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

Fundamental principles

• A project is a finite process with a defined start and end.
• Everyone must be clear on what the project is intended to achieve, why it is needed, how the outcome is to be achieved and what their responsibilities are. This will generate a positive commitment to the project.
• Well managed projects have an increased chance of success.

Context

The process Initiating a Project (IP) is there to lay the foundations for the above principles.
It will follow Starting up a Project (SU).
It is triggered by Authorising Initiation (DP1), leads to 'Authorising a Project (DP2)' and invokes the Planning (PL) process to create the Project Plan and the Managing Stage Boundaries (SB) process to create the Stage Plan.

Initiation should always be the first stage in any PRINCE2® project.

Process description

The purpose of Initiating a Project is to draw up a ‘contract’ between the Project Board and the Project Manager.
The ‘contract’ is in the form of the Project Initiation Document.

There should be a common understanding of:

• The reason for doing the project
• What key products the project will deliver
• How and when these will be delivered and at what cost
• The scope of what is to be done
• Any constraints that apply to the product being delivered
• Any constraints that apply to the project
• Who is to be involved in the project decision making
• How the quality required will be achieved
• What risks are faced
• How the project is controlled
• Who needs project progress information, how and when
• The next commitment that the Project Manager needs (the next Stage Plan)

The Project Manager must always document the above understanding, no matter how small the project and no matter how informally this is carried out with the Project Board.

The document should be signed by the Project Board even this if this is only one person.

Formally the objectives of the Initiating a Project process are:

• Document and confirm that a suitable business case exists for the project
• Ensure you have a good and accepted foundation for the project, prior to the commencement of any work, via the Project Initiation Document
• Enable and encourage the Project Board to take ownership of the project
• Enable and encourage the Project Board to:

1. Make a decision on whether the project is viable
2. Agree to the commitment of resources to the next stage of the project

• Provide the benchmark for the decision-making process required during the project’s life
• Ensure that by carrying out initiation in an organised manner, the investment of time and effort required by the project is made wisely, taking account of the risks t the project

Scalability

The amount of work here may be reduced if the project is part of a programme.
It is possible that the Project Initiation Document may already be completed and only the Stage Plan and initial versions of the appropriate logs and files may need to be created.
However, the Project Manager still has the responsibility to make sure that the products provided by the programme are current and complete.

For small projects this process may be satisfied by documenting answers to the questions identified in the key criteria of Preparing the Project Brief, together with the Project Plan and the next Stage Plan (which may be the same plan for a small project).

It is possible that the Project Manager has agreed with the Project Board to combine the two processes of Starting up a Project (SU) and Initiating a Project (IP).
If this is the case, the sub-process of Authorising Initiation (DP1) may be replaced with an informal agreement between the Project Manager and the Project Board.

This process brings increased levels of information which may require repetition as feedback is sought from the Project Board.

If the project is well defined and planned at the start initiation can be very rapid.

The Communication Plan (as part of the Project Initiation Document) should clearly identify the reporting structure with any programme management.

Before presenting any Project Initiation Document to the board get feedback form any stakeholders that are not Project Board members.

Refer to previous Lessons Learned Reports for any guidance, advice and information.