Introduction

• Defintion
• Structure and terminology
• What is a project?

Processes

• The processes
• Management levels
• Starting up a project SU
  • Fundamental principles
  • Appointing an Executive and Project Manager (SU1)
  • Designing a Project Management Team (SU1)
  • Appointing a Project Management Team (SU3)
  • Preparing a Project Brief (SU4)
  • Defining Project Approach (SU5)
  • Planning an Initiation Stage (SU6)
• Initiating a project IP
  • Fundamental principles
  • Planning Quality (IP1)
  • Planning a Project (IP2)
  • Refining a Business Case and Risks (IP3)
  • Setting up Project Controls (IP4)
  • Setting up Project Files (IP5)
  • Assembling a Project Initiation Document (IP6)
• Directing a project DP
  • Fundamental principles
  • Authorising Initiation (DP1)
  • Authorising a Project (DP2)
  • Authorising a Stage or Exception Plan (DP3)
  • Giving Ad Hoc Direction (DP4)
  • Confirming Project Closure (DP5)
• Controlling a stage CS
  • Fundamental principles
  • Authorising Work Package (CS1)
  • Assessing Progress (CS2)
  • Capturing Project Issues (CS3)
  • Examining Project Issues (CS4)
  • Reviewing Stage Status (CS5)
  • Reporting Highlights (CS6)
  • Taking Corrective Action (CS7)
  • Escalating Project Issues (CS8)
  • Receiving Completed Work Package (CS9)
• Managing product delivery MP
  • Fundamental principles
  • Accepting a Work Package (MP1)
  • Executing a Work Package (MP2)
  • Delivering a Work Package (MP3)
• Managing stage boundaries SB
  • Fundamental principles
  • Planning a Stage (SB1)
  • Updating a Project Plan (SB2)
  • Updating a Project Business Case (SB3)
  • Updating the Risk Log (SB4)
  • Reporting Stage End (SB5)
  • Producing an Exception Plan (SB6)
• Closing a project CP
  • Fundamental principles
  • Decommissioning a Project (CP1)
  • Identifying Follow-on Actions (CP2)
  • Evaluating a Project (CP3)
• Planning PL
  • Fundamental principles
  • Designing a Plan (PL1)
  • Defining and Analysing Products (PL2)
  • Identifying Activities and Dependencies (PL3)
  • Estimating (PL4)
  • Scheduling (PL5)
  • Analysing Risks (PL6)
  • Completing a Plan (PL7)

Components

• The components
• Business case
  • What is it?
  • Developing
• Organisation
  • Overview
  • The customer / supplier environment
  • Project Manager
• Plans
  • Benefits
  • Levels of plan
• Controls
  • Purpose
  • Project start-up
  • Tolerance
  • Product Descriptions
  • Exception Report
  • Controlled close
• Management of risk
  • What is it?
  • Risk analysis
  • Risk profile
  • Mapping the management of risk to the PRINCE2® processes
  • Interdependencies
• Quality in a project environment
  • What is quality?
• Configuration management
  • Purpose
  • Configuration control
• Change control
  • Purpose

Techniques

• General
• Product-based planning
  • General
  • Producing a Product Breakdown Structure
  • Writing a Product Description
  • Creating a Product Flow Diagram
• Change control
  • General
• Quality reviews
  • What is it?
  • Steps in a formal quality review procedure

Other

• Risk categories
• Health check
  • Health check – part 1
  • Health check – part 2

Authorising a Project (DP2)

Fundamental principles

No project should commit to significant expenditure without:

• Management approval that an acceptable Business Case exists for the project
• Checking that it fits with any relevant corporate or programme strategy
• Assessment and acceptance of the risks involved
• An estimate of the and cost involved
• Checking that the project will be appropriately controlled

A benchmark may be established against which the project can be judged and a baseline should be set to control change.

Context

The sub-process includes approval of the Stage Plan for the stage to follow initiation.
The approved Project Initiation Document triggers the start of the next stage of the project and forms the baseline for the rest of the project.

Process description

The objective of this sub-process is to decide whether to proceed with the project.

This is based on the approval or rejection of the Project Initiation Document.
It contains all the important information about the project.
Once accepted it is baselined to preserve the project’s original intentions.
This can be used in later reviews to assess the project’s success.

At other points in the project parts of the Project Initiation Document will be updated.
This will make sure that the Project Board always have the most up to date information on which to base any decisions.
This should not be confused with the original baselined document.

If the fixed parts of the Project Initiation Document should change, for example, the project definition consideration should be given to closing the current project and starting with a Project Initiation Document.

A full Product Description for the Project Initiation Document can be found in file ‘Project initiation document.doc’ in the product package.

It should contain the following items:

• Background

Provides the main events that led to the need for the project.

• Project definition

The Project Board must be happy that the project objectives are still achievable.
The remainder of this section will be a refinement of the Project Brief and Project Approach

