PRINCE2 Change and Issue Management
Welcome to a short 5 part series on PRINCE2 ISSUE MANAGEMENT. Tracking of Issues is simple, as long as you follow some simple guidelines:
Dealing with a Concession
On occasion, it may be the right thing to do to accept an off specification rather than try to correct, or redesign the product in some way. Just accepting the product as it is may be the best option for many reasons including time or cost. Such a situation within a PRINCE2 project is called a Concession.
Most of the time, it will only be the Project Board who can sign off a Concession. But what about highly technical projects where the Project Board’s experience may not be sufficient to make an informed choice?
In such a situation it may make sense to delegate Concession decision-making to the team manager or possibly even a team specialist. If this were to be the case, the Project Board would merely be “Rubber stamping “such an evaluation.
Want to master PRINCE ISSUE MANAGEMENT?
Accept it now – Fix it later
This is often a decision that needs to be made in the real world. The way to approach this is to combine a Concession with a follow on action – Which in turn allows the situation to be managed as a temporary Concession.
This would be a smart move particularly if you don’t have time to correct it without missing a key delivery milestone. You would make a Concession and accept the product knowing that it is only a temporary fix.
You would need the supplier or technical team to provide a new reworked product that does meet its quality criteria and come back after some time, maybe even after the project has finished, and get it accepted.
You would pass the follow on action to a manager in the organization who would then take responsibility for it after the project, and is committed to ensuring that the supplier provides be improved product.
The steps to managing an issue:
Step One – Capturing the issue
The first decision the project manager must make is whether the issue should be handled formally and tracked, or informally by making a note of it within the Daily Log.
If the issue is to be handled formally, then the full detail will need to be recorded in the Issue Report and then recording the tracking information of who sent its, its current status, etc. within the Issue Register.
It is important that you see the Issue Register as a control document. It provides an overview of all the current issues shown when each was received, what action is being taken on each, and whether or not it has been resolved.
The Issue Report records to full detail of each single issue. For experienced PRINCE2 team managers, you could ask them to submit any issues in the Issue Report format by completing as many sections That they can. Whether this information is then copied on to the Issue Register or the Daily Log does not matter.
A summary of the control information within the Issue Report is copied into the Issue Register.
Here is an overview of the sections contained within an Issue Report:
- Issue identifier. This is a unique reference, sometimes just a number other times alphanumeric
- Issue type. Here you state whether it is an RFC, An off spec or A problem/Concern
- Date raised. This is obvious I hope!
Raised by. This is normally the name of an individual although it could be a team or group
- Issue Report author. This is normally the project manager but could be a team manager or an individual
- Issue description. Here you detail the issue including the cause of the problem along with the Issue impact using one or more of the six PRINCE2Control areas of cost, time, quality, scope, risk and benefits
- Recommendation. This will be a scale as laid down during initiation and recorded in the configuration management strategy document. It could be as simple as high, medium, or low or to use A phrase such as “Essential “Through to a “Nice to have “
- Severity. Once more, this will use a scale as identified within the configuration management strategy, in addition the severity could indicate who is authorized to make a decision on the issue.
- Decision. This refers to the outcome, which may be to reject a Request For Change, or to make a Concession on an off specification.
- Approved by. This gives information on who made a decision which could be the project manager, the Project Board, or even the Change Authority if you have one.
- Decision date. Obvious I hope!
- Closure date. It may be that an issue situation where no action has been taken in which case the closure date will be the same as the decision date. But where action was needed, it will occur at some point After that.
The Issue Report covers all of the information on a single issue and that includes the action taken on it. A summary of the control information is also dedicated in the Issue Register but slightly modified as I will describe shortly.
The PRINCE2 Issue Register
This is a control document that gives an overview of all issues and will repeat much of the information as described within the Issue Report:
- Issue identifier
- Issue type
- Date raised
- Raised by
- Issue Report author
- Issue description
- Status. This was not included on the Issue Report although it could be if you wish
- Closure date
A point to consider here is that the severity and priority ratings may not be known at this point until the next step when the issue is examined. In such a case simply make your best estimate at this point in time and be prepared to come back and modify it after further examination.
It is often the case that the person who raised the issue will be emotionally motivated and overate its true status.
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.