What is the key Project Documentation?

Whatever methodology you are using; Waterfall, Agile, Scrum, Kanban, Scrumban, Lean ,XP – Extreme Programming methodology, PRINCE2 – controlled project management that leaves nothing to chance, or PMI’s PMBOK – applying universal standards to waterfall project management you need good documentation. So what are the key project management documents you require?

There’s no doubt that project documentation is a vital part of project management. It is substantiated by the essential two functions of documentation: to make sure that project requirements are fulfilled and to establish traceability with regard to what has been done, who has done it, and when it has been done.

Each phase of the project lifecycle requires a level of documentation, remember nobody wants documentation for documentation sake, it has to add benefit. Every document has to have a purpose, key to which it is helping the PM manage the project and get approval and decisions where needed. Detailed below are the key documents required based upon our experience:

 

INITIATION

The three documents in initiation / Kick Off work up the idea for a project from a one-page overview to a Project Charter, supported by the Business Case, which is a living breathing tool that drives the need for the project.

You add more detail at each point when you have established that it’s worth progressing, checking the expected benefits are still going to be achieved. The information from the earlier documents is not duplicated because in the later ones you expand on the information.

 

The Idea: A one-page overview of the basics of the idea for the project.

The recommendation: Typically five to ten sides of paper, exploring options, recommending one, recommending not to go ahead after all or perhaps recommending that while the work should be done, it doesn’t need a project to do it.

Project Charter: Okay, it’s looking like a viable project now. The Project Charter sets down the scope and an overall Business Case and is developed ideally using project and business expertise.

You will also develop the Stakeholder Log, mapping the interests of all parties in the project and a Stakeholder matrix

and a Requirement Specification and Trace-ability Matrix, A Requirement Specification document is a complete description of the system to be developed. It contains all interactions users will have with the system as well as non-functional requirements, the purpose of the trace-ability is a table that traces a requirement to the tests that are needed to verify that the requirement is fulfilled. A good trace-ability matrix will provide backward and forward trace-ability: a requirement can be traced to a test and a test to a requirement.

PLANNING

During the planning stage you should utilize three further documents along with the Project Charter created during the Initiation phase.

Project Management Plan (PMP): The tactical view of how you’ll manage the project. You’ll need some or all of the following:

 

· Project Plan: With the product, Work Breakdown structure, activity and resource lists and plans, consider utilizing a tool to produce this such as MS Project and also the budget

 

· Risk Plan: How you will control risk on the project, including reporting and escalation procedures

 

· Quality Plan: The level of quality to be achieved, and how you will achieve it

 

· Communications Plan: What information will be needed and how it will be communicated

 

· Stakeholder Plan: How you will manage stakeholders

 

· Procurement Plan: If your project involves a significant amount of procurement this plan shows what will be bought and when, including lead times which are important if there are dependencies in the project

 

· Other Controls: Details of any other controls to be used, not covered in the other plans in the PMP

 

· Stage Plan: The plan for the first Delivery Stage so you can move ahead promptly when the Charter and PMP are approved

 

The planning stage is the time to start to develop the core logs for the project:

Logs are working documents to keep track of things such as risks. You may not need all of the ones in the list below, but you’ll need most of them. You set up the logs in the Planning Stage, or sometimes before, ready for use throughout the project.

Don’t dismiss logs as unnecessary and project bureaucracy. They are necessary. For example, you may decide not to bother with a Risk Log. Instead you’ll just keep a simple spreadsheet with each risk on a row. Okay, you’ll need some columns with headings then. Perhaps items such as how severe each risk is, what actions you have planned to control it, who is responsible for taking any action and managing the risk, when you last reviewed the risk. You get the point; you’ve just re-invented the Risk Log.

Managing and mitigating risk is a vital element of managing project success.

 

Project Log: This functions as the Project Manager’s journal. It contains reminders, notes, records of important phone calls and decisions, lessons being learned from the project, and so on. It’s both simple and really useful.

 

Risk Issue and Assumptions Log: Another simple but powerful log, the Risk Log has information on each risk and how it is being managed. It should be made available ‘read-only’ to everyone on the project so that everyone is aware of the risks and is watching out for them. It also pays to keep a log of assumptions and to validate them from time to time, considering what the impact on the project would be if the assumption proves to be untrue.

Dependencies Log, capture and monitor all the dependencies you have on others to deliver the project and others may have on you. Record the date when the dependency is required and openly share the dependency with the owner / person responsible for delivery.

Change Log: Not mentioned by many of the project approaches except however this log is very powerful. If you keep a list of changes in this log you can quickly track which changes that have been accepted, which have been rejected, who suggested them and, importantly, the impact on the project, what they cost and time impacts.

 

Executing and Monitoring

During the Delivery Stages, Closure Stage and evaluation of the project you’ll need some further documents. This list is to help you think through what you’ll need, and perhaps what you won’t need, the key documents you will require include:

 

Stage/ regular progress Report: For the Project Manager to report progress to their Steering Group and stakeholders, possibly copied to others such as key stakeholders and Project Managers of any interfacing projects.

 

Team Progress Report: Where you have a project with multiple teams, the Team Leaders will need to inform the Project Manager of progress on their current work assignments.

Project Issue: A communication from anyone in the project to the Project Manager, but you may choose to use them for written communications between the Project Manager and the Steering Group too.

Project / Stage Closure

Stage Completion Report: Produced at the end of each stage, this report is used by the Project Manager to inform the Project Steering Group of how the stage went. So, what was the final time and cost? Were there any problems that will affect future stages? This report may be given as a presentation at the Stage Gate.

Project Completion Report: Produced by the Project Manager at the end of the project, it reports how the whole project went. It should also record any lessons learned during the project, capture lessons learnt throughout the project not just the end; good and bad, that may be of value to future projects. As such a Lessons Learned Log should be kept during the Project.

 

Project Evaluation Report: Produced after the end of the project, this sets down information on benefits realization, detailing what the actual benefits were compared to what was expected when the project started and the suitability of project deliverable s after an initial period of use say 3 months.

 

Lessons learnt report: Summary of what went well in the project and what went badly and the lessons learnt during the project. It provides guidance for projects in the future.

 

Overall with documentation, follow the KISS principle of Keep It Simple, Stupid or remember less is more. The decision on the level of documentation in the project is a control decision and it’s a balancing act. On the one hand you don’t want excessive or unnecessary documents, on the other hand you need to keep the project under control and other people need to monitor its progress.

 

The control level of documentation may be dictated in part by your organization’s standards, engineering firms may require key design documentation to be produced (logical technical models, high-level design’s and detailed design documentation). However, even here think hard, if something is set down as mandatory for every project, be prepared to challenge it if there’s no value to your project. You may need to get the Project Steering Group on board to do that, as it’s not in the PSGs interest to incur unnecessary overheads and divert effort from getting the project delivered successfully.

 

In other cases, it’s not so much the organizational standards that are dictating the degree of documentation but a Project Management Office. As with standards, though, question the value to your particular project of what they’re doing. You really have quite enough to do without spending time and effort on unnecessary documentation for documentations sake.

 

pmp-practitioners.com can provide you with all your document needs. Each document pack contains Hot Tips, Guidelines, a Template and a Checklist.

These are bundled together as a pack that you can buy and download separately. Most document bundles are priced at $47 each and the whole document set is offered at a heavily discounted price.

https://pmp-practitioners.com/documents/

We provide 20 days on line post-sales support for purchased documents from around the World.