Project documentation – value for money?

Posted on March 20, 2009


imagesI’m always baffled by the volume of documentation generated by a project. Pages of text and flow charts describing business & system requirements and project documentation.  Now, think of the value of this documentation during and after the project.

One wise man might ask: “why so much energy is consumed by the project team and what value am I really getting out of this.”

Let’s have a look on the type of documentation and the way there are managed. I will focus on the three majors although they are many others that could worth the effort to explore.

  • Business Requirements Documentation
  • System Requirements Documentation
  • Project Management Documentation

Business Requirements are usually written by consultants or integrators to ensure  a correct understanding of what the customer meant, and further configure or code the appropriate piece of software. These documents are most of the time written with word processor and are going thru several cycles of validation. It is not unusual to see thousand of pages produced with reference to each others. This heavy package has an additional objective: it is to protect parties for what is in scope and out of scope of the project  The advantage is very often more on the integrator side as “what is not written, is not in scope” and what will drive the workload on resource is only know by them as they are the experts of the technology or system they are implementing. To balance this shift in power the customer is insisting on seeing every thing he can think about in these documentations. Moving forward the quantity of documentation will measure its quality.

System Requirements is a different animal but surprisingly managed the same way. Based on the Business Requirements the Integrator is producing the technical translation and asked a customer validation on something he/she can not understand. Based on the complexity of the software or technology it becomes sometime absurd.

Project Management is usually more used in a strategic manner, as it is one of the first documentation that is produced. Heavy and nice package are produced that nobody is looking at when the project kicks off. In addition this documentation is distributed to the project team without much explanations.

My piece of advise will be to set up clearly the rules upfront with the selected partner and make it part of the contract itself. Project documentation consumes more or less half of the consulting effort, be pragmatic and focus on your needs.