The most expensive sentence in any project is: "I didn't know it was decided that way." It is usually said by someone with the authority to reject the work — and said after the work is done. Stakeholder management exists to prevent that sentence.
Who counts as a stakeholder?
A stakeholder is anyone who affects the project or is affected by it. Not just the client and the team, but also:
- end users who will actually work with the result;
- the funder or grant provider, with their own conditions and reporting requirements;
- support functions — IT, finance, procurement — without whom nothing moves;
- management, who decide priorities and resources;
- external parties: partners, suppliers, the local community, regulators.
The rule is simple: if someone can stop the project, slow it down or refuse to accept the result, they are a stakeholder — whether or not the project plan mentions them.
Map interest and influence
Not everyone can or should be engaged the same way. The classic matrix sorts stakeholders on two axes: how much interest they have and how much influence.
| Influence / interest | Low interest | High interest |
|---|---|---|
| High influence | Keep satisfied — short summaries, no surprises | Manage closely — involve in decisions, meet regularly |
| Low influence | Monitor — general information is enough | Keep informed — they give the substantive feedback |
The exercise takes twenty minutes and saves months. Most late surprises come from the top-left box: someone holds a veto, but nobody talked to them because they were not visibly interested.
The RACI matrix: four roles, one kind of clarity
- R — Responsible. Does the work. There can be several.
- A — Accountable. Owns the outcome and accepts it. There is exactly one.
- C — Consulted. Asked for input before the decision. Two-way communication.
- I — Informed. Told after the decision. One-way communication.
An example for a single deliverable:
| Activity | Project manager | Client | Developer | Accountant |
|---|---|---|---|---|
| Approving requirements | R | A | C | I |
| Technical delivery | A | I | R | — |
| Budget change | R | A | I | C |
| Accepting the deliverable | C | A | R | I |
Three rules that make RACI useful
- Exactly one A per row. Two accountable people means nobody is accountable.
- Do not make everyone a C. If eight people must be consulted before any decision, no decisions get made. C is for those whose input genuinely changes the outcome.
- Fill it in together, not alone. The value of RACI is not the table but the conversation that filling it in produces. That is where mismatched assumptions surface.
A communication plan in one table
The stakeholder map and the RACI together answer "who learns what, and how often". Four columns are enough: audience, content, frequency, channel. For example: monthly status report to the steering group by email; weekly summary to the team; quarterly report to the funder on their form; a notice to end users before launch.
Without it, one of two things happens: everyone gets everything (and nobody reads it), or nobody gets anything (and everyone is surprised).
How Projektiassistent helps
Projektiassistent ties roles and accountability directly to the project structure: every deliverable and work package has an owner, and every significant decision lands in the decision log together with its rationale. Three months later, "who approved this and on what basis" is a question with an answer — without digging through old email. See also the tasks of a project manager.
Summary
Stakeholder management is not diplomacy, it is risk management. Map who has interest and who has influence, split accountability with RACI so every decision has exactly one owner, and agree who hears what and when. Then nobody turns up two months later saying they did not know.
If you want accountability and decisions recorded in one place, start here: projekt2.projektiassistent.ee.