Module 1: Introduction to project execution

Hi there. If you’ve gone
through our previous courses, you’ve spent a lot of time digging into the intricacies and significance of setting
up a project for success. And now, we’re at the
project execution stage where all of that
hard work comes together. If you haven’t gone through
our previous courses yet, we recommend checking them out. Before we get started, let me introduce myself. My name’s Elita, and I’ll be your instructor
for this course. I work as a Senior Engineering
Program Manager at Google, where I currently
lead the team behind routing and navigation
on Google Maps. I joined the company in 2007, working on teams across Google’s engineering
organization in New York, London, and Seattle. In 2013, I joined the Google Maps team and
launched popular features like holiday hours and
attributes on businesses, while leading global teams from New York to Sydney to Hyderabad. Generally, I like solving problems and learning new things. Every new project and team
allows me to do both. I’m excited to lead you
through this course and demonstrate how to put a
project plan into action. First step, you’ll
learn more about risks and unforeseen changes
through the project. If you’ve taken our
previous courses, you might recall that
change is inevitable. And to combat that, we’ve covered the concept of risk mitigation
during the planning phase. And now we’ll take it one step
further and discuss what to do when a risk
actually materializes. Next, I’ll discuss
tracking and quality. You’ll learn how to
track and measure your project’s progress, and
you’ll learn how to use continuous improvement and
quality management techniques to keep the project on
track and running smoothly. These best practices are
valuable to just about any role, and I’m looking forward to taking
you through them. Other big aspects of running a project include
decision-making. You’ll learn to both
use and analyze data to inform your decision-making,
and then, in turn, use that data to explore and explain key aspects
of your project. I’ll also discuss team management and the fundamentals
of influencing. So much of the success
of a project relies on teamwork, and you’ll
learn more about how you, as a project manager, can effectively lead your
team to the finish line. Speaking of teamwork, I’ll share some of the
tools that provide effective team
communication along with tips for organizing and
facilitating meetings. And then, we’ll wrap up by discussing
how to close a project. You’ll learn the steps required
to finish a project and the importance of celebrating a job well done with your team. Sounds kind of fun, right? After all that planning, this is the point in the
project life cycle where work gets done and
everything comes together. Ready to get started? Meet me in the next video, where you’ll learn
about the importance of tracking and measuring
project progress.

Hi again. In previous courses, we’ve discussed the
importance of breaking your project down into milestones and tasks and assigning those tasks to different
members of your team. We’ve also discussed setting
a schedule and budget. But once the project
execution phase gets going, how do you actually know that
the work is getting done? Well, you can do this in a
few ways, but primarily, you can keep tabs on project progress by
tracking and measurement. This is actually a big part
of project management. Tracking, by definition,
is a method of following the progress of
a project’s activities. Measuring project performance regularly to identify deviations from the project plan can help ensure that the project
stays on track. A deviation is anything that alters your original
course of action. Deviations from the project plan can be positive or negative. Are you ahead of schedule
because a technical problem is less complex than you
estimated? Thumbs up. Did a natural disaster shut
down your testing team? Big thumbs down. Both of these are
examples of deviations. They’re also examples
of why tracking is such a crucial part of your role during the project
execution phase. Let’s examine some
of the ways that tracking is beneficial for
your project’s success. To start, tracking makes
key project information transparent, and transparency is essential for accurate
decision-making. Even the strongest
project managers make poor decisions when they
lack information or context. Tracking centralizes
project information so that everyone can
understand the status of each part of the project, which can then help you identify
gaps in your knowledge. Also, projects have so
many little details. It’s hard to keep
everything straight. Tracking helps ensure that you don’t risk
forgetting something. Second, tracking helps keep all team members and stakeholders in touch with
deadlines and goals. To ensure that everyone has visibility into project progress, you should have a
project plan that works both for you and your team. This way you’re all
on the same page about how the project
is progressing. You will learn about
different ways to track a project later
in this module. Tracking is also
crucial for recognizing risks and issues that can
derail your progress. With effective tracking, you will be able to identify issues in a timely fashion and work with your team to take
corrective action. By providing visibility into the various parts of the project, tracking helps you and your team identify and focus
on areas at risk. And finally, tracking helps
build confidence that the project is set to
be delivered on time, in-scope, and within budget. Having a clear, up-to-date picture of the overall
project status keeps the team motivated and focused on staying the course. So to recap, tracking
is important for a few key reasons,
like transparency, risk management, and keeping
the project on track. Coming up, we’ll take you through some of the key items to track during project
execution. Meet you there.

