Introduction

The Importance of Documents

Until a project produces some tangible deliverables, the only items produced are the documents. In fact, documents are considered some the major milestones of the Initiation and Planning phases. They drive the project, organize it, standardize it, and provide communication not only among the stakeholders but within the project team. If one member of the team leaves, the replacement should be able to take over strictly by reading the documents. If the team in one phase is not the same as that in another, documents are the main form of information exchange. Imagine what happens if the planning team does not produce a proper Project Plan. Can anyone continue working on the project without a clear idea of what is to be produced, for whom, and by what date? Some of you may be saying "I've been there!" but it is better to write it down.

In a time crunch, the first item to be dropped is the production of the documents, but a wise project manager knows that the documents are the first items to produce. Without them, the project flounders, wrong things are built, no one is aware of progress, and the project dies.

Standards

In a large organization in which many projects are produced, one of the most efficient project management methods is to have all the documents with a similar look and feel. You can accomplish this by using the outlines and templates provided in this book. Most important, having standard documents will introduce standard terminology, which will improve communication among project stakeholders immensely.

The Documentation Plan

Why Have a Plan?

Although this book is not intended to teach project management, the basic tenet of project management is to plan things. Since documentation will be the only deliverable for the first part of the project-and in fact sometimes the only tangible deliverable (in the case of a software project, for example)-it has to be done right. This book will help you plan.

Size and Time

Make your documents as concise as possible. It is very important to keep the project's size in mind when you decide what to report. For example, even for very large projects, clients will not pore through hundreds of pages of minutiae to determine the status of their project. It therefore is best to group comments into shorter statements based on activity or outcome, with supporting documentation provided in appendixes for lower-level managers to review. You can write only five to ten pages a day, so use your time efficiently.

Who Is the Document Intended for?

There are always obvious and less obvious readers for each document. For example, the Project Concept is intended for the financial decision makers, and the Project Plan for the project approvers and workers. However, documents are public: You do not know who may be reading them. I always recommend writing for the lowest common denominator. This can be a high-level manager who is unfamiliar with project management and its terminology. However, the project may depend on the approval of this manager, so write the document to ensure that he or she understands it.

Language

Keep the language simple; include only the essential information. There is no need to impress anyone with large, complex words and sentences. KISS (Keep It Simple, Stupid) applies here as it does in any other writing.

The Case Study Project

The documents in this book are based on an actual project: the construction of a water theme amusement park in Ottawa, Canada. Although true to the theme, the actual problems, issues, and concerns raised in the example documentation are fictitious. However, they illustrate typical problems that can arise during any project.

The Order and Necessity of the Documents

Table 1 lists all the documents detailed in this book. The table is divided horizontally for two types of projects: internal and external. An internal project is one produced by one section of a company for another section. There is no formal contract between the developers and the client. An external project is one contracted with an external developing organization and involves a formal procurement process and contracting.

Table 1: Documents Produced by Phase of the Project

Not all of the documents in this book are produced for every project. Let us detail the circumstances under which each one would be produced (see Table 1).

Project Concept

This document must be produced for every project. It is not a large effort (two or three pages), outlining the basic ideas, problems to be solved, strategy, and solution, plus a ballpark cost and time estimate. The estimates in this document may be +75% to -25%* in error.

The Business Case

This document must be produced for every project. It is used to ensure that the development effort is cost-effective; the project must eventually pay for itself.

Requirements (Internal Projects) or Request for Proposal (RFP) (External Projects)

The requirements document details the client's business problems that will be solved by an internal group. It states the maximum budget allotted, the required time frame, and possibly a suggested solution. Depending on the knowledge the client has of the project requirements and the skill of the person writing it, this document may be as short as a few pages, giving only rudimentary requirements, or as long and as detailed as the Preliminary Plan.

The RFP accomplishes the same purpose for external projects. This is the document published to the external world, soliciting the interest of contractors to bid. Some items that may appear only in the RFP are a request for data on the contractor (such as experience and references) and the more formal terms and conditions of the solicitation.

Preliminary Plan

This is the first, high-level plan of the scope, time, cost, communication, risk, quality, procurement, and human resources required. For an external project, this is the basis of the proposal; for an internal one, it is the basis of the Project Charter. The estimates in this plan may be +25% to - 15%* in error.

The Proposal (External Projects) and the Charter (Internal Projects)

For the external and internal worlds, this is the formal statement of the developers to the client about the exact deliverables, cost, schedule, method of delivery, acceptance, commitment, and so forth. In a competitive environment, the Proposal is also a sales tool, emphasizing the virtues of the vendor. Obviously, the external Proposal leads to a more formal contract than the internal Charter; however, a formal commitment should be made in both cases.

Contract

For larger external projects, a contract may be needed for legal purposes. For small projects, a signature on the proposal may suffice.

Final Plan

It may take several weeks or possibly months to go through the contracting process, and more information about the project will then be available. In addition, the estimates in the preliminary plan might have been very inaccurate. The preliminary plan therefore is revised, more detail is filled in, and the estimates are redone to generate the final plan.

Communication, Risk Management, and Quality Plans

The ways these items will be managed must be addressed for all projects. Depending on the size and scope of the project, these may be separate plans or sections in the final plan. Examples of stand-alone plans are discussed in the book.

Meeting Minutes

Two meetings are discussed: the team status meeting and the Project Managers meeting. The former is informal, and minutes may not be taken. The book shows a "record of discussion" with a list of action items. The Project Managers meeting occurs in most organizations in which a committee of managers oversees the progress of several projects. Formal minutes should be taken, and this is shown in the book.

Status Reports

When the project execution phase starts, progress status must be reported to all the stakeholders at a set frequency. A simple status report is shown in the book.

Risk and Quality Control...