Understanding risks

Projects deal with change, and dealing with change is risky business. Researches
shown that numerous project managers are [not] prepared nor appropriately managed
risk. Are you ready to manage the risk that can plague your project and potentially your
business as well? When I talk about risk, I'm talking about things that haven't happened
yet. There's a probability of some sort of event occurring that'll have an impact on your
project. This impact could be positive when things go right, or it could be negative when
they go wrong.
With the significance of risk management in mind, let's look at the two major categories
for risk, positive and negative risk. Positive risks are often called opportunities, and they
still need to be managed. While we're not going to focus on opportunities, the logic and
the process of dealing with them is the same as for negative risks. It's just that their are
typically more instances of negative things happening in projectsthat have to
managed. So, we'll focus on negative risks.
Negative risks are events that could cause your project to be thrown off course. So, it's
vital that you pay attention to them. Whether you are dealing with positive or negative
risks, there are standard series of steps to follow when managing risks. First, you need
to identify the risks on your project. When you see something that will probably
happen, you should take action ahead of time, before the impacts are felt in your
project. Be proactive rather than being reactive, to appropriately determine when to take
action.
You need to take the second standard step for risk management and asses the
likelihood of a risk happening, and determine which risks you will address. Addressing
risk means taking action. Determining the actions to take is step three. Investigating
alternatives to steer your project through the least bumpy section of the road. You might
try to smooth out part of the road for a more comfortable ride. Using either alternative,
the idea for you is a project manager is to control how much your projects are exposed
by risk.
The last step in the management process is to control risk on an ongoing basis. This is
important to do, because risk change over time. So, you should constantly assess your
project for the likelihood of a risk happening, and it's potential impact. Understanding the
consequences of any risk will help you manage it. The last thing you want is for a risk to

effect deliverable's, your budget, or your quality standards when you could have
addressed it proactively.
As I help you examine risk in this course, keep in mind that managing risk doesn't
mean playing it safe at all costs. Any sort of change comes with a level of risk. It's how
you manage it that makes all the difference, which is why I will help you asses
approaches to deal with risks as they crop up. If you don't, they can literally create havoc
on your projects. Ultimately, project management is risk management. Managing risk
shows that you're aware of your challenges, and you've considered your options.
By clearly understanding your risk in the scheme of what you're trying to achieve, your
project has a greater chance of being delivered successfully.

Incorporating risk management into your project :

As a project manager, not a day goes by when I don't see something that can present a
risk to my projects. My primary advice to you is to deal with this thoroughly without it
consuming every moment of your day and driving you crazy in the process. Here are a
few survival tips for you to consider to help you do this. First, use risk to prioritize what
you do on a day to day basis. At the start of every working day, prioritize your tasks.
If necessary, re-prioritize your to do list so you can handle the riskiest things first. For
example, if you think that a project stakeholder is concerned about something, you
should prioritize your time to visit with them and try to ease their concerns. If you think a
risk is going to impact an implementation process, you should look at the process,
assess it and attempt to control it. If your project team admits their uncertainty over a
deliverable which will pose a risk to your project, you need to work with your team as a
matter of urgency.
Second, as part of your general approach to managing your project, include a
discussion on risk as part of your regular status meetings. Put it on as a topic to touch
on with your sponsor. Ask what risks they think are important and determine what they
think of your strategies to deal with risks. Ask for suggestions and garner their
support. Third, regularly gather together people as a team and assess your overall risk
status. You should include your customers and your sponsor in these discussions.

Consider having these risk assessment discussions at major milestones in your project
such as Stage-Gates. Having regular, open and frank discussions about risk will help
you manage risk as a regular course of doing business. Lastly, after each of these risk
assessmentdiscussions, create or update your overall risk plan. This plan details the
risks you are managing and provides an ongoing means of reporting what actions you're
taking and the status of each risk. The risk plan helps you ensure you're on top of what's
going with risk and your project.
Working these plans proactively can help you be cool, calm and collected in your risk
management approach. It treats risk management as an everyday event and an
essential part of keeping your project on track. If you ignore the whole idea of risk you'll
end up fighting fires. This is a tough way to spend your day. Jumping from crisis to crisis
can have a negative impact on your schedule, your costs and the quality of the products
you deliver. Not to mention the emotional drain it puts on you and your team.
And you'll be so busy putting out the fires that any process improvement
opportunities that could come out of risk would be largely overlooked. If you look and act
like you're in control of risk then you'll have a better chance of getting others engaged in
a sensible risk management approach. In addition, you will help your management
perceive you as a person with a balanced business approach to implementing your
project and dealing with the challenges that change brings to the business environment.

Understanding your stakeholders' risk tolerance :

Projects involve people, and people aren't all the same. Those differences can be even
more drastic When dealing with the threats of risk.So, you can hope that you will pick up
these differences as you go along, or you can be more methodical in understanding
your stakeholders. Personally, I recommend being more methodical. The critical element
to methodically understanding how your stakeholders will react to risk, is to understand
their risk tolerance. With that information, you can determine the level of effort, focus,
and attention that's required in your risk management approach.
There are two components to understanding risk tolerance, the people element, and the
appraisal element. Let's take a look at the people side of things. First, be prepared for
the fact that your stakeholders, sponsors, and the people on your project team will each
tolerate risk differently. Some people are prepared to jump out of airplanes for

