Prince2 header
products page

PRINCE2 - Controlling a Stage (CS) part 5



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.

Information needs
Management information Usage Explanation
Business Case Input Reference back to the Business Case to evaluate the impact of the Project Issue.
Stage Plan Input One of the bases for impact analysis.
Project Plan Input To check whether a Project Issue affects the project.
Issue Log Update A list of all outstanding Project Issues and their status, updated with impact analysis information.
Risk Log Update Current risks that may be affected by a Project Issue. To be updated if any action is recommended that will affect a risk or generate a new one.

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.

Non - PRINCE2 information

This product contains EVERYTHING in the publications:

Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.

And much more besides - at a fantastic price.