Previous articles in this series have addressed identifying
risks to the project and choosing which risks to avoid or minimize by scoring
and prioritizing the identified risks. The purpose of these two activities is
to determine which risks you should deal with to increase the likelihood that
your project will meet its goals and objectives. The actions that can avoid a
risk are determined by the nature of risk, as are actions that can reduce the
impact or probability of the risk event. The risks to a project that will build
a bridge will differ from those that will build a software system. This article
will address devising strategies for risks to software development projects.
Risk strategies are categorized in accordance with their
approach to dealing with the risk:
Avoidance The action or strategy chosen will be such
that it eliminates the factors that generate the risk. For example,
multi-sourcing a software system’s server will avoid the risk of delays to the
project if your single source supplier cannot deliver the server on time.
Mitigate Risk mitigation entails devising an
approach that can lessen the likelihood of the risk event happening, but not
completely avoid it, or lessen the impact if it does happen, but not completely
Transfer You don’t avoid the risk or mitigate its
impact or probability, you transfer responsibility for dealing with the risk to
a third party. The classic example of this is insurance.
These strategies all deal with risk events that are threats
to the project’s goals and objectives. There are things that could actually
enable your project to exceed its goals and objectives and these are called
Opportunities. Opportunities differ from risks in that risks are discouraged
while opportunities are courted. A common example of an opportunity is the
chance that a programmer finishes a piece of coding ahead of schedule. If you
do nothing, the programmer will have a nice holiday but the project won’t
benefit. A contingency plan for deploying the programmer in question on a piece
of code on the critical path could help you deliver the project ahead of time.
Contingency plans are not the only tool in the risk manager’s arsenal. Here is
the complete list:
Exploit To exploit an opportunity the project manager
would implement a plan to increase the likelihood of the event happening.
Taking our example of the programmer finishing the code earlier than planned,
we could put a senior programmer on that code to increase the likelihood they
would finish early. It is likely however, that putting the senior programmer on
work that lies on the critical path.
Enhance Deals with the impact of the opportunity.
Let’s stick with our software system example. We have implemented a plan to
exploit this opportunity by assigning the senior programmer to that code. We
could enhance our opportunity by having a marketing program ready to capitalize
on the early release. Enhancing the opportunity in this case would mean we not
only save money by completing the project early, we also increase revenue with
our marketing campaign.
Share Sharing the opportunity means that the
opportunity is shared with one or more parties outside the organization
performing the project. The classic example of this is the formation of
partnerships between companies to develop new technology. The purpose of
sharing is to engage skill or expertise that the performing organization does
not have in order to enhance or exploit the opportunity.
There are 2 strategies that we have not covered as yet and
they apply to both threats and opportunities. These are:
Acceptance Risks that are accepted have scores that are
below the project’s risk threshold. The costs saved by avoiding or mitigating
the risk do not justify the expense. Opportunities that are accepted are not
acted upon for a similar reason: the expense of enhancing, exploiting, or
sharing the opportunity exceeds the benefits that would be reaped should the
Contingency The key difference between a contingency plan
and the other actions for threats and opportunities is that the other plans
(avoid, mitigate or transfer for threats; exploit, enhance, or share for
opportunities) are proactive; they require you to act before the risk event
happens. Contingency plans require you to devise a plan that will be acted upon
should the risk event happen.
The skill that good risk manager’s have is not the ability
to categorize an approach to a threat or an opportunity, rather it is the
ability to identify the best strategy or plan to deal with the threat or
opportunity with the budget available. Focus on the strategy or plan before
worrying about whether the action falls into the avoidance or mitigation
category. Good risk managers know their limitations when it comes to
identifying the best strategies and plans and know how to supplement their
knowledge with Subject Matter Experts (SMEs) to address their shortcomings. The
first part of your risk strategy planning should be the identification of your
areas of deficiencies and a plan to engage SMEs who can make up for them.
Let’s walk through some things to look for in each of the
above strategies. The purpose of expanding on each of the categories is not to
give you a comprehensive list of strategies or plans for each category, but
rather to give you an overview of the characteristics that tend to make the
different strategies or plans effective.
Avoiding a threat to your project’s goals will involve a
plan to remove the project element(s) that would introduce the risk. You need
an action that effectively removes the threat and you need to implement it in
time to avoid the risk event. Let’s take the example of the risk of flu
infecting a programmer developing a key piece of code for your software system.
Having that programmer (and probably the entire team) inoculated for flu would
be one way of avoiding this threat. Let’s assume that the shot has a 2 week
incubation period. That means that the shot won’t be effective until 2 weeks
after its been given. To be an effective avoidance plan you’ll need to ensure
the programmer gets the shot at least 2 weeks in advance of the start of
I have exposed a weakness in the segregation of approaches
to dealing with risk into categories: is the flu shot 100% effective in
avoiding the risk? The difference between avoidance and mitigation lies in that
percentage. The flu shot is an avoidance plan if it is 100% effective, but
becomes a mitigation strategy if it is only 99% effective. The real question
is: does it eliminate enough of the risk to make it worth while? You would
probably need to be a doctor to be able to provide a good answer to that
question, but there are other situations where your SMEs will be able to
provide good answers.
Let’s use another example to demonstrate an effective
avoidance plan. The risk event you want to avoid is that the introduction of a
new development platform that your development team has never used before will
add extra effort to the project and delay the delivery of the software system
past a hard deadline. The platform was chosen in the first place because
eventually it will make programming more efficient and produce a better quality
system but your project will not be able to realize those benefits. A possible
avoidance strategy would be to continue programming on the old platform.
Continuing on the old platform is guaranteed to be 100% effective in avoiding
this risk because you remove the technology that introduced the risk event in
the first place.
The trick to devising a strategy that will effectively avoid
a risk event is to choose one your project and your organization can afford.
The cost of the example cited above might be greater than the budget for the
project would allow. Worse than that, it might be an approach that your
organization cannot afford. Delaying the benefits to be derived from the
introduction of the new platform might be urgently needed by the company. Your
subject matter experts can help you gather the information you, or your
sponsor, need in order to make a good decision.
In the case where an effective strategy that avoids the risk
event cannot be devised, is it possible to devise a mitigation strategy that
will reduce the impact of the risk event enough to preserve the project’s goals
and objectives. Would a training program that provides the programmers with
training in the new technology, plus the addition of 1 or 2 extra programmers
reduce the impact of the risk event enough to deliver on time? The choice will
always be a business decision: is the cost of the preventive strategy greater
or less than the benefits derived? Is there a more cost effective way of
achieving the same goal?
Mitigation is typically reserved for referring to threats to
the project, but can be expanded to include both threats and opportunities if
you divide the category into 2 sub-categories: exploitation of the opportunity
or reduction of the likelihood of the threat and enhancement of the opportunity
or reduction of the impact.
Exploit the Opportunity or Reduce the
Likelihood of the Threat
Mitigation strategies that reduce the likelihood of the risk
event, or threat, can be exemplified by our flu shot example. If the flu shot
is less than 100% effective, then the flu shot would reduce the likelihood of
the risk event. Test tools are another good example of a mitigation strategy
that reduces the likelihood of a risk event. The risk event in this case is a
bug being introduced into a later development phase such as Quality Assurance
testing or User Acceptance Testing. The introduction of the automated test tool
will increase the capacity of each programmer to test so if a programmer has a
total of x hours to conduct unit, function, and system testing, the automated
test tool will increase the number of test cases the programmer can run. This
will reduce the risk of a bug that should be identified at this stage finding
its way into the next stage where it is more expensive to fix.
Tools that enable continuous integration are also examples
of mitigation through the reduction of the likelihood of the risk event. The
risk is that a bug that has to do with the integration of various applications
in a software system will not be found during development and will be
propagated to a later test stage where it will be more costly to fix.
Continuous integration reduces the likelihood of this by compiling and testing
the system each time a piece of code is checked into the library. The question
is how effective is it in reducing the likelihood: 100%?, 75%?, 50%? The answer
is that it will depend on the number and thoroughness of the test cases.
Notice that the strategy does not reduce the impact of the
risk event in any of the examples given above. A bug that escapes the rigorous
tests implemented with the automated test tool will still cost the same amount
of effort to report and fix.
Exploitation of an opportunity will also increase thelikelihood of an opportunity without enhancing its impact. I will stick to the
example stated in the section entitled Exploitation above, where you staff the
programmer role with a senior programmer to increase the likelihood that they
finish the task early. There are several issues to consider in this case. Does
the amount of time saved on this task warrant the expense of the senior
programmer? Will engaging the senior programmer for this role put another task
Enhance the Opportunity or Reduce the
Impact of the Threat
Reducing the impact of a threat does not have any effect on
the possibility of the event happening. It does tend to reduce the cost of the
event if it does happen, either the cost in terms of time or money. Taking our
example of the flu shot, let’s suppose we have weighed the benefits of reducing
the likelihood (or avoiding it altogether in the case of 100% effectiveness)
against the cost of the shot and determine our risk budget can’t afford the flu
shot. We still want to do something to address the risk we run of the
programmer falling ill and delaying delivery of the software system.
We could partner another programmer with them so that if the
programmer who is developing an application that is on the critical path falls
ill the partner can pick up their work without having to be brought up to speed
on the application. The partner should be working on an application that is not
on the critical path and has at least 3 days of slack, assuming the average
length of a flu bout is 3 days. The programmer should also have roughly the
same skill set as the key programmer and have a comparable amount of
experience. The cost of this strategy would certainly be less than the cost of
flu shots. It will not reduce the likelihood of your key programmer catching
the flu but will reduce the impact of the event if it were to happen.
Please note that this is not a tutorial on appropriate risk responses.
The examples I’ve chosen merely illustrate the points I’m trying to make. Flu
shots for the entire development team, or specific members of it, wouldn’t be
feasible in smaller companies. You probably would not be able to dictate to the
team that they must be inoculated even if you had the
means to provide the inoculation.
Enhancing the opportunity should provide a benefit to the
project in terms of money, time, feature set, or quality. Let’s take the
example we used in defining the approach. Let’s say we engaged the senior
programmer to code the critical path application increasing our chances of
getting to market with our software in advance of our planned launch date.
Investing in a marketing campaign which takes advantage of our early launch
date should generate extra sales. Just how many more sales it would generate
would be impossible to forecast. You would need the help of a market analyst to
forecast the increase as accurately as possible. The decision then becomes will
the cost of the marketing campaign (or the change to the existing campaign),
plus the cost of the senior programmer be less than the forecast revenue
increase? Would there be a revenue increase without an additional marketing
campaign (or change to the existing one)? Would that revenue increase exceed
the cost of the senior programmer?
I used the example of purchasing insurance to illustrate
this approach to risk. Insurance is certainly not the only option for this
strategy, you could transfer the risk by engaging a vendor or sub-contractor to
develop an application using a new technology that is a core competence of the
vendor. You could also transfer the risk of introducing bugs into the User
Acceptance Test environment by engaging your companies Quality Assurance group
to do QA testing before turning the system over to the user community. You will
need to weigh the cost of transference against the benefits that will be gained
by the transfer.
Sharing is similar to transfer in that you engage a third
party to increase the likelihood of the event happening or increasing the
reward if it does. Let’s use the example of the new technology again. Our
competent crew of programmers could certainly master the new technology with
the proper training, if your project has the time to conduct the training.
Outsourcing the development of the part of the system that uses the new
technology would allow you to complete that part of the project in less time
than could be expected if it were done in-house. That savings in time may allow
you to get your system to market quicker which would increase sales.
Outsourcing the development becomes a "sharing” strategy in that case.
Keep in mind that transferring a risk does not mean you have
no further responsibility or actions to take. Would you abandon all driving
safety measures just because your car is insured? Stop wearing a seat belt?
Exceed the speed limit? Pass cars when you can’t see the oncoming traffic? Of
course not, you’ll still take these precautions to avoid an accident because
your insurance company will only cover the monetary costs of an accident, they
can’t deal with the pain, suffering, or loss of life an accident may cause. Risk
avoidance and mitigation strategies must still be monitored when a risk is
transferred. Unit, function, and system testing must still be diligently done
by the programming team even if you have transferred responsibility for QA
testing to an external organization.
Contingency planning requires an extra element that none of
the other strategies employ: a trigger. The other strategies are designed to be
implemented before the risk event occurs whereas a contingency plan is designed
to be implemented as soon as the risk event happens (or the opportunity
happens). The contingency plan requires a means of alerting the project manager
to the risk event. The trigger should be something that the project manager
will examine periodically to check for the risk event.
For this strategy, let’s use a construction project as an
example. Your construction project is an office building and the dry wallers
union contract ends August 31st. That date occurs right in the
middle of the installation of the interior walls for your building. You can’t
do much to replace the dry wallers if there is a strike; employing non-union dry
wallers would risk a walk-out of all the trades on the project and you can’t
affort that risk. There is a product however, that can be installed in place of
dry wall and can be installed by carpenters. The cost would be just about the
same as dry wall making it an acceptable substitute. Your contingency plan is
to order the substitute product and engage the extra carpenters. You would only
do this in the case of a strike, it would be far too expensive to purchase the
substitute product and engage the carpenters just in case there is a strike.
You need to choose an appropriate trigger, one that will avoid unnecessary
expense but will implement the substitution in time to preserve the project end
Unions must provide a strike deadline by law in most countries,
states, or provinces. This deadline does not necessarily mean a strike will
happen; there is still the possibility of a negotiated settlement at any time
up to the last minute. It would be appropriate to define that strike
notification as a trigger. You will issue a purchase order for the substitute
product in case of the notification, in fact you could have your purchaser
prepare the order in advance and then issue it to the vendor when you receive
the notification. You will also issue the order for your carpenters to the
appropriate union hall, etc. when you receive strike notification.
The key to implementing an effective contingency plan is to
choose a trigger that will provide you with enough time to implement the plan
and is cheap enough to make the plan cost effective. Let’s use an example from
the software industry now. Let’s say you have a senior programmer working on an
application on the critical path and that programmer is in the Reserves. They
may be called up at any time and will be lost to the project if they are. The
reservist will be given one week’s notice before they have to report (please
keep in mind these are hypothetical situations) which would leave you one week
to find a replacement. The skill set the programmer has is in short supply so
you can’t identify someone in your organization to replace them. You could hire
a contract programmer to fill the position. You would use the call-up notice as
a trigger to implement the contingency plan. The trigger leaves you with a
reasonable amount of time to implement the plan and won’t require you to pay a
contractor while the reservist is still on the job.
The strategies described above are all intended to deal with
the risks identified with the project, but is it reasonable to expect every
possible risk to be identified? The answer is no, it isn’t. The risks we don’t
know about have the potential of de-railing our project even if we effectively
avoid every risk we have identified. So how do we deal with the unidentified
Unidentified risks are sometimes called the unknown
unknowns. That term stems from the statement "I don’t know what I don’t know”.
Since you don’t know anything about them, what the event is, how likely it is
to happen, or what the impact would be if it does happen, none of the
strategies described above will be effective in dealing with them. The only
strategy available for dealing with the unknown unknowns is a contingency
reserve. The contingency reserve can be either monetary or time.
When the contingency reserve is defined in terms of time the
reserve may be called a buffer. You need to protect this buffer from the
project stakeholders. There will be a strong temptation to fund requested
changes from this buffer, resist this. The buffer should be monitored
throughout the life of the project to ensure it is sufficient to carry the
project through to completion. The buffer may be broken down into individual
amounts for project phases, stages, or deliverables. The contingency reserve
may also be calculated in this way. The reserve needed for the build phase of
the project is likely to be greater than the reserve needed for design. The
contingency reserve is depleted each time an unanticipated risk event occurs.
The reserve will also be depleted if the avoidance or mitigation strategy for
an anticipated risk proves ineffective.
The tips and tricks described in this article implement some
of the best practices promoted by the PMI (Project Management Institute). These
are taught in most PMP® courses
and other PMP® exam preparation training products. If you haven't
been certified as a PMP® (Project Management Professional) by the
PMI and would like to learn more about certification, visit the three O Project
Solutions website at: http://threeo.ca/pmpcertifications29.php.
three O Project Solutions also offers a downloadable software based training
tool that has prepared project managers around the world to pass their
certification exams. For more information about this product, AceIt, visit the
three O website at: http://threeo.ca/aceit-features-c1288.php.