Once you’ve got your stakeholder list — the one from the stakeholder list document, filled in with names, titles, and notes — the next step is to stop looking at it as a flat list and start grouping them.

A flat list of twenty names is hard to work with. You can’t send the same email to everyone. You can’t run the same meeting with everyone. You can’t make the same promises to everyone. So you split them up.

Why group them?

People on your stakeholder list have different relationships to the project. Some care about the budget. Some care about the timeline. Some care about how the thing works. Some care about how it makes them look. Some just want to be told things won’t break.

Grouping them lets you talk to each group in the language that makes sense to them. A group of end users needs different information than a group of sponsors. A group of technical reviewers needs different information than a group of compliance people.

It also helps you spot gaps. If you group everyone and one group has only one person, that’s worth paying attention to. If a whole category is empty, you might be missing stakeholders you haven’t thought of yet.

How to group them

There’s no single right way. The two most useful approaches are by role and by goal.

By role

This is the simplest. Group people by what they do on the project:

  • Sponsors — the people funding it, signing off on it
  • Project team — the people doing the work
  • End users — the people who will actually use the output
  • Support/maintenance — the people who pick up the pieces when it’s handed over
  • External parties — vendors, regulators, partners

This works well early on, when you’re still figuring things out. It’s intuitive and matches how most organisations are structured, so it’s easy to communicate.

By goal or interest

This is more nuanced. Group people by what they care about:

  • Budget-conscious — anyone whose primary concern is cost
  • Timeline-conscious — anyone whose primary concern is speed or deadlines
  • Quality-conscious — anyone whose primary concern is how well it works
  • Risk-conscious — anyone whose primary concern is what could go wrong
  • Visibility-conscious — anyone whose primary concern is how this looks to their bosses or the public

This is more useful later, when you’re planning communications or managing expectations. It tells you what angle to lead with in a conversation. Talk to the budget-conscious person about cost. Talk to the visibility-conscious person about outcomes.

You can also combine both. A stakeholder might be in the “end users” role group and the “quality-conscious” interest group. That’s fine. The groups aren’t mutually exclusive.

What to do with the groups

Once they’re grouped, you can:

  • Tailor your communications. Each group gets the format and detail level they need.
  • Plan your meetings. Don’t bring the whole list to every meeting. Bring the relevant group.
  • Assign engagement owners. Someone should own the relationship with each group.
  • Track concerns by group. If a whole group is unhappy about something, that’s a signal worth acting on.

Download

Stakeholder Roles Groups Document (docx)

It’s blank. That’s the point. Fill it with your project’s reality.