So we’ve discussed that
tracking monitors the progress of
project activities. But you may still be wondering, what specifically
should you be tracking? I’ll take you through a few of the most commonly
tracked items that I found helpful when managing
projects at Google. First, you should always
track the project schedule. This is made up of tasks
and activities that ensure that the project is effectively heading toward its
completion date. After all, your
ultimate goal is to complete your
deliverables on time. Equally important is tracking
the status of action items, key tasks, and
activities to ensure that that work is
actually getting done. Tracking tasks also helps to track your team’s progress
toward milestones. We learned a bit
more about tracking progress toward milestones
earlier in the course, and we stressed the
importance of creating tasks and milestones to keep
everyone on track. When you’re in the
middle of a project, new tasks will come
up all the time. In order to avoid
missing deadlines, it’s imperative to
track tasks as they progress and as you
approach key milestones. Next, you’ll also need to
track costs to ensure that you don’t overspend or
underspend on project tasks. As I mentioned earlier, all projects have budgets, and whether or not you’re
overseeing the entire budget, you may be overseeing tasks and resources that have
budget implications. Finally, you’ll need to track
key decisions, changes, dependencies, and
risks to the project, including any agreed
upon scope changes. This way, your team and
stakeholders are aligned on what needs to be done
for the project to succeed. We will cover this in
more detail throughout the course since it’s a big
part of running the project. To recap, the items that are
helpful to track throughout the project execution phase
include the project schedule, which contains the key
tasks and activities, the status of action items, progress toward milestones, costs, and key decisions and changes. There are many moving parts to be aware of once a
project is underway. Tracking them closely
benefits you and your team as you head
toward the project goal. I’ve taken you through
an introduction to tracking, and coming up, we’ll discuss project
management tools and templates you can use to
track project activities. Meet me in the next video
to expand your toolkit.

In which of the following scenarios is a roadmap the most effective tracking tool?

A software development project in which clear communication about big milestones is key

Roadmaps are great for tracking big milestones and conveying a sense of the big picture to stakeholders.

In which of the following scenarios is a Gantt chart the most effective project tracking tool?

A large construction project involving multiple contractors and many interdependent tasks

Gantt charts lay out ownership and responsibilities explicitly. This makes them a good choice for large projects with multiple dependencies.

