• It is important to remember that risks aren’t

all bad. A risk is simply a moment of

uncertainty. You don’t know for sure what will
happen, and the potential outcomes can be
positive or negative.
• Risks can be uncertainties in scope, schedule,
cost, or quality. The point of creating a risk
management plan is to identify those
moments and create a system to maximize the
positive impacts (and mitigate any potential
negative ones!)
• For one thing, studies have found
 that we overestimate our ability to
influence events that are heavily
determined by chance. In other
words, we think we have more
control over uncertainties than we
actually do.
 You can blame cognitive biases (mental shortcuts that
influence our thinking) for this problem. More specifically, when
imagining the outcomes of a project, it’s easy to fall victim to:
• Anchoring: When we give too much value to readily available
information instead of thinking about less-likely outcomes.
(i.e. you only think about the risks you faced on a previous
project and not other ones).
• Confirmation bias: When we value information that aligns with
our current position and de-value anything that contradicts it.
• Survivorship bias: When we give too much value to the stories
of success and ignore all the ones of failure.
• Groupthink: When we get sucked into a group’s decision and
don’t bring up objections (even if they’re valid).
• The planning fallacy: When we’re overly optimistic about how
much time or resources a project will take.
 So what sort of risks and uncertainties do you need to
consider when writing a risk management plan? According
to the Project Management Institute, most project risks fall
under a few key categories:

• Technical. This includes risks based on requirements, the

technology being used, interfaces, performance, and
quality.
• Management. This includes any risks that come up from
planning, scheduling, estimating, or communication.
• Organizational. This includes any project dependencies,
logistics, resources, budget, etc...
• External risks. These are risks that come from your
customers, users, contractors, or even the market itself.
 For each risk, there are 3 levels of knowability to
consider

• By definition, project risks are unplanned. But that

doesn’t mean they’re always unknown. Part of
understanding risk management is also knowing
how much you’re expected to know going into it.
• Risks fall into three levels of knowability:
1. A known risk is something that has
been brought up already by a
stakeholder, teammate, or yourself.
Maybe it came up during the project
planning stage or was voiced by an
expert. These need to be carefully
analyzed (see the next step!) and
documented.
2. An unknown risk is one that didn’t
come up right away and might only be
known or recognized by a few people,
such as an expert or specialist. You need
to spend a careful amount of time trying
to discover these while writing your
project risk management plan.
3. An unknowable risk is one that you
can’t be reasonably expected to foresee,
such as total system failure, a market
crash, or an accident. While there’s no
point listing all these out in your plan, it’s
important to accept that you can’t
anticipate every risk. But that doesn’t
mean they’re not out there.
 1. Risk analysis: Identify potential risks (and
then document and prioritize them)
• The first step is to identify all the potential risks
that your project is facing. This should happen at
the beginning of the project as well as periodically
throughout (such as after hitting a key milestone).
• Here’s where you need to dig into the four risk
categories (technical, management,
organizational, external) as well as consider all
levels of knowability (known risks, unknown risks,
unknowable risks).
 There are many different ways you can identify
risks and which strategy you use will come down to
your resources, team, and the size of your project.
To get started, try a few of these:
1. Interviews. Set time aside to speak with key
project stakeholders, outside experts, and other
teammates who might be able to shed light on
some of the more unknown risks.
2. Brainstorming sessions. Your team is one of the
best sources of information on potential risks. In
many cases, they’ve worked on similar projects and
will know where things broke down.
3. Risk checklists. Does your company already have
a workflow in place for identifying risks? If so, they
probably have a checklist of areas and categories
for you to explore. If not, this is a great tool to build
and use in later projects.
4. Assumption analysis. Every assumption is a
source of potential risk (remember the cognitive
biases we listed above?) Take a few minutes and
think about everything you’re assuming to be true
or real about this project. Are your thoughts valid?
Do you have proof?
• The best course of action here is to involve as many people
as possible in each process. Consult with your team,
project stakeholders, and even outside experts if possible.
• Once you’ve identified potential risks, you need
to document and prioritize them.
• Let’s start with writing a risk statement. Instead of a vague,
one-word risk like “budget”, you can use what’s called
an if-then statement to clearly define each risk. Simply put,
this is a language formula that goes:
If [Event/Risk], then [Consequence].

• These statements not only help you understand what will

trigger the risk or uncertainty but also what the potential
impact is.
 2. Evaluate and assess the consequence,