fun. Some people are cautious walking down stairs. And there's everyone in
between. You need to take this into consideration when you talk about risk in your
project.
The key is to always listen carefully as you discuss elements of your project. The
second thing to keep in mind, is that people have a natural tendency to want to protect
scope, time, or money when these triple constraints are discussed. Which way they lean
will depend upon their prior experience, the organizational culture they're used to, and
the particulars of your project. For example, one organization I know of is involved in
yearly industry trade shows.
At these shows, the company is expected to display new products. If they don't have
new products ready to show off at the trade shows, it'll impact their business. A project
stakeholder in this instance will be totally focused on time constraints, because it is
critical they have products ready to demonstrate at the trade show. Risk impacts to cost
and scope are a much lower priority for them. In another scenario, which
demonstrates a different risk tolerance, there are regulated industries where scope is of
critical importance.
Your project might be fulfilling commitments that are legislated by law. Compliance and
scope considerations, along with on-time implementation to meet legal requirements will
be top of mind for your stakeholders. Cost might take a bit of a back seat in these
instances.While considering people's risk tendency, you should also take the
second risk tolerance component into consideration. Performance appraisals. How is
your stakeholder being appraised by their manager? What are they being told they're
doing well, and what do they need to improve? To obtain this information, it is absolutely
fundamental that you post critical questions, and listen to the answers you receive.
Without directly asking about their personal performance appraisal, you can ask
them "What outcomes are you most excited about, "and what potential negative
outcomes most concern you?" If you have these candid discussions about their
expectations and concerns early on in the project, you'll get a feel for which project
constraints they'll want to focus on. There's usually a risk/reward balance in any
organization, and an underlying culture in the willingness to accept or manage risk.
Some entrepreneurial organizations will take significant risk, whereas more conservative
industries will want to mitigate their risk, and they'll expect you, as a project manager, to
conform to their style. The techniques I've discussed here can position you well to

understand how you need to proceed, relative to project risk. The more you understand
your organization's position on risk, the better you'll be able to successfully focus your
risk management efforts, and prioritize risk activities.

Understanding risk-identification methods :

You cannot fix what you don't understand. Moving forward on a project without
performing appropriate risk identification is like heading out on a hike in the wilderness
without a GPS or a map. It is easy to get yourself quite lost when you encounter the
unexpected. Risks represent the unexpected in my hiking analogy. Different types of
projects have different risks, and if you don't know your risks, what the probability of
them occurring, and the impact they'll have, it is impossible to manage them effectively.
So, conducting an appropriate risk identification process is crucial. Here are three risk
identification approaches that I recommend for use on your projects. The first approach
is to hold a brainstorming session, which is also known as a risk workshop. As they say,
several heads are better than one, and this holds true when it comes to identifying
project risk. For these workshops, however, don't limit yourself to your project team. It's
a good idea to involve your key stakeholders, sponsor, and maybe other project
managers in this session.
To make these brainstorming sessions more effective, it's important that you participate
in the workshop with a checklist of questions you want answers for. For example, is your
costumer organization use to change? Are there external factors that will impact your
project? Does a lack of a particular skill in the organization present a risk? What are the
lessons learned from previous projects? In this session have everyone come up with
their top five risks, and remember, that through this exercise, traditional brainstorming
rules apply.
Capture all the potential risks. There are no bad ideas. You'll sort through them
later. The trick during the brainstorming session is to think at a high level so you get a
broad set of risks. If you need some ideas for the sorts of risk areas to cover, I've
provided a checklist of questionsthat you can download if you're a Lynda.com
member. The next risk identification method I recommend is to look to industry specific
riskcategories you'll need to cover.

For example, in the construction industry there are safety risks. In IT there are
information requirement risks, and risks involving the creation of solutions that are too
complex. To help, most industries have associations, online resources, and risk
tools that you can leverage. Use them to identify risks. Examine your project against
others in your industry. You might also find resources through other project managers
involved in your industry. The Project Management Institute also has project
management standards for projects in government, software, and construction that are
useful.
The last technique to consider for risk identification is to look at your work breakdown
structure, or WBS, and identify risks by tasks or group of tasks. As you will use the tasks
in the WBS to deliver your projects, using the identified tasks in the WBS can trigger risk
ideas that you would have otherwise missed. This is a good, systematic last step to help
ensure you have thoroughly considered potential risks that may plague your project. You
can't address risks you haven't identified.
Launching your risk management approach with thorough and well considered risk
identification practices will help ensure you manage your project in a controlled,
proactive manner.

Categorizing and consolidating risks

There is benefit to having a large number of risks, identified for your project, but
managing an extensive number of risks, can be awkward and cumbersome. With lots of
groceries, it is good to sort things out. Place items in separate bags for the freezer,
fridge, and pantry. Be organized when you get home. The same pertains to risks on
your project. How will you ensure your risks are well organized, so you can manage
them? Categorizing risks for your project is a great way to ensure you are well
organized.
Let me share some typical ways to categorize risks, and some tips for using those
categories wisely. My first suggestion for categorizing risks is by looking at the triple
constraints of time, scope, and costs, as well as quality and resources. Look at how
your risks may impact your project, and identify any budget, schedule, personnel, and
requirements risks. Try to find any risks that have some common causes. For example,

