Do I Need to Match-up the Functional Spec with the Spec in the Contract

Question

This maybe a bit of a noob question to you client facing PM's out there, but I'm a PM with a pre-sales background, so please bear with me.

I'm used to working on projects where you have an initial scope (high level) and you work with the customer to define their requirements, forming some sort of a functional specification. Sometimes there may be an RFP, but it's usually not contractual.

I recently started a new job working as a PM for a vendor dealing predominantly with government clients (IT). My first project is rather big, with a mix of off the shelf and in-house (customised) software. We won the project in response to a tender, in which was included a set of general / functional specifications - two documents labeled exactly that.

Now, it's a fairly complex project; thus, there will be many days of requirements gathering. But as I understand it, we are contractually obligated to deliver (within scope) what is defined in the specs. In fact, the original specs are quite detailed (user should be able to hover over link and see a preview of the image, etc..)

I'm supposed to eventually (after all our requirements gathering sessions) come up with a functional specification that is somehow derived from the conversations we have with the users, plus the original specifications, of course.

The problem is that, after reading functional specs (and other project documentation) from other project managers in my company, I see that there is rarely any link back to the contractual tender specification. I feel that there is something missing, i.e when the client eventually signs off on our specs, surely they will check to make sure they conform to the original tender specs? Where our functional spec does not conform, surely they will ask questions.

I suppose my point is this: After speaking to the end user, some points of the original tender specs (contract) may become invalid, may change, or there may be additions (within scope). So, should there be a matrix in between the two documents (original spec and end functional spec) to track all this?

Many thanks for any information on this. I just feel like there is a big gap somewhere.

Answer 1

If I were in your shoes, I would surely feel the need to track any changes made to the spec. When the client reviews what you have and makes changes, whether they be additions or removals, it would be wise to clearly document this, as it's very possible that all stakeholders representing "the client" may not be all on the same page.

For instance, if the client's people doing the reviewing are in a different department than the client's people who drafted the original spec, there could be a misunderstanding later on as to why features A, B, and C weren't implemented when they were clearly listed in the original spec drafted by the client.

The advantage of having a matrix, or some other documentation highlighting the changes, is that you could have this sent out to all stakeholders for review, including other contacts you may have that work for the client and internal stakeholders, such as executives, other project managers with a stake in the project, and developers.

This may be an overkill, but I'm not familiar with your company culture or the client's company culture. However, it's better to have it and not need it than to need it and not have it.

Answer 2

This is fairly common with government contracts as they use a lot of 'boilerplate' specs for tenders, and then adjust as the project progresses.

Really what you want is the Change Control process that the tender describes. Requests for Change, Requests for Information, etc.

Make sure that your contract is clear on who has the ability to sign off on changes, and who's approval is needed to implement those changes. Then, as you find these gaps, send a Request for Clarification to get some direction, and once you've got that, send a Request for Change to document the approved change/discrepancy.

This process, while lengthy, provides you as the contractor three distinct advantages -

It gives you a way to formally inform the client of the gaps you're finding

It gives you clarification as to what's really wanted

It provides a paper trail of the decisions made, and who made them

Having done a number of government projects over the years, the only real way to handle it and protect yourself it to make sure that EVERY decision is documented with the correct signature. The Tender specs may be loose, but the Contractual and Procedures specs most definitely aren't. Any change you make from the original request that isn't documented will be treated a s deviation from the contract and you will be required to correct it at your expense.

Sorry if this sounds alarmist, but on some projects I have literally spent years arguing over the wording in a single line in the contract in order to get paid for work performed.