Module 3: Managing risks effectively

Welcome back. Earlier, we covered managing costs
and a project budget. We discussed what the components
of a project budget are, how the budget process works, and how to track and
estimate a budget. You also learned about
the procurement process. Coming up, we will discuss risk management and why it’s important to help
prevent project failure. Knowing how to anticipate
and alleviate, (commonly known as mitigate) the potential problems is your best bet for keeping
a project on track. You will learn how to define and relate risk management
concepts and explain how risk management can help protect your
project from failing. You’ll also identify risk types and how to measure
their impact on a project and
communicate and resolve identified risks using
a mitigation plan. Ready to get started? Great. Meet me in the next video.

[MUSIC] Hi, I’m Stanton, and
I’m a program manager at YouTube. Thinking back to one of the first
projects I ever worked on, we were actually in charge of
building this sports highlight app. But it wasn’t just an app,
it was an iOS app, it was an Android app, it was a website. And I remember the very first
meeting I went to, I was just furiously taking down notes and trying to
understand what the heck was going on. And immediately after I thought: okay, this is my first project,
I have to get all the details right. I have to make sure we know every
little thing that was going to happen. The launch date needed to be perfect.
We had to get all the bugs down to zero. I was just totally consumed with getting
everything right the first time. I think what I’ve realized since then is you’re probably not going to get
your first project plan correct because there’s just so
many things that can change. You might find a bug last
minute before launch. Your client might come in and
say they want different requirements like, “The screen needs to be
blue instead of red.” And then you find out that it’s not really
that easy to change from blue to red. If I could go back and
tell myself what to do at that point or what I could have done differently, I would have just told myself:
don’t worry so much—changes happen. It’s how you react and respond to
those changes that’s more important. I think one of the best compliments I’ve
gotten is, “Even throughout all this mess, you’re cool, you’re calm, and
you’re collected.” You think through what
are the issues that have happened, how do we resolve them, and
you do your program management thing. You’re not always going to have
the right answer the very first time; things can change at the last minute. If you’re able to stay cool and calm, make sure you understand everything
else that’s going on on the project. All these years have taught me that,
you can always reuse some things. You’re always going to have to react
to some things, but no matter what, try to think proactively, try to figure
out what those issues are going to be, and you’ll be the better for it.

