Examining the issue
This should involve all appropriate individuals, not just the project manager. These individuals could include team managers, team members, specialist contributors, Or even external third parties such as suppliers.
Be careful about involving Project Assurance here, as that may detract from the impartiality. Remember that Project Assurance provides an audit function independent of the project manager.
There are several impact areas that should be considered, and the following list give you some ideas for those that should be included when examining the issue:
Staffing levels and staff availability
A point worth considering here when planning the project with in the initiation stage, is whether you predict and expect many changes to occur. In such a case it would be smart to include resources and time in your plans for issue impact analysis.
There are three levels of decision-making authority here, the project manager, a Change Authority if you have one, and the Project Board. Such actions if beyond the project managers delegated authority, needs to be proposed to ever is authorized to do so.
Exactly who that authority should be, falls to the Project Board. During initiation, the Project Board must decide how much authority, and what type they are prepared to delegate to the project manager, and this includes a clear definition of the point where the project manager must come back to them for a decision.
Very often this decision point is cost or budget. The way to do this is to set a band of cost where if any issue action occurs within it, then the project manager can make the decision. Any point above that and it will need to go before the Project Board.
But there is another dimension to this, as some decisions, although falling within the authority banned described above, may have operational consequences that the Project Board need to be involved in.
Deciding the actions
Such actions would be entered into the Issue Register and all the relevant Issue Report. If the issue has been escalated to either the Project Board or a Change Authority in, the decision will be taken at that level.
The decision could be a simple as a “yes or no“, but it may be an agreement to defer a decision until they obtain more information. In such a situation, the project manager will collect the information and return for a decision.
Such a deferment could be to review it later in the current stage, or if nearing the end of the project, there is sufficient funds left in the Change Budget, or it could be done in a later stage, or even to be done in a future project.
If the latter action is decided, then the follow-on action would be used and passed to a responsible role to carry that through after the project has finished.
Implementing the work
If a decision is made to proceed within the project, then the project manager needs to manage this.
It is often the case that some form of re-planning is needed within the Stage Plan or a Work Package. Once the work is complete, the issue can be closed down within the Issue Register and the Issue Report, or if it was being managed informally, within the Daily Log.
PRINCE2 Change Budget
I have mentioned a Change Budget, and it is worth mentioning how that is set up.
It can be set up an authorized on a stage by stage basis, or for the project as a whole.
A Change Budget is a good idea as it will allow the project manager to accommodate any unforeseen changes without having to constantly go back to the Project Board to approve every single change no matter how small it is. Such a point should be made clear to the Project Board if they are hesitant about approving a separate Change Budget.
Another option the Project Board has during the initiation, is to appoint a Change Authority who would act on their behalf to manage and deal with any changes. This would free up the Project Board to direct more appropriate areas rather than tie them down to long and detailed meetings concerning the approval or otherwise of changes.
Whenever any form of delegation regarding changes is agreed, it is important that the “rules of engagement “are made clear to all those involved.
I want to make one other point here, and it could be a better approach rather than just implementing issue resolution actions.
This is particularly useful for complex issue resolution actions. The option I’m talking about is to create an Exception Plan that replaces the rest of the current stage plan. The project manager would produce a new plan showing all the work necessary to implement the change and then presented to the Project Board for approval.
In summary then, the Issue Register is ready to use to record the existence, the progress and the outcome of issues that are being handled formally within the project. The Issue Register is maintained and used throughout the whole of the project and is Included within the last delivery stage of the project.
Indeed, the end project report contains in the ongoing issues that need to be passed on to operational management rather than be dealt with during the project before closure. These are called follow on actions. The lessons learned report which forms part of the end project report, will include any lessons learned from specific issues or their management throughout the project.
The contents of an Issue Register are fairly logical. You would need to record who sent the issue, when it was cent, a brief description of what the issue is about, the current status for example under review, and finally when it is closed.
This last point is important as it advises you which issues have been resolved and which ones are still being worked on.
The Issue Register is set up in the initiation stage, ready for use in the delivery stages. Indeed, there really is no problem in setting the Issue Register up at the very start of the initiation stage as there may be several issues raised during that time which require formal resolution.
As you can see, when handling issues, it is not always just about problems, but also good ideas as well. The exact procedure that you use for formal issue management should be laid out clearly within the configuration management strategy created during the initiation stage.
Off Specification (Off-Spec)
The term off specification means that the product has failed to meet its quality criteria during testing and that you cannot easily correct the problem. An off specification could be raised even before the product is tested in a situation where the team can see that the product is never going to meet its quality criteria.
You may be thinking that if a product does not meet its criteria and it fails its test, the all you need to do is to take it away on work on it until it does meet the standard and passes the test. Although a reasonable thing to do, it may not always be that easy.
It may be that the correction is going to take some time and that time tolerance would be exceeded, or perhaps the resources are no longer available, or that obtaining resources is difficult, for example some components used within the product are no longer available.
So the usual case is that an off specification is for a product that has not met its quality criteria, but sometimes it can be because a product exceeds its specification which may also cause a problem.