How to manage a Request For Proposal – Part 3 : a specifications proposal template13 min read

Cartographie du projet

Ok, the RFQ analysis told you to go for it! Now is the time to write the proposal (aka the specifications you recommand for the project).

Thanks to Part 2, you manage to organize all your team to efficiently write the proposal in the minimum of time. In this third part, we will share with you a template for it: what to put in, how to build an easily updatable content with modular sections.

As we regularly say at Naept, the main best practice in documentation is reuse and iterate. So the template we are about to describe here is a variant of the request for proposal one we explained in the dedicated article. The purpose is to have similare templates, like this the reader can easily and intuitively navigate within documents. Besides lots of content need to be repeated from one to another, it is better if similar contents are located in similare locations.

Just like in the request for proposal template article, pick whatever suggestions suit your need, we build them to be relatively independant and modular.

Let’s dive into them…

The document contributors list

Importance : 1/5

This is the list of people that have contributed to the building of the document. We can even add their e-mail addresses and the role they played to help the readers of the document get answers to their questions.

ContributorsRoleCompany
Julien AUPARTReviewerNaept
Luc DUMONTWriterNaept
Anthony STARKWriterStark Industries

Evolutions list

Importance : 4/5

This is a highly critical piece of information to add to your document. Your proposal will gain in maturity with time and according to discussions with your customer. 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 one.

ItemsEvolutions
§1.2New
§3.5.2Deletion
§4.8Update

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 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. This contextualization articulates in several cascading descriptions.

You can basically duplicate every description from the request for proposal, at least to avoid having to retreive the original document in the first place. The purpose is to provide a future reader with the minimum of contextualization if it reads the document long after the end of the project in a search for reusable material for a new one for example.

Description of the companies

Importance : 3/5

In a proposal, there are now 2 companies working together : the customer and the supplier.

Describe both companies: what are their fields of expertise? Their implantations: local, nationwide, worldwide? Who are their customers, their market? What are their values? Etc.

Description of the overall project

Importance : 4/5

Your proposal belongs to a bigger project. Describe it

Description of the proposal subject

Importance : 5/5

Before going very deep into the detail of your solution by listing its specifications, you can just tell with 2 or 3 sentences its purpose for the reader to get the “big picture”.

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 proposal is to describe the solution matching the customer need, with an agreed level of details.

Bibliography

Importance : 5/5

While describing the specifications, you may refer to external documents. The reader 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:

ReferenceDocument
BIB01ARINC422 Standard, v5.2
BIB02Article : What is a traceability matrix ? Part two

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
  • the content 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 your 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 them all in their dedicated table and give each of them their own small reference:

ReferenceItem to be defined
TBD01The car wheel diameter
TBD02The car color
  1. You now have a clear and precise list of everything left to be defined.
  2. Thanks to the small reference you are just a couple of “Ctrl + H” away to update everywhere a detail is missing!

The specifications 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 specifications matching the customer requirements.

Consider each specification like a relatively small and independant task to do to cover one requirement, several requirements at once or just a fraction of a big customer requirement.

Try to make them the simpliest possible. If it is not possible, break one complexe specification in several ones. It is actually a good thing to have many more specifications than customer requirements. It means that your solution is well described and be easier to develop. It is always better to have many small steps than big ones.

Just like the requirements in the request for proposal, gather your specifications by topics.

How to structure a specification to make it efficient

We said it multiple times before, a specification is the description of a small, specific and self-reliant part of your solution. Here we will deal with how to arrange the specification 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_TP_AESTH_0014.1 Vehicle color
The paint reference used for the vehicle body shall be : MOTIP – 41530.
END

Coverage:
NPT_PROJETX_CDC_AESTH_0038.2 Vehicle color
NPT_PROJECT_CDC_GEN_0127.6 Project Guidelines
NPT_PROJECT_CDC_WEATHER_0538.2 Weather conditions

Reference and title

NPT_PROJETX_TP_AESTH_0014.1 Vehicle color

We already explained the benefit of using unique references to identify requirements or specifications in order to mention them in a traceability matrix, an evolution table or in any other document.

