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

General

There are 2 types of product that need control.

The development of which are the subject of the plan

These are required as part of managing the product and for establishing and maintaining quality, for example, End Stage Reports.
Examples of these management products are seen in the file ‘management products.doc’ in the product package.

This technique covers the control of specialist products.

There are two key elements to remember:

• If a product is changed the Product Description should be checked for possible need to update it.
• Once a product is approved, the Project Manager should only authorise any work that would change it after seeking approval from the Project Board.

As usual, if the programme or organisation already has procedures and forms make sure that they are compatible with the approach below.

Change control steps

Changes are treated via a type of Project Issue.

These changes could be:

Request for Change

• A request to change what the project is set to deliver, for example, the specification of requirements.
• A suggestion to improve one or more of the project’s products.

Off-Specification

• A record of some current or forecast failure to meet a requirement.

The file ‘change control technique steps.doc’ contains a flow diagram of the necessary steps for recognising, recording and managing changes raised as a Project Issue.

Issue Log

Any issue will be raised as a Project Issue and given a unique number, the date received and the issue status.
This information is recorded in the Issue Log. A Product Description is given in the file ‘Issue log.doc’ in the product package.

Prioritise

All issues raised must be assessed for priority.

With the project in mind a system for prioritising changes could be:

Must

The final product cannot be produced or would fail without it.

Important

Not doing it would be inconvenient and a work around could be employed in the short term.

Nice-to-have

But not vital.

Cosmetic

Of no importance.

None

Does not involve any change.

The author of the issue will receive a copy of the Project Issue as acknowledgement of its entry into the Issue Log.

Simple issues, such as questions or misunderstandings should be answered immediately, giving a copy of the reply to the author, with the details and action recorded in the Issue Log.

Impact analysis

An impact analysis is carried out on the remaining issues.

The effect of the changes are assessed by considering:

• What exactly would require changing including those of linked products?
• What resource is required to make the change, for example, people and equipment?
• What will be the impact on the Team, Stage and Project Plans would be?
• Would the change create a deviation in project , stage or team tolerances?
• Is there any impact on the Business Case?
• Will any existing risks alter or would any new risks appear?

Following the impact analysis you should re-evaluate the priority.
This could be carried out by the Project Board or be delegated to a change authority who may make all decisions on Project Issues.

Authorisation

Change authority is covered in more detail elsewhere (see Change control).

Decisions on Requests for Change should only be made by either the Project Board or the delegated change authority.

For Off-Specification the Project Manager could try to solve the problem within the tolerance margins. This could mean extra activities form modifications to the plan(s).
Where the Off-Specification cannot be corrected within tolerance levels the Project Manager must follow the exception procedure, Escalating Project Issues (CS8) which will bring it to the attention of the Project Board in Giving Ad Hoc Direction (DP4).
If the Project Board accept the Off-Specification without any corrective action it is called a ‘concession’.

After impact analysis Project Issues are transferred to the Project Board or change authority.

Actions may be:

• Reject the project issue
• Put the issue in a pending status
• Remove the cause of the problem
• Ask for their implementation

Following this the Project Issue is returned to the Project Manager and the Issue Log is updated and an updated copy is sent to the author.

For any implemented Project Issue that may cause a deviation outside of stage or plan tolerances will be entered into an Exception Report.
This is covered in Escalating Project Issues (CS8).
The most likely result of this will cause the Project Manager to produce an Exception Plan detailing any necessary extra work.
This would be submitted via Producing an Exception Plan (SB6). Within this process the Project Board may be substituted by the change authority.

Impact analysis should consider the business, the user and supplier.
Make sure that all information is available before asking people to consider the impact.

Where a project is part of a programme you will need to consider where the decision base should be or to ensure that a programme representative is present on the change authority.