In the danger zone

A few years back, I worked on the construction of a high-profile millennium project. We knew that the building we were altering was important; we knew that obtaining planning permission would be complicated; and we knew that a lot of people would have to be consulted before work went ahead. We therefore identified a list of consultees and arranged to make presentations to them.

What we did not know was that three of our consultees had extremely strong views. So strong, in fact, that they succeeded in delaying the planning process for about a year. The building opened on time, but only because we were able to accelerate works at the cost of additional disruption to the client.

On another project, our preliminary risk analysis suggested that the main contractor might become insolvent. Despite reports in the press and grumblings from subcontractors, no action was taken and – surprise, surprise – the main contractor later went bust, causing considerable delay and additional cost.

These are examples are testimony to the fact that, in the construction industry, we are generally bad at the "management" bit of risk management. We complete detailed analysis and produce impressive charts and statistics that are based on little real information. This might allow us say we have "done" risk management, but we have probably not really increased the team's level of understanding of the project nor set in place a mechanism to reduce risk for our client – the generic failing illustrated by the first example.

For example, we have methods such as Monte Carlo analysis, which can model many thousands of future possibilities and generate statistical outputs to demonstrate your chances of completing the project within given cost or time parameters. But this kind of analysis is only of use if you have some sound data – and in the construction industry, you generally do not. In short, meaningful analysis can only be undertaken once we have fully understood the project and the risks that affect it, and this requires a lot of thought and discussion.

Another way to fail is shown by the second example. If you compile a list of problems and assign some actions to be taken with respect to them, you may think you have accomplished something. And you would be right – but if and only if you then took those actions … How to do it For risk management to be useful, it needs to be a structured and clear process that enables us to appreciate the uncertainties surrounding our projects and allows us to define clear means to reduce that uncertainty and increase the chances of the project delivering what our client requires.

The basic steps that should be adopted are: n Define and understand the things that are critical to project success for the client. If you do not know this, it probably represents the biggest risk. Once you know the benefits required, you can then think about what might threaten their delivery.

n Define the things that may prevent that success being achieved – that is, the risks. This could also include the lack of information, resources, an appropriate management structure or communication routes.

n Understand the risks, their likelihood of occurrence and the impact should they occur. This assessment can only be broad, so the most important thing is to identify those things that could impact severely on the project and ensure that they are mitigated: find those three people who can delay planning for a year.

We need to remember that there is no magic involved, so the results are only as good as the information we have provided

n Order the risks so that action and effort can be focused on the big ones. This is generally done by assigning a numerical rating to likelihood and impact assessments and multiplying these together. There are a range of systems, some more sophisticated than others; the key is to focus on ranking the risks according to impact.

n Assign actions, prioritising them in terms of the biggest risks.

n Undertake the actions – easier said than done, but the better the risk is understood, the higher the chance of the team managing it.

n Review the register to ensure that the actions are actually reducing risk as they were intended.

Risks are by their nature things that might not happen and we tend to read this as will not happen. After all, we all have more pressing things in our in-trays – things that have already happened! But sometimes the pressing things in our in-trays are of little real importance – they are just there, and so we perceive them as more urgent. In fact, the real urgency may lie in something that might seriously affect the project if we do not take steps to prevent it.

I often get the sense that we prefer to sort out a crisis rather than gently work away to prevent one. Perhaps in our rather macho industry the greatest glory is in dashing round fighting the fires, and not quietly ensuring they never ignite in the first place.

However, I do have a cheering example to end on. Our project management team on the Eden Project identified, unsurprisingly, that planting a large number of trees quickly was key to the programme. However, experts had dismissed our fears that it might prove difficult to get large plants into position within the biomes. Handling plants that were 10 m high and weighing more than a tonne was common practice, they said.

Our team was unconvinced and constructed mock-ups using telegraph poles with concrete bases to simulate rigid trees, and a surplus 7.5 m tropical plant to model floppy plants. This experiment showed that there were, indeed, serious problems.