Documentation always seems to be the most difficult part of the project to complete. There is little glamour and no major kudos in doing documentation. That does not diminish its importance, however. There are at least five reasons why the project manager and team need to do documentation on the project:



Reference for future changes in deliverables. Even though the project work is complete, there may be further changes that warrant follow-up projects. By using the deliverables, the customer may identify improvement opportunities, features to be added, and functions to be modified. The documentation of the project just completed is the foundation for the follow-up projects.



Historical record for estimating duration and cost on future projects, activities, and tasks. Completed projects are a great source of information for future projects, but only if data and other documentation from them is archived so that it can be retrieved and used. Estimated and actual duration and cost for each activity on completed projects are particularly valuable for estimating these variables on future projects.



Training resource for new project managers. History is a great teacher, and nowhere is that more significant than on completed projects. Such items as how the WBS architecture was determined, how change requests were analyzed and decisions reached, problem identification, analysis and resolution situations, and a variety of other experiences are invaluable lessons for the newly appointed project manager.



Input for further training and development of the project team. As a reference, project documentation can help the project team deal with situations that arise in the current project. How a similar problem or change request was handled in the past is an excellent example.



Input for performance evaluation by the functional managers of the project team members. In many organizations, project documentation can be used as input to the performance evaluations of the project manager and team members.



Keep in mind - care must be exercised in the use of such information, however. There will be cases where a project was doomed to fail even though the team members’ performance may have been exemplary. The reverse is also likely. The project was destined to be a success even though the team members’ performance may have been less than expected.  Use and distribute this information with caution.



Given all that documentation can do for you, to be most effective and useful, the documentation for a given project should include the following parts:

 

 





     
  •  
  • Project Overview Statement




    •  
  •  
  • Project proposal and backup data




    •  
  •  
  • Original and revised project schedules




    •  
  •  
  • Minutes of all project team meetings




    •  
  •  
  • Copies of all status reports




    •  
  •  
  • Design documents




    •  
  •  
  • Copies of all change notices




    •  
  •  
  • Copies of all written communications




    •  
  •  
  • Outstanding issues reports




    •  
  •  
  • Final report




    •  
  •  
  • Sample deliverables (if appropriate)




    •  
  •  
  • Client acceptance documents




    •  
  •  
  • Post-implementation audit report




    •  
  •  

 


This list is all-encompassing. For a given project, the project manager has to determine what documentation is appropriate. Always refer back to value-added considerations. If the document has value, and many will have good value for future projects, then include it in the documentation. Note also that the list contains very little that does not arise naturally in the execution of the project.