Documenting stakeholders

You should always know the status of every stakeholder at any given point in a project’s life.

The stakeholder register is therefore one of the first project documents we produce and one of the last ones to be retired.

A good stakeholder register will have the following information about each stakeholder.

Identification information

• The stakeholder’s name and contact information
• The organization they represent
• Their relationship to the project (for example, sponsor)

Prioritization information

• Their level of power over the project
• Their level of interest in the project
• Your preferred engagement strategy

Engagement information

• Their expectations of the project
• The value they can deliver to the project
• Their preferred communication media and timing

You should also layout your stakeholder taxonomy, so that untrained users can decode what you mean by, for example, the sponsor or governance group.

Definition of your prioritization and engagement strategies is equally important; after all, your understanding of ‘high’ power might be quite different from mine!

A great stakeholder register also doubles as a communication plan for the project.

By keeping records of each contact linked to individual stakeholders, you can more efficiently manage your stakeholder time and effort.

Modern customer relationship management (CRM) software, such as Salesforce, Oracle, and Microsoft Dynamics, is ideal for this.

For the rest of us, a sample stakeholder register that is free to download, use, and share can be found here. 

---

Do I have to?!

Does every project need a stakeholder register?

The graphic introduced in the last Unit (Topic 1.9: Project Documents) suggests that you only need to prepare a formal stakeholder register for medium- or high-risk projects.

If that doesn’t make sense yet, don’t worry!

We will discuss what we mean by low/medium/high-risk projects more fully in the next Unit when we introduce the risk profile tool.

For now, though, understand that not every project demands a stakeholder register – many projects succeed without one!

So when does preparing one become necessary?

A rule of thumb for any project document is that the benefit of having it must be greater than the effort required to produce it.

In this instance, you should only prepare a separate, formal stakeholder register and communications plan if, within your project:

• Stakeholders can expect to have multiple contacts from different project team members 
• Stakeholders (including the project team) are likely to change throughout the life of the project (something that can be expected in long projects), or
• You need to evidence your engagement with stakeholders, for example, when there is a legislative or policy requirement for consultation or when there is a known group of hostile stakeholders.

That said, you should always follow the management process of identifying, prioritizing, and engaging your stakeholders.

What you subsequently record, however, should be fit for purpose, considering the proven benefits of having a clearly documented project methodology.