The design and construction of infrastructure has been a part of what societies do for centuries, and one can assume that the business model for a project and its associated specialisms: project management, design, estimating, planning and so on have also been around for the same time. Over time the various expert disciplines have become established in their roles and their practice has become polished, and it has to be said, somewhat preserved. I want to take a look at one of the newer members of the project community, Risk Management, as it is used on Projects, because it seems to me that its practice has become preserved before it has been polished.
Nowadays no project of substance is without a professional person whose job it is to identify risks to delivery of the project on time and on budget, to assess these in a variety of ways that range from, literally, the colourful to the mathematical in order to advise of their potential threat, and then to recommend actions, usually to be taken by others, to limit or eliminate this possibility. Many flow charts have been drawn up for the process of project risk management, all of which tend to have the same basic content and cyclic nature, and there are many standards. I sometimes sense a furious debate is happening out there about revisions to a process that is, at the end of the day, mainly dependent for its success on the talent of its operators to devise and implement ways that will avoid the unwanted outcomes of risks that could make a project overspend or overrun. The most common way is obviously not to do the risky thing.
Sometimes it cannot. Sometimes the only thing that can be done is to accept that something unwanted may happen, say, during design or construction, and that the most appropriate thing to do is to have a sum of money ready to fix the problem. Such a contingency will usually have to cover several such situations, for example: the award of a planning approval being conditional on additional things being built too; the excavations hitting buried obstructions, and the installed computer systems not working well together.
It is the calculation of this contingent sum that is the first thing I want to consider more closely in these articles because it seems to me that here is a good example of the process of risk management preserving what it does, and I think what it does is wrong.
The established way to calculate the contingent sum (I have never it seen it done otherwise in twenty five years) is to quantify the risks and assemble them into an overall calculation, the risk model, which is then used to calculate the funding needed to cover the unwanted outcomes of the risks at some desired level of confidence. The higher the level of confidence, the higher the contingent sum will be. The use of an 80% level of confidence, first used by the rail infrastructure company Railtrack in the early 1990s, has become wide spread norm when the funding required for projects is assessed.
However it is not this arbitrary level, nor the fidelity of risk modelling, that I want to challenge at this time. It is instead the widely held view, seen in many a risk management textbook, that the level of risk in a project will reduce as a project progresses. While it may not be perfectly so, it is I agree, reasonably true. Risks disappear as the work they are associated with is completed, and at the end of a project when all of it is completed, there are generally no risks left. If the unwanted outcome of a risk did not happen, and the work it was associated with has been done, then the risk’s part in the overall contingency can be returned to the funders.
However the level of risk can go up. It can go up, firstly and obviously because not all risks may have been identified in the earlier cycles of the risk management process. Some may be found later. But secondly, a project is never exposed to all of its risks at the same time. Why then are projects funded from the outset as if they are?
Take the three examples above: the possibilities of additional works as a condition for planning approval, buried obstructions and systems integration failures. An element of contingency funding necessary to pay for systems integration problems is not needed at the start of a project, when contingency to design additional works may be. Indeed, if contingency for additional works is included in the project finances, and none are needed, then that money could be rolled over and possibly used as the contingency for buried obstructions, and if none are found, rolled over a second time to be used to overcome possible systems integration problems.
Not all risks need to be funded from the outset, and – I emphasise this is only one from a number of possible strategies, more than one of which may well be enacted – if the risks were managed in the order of the proximity of start dates of the time frames within which their unwanted outcomes may happen, then it may be possible to achieve that a keep-and-re-use approach to providing financial cover for risk.
The savings can significant. They come about because money has a price too, and the lost interest (or, if project funding is borrowed, the interest paid) and the inflexibility of having funds tied up in contingency that cannot be used for other investments can be considerable.
There are, as might be foreseen, subtleties that need to be understood when an unwanted outcome of risk occurs under such a regime. The residual exposure to risk may not change in ways that can be easily understood after some of the contingency money has been spent. For example, if a tunnel collapses, and is repaired using contingency money then when the tunnelling resumes, the risk of collapse may have altered in some way but it has not disappeared. But even so, there are cost savings to be made on projects when the risk is increasing because a project need only be funded for risk to the extent that it is currently exposed to risk. And that can be an awful lot less than all of it.
[ribbon_new header=”h2″ style=”dark”]Author Bio:[/ribbon_new]Derek Salkeld has been a risk analyst and risk manager for 20 years. He trained as a geophysicist and led a signal processing systems design team for a UK military systems manufacturer. He has extensive experience of multi-disciplinary engineering projects covering a wide range of assets including: the assessment of Network Rail’s IT investment programme; the development of an asset investment model of waste water treatment systems owned by the Water Service of Northern Ireland and the business case for the London Cross Rail system. He was risk manager on both the recently opened London cable car and the East London Line projects. He is currently advisor to London Underground Limited on its stations capital works programme and to Genesis Power on its Tekapo hydro electric projects in New Zealand. He is the author of Project Risk Analysis: Techniques for Forecasting Funding Requirements, Costs and Timescales published by Gower.