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

Examining Project Issues (CS4)

Fundamental principles

Each Project Issue should be considered for its impact and alternative actions considered. Only then make a decision on which action is best.

Context

The sub-process Capturing Project Issues (CS3) captures all of the Project Issues that have not been resolved.
During the sub-process Reviewing Stage Status (CS5) they should be reviewed and appropriate actions recommended for consideration.

Process description

An initial examination of a Project Issue should be performed as soon as it is logged.

All open Project Issues should be reviewed on a regular basis.

The Project Issues should reviewed against:

• The stage status
• Product delivery
• The progress against plan

When this is done a decision can be made as to the appropriate action.
This would not be appropriate if the Project Issue raises and urgent matter needing immediate action.

This sub-process must also consider the wider impact of any Project Issues outside the project.
Should an issue be transferred elsewhere the Issue Log should record it as ‘closed’ with an appropriate note attached.
This may arise if the Project Issue is moved upwards to a programme for consideration.

To prepare Project Issues for the sub-process Reviewing Stage Status (CS5) the following steps are needed:

• Assemble all available and relevant information about the Project Issue, including anything that pertains to the Project Issue’s effect on:

1. Costs
2. Timescales
3. Benefit achievement and / or value
4. Risks
5. Meeting the requirements of the project
6. Meeting the stated quality standards

• Devise alternative courses of action
• Update the Risk Log if the Project Issue relates to a previously identified risk or reveals a new risk
• Revise, if necessary, the priority of the Project Issue
• Recommend a course of action. A single recommendation may address a number of Project Issues

Responsibilities

The Project Manager is responsible for this sub-process.

Members of the teams may be required to assess the impact of Project Issues on products, workload, cost, schedule and risk, and devise alternative courses of action.

Some of the administrative work may be delegated to a Project Support role.

Those with a Project Assurance responsibilities should be involved in the examination of the impact of Project Issues on the products, risk and the Business Case.

The Configuration Librarian, where appointed, will be responsible for maintaining the Issue Log.

Who makes decisions on the actions to be taken about the Project Issues depends on decisions made during the 'Initiating a Project (IP)'.

The Project Manager will have discussed the likely volume of changes with the Project Board.
They will have decided whether to make decisions themselves or delegate this to a change authority.

See Authority Levels in Change Control.

These are given in tabular form in the file ‘CS4 examining project issues.doc’ in the product package.

Key criteria

• Who would be best to evaluate the Project Issue?
• How urgent is the decision?
• Is it clear when a decision has to be taken?
• Is any special action needed to assure the customer’s best interests during the evaluation?
• Was time and effort for Project Issue evaluation put in the Stage Plan?
• How do any relevant contracts handle changes?
• Is there a separate change budget?
• What products would the Project Issue affect?
• Who would be involved in taking any action?
• What alternative courses of action are there?
• What would the solution to the Project Issue cost in effort and money?
• What is the impact of the Project Issue on the Business Case?
• Would implementation change the current project objectives, as specified in the Project Initiation Document?
• What would the impact of the Project Issue be on anything in the Risk Log?

Time should be built into the Project Plan for experts to carry out the necessary impact analysis as soon as a Project Issue materialises.

Review of open Project Issues should occur regularly and frequently.

This sub-process and Reviewing Stage Status doesn’t have to be formally separated in small to medium sized projects, but information gathering / talking to the originator might be hard to do during a stage status review.

Urgent and important are not the same thing. Deal with urgent immediately and with important comprehensively.

Focus on the important Project Issues by filtering out the trivial items.

Give feedback to the Project Issue authors on any actions that arise.