Hello, and welcome back. Hopefully, you’re
beginning to notice how important it is to
plan for risks. Even the simplest projects
can carry some kind of risks. Remember, those risks shouldn’t deter you from pursuing
the project’s goals. The key is to be prepared. Let’s discuss tools and techniques you can use
to identify risks, including brainstorming
and risk assessment. Brainstorming is one of the most effective techniques
for identifying risks with the team because it
allows groups to spontaneously share
ideas without judgment. As a project manager, you will be responsible
for bringing a group of people together to
imagine potential risks. Have your RACI chart at
the ready to refer to when you decide who to
invite to this meeting. Speaking from experience, the best team for this
task is a diverse one, which includes individuals from various roles, backgrounds,
and experiences. Diverse teams bring different
perspectives, experiences, and skill sets, and
this may help you to identify risks that you may not have thought of on your own. For example, one
member of your team might have experience working
on multiple projects, while another newer team member, might bring a fresh
perspective from their previous experience
on other teams. A great tool that
you can use during brainstorming is called a
cause-and-effect diagram, also sometimes known
as a fishbone diagram. Cause-and-effect diagrams
show the possible causes of an event or risk and are very useful
at risk management. For example, in the
diagram seen here, the effect listed is a supplier
missing its deadlines. This is a risk to your project. On the left, you’ll brainstorm potential causes that
would lead to the effect, like poor delegation or a
lack of tracking tools. In other words, cause-and-effect diagrams can help identify all the ways that things
could go wrong by identifying a potential
risk, known as the effect, and working backwards to consider the potential causes
of that risk. By categorizing and breaking them down into further causes, you are able to identify areas that could lead to a
potential problem, like exceeding your budget or allowing scope creep to
impact your timeline. As a reminder, scope creep
refers to changes, growth, and uncontrolled
factors that affect the project’s scope at any point after the
project begins. During these
brainstorming sessions, you might find that your list of potential risks is quite
long, and that’s okay. It is a reality you
and your team cannot account for every single problem that can occur
during your project. So how do you decide
which risks to focus on? List the outcomes from the
brainstorm in a risk register. A risk register is a table or chart that contains
your list of risks. Next, you will adopt a
risk assessment technique. Risk assessment is the stage
of risk management where qualities of a risk are
estimated or measured. By qualities, we’re
mainly referring to how likely the risk is to occur and its potential
impact on a project. We’ll come back to this
point in a moment. There are a few ways
to assess risks, but one we’ll focus
on is creating a probability and impact matrix. A probability and
impact matrix is a tool used to prioritize
project risks. I personally love
this technique and use it all the time
in my role at Google. Earlier, I mentioned
that you need to assess the likelihood that a risk will happen and its potential impact. This matrix will help
you do just that. To create a probability
and impact matrix, you will need to think
about the level of impact. Impact refers to the damage a risk could cause if it occurs. Impact is also determined on a scale of high, medium, and low. High means that if
the risk occurs, it will substantially
alter the project. Low means if the risk occurs, it will have a slight impact but it’s not likely to
derail the project. You will also need to
think about probability. Probability is the likelihood
that a risk will occur. We also determine probability on a scale of high, medium, and low. In this case, high probability means there’s a high
likelihood of this happening. Low probability means
you’ve identified a risk that could happen, but it isn’t likely that
the risk will occur. These two considerations come together to determine the
inherent risk rating. Inherent risk is the
measure of a risk calculated by its
probability and impact. Measuring the inherent risk gives us a method for
understanding a risk. Inherent risk is also
determined on a high, medium, and low scale. Basically, if a risk has a low impact and low probability, it has a low inherent
risk rating. These are the types of risks you don’t need to worry
too much about. But if a risk has a high
impact and a high probability, then it carries a high
inherent risk rating. Medium to high risks are
the risks you should focus on and create detailed
mitigation plans for. When you’re creating a
probability and impact matrix, it’s important to ensure you
create a matrix that meets accessibility guidelines
and has information and formatting that everyone can easily and quickly understand. One way to do this is
to use both color and distinct shapes or text to
communicate levels of risk. You can learn more about
accessibility communication by visiting course resources. The way you view and
manage each risk will be determined based on your
organization’s risk appetite, which refers to
the willingness of an organization to accept the possible outcomes of a risk. You, your team, and your stakeholders may have different
appetites for each risk. We’ll discuss how risk appetite plays into risk mitigation
in just a bit. Certain low-level risks
that could result in minor setbacks are much more tolerable than high-level risks that have the potential to completely derail your project. Once you’ve completed
your risk assessment, you will update the risk register to include high, medium, and low ratings for
some examples of risks that you’ve identified
for this project. Great. Now that we’ve covered how to identify
and assess risks, we’ll go on to the next video, where we’ll discuss some of the types of risks
you’ll run into during your role as a project
manager. Meet you there.

What risk refers to the possibility that a project won't produce the results outlined in the project goals?

Scope risk

Scope risk refers to the possibility that a project won’t produce the results outlined in the project goals. Time risks, budget risks, and dependencies may also pose risks to the project.

