Skip to content

good practice and innovation
about us infoKits Tools & Techniques Publications Events
You are here: Home » infoKits » Programme Management » Managing By Exception

p3m What is P3M? Programme Management Banner

Managing By Exception

MSP

In MSP methodology this is covered by (chapters given in brackets):

  • Risk Management and Issue Resolution (11)
  • Managing the Tranches (16)
  • Delivering the Capability (17)
  • OGC MSP website

Manage by exception is the advice we give to both Project Managers and to senior managers in relation to their overall portfolio. Unsurprisingly then the advice to Programme Managers is similar. In short it means giving your team of managers sufficient flexibility to be able to manage their own projects effectively and only intervening when it is strictly necessary.

This can take the form of reporting by exception i.e. identifying variances against the plan and meeting with the Programme Board in line with key decision points rather than reporting on every detail of a project and meeting as a matter of routine. One means of helping you to do this is to identify tolerance limits for individual projects.

Tolerance Limits

The concept of tolerance recognises that there is an element of uncertainty in every project.

A long project may well have a deadline of 2 August in two years time and have a set, agreed, budget of £2M, but expecting the project to come in on the dot - neither late nor early - and to have spent the determined budget to the penny is totally unrealistic. As is the concept of agreeing the exact end date and budget spend for each stage or phase.

If a Project Manager has been given a non-flexible fixed amount of time and budget, that is almost certainly not going to be achievable. Their only course of action, once it can be forecast that the project will not hit the stated time/cost, is to raise an issue and ask senior management for a decision on whether to continue or not.

Senior management will now perceive they are being drawn into the minutiae of the project and will either feel annoyed and give time grudgingly, perhaps not considering the necessary decision as important because it happens at every stage, or they will enjoy and desire the involvement and will start to micro-manage the project, undermining the project manager until the project reaches a stage where senior management involvement is necessary 100% of the time because no one will take the Project Manager's word.

The answer is to allow the Project Manager the ability to take decisions without senior management involvement providing that the resulting changes to the plan do not cause the forecast budget or timescale to move outside an agreed tolerance, either at the end of the current stage, or by the end of the project.

So, instead of specifying an end-stage position of '8 November YYYY' and expenditure to date of £105,000, you agree with the Project Manager, as part of the authorisation process for the stage, that it will end within a range of dates and within a range of expenditure. This range could simply take the ideal and then do a plus or minus calculation, or more likely will do something like a plus or minus % with a corresponding date range of, say, 6-9 November YYYY.

Tolerances in Action

Office of Government Commerce

Within the PRINCE2 methodology, you can find equivalent processes in:

During the course of a project, a Project Manager will often hand out responsibility for a work package to another manager. The Project Manager should also be able to agree acceptable tolerances with the manager of the work package.

The tolerance limits should be appropriate to the scale and complexity of the project. They should not however be a 'slush fund' to compensate for sloppy management. Key to setting appropriate limits is your risk assessment and management plan. This should have enabled you to gain an understanding of the overall level of uncertainty in your projects and to plan for this. In the section of the Risk Management infoKit on Costing Risk we look at how to set aside a budget for particular risks and to set an appropriate contingency against a range of minor risks. This type of planning is most effectively done against a programme of projects to avoid having too many small contingency pots.

Escalating Issues

Office of Government Commerce

Within the PRINCE2 methodology, you can find equivalent processes in:

  • Capturing Project Issues (CS3)
  • Examining Project Issues (CS4)
  • Reviewing Stage Status (CS5)
  • Taking Corrective Action (CS7)
  • Escalating Project Issues (CS8)
  • Giving Ad Hoc Direction (DP4)
  • OGC PRINCE2 website

Issue management is of course the stock in trade of project managers but there may be times when resolution is beyond their control and they need to escalate up to Programme level. N.B. If the project is not part of a programme then escalation would be to the Project Board or Sponsor.

Where the resolution of an issue can be undertaken without taking the current project stage outside its agreed tolerance limits, the Project Manager can take action without having to involve senior management.

The decision as to whether it will take the project beyond its agreed tolerance requires some evaluation of the cost and time that it will take to deal with the issue, whether the issue can be dealt with concurrently with other project work, or whether it would introduce delay.

Even where the resolution can be carried out within tolerance, the Project Manager may refer to senior management for advice, particularly if the issue or the means of its resolution may affect other projects in a programme. Where delays or costs caused by an issue cause the forecast stage or project end-point to be outside agreed tolerances the issue must be escalated to senior management for a decision.

This is done by means of an Exception Report:

Contents Description
Description of Issue The cause, the nature, whether it has arisen from a known risk.
Consequences Cost, timescale, effect on scope or quality. These should be both in terms of the current stage and the entire project.
Options A list of alternative solutions including cost, timescales and effect on quality.
Option Consequences Evaluations of possible alternative solutions on the Business Case, tolerances, whether any new risks can be identified.
Recommendations The project manager's recommendations.

The function of the Project or Programme Board/SRO is to ensure that any recommended option continues to focus on the business objectives and to consider the impact of the issue on the Business Case and future risks.

The Board or SRO at this point may decide to:

  • ask the project manager to produce an Exception Plan - a new version of the stage and/or project plan for the remainder of the stage/project reflecting the current situation

  • reduce the scope/quality of the stage and/or project to bring it back within tolerance

  • bring the project to an early close

The Board also has the responsibility to secure any increased or extra resources needed to implement whatever decision is made.


Bookmark and Share
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)