Michelle Symonds argues that risk management fails to effectively address the real project risks: the unknown unknowns.
Risk management in projects involves identifying, quantifying, and managing risks. All projects have some measure of risk. Projects using new technology face the prospect of that technology failing to deliver on expectations; highly complex projects deal with the problem of being able to accurately estimate time and costs; and even the smallest and simplest projects have some element of risk.
It is impossible to remove all risks, so we try to identify and manage them to prevent project failure. A risk plan is the only way to obtain project approval, as it presents the risks as well-defined and, therefore, controllable.
But what about the unknown risks that take you by surprise and knock a project completely off-track? Risk management is considered a major part of the project management process, but can it help with such events? And if it can't, why do we expend time and energy trying to predict and control the unpredictable?
It is convincing to argue that having a risk plan enables a project manager to factor in contingencies (financial and otherwise) that help outline what might happen during the course of the project and to be prepared if those events do occur. But it could also be argued that, if the risks are known and can be anticipated, then the likelihood of them occurring is high, so why not simply include additional tasks within the project schedule to deal with them? For example, you should allocate time to review specifications part-way through the project to avoid the problem of incomplete or inaccurate specifications; or, you should allocate time to improve client communications at regular intervals.
Many risk management plans are little more than a standard template that lists the same risk factors for every project: un-documented assumptions, failure to estimate tasks accurately, key team members re-assigned, etc. Surely by now we all know that these uncertainties exist in every project.
If we know about potential risks, why are we even calling them risks — aren't they simply the inherent uncertainties present in doing anything new? Indeed Stephen Ward and Chris Chapman argue against using the term "risk" in their paper "Transforming project risk management into project uncertainty management."
So does risk planning and management serve any practical purpose, or is it simply designed to provide a get-out when problems start to occur, or an explanation of why the budget is over-running? Has the project been approved on minimal costs just to get it through the approval process even though there are "risks" attached to it that are certain to occur? Or is it not about cost at all? Are the risks of failure so high that there would be no appetite for that level of risk-taking if it was fully exposed, but there are senior executives still driving the project forward? Real-life projects are influenced by so many conflicting factors that it is sometimes difficult to see why a certain project was ever approved.
There is an upside to taking risks: It is often the only way to achieve something truly groundbreaking — many would argue it's the only way, and can often present great new opportunities. So we use risk planning and management to persuade ourselves that we can understand and can control the risks even when we know the real risks are those that we are not prepared for: the unknown unknowns.
Another problem with risk management is that many potential risks are predicted by past events, yet any stockbroker will tell you that you cannot predict future financial markets by looking at historic trends. The best that we are doing is guessing — until a risk event actually occurs, we cannot say with any certainty that it will happen. Sure, we perform analysis, look at past trends, add some contingency in time, cost, and human resources, but at what point does all this effort start to outweigh the benefits?
If risk management could prevent projects from failing or being adversely affected by external circumstances, all projects would be successful, and, clearly, they aren't. So should we bother expending time and effort planning for predictable risks that are a natural part of most projects? Would it be more effective to simply deal with the problems when they occur. At least that way the problems are tangible, so the solutions will be easier to devise; and if we accept that problems occur in projects, then we shouldn't be taken by surprise when the inevitable happens, whether that is a new technology not living up to its promises, incorrect assumptions, changed priorities, or any other factor that can negatively affect a project's outcome.
And if we know that risks are certain to materialise (even if we do not know what they are), we can accept problems or uncertainties as part and parcel of every project and deal with them in a measured way instead of overreacting and assuming the project is doomed to failure just because it has hit a bump in the road.
Risk management may seem like a sensible process, and maybe it is useful for a novice project manager, but it fails to effectively address the real project risks — those factors that cannot be anticipated. Yet we continue to see risk management as a necessity and one of the building blocks of good project management. Who among us is courageous enough to embark on a project with no risk management in place, simply some contingency for unspecified tasks? That is perhaps the hard bit to sell to senior management.
Share your feedback
I would like to hear your opinions on why you use risk management as part of the project management process, and whether you think it adds real benefit, or if you have used a better approach.