Hi again. Let’s discuss some common
types of risks that you might plan for while managing a project. Though there are many different types of
risks that could impact your project, the big ones that you want to be aware
of are: time risks, budget risks, and scope risks. Let’s break those down. First, we have time risks. Time risks refers to the possibility
that project tasks will take longer than anticipated to complete. You’ll need to be aware of time
risks because time is money. Poor time management may
deplete your budget and upset your stakeholders by causing delays. Next, we have budget risks. Budget risk refers to the possibility that
the cost of a project will increase due to poor planning or
expanding the project scope. You need to be aware of budget risk
since budgeting provides the basis for project costs control. For example, if you overspend, you might
not be able to pay your suppliers. This could result in some
reputational damage for the company. Then we have scope risk. Scope risk refers to the possibility
that a project won’t produce the results outlined in the project goals. You need to be aware of scope risks
because the deliverables of your project might not be acceptable to your
stakeholders or customers, and that may defeat the purpose
of the entire project. While time, budget, and
scope risks are very common, there are other types of external
risks that you should be aware of. By external risks, we’re referring to
risks that result from factors outside of the company that you have
little to no control over. For example, your project could be
impacted by an environmental risk, like a major storm, or a legal risk,
like a change in regulatory requirements. And it’s also important to know that
there are endless types of risks. There will never be a prescription for
how to identify and manage every single possible risk. But if you have a plan, you’ll be better set up to deal
with whatever comes your way. Okay, now let’s discuss a certain type of
risk known as a single point of failure. A single point of failure is a risk that
has the potential to be catastrophic and halt work across a project. These are risks that have the power
to stop an entire team in its tracks, meaning that no one can make progress on
their tasks until the issue is resolved. For example,
in our Office Green scenario, a single point of failure might be a power
outage that takes down the internal database where every piece of
information about the project is stored. Until the database is back up and running, your team won’t have access to any of the
information they need to do their jobs. As a result, your team won’t be able to
complete any of their assigned tasks. To mitigate this risk, you might budget
for a separate cloud service to serve as your backup for all of your project
documentation and information. As the project manager,
you’ll need to identify and monitor potential single points
of failure in your project, since they can be detrimental to
the project timeline, budget, and scope. Another source of risk to be
aware of are dependencies. A dependency is a relationship between
two project tasks, where the start or completion of one depends on the start or
completion of the other. In other words, dependencies are like links that
connect one project task to another. A dependency must be addressed
before the task can be completed or before another task can begin. Because dependencies are the links that
connect one project task to another, they are often a huge source
of risk to a project. For example, imagine that you’ve tasked a teammate
with hiring a local plant supplier. Until they’ve signed a contract with the
supplier, your team can’t place any orders. That’s a dependency. Now here’s where the risk comes in. If your teammate doesn’t
meet the hiring deadline and then goes on vacation for a week, this could delay your project timeline.
Not great right? If you don’t plan for
dependencies, you might risk and impact your budget schedule or
project outcome. To prevent something like this from
happening, you might ask a teammate to share their out-of-office plans with
you at the start of the project. This helps you to stay aware
of everyone’s schedules, ensuring that there are backup plans in
place to maintain your project schedule. There are two types of dependencies: internal and external. Internal dependencies refer to
dependencies within the project that you and your team have control over. For example, you’ll need to secure
approval on a website design before development can begin. On the other hand, external dependencies are dependencies
that you have no control over. For example, the farm that your plant
vendor works at might have experienced a lighter rain season this year, meaning
that they’ll have fewer plants to sell. There are many different risks that can
impact your project, from time risks to budget risks to scope risks. But remember, no project is risk-free. And with careful, upfront planning, you can do your best to
prevent risks from occurring. In the next video,
we’ll discuss how to mitigate risks. I’ll meet you there.

Hi, and welcome back. Okay, so you’ve learned
how to identify your project’s risks
and assess them using a probability
and impact matrix. Now that you know which risks
require your attention, how do you determine
what to do about them? This is where risk mitigation
planning comes in. Risk mitigation planning is about finding ways to eliminate or reduce the impact of
potential risks to your project. There are four common
ways to mitigate risk. You can avoid it, accept it, reduce or control
it, or transfer it. Let’s discuss each option using
the Office Green example. Sometimes you can avoid
the risk altogether. For example, if you learn that a certain contractor you’ve
considered working with on your Office Green project has a poor reputation for
meeting deadlines, then you might choose to avoid that risk by hiring a
different contractor. You can also accept the risk, especially ones that you deem low in probability and impact. In this case, you’re accepting the possibility that
this risk can happen. You’ve agreed to monitor it
throughout the project, and you’ll ultimately be okay with the risk if it does happen. For instance, maybe your
plant supplier tells you that one of the planter styles you’ve requested is back-ordered. The supplier is confident
that they’ll have time to restock the planters without delaying your project schedule, but if there is an issue
with every stock shipment, this could delay deliveries to your clients by up to two days. Rather than starting over
with a new supplier, you decide that it makes more
sense to accept the risk. It wouldn’t be ideal
for this delay to occur, but you’re
flexible and you know that accepting this
risk will save you and your team the headache of
onboarding a new supplier, which could take two weeks. Another way to mitigate a risk is to reduce or control it. Personally, I like to use a decision tree when
building mitigation plans. A decision tree is a flowchart
that helps visualize the wider impact of a decision on the
rest of your project. For example, you decide to
hire the contractor with a reputation for
missing deadlines because you know
they do great work. In this case, you might
create a quick flowchart that visualizes the risks and potential options
for addressing it, like checking in with
the contractor daily, either by email or
through meetings. Ultimately, you might then
choose to have daily check-in meetings with the team to ensure that they’re staying
on top of their tasks. Finally, you can choose
to transfer the risk. For example, you’ve determined that it’s too risky to
attempt to grow plants on site at Office Green due
to the possibility that bad weather or pests could negatively impact your product. Instead, you’ve made a
decision to transfer the risk to another
party or parties. By outsourcing plant
production to local suppliers, you have the power to change suppliers if there’s an
issue with quality. When you transfer the risk, you don’t risk losing out on
time, resources, and money. To recap, four common ways to mitigate a risk
are: to avoid it, accept it, reduce or
control it, or transfer it. Using one of these four
strategies can help you effectively take control of
the risks to your project. Coming up, we’ll discuss how to document these risks in
a risk management plan.