one common area for risks might be that you don't have enough people, or you lack
people with the relevant skills.
You could have a substantial list of risks, but in many cases, they may all tie back to this
category of people and skills. A second way to categorize risks is by business
areas, such as external market risks, or shifts in business strategy. This can be very
helpful, when you are dealing with your client, and the risks they may bring to the
project. Taking this approach can enhance the perception, that you are managing the
project with your client, and their needs in mind.
It can also help engage your client, to ensure you manage their risks appropriately. A
third way to categorize risks is by technical topics.These might include design and
development problems, testing and maintenance risks, and technical uncertainty. Or,
you can use technical product risks, such as a requirement potentially being too
complex, or other risks, such as managing external vendors. Fourth, you can utilize an
integration risks category.
Integration risks surface when you are working on your project, and there are many
other things happening in the organization. If you have nine other projects targeting a
particular business area, this might signal a need to address integration risks. When
solutions need to be brought together. As all the changes brought about by these
projects may need to be coordinated, significant risks could surface. This is a risk topic
that is often overlooked by project managers. Although these are common risk
categories, you might find others are more usefulon the specific projects you manage.
No matter the categories you use, here are a few tips for managing risks with risk
categories. First, don't hesitate to revise your risk categories if it's helpful. As the project
progresses, you learn more about the risks that are substantial. As a result, more
relevant categories may surface. Some risks may blend into other categories, depending
on the stages in your project, so keep your eye on the ball. Continue to identify risk and
risk categories as the project unfolds.
You can do this as your regular team or status meetings. My second tip is this, keep
your list of categories short and simple. Try to avoid a multitude of categories, so you
and your team don't have a hard time keeping them all contained. Lastly, be as succinct
as you can when assigning risk categories. Package the risks, so there's a common
relevance across different areas of the project that you, your project team, and other
stakeholders, easily understand.

Using well crafted risk categories can help you manage your project risks more
easily, but it also helps your stakeholders to see the risks for what they are, and helps
you make better decisions to address them.

Writing risk records

A large number of risk management plans get thrown in the trash with
exasperated project managers and sponsors screaming things like"Depite our work, this
risk plan is useless!" The difference between risk plans that work, and those that do
not, usually comes down to one simple element: the way risks are written. Do you know
how to write appropriate risk records? I want to share with you the proper way to prepare
a risk record.
As a means of discussing the proper way to draft your risk records, i'll share a story
where risk records were written inadequately. An airport company has identified a risk
that their fuel trucks may be unable to make it out onto the tarmac to refuel the
airplanes in a timely manner.This will cause the planes to be delayed. No specific cause
for the delay in the fuel truck arrival is discussed. So the project manager and
sponsor assume that the risk revolves around the fuel trucks having a mechanical
failure.
As a result, they use a single risk record, and jump to a single risk mitigation
action. They decide to have more fuel trucks available, so that regardless of a
mechanical failure in one truck, they'll always a truck ready to refuel the aircraft. This
sounds like a reasonable risk mitigation strategy. However, during the next month, the
fuel truck drivers go out on strike. The airport management company could have all the
fuel trucks in the world, and none of them would be able to show up.
There's simply no one to drive the trucks. What went wrong here? The team only
considered one cause for the risk ocurring, and their risk records were inadequate to
service other possibilities. So you don't end up like our unfortunate airport
managers, let's take a look at the formula for writing effective risk records. First, adopt
this simple structure. A properly structured risk record is easy as pie.
Probability of impact as the result of an event. Add the cause of the event, and you have
a perfectly useful risk record. Back to our airport example. The appropriate risk record

would be there is an x percent chance that the fuel truck drivers will go on strike causing
the fuel trucks to be delayed in refueling the aircraft. This will increase costs by y
dollars per flight due to delays.
Second tip for writing risk records, don't hesitate to have multiple risk records for the
same risk. In each record, you outline different causesbecause the mitigation action will
be different. In my airport management example, writing multiple risk records to
address different causes of the fuel truck delay risk event would have been a valuable
thing to do. Another risk record, similar to the one I just shared with you, could be written
to address the situation they did think of when a fuel truck mechanical failure occurs.
Last, my third tip for writing risk records. Don't write the records and leave them to
collect dust. You need to be continually going back to your records to see how the risks
are tracking. As the project progresses, your risk may change. Specifically with
probability of occurring,and potential impacts. You may also surface other potential
causes for the risk to occur. Keep your risks current, and you will always be on top of
things that could derail your project.
You might think it seems a bit redundant to write multiple records for risks with the same
impact, and keep reviewing them all the time.However, you will want to
understand when you need to act to address risks and ensure those actions will be
useful. Starting with specific and structured risk records makes your risks relatively
easy to review and update. With well crafted risk records, your risk management plan
can be pragmatic, inefficient, and a well crafted risk plan proactively addresses the
problems the can plague your project which can be the difference between
successful delivery of project outcomes, or a project that gets cancelled before it
delivers any value.

Building a risk register

So you have a collection of items that you want to keep track of and care for
appropriately. First thing you would do is find a place to keep them, right? Many project
managers draft a set of risks, but create a problem for themselves because they don't
create a common and accessible place to keep and care for them. To prevent yourself
from having this problem on your projects, it is important to create a risk register. Let's
examine the data elements you include in a rich useful risk register.

