BA Playbook: Stakeholder Register

To be successful, business analysts need knowledge, experience, and a practical toolkit. I would like to complement all the articles I already published about business analysis discipline, skills, and mindset, with a series of write-ups on tools and artifacts to use on projects. 

We’ll start with a stakeholder register — a list of individuals and groups involved in a project, indicating their roles, interests, and communication preferences.

As projects involve diverse groups of people from business, IT, project and change management, as well as external consultants and vendors, keeping track of who is who is essential. 

Business analysts, along with project managers (PMs, or their equivalents), are constantly on point to organize meetings, request information, or share documentation with the right audiences. The bigger the project, the easier it is to get lost in names, roles, and responsibilities. The longer the project, the more movement, assignments, and reassignments. On COTS (commercial-off-the-shelf) software implementations, organizations may even engage multiple vendors, each accountable for their own SOW (statement of work). 

In the ideal world, a business analyst would rely on a PM to manage the stakeholder register. In real life, a BA might have to be the one to create it.

Sometimes, a BA needs a draft version for the initial discovery meetings before a PM gets around to it. Moreover, these sessions can be a source of information for forming the register, through a discovery of the impacts of the proposed change on different parts of the organization. 

Then, there is the law of the jungle: whoever needs it most (or first), will be the one doing it.

Thus, business analysts, bearing the responsibility for getting stakeholders together at the start of the project for discovery, current state analysis, root cause investigation, and brainstorming business requirements and product features, need to know who their stakeholders are. Who should be invited to what meetings, who can provide what information, and who needs to be informed of what. And this is where the stakeholder register is indispensable. 

Let’s break it down into the main sections such a register requires.

1. Stakeholder details 

• Stakeholder name
• Title and department
• Party (this could distinguish business vs IT team, or client organization vs vendor representatives)
• Domain (capture what expertise each stakeholder brings, such as operations knowledge, compliance, business rules, or a specific business domain of sales, manufacturing, or customer service)

While this section will be used by everyone, capturing the domain of expertise is key for business analysis activities.

2. Contact information

• Email, phone number, and the indication of contact preference
• Location and mode of work (office, branch, city, and whether the stakeholder is working remotely or overseas)
• Time zone 

As a frequent meeting organizer, a BA must take into account the time zone of regular meeting participants. Nothing like a grumpy subject matter expert to spoil the mood in a requirements session.

3. Roles and access

While a RACI matrix will capture roles and responsibilities on a very granular basis, in the register, we want to summarize it, for example, capturing:

• Project role (sponsor, a subject matter expert (SME), PM, BA, consultant, test lead, or architect)
• Change management role (lead or change champion)
• Role in project or configuration management tools, e.g., reviewer, contributor, or approver

This section should be customized to align with the project methodology used in a particular organization.

4. Communication needs 

This section can be handy for generating lists: meeting invitees, communication recipients, or collaboration channel members. The columns can list key means of communication or collaboration, and Yes/No flags will indicate who requires what. 

The best way to use it is to filter it on “Yes” and then copy email addresses to have a current distribution list. Static distribution lists are notorious for getting out of date.

Columns may include:

• Daily standup meetings
• Weekly project update emails
• Requirements (meetings, change notifications, distribution of requirements artifacts)
• Product demos
• Steering committee updates
• Test execution reports

Essentially, this section becomes a communication plan indicating each stakeholder’s informational needs.

To these main sections, feel free to add anything else that may be specific to the initiative or your organization’s methodology.

A stakeholder register must be posted in a visible location accessible to all project members, with a clear procedure for updates and a designated owner. As a best practice, you should have the first version available for a project kick-off, and continue to update it as the scope evolves. 

You may get my Stakeholder Register Template as part of the Business Analysis Playbook, or create your own. Add, split, or merge columns as needed for your project. Create lists of values to manage consistency of information via drop-downs (in turn, this will help with filtering information.) 

And most importantly, use the register to keep track of your stakeholders, avoid missing anyone when sending updates or planning important meetings, and keep the team informed. Communication challenges remain one of the primary issues that both large and small projects encounter, because we are all human.

Training | Mentorship | Courses | Books | Downloads | LinkedIn | YouTube |BA Playbook