Risks and Stakeholders: The Two Questions Most Project Plans Skip
Most projects don't fail because the work was too hard. They fail because nobody knew who could say yes, and nobody wrote down what could go wrong. Here's how to answer both questions before kickoff.
4 min read
Every project plan has a timeline. Most have a budget. Surprisingly few have honest answers to the two questions that actually determine whether the thing ships: who can say yes, and what could go wrong? These get skipped because they're uncomfortable. Naming stakeholders means admitting that someone outside your team holds veto power. Naming risks means writing down, in advance, the ways you might fail. It's far more pleasant to draw a Gantt chart and hope.
But projects rarely die from bad estimates. They die in the gap between "we built it" and "legal hadn't reviewed it," or in the three weeks nobody moved because two directors each assumed the other was deciding. Those aren't scheduling problems. They're mapping problems.
Map the stakeholders in three buckets, not one
The word "stakeholder" is nearly useless because it flattens wildly different relationships into one list. Split it up before kickoff:
Deciders — the people who can change scope, reallocate budget, or kill the project. Usually one or two. If your list has six, you don't have deciders, you have a committee, and you should find out who actually breaks ties.
Approvers — whoever signs off on the final deliverable. Legal, security, brand, a client's procurement lead. These are the ones who show up in week eleven with objections that should have surfaced in week two. Name them early and tell them when their gate is coming.
The informed — people affected by the outcome who don't get a vote: support teams, adjacent squads, the customers whose workflow changes. They need a rhythm of updates, not consultation. Confusing this group with deciders is how a simple project acquires nine opinions.
Write each name down with the decision they own. "Priya — approves final copy." "Marcus — signs off on data handling." Vague entries like "Marketing" are a future argument with a delay attached. This is exactly the distinction a RACI matrix encodes, and it's why Casperry enforces exactly one Accountable per task — Responsible, Consulted, and Informed can be as many people as reality requires, but ownership can never be split into ambiguity.
Name the risks that are actually risks
A risk register full of entries like "timeline may slip" is decoration. Useful risks are specific, have a trigger, and have an owner. Push for the ones that make people shift in their chairs:
- Dependency risks — we're waiting on a team that hasn't committed to a date.
- Approval risks — the security review historically takes four weeks and we budgeted one.
- Key-person risks — one engineer understands the legacy integration, and she's on leave in March.
- Assumption risks — we assumed the API supports bulk writes. Nobody has checked.
- Political risks — a stakeholder disagreed with the premise and went quiet rather than agreeing.
For each, note the early warning sign and who's watching for it. The point of a risk register isn't prediction; it's shortening the time between a problem appearing and someone recognizing it as the problem you already named. When things do go sideways, the incident deserves a record linked to the project it damaged — tracking disruptions as first-class Events, rather than as a subject line in someone's inbox, is what turns a painful quarter into an institutional lesson.
The counterargument: don't turn planning into a ritual
It's worth saying that risk registers and stakeholder maps can become their own failure mode. A team that spends two weeks enumerating thirty-four risks, assigns each a probability score to one decimal place, and then never reopens the document has bought nothing but a feeling. Some projects are small enough, or reversible enough, that the fastest way to discover the risks is to start and see what breaks. Heavy ceremony can also give false comfort: the genuinely dangerous risks are usually the ones nobody thought to write down, and a full register can make a team feel covered when it isn't. The honest test is proportionality — map stakeholders in depth when approval chains are long and reversal is expensive; keep it to a five-minute whiteboard when it isn't.
Keep the map alive
Both documents rot quickly. Stakeholders change roles, risks retire, new ones appear the moment scope shifts. The fix is to attach them to the work rather than to a file nobody opens: ownership recorded on the task, disruptions logged against the project, and a visible trail from the original request through to delivery so that six months later, "why did we build it this way?" has an answer. When a project's Source view shows the requests and events that led to it, the stakeholder map and the risk log stop being planning artifacts and become the project's memory.
If you're tired of ownership living in email threads and risks living in a spreadsheet no one has opened since kickoff, Casperry is built to keep both connected to the work itself. Worth a look next time you're mapping a project.