First and foremost, the risk register captures details for the risks that have been
identified at the beginning and during the life of the project.It also includes the high,
medium, or low grades in terms of their likelihood of occurring and how seriously they'd
impact your project.Second, you include the plans for treating each risk, as well as the
costs of any treatment strategy, who's responsible to execute, and the results if that
strategy was executed.
Third, your risk register should identify the owner of the risk and how the risk is tied to a
task or series of tasks in the project schedule. Risks typically manifest themselves in the
execution of tasks or a hurdle to executing a task appropriately. As a means of tracking
your risks appropriately, and understanding when they might occur, or the risk possibility
is past, having risks tied to tasks is a useful management practice.
Now that I've outlined the data to include in your risk register, let's talk about best
practices for making the risk register as pragmatic as possible. First, use your risk
register as a risk focus task or to-do list. You should have statuses related to each
risk and allocate action items to each risk. You should also assign resources to each
risk-related action, so it's clear who's responsible for managing the risks.
My second best practice to share, ensure you understand the in's and out's of your
project before you build and publish your first risk register. This allows you to collect the
knowledge and understanding of your key stakeholders and understand how they want
to manage risk. It also helps to know where to get the information you're going to
need to ensure your risks are relevant. Third, sort the risks in your risk register by
probability and impact to your project.
You'll be dealing with a number of risks in a typical project. However, you do not need to
share every risk with your sponsor and senior stakeholders. They will probably only be
interested in risks that they have to address themselves. Having your risk register sorted
appropriately means you can easily share the top risks with senior stakeholders. One
last best practice, make your risk register complete,but keep it brief and to the
point. Your risk register should be much more than a list saying you have 20 risks.
Ensure it can quickly convey essential risk information and what you're doing about the
risks. Also, make sure it's updated at least after every status meeting. Your risk register
will serve as a great tool if you are vigilant by including and maintaining the right
information throughout the project. It brings your risk management plan to life and gives

you a concise crisp summary of the status of all the risks on your project at any point in
time.

Performing qualitative risk analysis

Considering the number of potential risks that could occur on any project, every project
manager faces a troubling dilemma. How can you manage a project without
spending 120% of your time managing all of the possible risks? When will you ever get
a chance to perform the numerous other responsibilities you're expected to fulfill? The
answer is to perform a qualitative risk analysis to filter and prioritize your risks.With
qualitative analysis, you do this based on a quick, high-level assessment of their
probability and impact of actually occurring.
I will share the simple steps to use, so you can do this quickly and efficiently. First, you
need to determine a straightforward assessment for each risk's impact. One way to keep
it simple is to work out what would make something high, medium, and low risk for your
project. Would it genuinely blow out your budget, or delay your project
substantially? These should be treated as high impacts. A difficult, but manageable
situation would constitute medium impacts.
If something would end up being nothing more than a bother and easily
manageable, low impacts. Second, you do the same for probability.Just keep it simple. It
really doesn't matter if it's not finer in detail than high, medium, and low. So, if you
believe the probability is 80% or greater, call the probability high. Over 40%, medium
probability. Less than 40%, low probability.
The point of the whole qualitative analysis exercise, is to get a high level ranking for all
your risks. It should be quick. It's just a filter to help you work out which risks to spend
your time on. Now, the last step. Once you have gone through all the risks, and written
down the ratings, sort the results. This will give you a high-level reference for which
ones need to be examined further, and which ones can be left for a while.Just make
sure you keep this initial master list of risks.
Keep reviewing the list throughout the project life cycle, to make sure all low risks stay
rated as low risks. Here are a few tips for ensuringyour qualitative risk analysis is

efficient and effective. First and foremost, don't make it too complicated. Don't be too
fine in your determinations for high, medium, and low risks. Remember, you're just trying
to regulate the effort you go through, not chase every risk. You just want to know where
to focus your risk management energies.
Second, to help everyone on your project team understand your qualitative
analysis, draw up a table like this one, known as the three by three risk matrix. It has
probability on one axis, and impact on the other. By recording your findings in this sort of
format, you can easily see the risks. Last, after you complete your three by three
matrix, look at where your risks lie. If there are a large percentage of medium-medium
risks, ensure you didn't put them into that segment by default.
Maybe it's out of habit. The question you need to ask yourself is, "Did I really label the
risks qualitatively, "in relation to the others?" Basically, you're going to have to
address your high-probability, high-impact risks first. These have to be your
priority. Then you'll look at your risks rated high-medium, and medium-high. You may
also consider your medium-mediums. For all of your lows, you're probably not going to
do much at all, and that's okay.
If you go through the qualitative risk analysis process quickly and efficiently, you are well
on your way to making your risk management approach manageable, and well-suited to
the needs of your project.

Performing quantitative risk analysis

Project risks can be like ghosts, they can haunt you if you don't address
them. Constantly waiting to catch you when you're distracted, risks need your attention
before they cause chaos on your project. So, how do you know what risks to
address and when you need to purge them from your project? First, after you've
performed a qualitative analysis, you then conduct a quantitative risk analysis on your
most substantial risks. Quantitative Analysis is the process that guides you on how
much you can spend to address a risk.
For example, you don't want to spend 10,000 dollars to address a risk that will cost you
5,000 dollars. I want to share with you a few steps that you can take that will help you
insure you're addressing the right risks on your project. The first step is to look more

