I am struggling with something that I wanted to post for discussion. When we collect requirements from a client they usually put together a requirements document that is their master document for the project. Sometimes we are the only vendor included in the document other times there are requirements for us as well as other vendors. Our client is responsible for maintaining this document. We take this document and reformat their requirements in to our format (completely different from the client). We then keep this copy as our master document and update it accordingly as things change (internally or externally). I am struggling with this a little because at first glance it seems to be a problem because we now have 2 documents (one for the client and one for us). We could translate them incorrectly as well as it is difficult to keep them in line so we could mistakenly deliver something that they were not expecting. On the other hand we usually have our own internal requirements that we need to add that do not impact the customer (quality assurance and requirements to run the project as we run the processes at our site for our clients). This could also reduce the “ownership” of the project by our PM as they now are just passing the requirements from the client to our team. Any ideas on how to best handle this situationj? Saving Changes...
Sort By:
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Sounds like communication, a critical success factor, needs to be improved. Its pretty obvious that having one requirements document would be helpful. Is the format your company uses really important or is it just a formality? Eliminating anything done as a mere formality will help any project.
Ask yourself the question "would it help if we met the client more than halfway by using their requirements document as our bible?" Saving Changes...
John ZacharProduct Dev Manager| Association for Project Management (APM)Brackley,, Northamptonshire, United Kingdom
I think this is likely to be even messier.
A good requirements doc identified the requirements - not solutions; so there are all the issues about actually getting the requirements correct.
Then there is the issue of making sure that the requirments statements are actually requirements statements, not just statements of desires / needs / wants / etc. This means that any requirements statement (assuming it is a good requirements statement) should be able to be satisfied in more than one fashion. There may the odd occasion when only one method (solution) will work, but that should be only rare occasions.
Then following the requirements statement, I include the criteria that will satisfy the requirements statement.
The requirement is . . . .
That requirement will be satisfied if . . . .
Inclusion of assumptions, constraints and notes at this stage can be very beneficial.
Assuming you follow the above, then the agreement betwee the two sets of people should be fairly easy. If I haven't made myself clear enough, do let me know.
