How to build a Request For Proposal?
Here is a method to write a request for proposal: which elements to put in, how to sequence and structure its content… Those best practices come from our own experience of engineering project management and from companies we worked with.
Before going further, let’s check some definitions of concepts we mention in this article:
Supplier
In this article, we call supplier the person to whom you delegate the realization of the product or a service described in your request for proposal. This supplier can belong to another company or to another department of your own company.
In a previous article, we saw how to organize and archive all the project documentation, such as the request for proposal. Today we are going to deal with the content of the request for proposal. We are going to review all the useful sections to add to make it the most complete, easy to understand for your supplier and easy to update for you if your need evolves. We have add a personal importance level for each item to tell you, from our point of view, how required we think they are.
We suggest you download our open-source template to get an illustration of the concepts we explain here.
The document contributors list
Importance : 1/5
This is the list of the people that have contributed to the building of the document. We can even add their e-mail address and the role they played to help the readers of the document get answers to their questions.
Evolutions list
Importance : 4/5
This is a highly critical piece of information to add to your document. Your need assessment will gain in maturity with time and according to discussions with your supplier. So you will keep it up-to-date to ease and speed up the review of a new revision of your document; it can be a great help to identify items that have evolved since the last revision.
Check the dedicated section of our article about matrices for more details.
Vocabulary
Importance : 5/5
Before going technical in your document, it can be very helpful to define all the acronyms, concepts and technical wording you will use.
It is likely that a reader would use the same wording but with a slightly different meaning. That difference could lead to misunderstanding later in the project. Or maybe you have very specific concept hardly understandable for anyone else.
So to limit the risks, the best is to start the document with a table explaining every technical concept.
We dive a little deeper in this issue in the following article : 4 major difficulties in writing a specification document
Descriptions
This is another major difficulty in writing a document: it is very important to describe the context of the project the document belongs to. Thanks to those descriptions, your supplier will provide you with better enlightened advices. This contextualization articulates in several cascading descriptions.
Your company description
Importance : 3/5
Describe you company: what is its field of expertise? What is its implantation: local, nationwide, worldwide? Who are your customers, your market? What are your values? Etc.
Telling more about you when you post your request for proposal on an online platform may bring new suppliers. You can better benchmark those suppliers depending on if they already are experienced with your field of expertise…
The project description
Importance : 4/5
The need you describe in the request for proposal belongs to a bigger project.
For example, I used to hire a supplier to build several industrial computers with very technical specifications. I wasn’t a specialist in computer building, that’s why I hired a supplier, so in addition to my need description I gave a few words about the bigger project those computer will be used for. According to this context, my supplier was able to give me pieces of advicesand tell me about risks I wasn’t aware of. And together we came up to better requirement for those computers.
The request for proposal subject description
Importance : 5/5
Before going very deep into the detail of you need by listing its requirements, you can just tell with 2 or 3 sentences the purpose of your need for your supplier to get the “big picture”.
In my previous example, the computers I needed were supposed to pilot test benches to validate a plane calculator.
This specific description can easily be merged into the project’s description.
Description of the document
Importance : 2/5
Finally we deal with the purpose of the document itself. During the project, you may have several kinds of documents (request for proposals, hardware specifications, software specifications, validation plans…). They can reproduce the same descriptions previously detailed but each of them will have a specific description that gives the purpose of the document itself.
The purpose of the request for proposal is to provide the suppliers candidates with a relatively short description of the need. It is expected from the suppliers to match this request with a document describing their solution in order to select the best proposition amongst all the suppliers.
Here are some brief descriptions for the other documents of the project:
- Hardware specifications: they shall describe in detail the supplier’s solution from the hardware point of view
- Software specifications: they shall describe in detail the supplier’s solution from the software point of view
- Validation plans: they shall describe all the tests to be perform in order to check the integrity of the deliverable coverage of the customer needs listed in the request for proposal.
Bibliography
Importance : 5/5
While expressing your need you may refer to external documents. The reader of the request for proposal shall also read those external documents to understand what you require.
Such external documents can be for example:
- A description of a standard the deliverable shall respect
- A construction plan
- A component datasheet
- An article from a specialized journal
- …
It will be very useful to list all those external documents in a dedicated table. This table shall at least contain the title, the revision of the document and if possible a link to find it.
Besides, to avoid repeating the complete title of a document every time you want to refer to it, we can give to each external document a small reference to put in the text. This reference can consist in several alphanumeric characters and the links between the references and the external documents are given by the bibliography table as follow:
A benefit of this method is that if an external document revision evolves you won’t have to update your document everywhere you mention it, you will just have to update the bibliography table and the small reference can stay the same. So your document is easier to maintain!
The “To Be Define” elements table
Importance : 4/5
You may have to publish your document before it is completely finished for several reasons:
- you are waiting for some information details
- your need is not complete yet because you require some expert opinion
- To meet your deadlines you need to initiate the project as soon as possible
Given that, there are still some details to be defined within you document, some “holes in the racket”. Just like the external document mentions, those missing details can pop here and there. So a good practice is to list all of them in their dedicated table and give to each of them their own small reference:
- You have now a clear and precise list of everything left to be defined.
- Thanks to the small reference you are just a couple of “Ctrl + F” away to update everywhere a detail is missing!
The need requirements list
Importance : 5/5
Finally! This section represents 95% of the content of the document. This is where you will describe in the most exhaustively possible way all the requirements of your need.
Consider each requirement like an item of a shopping list. It is the shortest description of a specific need of your project. Try to make each requirement the least dependent possible from another one. Try to make each of them an easily identifiable paragraph. And gather all the requirements talking about a specific thematic under a unique category (or section, or chapter, you name the structure). Those little tips will make them easier to update.
For more details, check this article Needs assessment : some good practices.
In the following section, we will show you a way to structure one requirement. This structure applies the previous tips.
How to structure a requirement to make it efficient
We said it multiple times before, a requirement is the expression of a small, specific and self-reliant need of the project. Here we will deal with how to arrange the requirement content in order to make it easier to identify, update and reuse on other projects. We are going to break down this example:
NPT_PROJETX_CDC_AESTH_0038.2 Vehicle color
The vehicle shall be painted in red.
ENDIntention : Red is the company identity color.
Reference and title
NPT_PROJETX_CDC_AESTH_0038.2 Vehicle color
We already explained the benefit of using unique references to identify requirements in order to mention it in a traceability matrix, an evolution table or in any other document.
Here the root of the requirement reference is the document reference (see How to organize your project documentation). To this root we add a short string identifying the requirement category. In the example the string is “AESTH” for the category “Aesthetic”. We put this requirement in this category because it was dealing with the color of the vehicle.
Then the reference contains a string composed of a number. This number shall identify the requirement. Two different requirements shall not have the same number in the document. So you know that the requirement “0038” is about the vehicle color.
Finally the requirement reference ends with a point and another number that represents its revision. The revision is the number of times the requirement has been updated. In our example, this is the second time the requirement 0038 has been updated. Giving a revision number to each requirement is very useful to quickly identify the updated requirements between 2 revisions of a document.
After the reference, we add a title to the requirement telling in a few words what the requirement is about. This helps the fast-reading of the document.
Content and end tag
The vehicle shall be painted in red.
END
Under the reference, you can now describe the content of your requirement.
Ending the requirement description with the “END” tag allows to frame what is mandatory and precisely define the project perimeter. The reader knows that everything contained between the reference and the END tag is not open to negotiation from the contract point of view. This convention can be settled in the document description for example.
I have added a margin for the content to make it more comfortable to read. That is another way to identify the content.
The Intention
Intention : Red is the company identity color.
This is, in my opinion, a good practice to add to your documents that comes from legals. After a mandatory item such as a requirement, we add an optional paragraph explaining why we have such a need. Sometimes the requirement content is complex and we could be tempted to lengthen it with not so mandatory indications trying to make it clearer. But mixing mandatory content with popularization risks to blur the perimeter.
So when an explanation would help to understand a requirement, just add it after an “Intention” paragraph that won’t interfere with the mandatory project perimeter.
Conclusion
That’s all folks! You now have a set of modular content to populate to request for proposal in order to make it clearer and easier to update. Besides all those items are highly modular, so you can put them (or not) wherever you want in your documents. So they can be reused, enhanced and optimized over and over. The more you reuse them from a project to another, the more efficient they get and the better is your documentation!
What about you?
How do you structure your documents?
Do you add other items?
What are your best practices?
📝 Contribute to our Study of documentation on business projects.