closely at the probability of each risk occurring. Because we're looking for a more
refined estimate in this quantitative analysis stage, I would assign a probability in
increments of 10. So ten percent, twenty percent and so forth.
The second step is to estimate the cost to your project, or your organization, if a risk
came to fruition. The dollar values you choose to estimate the cost would depend upon
the overall budget of your project. If you were managing a project whose total budget is
100,000 dollars or less, then I would estimate the cost in increments of 5,000
dollars. Half a million or less, then I would use estimates in increments of ten thousand
dollars. For one million or more of total project budget, I would use increments of 50,000
dollars.
If you're managing multi-million dollar projects, then you might want to conduct more
detailed approaches to estimate the impact of risks.The third step, is to multiply your
estimates for the probability and cost impact and sort the answers so you have a guide
to determine what your most important risks are that you should address. For example,
if Risk A has a probability of occurring of 70 percent and an impact of10,000 dollars, the
resulting answer would be 70 percent of 10,000 dollars, which is 7,000 dollars.
If Risk B had a probability of occurring of 30 percent but a cost impact of
150,000 dollars, the resulting importance ranking would be 30 percent of 150,000
dollars or 45,000 dollars. This method suggests Risk B be addressed before Risk
A. Remember, this is only a guide. You should look at each of your projects risks to
determine what makes sense. The last step, is to take your most important risks and ask
"If I was going to "address this risk, how much would that cost?" You certainly should
spend an appropriate amount of money to mitigate a risk that isvital to your projects
success.
There could potentially be a number of ways to address a risk however. The greater the
potential impact, the more analysis you may want to perform to investigate alternatives
to relieve your project of the risk. The thing you should remember, is that quantitative
analysis can be a bit of a balancing act. You want to dedicate enough time so that
you get a thorough analysis but not too much time so you get bogged down with your
estimates. Allocate your time based on the potential impact of each risk.
This will give you the information you need and let you get on with the job of managing
your risks. Performing a quantitative risk analysishelps you ensure that you have control
over the elements that can adversely impact your project. When you have those adverse

elements under control, you are well on your way to ensuring your project can be
delivered with integrity.

Assessing and prioritizing analyzed risks

The science of risk management is fairly straightforward. Prioritize your risks by
potential impact and manage your most significant project risks. Many project managers
do this and believe they're on the right track. And they usually are, most of the time. The
problem is stakeholders don't always think scientifically. To effectively manage risks on
your projects, you need to consider stakeholder risk sensitivitiesbefore you can say your
risk analysis is complete.
It's important to remember in any risk analysis that your stakeholders, sponsors, and
project team may all tolerate risk differently. In cases where your stakeholders are very
sensitive to some types of risk, complete your risk analysis by incorporating that into
your risk management. Here are the steps you can take to make sure you and your risk
sensitive stakeholders will be aligned when it comes to managing your project
risks. First, split your risks into impact type.
Time impacts, scope impacts, and cost impacts. Once you've done this, consider your
stakeholders' or sponsors' tolerance for these three types of risk. Second, consider reprioritizing your risks to ensure the impact type with the lowest stakeholder
tolerance gets a high priority.By understanding the sensitivities of your stakeholder and
sponsor, and adjusting the way you prioritize things, you'll have an easier time managing
risk on your project.
It shouldn't be difficult or time consuming. The addition of stakeholder priorities to your
risk analysis simply gives you a final prioritized risk list. The third step in refining your
risk analysis is to consider your potential risk treatment actions and their costs against
the actual costs the risk would add to your project, and most importantly, the impact to
the perception of your stakeholders. A project manager and sponsorrarely have a large
fund to mitigate risks.
As a result, you need to decide how to allocate this prudently. If you only have
$200,000 of risk treatment funding available to manage risk on your project, you want to
have the risks sorted appropriately and allocate the $200,000 to the risks that should be

addressed. This should consider the overall financial impact of the risk, the cost of
addressing the risk, and the risk tolerance of your sponsor and senior
stakeholders. Once you've done this, you are ready to take the fourth and final step to
completing your risk analysis.
Share your final prioritized risks with your sponsor. Here are some final tips as you use
these steps to finalize your risk analysis. First, risk prioritization involves a lot of
judgment calls and estimations. Don't be afraid of going forward without a lot of
facts. You rarely have solid facts when it comes to risks. Next, it is important that you
communicate your estimates and assumptions and consider those of your sponsor and
stakeholders.
Although there is science involved, most good risk analysis exercises involve a healthy
dose of art in the form of intuition and frequent communication. Lastly, fault on the side
of being inclusive. Involve as many stakeholders as you can. Not only will you produce a
better risk analysis product in the event an unexpected risk does become an issue, you
won't be alone when answering the "why didn't you think of that" type questions that
may be raised by senior leaders.
There are a number of steps to take when identifying and analyzing risks. But engaging
in methodical effort is worth it. As risks coming to fruition as issues are likely to seriously
impact your project, leading the project team and stakeholders through a practice of
diligent risk analysis, you will be well positioned to manage the good and bad ebbs and
flows of your project.

Common risk responses

All the risk analysis in the world will do you no good if you don't ultimately have a plan to
address your risks so the impact on your project is minimal. The fact is, however, that
most project managers don't fully consider all of the risk response alternatives available
to them. To ensure you don't fall into the trap of considering only a single solution, and
moving on before you should, here are the most common risk response types, all of
which should be considered for each important risk on your project.
The first risk response approach is to avoid the risk. You eliminate it altogether. Maybe
you remove it from scope. Maybe you change the timing of an action so that you dodge

