Ever heard that statement? Normally what they really mean is “I get it, but why does it have to be so formal?”
The deciding factor on how much formality is appropriate should be based on the size and complexity of the project or programme. In ABCD we have the Criticality/Complexity Diagram (CCD) that can be used to explain this. The CCD is also a useful mechanism for stopping fixation with the size of the project and making management take account of what is really making the project potentially risky ie the complexity
On the CCD, the project is positioned, relative to other projects in the organization. If the position is agreed to be in the top right hand corner, formal risk management is justified. If the project is positioned outside the top RH corner, then simpler, less formal risk management approaches are appropriate. Simple eh? But lets look deeper at the psychology of what can happen here…
Good project and programme managers often have strong personalities and the problem is that this can verge on arrogance. For example, the Programme Manager of a large-scale programme looks at the risk management process and concludes that it is a sound system but he/she can identify all the key risks themselves without the help of the process. To them the formal process is (mistakenly) just an unnecessary overhead.
The PM of a small to medium sized project should indeed be able to identify all the key risks without the need for a complex risk process. However, as soon as the scale of the enterprise gets larger, and in particular the number of stakeholders becomes significant, it becomes inevitable that key risks are going to be missed. This is going to happen simply because of the challenges in communicating all the relevant data will mean that things will get missed, miss-interpreted, or inappropriately prioritized (and by the way, did I mention “assumptions”? We discussed the psychology of traditional risk identification vs assumption-based in an earlier blog…. ).
In a large/complex programme, a formal, rigorous process like ABCD is not just justified, its essential. But again, arrogance can raise its ugly head and this time the PM insists that the “simple” risk management processes that they used effectively before on smaller projects will work perfectly adequately here “just scale them up a bit”…
Well no they won’t….
Simple risk management processes tend to come a cropper when applied to large-scale initiatives ie
- The scale of the programme means that so many risks are raised that the management can’t assess priorities appropriately and lose focus, or…
- Inappropriate escalation between layers in the programme mean that very few risks get escalated and senior management incorrectly assume that all is well.
- This situation is exacerbated by a manual escalation process that means that PMs do not escalate when they should do, but try and solve the risks themselves. If they fail, it could be fatal for the programme, and comes a big surprise to senior management.
- This also causes an unhealthy shift from risk management to issue management – the subject of an earlier blog.
- The team can also be inhibited from escalating risks by the knowledge that their “arrogant” programme manager will try and squash their concerns because they don’t conform with their view of the world.
So the message is clear – when the project is critical and relatively complex, appropriately formal risk management processes are essential is you are going to identify all key risks.
And if you are still not convinced, ask yourself this question – How many showstopper risks do you need to miss before one stops the show?
And just in case you were wondering – how many times do people fail to “get it” after ABCD has been implemented? Just once in my experience, but that may be the subject of an interesting case study in a later blog…
Hi Keith
A thought provoking post as usual. I have seen this “swamped with data” on too many large programmes. It simply causes management to give up on risk management in despair as they can’t see the wood for the trees, to coin a phrase. On one particular programme I worked on a few years ago, the PMO were completely overwhelmed by the risks submitted by each project. It was so bad that the PMO resorted to re-creating a programme risk register from scratch that was then rejected by the senior management (correctly) as it didn’t come from the projects!
We had a simple color coding for all the projects at the senior management reivew. Green was on track. Yellow was off track but recoverable. Red was off track, non recoverable, being replanned.
With time, Green became “new project,” yellow was “project in progress” and red was “project trying to complete.” The color codings still indicated the overall status of the project, it was only that senior management was not effective at intervening to make a difference on the projects (i.e., corporate culture of late and buggy projects).
Good to great techniques make a difference, if there is a team of folks capable of taking action on the information they get. If a good technique doesn’t work, there is often a more fundamental issue that needs to be fixed first.
Good technique.
Brucce
Hi Don – I have seen this “swamped with data” also – many times. And the point you make about the PMO “making up the risks” is exactly the point of this post – if the risks do not come from the front-line troops and they do not have confidence in the integrity of the system, then risk management will inevitably fail.
Hi Bruce – thanks for your input. This is a touchy subject for me as I am always suspicious when RAG gets used for virtually everything. Sure its intuitive but it can also be confusing.
The classic problem is that RAG is used to summarise too many things eg an overall status of Red can mean that the risk is critical or uncontrollable or both!
In ABCD, RAG is used for the overall Criticality of the risk and ABCD is used for Controllability. These are very different dimensions of the risk and need to be kept separate in order that the subsequent Risk Plans can be targeted appropriately.
I totally agree with you re senior management intervention. One of the critical success factors with ABCD is to get the senior management team totally bought into the process so that they act as “champions”. This ultimately make the process deliver its benefits.
Hi Keith,
Good to hear from you again – it seems like a long time – you been busy? I have seen first hand what happens when an organisation tries to standardise on a single risk management process (and tool). In my experience the tendency is to over-simplify and then the larger projects can’t use these processes for effective risk management.
My question for you is, if you employ a more comprehensive project that effectively supports the larger project, then what should you do for the smaller projects, which do not justify such complexity?
Hi Ravi – been super busy but now time to blog again….
The answer to you question is to make sure that you have a robust process for your largest/most complex projects and then for the rest you have two choices. The most radical is to do no risk management – if they are not critical projects they cannot hurt your your business significantly if they fail?
However, the pragmatic approach would be to use a simplified risk management process for the simpler projects – in ABCD we use the QAC (Quick Assumption Check). Feel free to call if you would like to discuss further…
Hi Keith,
Good to see you discussing many of the issues from my forthcoming book -A short guide to facilitating risk management (Gower June 2011)
I’m wondering if you’d like to review it at some stage – perhaps send me an e-mail or have a look at http://www.facilitating risk.com
Regards,
Penny
Hi Penny – would be delighted to – have emailed you..
Hey Keith, This reminds me of a large government program that I worked on some time ago. The program manager was the brains behind the deal and was generally acknowledged as the only person who might navigate the program through to a successful conclusion. The problem was that he had no people skills, did not believe in formal process and was the arrogant b’stard that I have ever worked with! The program limped along for a year before falling in a heap – to everyones surprise. The program manager then had a nervous breakdown. Go figure.