impact, and probability of each potential risk
As you prioritize your risks you’ll naturally ask three
questions:
• What will happen if this situation takes place?
• How likely is it that this will happen?
• How bad will the resulting impact be on the project?
These factors—consequence, probability, and impact
—give context and importance to each of your risks.
Instead of just being a simple statement, you’re able to
understand exactly how bad they are and how much
you should be planning ahead for them.
• In this step, you’re going to review the
qualitative and quantitative impact of the
risk and then assign a likelihood
score (from low to high probability) and
a risk impact score (either low, medium,
or high).
• If you have a lot of risks, you might use a
more complex system to score the
likelihood and impact of them. 
3. Assign roles and responsibilities to each risk

• It’s not enough to just write risks down and hope

they don’t come up. Each risk needs to be
assigned to a team member, prioritized, and given
an estimate of the resources needed to handle it.
• The designated team member will be responsible
for taking ownership if the risk becomes an actual
issue. As part of this, they need to understand
the risk triggers or warning signs that signify they
need to jump into action.
• A risk trigger might be identified in advance
(when it’s a knowable risk), while in other cases
it’ll be pretty much impossible to pinpoint its
exact cause. For example, you might know that
there are risks to your brand when you change
your pricing structure, but you won’t necessarily
be able to identify the exact trigger, such as a
Facebook post or blog from a customer.
• While risks should be assigned to a single person,
they should be visible to all. This way, everyone is
aware of what to watch out for and who to
contact if they see one of the triggers.
4. Come up with preventative strategies for
each risk
• The point of a risk management plan is to give
you a clear path towards solving any potential
issues that come up. For each of the identified
risks, the project manager and the assigned
teammate should brainstorm a proper
response.
In most cases, you’ll handle a risk that has become an issue
in one of four ways:

• Avoid: Change your plan to bypass the issue. In other

words, remove the cause of the threat altogether.
• Transfer: Outsource the risk (or a portion of it) to a
different team or agency. Think of this as a typical
“insurance” policy.
• Mitigate: Take immediate steps to reduce the impact of the
risk. This could mean reviewing your requirements, going
through additional testing, or looking for different options.
• Accept: Assume the chance of a negative impact or
eventually budget in the cost of dealing with it.
5. Create a contingency plan in case things go
really wrong
• In the case that you’re accepting the potential
fallout of a risk, you should know what to do if
it becomes realized. This is called a
contingency plan. In other words, you’re
answering the question: “What do we do
now?”
 Contingency plans should be saved for risks that are high
priority and high impact but without an obvious solution for what
to do if they happen. In this case, you’ll want to have a workflow
mapped out that follows a few steps:
1. Find and document resources that can be used in an
emergency. This could mean moving team members off a different
task, diverting budget, or increasing the scope.
2. Know who will need to be notified in the case of this issue. You
can use your communication plan to help find these people.
3. Create a plan of action for dealing with this issue. Are there
alternatives you can propose or flexibility you can add to your
current project plan? Do you know who to bring in and where to
ask for help? A checklist can help keep you focused when you’re in
crisis mode.
4. Keep an eye on the risk triggers for these issues (especially
deadlines).
 6. Measure your risk threshold and work
with project stakeholders
• While every project comes with some level of
risk, there are ones where the potential
negative outcomes are just too much to
gamble on. This is what’s known as your risk
threshold—the amount of risk your company
or stakeholders are willing to take on.
• As you create your risk management plan, it’s
important to 
stay in contact with your key stakeholders and
sound out how they’re feeling.
• Is there too much risk to justify the project as
scoped? Can you make changes to your 
project plan before you start to reduce the risks?
• While this might feel annoying, it’s better to
make changes early on rather than hit serious
issues once you’ve already committed time and
energy.
 7. Continue to monitor and report on each
risk
• Lastly, risk management is a circle, not a linear
path. Because you’re dealing with unknowns,
your risk management plan needs to be a living
document.
• Whoever owns the risk needs to be responsible
for tracking it, updating it in your project
management tool, and making sure other people
are aware of what’s going on. As your project
progresses, there is a good chance new risks will
come up or current ones will evolve and change.
• Maybe what seemed like a low-probability risk
early on is suddenly much more likely. By using a
tool like Planio to keep track of your risks, you
can quickly update them and keep everyone up-
to-speed with what’s going on.
• Project risk management can’t be done in a silo.
To have the best chance of hitting project success
it needs to be an integrated part of your project
management process.