Compliance matrix: how to manage a request for proposal

7 min readMar 22, 2021

You have just received a new request for proposal from a customer. A big one. 30 pages, several expertise domains required, almost a hundred requirement. You have to sort it out. You will need a compliance matrix!

Vocabulary

Before going further, let’s check some definitions of concepts we mention in this article:

Request For Proposal
An RFQ is the document a client sends you to explain more or less briefly the project he would like you to do for him. When it is very detailed, it can be considered as a specification document. You will have to answer with a proposal in which you tell him how much the project will cost him.

The purpose

Sometimes the RFQ are rather light and request a short proposal. But, if on the contrary, the request is very detailed then its treatment requires a deep study to :

understand well-enough what is asked
precisely explain your solution

Besides you may face some competitors on the market so you cannot loose any time. Therefore you have to be fast and organized. The compliance matrix is a tool allowing you to manage every components of your customer need to define what to do with it : ask for more information, go for it, subcontract…

So basically a compliance matrix is a kind of conversion box that takes the customer’s request as an input and produces your treatment for its need, aka your solution as an output.

The format

Just like the reading sheet, the compliance matrix is a simple spreadsheet document. So you can build one from your favorite editor. You can download for free a model we made after multiple customer feedbacks. This is a Microsoft Excel template format. Which means every time you double click on it, it creates a copy of the original file. If you want to modify the template to add your own reusable content, just right click on it and hit modify.

The content

Let’s see what the headers of this matrix are and how to fill this table.

Each line of the matrix represents the management of a specific need expressed by the customer. We call such a need assessment: a requirement. The blue columns contain the data issued from the customer, and the yellow ones are about your way to manage them.

And last disclaimer, such a matrix is highly versatile. Each company has its own version. The columns vary a lot depending on your RFQ treatment workflow, the size of your company, the number of people involved in the process, the complexity of the customer’s need, … We have encountered dozens of different kind of matrices. Here we present the most common headers and the management they induce. So feel free to download our template and update it to your needs.

# Id

This is just the number of the line. It helps communicating on the matrix with the other people on the project. By default, as soon as you deal with an array of any kind, it is a good practice to give a simple iterative id to the lines in order to keep track of the new entries.

Source

This is the document title / name where the customer requirement comes from.

Sometimes the customer RFQ is a unique document, so every requirement will have the same Source. But it can happen that its need is described in multiple documents like in the construction industry where you have a main file explaining the global project and many annexes detailing specific aspects.

Location

The document can be hundred of pages long, so it might be useful to indicate where in the document this requirement is located. This is the purpose of this column.

We recommend to not indicate a page number because they might evolve from a document revision to another. Instead we suggest to give the title or the number of the smallest sub-section containing the requirement.

Requirement Reference

Here you identify precisely the requirement. You can either put the reference if there is one, or a simple title. The purpose here is to know what requirement we are talking about.

Requirement content

This item is optional but as it is very frequently displayed in compliance matrices we encountered, we did put it in our template.

If the requirement is relatively short, you can copy it here. It avoids having to look for it in the document. It eases the management but what if the requirement evolves ? You will have to remember to update it. So you must be careful with this item. The most important is to fill the 3 previous ones (source, location and requirement reference) to ensure the traceability.

Theme

Here you tell, in one or two words, what the requirement is about, what expertise is involved or what kind of technology. For example : legals, mechanics, web development, marketing, …

The purpose of this item is to sort, classify, categorize the requirement to ease its management. So if an expert in mechanics has to have a quick look, he can filter the content by his field of expertise.

MoSCoW

This one is very interesting. It is about the MoSCoW method which allows to prioritize the requests. It tells the criticality level of a need. MoSCoW is an imperfect acronym to memorize in order the different levels :

M for Must. An M requirement is an absolute need for the customer
S for Should.
C for Could.
W for Wish. Sometimes it says W for Won’t.

This scale is very personal for every one. So if your customer gives you its signification or another classification, this is a very precious element telling you where are the pain point.

If he doesn’t give you such information, it could be very interesting to ask him for it. Or maybe it means that every requirement is equally needed. It’s worth asking.

Impacts

Here we enter the columns that are specific to your own management. So starting with this one until the last, you may want to adapt them.

Impacts is a collection of several columns : Field 1, Field 2, … Those fields should be replaced by your different departments / services / expertise domains. Then complete the column by putting an “X” or a “1” (we prefer 1 so you can apply formula more easily) when a requirement is impacting one of your fields.

When the requirement is complex, it might involve several expertise domains and those columns are another way to classify the requirement. For example, you could have a project manager who initiates the compliance matrix. He reads the RFQ, identify the requirement in the table and for each of them he sets 1 where they must be reviewed by this or that expert. So when the expert received the matrix, he sorts the requirement by his own field so he doesn’t have to read all the RQF.

Risk

To every requirement, it is possible to give a risk level : whether it is totally safe to do or we anticipate future difficulties on this requirement.

Here too, the way to evaluate risk is very specific to a company. So, in our template, we just put a scale from 1 to 5. Feel free to define 1 or 5 as your maximum risk level or even to define another scale.

Management

This new set of columns represents your way to deal with the requirement during the analysis. We suggest in our template 4 possible managements for requirement :

Technical Analysis : the requirement is complex and requires one of your specialists to have a look and give his opinion.
Customer clarification : the requirement is not very clear and you have some questions about it for your customer. Once the requirement is clarified, a new management decision shall be made.
Internal execution : the requirement is clear, your company has the skills to deal with it. It is a green light.
Subcontracting : the requirement is understood, your company cannot execute it but you have a supplier you can subcontract it to.

Those 4 ways may not cover all the possibilities, they are just examples. Complete them with your own internal processes.

Analysis / Comment

This section is to give some details about either the expert analysis or just the requirement itself. It shall be used by any contributors to give enlightenment or ask questions about the management or the understanding of the requirement.

Go/NoGo

And finally, once the requirement understanding and management has been fully processed, you can tell here if it is a Go or a NoGo. In other words, you say Go when you can deal with the requirement whatever the management you chose, and you say NoGo when you cannot or you prefer not to because it is too risky.

Conclusion

Of course the best case scenario is to Go on all requirements, but identifying very early in the process the risks or the impossibilities on a project is the power of the compliance matrix. It is better to find them out at the beginning than several months into the project. At that stage the cost of fixing them could be multiplied several times and put at risk not only your company but your customer’s too!

The compliance matrix is another very powerful tool allowing you to cut a big request in lots of smaller simpler ones. Even if you customer has written a big continuous and not well structured need description, you can use the matrix to cut it, identify requirements within it and manage them all flawlessly.

📝 Contribute to our Study of documentation on business projects.

Originally published at https://www.naept.com on March 22, 2021.