Chapter 2

The Key Documents

In This Chapter

About documents and why you’ll need at least some

When a document needn’t be a document

Documents for Kick Off and the Planning Stage

Documents for control, including progress reports

Balancing the amount of documentation against the control needs

Chapter 1 contains a warning about not creating a ‘paper mountain’ in your project. However, unless you have a particularly good memory and nobody else will ever need to see any project information, you’re going to have to write some stuff down.

This chapter explains the range of documents you may want to think about for your project. You may not need all of them, but you can use the checklists to think through what you will need, and then how much detail you should go into, which in turn will depend on the control needs of the project. Later chapters in the book contain checklists that will then help you make sure that you’ve thought through everything correctly. Those chapters also include templates to save you having to design documents from scratch.

A document needn’t always be a document. To keep things simple, this book refers to documents, but a document needn’t always be a document. For example, a progress report may be entirely verbal or given in the form of a short business presentation with visuals. In the early part of Kick Off, the Idea and Recommendation may each be an agenda item in a management meeting where someone explains the proposed project. The content is the same; it’s just the medium that’s different. In each case, think through the best way of communicating; the answer isn’t always a document.

Kick Off

The three documents in Kick Off work up the idea for a project from a one-side overview to an Outline Charter. You add more detail at each point when you have established that it’s worth progressing. The information from the earlier documents is not duplicated because in the later ones you expand on the information in the earlier ones.

• 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.
• The Outline Charter: Okay, it’s looking like a viable project now. The Outline Charter sets down the scope and an overview Business Case and is developed using project expertise, not just business expertise.

Project Planning

If the managers in overall charge of the project and its preparation, the Project Steering Group (PSG), accepts the Outline, it’s time to start the project itself and that begins with the Planning Stage. You’ll need some major documents here for project approval and then control, but you’ll need to prepare other control documents too, such as a Risk Log and a Project Log.

The major planning documents

There are three major documents here, but the second one – the Project Management Plan – contains quite a few other plans.

As always, fit the documentation to the control needs of the document. There are no prizes for producing unnecessarily large documents – they merely drive up project overheads and waste everyone’s time in preparing and then reading them.

• Project Charter: The strategic view of the project. This will be maintained throughout. Amongst other things it contains the scope statement to say what the project is, the objectives and, importantly, the full Business Case.
• 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, activity and resource plans and also the budget.
  • Risk Plan: How you will control risk on the project, including reporting 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: If you have a significant amount of Stakeholder management to do, how you will do it.
  • Procurement Plan: If your project will involve a significant amount of procurement. This shows what will be bought and when, including lead times.

If you need to let a contract the lead time can be substantial, with Invitations to Tender and agreeing the contract. You may need to start the process several months before the actual purchase is due 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 logs

Logs are working documents to keep track of things such as risks. You may not need all of the ones in the checklist, but you’ll need most. 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 just over-formalised project bureaucracy. They are often logically 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 things such as how severe each risk is, what actions you have planned to control it, who is responsible for taking any action, when you last checked the risk. You get the point; you’ve just re-invented the Risk Log.

• Project Log: This functions as the Project Manager’s journal. It contains reminders, notes, records of important phone calls, lessons being learned from the project, and so on. It’s both simple and really useful.
• Risk Log: Another simple yet 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.
• Change Log: Not mentioned by many of the project approaches except the PRIME method, this log is powerful. If you keep a list of changes in this log you can quickly track which changes have been accepted, which have been rejected, who suggested them and, importantly, what they cost.
• Stakeholder Log: If you have a significant number of stakeholders in your project, you can keep a list in the log, perhaps grouped according to their interest. For example, operations staff, suppliers, other organisations that you work with and who will be affected.

Two checklists

You’ll use the two control checklists stage-by-stage, but you should decide the format during the Planning Stage.

• Quality Checklist: A list of tests and other quality activities being done in a stage. Each item is then ticked off when it is done. The checklist is a simple but powerful tool for making sure that a planned test hasn’t simply been overlooked.
• Work Checklist: A list of products to be developed in a stage, and then the date when each is delivered having been completed and successfully passing any tests. This is an extremely powerful progress checking tool.

Project Control

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

• Stage Progress Report: For the Project Manager to report progress to the Steering Group, possibly copied to others such as organisational managers and Project Managers of any interfacing projects.
• Team Progress Report: Where you have a project with multiple teams working, the Team Leaders will need to inform the Project Manager of progress on their current work assignments.
• 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, good and bad, that may be of value to future projects.
• Project Evaluation Report: Produced after the end of the project, this sets down information on benefits realisation (what the actual benefits were compared to what was expected when the project started) and the suitability of project deliverables after an initial period of use.
• Project Issue (or Project Memo): 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.
• Work Package: A work assignment given to a Team Leader by a Project Manager. It sets down what work is to be done and how. A project team will work through one or more Work Packages in a Delivery Stage.

Thinking About What You Need

Your 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 in control and other people need to check up on it too – they can’t check what isn’t there. Overall with documentation, follow the KISS principle of Keep It Simple, Stupid.

The control requirements may be dictated in part by your organisational standards. 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 one. You may need to get the Project Steering Group (PSG) on board to do that, but it’s not in the PSGs interest to incur unnecessary overheads and divert effort from getting the project delivered successfully.

In some cases, it’s not so much the organisational standards that are dictating the degree of documentation but a Project Management Office that is getting a bit carried away. 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 bureaucracy.