Now that you know your options for mitigating potential risks, let’s discuss how to document your risk-planning decisions. As you’ve been learning
throughout this program, documentation is a crucial part of your role as a
project manager. This is especially
true when identifying risks and creating a
plan to mitigate them. A risk management plan is a
living document that contains information regarding
high-level risks and the mitigation plan
for each of those risks. This plan helps ensure that teammates and
stakeholders have a clear understanding of potential problems and a plan to address them
should they occur. Risk management is an
ongoing practice that you’ll take part in throughout
the planning and execution of a project. Since risk management evolves
throughout the project, the plan should be updated regularly to add newly-identified risks, remove risks that are
no longer relevant, and include any changes
in the mitigation plans. Let’s review an example of a risk management plan similar to the one we sometimes
use here at Google. At the top of the document, we include the name
of the company, and below it, the
name of the project. We also include the
document author so that anyone reviewing the plan knows exactly who to reach out to if they
have any questions. This template also designates a spot for the document status. As you’re building your plan, you can list the
status as “in progress.” Once the plan is complete, you can change the
status to “final.” We’ve also included
helpful details like when the document was created and
when it was last updated. Details like these
might seem small, but it’s best practice
to include them. That’s because being
transparent about dates provides stakeholders with a sense of how up-to-date the document is. Below these details, we have
the document objective. Here, we’ve written that
our objective is to outline mitigation plans
for Project Plant Pals. Below that, we’ve added an executive summary
of our project. Executive summaries
should include a brief introduction to
the normal conditions of a project and an outline of the potential risks that
could impact the project. Now onto the really
important stuff: the risks and how
we’ll mitigate them. This document also includes the risk register you
learned about earlier, which is a table or a chart that contains your list
of possible risks. Here, we’ve outlined one of the potential risks to
Project Plant Pals, which is the potential
for the vendor to fall behind on a deadline. We’ve given this risk a
medium inherent risk rating. Remember that inherent
risk is the measure of a risk calculated by its
probability and impact. A mitigation plan has also
been included for this risk, which is to hold
daily meetings with the vendor to help
them stay on task. Down in the appendix
of the document, you’ll find the probability
and impact charts as well as the probability and impact matrix that we use to assess our risks. Once you’ve filled out
the risk management plan, you’ll share it with your
team and stakeholders to get their input and to ensure that they are aligned with your plans. Coming up, we’ll dig
deeper into the topic of communicating risks to
stakeholders. See you there.

During the planning phase, what should you consider when communicating a risk to stakeholders?

Severity of the identified risk

You should consider the severity of the identified risk. It is important to communicate early and often with stakeholders about medium- and high-level risks. For low-level risks, something as simple as an email might suffice.

Hello. As you’ve learned
in the past few videos, identifying and
assessing risks is a crucial part of the
project planning process. These exercises help clarify the most important
risks for you and your team and ensure
that everyone agrees on which
risks to plan for. But it’s not enough for you
and your teammates to simply be aware of the biggest
risks to a project. You also need to communicate these risks to your
project stakeholders, whether through
documentation, e-mail, meetings, or other forms of communication you’ve
deemed appropriate. Your stakeholders need to be aware of the risks
facing a project, because if you don’t
tell your stakeholders about important risks, they may be less equipped to help you if an issue does arise. For example, they
might not be able to provide you with more
budget should you need it or with more resources
should you require them. Even worse, your stakeholder might be
caught off guard by an issue. Unpleasant surprises
like these can erode that trust in you as
a leader of the project. They’ll likely want
to know if you were aware of the possibility
that this risk could occur, and they might wonder
why you didn’t share this information
with them sooner. That’s why it’s important to
communicate early and often with stakeholders about
medium- and high-level risks. It sets expectations with
stakeholders about what to potentially expect during
the project execution phase and demonstrates that
you’ve taken steps to mitigate and plan for those
risks should they come up. It also gives you the
opportunity to suggest ways they might be able to
help you if a risk does arise. How do you communicate risks to stakeholders during
the planning phase? Well, that depends on the severity of the
identified risk. For low-level risks, something as simple as
an e-mail might suffice. For example, when sending out weekly planning updates
to a project stakeholder, you might list a few low-level
risks that are relevant to their interests and briefly explain how you’ll address
these risks if they arise. For medium level risks, you might increase your
level of communication to a direct e-mail
between yourself and the stakeholder in which
you outline the risk with more specifics and provide a detailed explanation of your
plan to mitigate the risk. You might also link to your risk management plan to provide them with
more information. You might write “urgent” in the subject line to stress
the e-mail’s importance. The serious nature
of high-level risks requires a thorough and direct
level of communication. When you’re meeting
with stakeholders to go over the project plan, you might add an
agenda item to present serious risks and your plans
to mitigate these risks. You can also use
this time to collect feedback on your risk
management plan and ask for insights from
stakeholders on how they suggest handling these
high-level risks. Your stakeholders might have prior experience planning for similar risks and strategies that you hadn’t
considered before. Risk communication is a big part of my role here at Google. As a program manager, I’m constantly writing
e-mails and delivering presentations on the
status of my projects, often with the goal of sharing known risks and my
risk mitigation plans. In discussing these plans
with my stakeholders, we often uncover other risks that I hadn’t even considered. For example, in a recent meeting, I was presenting a
potential new product to a stakeholder on
a different team. In the meeting, the
stakeholder flagged their concerns that
my solution might create time and resource risks that could have a negative
impact on their team. This discussion gave
me deeper insights of my colleagues’ potential risks
and of the product’s users’ needs, which made me
realize that I needed to ask my project sponsors for additional budget
and resources. It’s always a good idea to discuss your plans with
your stakeholders. They may have a
different perspective. To recap, it’s important
to communicate risks to stakeholders so
that they’re better able to help you should one arise, and you should tailor
your communication style according to the
severity of the risk. Up next, we’ll review and wrap up all that we’ve
covered. Meet me there.

