Planning 4 - Managing Risks
Google Project Management Certificate · Course 3: Project Planning - Putting It All Together
No project runs exactly to plan. Even the most experienced project manager builds a perfect schedule and then somebody calls in sick, or the guests arrive and nobody bought ice. Because that is simply the nature of projects, the sensible response is not to hope for the best but to anticipate what could go wrong and decide, in advance, what you would do about it.
That anticipating is risk management, and this module treats it as planning work in its own right. The logic loops: find the risks, judge how likely and how damaging each is, decide which deserve attention, plan a response, keep watching. The toolkit is small - brainstorming with a diverse team, the fishbone diagram, the risk register, the probability and impact matrix, and four standard mitigation moves. What you actually produce is a risk management plan: a living document listing the high-level risks and the mitigation for each, shared with the team and stakeholders so nobody is caught off guard.
Risk, issue, and risk management
Section titled “Risk, issue, and risk management”The link between the first two is the thing to remember: a risk that actually happens becomes an issue. Risks are the big what-ifs; issues are what is hurting you right now.
Risk management is not a one-time exercise. You run it repeatedly, because the picture keeps changing.
Why it is worth the effort
Section titled “Why it is worth the effort”Done well it gives you an understanding of what could go wrong, a list of who to consult about each risk, and a view of how each could be mitigated. Skipping it costs you:
- Missed goals, timelines, or success criteria. If the research analyst quits halfway through and there is no backup plan, the report misses its deadline.
- No sense of how flexible the plan is. There is rarely only one route to a project goal. Thinking risks through in advance shows where the plan can bend so you can pivot and still succeed - a standby supplier turns a failed order into an inconvenience rather than a crisis.
- Full exposure to the unforeseeable. Suppliers run short of stock; budgets get cut without warning. The process reduces the impact of surprises and frees resources for work that actually benefits the project.
For the running Plant Pals service at Office Green, two candidate risks: the new service web page is not live in time for launch, and the plant supplier runs low on the cacti and ferns the project needs. Neither is certain; both deserve a plan.
The risk management process
Section titled “The risk management process”Risk management is an ongoing practice across the whole life cycle, and usually takes some variation of these five phases.
Risks can be opportunities too
Section titled “Risks can be opportunities too”Risk is not automatically bad news. An opportunity is a potential positive outcome of a risk, and capitalising on one lets you reach the goal faster, more cheaply, or with less effort.
The useful part is that the same five phases apply. Identify, analyse, evaluate, treat, and control opportunities exactly as you do threats, using the same brainstorming and the same look back at project history, and record in the risk management plan how you would take advantage of each. Know what to do if things go wrong, but plan to seize what goes unexpectedly right.
Identifying risks
Section titled “Identifying risks”Brainstorming with the right people
Section titled “Brainstorming with the right people”Brainstorming is the most effective technique for surfacing risks with a team, because it lets a group share ideas spontaneously and without judgment. Your job is to convene that group - have the RACI chart to hand when deciding who to invite.
Make the group diverse. Different roles, backgrounds, and experience produce risks you would never reach alone: a veteran of several projects sees patterns, while a newer teammate brings a fresh perspective from previous teams.
The cause-and-effect (fishbone) diagram
Section titled “The cause-and-effect (fishbone) diagram”The move is to state a potential risk as the effect (the fish’s head, for example a supplier missing its deadlines) and work backwards into the causes that could produce it, sorted into categories along the spine. Categorising and then breaking each down further exposes the areas that could lead to a problem such as exceeding the budget, or letting scope creep (uncontrolled changes and growth affecting scope after the project begins) eat the timeline.
A related idea it is built to find: the root cause, the initial cause of a situation that introduces the problem or risk. Not every cause you list is the root cause.
-
Define the problem. State it clearly, put it at the head of the fish. Miguel, a project manager at Office Supply Inc., is planning a summer promotion with free delivery, and his company has struggled to deliver to downtown office buildings on time - so his problem is trouble delivering products to downtown office buildings on time.
-
Identify the categories. They change with the problem and the industry. Common ones: people, technology, materials, transportation, money, time, environment, procedures. Miguel picks people, technology, materials, transportation, and environment.
-
Brainstorm the causes. Fill each category with the team’s ideas. Miguel’s diagram ends up with people (lack of training, distractions, not enough people), technology (overcomplicated, outdated), materials (fragile packaging, lack of forklifts), transportation (trucks too small, trucks too big, not enough trucks), and environment (city traffic, busy elevators, long distances).
-
Analyse the causes. Test which is truly the root. More forklifts would speed loading, but when Miguel times loading and unloading the saving is negligible - so forklifts are a cause, not the cause. What stands out is that there is no set delivery schedule and the problem only appears in the city, not the suburbs, so traffic is implicated and moving departures ahead of rush hour is the fix worth making.
Getting a first list from a gen-AI tool
Section titled “Getting a first list from a gen-AI tool”A project charter may name only a few risks. A gen-AI tool such as Gemini can widen that list fast. Set the scene with real detail - act as a project manager overseeing development of a dog wellness app for a mid-size company offering dog walking, training, and pet supplies; review these project details and identify only major risks that could affect the timeline or budget - then paste in (or, with some tools, upload) the charter.
| Do | Why |
|---|---|
| Give lots of context | The more project detail in the prompt, the less generic the risks that come back |
| Ask what could go wrong, not just what could go better | Gen AI is strong at brainstorming, and this is a brainstorming job |
| Ask it to reformat | It generates text quickly, so challenge it to restructure until the format suits you and the team |
| Review with your own judgment | A long list may carry irrelevant items and still miss key areas - it is a starting point |
| Come back later | As new risks appear during the project, return with the specifics and brainstorm mitigation plans |
Like a human, a gen-AI tool cannot stop a risk becoming a problem that derails the project. It only helps you get ahead of risks sooner.
Assessing and prioritising risks
Section titled “Assessing and prioritising risks”Once the brainstorm is done, list the outcomes in a risk register - a table or chart containing your list of risks - and then assess them.
The probability and impact matrix
Section titled “The probability and impact matrix”A probability and impact matrix is a tool used to prioritise project risks. Two scales, each rated high, medium, or low:
| Dimension | Definition | Read the scale as |
|---|---|---|
| Impact | The damage a risk would cause if it occurs | High substantially alters the project · Low is a slight effect, not likely to derail anything |
| Probability | The likelihood that the risk occurs | High means very likely · Low means it could happen but probably will not |
Put the two together and you get the inherent risk rating.
- Unlikely, but it would hurt - still worth a written mitigation plan
- Could derail the project: detailed mitigation, named owner, watched closely
- Log it and move on - not the type to worry much about
- Likely, but a minor setback: monitor and keep a light workaround ready
Risk appetite
Section titled “Risk appetite”Risk appetite is the willingness of an organisation to accept the possible outcomes of a risk. How you view and manage each risk depends on it, and you, your team, and your stakeholders may each have a different appetite for the same risk. Low-level risks that cause minor setbacks are far more tolerable than high-level ones that could completely derail the project. When the assessment is done, go back and update the risk register with the high, medium, and low ratings.
Types of risk
Section titled “Types of risk”The three big ones
Section titled “The three big ones”| Type | What it is | Why it matters |
|---|---|---|
| Time risk | Project tasks take longer than anticipated | Time is money - poor time management depletes the budget and upsets stakeholders through delays |
| Budget risk | Costs rise through poor planning or expanding scope | The budget is the basis of cost control; overspend and you may not be able to pay suppliers, which damages the company’s reputation |
| Scope risk | The project does not produce the results set out in the goals | Deliverables stakeholders or customers will not accept defeat the purpose of the whole project |
External risks
Section titled “External risks”External risks result from factors outside the company that you have little or no control over - an environmental risk such as a major storm, or a legal risk such as a change in regulatory requirements. There are endless types of risk and there will never be a prescription covering every one; having a plan is what makes you readier for whatever turns up.
Single points of failure
Section titled “Single points of failure”The Office Green example is a power outage taking down the internal database that holds every piece of project information: until it is back up, nobody can do their job. A cheap mitigation is budgeting for a separate cloud service as a backup for all project documentation.
The other common form is people rather than systems. Projects lean on subject matter experts (SMEs), team members with deep understanding of a particular job, process, department, function, technology, machine, material, or type of equipment, who advise throughout the life cycle. Having only one SME familiar with a critical system is a single point of failure - one perspective, nobody to offer another. Identify and monitor these early, because they hit timeline, budget, and scope alike.
Dependencies
Section titled “Dependencies”Because they are the links connecting one task to another, dependencies are a large source of risk. Task a teammate with hiring a plant supplier and nobody can place orders until that contract is signed - and if they miss the deadline and then go on holiday for a week, the timeline slips. A practical countermeasure is asking everyone to share their out-of-office plans at the start of the project, so backup plans can be built around known absences.
| Kind | Meaning | Example |
|---|---|---|
| Internal dependency | Within the project, in your team’s control | Website design must be approved before development can begin |
| External dependency | Outside your control | A lighter rain season at the vendor’s farm means fewer plants to sell |
Four dependency relationships are worth knowing by name:
| Type | Rule | Everyday example |
|---|---|---|
| Finish to Start (FS) | Task A must finish before Task B starts. The most common type, a natural progression | Socks on before shoes on |
| Finish to Finish (FF) | Task A must finish before Task B can finish. Uncommon | Finish the icing before you can finish decorating the cake |
| Start to Start (SS) | Task B cannot begin until Task A begins, so the two run in parallel | Pay for the train ride, then board the train |
| Start to Finish (SF) | Task A must begin before Task B can be completed | Your friend cannot finish his shift until his coworker starts hers |
A dependency graph draws these relationships so you can see the flow of work, and the risk hiding in it. Making sandwiches: gather materials (A), then jelly on one slice (B) and peanut butter on the other (C) run in parallel, both must finish before the slices are pressed together (D), and only then do you serve (E). Anything waiting on two predecessors, like D, is where delay risk concentrates.
Mitigation strategies
Section titled “Mitigation strategies”| Strategy | What you do | Office Green example |
|---|---|---|
| Avoid | Sidestep the situation altogether | A contractor has a poor reputation for meeting deadlines, so you hire a different one |
| Accept | Agree the risk may happen, monitor it, and be prepared to live with it. Suits risks low in both probability and impact | A planter style is back-ordered and a restock problem could delay client deliveries by two days; onboarding a new supplier would take two weeks, so accepting is the cheaper headache |
| Reduce or control | Keep the risky option but add controls that shrink the damage | Hire the deadline-slipping contractor anyway because the work is excellent, then add daily check-in meetings so nothing drifts |
| Transfer | Shift responsibility for the risk to another party | Rather than growing plants on site, where bad weather or pests could ruin the product, outsource production to local suppliers so you can switch supplier over quality |
The same four strategies on a single point of failure
Section titled “The same four strategies on a single point of failure”Office Green buys most of its seeds from a South American supplier, and that country’s government announces an export tax that pushes the price out of reach. Framed here as avoid, minimise, transfer, accept, each strategy offers a way out:
- Avoid - switch to a different seed that is widely available in several locations.
- Minimise - buy from the original supplier and one in a neighbouring country, since a single tax change is unlikely to hit both. Mitigations like this are often called workarounds, and they start with admitting the risk exists.
- Transfer - buy through a North American supplier that sources from several South American countries, handing them the regulatory risk and cost.
- Accept - treat it as a normal cost of doing business, either actively by setting aside extra funds to buy your way out of trouble, or passively by doing nothing.
The risk management plan
Section titled “The risk management plan”Because risk management runs through planning and execution, the plan is updated regularly: add newly identified risks, remove risks that are no longer relevant, and revise mitigation plans as they change.
What goes in it
Section titled “What goes in it”| Section | What it holds |
|---|---|
| Company and project name | Right at the top of the document |
| Document author | So anyone reviewing the plan knows exactly who to contact with questions |
| Document status | In progress while you build it, final once complete |
| Created and last-updated dates | Small details, but being transparent about dates tells stakeholders how current the document is |
| Document objective | One line, for example: to outline mitigation plans for Project Plant Pals |
| Executive summary | A brief introduction to the normal conditions of the project, plus an outline of the potential risks |
| Risk register | The core table: each risk, its inherent risk rating, and its mitigation plan |
| Appendix | The probability and impact charts, and the probability and impact matrix used for the assessment |
A filled-in register row from the Plant Pals example: the risk is the vendor falling behind on a deadline, the inherent risk rating is medium, and the mitigation is daily meetings with the vendor to help them stay on task.
Once the plan is filled out, share it with your team and stakeholders to get their input and confirm everyone is aligned.
Communicating risks to stakeholders
Section titled “Communicating risks to stakeholders”It is not enough for you and the team to know the biggest risks. Stakeholders need to know too, because if they are unaware they are less equipped to help you when something goes wrong - they cannot release extra budget or extra resources for a problem they never heard about. Worse, a stakeholder blindsided by an issue will ask whether you knew it could happen and why you did not say so sooner, and that erodes trust in you as the project’s leader.
Communicating early and often about medium and high risks sets expectations for the execution phase, shows you have already planned mitigations, and lets you suggest how stakeholders might help if a risk arises. Match the channel to the severity:
| Severity | How to communicate |
|---|---|
| Low | An email is enough - list a few relevant low-level risks in the weekly planning update with a brief note on how you would address them |
| Medium | A direct email to the stakeholder with more specifics and a detailed mitigation explanation, linking to the risk management plan. Put urgent in the subject line if it warrants it |
| High | Thorough and direct: add an agenda item to the project plan meeting, present the risk and your mitigation, then collect feedback and ask how they would handle it |
Revision summary
Section titled “Revision summary”Next: Communication & Documentation → - keeping everyone informed and the plan findable.