Topic 7 — Risk and stakeholder management

Goal: See trouble before it hits and keep stakeholders aligned.

Lesson 7.1 — The thing that could go wrong

Three days into the driver-app project, Renata is in a kickoff at Cartwheel when Marcus, the tech lead, says it almost in passing: "The maps SDK we need is still in beta. If they change the API before we ship, we redo a week of work." Then he moves on to the next slide.

Renata writes it down. Not because anything has broken (nothing has) but because something might.

That sentence is a risk: anything that might go wrong and threaten the project. A vendor's beta SDK changing under you. A key engineer taking the leave everyone knows is coming. A requirement Priya hasn't fully pinned down. A technical unknown nobody has tried. None of these are problems today. Every one could be next month.

In her hotel-events life, Renata did this on instinct. A 300-person conference always had a "what if the caterer is late" plan and a "what if it rains" tent on standby. Nobody called it risk management. It was just how you ran an event you couldn't afford to have blow up in front of the guests.

A risk is a problem that hasn't happened yet, which is exactly why it's still cheap to deal with. The calm project managers aren't the ones nothing goes wrong for. They're the ones who wrote it down on day three.

Lesson 7.2 — The four-step loop

So Renata has a risk on a sticky note. Now what? She wants a habit she can run on every project, not a wall of sticky notes. The standard one is four steps.

1. Identify. Get the team in a room and ask the blunt question: "What could derail this?" Marcus knows the technical landmines, Jamie the QA engineer knows where things have broken before, Priya knows which requirements are still soft. The people doing the work see risks the manager never would, so you ask them, out loud, early.

2. Assess. You can't treat every risk as a five-alarm fire, so you score each one two ways: likelihood (how probable is it?) and impact (how bad if it happens?). The beta-SDK risk is medium likelihood, high impact, so that one gets attention. "The office coffee machine breaks" is high likelihood, near-zero impact, so that one does not. (More on this in 7.3.)

3. Plan a response. For the risks that score high, decide now what you'll do, while it's still hypothetical and cheap. (The four kinds of response are the next lesson.)

4. Monitor. Risks aren't a one-time list; they shift as the project moves. So you keep a risk register, a living document with one row per risk and its likelihood, impact, owner, and planned response. Renata revisits hers every week. It's the artifact that turns "I have a bad feeling about the vendor" into something the team can act on.

Identify, assess, respond, monitor, then loop. That's the whole engine.

Lesson 7.3 — Likelihood times impact, and the four responses

Renata's register has eleven rows and she has time to seriously plan for maybe four. Which four?

She scores each risk on likelihood × impact. A simple high/medium/low on each axis is enough; you're not doing math, you're sorting. The risks that land high-likelihood and high-impact go to the top of the pile. A rare, minor risk sits at the bottom and just gets watched.

For the ones at the top, she picks one of four responses:

• Avoid: change the plan so the risk can't happen. Drop the beta SDK and use the stable, older mapping library, even though it's less slick.
• Reduce (mitigate): lower the likelihood or the impact. Wrap the SDK in a thin adapter so that if the API changes, only one file breaks instead of twenty.
• Transfer: move the risk to someone else. Pay for the vendor's paid support tier so they owe you a fix; insurance is the classic example.
• Accept: decide the risk is small enough to live with and just keep an eye on it. You document it and move on.

For any serious risk, she also prepares a contingency, a backup plan she can pull off the shelf the day it goes wrong. If the beta SDK breaks, the contingency is "switch to the stable library; Marcus has scoped it at two days." She lines up a backup vendor before she needs one, and builds a few days of slack into the schedule so a slip doesn't blow the launch date.

The point of planning a response is to make the bad day boring. When the risk hits, you're not panicking; you're running step two of a plan you wrote weeks ago.

Lesson 7.4 — Risk vs. issue, and the RAID log

A week later the beta SDK doesn't change. But the vendor's servers go down for a full day, and the team can't test. That wasn't on Renata's register. It's not a risk anymore. It's happening right now.

That's an issue: a problem that has already happened. A risk is a potential future problem; an issue is a present one, and the two need different moves. A risk gets a plan you hold in reserve. An issue gets action today: fix it, tell the people it affects, adjust the plan.