My name is Aji, and I’m a Senior Program
Manager at Google. Program management spans a
lot of different industries, a lot of different applications. At its core, it means that
we bring order to chaos. At Google for me, I work on product launches. I also develop new processes
and procedures for teams. I work across different
functional areas, so that could be engineering, it could be UX, it could
even be People Ops to help launch products. To me, risk management
means looking ahead and trying to
anticipate issues. I liken it to the analogy
of being on a ship and being the person
looking ahead to make sure there’s
no rocks, right? A lot of our projects, I would say for the most part, at least in my experience, are never just done in a silo. There are other
dependencies, right, and other teams that are
depending on you to execute. It is very important to de-risk, to look ahead, to
manage those risks, to communicate those risks to the appropriate stakeholders, to make sure that you’re
delivering on your commitments. I think that the first step is identifying the problems, bringing in the right people, so that you know that you
have a good, kind of, comprehensive list,
and then from there, trying to figure out how to manage those issues, and again, that can be, and that should be, a very collaborative
thing, right? Because everybody on your team needs to be equally
vested in making sure that the project
executes successfully. I have a project right
now that I’m working on, and with this project, after we determined what our strategy was
going to be and what our end state was
going to be from a product strategy perspective, the next step was
creating what we call “UX mocks” or “UX designs,” and so basically,
that’s just pictures of what we want our
end state to be like, what’s our ideal state, right, in a visual format. As a program manager,
my job is to kind of take a step
back and make sure, okay, what are the
potential landmines? What could go wrong? As I started going through the designs and looking at them, I realized that in my
mind it was hard for me to reconcile and say, “Okay, this is what
we’re doing today. This is what’s going to change.” It wasn’t very clear to me, and I’m less of a visual person and more of like a, you know, I like spreadsheets
and all of that and have things in detail, and so in my mind,
I was like, okay, if I’m having this issue trying to reconcile between, okay, visually we say we’re
going to design this, but this is where we are,
what’s the difference? If I’m having this issue, then maybe other people are
having this issue, as well. And okay, if other people
are having this issue, maybe our engineers are
having this issue as well. And so, when I set up the
meeting, within five minutes, we started to realize that
there were differences in how they were interpreting
what we were supposed to do, that we had gone
down this road where these two teams were executing on things in a different way. We wouldn’t have realized
it until the end, and then it would
have been too late. I love program management. I love coming into a problem, being given a problem that’s very ambiguous and not well
thought through, right? And it’s a huge pain point, and then coming up with a
solution to that problem.

Nice work. Let’s recap what
we’ve discussed so far. You learned about risks, which are potential events that could impact your project. You also learned how
risks differ from issues, which are known and
real problems that may affect the ability to
complete a certain task. I introduced you to
risk management, which is the process
of identifying potential risks and issues
that could impact a project, and evaluating and applying steps to address their effects. We’ve discussed brainstorming as a technique for
identifying risks, and I introduced you to tools you can use to identify, assess, and document risks, like a
probability and impact matrix, a risk register, and a
risk management plan. Finally, we discussed
the importance of communicating risks to
your stakeholders in order to set expectations
and demonstrate your work to plan for and mitigate potential problems
with the project. Coming up, we’ll discuss documentation and
communication. See you soon.