Risk management is not easy. Nor is it magic. It is (in short) a systematic process that manages and communicates risk from identification to retirement and it is integral to project management – not an add-on. Planning a project without accounting for risk is “happy-day planning” - i.e. when everything goes right first time every time. And yes, it is a major reason why plans so rarely reflect reality. However best practice risk management conveys a number of long term advantages including (amongst others) predictable performance of projects that enable better corporate planning and budgeting.

Before anyone feels bad about not knowing best practice, let me begin by observing that not everyone reading this may know the cure for these symptoms: that alone is not a sin (it’s difficult enough to find anyone who knows about it, let alone train it to you). The real sin is to keep making the same mistakes without learning lessons or seeking solutions.

But before I get carried away with the huge advantages of good practice, let me first consider my experience of the top ten common mistakes made in risk management.

1. Tick-in-the-box risk workshop

Many people’s experience of risk management is attending a coffee morning (with biscuits as the incentive to attend) for an hour sometime around the start of a project. At that one (and only) workshop a list of “risks” are extracted from a group of people who are rarely the right attendees. The meeting usually ends with an action on the project manager to complete the list later. A risk register is issued within days, (not read or reviewed by anyone) filed and collects dust thereafter. And just occasionally project managers will produce minor amendments to the risk register from time to time as if to prove they haven’t forgotten it – however this is invariably a token and meaningless gesture.

Much as I may delight in freshly ground coffee and chocolate biscuits, this is not risk management; nor the means by which to construct a risk register; nor manage risk. Many tools and techniques exist (and I’m not talking software applications either) that enable an appropriate merger of rapid, top-down and bottom-up identification (the systematic, comprehensive coverage of project management and technical deliverables).

2. Stating facts (not risks)

So few risk registers contain risks. Usually they are filled with general concerns or statements of fact such as “downturn in company performance” or “inexperienced development team” - neither are risks. Only by correctly defining risks can we begin to understand the pivotal nature of risk management. For those unclear you could start by using: “There is a risk that {condition} due to {cause} resulting in {consequence}”.

By identifying the specific risk, its root cause and potential effect will you able to assess and properly manage the risk.

Uncertainties and issues are also often confused with risks so let us be clear about what they are. Uncertainty is something that will happen in a given planning scenario, but the exact measures are unknown. We should try and crystallise uncertainties as soon as possible so that we can then deal with it.

An issue1 is an event that has happened or will happen (100% probability).

3. Confusing probability and impact

It may sound obvious but it is remains high in our top ten chart.

Probability is an assessment of the likelihood of a risk occurring considered against pre-defined scales.

Impact has at least three domains: time, cost and quality (there are others) and is a qualitative and quantitative assessment of the effect of the risk were it to occur.

They are completely different and, in the case of impact, each domain can be scored differently (but never averaged).

4. The Bruce Forsyth Syndrome

This has to be the most amusing deficiency in our top ten. Characterised by a group of people arguing about the probability of risks it is identified by shouts of “higher, higher! No, lower, lower. No higher, higher…” and so it goes on.

Perhaps the most amusing aspect of this scene is that this is usually conducted against the backdrop of no scales, either qualitatively described or quantitatively specific, that defines the boundaries for each of the categories. At best the scales have been “borrowed” (without any thinking taking place) from some generic template. People are consistently poor at assessing risks and do so not necessarily from malice, stupidity or even politics; but simply because they have their own perspectives.

Scales must enable consistent calibration appropriate to the project (and they may be altered where necessary during a project and causing a complete reassessment)! The scales and common definitions should be linked to the critical parameters of the project.

5. Mitigation before fallback

Typically mitigation strategies are an assumed means to manage risks: incorrect! For each high criticality risk there must be a minimum of one fallback plan before a mitigation strategy is considered.

A risk cannot be fully assessed (time, cost and quality) unless and until the fallback plan is considered. The “cost” of a risk is what it would “cost” to absorb the impact of (accept), mitigate, avoid or transfer it.

