{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

Most of us want to work on projects that make a difference. So we have to deal with risk.

Project managers talk a lot about risk. They prepare risk registers. They analyse impacts and probabilities. They define strategies to mitigate risks.

Then they do nothing.

All this work goes into a document repository somewhere, and gets forgotten. Maybe they polish off the risk register periodically to update it. Often they don't even do that.

Risk management is a ritual, part of the ceremony of kicking off a project, unconnected to the stuff these managers do day-to-day.

“NO,” I hear you say. “Project management is all about risk management. It informs everything we do. We constantly look for ways to reduce risks.”

The evidence doesn’t support this. Projects fail every day. They founder on easily-predictable problems: miscommunication, poor estimating, unhappy stakeholders, etc. Too often, the root causes are identified in our risk registers, known about by members of our teams.

We might recognise potential risks. We might even act to reduce their severity as we set up the project. But we rarely actively manage them throughout the project.

Specifically, we too often miss a key point in a risk’s lifecycle – the trigger point.

We can manage risk at one of three times:

1. Before it’s happened

This is about reducing the probability of a risk occurring or doing damage to the project. If a tool is risky, we choose another tool.  

If a schedule looks fragile, we add buffers and redundancy. If a partner looks unreliable, we reduce our reliance on that partner. We buy insurance. And so on.

Most project managers at least try to take such actions during their initial risk planning sessions. (Or they talk of taking such actions: too often their mitigation strategies get written up but never enacted.)

2. As it’s happening (i.e. at the trigger point)

This is about dealing with incipient failures.

Failures often grow over time. A small misunderstanding gets embedded in code; we write more code that depends on the first code; eventually the mistake is spread throughout the system. Or the initial misunderstanding feeds mistrust and grows into personal animosities.  

Or someone gets overloaded, starts making mistakes, and ends up creating more work for everyone.

If we can catch these failures early, before they escalate and get entangled, we can deal with them more easily. Firstly, we’re dealing with smaller, more contained issues. And secondly, we’ve got more time to deal with them.

3. After it’s happened 

This is the realm of contingency plans. A risk has materialised and started to damage our project; we’re now aiming to contain that damage.  If we have a decent contingency plan, we can probably do that without too much pain.

And if we don't have a contingency plan, we’re now into crisis management.  But none of your projects ever go there…

The ideal time to reduce risk is point (1).

We’d all like to make our projects risk free.

Unfortunately, that’s rarely feasible. Projects are about engaging with risks, not avoiding them. We engage with risk in order to achieve commensurate rewards. If we can eliminate all risks, then the project is probably trivial, the rewards inconsequential.

Most of us want to work on projects that make a difference. So we have to deal with risk.

The next best time to deal with risk is (2).

Catch risks as they occur, and we can deal with them before they damage the project.  A “stitch in time saves nine”, and all that.

Yet all too often, we miss this trigger point.  We get snowed under with other tasks – status reporting, updating Gantt charts, maintaining budgets, running routine meetings, etc.  We get caught up in technical complexities.  We get overwhelmed with the amount of information that our project teams produce.

So we miss the early signs of risks coming into play and end up at (3)

Go straight into contingency and crisis management. Now we’re focused on containing damage, not on delivering a successful project.

The worst thing about this state is that it’s self-perpetuating. When we’re in crisis mode, we get focused on immediate concerns. It’s hard to spot incipient failures elsewhere when we’re dealing with a crisis here.  

So those failures get time to grow, to become the next crisis.

It’s possible to avoid this treadmill. One of my favourite columns in a risk analysis is called “Triggers”.

If the team spends a little time thinking about how each risk might come into play, and how they’ll recognise that it has done so, then they’re better prepared to spot it as it occurs.  This sets you up to spend more time managing risks at point (2).

Do this regularly, at initial risk identification and at subsequent risk reviews, and you start to vaccinate your project against common risks. People will be keyed up to notice risks and deal with them as they occur.

That brings up another point. Risk management is a team game. The project manager can't be everywhere, attuned to every signal.

Build a network of trust within the team. Listen to their concerns. It’ll help you recognise and deal with risks before they damage your project.

Graham Oakes

Published 21 March, 2014 by Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is contributor to Econsultancy.

43 more posts from this author

Comments (3)

Avatar-blank-50x50

Jon Rogers

This is great. You're right, risk triggers should be added. And, PM's should ask their teams at each status meeting if anyone sees any upcoming risk triggers. That way, everyone on the team thinks about it regularly and outside the standard Risk Review meeting. I'm going to do this going forward. Thanks!

about 2 years ago

Avatar-blank-50x50

Ashish Sharma

For minimizing the risks in any of the project management plan it is very necessary to analyze the plan before finalizing it so that at our best level we are able to find out its errors

about 2 years ago

Sarah Alder

Sarah Alder, Managing Director at Cranmore Digital Consulting Ltd

Great post, I want to say it's only bad project managers that file away their risk registers and don't actively monitor risks. But, hand on heart, I know you are right.

about 2 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.