Manage by Exception Prince2ce2®
Manage by Exception – Involve next Level of Management only when it is required
One of the PRINCE2® methodology principles is Manage by Exception. Tolerances are set at each appropriate level, for example project, stage, or work package levels. In PRINCE2®, it is assumed that the people on the Project Board are senior individuals comprising of the performing organization, user community and the suppliers who have little time to spend on the day to day management of the project. The day to day management is the responsibility of the project manager. The Project Board therefore delegates day to day management for a stage to the project manager within agreed ‘tolerance’ levels for the objectives of time, cost, risk, quality, benefits and scope. The project manager should be confident that s/he can deliver the stage plan within these agreed tolerances then s/he can take corrective action to get things back on track if things are running late of going over budget. If however, the project manager cannot deliver the stage plan within these agreed stage tolerances then this is known as an ‘exception’ in PRINCE2® and this must be escalated to the next management level; the Project Board, for a decision. This therefore, is a very efficient use of senior management time and means that the project Board are only involved in taking decisions as and when the need arises. It is important to note that they are of still involved in taking the key ‘Go/No go’ decisions at the end of each stage.
An exception report is created whenever a stage plan or project plan is forecast to exceed the relevant tolerance bounds. At the first instance of forecasting that a tolerance is to be exceeded, the project manager will log it as an issue in the issue register. The next step is to create the exception plan (if the Project Board requests after reviewing the Exception report) which is created by the project manager in order to advise the project board that tolerance is forecast to be exceeded as well as to present a range of options and recommendations outlining the actions to take in order to resolve the situation. Based on the information provided within the exception report, the project board may choose to:
•?Approve or reject the situation •?Defer making a decision until later
•?Request more information
•?Brought a concession for the project manager to proceed without the need for any corrective action
•?Instruct the project manager to resolve the problem
•?Give advice and guidance to the project manager
•?Request an exception plan based on one of the options (theirs or the project manager’s)
•?Seek advice and guidance from corporate or programme management
•?Instruct that the project be prematurely closed
The format of an exception report can be in the form of a document, an email, other form of electronic communication, or it may be given verbally.
Typical contents of an exception report
This should describe and present an overview of the exception situation that is being reported
Cause of the exception:
This describes the root cause of the deviation that led to this exception and deviation from the current plan. The reasons for the forecast deviation must be clearly stated and analyzed. The project manager will want to inspect the issue register and its impact analysis to help determine the cause. Also, the project manager should get advice for all appropriate stakeholders such as the specialist team, the team manager, and the individual or group who raised or caused the issue in the first place.
Consequences of the deviation
Before any action or recommendations can be made, it must be first understood exactly what the implications for both the project and corporate or programme management are so that informed choices can be made. Such impacts must be determined from the business, customer, user, and supplier perspectives. Of particular importance are the implications for the business case, and these must be taken into consideration. Also be impact on the overall project plan must have been calculated. A useful checklist when determining such impacts is to consider the six variables that would be involved in any project such as:
Usual documentation to act as references to determine the impact are the following:
•?The issue register
•?Project initiation documentation
The project manager will almost certainly want to involve the specialist team in helping to describe such impacts as well as to consider options for recovery or minimization. Other useful stakeholders could be the users, customers, or appropriate operational managers.
This lays down the options that are available to resolve the deviation and for each option what the effect would be on the business case, risks and tolerances. Wherever possible, several options for recovery should be given as this will give the project board confidence that sufficient thought has gone into considering all possibilities. Each option must include the risks for such an option as this will assist in making a recommendation based on the project boards risk appetite (level of risk an or an organization is willing to accept or have already accepted). There is a temptation for the project manager to start creating detailed plans around some or all of the options, but this should be resisted as the project board may decide all different actions or consider options of their own. In such a case the effort involved in creating plans will have been wasted. If time is of the essence, the project manager may wish to advise the board verbally that an exception report is being created and advising them of the options currently being considered within the report. They may be able to shed some light on their favored approach or even instruct the project manager to plan a chosen option in more detail.
This is the project managers recommended option, and it is important to include the reasons why the other options were not considered, and why this option is the chosen one. Remember, the project board may choose not to take this recommendation, so a project manager would be wise to articulate clearly why this recommendation is being made. An important source of information for the project manager in both considering options and the recommendation is the project initiation documentation. The project plan and the various strategy documents will be helpful here. Of particular assistance is the project product description containing the acceptance criteria and project objectives. The current stage plan will also be used as a source of reference. The project manager is advised to have discussions with any or all appropriate stakeholders such as the senior user, senior supplier, and project board executive, departmental or operational managers such as those responsible for finance, procurement, legal, end-product operators etc.
This should capture any lessons that can be learned from this exception situation and consideration made whether such lessons can be applied for the remainder of this project and/or future projects. All such lessons should be added to the lessons log. If the project board request that an exception plan is created by the project manager to be reviewed at an exception assessment, then the end stage report will include such lessons.
It is worth mentioning that the exception situation may have been caused by an external event that affects the project, indeed, it may be the project board that brought this to the attention of the project manager. Other sources of information other than those mentioned above are the quality register, the checkpoint reports, or highlight reports.