Welcome back. Now that you understand how
essential tracking is, let’s explore and compare various types of
tracking methods. The purpose of your
project plan is to guide you through the
execution of your project. Therefore, it will always include at least one type
of tracking method, and sometimes you
might use more than one depending on what
your team needs. The tracking methods
we’ll discuss in this video are a Gantt chart, a roadmap, and a burndown chart. There are many others, but these are the few that
I’m going to focus on. Whichever type you
choose depends on what you deem suitable
for your project. It’s important to remember
to select something that the entire team
can easily understand, reference, and keep up to date. Let’s compare the tracking
methods I mentioned. Perhaps the most
common tracking method of all is the Gantt chart. It’s a tried and true tool to
keep your project on track. A Gantt chart measures tasks against time and includes
useful information, like who will own each task and what the order of
the tasks should be. For this reason,
it’s a useful chart for staying on schedule
and for projects with many dependencies or tasks or activities or milestones that
are reliant on one another. It’s also a helpful chart for teams with a lot
of people, because ownership and
responsibilities are explicitly laid out visually. As you track and move along
sequentially over time, this starts to look
like a waterfall; hence, why Gantt
charts are commonly used in Waterfall
project management. Each task is represented by a
horizontal progress bar, and the length of the
bar is dependent on how much time is
allotted to the task. The bars are stacked on top of each other to denote
that the task at the top must be completed before the next one below
it can be completed. Gantt charts typically live in your project plan and are updated as the
project progresses. Another common tracking
method we have here at Google is a roadmap. A roadmap is best suited
for when you need a way to track big
milestones in your project. It’s useful for illustrating how a project should evolve over time to a team and key
stakeholders. Here’s an example: a roadmap might list your
project’s goals at the top and a description of the approach we’ll be taking to
meet those goals. In this example, the
goals are to increase online business-to-consumer
sales by 20 percent year-over-year and to increase holiday sales to
existing customers by eight percent over last year. The approach details
the main tactics your team will use
to reach your goal. A roadmap also includes a
high-level project overview. High-level in this context
means a concise summary, usually three-to-four
sentences, to clearly state the objectives and
priorities for your project. Below the goals, approach, and overview is a table that maps out what the
process will entail. In this example, our
table is divided into quarters that reflect
the project timeline. A quarter is a three-month period on a company’s
financial calendar. Key milestones are
listed for each quarter. Then, there are tasks that each team member or
department needs to complete. Most tasks may map to a milestone due within
the same quarter. In our example, the
project as a whole has a key milestone in Q1 to finalize inventory for
the holiday season. The work of product testing and finalizing suggestions for offerings mainly falls to the
marketing and sales teams. However, sometimes the tasks
may need to be completed in advance to unblock another team or milestone in future quarters. The product and engineering
team is working on tasks in Q1 and in Q2 that lead up to the launch of the refreshed online store in Q3. In order to reach that milestone, each department needs to
complete specific tasks, and the roadmap tracks
both individual and project progress
toward milestones. Finally, there’s
the burndown chart, the most granular of the
three tracking methods. A burndown chart measures
time against the amount of work done and the amount
of work remaining. Their main uses are to keep
the project team on top of targeted completion
dates and to keep the team aware of scope
creep as it occurs. Burndown charts are best suited
for projects that require a detailed, broken-down review of each task associated
with a project, and they’re great
for projects where finishing on time is
the top priority. The y-axis or the vertical axis symbolizes the number of
tasks left to complete, and the x-axis or the
horizontal axis signifies time. Progress gets tracked from the upper left-hand
corner of the chart. As the project goes along, you’ll track down, working your way towards zero remaining tasks, and to the right, working your way
toward your end date. There’s typically a dotted line for your expected or projected progress based on the rate your team’s expected to close tasks, and a solid line representing
your actual progress. Before you continue
on with your project, you’ll need to decide which
tracker makes the most sense. If you need to communicate
milestones to a large team, you might choose a roadmap. If you have a project with
multiple dependencies, you might choose a Gantt chart. If tracking tasks against your deadline is
especially important, then the burndown chart
might be your best option. And you may even decide
to use more than one. Because the tracking method will be determined by the type of project you’re working
on, your resources, and the project scope, you’ll probably end up
using several types of tracking methods at some
point in your career. In my time at Google, I’ve regularly combined methods and used a few different
types together. For example, using a Gantt chart to scope work at the
beginning of a project, then switching to a
burndown chart in the weeks before a launch to
make sure we’re good to go. Now you know a bit more about the various types of
tracking methods, including a roadmap, Gantt
chart, and burndown chart. Next step, we’ll focus
on understanding continuous improvement
and process improvement.

