I have been challenged to write about issue management by a former colleague who says that he sees so many examples of how project issues (mostly linked to large ERP projects) are “incorrectly logged, escalated, allocated severity, given owners, tracked, date and time committed, and closed properly”.
Now I feel some pressure, as David has already articulated the bare bones of what project managers are taught. So I need to get serious, and that requires discipline.
First, defining “issue”
What is an issue and how does it differ from a risk? The single differentiator is certainty – a risk is an uncertain event that may effect outcome,whilst an issue is an event that may effect outcomes. Let’s be more formal. A risk can be formally stated in terms of four components:
- Root causes
Pre-existing conditions that make the occurrence of a risk possible. These are why fellow blogger Glen Alleman is clear that there is no such thing as “unknown unknowns”. The condition is there and knowable – albeit with a potentially high threshold for discovery.
The circumstance that can set about the event by disturbing the root cause conditions.
The event or change we are concerned with
The change in outcome – which can be adverse (a threat-type risk) or positive (a benefit-type risk)
For an issue, the trigger has occurred, so there is no doubt that the risk event will happen – although there may be uncertainty about the consequences.
What process can we use to manage an issue? For me, the best approach is derived from a problem-solving methodology that is well known in many areas of industry – in particular, the auto-manufacturing sector, where it originated. This is the “Eight Disciplines” method. I will describe it here, as adapted to issue resolution.
And the essence of any issue management process must be in “resolution” – taking action to deal with the issue. This is not to suggest that the governance matters of authority and record-keeping are unimportant, but merely to suggest that they are the “tail” not the “dog”. Too many PMs get caught up in these and let the issue run away with their project.
There are eight disciplines, but in my training, I have introduced a ninth discipline, “D0”, before starting with what is normally regarded as the first, “D1”. I am a passionate believer in the concept of “triage” in a project setting. In this case, as soon as you become aware of an issue, there are four triage activities you must take immediately, to assess and prioritise the matter.
- Safety first
Is there an immediate threat? If so, deal with it. Take emergency action.
We may be talking about life an limb, but this may also be about operational integrity, regulatory compliance, reputation or any other “must-do” concerns to your organisation.
- Marcus Aurelius next
Marcus Aurelius – Roman emperor and philosopher – said that we must understand the true essence of all things. What is the issue? What is the issue?
Set your priorities in terms of time to deal with the issue, resources to deploy, and importance compared to other issues and planned activities. If you will need authority to act in accordance with your prioritisation, then document your evidence and reasoning.
- Goal and Objectives
Set your goal and objectives for resolving the issue: what does “resolved” require, and what are the time, cost and quality criteria you will evaluate your performance against?
Start your entry in your issue log by recording your emergency actions, your understanding of the issue, your prioritisation and your goal and objectives.
Your emergency action may have fully resolved the issue – but that will be rare. Now you are ready to pursue the eight disciplines. For that, you must see Part 2.
The “so what?”
Issue management calls for discipline. Filling in an issue log and turning half your attention to the matter will rarely give just the right amount of focus. Start your process with a precise triage of the situation, and then you will be able to act according to a true prioritisation.