Issue management is a natural and essential part of project management. But if it is not set up correctly, it will compromise or even completely undermine your risk management.
Defining issues and risks is not as easy as it looks
On the surface, it’s quite clear: an issue is a problem today and a risk may become a problem in the future. In practice it’s not that simple and I have watched many organisations struggle with the question of “is it an issue or is it a risk?”
One reason for this confusion is that most risks will require actions and the first step is often urgent. Therefore “Risk Owners” tend to interpret any problems with getting the first step in the risk action plan as an “issue” and consequently raise a formal issue for virtually every risk with a risk plan. The result is effectively duplication of the same “concern” as both an issue and a risk and more data for the Project Manager to review leading to potential information overload.
Whilst dealing with the “issue” of crossing the snow-bridge, we had to consider the “risk” that we wouldn’t reach the summit and get down before dark.
When does a risk really become an issue?
Again it’s not as simple as it seems. The definitive answer is – “when you can no longer stop the risk impacting, it is an issue”. This means that it doesn’t actually have to impact to become an issue. But who can determine this? Let’s look an analogy.
A missile coming over the horizon should be managed as a risk as we need to work out how to stop it impacting us. Once it has impacted, the resulting crater is an issue and then we need to work out how to clear up the mess.
At some point, an observing soldier may view that the missile is now too close to do anything to avoid impact. The soldier therefore declares the threat to now be an issue. However, the soldier is not aware that his commanding officer has access to the latest in anti-missile technology that could be used to knock out the missile just before impact. If the soldier had communicated the threat as a risk, albeit a very urgent one, then the missile could have been destroyed before impact rather than just accepting that impact was inevitable.
This is of course very much a state of mind, but a very important one that is fully exploited in the ABCD risk management process. ABCD forces people to capture and escalate risks in the form of assumptions even if the impact is close. It is surprising how much senior management can be motivated when things become Important and Urgent, as Stephen Covey once said…
Get the balance right
One of Stephen Covey’s insights from his excellent book, “The 7 habits of highly effective people” can be used to explain the balance required between issue and risk management. As Covey describes time management; everything we do can be categorised as Important and/or Urgent. We have to deal with the Important andUrgent things first but after that we tend get drawn into the Urgent but Not Important stuff i.e. we allow ourselves to get distracted (interuptions, phone calls, emails etc). The effect of this is we don’t spend much time on the Important and Not Urgent stuff. As Covey puts it – we need to spend more time on the Important and Not Urgent tasks and we will then have to spend less time on fixing the Important and Urgent things.
Transposing this to project management; the Important and Urgent things are “Issues”. Whereas “risks” are clearly Important (if not fixed they will become issues) but are not urgent as they are in the future. Applying Covey’s logic again, we need to spend more time on risk management and we will then need to spend less time on issue management.
In practice this simply means getting the balance right and making sure that a focussed risk management process is not overwhelmed by the demands of issue management. In other words, if you have too many issues, then you are not spending enough time on risk management.
Hi Keith – sorry this is so late (I’ve been busy with some “issues” recently), but I just wanted to add my agreement to both the points in your post and to Terry’s comments above. If only all Programme managers had this degree of insight inherently or would receive a nudge in this direction if not!
[…] This post was mentioned on Twitter by Keith Baxter, Keith Baxter. Keith Baxter said: Just finished a new blog – first since April. Have I really been that busy? http://bit.ly/b7dJ4B […]
Hi Keith – great post – worth waiting for :-)
I think that you hit the nail on the head with your comments re duplication of issues and risks. Assuming that you can get the buggers to input Risk Plans, I have found that all the important risks do get duplicated as issues. As you say, every first action to the Risk Plan is a potential issue to the guys on the ground.
The way that we stop this is to have a hard-review gate for every issue that challenges the need to raise the issue seperately. It does work but it seems to be a lot of faffing around. Any tips you have on short circuiting this would be gratefully received.
Hi Jon,
I think that the key to controlling the data is by imposing the ABCD rules for issue management rigorously. So forgive me if I teach you to “suck eggs” but….
Firstly, by wording the issue as an open-question you force people to be specific. Secondly, real issues are only transient – you either fix it quickly or you develop a plan.
When you have a plan, you have assumptions and therefore you can assess the assumptions for risk and close the issue – therefore only tracking the concern in one place.
Finally, the question format of the issue forces you to think if you are actually making assumptions ie the only time that you should legitimately capture an issue is when the question does not have an (assumed) answer.
You may remember all this from your training but it was a long time ago :-)
Hey Keith – really interesting. I just went through our risk and issue registers and found 20 items that were effectively duplicated. Think that we can tidy this up. Good post.
Keith…informative as usual.
I do think that a reason why we have so many issues, so often, and why they duplicate the risks, is that too often the conventional “risk register” is a static repository, populated at the outset of the project or programme; if we’re lucky, there may be an end-of-phase review and update of the register’s contents.
Hence, when the risk does materialise, it becomes an issue – i.e. something ‘urgent’. Not surprisingly, since they are often realised risks, the issues duplicate what’s in the risk register.
With ABCD of course, there are two elements which, I think, work to off-setting this poor practice. First, as you note above, the articulation and challenging of assumptions should generate awareness of ‘what can go wrong’ earlier rather than later. Second, the element of looking at the timing (“urgency”) is key to forcing constant review of the risk. As it gets closer in time, ABCD will generate an awareness of when it is time to act upon the risk before it becomes an issue. Coupled with the dimensions of Controlability and Criticality, this view ensures that attention is paid where it should be. Your analogy of the missile above is very good in capturing this aspect of ABCD.
I can recall a large program of work on which I was undertaking a health check and plotted the Controlability / Criticality / Urgency of the risks. It proved very effective (particularly the “criticality” aspect) in focusing executives’ attention where it was required. Smaller issues were not ignored, but corrective plans put in place quickly to address them, which had the added benefit of providing a feeling of attaining some ‘quick wins’ to get the work back on track.
At the end of the day, of course, effective risk management is a behavioural, not a process, issue. But the strength of ABCD is that it inherently – if not necessarily intentionally – recognises this, and offers the process and methods to counter the wrong behaviours by filtering out the noise, and focussing resources and energy where they are required.
Looking forward to the next blog, and of course the book.
Hi Terry – thanks for sharing your experience. Sorry for the delay in replying – trying to climb mountains at the moment but the weather won’t behave itself.
Completely agree with your prognosis that its all about behaviour and not process. The thing that we have tried to do with ABCD over the years is to adjust the process to try and change/guide behaviour. I think this has worked well in some ways and still can be improved in other areas – any suggestions greatfully appreciated.