[MUSIC] Hi my name is Belinda and
I’m a program manager with Google. My role with Google has been building
budgets for the last several years, there’s a lot that goes into
building data center budgets. It can take quite some time,
and they’re due every year for the renewal of the following
year by September 1st. The budget is entailed of anything you can
think of down to janitorial services for the data center site, all the way to UPS
units to have to run it’s battery backup, in case we lose power. So the role that I have had for
several years has been to not only build the budget but to figure out and
work with the team and also vendors, on what money is needed
funding as we grow as a site as well. And for me what I’ve always done is built
a Google sheet, and I’ve used that year over year line item by line item, and
I break it down per the account GL, account code, and also with the D
channel that references to that. And basically that is just
the categories of whether we’re dealing with mechanical electrical
chillers, maintenance for the lawn RTU units,
mechanical concepts, labor, repairing services to the elevators,
lifts, golf carts, generators. You do a line by line item for
anything that takes a data center to run. So it can be very convoluted and
quite difficult, but I have always found that the Google Sheet
is the best method for my base structure if where I start, currently there’s four
managers that I build that budget with. We have a meeting and go over the budgets
to be clear and as transparent you can be to make sure that you’ve got
everything in there that was requested. What has happened over the years is
what we’ll have is we’ll have a manager, that will be the lead
with me on the budget. So that when we go to submit the budget,
and we’re at a director level meeting,
when we’re submitting this, I have a FM manager from the site that
is actually overseeing that budget. It depends on who you’re working with,
but they’re going to know what their needs are and they can help you understand
when they need those needs, and how much money they need. So for anyone that’s looking to go into
project management, budget management, I think that that they really need
to know that they they love math. And they need to also love
change because change happens so often with project management and dealing with budgets because they change
hourly, sometimes they change daily. Sometimes you have a really, really
calm week where everything went like it was supposed to, and
then sometimes it’s chaos. For me, I like being busy and
I like change, I’m not afraid of it, but I think that people that would
be interested in this type of role would need to understand
that that’s going to be there. So anyone who’s starting to build budgets
with Google, it can be quite overwhelming even though with the experience that
I had it was overwhelming for me. And I had to figure out a platform for
me and the sheet that made sense so
I could track it. But I think that the advice I would give
anyone that’s starting out with budgets would be take it one day at a time,
you don’t learn all in one day it can be overwhelming, but to break it
down maybe and in smaller pieces. [SOUND]

[MUSIC] Hi, my name is Pranjal, and I work as a program manager in
the Site Reliability Engineering org. You can also call it SRE. What SRE does is they
are primarily responsible for all the critical services within Google, and in case something goes wrong, we are the first line of defense. I think I can talk about the first
big project I managed at Google. My tech lead and I co-founded this
project about three years ago, and I continue to work
on it as of right now. So the project of what we wanted to do
in terms of ambition was we wanted to generalize some tooling to help mobile
apps be reliable in production. So what that means is,
let’s say you’re using a mobile app. We want to make sure that in
case something goes wrong, we detect it before the user does, and we take action before the user even
knows that something’s wrong behind the scenes, right? So we started out with this project, and
my biggest fear in terms of working on this project was managing a trade off
between ambition and project quality. So when we did our brainstorming sessions,
and we wrote out a roadmap, it just seemed a bit too overwhelming—the scale at which we
were planning to work. I think I would be really thankful
to my manager at the time. She said, she gave me some really good
advice, she said, “In case you have, let’s say, five different tracks
going on in a very big project, not all five tracks have to be
worked on every single day. You could probably take out a quarter and make super-good progress on maybe
track three and track five, whereas you can bootstrap the other
tracks to make progress on it in the next quarter.” So that gave me a bit of peace of mind. And she also empowered me
to think in terms of—I’m in a position as a program manager to
push and pull on those priorities. As long as people are aware of what
we’re working on, what risks need to be identified and mitigated, and
if everything’s being tracked properly, it’s okay to maybe accelerate sometimes
and pause sometimes In fact, I learned that zooming out and pausing
sometimes can result in original ideas and then also gives people
a little bit of a breather.

Which of the following issues can result in a major change to a project plan? Select all that apply.

A client doubles their original order

Scope creep isn’t always a negative, but it can still have a big impact on project tasks, structures, and processes.

A client cuts their budget because of an economic recession

Budgetary restrictions can have a big impact on project tasks, structures, and processes.

An earthquake damages the foundation of a construction project

Force majeure can cause damage that has a big impact on project tasks, structures, and processes.

