Consultancy brings together a number of skills from an individual or organization in order to deliver a successful project to a client. From the analytical skills at specification, through the technical skills of the execution and support, to the organizational skills of project management, the common thread that should bring all of these together to form a cohesive project is documentation.

The requirement for project documentation should come from both the consultancy and the client, and both will have their own needs from the produced documentation. In this column, I’ll look at some of the reasons for and elements of project documentation—so consultants can keep a relevant history of their work and give the client the support they require. Most importantly, bear in mind that good project documentation adds value to the delivered project.

The need for documentation
To sum up the need for documentation, I would cite three concepts: traceability, history, and control. In a previous column on change control, I discussed tracking configuration changes during the execution of a project and subsequent maintenance. This is a good example of documentation providing traceability, though it can also trace the sequence of implementation steps, the key decisions made in the project, and the time scales of the project. The documentation can also provide a history of the project by being used as a constant work in progress through the addition of daily or weekly updates. Documentation should also provide control of the project by providing a single source of knowledge, which is reviewed by all parties and understood as the definition of the current state of the project.

Through these banners, project documentation can be a mediating factor in discussions and essential in tracking a long project. Together with change control, this source of knowledge can also be a lifesaver in a crisis.

Documentation content
Content can vary in its organization from project to project, though a valuable exercise would be to produce a standard template on which to base your future documentation products. This has timesaving benefits later as you start each project, allows the consulting staff to become familiar with a documentation scheme of work, and gives the consultancy the opportunity to build its corporate identity into the documentation product. To build your template, take a look at one of your past projects and see how it followed your consultancy approach—you should be able to put sections together that mirror that approach. As a starting point, here are some possible subheadings for your template:

  • Scope
  • Current Configuration
  • Project Issues and Resolutions
  • Outstanding Issues and Resolutions
  • Completion
  • Review

A skill in producing the documentation of a project is in bringing the requirements from all parties into the same piece of documentation as far as possible. This lessens the number of pieces of documentation in circulation and promotes visibility and cooperation from both parties in the project.

Content will vary in depth and range depending on the nature of the project, time spans, and circulation. However, there are some items that both parties will usually want to see in most projects, and these could be built into your templates. These will encompass the “hard” factual items, such as server and software configurations, and the “soft” items like project issues, minutes of meetings, and points of contact.

So, some project documentation could simply consist of configurations of the installed software while others may document the life span of a longer project together with notes of decisions made and dates of milestones reached. One important note is to agree on the level of detail that your client requires. There is no point in swamping them with pages of description when they only require a note of the final decision. Conversely, it can be very difficult to add accurate content to the documentation later, so too little detail can also be a waste of effort.

Managing the documentation effort
So far, it may appear that, as consultants, we have just created ourselves another great workload! It’s true that producing project documentation can be a time-consuming burden that does little to actually move a project forward.

The time that it takes to produce the documentation needs to be carefully managed. It is easy for this part of the whole project to become a workload of its own. The amount of time actually taken should reflect a number of factors. These might include the importance the client places on the documentation, the detail required, the provision you have made in the project costing for project management, and your relationship with your client.

Remember, however, that the documentation product should also be seen as part of your project “deliverables.” Left with the client, it can serve as your best “business card.” Ensure that it is presented well and meets the clients’ expectations. Along with the change control and custom operational procedures you have created for your client, you leave behind a professional account of your work.

David Parkinson lives and works out of the North West United Kingdom as principal consultant for Control Key Ltd. Clients range from a Premiership Football Club to small manufacturing sites.

How important is project documentation? What process does your firm have in place? Give us your thoughts by posting a comment below. If you have a question or comment for David, send us a note.