Risky Business & Project Risk

Ed Walker discusses risky business and project risk…


I will never forget my first introduction to Project Risk whilst at university, the lecturer pulled up a chair in the middle of the tables and lit up a big cigar.  “Tell me, what risks am I taking then?” he said nonchalantly chuffing away.  The students that were not struck dumb set off giving what now seem like feeble answers about his health and passive smoking.  He sighed dramatically “come on, you can do better” he let us flail about for a while longer then went on to list some of the most imaginative and eccentric risks associated with smoking in front of a student class and then pointed out that not a single one of us had pointed out the opportunity risk.  I fell right into the trap by asking “what benefits could there possibly be of smoking in front of this class?” he grinned at me whilst stubbing out his cigar – “well, for one thing I’ve just ensured you will definitely remember my lecture”.

He was right, all these years later I still remember his lecture and whilst I wouldn’t go around recommending his methods for lecturing, I would recommend his fanatical devotion to project risk.

He firmly believed that everything in life boiled down to the proper appreciation of risk, it was the hub around which all things revolved, the reason you have a schedule and a budget.  Having gone on to experience projects over many years, I have come to share his zealous view – if you want your project to be highly reliable then you’d best have excellent risk management.

Sadly, I have seen countless examples of poor risk management, from the non-existent to the woefully misguided.  One of my favourites was associated with an oil and gas company in America, I arrived into an existing project to look after the ‘down hole’ side of things and was invited to sit in on an overall project update.  The section on risk was one of the most unimaginative generic token risk registers I have come across.  You know the sort where someone has told a project manager they have to have one so they produce it with all the gusto of a child considering a nasty piece of homework.  This risk register was stunning, it had imaginative things like ‘cost overrun’ and ‘project delay’ with world beating mitigations such as ‘keep spend within budget’ and ‘ensure contractors deliver on time’.

Thanks to such dazzling insights into the potential pitfalls and opportunities the project was completed massively under-budget and almost three years early…  Well as I am sure you can guess, it was actually a disaster, a simple delay in one contract had decimated a nicely lined up set of follow on works resulting in huge compensation requests from contractors and the resulting arguments about that had fed into a whole series of delays, bad feeling and eventually a breakdown of relationship with the principle contractor.

I am sure some of you are scoffing at such basic errors but for me this is an exaggerated version of the treatment risk often gets as something to be recorded as opposed to constantly managed.  Much of this is often the result of Project teams trying to consider risk alone or perhaps finding one from another project and adapting it for their project.  Worse still, once the project gets started they promptly ignore it only to wheel it out and tart it up for the occasional project meeting.

If you want your project to be highly reliable you must treat project risk with the attention and respect that it deserves.  This includes working in new ways with your contract partners, it doesn’t matter if you contractually hand risks to them, if the risk occurs the project still suffers.  The most rewarding way to engage in risk management with contractors is to share your risk register with them, I am a great advocate of this – the ‘screw over’ section.  This is how you expect the contractor to ‘screw you over’ by being late or perhaps variation heavy, sharing this can create an honest appreciation of the true risk to both parties (you often find that the contractor has their own screw over section with all the things they expect you to do to them).

This collective view of risk allows you far more options for mitigation than you would otherwise had and when I have used it conversations turn into what the project needs and it gives you a good chance of having an excellent collaborative relationship with your suppliers.  It’s also a powerful tool to weed out the amateurs because if the contractors have a poor appreciation of the projects risks, why on Earth would you gamble your investment money on them getting it right?

4 thoughts on “Risky Business & Project Risk

  1. Some solid advice in the article about risk management, thanks!

    For me, the hardest part of risk management is to spot the risks in the first place. And, for a firm that specializes in knowledge management, I’m surprised that a KM angle does not appear in the article. Risks = what you don’t know!

    My introduction to formal risk was via Praxis, inventors of BS 5750, who separated project planning into 3 – risk planning being one of those elements. And the approach to risk was to review every single task in the emergent action plan and determine the things that were uncertain. Anything. And, of course, the next question was ‘what are you going to do about it’?

    There’s a human frailty here, and it’s the presumption, especially among those that believe they have some expertise, that they know what needs to be known. So often that’s not the case! Risk No xxx1 – we don’t know what we don’t know.

  2. Mike,

    Couldn’t agree more regarding the “Rumsfeld Conundrum”. From the perspective of High Reliability, you would want your project manager to be aware of hazards such as the one you describe and to have behaviors that would help them uncover as many of the unknown, unknown’s as possible.

    This type of problem can also be associated with the perception of risk management, I’ve met many project managers who treat their risk registers as something they have to complete as opposed to being a tool that can deliver real value to them.

  3. Don’t know if anybody has come across a process called ‘Retrospective Analysis’. I sat through several sessions of how to use this process in Shell. I am not sure if they continue to use it, since I only was aware of two projects where it was demonstrated. Basically the team goes back to the beginning of a project and looks at the ‘errors’ that were made, starting at the very beginning and working through what happened, how decisions were made (and of course the wrong decisions with the benefit of hindsight). It was very educational and quite thrilling to sit through these sessions, I would recommend it to any company that still wonders how things went wrong in a project. It is comparable to looking at your work/life history and picking out decisions you made at certain times that were wrong/right and how your life changed at that point.

    1. Yes, a Retrospective is the ‘big brother’ to an After Action Review. There are immensely powerful techniques, especially if they can be conducted on an equitable, fear-free and honest basis. So often, the truth gets smothered because people responsible don’t want any bad news getting out – but that also precludes the opportunity to learn from your mistakes. I heartily recommend both techniques.

Leave a Reply