Welcome back. In
an earlier video, we learned about how to identify risks when
planning projects. In this module, we’ll learn
why risks and changes might occur during a project and how that can impact your
project’s scope. You may remember that a risk is a potential event that might occur and could
impact your project. When you think about risks in the context of
project management, you’ll think about
them as hypothetical. In other words, these might not be events that will
definitely happen, but because there’s a possibility
that they could happen, it’s your responsibility
as a project manager to identify and plan
for those risks. Let’s revisit some
examples of risks. A project risk might be a contractor missing a deadline, or introducing a tool that may lead to communication
breakdown within your team, or unexpected,
additional work because of an unforeseen policy
being put in place. When any risk occurs, the consequence is a change
to the project plan. A change is anything that
alters or impacts the tasks, structures, or processes
within a project. Changes are typically unexpected. More often than not, they have a negative
impact on the project, and you’ll have to
learn to navigate that. But sometimes, and I’m placing a heavy emphasis on sometimes, changes can have a
positive impact. Changes can encompass
any variance from the original project plan in regards to the triple constraint. This may entail changing
priorities and scope, budget and resources, or changes
to the project timeline. We’ll discuss how the internal
and external dependencies of a project impact each
other and bring about change. Let’s go through a few types of changes that can
affect your project. Some examples of changes may include new or
changing dependencies. Dependencies are
tasks, activities, or milestones that are
reliant on one another. So if one task isn’t
completed on time, it may put your
other tasks behind. You might be in
charge of renovations on a home where there
are dependencies. In a bathroom remodel,
for instance, a new sink cannot be installed until the vanity and
plumbing are in place. Next, is changing priorities. The scope of the
remodel changes if your client’s in-laws
suddenly have to move in, and you have to move
up planned work on the spare bedroom before
completing the bathroom remodel. Next up, the capacity and
people available could change. Maybe you have to
replace the plumber because you had issues
on the job site. Another type of
change could include a new limitation on your
budget or resources. For example, you need to reduce design costs
in the new bathroom by 10 percent because
your quotes for electrical work come in
higher than expected. Another change could
be scope creep. Scope creep is when changes, growth, and other factors
affect the project scope. For instance, your clients
are so happy with the tile in the new bathroom
that they’d like to replace the tile in all
of their bathrooms. Finally, force majeure. This is another change
that could occur due to a national or
international crisis. If you aren’t familiar
with this term, it means an unforeseen
circumstance that prevents someone from fulfilling
the contract due to a major crisis. Force majeure is pretty uncommon. But for instance, if a
union goes on strike, certain vendors won’t be able
to fulfill their contracts. If there’s a pandemic, all production on your new
product might be halted. Changes should be
measured against the baseline estimates of scope, budget, and time allotted for your project, given the
original requirements. Be mindful that when you change
any one of those things, there may be knock-on
effects which could be positive or negative. For instance, your
clients may believe they have beautiful hardwood
floors hiding underneath old living room carpet
and want to pull up the old carpet and use the original hardwood
floors underneath. You, the project manager on this particular
construction job—you’ve budgeted to have
the carpet removed and the old floors sanded
and stained. Bad news. You pull up the carpet and find the floors are in bad
shape and rotting. They’ll need to be
replaced or repaired, which could be costly, so your timeline and budget
are likely to take a hit. When it comes to who takes on the responsibility of
managing the changing scope, it’ll be you—the
project manager. But depending on the project, you probably won’t do it alone. In order to properly
manage changes, you’ll want to refer
to documents like your Statement of Work
and the RACI chart. But you might also have to
create some new documentation. You’ll want to create or
familiarize yourself with the processes for requesting changes for your team
or organization. These processes might include
a change request form. Let’s discuss change
request forms. You and your stakeholders will use these forms in order to stay on top of, and adequately
manage, any changes. Since a lot of people
with different roles on the project can
fill out these forms, it’s important for
the forms to be self-explanatory
and very thorough. In the provided template, which uses a 2-by-10 table, you’ll need to include
information in the cells, such as: the project name, the discussion owner, who’s taking the lead on this
discussion from the team, discussion type.
You’ll want to let your audience know if you’ll
be discussing a risk, opportunity, or anything else. You’ll want to identify the teams involved and the expected
outcome of the discussion, which might be a change in
priorities, schedule change, or an official call
on how to proceed with an issue. Add
the target date for discussion, and identify
which milestones or goals might be impacted. Provide a short description of the current situation,
the change, and any difference you expect to make to
the plan of record, like a snapshot of
the before and after. Then go into in-depth
proposal for the necessary changes and
address any trade-offs. Finally, provide any
background information so that everyone shares
the same context. You can also refer to your
statement of work, or SOW, for more information about who needs to be involved
in that conversation. If you find that one or more of your milestones are at risk
of not being completed, then you’ll need
to get a customer sign-off before the scope, deadline, or budget are changed, and all parties involved
need to be informed. Great work. We’ve reviewed how to define risk and
know more about how to identify the reasons why risks and changes might occur
during a project. And now we can explain the impact of increasing a project scope. In the next video, we’re going to discuss the role dependencies play and how to properly manage them. We’ll
meet you there.

