Many project managers think risk management is just a waste of money, but are they right?
Under the auspices of HM Treasury, a group of major infrastructure owner operators known as the Infrastructure Risk Group published a report recently on what it found to be the best risk and contingency management practice for UK infrastructure projects.
The intention was to share and improve best practice, and through this ensure that greater financial benefits are reaped from the next generation of projects. I declare an interest: I am an advisor to one of the members of the IRG which, as well as involving the Treasury, includes Network Rail, the Highways Agency and others.
At the launch of the report, the message from the key speakers – senior directors from HMT, the National Audit Office, London Underground and Crossrail – was clear: exemplary risk management practice would not only be welcome, it is expected. The risk management field is now wide open but what, I wonder, are those of us grazing in it up to? Are we pushing its boundaries or are we lying on the grass? I suspect I know the answer.
Over the last 20 years, risk management in banking and insurance has moved on but what we do in infrastructure projects is largely unchanged. Indeed, it may even have gone backwards. There is a recommendation in the IRG report that the cost of a major project should not be fixed years in advance of completion. Instead, a range of costs, reflecting the current state of knowledge, should be provided in the early years.
This is what happened for the first phase of the Channel Tunnel Rail Link in 1993. The then Secretary of State for Transport, John MacGregor, announced that the costs of CTRL1 would be between £2bn and £3bn. He did not commit to a single number that the press could use against him. However in 2013, the cost of HS2 was given as a single number, and it has been a political football kicked all over the field ever since.
What about the generation of such numbers? Have the risk managers been steadily building up the quality and reliability of the data and its modelling that is capable nowadays of giving reliable and robust outputs? I doubt it. Most of us have been using the same old questionable numerical methods, fed with the usual speculative data obtained at short notice from a limited circle of sources – our teams.
They provide us with non-specific statements about how a project may find itself in an overspent situation, or running behind schedule, and then explain what actions will be taken to prevent this occurring. If a quantified analysis has been done then the team usually provides four numbers about each risk for use in a simplistic Monte Carlo simulation: the probability of an unwanted event happening and the minimum, most likely and maximum costs. This one-fits-all approach is unlikely to reflect reality.
It is difficult to see what the risk manager contributes to the process other than take on a major part of the workload of carrying it out. This led me to think of a test. Suppose I place £100,000 in front of a project manager. I tell them that they can either hire a risk manager or pocket the money. The catch is: if the project is delivered late or over budget, the manager has to repay the money they took plus £50,000 more. What would the project manager choose to do?
A straw poll of colleagues found they would pocket the money because they reckoned they could carry out the risk management. They said they would need experts to design and construct the project, but when it came to risk management they felt an expert was unnecessary.
This vexed me. The challenge it sets for those of us working in the field of risk management is how to contribute something that would not exist but for our having created and developed it. Managing a process of managing risk is not sufficient reason to hire us. We need to bring something to the table. Knowing the risks, how much contingency will be needed to cover them and how to reduce them could be it. It is time for risk managers to become expert on risk, and not just the process around it.