Stakeholder register: knowing who can stop the project

A stakeholder register lists everyone with an interest in a project — who they are, what they want, how much influence they have, and who is responsible for keeping them informed. It sounds like formality until the first time a project is delayed at the last moment by someone nobody had spoken to, which is a failure mode common enough to have its own resigned tone in most companies.

The register is not the point; the mapping is. Working out who can block this, and what each of them actually wants, is an afternoon's thinking that changes how the project is run.

What to record for each stakeholder

• Name and role, and the organisation if they are external.
• Their interest in the project stated in their words: what they gain, what they fear losing.
• Influence — can they stop it, delay it, or only comment? Be honest rather than polite about this.
• Current position: supportive, neutral, sceptical, opposed. Recording opposition is not disloyal; it is the input the plan needs.
• What they need from you: approval, information, involvement, or simply to be left alone.
• Communication: what they get, how often, in what form. A weekly email suits some; a fifteen-minute call suits others and is faster.
• Owner — who on your side holds the relationship. Unowned stakeholders become unpleasant surprises.
• Notes on the last substantive conversation, so a handover is possible.

Handle the register's sensitivity deliberately. It records opinions about named people — that someone is sceptical, or influential but disengaged — and it is personal data. Keep access to the project team, avoid characterisations you would not defend to the person's face, and remember that these documents are discoverable in disputes. Write it as though the subject might read it, because occasionally they do.

Building and using it

1. Brainstorm broadly first: sponsors, users, budget holders, technical owners, suppliers, compliance, anyone whose work changes because of the project. Missing stakeholders is a bigger risk than listing too many.
2. Rank by influence and interest — the classic four quadrants are enough: manage closely, keep satisfied, keep informed, monitor.
3. For the high-influence group, write what they actually want rather than what their role implies. These often differ.
4. Assign an owner per stakeholder and agree the communication rhythm with them, not for them.
5. Talk to the sceptics early. Objections raised at kick-off are cheap; the same objection at sign-off is a delay.
6. Update after each phase, and whenever someone changes role — a new budget holder resets the entire relationship.
7. Review before any major decision or milestone: who needs to know before this happens, not after.
8. Close it out at the end, noting who to thank and who to keep warm for the next project.

The quiet stakeholder problem

The person most likely to derail a project is rarely the loud objector — they are visible and can be worked with. It is the one with real authority who has not engaged, whose absence is read as consent, and who surfaces at the end with a well-founded objection nobody solicited. The register's most useful column is the one flagging high influence and low engagement, because that combination is where late surprises come from. Getting fifteen minutes with that person early is usually the highest-return activity in the whole project.

Ettex Records suits the register once it is more than a handful of rows: custom tables with typed fields for influence, position, communication frequency and owner; relations between tables so stakeholders link to the projects they touch; grid and kanban views with saved filters — high influence and disengaged, everyone one person owns, anyone not contacted this month; revision history where every change is tracked, which matters for a document about people; and row comments for the discussion. Contact details themselves belong in Ettex Contacts, the communication rhythm goes in Ettex Calendar, the project plan and status reports live in Ettex Docs, and the correspondence sits in Ettex Mail.

The boundary: Ettex has no stakeholder or engagement module. There is no influence-interest chart generated for you, no engagement scoring, no reminders when a stakeholder has not been contacted, no communication tracking against a plan, and no permission model that hides the register from the people described in it. It is a structured table you maintain — and given what it contains, deciding who can open it is worth a moment's thought. It is the input to the communications side of a project status report: who is told what, and how often.

Where stakeholder management fails

• Only the obvious stakeholders listed, missing the technical owner or the compliance function whose sign-off is mandatory.
• Influence recorded politely rather than accurately, so the map does not describe reality.
• No owner per stakeholder, meaning contact happens when someone remembers.
• Sceptics avoided until late, converting a cheap objection into an expensive one.
• High-influence, low-engagement people left alone because they are not asking for anything.
• Communication designed for your convenience rather than theirs.
• Never updated when people change roles, which is when relationships reset entirely.
• Written in language nobody would want to read about themselves.

The register lists people; two other artefacts decide what to do with them. A stakeholder analysis sorts them by influence and interest, and a raci matrix converts that into who decides, who does and who is merely told.

A stakeholder register is an afternoon that buys you the absence of late surprises. List broadly, rate influence honestly, give every name an owner — and go and find the powerful person who has not said anything yet.