the risk. For example, let's say you're working on a project where you're designing and
building animportant component of a large machine, and let's say your project team
believes your current plan of making the component out of fiberglass might be
inadequate because the component needs to be rigid, but the fiberglass might be too
flexible.
So instead, you and the team decide to make the component out of steel. You've just
employed an avoidance treatment technique. You've avoided the risk of using fiberglass
altogether. The second risk response is transference. You move the risk to someone
else. Examples of this are taking out insurance that something bad could happen, kinda
like when you get insurance on your car. The impact of the risk istransferred to the
insurance company.
You don't totally eliminate the impact because you still have to pay the deductible, and
the impact to your project is something you'd still have to deal with. So, the impact of the
risk isn't zero. However, it's significantly reduced. Typically, with transference, you'd
get some relief from the transferee, such as a payment from insurance. The third risk
response is to mitigate the risk. Let me show you how you can reduce the probability of
a risk occurring in this first example.
Let's say you're working on a project where you're depending on vendors to supply you
with parts. If you have a vendor that's at risk of being late, you may need to have a
mitigation strategy. One approach is to put a contingency contract in place with a
second vendor. You may spend more, but the alternate contract should help you ensure
you get things done on time. Of course, the risk of the alternate vendor being late may
still happen, but overall you're driving down the probability of the risk occurring.
In a second mitigation example, you can reduce the impact of a risk
occurring. Considering the scenario we discussed, when you're depending on a
vendor to deliver your product on time, you can create an alternate project
schedule, where you perform an installation later involving the parts you're receiving
from the vendor. This might not be ideal, but if the supplier is late, the impact on your
project won't be as great. In addition to avoidance, transference, or mitigation, there is
another response option.
You can accept the risk. This means you do nothing to avoid the risk. It's a common
response for low-priority risk events. You simply accept the risk as is. If the risk event
occurs, you just absorb the impact because it's not worth the time and cost to address

it. The important thing about any risk response is that you go through your options
carefully. By responding to risks, you're enhancing the opportunities andreducing the
threats to a project's objectives.

Determining the appropriate response

The average project manager considers responses to each high priority risk. Better
project managers look at each of their risks, and consider all four types of risk
response: avoidance, transference, mitigation, and acceptance. The best project
managers further define their response strategy by considering three other factors in
choosing the appropriate response strategy. The first consideration is the
tradeoffbetween your triple constraints of time, scope, and cost.
As the quote goes, "You can spend money to save money." But that is not always the
best approach. For example, if time is your number one driver, you may use cost to get
around the time constraints. This could involve using additional resources to make sure
activities are done on time. Or you could reduce the scope or functionality of your
products, to make sure you deliver your project in the desired time frame. If scope is the
number one priority, you may have to incur additional costs, or consider adding time to
your schedule.
You should consider trading other than the risk-impacted triple constraint element to
determine the best alternative. Second consideration when investigating risk
treatments is to determine if your risk response actually adds other risks. If so, are they
manageable? For example, as a means of ensuring you get the right skills when you
need them, you may contract with two specialized technical skill providers. Adding a
second vendor may reduce your risk of getting skills on time, but may add other risks,
such as contract management risks, if you have never worked with that vendor before.
The fact that a risk response adds other risks is not uncommon. You just have to be sure
you evaluate the nature of any new risks you may introduce to your project with your risk
responses. The third consideration I want to share, is to examine when you have to
make the decision to execute that strategy. Let me explain this concept. Let's say risk
response option A is going to take you two months to put in place, and will cost $4,000
to execute.

You will likely have to decide to execute this response strategy long before you can
tell for certain that the risk will come to fruition. In contrast, risk response option B will
cost $4,500, but you can execute it immediately before the risk occurs. If both of these
response options have an equal chance of reducing the impact of the risk, you might
choose option B over A. This is because option B, although slightly more
expensive gives you a greater chance of spending nothing at all on a risk response, if
you can determine if the risk won't come to fruition at all, and not need a response.
It gives you the advantages of not having to play your cards too early. The last
consideration is the speed with which you can get permissionto execute a response
strategy. If two options are similar in their cost and effectiveness to reduce the risk, it is
usually best to choose the response action you can execute more quickly. This gives
you more flexibility in determining if and when a response is needed to a given risk. You
can take more time to be more decisive, or collect more data before spending additional
funding.
So, financials are not the only consideration when choosing your risk response
strategies. Considering other factors that allow you more management flexibility, or the
ability to trade off less sensitive project constraints to help others, is a great way to
demonstrate your prowessin considering alternatives for treating your project risks.

Building a risk-response plan

With all of this work on risks and appropriate responses, how do you ensure it doesn't all
fall through the cracks when the day-to-day pressures of deadlines, heaps of e-mail and
stakeholders wanting attention flock to your desk? The answer is you create a risk
response plan. A document that not only captures your risks and analysis you've
performed, but actually informs your actions going forward. Let's talk about the
fundamental items you should put into your risk response plan.
First and foremost the risk response plan lists your risks, including identified risk
causes, descriptions and potential impacts, along with a triple constraint element or
elements affected should the risk occur. Second, include your qualitative and
quantitative analysis results and your risk response plan for each risk. You may include
a primary and secondary risk response plan if more than one is being considered.Third,
if executing your risk response plans include leveraging contingency reserves or if they

