This post has been written by Yehuda Sapir – an expert on risk management, PMP, RMP, ISO31000 certified, qualified on financial risk management, yehuda@keshetsolutions.com.
As part of the forum which Tal Levanon, a professional colleague, has provided me, I have decided to pose a question which, I hope, will stimulate those dealing in risk management to devote some thought to the following fundamental issue: what constitutes a risk to an engineering project?
To all appearances, this is a simple question: a risk is the effect of uncertainty on the project goals (as defined in International Standard ISO31000).
The classic risk management failure
The book entitled The Failure of Risk Management, a second edition of which was published in 2020 (Douglas W. Hubbard), deals with the variety of issues of failure in the classic risk management: the tables, the matrices, the risk surveys – why do all these actually fail in helping projects to succeed and even become counterproductive. Hubbard offers alternatives for understanding the nature of the risk like for example, “potential loss, disaster, or undesirable events which are measured by the likelihood attributed to the events and the scope of their impact” or simply put, “the possibility that something bad will happen“.
Risk Management – Managing Uncertainty
Let’s try to gain a deeper understanding of the issue of uncertainty. Here too, the range of possibilities the Web and the dictionaries offer is quite dazzling (even the English term Uncertainty is subject to broad interpretation), but in all likelihood the uncertainty can be associated with a state of “lack of information and/or knowledge which prevent predicting the future”.
Lack of information or lack of knowledge - what’s the difference?
The lack of information is distinct from lack of knowledge. Lack of information means lack of data, facts, figures, measurements, while a lack of knowledge, on the other hand, is the absence (or lack) of professional, individual, or group capability to analyze the data and the facts, to build forecasts and analyze them, to evaluate various scenarios, and perhaps even inability arising from the biasing of the facts (in other words information is available but it is biased, asymmetrical, unbalanced- but more about this in a separate post).
What is the difference between an Issue and a Risk?
A lot has been said in professional circles dealing with this matter, about the difference between an Issue (a management issue, lack of clarity, a project-level issue) – and a Risk which is by nature uncertainty, in fact it is the difference between an Issue and a Risk.
The following diagram is an attempt to describe the difference between a Risk and an Issue:
The Issue is a situation described at a relatively high level, with a large amount of information, and a high likelihood that we are professionally capable of dealing with the issue, and yes – this could get complicated, just as any other known action. The water may be colder or deeper than what we knew or measured, but this is still within reason, can be dealt with relatively quickly within ordinary management practices, and there is no need to deal with a sizable, unpredictable uncertainty.
The Risk is an unpredictable future situation, or which is very difficult to predict in the absence of sufficient information or knowledge. It is beyond the mountain, over the horizon, sometimes even intangible and – most importantly – it is not a trivial part of the project, not the everyday routine work that might get disrupted.
An activity that might be disrupted is an Issue, which is handled through management routines, work plans, timetables, method statements.
Here are some examples of risks (significant uncertainties) versus issues – reasonable uncertainty:
- Protracted proceedings for obtaining a building permit at the local planning committee might impact the project’s timetables. Really? Probably not.
First of all, there is regulation and there are standard response times for the committee. Secondly – the number of permit requests submitted is huge, and so are the real data (the delays and the overruns) regarding the committee’s response and granting of the building permit – a huge amount of data both based on the professional’s experience, statistics, studies, and even inquiries with the committee itself – these will produce a large amount of information which will enable predicting in advance, and at a (relatively) high degree of accuracy, the timing at which a building permit will be issued, after having fulfilled the terms for the permit, and even given that delays and overruns from the standard times are to be expected – but these are known, they are familiar and predictable. Therefore, there is no point writing the standard times + a little bit in the schedules. Rather, one should address the expected delays which are based on knowledge. Here there is a high degree of certainty that there is going to be a delay and the length of the delay can be estimated. One can try and deal with it through known managerial practices (submission of a complete application, pressuring the committee, quick response to the committee’s requests, use of experts, prior acquaintance with the committee, extensive experience in submitting requests for permits). - Delays in works of the infrastructure company at the site may cause prolongation of the schedules. Indeed? Apparently not. The amount of work these companies have carried out in recent years in construction sites (diverting infrastructures, reinforcements, relocation, burying) enables any experienced professional to come up with a relatively close estimate of how long it is going to take for the companies to accomplish the work, including the expected delays and overruns. Of course none of this obviates the need to traipse among these companies, but this is the common practice, neither an uncertainty nor a risk. It’s reality. The likelihood that these companies will fall in line with the project-owner’s plans (whoever the project owner may be) and will stick to these precise schedules – is so low and remote that the likelihood of failure to meet deadlines varies between high and certain, therefore the delay can be placed in the issues category rather than in the risks category.
- Lack of knowledge among professionals in the country in field XYZ may cause the engineering design to take longer. Indeed? Not really. The lack of knowledge is a known given. There is no reason to classify it as a risk. This is a surmountable managerial issue, and including it in the risk survey won’t solve the problem, and indeed it is a problem. If there is a lack of knowledge, this can be bought – through experts, research, data collection. The problem is known, the solutions are known, and the likelihood that someone is going to assume responsibility by embarking on the project in the absence of such knowledge usually borders on professional malpractice, rather than being a risk.
- The absence of regulation in field XYZ and the low probability that such regulation will materialize by the time commissioning takes place (in view of the prolongation of legislative or regulatory processes given lack of information and knowledge in the field in the country at the moment), might entail a substantial delay in obtaining an operating license. Yes, this is a risk, a quintessential uncertainty, and even worse – it lies with a third party over whom we have limited or non-existent leverage to exert influence. We don’t know when such regulation will exist, and whether and how it is going to affect the project which has already gotten underway and which relies on such future regulation (for example – directives of the competent cyber entities in the country, the Cyber Authority. Changing requirements due to the proliferation of cases of hacking into information systems, the hackers’ sophistication on the one hand and the growing experience on the other).
- The technology that ought to be implemented in a project has only been tried in two places anywhere in the world, and there too, the cumulative experience amounts to no more than a year or two. The weather conditions and the environment in the two locations are very different relative to the production site in Israel, and there is a high degree of uncertainty as to the outputs of the facility as well as to the maintenance and operational costs. Indeed, a sizable aggregation of uncertainties, surely a risk that has an impact on the project goals. One can make working assumptions (not a simple matter), one can run a pilot site under prevailing ambient conditions and let it run for 2-3 months and draw conclusions, one can assign the accountability to the technology provider (to a limited extent, since he is likely to have reservations on a broad range of issues. Besides, the fact of writing the contract and signing it does not really transfer or divide the accountabilities evenly).
The importance of distinguishing between an Issue and a Risk
Why is this distinction important? Because risk management is intended to serve the project manager, the project management team, and primarily the making of the cardinal decisions in the project lifetime, decisions which are made under conditions of uncertainty. Risk management is not intended to serve as a “reminder” for the project manager regarding open routine tasks which are known and familiar (which would be dealt with one way or the other, even if they do include a measure of uncertainty). Risk management is not a tool for tracking and control – its main mission is to serve the project in all matters concerning uncertainties, the ability to identify them, to discuss them, and based on their analysis, to make informed decisions under conditions of uncertainty.
Project managers and decision-makers will embrace risk management only if it becomes a tool that helps them directly in managing the project and in making decisions under conditions of uncertainty.
Issues management becomes just another time-consuming chore, consuming double the time, and in the end the risk management is abandoned in desperation and frustration over the loss of valuable time. This valuable time could have been saved by continually dealing with piecing out the complicated, invisible, unknown future, in order that when the day comes and we reach it, we arrive prepared with informed decisions being made.
the project successfully.
Want to talk to Tal Levanon about it?
If you answered 'yes' - then we have a solution for you!
Why is it important to manage uncertainty?
Uncertainty is not a mishap, a disaster or a sin – it is always with us, it’s part of our lives. But not every little issue in the everyday practicalities is an uncertainty. We don’t manage risks in a structured process like driving on a familiar road inside the country under familiar conditions. There is no reason to waste precious time on that. There is, however, good reason to manage uncertainties on a winding road in a foreign country, unknown to us, which we have never traveled on before, and where it is likely that we will:
- Run into extreme weather (wind, rain, snow) while driving along this road, even in the European summer.
- Encounter animals crossing the road, animals we are not familiar with from our original country.
- Arrive at roadblocks we were unaware of (because we can’t read the local language and we aren’t updated with the news).
All these cause uncertainty which will affect us when we have to catch the flight back home, to the hotel or to the planned meeting.
At the end of the day, the main mission of risk management is the coping with significant uncertainty in the decision-making processes. Not the kind that is expected, known, familiar, repetitive and can be dealt with, but rather the kind that is unfamiliar to us, that will surprise us when we least expect it, that we have difficulty acquiring knowledge about and which we cannot prepare for in advance.
Be diverting risk management into the comfort zone of issues management (involving a measure of uncertainty) results, in most cases, in valuable management time being wasted, inefficiency, repetition of things which are in any case being dealt with in other forums. The goal of risk management is to support and assist senior managers when they come to make decisions under conditions of uncertainty.
And what’s in the next posts? About bias and its impact on risk management and project management in general, and about the various ways in which risks can be managed in such a way that they will support the project manager and the decision-making processes.
