Skip to content

Stakeholder Register

At a glance

  • Purpose: Identify everyone whose interest, influence, or attitude can affect the project, and record what that implies for how you engage them.
  • Use it when: At initiation and reviewed throughout. It feeds the communications plan and the RACI matrix.
  • Owner: The project manager.
  • Related: Module 02 · Lab 02 · Lab 05

A stakeholder register records everyone with an interest in the project and what their interest implies for how you engage them.

Copy the skeleton below and replace the bracketed text.

Register skeleton

# Stakeholder Register — [Project name]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Owner** | [Who maintains this register] |

## Stakeholder table

Rate interest and influence as **Low**, **Medium**, or **High**. Rate attitude as
**Supportive**, **Neutral**, **Resistant**, or **Unaware**.

| Name / group | Role | Interest | Influence | Attitude | What they need from the project |
| --- | --- | --- | --- | --- | --- |
| [Name] | [Role] | High | High | Supportive | [Their need] |
| [Name] | [Role] | Low | High | Neutral | [Their need] |

## Engagement strategy

For each high-influence or resistant stakeholder, state how you will engage them.

| Stakeholder | Strategy | Frequency | Owner |
| --- | --- | --- | --- |
| [Name] | [e.g. weekly demo, monthly written update] | [Weekly] | [Who] |

## Analysis notes

- **Key players** (high influence): [Who, and how to keep them aligned]
- **Watch closely** (high interest, low influence): [Who, and how to keep them informed]
- **Keep satisfied** (low interest, high influence): [Who, and how to avoid surprises]
- **Monitor** (low interest, low influence): [Who]

## Open questions

- [Something you do not yet know about a stakeholder]

How to use this template

  1. Identify by role and by name where a person is identifiable. "The users" cannot be analysed, contacted, or persuaded.
  2. Rate interest and influence separately. They are independent: a busy registrar may have high influence and low interest, and a vocal support team the reverse.
  3. Record attitude honestly, including resistant and unaware. A register of supportive stakeholders means the analysis stopped early.
  4. Derive an engagement action for every high-influence or resistant stakeholder. Those are the people who can stop the project, and they need a named owner for the relationship.
  5. Record what each stakeholder needs from the project, not what you would like to tell them. That column is what the communications plan is built from.
  6. Review after every milestone. Attitudes move when people see the product, and the register should change with them.

Field descriptions

Field What goes in it Watch out for
Name or group A person, or a genuinely identifiable group "End users", "management"
Role Their position relative to the project Job titles that hide the relationship
Interest Low / Medium / High — how much they care High interest assumed for everyone
Influence Low / Medium / High — how much they can affect the project Formal authority confused with influence
Attitude Supportive / Neutral / Resistant / Unaware Optimism substituted for observation
What they need The information or outcome they want What you want to tell them
Engagement strategy The specific approach, with frequency "Keep informed" as a strategy
Owner Who in the project owns that relationship Every relationship owned by the PM
Open questions What you do not yet know about them Nothing, which usually means nothing was asked

Worked example

From Lab 02, on the public service complaint system — invented stakeholders for teaching:

Name / group Role Interest Influence Attitude What they need Engagement
Director of services Sponsor High High Supportive Confidence the service improves measurably Fortnightly written update and milestone reviews
Data protection officer Compliance oversight Medium High Neutral Evidence that personal data handling is considered early Review at design and before release
Departmental IT operations Runs the service afterwards Low High Resistant — fears an unsupportable system To be consulted on the support model, and to have their concerns answered Monthly working session; joint support model
Complaints officers Daily users High Low Supportive but sceptical of the current system Involvement in design and training dates Two workshops and a pilot group
Citizens raising complaints Beneficiaries High Low Unaware Nothing directly; their interests are represented Represented through the service team

The most dangerous row is the third, not the first. Departmental IT operations has high influence, low interest, and a negative attitude — they can stop the service being accepted into support after the project closes, and nobody would notice until then. Meanwhile the citizens carry high interest and no influence, so their interests must be represented rather than consulted, which is a different engagement mode and worth stating explicitly.

Common mistakes

  • Categories instead of people. "The users" cannot be engaged, so the strategy column stays vague.
  • Influence confused with authority. Someone with no formal sign-off power can still block adoption — the IT operations row above is the standard example.
  • Optimistic attitudes. A register in which nobody is resistant has either met only the friendly stakeholders or is not being honest.
  • No engagement action for high-influence people. Analysis without an action changes nothing.
  • Written once and filed. Attitudes change as the product becomes visible; a stale register is worse than none because it gives false confidence.
  • Analysis paralysis. This is a working document, not a research project — an hour's careful thinking beats a fortnight's taxonomy.
  • Sensitive personal data collected. Record only what is needed for engagement decisions; attitudes and influence ratings are not a place for personal detail.