include contract-related actions you'll need to take with your vendors you should note
these as well.
After these fundamentals are compiled in your risk response plan these additional
elements can turn your risk response plan into a powerful control document. The most
significant item to add to each risk in the response plan is the timing for when you want
to either A, assess the status of the risk of B, execute a response action. These can
then be added as tasks in your project schedule and assigned to a specific individual.
Let's say you have two technical experts who are due to start work at a certain point in
your project, and they're currently working on another project. You see the possibility of
your experts other project running long and have noted this as a risk. In this example
you should note twotiming-critical actions against that risk. When to check the status of
the other project to determine if your technical experts will be available,and when you
need to go to the marketplace to contract other experts because the ones you planned
on won't be available.
The next significant item to have in your risk response plan are status dates for your
vendors, or to check on products from areas not under your control. For example, when
I was moving from the US to a work assignment in Australia and having my household
goods sent there by sea, I didn't know when I packed the container whether it would go
from LA to Sydney directly or via Singapore. I had to monitor the forecasted delivery of
my shipping container. True to form, it was shipped through Singapore and took longer
than expected.
I used this tracking to ensure I did not rent an apartment too early, before I
could practically occupy it with my furniture. Building a risk response plan is going to
take some work on your part, but the last thing a project needs is a weak, unmonitored
risk response plan. By ensuring your plan is robust and helps you track the actions
required to monitor and execute responses against risk, you can dramatically reduce the
impact of risk on your project.

Understanding risk triggers

Protecting your project is not all that different from protecting a National Park. The park
rangers construct towers to keep an eye on the landscape, looking for signs of

trouble. This works well, because where's there's smoke, there's usually fire. You should
do the same thing for your project. And it rarely requires timber or construction skills. As
smoke is the warning sign for fire, I suggest you spend time thinking of what is called
"risk triggers" early warning signs, like smoke, that indicate a risk is about to come to
fruition.
It's a sign that you should be preparing to take action. Let's look at some common types
of project risk triggers. The first type of risk trigger is one that gives you an immediate
indication that a risk is happening. In your project environment, you may have technical
experts that are going to join your project at some point downstream. You request these
technical experts to start attending status meetings one month before they are due to
start so they can hit the ground running and know what's happening on the project.
The time for them to appear comes around, you remind them of their commitment and
they don't show for the status meeting. This is a likely risk trigger that other priorities
might put the experts participation in your project, at risk. The second type of risk
trigger are forward indicators. Unlike smoke, which indicates a fire is happening now,
forward indicator risk triggers are signals, something's going to happen at some period
of time in the future.
Tuna fisherman provide a useful example of a forward indicator risk trigger. Tuna
fisherman have risk triggers tied to the temperature of the water at different times of the
year. They understand if it's going to be a plentiful fishing season depending on the
water temperature.They've studied it over time. They can plan on X amount of
revenue and Y number of fisherman they'll need for a voyage based on the water
temperature which indicates a future projected tuna population they can catch.
Risk triggers can be varied and typically involve people's behavior, unexpected schedule
changes or task deadline failures. They can show up as defects in early versions of
products being produced. No matter the type or variety, here are some hints for
determining and leveraging risk triggers. First, do some research. Potential sources for
risk triggers include: Past risk logs, post implementation reviews, and risk and issue logs
from past projects.
Second, once you've determined reasonable risk triggers, empower your team to search
for them. The reality is, that while you have to keep your eye on things, you can't be
everywhere at once. You have to empower your project team so they understand the
risk triggers too. After all, they're often the subject matter experts who are living and

breathing this everyday. So get them to staff the watchtowers and look for smoke along
with you. Third, plan on what you're going to do when you spot a risk trigger.
The whole idea of utilizing risk triggers is to enable you to react quickly and
decisively. Involve your sponsors and key stake holders in the risk trigger process, so
they know what you're going to do should some nasty smoke appear on the horizon. By
understanding risk triggers, communicating them to your team and your
stakeholders, you can spot and react to risks much more quickly. Rapid and decisive
responses to risk triggers means you'll be more effective in the management of risk in
your project environment.

Incorporating risk management into reporting

You can perform a lot of a great work on your risk management, and it can all go for
not if you do not communicate it well; however, communicating something
as comprehensive as the risks on your project can be a far reaching and tedious
task. Incorporating risk management into your regular reporting approach is a great way
to both bring your risk management to life and keep a bit of balance in your own
life. Here's how: First and foremost, put a risk section into your regular status report.
This is where you talk about what you've accomplished, deadlines you might have
missed, and tasks you are going to be tackling within the next reporting period. It's
natural that risks can affect all of these so should be included in your status. As status
reporting should be concise, consistent, and frequent, so should your references to
risk. By documenting risks in your status reports, you're doing several things,
including, communicating the risks to your project team, keeping your sponsor up-todate on the true position of their project, preparing stakeholders for any corrective action
you may need to take, and shows you're planning ahead.
A second way to incorporate risk management in your reporting, is to use your project
schedule. It's a good practice to associate risks with tasks. Using dates from your
project schedule, you can create sections in your schedule or risk response plan
for risks that have been bypassed, risks that you have to be aware of in the
moment, and risks that you will be looking at in future periods. A third technique is to
regularly distribute significant parts of your risk response plan.

Highlight the risks you are currently focused on and provide the details to
stakeholders that can help you detect and manage them. This is particularly helpful if
you need to provide more detail on your risks or your organization has a
particular sensitivity to a certain risk. For example, if your organization is
particularly sensitive to schedule risk, you might have a separate detailed report to say
when you're schedule has varied from the plan. You could include details as to why it's
varied, and any specific actions you are planning that will get you back on schedule.
During times when there are lots of schedule risks, your risk response plan extract can
go even further. You can detail the risk triggers and the actions to take if they're
noticed. It's also useful to make note of any meetings or communications that happen
around the risks, even like a phone call or email. This basically highlights how
you're managing the risk through the process. With concise and focused risk
reporting,you can help your sponsor and key stakeholders make very clear and
informed decisions.
You can also help your project team help you with appropriate and timely risk
management. Put the effort into your risk reporting, and you'll likely be able to suggest
the best way to enhance or avoid most any risk that may surface on your project.

