On the face of it, issue management is both a basic part of project management and pretty straightforward. Experienced project managers deal with it day-to-day.
Yet, when you delve into it, you’ll find two surprises. First, the PMI‘s Project Management Body of Knowledge, its PMBOK Guide, all but ignores it. There is no Issue Management process. And second, project managers have two significantly different concepts of what an issue (and therefore what issue management) is.
So, in this guide, we’ll unravel all of this, telling you everything you need to know about issues and issue management. And we’ll offer you the issue management process that PMBoK really ought to have*.
We’ll split our exploration of Project Issue Management into five sections:
The challenge we are going to have here is that there are two significantly different concepts of what an issue is. However, both are clearly distinct from a risk. So that’s where we will start.
A risk is
And we tend to concern ourselves mainly with risks that will have an adverse impact on the outcome we want. These are, strictly, threats. Opportunities are risks that can have a positive effect on our outcome.
Issues are different. There is no uncertainty. Whatever might have happened has happened. Or will happen for sure. Issues are certain.
I particularly like the illustration in ‘Fast Track to Success: Risk Management’ (US|UK) by Keith Baxter.
The difference of perspective on issues comes, as always, when crossing the Atlantic. However, my experience is that many project managers in the UK share a perspective with our American cousins.
That is to say, an issue is something that could have an effect on your project, and therefore needs action.
However, the Association for Project Management (APM – we did a video, answering the question ‘What is the APM?’) takes a somewhat different view. It distinguishes between what we might call big issues and small ones.
It calls small issues ‘problems’. The project manager can deal with these. Larger issues come into the purview of its issue management process. These, you will need to escalate to your Project Board or Steering Group.
When we discuss the
With these distinctions in mind, let’s look at some formal definitions of an issue. The first is the simplest, and the one I like best.
A current condition or situation that may have an impact on the project objectives.PMI Project Management Body of Knowledge, 6th Edition
Notice that, just like a risk, the PMI’s definition allows that an issue could have a beneficial or adverse impact.
The PMI’s definition is similar, in substance, to that used within PRINCE2 and related toolsets, like MSP (Managing Successful Programmes):
A relevant event that has happened, was not planned, and requires management action.Managing Successful Projects with PRINCE2
But, as we’ve discussed, the UK’s APM takes a slightly different view:
A threat to the project objectives that cannot be resolved by the project manager.
Issues should be differentiated from problems, which are concerns that the project manager has to deal with on a day-to-day basis.APM Body of Knowledge, 5th Edition
Issue Management, then, is simply the process of managing issues.
When we describe a process, below, we will lean heavily on the process of managing risks. This is because you can think of an issue as a risk with a likelihood of 100
As I have said at the start of this article, there is no issue management process within the PMI’s PMBOK Guide. However, PRINCE2 and the APM’s Body of Knowledge both have their own issue management process, so let’s just understand how they recommend you do things.
We’ll start by recalling that, for the APM, an issue is big enough to need the Project Manager to escalate it. The APM has a three-step process in its 5th Edition Body of Knowledge:
At the same time, you will track the progress of each issue with an Issue Log.
PRINCE2 offers us a very similar process to that of the APM. However, it is framed as a process for ‘issues and risks’. It is documented within the ‘Controlling a Stage’ process. For the process steps below, I shall drop the ‘and risks’:
In describing the OnlinePMCourses process, we will incorporate everything in both of these processes, and also take account of the distinction between small issues (which APM calls ‘problems’) and lager issues.
Fundamentally, any risk or issue management process will be a version of the Shewhart Cycle of:
The figure below summarizes the OnlinePMCourses issue management process.
You cannot do anything until you are aware of an issue. You need to create a culture of vigilance among your team, and also the confidence to report issues quickly. Too many project team members prefer to keep their heads down and hope issues go away on their own. They fear blame.
Of course, some issue will self-resolve. But many won’t. And some will explode out of all proportion if you fail to deal with them swiftly. So a ‘no blame: no fear’ culture is vital.
Getting this right means having a systematic approach to monitoring your project. A good approach is to set up issue-spotting as a part of one of your regular project meetings. Weekly or even daily check-ins are ideal.
As soon as you identify a risk, you will need to record it onto your Issues Log. We’ll look at that in more detail later.
This step is where you need to understand the nature of your issue. Principally, this is the impact (or severity), in terms of:
These will help you to assess the scale of the issue.
You will also want to think the scale of the issue and the means you’ll have to control it. All of this will lead you to determine two things:
Together these will tell you whether the issue is ‘small’ and therefore, in APM’s terms a problem that you as Project Manager will deal with either:
If it is not, it will be a substantial issue that you will need to escalate to your project sponsor, project board, or another senior level. PRINCE2 offers the following useful guidance:
The Project Manager can only take corrective action … as long as the stage (or project) is forecast to be completed within the tolerances set by the project Board.Managing Successful Projects with PRINCE2, 2009 Edition
What this means is that, if you (the PM) cannot fix the issue without blowing the schedule (or the budget, I’d add), then you need to escalate it. However, you may find yourself executing the instructions or decisions of the senior people to whom you escalated the issue.
Here, you will need to assign responsibility for the issue. This must be at the proper level of authority. It may be that you determine the action to
Assign each issue to the person best equipped to deal with it. This can be someone outside of your project team. But, if you do allocate it outside your team, be sure they know what they are agreeing to, and that you have a commitment from them.
If you are going to escalate the issue, you should do so with a four-part ‘Exception Report’:
Finally, communicate the issue to your team and also to appropriate stakeholders.
This is where change happens. There may be some problem solving and detailed planning, but the substance of this step is ‘doing’.
There may also be a need for subsequent actions:
To supplement this article, we recommend you read our companion article: ‘Problem Solving: a Systematic Approach’.
Monitoring, controlling, and maintaining a record of issues is a key part of project governance. So too, is incorporating the issues status in your regular project reporting. You will use your Issue Log as the primary tool for this.
You will find a lot of guidance about the fields you need in your Issues Log (also called Issues Register). My advice is to keep it as simple and trimmed-down as you can.
If you make your Issues Log too complex and hard to maintain, then you’ll find yourself dodging the onerous requirement. Therefore the log will become a sterile document that is incomplete and therefore useless. So, for each possible field, ask yourself:
What will we use this information for?
If you have no satisfactory answer, either delete the field, or hide it. And, by the way, for most projects, the best software to use is a spreadsheet like Microsoft Excel, Apple Numbers, or Google Sheets.
So, here is a long-list of potential fields;
I’ve given some thought to the practical tips I can offer you from my own experience, and collated them for you, below. They are in no particular order.
You know those children’s cartoons, where one character gets left holding the fizzing bomb. In Tom and Jerry, it’s usually Tom. If he put it out straight away, by pinching the fuse, nothing bad would happen, just a minor burn to his fingers.
But he rarely does. Instead, he watches it, hoping it will go out on its own. And it doesn’t. D’ohh!
As with all aspects of project management, you should be reviewing your Issues Log and your Issue Management process periodically. A good time to do this in a formal way is at your regular Stage Gate meetings. But informally, I’d recommend looking at it weekly.
Good governance means keeping a detailed record of your Issue Management process. There is nothing too
Always express your issues with precision, and in enough detail that you can fully understand what needs to happen, and why. For example:
[This] has happened. The result is that [these things] will ppen and that [these other things] could also happen, with a likelihood of [estimate]. To manage the situation , we need to [create this outcome].
We explained the Pareto Principle in a short video. Most, say 80%, of the impacts on your project will come from a few, say 20%, of the issues that arise. So, you will get maximum benefit for minimal effort is you concentrate your efforts on the few issues that pose the greatest threat to your project’s success.
Often, success or failure of your Issue Management process comes down to judgment. How well do you assess the priority and impact of the issue? And do you allocate or escalate it appropriately?
If you over escalate minor issues, you not only waste precious resource, but you alienate senior people. They will no longer trust your judgment and you may find that a genuinely serious issue does not get the attention it deserves.
If, on the other hand, you fail to escalate issues that need senior tier attention, you can find yourself out of your depth, with the impact growing uncontrollably.
Always review your Issues Log at the end of the project so you can draw lessons learned from it. You’ll want to document these and include them in your project’s lessons learned analysis.
What are your thoughts and questions about Issue Management? Please do leave them below, and we’ll respond to every comment?
In case you are wondering: ‘where would Issue Management fit into the PMBOK Guide’s process set’, here’s my answer.
Probably, I’d put it into the ‘Project Integration Management‘ Knowledge
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.