Which type of dependency describes the relationship between two tasks within the same project?

Internal dependency

Internal dependencies describe the relationship between two tasks within the same project. For example, a project manager would not tell a team to start working before scoping work and signing contracts—these activities need to come first.

So we’ve covered risks and
how they affect a project, but we haven’t fully discussed
dependencies—arguably one of the biggest factors in a project. In this video, we’ll discuss
dependencies—both internal and external—how to identify and track them,
as well as their importance. There are a few different
types of dependencies, and we’ll discuss a few examples of each one. So what exactly are dependencies? Dependencies are the links that
connect one project task to another, and as we mentioned, they’re often
the greatest source of risk to a project. Two or more project tasks may have
a relationship with one another in which the completion of one task is reliant
on the initiation of another task, and vice versa. Think of these tasks
like a line of dominoes toppling each other over, one by one. If one domino falls, it’ll knock
the next one over and so on and so on. For instance, a construction company may
have a number of jobs across the city. Each project requires a foreman and
a project manager to be chosen before the requirements, timeline, and budget
get signed off and the crew is chosen. You wouldn’t choose a crew and tell them
to get to work before the work has been clearly scoped and
the contracts were signed. That’s an example of
an internal dependency, which describes the relationship between
two tasks within the same project. External dependencies, on the other hand,
refer to tasks that are reliant on outside factors, like regulatory agencies or
other projects. For instance, if a construction company
is scheduled to demolish a building site, they’ll have to wait until their
project is approved by the city. External dependencies aren’t always
in the project manager’s control, but it’s important to be aware of them so
that the project stays on track. Mandatory dependencies are tasks that
are legally or contractually required. For instance, when that construction
company finishes the demolition and starts the rebuild, they’ll first have
to pour a concrete foundation and then have it inspected by
the city to ensure it meets their standards before the construction
company can continue to build. Lastly, discretionary dependencies
are defined by the project team. These are dependencies that
could occur on their own, but the team saw a need to make those
dependencies reliant on one another. For instance, the construction company may
be using concrete from a new supplier and want to run a test, pouring a portion of the foundation to
get a better estimate of the total amount of product they’ll need to complete the
foundation, rather than buying too much or too little product up front. The task of pouring a portion
of the foundation comes first, because the team needed more
information before making a decision. A project manager has to work diligently
to incorporate dependency management. Dependency management is the process of
managing all of these interrelated tasks and resources within the project
to ensure that your overall project is completed successfully on time and
in budget. To pursue effective dependency management, there are four important steps
that a project manager can take: proper identification, recording
dependencies, continuous monitoring and control, and efficient communication. The first step is proper identification. A project manager will have to
brainstorm all possible project dependencies with their team and
categorize them accordingly. Next step is recording dependencies. After all dependencies are identified,
a risk register should be created. A risk register is a table or
chart that contains your list of risks and dependencies. The risk register should include
a description of the dependency, the date, and all activities or tasks
that may be impacted by the dependency. Then, a project manager will want to
maintain continuous monitoring and control. This means you will want to schedule
regular meetings to check in on the interrelated tasks, staying up-to-date on any progress
being made and double checking for changes that will impact other tasks. Last step is efficient communication. Keeping the project team and stakeholders
updated can help resolve dependencies and keep the project going strong. To recap, we just discussed how to define
dependencies, both internal and external, and we learned the importance of
managing and tracking dependencies. We also discussed the importance of
clearly defining dependencies at the project outset,
like in our foundation example, and learned about dependency management. In the next video, we’ll give you concrete techniques
to manage the risks in your project. I’ll meet you there.