Deciding when to execute a risk response

As the Kenny Rogers song goes, you gotta know when to hold 'em, and know when to
fold 'em. Know when to walk away, and know when to run. So it goes with risk
responses. Determining the right response takes some work, but determining when to
pull the trigger and spend time and money on a risk response can be a tricky venture,
given all the dynamics of today's projects. Project managers who understandwhen to
execute a risk response and when to hold off, are the ones who always appear in control
of their projects.
There are three ways to approach the execution of the common risk response actions of
avoidance, transference, mitigation, and acceptance. The first execution approach is to
execute proactively. For example, in a component design and assembly project, you
may believe there's a risk in making a Telephony emponent out of fiberglass because
you may need a solution that's going to be more rigid. So, using steel to make the
component has been proposed as a response action.

You can address this risk proactively by spending the money and time to have sample
fiberglass components manufactured ahead of time.From these samples, you can
determine if the rigidity risk is viable. This gives you assurance, and is proactive, but can
be very expensive in some project instances. Still, it could be money well spent. The
second option is to execute a response action, immediately after an assess and respond
approach. You make an assessment based on testing the manufactured parts at the
prescribed time in your schedule, and then you decide on the immediate actions to
take, based on the results.
If the fiberglass works well, you do not spend any money on a response action you don't
need. If the risk is valid, and the fiberglass is too flexible, you have to spend the
money to correct the situation by using steel and recover any delays in your
schedule. The third option when deciding on a risk response is to be reactive. You
change something after the impact of the risk has been felt. If the fiberglass proves not
to be rigid enough once we deploy it, then we can correct it after installation.
This will probably involve some other testing processes, and coming up with a corrective
action like reinforcing the fiberglass parts in some manner. It can also upset your client
and your reputation. In this case, we've let the risk pan out and then reacted to it. It is
not usually a very good option, but can be considered for very low probability or low cost
risks. Basically, what you're trying to do is think about the right balance between your
triple constraints, time, scope, and cost.
Being proactive and doing something ahead of time typically gives you the best end
result when it comes to risk management, but it can have drawbacks in costs
and, potentially, time. Going down the assess and respond route could cost you nothing
if it works. But if the work isn't the level of quality you need, it could cost you scope and
time when you least need those challenges. Being reactive could impact all three of your
triple constraints. In our example, by trying to reinforce the fiberglass, it could mean
you'd have to perform some redesign of the entire component, and this probably would
be expensive.
Whatever the case, it pays to analyze your risks before deciding which way to execute
your response. Assess the impact of the risk and really look at how much control you
need to put in place and when to get the optimal risk management result.

Adding and deleting risks from the plan

It is a very tempting and refreshing thing to do like striking items off of your to-do list at
the end of your week. Striking risks off your risk planthat did not come up and bite
you can be liberating. As liberating as that can be, I recommend you carefully consider
how you manage the removal or addition of risks to your plan. Here are some of my
thoughts on how best to make adjustments to your risk plans. First, clearly demonstrate
when a risk has been bypassed on your project.
It's good for your sponsors to know that something which was a concern is no longer a
risk. If they can see that in black and white, they'll have even more faith in your ability to
competently manage the project. Don't delete them however, because when and
how the status of each risk was communicated is useful information to refer to in future
projects. In addition, having carefully tracked your risks and what is communicated
about them is useful if there is a change to your sponsor or key stakeholders.
They can bring new or different perceptions about things that can impact your
project. Next, I want you to ensure you capture close calls in your risk plan. Sometimes,
risks do not become issues because your project team performs extraordinary acts or a
last minute decision by your sponsor or significant stakeholder saves the day and
circumvents the risk. These are close calls. You will want to ensure that information is
captured completely and in detail for these close calls, as they are very important risks
to remember.
They are likely to occur again on a future project. Third, if you or another stakeholder
perceive a new risk exists, capture it immediately. It's important to document newer
additional risks, even if they may be deleted in a short period of time. It'll help you to
pinpoint what happened and did not happen, and which risks you should consider in
future projects. It also helps you ensure you have all of your bases covered and are
perceived as listening to your stakeholders.
Fourth, it is important to add risks that you didn't originally consider, either because of
new news or you just overlooked them. Adding risks that you hadn't originally
considered, even without the changes we've discussed here, is the other project
reality. Once you complete tasks and you have your task output, new risks can pop
up. You should always take the time to add these to your project documentation. This

helps provide you with a master list of risks that you can refer to on any project you
manage in the future, in any scenario.
Fifth, modify your plans and project tasks as appropriate to accommodate new or
altered risks. New risks that are considered can help you and the team mindfully
complete tasks or consider other approaches as appropriate. Being proactive with new
risks can also lead to the reassignment of contingency money you haven't spent. Adding
risks to your plan can help you attract these funds appropriately. Your risk plan can be
the most valuable permanent record of what transpired and did not transpire on your
project.
As such, it is a valuable document that can prevent you and your project management
peers from having to relearn painful lessons.Capturing more detail versus less in my risk
plans has always served me well, and it can also save you pain and heartache.