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,

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.