• Business Case

The Project Board must confirm that an adequate and suitable Business Case exists for the project and that it shows a viable project.
Information on the expected benefits and savings should be supplied and approved by the customer.
The projects costs will derive from the Project Plan provided by the Project Manager.

• Project Quality Plan

This must state how the project intends to meet the customer’s quality expectations and where quality responsibilities have been allocated.
The Project Board should satisfy itself that the expectations have been correctly translated from the Project Brief and that the Quality Plan will deliver them.

• Risk Log

Potential risks affecting the project’s products should be identified by the project management team.
See 'Management of Risk'. The Project Board must ensure that all risks are properly assessed.
If appropriate, suitable countermeasures and contingency plans should be put in place.

• Project Approach

This will show what method will be used to provide a solution to the project’s objectives.
This is discussed more full in the sub-process Defining Project Approach (SU5).

• Project Plan

This gives an overview of the timescales, costs and the major products.
When previous worked has been carried out, for example, a feasibility study, a previous plan might well exist.
If this varies widely from current forecasts the project should be examined carefully for the reasons.
The Project Board should them assure itself that the plan and the project are still viable.

The Project plan must be aligned with any existing strategic and programme management plans.

• Project organisation

Most of the project management team will have been appointed during the process Starting up a Project (SU). These will now require formal confirmation and any late appointments negotiated. Each member of the team should have agreed their role, as described in Organisation which is one of the items that must be confirmed by the Project Board.

• Controls

The Project Initiation Document will include details of the controls that will allow the Project Board to maintain overall control.
This includes step-by-step approval for the project to proceed at the end stage assessments, confirmation of the tolerance level for the project and the stage after initiation, and details of what will happen if any stage exceeds its agreed tolerance.

Information should include the frequency and content of reports from the Project Manager to the Project Board. It will include details of how the Project Manager would manage the project on a day-to-day basis.

The Project Board must assure themselves that all controls are adequate for the nature of the project.

• Communication Plan

This should reflect the needs and timing of communications (in both directions) between the Project Manager, the Project Board any other interested parties.
The plan will contain details of any required co-operation from outside of the project.
It will include any links to corporate or programme management as part of the sub-process.

Responsibilities

The Project Board is responsible for this sub-process with input from the Project Manager.

These are given in tabular form in the file ‘DP2 authorising a project.doc’ in the product package.

Key criteria

• Does the project support corporate strategy and programmes?
• Is the Business Case acceptable?
• Are the risks manageable and acceptable?
• Can the Project Manager show that the Project Plan is achievable?
• Is there confidence that the required resources can be made available over the life of the project?
• Are the differing objectives of all parties clear at the point of initiation?
• Do the defined controls ensure that the differing objectives of all parties will be met at each point in the project?
• What happens if one party’s decision criteria require cancellation, while others propose continuation?
• Can contract termination criteria, terms and conditions be agreed to account for this, or should normal contract discharge conditions apply?
• Has PRINCE2® been adapted correctly to account for customer or supplier organisational or control models?
• Do the relevant risks and assumptions clearly identify the impacts on customer and supplier?
• Can or should the supplier have sufficient control over the customer’s organisation to be required to bear any of the business risks?
• For each risk and assumption, are each respective customer’s management, monitoring and containment responsibilities defined?
• Where a supply-side risk impacts on the customer’s Business Case, is it clear whether the supplier or the customer will mange it?
• If the project is based on staged payments, has an appropriately detailed level of identification of product or outcome delivery been identified?
• Do the Acceptance Criteria reflect the staged payments approach?
• If funding for the project is variable, has adequate consideration been given to how the supplier will ensure that the contracted scope is fully funded?

The Project Initiation Document requires time to study it fully so that the Project Board can better make decisions perhaps discussing any points with the Project Manager and others. There should be few, if any, surprises if the Project Board and the Project Manager have been working closely together.

The project organisation structure must allow for communication to decision-making forums that already exist within the customer and supplier organisation as well as to temporary ones established to ensure effective management of the project itself.
This will normally be a Project Board responsibility. The potential delegation of Project Assurance responsibilities can be used to help achieve the required communication.

For fixed-funding projects it must still be practical for the customer to pay for any cost increases caused by scope variations requested by the customer.

When the supplier funds the project there may be implications for the organisation and control of the project.
This should be carefully described in the job descriptions of the Executive and Senior Supplier.

The Business Cases for the customer and supplier may be quite different, making decision making less easy.
An understanding of these differences may assist in assuring compatible behaviour.

When the project subject to tight timelines it may be appropriate to review the PRINCE2 controls and their frequency.

The next Stage Plan must be approved at the same time as the Project Initiation Document.

When project funding is variable the stage approval should include assurance that the required funds are set aside.
The choice and timing of stages may reflect any need to confirm continued funding.