Good risk management is mostly the art of turning would-be issues into managed risks: catching them while they're still on the future side of that line, so you meet them with a plan instead of a scramble.

The worst outcome in any project is a problem that was completely foreseeable that nobody planned for. That's the gap this whole topic closes.

Many teams widen the lens with a RAID log, which tracks four things side by side:

• Risks: what might go wrong (your risk register is this column).
• Assumptions: what you're taking for granted as true ("the vendor's free tier is enough"). When an assumption turns out false, it often becomes a risk or an issue.
• Issues: what has already gone wrong.
• Dependencies: what you're waiting on from someone else (the design team's icons, a legal sign-off, another squad's API).

The risk register is just the R slice of a RAID log. The fuller view catches trouble that doesn't fit neatly into "risk": the shaky assumption, the dependency on a team that doesn't report to you. For Renata, the dependencies column matters most, since half of what can sink her launch lives on other people's plates.

Lesson 7.5 — Stakeholders, and the one habit that protects trust

Renata has no one reporting to her. Marcus doesn't have to take her estimate seriously. Tomás, the engineering director, can move her launch date with one sentence. Priya owns what gets built. Renata owns delivery, and she can't order any of these people to do anything.

That's the job. A project manager runs on influence, not authority, and the raw material of influence is your stakeholders: anyone affected by or interested in the project. The team, leadership, the customer couriers, the support folks, the departments downstream. Managing them well is not office politics. Without a chain of command, it's the only way the work moves at all.

The first move is to map them. The standard tool is a power/interest grid: place each stakeholder by how much power they hold over the project and how much interest they have in it. ("Power" is the standard term here, and it covers the same idea as "influence" — your ability to sway the project — so don't let the two words trip you up.) That gives four groups, each with its own communication strategy:

	Low interest	High interest
High power	Keep satisfied: concise high-level updates	Manage closely: engage often, deep involvement
Low power	Monitor: minimal effort	Keep informed: regular updates

Tomás is high power and, once the project's underway, high interest, so manage closely: a short status with dates and the top risks. Marcus and Jamie are the team, so keep informed with the full detail they need. A VP who controls budget but never reads the updates is high power, low interest, so keep satisfied with a brief that doesn't drown them. Tailor the message to the person: executives want the headline and the risks, the team wants the weeds.

And underneath all of it sits the single most important habit in the role. Manage expectations early and honestly. When the beta SDK actually breaks and the launch is at risk, Renata does the thing that feels worst and is right: she tells Tomás that day, with the size of the slip and her plan, before he hears it anywhere else.

Surprises destroy trust. Early heads-ups protect it. A late deadline everyone saw coming is a managed risk; the same delay sprung at the last minute is a betrayal.

It always feels safer to wait and hope it sorts itself out. It never does. The project managers leadership trusts to run anything are the ones who say the hard thing while it's still early enough to fix.

Worked example — The vendor goes dark

Walk it end to end. Cartwheel's driver app depends on a mapping SDK that, in week one, Marcus flagged as still in beta.

Identify. In kickoff, Renata logs it: "Maps SDK is beta; API could change, or the vendor could be flaky." Row one of her risk register.

Assess. Likelihood medium, impact high. It goes near the top.

Respond. No equally good alternative exists yet, so she can't avoid it. She reduces: Marcus wraps the SDK in an adapter so a breaking change touches one file. She adds a contingency (the stable library, pre-scoped at two days) and three days of schedule slack. On her RAID log she also notes the assumption ("the free tier is reliable enough") and the dependency (the vendor's uptime, which she doesn't control).

The risk becomes an issue. Week six, the vendor's servers go down for a day and testing stalls. Now it's an issue, and Renata switches modes: the team works around it using the adapter's mock layer, and she pulls one day from her slack.

Stakeholders. She tells Tomás the same day (high power, high interest, manage closely) with a two-line status: "Vendor outage cost us a test day; we absorbed it with built-in slack; launch date holds." The team (keep informed) already knows the technical detail. Because she'd named the risk in week one and flagged the slip the day it happened, Tomás's reaction is a thumbs-up, not a fire drill.

One foreseeable risk, planned for in advance, met with a contingency, and communicated early. That is the entire topic working as one machine.