Prince2 header
products page

PRINCE2 - Controlling a Stage (CS) part 9



Escalating Project Issues (CS8)

Fundamental principles

A stage should not exceed the tolerances agreed by the Project Board.

The Project Manager should always present a recommendation when escalating Project Issues.

Context

This sub-process can be an advanced warning to the Project Board of a deviation that may lead to the need for an Exception Plan.
The Project Manager can only take corrective action or maintain the status quo while the stage is forecast to stay within the tolerances set by the Project Board.

Escalating Project Issues(CS8) applies where any corrective action would not save the stage or project from going beyond the tolerance margins.

The decision by the Project Board in response to the escalation may lead to the removal of the problem, the production of an Exception Plan, where cost and / or time targets are adjusted, the approval of a concession or the premature close of the project.

Process description

The Project Board controls each stage by setting tolerances (see Controls).

The Project Manager only has authority to proceed with a stage provided it is forecast to stay within the tolerance margins.
If the stage is forecast to go outside the tolerance margins (possibly from the result of a corrective action) the Project Manager must inform the Project Board of the situation

A Project Issue may well cause a deviation.
This could apply to more than one Project Issue which might take the stage or the entire project beyond agreed tolerances.
These are fully described under Change Control.

Other causes of deviations may be:

  • Poor estimation
  • A change in resource availability
  • Resources under or over performing
  • Unplanned tasks
  • Tasks not needed
  • Rework

The Project Board must make the decision on which (if any) changes to approve for action.

In order to retain the Project Board’s overall control the following steps are taken:

  • Assemble the results of the full impact analysis of the deviation; the analysis should cover specialist, user and business impacts.
  • This is completed in the sub-process Examining Project Issues (CS4).
  • Assemble and evaluate options for recovery (or to take advantage of good news) (Again, completed in the sub-process Examining Project Issues (CS4)).
  • Make a recommendation
  • Put the situation, options and recommendations to the Project Board in an Exception Report
  • The Project Board indicates support or otherwise for the Project Manager’s recommendation
  • In the sub-process Giving Ad Hoc Direction (DP4)
  • Updated the information in the Configuration Item Records for any affected products.

The Product Description for an Exception Report is given in file ‘Exception report.doc’ in the product package.

Through this the Project Manager will advise the Project Board of the impact of the deviation on the Project Plan, Business Case and risks.
Various options should be identified and a course of action recommended to the Project Board.

After the Exception Report is considered by the Project Board (in sub-process Giving Ad Hoc Direction (DP4)), the Project Board will approve the report and advise the Project Manager of its decision. This may take the form of a request for an Exception Plan to replace the plan that is in exception(usually the remainder of the current Stage Plan), produced in Producing an Exception Plan (SB6).

The Exception Plan either recovers a situation that is outside tolerance or proposes a new plan with new targets for cost, time, scope, benefit, risk and quality as appropriate, plus new tolerances around these targets.

The Project Board’s advice should be sought before devising the Exception Plan.
All current constraints should be investigated with the Project Board to see if they still stand in the light of the new situation.

Another option that may be taken ins response to an Exception Report is to remove the problem (for example, defer the Request for Change).

Alternatively, the Project Board may decide to grant a concession and continue with the current plan, in which case the appropriate corrective action should be triggered via Reviewing Stage Status (CS5).

A final and more drastic decision would be to take the project to premature close, in which case the Project Manager will instigate Decommissioning a Project (CP1).

Parts of a plan that can be varied in response to an exception are:

  • Cost
  • Delivery date
  • Scope
  • Quality
  • Benefits
  • Risk appetite

Speed is an important factor in notifying the Project Board of an exception situation.

It will often be necessary to revise the Project Plan, as described in Updating a Project Plan (SB2).

Responsibilities

The Project Manager is responsible for escalating Project Issues.

Those with Project Assurance responsibilities should also be monitoring any situations that could cause a deviation and should bring the matter to the Project Manager’s attention.

The Configuration Librarian will update Configuration Item Records as required.

Information needs
Management information Usage Explanation
Tolerance threat Input Trigger for the Exception Report
Project Initiation Document Input This baseline allows comparison of any change against original expectations.
Business Case Input The latest version allows examination for impact of the Project Issue on the Business Case.
Stage Plan Input Updated with the actuals so far, this shows the likely impact on the stage of the deviation in question.
Project Plan Input This indicates the project status and the overall effect of any deviation.
Issue Log Input / Update Details of the change(s) that may have caused the exception situation. Update the Issue Log with the current status when the Project Board’s decision has been received.
Risk Log Input Details of the risk exposure that may have caused the escalation.
Exception Report Output / Input Description of the exception situation, its impact, options, recommendation and impact of the recommendation for the Project Board. Subsequent Project Board Approval of the Exception Report, which should be filed for audit purposes.
Project Board decision Input May be a request for an Exception Plan, cause a premature close of the project, result in deferring the change, or cause a concession to be granted, depending on the decision.
Trigger for premature closure Output As a result of the Project Board’s decision to close the project prematurely.
Exception Plan request Output As a result of the Project Board’s to request an Exception Plan.
Concession Output As a result of the Project Board’s decision to grant a concession.
Configuration Item Record Update Fields such as status may be updated, plus the addition of links to the relevant

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

Key criteria

  • Is the Project Issue within the remit of the project? If not, has guidance been given on how to progress it?
  • Is the stage forecast to go outside its tolerance margins?
  • Is there anything within the Project Manager’s remit that would bring the stage back within its tolerances without reducing quality or project scope?
  • Have all sensible alternatives been considered?
  • Is there a recommended course of action fro the Project Board to consider?
  • Has the impact on the Project Plan been calculated?

When a Project Issue is approved and there is work to be done in the current stage this may be the factor that drives the stage outside tolerances. The Project Board must be made aware of this possibility when considering the Project Issue request.

Such potential deviations should be forecast as far in advance as possible without being alarmist.
The Project Manager is expected to contain the situation.

Previous Highlight Reports must have set given indication that the stage might exceed its tolerances.

The Project Board could stop the project in response to an exception situation.

One cause of an exception is a supplier going out of business.

There must be an impact analysis carried out on the options that might counteract any forecast future deviation from tolerance.
This should include seeking the input from users where the impact of the deviation and could affect them.
Similarly, seek input from specialists concerning deviations.

The business impact should cover the Project Plan, Business Case and risks.

The Project Board may decide to accept an Off-Specification without corrective action, turning the Off-Specification into a concession.

Whilst the Project Board consider any Exception Report the management of the stage may still continue.
In this case, the Project Manager must decide if there are any activities that can proceed that are independent of any decision of the Project Board.
Should some or all work be stopped?

The Project Board should be notified as soon as possible of any forecast deviation.

This can be done in 3 steps:

  1. A brief statement
  2. Followed by support information
  3. Followed by exception planning

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.