Issue Management: All You Need to Know about PMBoK’s Missing Process

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, 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:

1. What are Issues? We’ll unpack the term and see the two competing ideas of what an issue is.
2. What is Project Issue Management? There may be two competing concepts of an issue, but they both need managing.
3. Project Issue Management Process. We’ll offer a single process that works for both ideas of an issue. In doing so, I guess we’ll be taking sides a little!
4. Project Issue Log. Whether you use our process or another one, you’ll need a tool to manage your issues and support your issue management process. This is the Issue Log.
5. Tips and Advice. Finally, we’ll round up some practical guidance to help point you in the direction of pragmatic and effective project issue management.

What Are Issues?

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.

Issues or Risks?

A risk is an uncertainty that can have an effect on your outcomes. Uncertainty is in the nature of risks.

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.

Issues of Problems?

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 issue management process, below, we’ll return to this distinction.

Definitions of a Project Issue

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

What is Project Issue Management?

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 per cent.

As I have said at the start of this article, there is no issue management process within the PMI’s PMBoK. 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.

Issue Management the APM Way

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:

1. Identify
2. Escalate
3. Resolve

At the same time, you will track the progress of each issue with an Issue Log.

Issue Management the PRINCE2 Way

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’:

1. Capture and Examine Issues
2. Escalate Issue
3. Take Corrective Action

Project Issue Management Process

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.

The Shewhart Cycle: Plan-Do-Check-Act

Fundamentally, any risk or issue management process will be a version of the Shewhart Cycle of:

• Plan
• Do
• Check (which W Edwards Deming wisely preferred to call ‘study’)
• Act (which some, including me, prefer to call ‘adjust’, to create a clearer distinction from ‘do’)

An Overview of Our Process

The figure below summarizes the OnlinePMCourses issue management process.

Identify Issues

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.

Analyze Issues

This step is where you need to understand the nature of your issue. Principally, this is the impact (or severity), in terms of:

• schedule
• budget
• delivery
• quality
• stakeholder perceptions

These will help you to assess the scale of the issue.

Big Issue, or Small?

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:

1. Priority of the issue – how much attention it merits (importance) and how soon (urgency). I would recommend a simple priority level to each:
   1. Vital – Immediate
   2. Important – Urgent
   3. Medium – Soon
   4. Low – As time allows
2. Controllability – the effort it will take to control the issue and manage the outcomes

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:

• yourself, or by delegating to
• team members

PRINCE2 on Big vs Small

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.

Plan Issue Response

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 take, or delegate that task. In assigning responsibility, also set a resolution deadline.

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’:

1. The Issue: what has happened
2. Implications: why it matters – and how much it matters
3. Options: how the issue can be dealt with, along with an assessment of each
4. Recommendation: your preferred approac

Finally, communicate the issue to your team and also to appropriate stakeholders.

Take Corrective Action

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:

• Creating a change request and handling the subsequent change control process.
• Managing consequential changes to the budget, schedule, or business case.
• If an issue remains unresolved for too long, you may need to escalate it.

To supplement this article, we recommend you read our companion article: ‘Problem Solving: a Systematic Approach’.

Ongoing Tracking and Reporting

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.

Project Issues Log (or Register)

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. Inly record information you need to either:

• properly manage your issues, or
• maintain full accountability, transparency, and good governance.

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.

Suggested Fields for Your Issues Log

So, here is a long-list of potential fields;

• Index number – a unique reference number for each issue. Vital for keeping a strict audit trail, and therefore part of good governance.
• Issue type – you may want to be able to sort or filter issues by type, for example: technical, personnel, stakeholder, change request, delay…
• Date identified
• Issue name – a short-form descriptor
• Issue description – detailed description
• Identified by…
• Issue documented by…
• Stakeholders impacted
• Urgency
• Severity
• Priority
• Assigned owner
• Resolution deadline
• Action Plan
• Status – live, under management, closed
• Closure date – when the issue was signed-off as closed
• Resolution details – what actually happened

Issue Management Tips and Advice

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.

Time is of the Essence

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!

Regular Review

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.

Record Everything

Good governance means keeping a detailed record of your Issue Management process. There is nothing too small, because anything can blow up and become big. But as well as creating an audit tral, your risk log is a powerful management tool.

Express Your Issues with Precision

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].

Pareto Principle, or the 80-20 Rule

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.

Success or Failure

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.

Lessons Learned

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 is Your Experience of Project Issue Management?

What are your thoughts and questions about Issue Management? Please do leave them below, and we’ll respond to every comment?

* PMBoK’s Missing Process

In case you are wondering: ‘where would Issue Management fit into the PMBoK’s process set’, here’s my answer.

Probably, I’d put it into the ‘Project Integration Management‘ Knowledge Area, and in the ‘Executing‘ process group. I’d place it as 4.4, straight after 4.3, ‘Direct and Manage Project Work’, shunting 4.4 to 4.5 and so on.