Identifying risks to your project and devising effective strategies to eliminate or mitigate the threats and guarantee or take advantage
of the opportunities is only half the battle in managing risks to your project.
Your client or customer’s business does not stand still while you deliver the
project so you should not expect project risks to be static. Risks will change
over time as the project deliverables and milestones change. Even when a risk
does not change, its importance to the project will change with time as the
project gets closer to the deliverable or milestone at risk.
Successful risk management requires agility, that is, you
must be prepared to respond to changes to the project environment. When a risk
you were monitoring disappears because the probability of it happening are
reduced to zero, the deliverable at risk has been produced, or the milestone at
risk has been achieved, the risk must be obsoleted and your focus moved to more
current risks. The execution of a project is a learning experience. As you
learn more about upcoming work, deliverables, or milestones, you are likely to identify risks that were not evident before. You need to be able to identify
those risks as soon as they become apparent and devise effective strategies to
deal with them. The activities described in the rest of this article
the process of Monitoring & Control (in PMBOK® parlance). These
will keep your project management style agile and protect your project
being blindsided by risks that could have been dealt with earlier on
weren’t. You may want investigate the possibility of receiving your PMP
(Professional Project Manager) certification. There are many excellent
PMP® courses and other PMP® exam preparation training products to help
you with your certification.
The Risk Register
Your risk register is your project’s bible for risk
information. All the information that you gather that is pertinent to project
risks should be captured in this document and that information should be kept
up to date as you move through the project work. The following is a list of
information that you should track with a brief description of each item. Items
that must be captured and tracked are bolded. Items that may be captured and
tracked are not:
event description A description of
the threat or opportunity that you are attempting to discourage or encourage.
probability The chance of the event
happening, expressed as a number (e.g. from 0 to 10) or ordinals (e.g. high,
impact The impact to the project’s
goals and objectives if the risk event were to happen, either expressed as a
cardinal (i.e. a number from 0 to 10), or ordinal (i.e. high, medium, low). The
method chosen for impact must duplicate the method chosen for probability.
score The product of the probability
and the impact. This is either a number from 0 to 100 or a description (i.e.
low-low, low medium, etc.).
Risk costThis can be expressed in monetary terms, time, quality, or scope.
Strategy One of accept, transfer,
mitigate for threats and exploit, enhance, and share for opportunities. Both
threats and opportunities can be accepted or managed with a contingency plan.
ResponsibilityThe name of the team member responsible for implementation of the
strategy where this is someone other than yourself.
Description This is mandatory when
the strategy is other than acceptance.
Status This refers to whether the mitigation
strategy has been implemented. A one word indication of status, e.g. initial,
planned, implemented, obsolete. You may want to add a fourth status to capture
the status of a contingency plan, for example "ready” to indicate your plan is
ready to implement if the "trigger” condition is encountered.
forecast date for implementation of the mitigation strategy. This does not
apply to a contingency plan.
ProximityThis refers to the proximity of the work, deliverable, or milestone at
risk. For example, you have identified the risk of a dry wallers’ strike to the
activity of dry walling the office building your project is building. The
proximity will increase as the date approaches for the start of that work. This
score can be numeric or ordinal. If you use a numeric system for capturing your
PI score, a numeric system for proximity allows you to combine the PI and
proximity scores (i.e. a number between 0 and 1,000).
WBS # You
may track the work involved in mitigating the risk in your scheduling tool if
this makes monitoring of the work easier.
Trigger The indicator that will tell you when you
must implement your contingency plan. The trigger is the condition that will
necessitate the implementation of your contingency plan.
Comments Any additional, anecdotal information
about the risk, such as the effectiveness of the strategy.
Risk ThresholdThe PI score above which a risk strategy other than acceptance must be
Your project risk register must be updated whenever any of
the information described above changes. You should be especially vigilant of
your contingency plan triggers, a once a week review of this information could
reveal trigger conditions for your plan were reached 6 days ago and you will be
exactly 6 days too late in implementing your plan.
When to Update
Some of your risk information will be updated on the fly, as
you become aware of a change in the circumstances surrounding your project,
some will be updated at regular intervals. Information you gather from
monitoring your project’s progress is gathered on the fly and will be used to
update your information about project risks. A key source of information is
your project schedule. As work is completed and new work undertaken and you
update your project schedule (MS Project file or other) with a percentage
complete date, assess the activity for related risks. Where the starting date
for an activity is a week closer, you may want to update your proximity score.
You will want to obsolete a risk here an activity, deliverable, or milestone at
risk has been completed or passed. You may break work down further in your plan
as it approaches and that breakdown may reveal risks hidden to you before. You
should repeat the steps you took to score your risk and devise a strategy for
Project status review meetings, team meetings, and even job
huddles are excellent venues for updating information about the current project
risks being monitored and new risks that have escaped your notice. Devote a
portion of your project status review meeting to the business of reviewing project
risks; don’t waste time on obsolete risks or risks that are too distant for
anyone to focus on yet. Use the risk register to focus discussion. High light
the risks you want to review. Jog everyone’s memory by reading the description
of the risk event and then poll the team to find out if any new information has
come to light which might change the risk probability or impact. Review risks
being managed with a mitigation plan to determine if the trigger conditions
have been encountered. Conduct risk review meetings where the scale of your
project warrants the extra meeting time. These meetings should be conducted
with Subject Matter Experts who have good knowledge of the risks and some
knowledge of risk management. You should conduct risk review meetings where you
have broken your project down into sub-projects which are each managed by a
project manager who reports to you.
Don’t neglect to include the topic of risks, new risks, and
changes to identified risks as subject matter for your casual conversations
with project team members. You’ll find if you practice your "walk around”
management skills, you will increase your chances of identifying new risks as
soon as they become known to the team. Listen with one ear tuned to the risk
"station”. Conversations that involve what if scenarios can frequently lead to
the description of a risk event which you may not have been aware of. Probe for
the existence of trigger conditions for risks managed by a contingency plan.
You may want to begin a conversation with "Have you noticed… (evidence of the
Risks will change dramatically from one project phase to
another. You may want to conduct a risk workshop with the team at the start of
each project phase where the project is large enough to warrant the expense.
Use your judgment when you decide whether your project warrants risk review
meetings and multiple work shops. The scale of the team involvement in managing
project risks should be proportional to the size of the project and within your
risk management budget. You may track time for risk management activities
separately from other administrative activities in which case you’ll need to
ensure you stay within your budget. Even where you don’t segregate risk
management activities from other administrative activities you need to ensure
that you don’t overburden the team to the point where the utilization rate
Obsolete risks should be marked as obsolete in your risk
register as soon as you become aware of their obsolescence. These risks should
not be included in any of your reviews, unless they become active again (the
recurrence of the conditions which produced the original risk will indicate the
recurrence of the risk). Just mark the risk as obsolete in the register so that
a viewer can tell at a glance that it is no longer active without removing it.
You need to leave the information about the obsolete risk in your register so
it can be archived at the end of the project, or project phase, with the rest
of the information.
Risks can become obsolete when the conditions that produce
the possibility of the risk event have passed or when the risk event has
happened. If the risk event occurred (and it was not an accepted risk) you have
some analysis to do. You need to analyze what went wrong with your avoidance
strategy, if that was the strategy you chose. This analysis won’t help your
project but may save projects that follow yours. You may not have time to
determine a better avoidance strategy, your project is probably running over
budget and behind schedule already, but at least indicate in your register that
the strategy failed.
Risks that are mitigated are somewhat more difficult to
analyze. It is particularly difficult to determine whether a strategy designed
to reduce the probability of a risk event was effective. The risk event either
happens, or it doesn’t. It is somewhat easier to assess the effect your
mitigation strategy has on impact. If the impact on your project matches the
worst case scenario of your risk event, your strategy was not effective. Take
the risk mitigation strategy of the flu shot. You identified the flu as a risk
to your project and took the step of having the team inoculated against it. If
only one member of your team took time off due to the flu, it is very likely
the inoculations had the desired effect. It will be a little more difficult to
assess the effectiveness of the strategy if a percentage of the team comes down
with the flu.
Risks that are transferred require special action. The best
example is a risk that has been transferred with an insurance policy. You will
need to initiate action as soon as you have been notified of the risk event, in
this case the action would be the filing of an insurance claim.
Changes to the Project
Change management and risk management must work hand in hand
if your project is to be successful. Changes to any of the project’s goals and
objectives may introduce new risks to the project and/or may obsolete existing
risks. Risk identification and analysis should be part of the analysis of every
change request. You must make the scale of the analysis proportional to the
scale of the requested change, while at the same time identifying any new risk
event that the change might expose the project to, or existing risks that would
become obsolete. You should evaluate the new risk event to determine its
probability and impact to calculate its PI score. Identify an effective risk
strategy if the PI score exceeds the project risk threshold, or simply note the
risk if it doesn’t.
The new risk event, its mitigation strategy, and any risks
that would become obsolete if the requested change were to be implemented will
factor into the business case for the change. The cost of implementing the
suggested risk mitigation strategy, along with the cost of the impact of the
risk event, should it happen, should be entered in the cost side of the
business case. The savings from any risk strategies that could be avoided due
to an obsolete risk should be entered in the benefits side of the business
case. This information should be captured in the change request. Acceptance of
the requested change should trigger the entry of this information in the risk
register and the implementation of the risk strategy. The information will be
archived with the change request should the change be rejected.
Risk Register vs. Project Plan
There is frequently an overlap of information in the risk
register and the MS Project (or other project management tool) file. Risks that
are accepted will not cross over from the register to the MS Project file but
risks addressed with any other strategy may. The trick is to know when you
should enter information about the risk in the MS Project file.
The MS Project file is useful for tracking work. Its key
output is the Work Breakdown Structure (WBS), designed to help the project
manager organize, track, and control work. Any time that a risk strategy
requires multiple activities or work packages you should consider the benefit
of managing that work in your MS Project file. The work is part of the work of
the project after all and tracking it there will make it easier to control than
if you attempt tracking it in the risk register. Risk registers are usually
fairly simple spreadsheets containing the information in the list in the
beginning of this article while your MS Project file is designed to break the
work down, then track it to ensure it gets completed.
You will need to identify any work you track in your MS
Project file with risk management if the risk management budget is tracked
separately. There are several different ways of accomplishing this, for example
creating a separate sub-project to capture and track risk management related
A simple rule of thumb to determine whether to track risk
management work in your MS Project file is this: if the work of implementing
the risk strategy should be broken down, or the work requires more than one
activity, you will probably save time and effort by tracking it in the MS
You need to monitor your risk management budget, if that
budget is separate from the project budget. The budget may be given to you in
the form of money, or time. If you are implementing your risk strategies on
budget, you won’t need to return to your project sponsor to ask for more. If
you are overrunning the budget you will need to change the project by either
increasing the risk budget, or accepting more risk. Unused portions of the
budget should be returned to the sponsor.
Risk reserves or contingencies should also be monitored.
Reserves may be given to you in the form of money or time. In software
projects, time is a much more common form of reserve, in this case you will
allocate your budget to the project by buffering the work on the critical path.
For example, if you are given a month of reserve for a 9 month project, you
would allocate portions of that month to activities on the critical path that
were at risk, allocating the largest amounts of time for the activities most at
risk. You should alert your sponsor when you are likely to consume the budget
before the project is complete. Unused portions of cash reserves should be
returned to the project sponsors as the activities they were reserved for are
Risks should form a part of the reporting of the project.
You should be able to mine all the information you will need from your risk
register. You do not want to report on each risk to the project so need to be
selective when deciding on which risks to report on. You may set a threshold
for risks to put in your report, such as any risks with a PI score over 80, or
only risks with a high-high score. You can also restrict the risks by number,
for example only reporting on the top 6 risks to the project. The proximity of
the risk should also influence your decision on which risks to report on.
No-one will be terribly interested in a risk to the User Acceptance testing
phase of your project during project planning.
You should include a brief description of the risk event and
the strategy you have chosen to address it. You may also want to include the
status of the strategy and an evaluation of its effectiveness – has the
strategy been implemented? Is it proving to be effective? How has the PI score
been influenced? You may also want to describe triggers for contingency plans.
Risks are scored for probability and impact after
identification and that score determines whether the risk will be accepted or a
strategy devised to manage the risk, but what happens to the scores over the
life of the project? Does it make sense to assess a risk as having a high
probability of happening, even after an expensive strategy has been implemented
to reduce its probability? Of course not. The trouble is that at the outset the
probability and impact scores merely assess the probability of the event
happening and the impact if it does. After a strategy has been implemented that
is designed to mitigate the risk, you really can’t evaluate the PI score of the
risk event without evaluating the strategy you have implemented.
You don’t necessarily need to consider the impact of the
mitigation strategy on the probability and impact of the risk event, but you do
need to evaluate the effectiveness of the strategy periodically and use this
evaluation to determine if a new or additional strategy needs to be implemented
to mitigate the risk. Take our flu scenario as an example. You’ve taken the
precaution of having the entire team inoculated for flu because that was
identified as an effective strategy to manage that risk, but now a new strain
of virus is making the rounds. You need to ask the question: is the vaccine we
used effective against the new strain? If it isn’t, should we take any other
precautions to mitigate this risk? You may decide that the probability of a
significant portion of the team falling ill with the flu has increased to the
point that you need to make contingency plans for hiring contract programmers
to pick up the slack if more than 2 team members become ill.
The obvious way to factor in the effect the mitigation
strategy has on the risk is to re-evaluate the probability and impact scores
based on the project environment, including the risk strategy. The new
probability score of a risk using an avoidance strategy should be 0. If you or
the Subject Matter Experts re-assess the probability of the risk occurring at
more than 0, you will need to re-evaluate the effectiveness of that strategy
and determine if a new one is needed. You would factor in a mitigation strategy
in the same way and re-evaluate the strategy if the PI score increased. You do
not need to use this method in order to factor strategy effectiveness into your
scoring. Another method is to simply identify the strategy as effective or not
effective. Strategies that are replaced with new, more effective strategies
should be retired and any future work associated with them should be removed
from your plans. For risks requiring additional strategies to increase
effectiveness, simply add the new strategy to your plan. A third approach is to
capture a separate PI score for the strategy. Score the risk event without
factoring in the strategy, then re-score it factoring in the strategy.
identification, analysis, scoring, strategy definition, and updating functions
are cyclical in the risk management discipline. You need to repeat these
activities periodically throughout the project. Updating information about your
risks must be done using all the information available to you from the project.
You cannot update your risk scores assessing the project environment, risk
factors, the proximity of the risk event, and the effectiveness of the risk
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.