PRINCE2 Stage Correction

When an issue needs stage correction

If the stage is going off track, then the project manager needs to react with actions that bring it back on track.

The project manager will first learn of such a deviation from the plan when checking the status of the stage. It is important to check with regard to issues, where you are in order to see if you have the capacity to absorb the issue impact of any action, or whether you need to escalate the matter to the Project Board.

The activity you would use there is called “Review the stage status“ and it is used to carry out a thorough check on the progress of the whole stage, including any forecasts, to see whether you are still likely to finish the stage within its tolerance limits.

The stage tolerances were set down by the Project Board at the beginning of the stage.

Just for completeness, do remember there is another activity within the Controlling a Stage process called “Review work package status“.

Although this too provides a progress check, but it is only done for each work package, and don’t forget you may have several work packages to completed during a stage, and often more of them may be executed in parallel.

The relationship between issues and risks

I have already given you a simple definition of an issue and of a risk, and they are clearly different. But did you know that one can cause the other?

If someone raises an issue, as part of carrying out issue analysis you may determine that this particular issue has an impact on one or more risks. The issue could make a risk more likely or less likely, the impact greater or less, or the impact areas may now be different.

It works that way when managing the risk too. When carrying out risk analysis a new or modified issue may be discovered. Also, as part of resolving a risk, you may only be able to minimize its impact rather than remove it completely. This remaining impact that for now, you can do nothing about, In and of itself could give rise to a new issue.

The Business Case

When managing the details within a stage, it is easy to forget that any issue that is being analysed may have an impact on the Business Case. I’m not just talking about benefits here, but also other aspects of the Business Case such as risks, constraints, timescales and cost.

Reporting an exception situation

Any given issue may cause stage or project tolerances to be forecast to be exceeded. As the project manager, if you have determined that no matter what action you take within your authority, you cannot adjust the running of the stage to finish within the limits of the tolerance, you must report this to the Project Board immediately.

The stage is now “in exception “

The only action you should now be taking is to investigate the size of the problem and the scope of the actions and produce an exception report. The structure of the exception report was laid down within the communications management strategy document.

It is important to realise that the exception report is not necessarily a document that may be a meeting, a phone call or an e-mail. Whichever makes most sense.

It is also worthwhile mentioning common sense. If the forecast deviation the tolerance is relatively small, then I would recommend immediately contacting the Project Board and discuss this with them verbally. Of course, first you would want to think through what actions you would take and at that swift meeting get their buy-in to proceed.

It may be that the actions that you can take to bring the stage back within tolerance may have other impacts such as Business Case impact.

So, whenever an exception occurs, the project manager recommends how it should be dealt with, but it is the Project Board that must decide how it will be dealt with.

With regard to issues, and as part of assembling an Exception report, you would want to check out the Issue Register to determine the latest progress of this or any other issues being currently managed under formal control, and if it has already been created, the formal Issue Report itself.

It is worth spending a moment considering the Lessons Report, which after all should be created at the end of each stage and at the end of the project. However, this is the minimum, and frankly a Lessons Report can be created at any point during the project.

With regard to issues and their inclusion within a Lessons Report, you should consider any statistics such as trends. The statistics may be helpful with resourcing similar future projects or future stages.

When detailing an issue within the Lessons Report, the following areas should be considered:

I mentioned earlier that issues and risks were related, and it is here whether you should mention whether the trigger event had been previously identified as a risk – either as a threat or an opportunity.

The Issue Register and follow on action recommendations

I do want to briefly mention that as the project comes to a close, you will be using the Closing a Project process. As part of that, you will want to close down the Issue Register.

Follow on action recommendations are what the Project Board recommended for the organization to do after the project has finished.

But you may carry some entries forward into follow on action recommendations, an example here is a good idea That you would recommend the organization to do after the end of the project.