Note:

PRINCE is a registered trademark owned by OGC (Office of Government Commerce).

PRINCE2 is an unregistered trademark owned by OGC (Office of Government Commerce).

Published here November 2002.

Introduction | Project Life Cycle | Management Levels | Authority Documentation
Special Project Management Roles | Document Description
Planning and Scheduling | Control | Summary | Endnotes

Authority Documentation

PRINCE2 tends to be heavy on documentation. A project has a set of progressive governing documents in its series of processes, a sequence that we had a little difficulty in following. The very first document is the "Project Mandate".[17] As PRINCE2 states, this document may come from anywhere, but should at least come from some level of management that can authorize the cost and resource usage[18] commensurate with the size and type of project. It must contain sufficient information to trigger the first "Starting up a Project" (SU) process and in that process is converted into a "project brief". The Guide recognizes neither business case nor project brief.

The SU process is intended to be of short duration and is designed to ensure that all the necessary players, and pieces, are in place prior to the real start of the project. It assumes that a provisional "Business Case" exists, although if it does not, it is created during the SU process. The business case justifies the undertaking of the project in terms of reasons, benefits, cost, time and risk and the source of this information is the project mandate or the project brief, the project plan and information from the customer.[19] The business case is a dynamic document that is updated throughout the project to reflect changing conditions, although it is "baselined" during the subsequent "Initiating a project" process.

The output of the SU process is an "Initiation Stage Plan" that ensures the required people are identified, and that the information they will need is contained in a project brief. The project brief is a relatively simple document providing background, project definition (i.e. what the project needs to achieve), the outline business case, the customer's quality expectations, acceptance criteria and any known risks.

This documentation feeds into the "Initiating a project" (IP) process, the output of which is a "Project Initiation Document" (PID).[20] Unlike the business case, which is updated, the PID is a substantial and stable document, except for the background attachments such as the business case. The PID is intended to define all of the questions what, why, who, when, and the how of the project. It is the base document against which the project board will assess progress, the change management issues, and the ongoing viability of the project.[21] Concurrently with the preparation of the PID, the first project stage is planned leading to the authorization by the project board of the project's first stage.

The Guide's equivalent of the PID is the "Project Charter" which is an output from the Initiation process under the knowledge area of Project Scope Management. The Guide defines project charter as "A document issued by senior management that formally authorizes the existence of a project. And it provides the project manager with the authority to apply organizational resources to project activities."[22]

Management Levels and Responsibilities  Management Levels and Responsibilities

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page