What is risk exposure?

A way to measure the potential future loss resulting from a specific activity or event

Risk exposure helps to measure potential future loss. One way to calculate risk exposure is to build a matrix with two variables: risk impact and probability.

Earlier we talked at length about
identifying and managing risks. Risk management is absolutely
critical to a project success. So in this video, we’ll introduce
additional techniques for managing risks. Let’s start with a reminder of
the definition of risk management: Risk management is the process of
identifying potential risks and issues which could impact a project,
then evaluating and applying steps to address the effects
of the identified risks and issues. One way to manage risks, and hopefully, prevent any risks from
materializing is to focus on managing the changes and dependencies, as well
as any scope creep in your project. If you can manage those two things,
both changes and dependencies and scope creep, other types
of risks become much easier to manage. If your dependencies are met on time, your team is less likely
to fall behind schedule. If your scope is tightly-managed, you’re
less likely to incur changes to your budget or
be forced to extend your timeline. Brainstorming with your team is one
of the most effective techniques for identifying risks in a project. Your teammates likely bring skills and
experience from previous projects, which can help suss out similarities and
keep you from repeating any issues. As we brainstorm with our team,
it’s best to create a risk register. As a refresher,
a risk register is a table or chart that contains your
team’s list of risks. You want to pose questions
to your team, like what could improve the outcome of the
project, or what could hurt or hinder it? You’ll list them all as if/then statements. For example, if a given event happens,
then here’s how the project is impacted. To help prioritize risks
within your risk register, you can calculate your risk exposure. Risk exposure is a way
to measure the potential future loss resulting from
a specific activity or event. A good method to calculate risk exposure
is to build a matrix like this one. When building out your matrix,
you’ll use two variables: risk impact and probability. Write “risk impact” at the top,
horizontal axis, and write “probability” on the side,
vertical axis. Mark high, medium, and low along each
axis as well, across the top from left to right and
down the side from top to bottom, because that’s how you’re
going to chart risk exposure. Add each risk to the chart at the cross
section of the impact the risk might have on your project and probability or
likelihood of the risk coming to pass. This is one technique, but
whatever strategy you use to examine your risk exposure,
your risks will need to be prioritized so that you know and your team knows which
ones to give immediate attention to. For anything that has a high impact
on your project, even if it has a low probability of occurring, make sure
to have a mitigation plan in place. How will you handle this risk
if it actually materializes? While a risk register is a great tool, it’s still likely that some
unforeseen risk will arise. It’s almost impossible to account for every single risk over
the course of a project. That’s where the ROAM technique can help. The ROAM technique—which stands for
resolved, owned, accepted, and mitigated—is used to help manage
actions after risks arise. Once a risk has materialized,
you need to decide what to do with it. If a risk has been eliminated and
will not be a problem, it goes into your “resolved” category. If you give a team member ownership over
a certain risk and entrust them to handle it, that risk goes into the “owned” category and is monitored through to completion. If the risk has been “accepted,” it has been agreed that nothing will be done about it. Finally, if some action has been taken
such that the risk has been mitigated, either reducing the likelihood
of it occurring or reducing the impact to the project,
it goes into the “mitigated” category. After each risk is placed into a category,
the team will discuss each risk and decide which should be prioritized. Awesome. Now you’ve learned a bit more about
how to differentiate risks and issues, as well as some new
techniques to manage various risks. Next, we’ll learn about how to share
these risks with your stakeholders and a technique called escalation. Sound intriguing? Head to the next video to learn more.