Whether it’s small or large, complex or simple, every
project has risk. It’s our job as managers to do our best to not only minimize
the risk in our projects but to minimize it as soon as we can. In this article,
you’ll learn a simple four-step approach for doing just that.


The first step to managing the risk of a project is to
inventory the situation. That is, identify all of the risks that you think are
possible in the project. The inventory should include all internal factors for
the project such as resource changes, assumption failures, and sponsor
availability. It should also include all external factors such as a change in
company direction or a change of technology direction. Most of all, however, it
should include the things that are new in the project. If the project is
working with a new technology, is using a new development methodology, or even
if there are new, relatively unknown team members, these need to be listed as
potential risks to the project.

The purpose of the inventory phase isn’t to classify the
risk or identify its importance. That step happens later. The goal is to
collect all the risks. If you mix in the process of evaluating the risk you’ll
find that you won’t get a complete inventory of the potential risks for the
project. Staying focused on capturing risks is essential to the process.


Once you have a complete list of potential risks, it’s time
to evaluate them. Each risk should be evaluated based both on its probability
and on the impact that it would cause if it happens. The loss of a key team
member may have a low probability; however, the impact to the project can be

Some people struggle with the evaluation step because both
of the numbers, percentage and impact, are guesses. They recognize that even
subtle changes in the values for these numbers can
have a huge impact on the total risk of the project. However, in general, the
objective here isn’t to come up with a single number that represents each risk.
The objective is to develop a framework for evaluating the various risks against
one another. Although precision in the estimating process is useful it’s not

The other factor to evaluate when looking at a risk is its
duration–how long that it can have a potential impact on the project. For
instance, the loss of a subject matter expert early in the project is a risk
because their input is still needed. 
However, later in the project they may not have much input and therefore
aren’t a risk if they leave.The
risk of a functional analyst leaving is greatest in the initial phases of the
project when they are intensively interacting with the customer. Later on in
the project, the loss of the functional analyst has a smaller potential impact
for the project.

In order to get a consistent number for all of the risks,
multiply the probability which should be per interval of duration by the impact
and finally multiply that by the duration. The resulting number is a single
number, a risk quotient, which can be used to prioritize risks within the
project. For instance, if the probability of the risk happening in a given week
is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is
$1000, the overall risk is $1000. 
(.10*10*1000 = 1000)


Now that you have a single risk quotient for the various
risks, it’s possible to prioritize the risks for the project. It can give you a
clear vision of what the risks are and which ones you’ll ultimately need to be
concerned about. This is also a part of the process that typically helps
validate the estimates made above. For instance, if your greatest risk is
personnel turnover (as it usually is) you may want to more objectively evaluate
the probability. If the average person stays at your organization for three
years you can assume a probability of them leaving in a given week is 1/156
(3×52 weeks/year) which is a 0.00641 percent chance.

Control and mitigate

Once the risks are prioritized you can go through the list
and identify which risks are controllable, which risks are things that can be
mitigated, and which risks must be accepted. For instance, the risk of loosing
key personnel can be mitigated by providing completion bonuses or even just
monitoring their happiness more closely. Technical risks can be controlled by
moving them forward in the project so that they are proven out nearly

In general, the fastest way to reduce the overall risk
quotient for a project is to tackle the controllable risks early in the project.
The more quickly that you are able to validate the risk associated with an item
the more quickly the risk is no longer a risk (so its probability can be zeroed
out.) Focusing on controllable risks won’t completely eliminate risk but it
will quickly cut it down.

The next step is to develop mitigation strategies for those
risks that can’t be controlled. Completion bonuses are a routine way that
organizations which are closing down operations mitigate the risk that the
people participating will leave before the project is ready to let them go.

Not every mitigation strategy needs to involve money. Simply
getting a verbal, personal commitment to finish the project is often enough to
further reduce the probability that a person will leave during the project. Most
people value their own sense of self worth and they believe that their ability
to meet their personal commitments is a part of the admirable part of their

TechRepublic’s free Strategies that Scale newsletter, delivered each Tuesday, covers topics such as how to structure purchasing, when to outsource, negotiating software licensing or SLAs, and budgeting for growth. Automatically sign up today!