There can be more than one fallback plan and more than one mitigation strategy and more than one could be executed simultaneously (if considered beneficial): and then they are included in the baseline project plan.

6. Risks not included in the project plan

Managing risks effectively (surprise, surprise) takes time, money and resource. Yet all too often these risk management activities are not included in the baseline project plan: why not?

High criticality risks must have some clear action plans associated with their management and resolution - and as an absolute minimum there will be one fallback plan. More often than not, there will also be an approved mitigation strategy. All such action plans need to be included in the baseline project plan: fully resourced, costed, tracked and reported in the same way as any other part of the plan.

Similarly some medium criticality risks may have good reason for inclusion; depending on their nature and potential resolution. Equally low criticality risks as a bare minimum will have some form of contingency action and/or budget set aside.

7. The PM manages all the risks

Often as a direct consequence of an initial one-off risk workshop (c.f. Tick-in-the-box risk workshop), risk owners are not identified correctly. Consequently the project manager can often find themselves burdened with the inappropriate responsibility of resolving a long list of risks. The project manager’s responsibility is to manage and communicate risk management not to do it all themselves. In executing this responsibility, the project manager should have identified genuine risk owners who understand their risk(s), have an interest and/or commitment to its resolution and will lead the activity to achieve that.

Wherever this symptom is seen it is often as a result of risk owners not understanding or accepting their role and responsibility. In all such cases, senior leadership within an organisation needs to demonstrate leadership by example.

8. Mr 10% (contingency)

How do project managers justify the 10% contingency mantra? I’ve never yet received a satisfactory answer: hardly surprising because I don’t believe there is one. Time and cost contingency calculated on the basis of both lessons learned from previous projects alongside the likely cost of post-mitigation recovery measures provide a basis for a specific level of technical and management contingency. At worst EMV (Expected Monetary Value) can be used to assess the array of low criticality risks and added to the high and medium criticality risk action plans and any planned liquidated damages (yet all too often contingency budgets is an EMV for the entire risk register – a thoughtless and fatal error).

If this isn’t done, on what basis are contingency funds released to a project manager to resolve risks as they materialise?

9. Mitigation that causes more problems than it solves

It is all too easy to get carried away on a wave of excitement when mitigation strategies are generated. But simple tests on their likely success are often omitted.

Firstly, there must be a likelihood of the mitigation strategy actually succeeding

Secondly, the mitigation strategy must be cost effective (and more so than any alternative risk management strategy)

Thirdly, implementing the strategy must not generate more or bigger risks or leave a larger sum of residual risks

Yet there are cases of organisations spending vast sums of money on a mitigation strategy that has no effect whatsoever on the risk it was intended to reduce!

10. We’re good at risk management because we bought the software

Oh dear, oh dear! Risk management applications software is not a substitute for actually engaging in best practice risk management - that remains independent of software.

And even if there were truly excellent risk management applications available there are a number of challenges to overcome including:

A convincing business change project designed to champion and persuade users that this is a step in the right direction, and…

Convincing project teams that in identifying risks they are neither creating them, nor demonstrating a lack of ability to be positive or manage a project well

Remember that use of risk management applications software is simply the tool: it does not implement the process or do the thinking. Back to first principles: garbage in, garbage out!

What next?

Risk management is not easy, painless, or predictable. Nevertheless without it, a project manager is in danger of not planning reality. The future is unknowable but not entirely unpredictable: so every second spent developing meaningful risk management develops the intelligence around what may happen and what we may reasonably do to not get caught by surprise. And “hey presto!” - maybe we won’t need that crystal ball after all.

And by the way: we’re not sure how many risk managers it takes to screw in a light bulb – they’re discussing it now because they weren’t expecting the light bulb to blow.

Author - Neil Richardson

After over 15 years’ in IT management consultancy both independently and with agencies including PA Consulting and Fujitsu/ICL, Neil is now one of Pelicam’s Managing Practitioners. In 2006 he established Pelicam North and is currently delivering Pelicam’s “Realising Project Intelligence” training alongside consultancy assignments.