Dealing with issues
As the project manager you can expect to receive project issues – often many of them. Although within PRINCE2, Issues are covered under change control, it is important that you understand and issue needn’t be anything to do with a change. For example, perhaps a member of the team is passing on a good idea.
Remember that an issue can come from anyone within the project or anyone with an interest in it. It can be sent in are any time and can be about anything that is relevant to the project.
As a project manager, when you first received an issue, you need to make a decision about whether to deal with it formally or informally. If the latter, then you can simply note it within the PRINCE2 Daily Log
PRINCE2 Daily Log
It may be that It is an issue that needs to be dealt with formerly and therefore needs formal tracking. In this case, the Issue Register is used. Your first action having entered it into the Issue Register is to then transfer the details of the issue into an Issue Report.
The PRINCE2 Issue Report
This is a formal record of an issue that is normally created by the project manager upon receipt of an issue. But be aware That it may have come from someone within the project and that they have already written an Issue Report and use that form to submit the issue in the first place.
Once you have recorded the issue, your next task is to see what action if any you need to take. This is sometimes called impact analysis.
In my past, I have often run software development projects, and writing software is something that I have not really done. If it is the case that you are not a subject expert of an issue that has been raised, then go ahead and get advice and guidance from the people who do know – Possibly those who make up the specialist team within the project.
Indeed, I would often run a risk analysis workshop or meeting with one or more individuals who can help determine the exact nature of the issue.
While carrying out issue analysis, there are a number of aspects that need to be answered and the following are examples of who you may wish to help with this:
Okay, so what some questions would you need answering at an issue analysis workshop or meeting?
First, check whether it is an issue rather than a risk. The difference is fairly straightforward. Put simply, an issue is an unexpected event that has just occurred, whereas a risk is something which may or may not happen at some point in the future.
Determine whether the issue affects costs, timescales, the Business Case, or the timings or level of expected benefits.
Does the issue influence the nature of a product or several of the products?
Another useful question to ask is whether the impact of the issue that has arisen within the present stage, does it impact this stage only or other stages during the project?
Going further, does this issue have the potential to impact other projects, programmes, or on-going operational management?
You will want to determine what action you need to take to address the issue, and then to determine whether that action can be undertaken within your level of authority, or whether you have to escalate it to the Project Board.
To help determine whether it needs to be escalated depends on the tolerance that you have been given for the stage (Or if the impact is outside of that or the project).
There are two useful activities within the Controlling a Stage process.
The first covers the steps you would take If the project manager can resolve the issue within their own authority, and it is called “Take corrective action “.
If the project manager determines that the issue needs to be escalated, then the activity called “Escalate issues and risks “would be used to escalate it to the Project Board.
Don’t forget, that even though the project manager feels confident that they can deal with the issue within their own authority, it may be good common sense to talk it through with the Project Board member informally.
At the very least, it will set the project manager’s mind at rest, with an added potential benefits of gaining a new insight or another idea about how to manage the issue.
The PRINCE2 Highlight Report
The Highlight Report is not supposed to be a huge, complex report. Rather, it should be straightforward and at the right level of detail suitable for the Project Board to absorb quickly.
The Highlight Report is important progress reports that the Project Board will find vitally important during the stage, as they are managing by exception. I make the point again that the Highlight Report should be simple and take not much more than an hour of the project manager’s time to create.
You will be aware of the social change that has occurred due to the proliferation of faster Internet connections and smartphones. We have all become skimmers rather than readers. We want to view information that is relevant and concise.
The Project Board are no different.
So do not create complicated and time-consuming reports because the Project Board may never read because of their complexity. They will not thank you for booking the hours that you rack up while creating long and complex reports either.
One particular section of the Highlight Report is called “Key issues and risks“.
Be careful not to go into too much detail here, the Project Board do not need to know that you are capable of dealing with the issue, only that you are bringing it to their attention and that you are currently managing it.
As an example, going into glorious detail about the technical matter that is being resolved within the specialist team may not be appropriate here.
Never forget that the Project Board are using the PRINCE2 principle of management by exception.
This means that they assume the project manager has everything in hand unless it is escalated formally or informally to them. In this way, their regular Highlight Report should be for information only, and not alerting them to some crisis that they are not yet aware of.
The message here is to include key issues within the Highlight Report of significant Issues only, not a mass of routine detail.
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.