Here the root of the specification reference is the document reference : NPT_PROJECTX_TP_. This stands for the company Naept (NPT_) Technical Proposal (TP_) for the Project X (PROJECTX_) (see How to organize your project documentation (naming convention, storage location, order…).

To this root we add a short string identifying the specification category. In the example the string is “AESTH” for the category “Aesthetic”. We reuse the same category from the request for proposal to ease the back and forth between the documents.

Then the reference contains a string composed of a number. This number shall identify the specification. Two different specifications shall not have the same number in the document. So you know that the requirement “0014” is about the vehicle color.

Finally the reference ends with a point and another number that represents its revision. The revision is the number of times the specification has been updated. In our example, the specification 0014 is in its first revision. Giving a revision number to each specification is very useful to quickly identify the updated ones between 2 revisions of a document.

After the reference, we add a title telling in a few words what the specification is about. This helps the fast-reading of the document.

Content and end tag

The paint reference used for the vehicle body shall be : MOTIP – 41530.
END

Under the reference, you can now describe the content of your specification.

Ending the 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 (at least once it has been accepted by both sides). 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

If you check our article about the request for proposal template, you will see we had an “intention” section right after the requirement content. This is useful to contextualize the requirement, to help to understand why this requirement is for. But such an intention is not very relevent for a specification that the unique purpose is to match the need. That is why we do not recommand to add an intention in a specification.

The coverage

Coverage:
NPT_PROJETX_CDC_AESTH_0038.2 Vehicle color
NPT_PROJECT_CDC_GEN_0127.6 Project Guidelines
NPT_PROJECT_CDC_WEATHER_0538.2 Weather conditions

The coverage section is a new yet very important feature for a specification. It lists every requirements that are covered by the current specification.

So in our exemple the specification NPT_PROJETX_TP_AESTH_0014.1 contributes to match all or part of the needs described in the following requirements :

  • NPT_PROJETX_CDC_AESTH_0038.2 Vehicle color
  • NPT_PROJECT_CDC_GEN_0127.6 Project Guidelines
  • NPT_PROJECT_CDC_WEATHER_0538.2 Weather conditions

Warning : I insist on the point that the specification doesn’t have to COMPLETELY match the listed requirement. It can only match a part of each. You may have very complexe requirements that will be totally covered by the contributions of several specifications. Which is again a good practice! Having several specifications to cover one requirement makes the project (and the proposal document) more flexible so easier to manage and to adapt to the customer evolutions.

The traceability matrices

At the end of the document, after the specifications list, there is a new feature to add compare to the request for proposal : the traceability matrices. We published a two part article on the topic : What is a traceability matrix ? Part one, where we detail how to implement them in you document. But here is what they are used for in a couple of word.

As we just saw, one specification can partly cover several requirements. So how do you make sure in the end that your proposal covers entirely the request of your customer? By using traceability matrices.

A traceability matrix is a simple two column table. The first column contains all your customer requirement. In the second column, facing each requirement, you list every specification covering it. Once the table is completed that to every specification coverage section, you have a complete clear view of how your solution covers your customer need. You immediately see if there is a requirement not covered. Besides, if your customer updates a requirement, you know exactly which specifications to update too.

Customer requirementsSpecifications
NPT_PROJETX_CDC_AESTH_0038.2NPT_PROJETX_TP_AESTH_0014.1
NPT_PROJECT_CDC_GEN_0127.6NPT_PROJETX_TP_AESTH_0014.1
NPT_PROJECT_CDC_WEATHER_0538.2NPT_PROJETX_TP_AESTH_0014.1
Downstream Traceability Matrix

This matrix is called downstream traceability matrix because it comes from the customer request and goes down your specifications. You can add also an upstream traceability matrice which goes the other way arround, from your specifications up to the requirement. This tool is useful for the project management: it helps identify the most critical specifications: those covering the most requirements. You may want to work on them first.

SpecificationsCustomer requirements
NPT_PROJETX_TP_AESTH_0014.1NPT_PROJETX_CDC_AESTH_0038.2
NPT_PROJECT_CDC_GEN_0127.6
NPT_PROJECT_CDC_WEATHER_0538.2
Upstream Traceability Matrix

Conclusion

We have intentionnaly kept this method the closest possible to the one for the request for proposal in order to maximize the reusable content from one document to another. Those modular elements help creating highly modulare and may not be all relevent for your own documentation but at least they allow creating a consistent environment for your readers to understand your project faster but they may not be all relevent for your own documentation. Consider this article as a toolbox where to pick from.

The more reusable your documentation is, the more time you can spend on effectively matching your customer need.

What about you?

dialog

Do you use templates for your documentation?
Is there content or modules you always put in it?
How to you manage not to spend too much time on this activity?

📝 Contribute to our Study of documentation on business projects.

Related Posts

Leave a Reply