The Ripple Effect: How to identify ALL of your stakeholders
Can we really identify ALL stakeholders?
Once upon a time, I worked on an IT project with a lot of stakeholders. This project spanned several iterations over several years and impacted several thousands of people. Some groups of stakeholders overlapped and needed different sets of information at different times. It was a complex project with significant impact to large groups of stakeholders. It is one of the highest impact projects I've ever worked on.
I have been thinking about stakeholders lately and recently went back to review our original stakeholder analysis. Although this agile project made frequent updates to the project and OCM plans, I wanted to see how close we were to reality when we started. If I had to give us a grade for accuracy, I'd give us a C.
However, in this case a C is actually pretty darn good. We expect there to be ripples in the pond once we start dropping rocks. Sometimes those ripples cannot be anticipated; we are not fortune tellers. On a large, high impact project, we know that we are making our best guess at capturing ALL of our stakeholders. We can conduct interviews, focus groups, surveys, and still miss some group of people who are unaware at the outset. That's why it is so important to start the OCM process early and revise regularly because we learn as we progress. Being wrong isn't the worst thing; not learning is.
While we shouldn't use a degree of uncertainty as an excuse to do a slapdash job, we shouldn't get so hung up on perfection that we fail to make a beginning.
How do I identify Stakeholders?
Here are some techniques to start with when you are beginning to identify stakeholders for your project. *I'm assuming in this article you understand the definition of a stakeholder and that you value identifying them and analyzing them to ensure the success of your project. If you need a more basic explanation of what stakeholders are and why this is important, I'll post a different article and link it here later.
Start with a brainstorm:
The first rule of brainstorming is that we don't talk about brainstorming…wait, no. The first rule is that there are no bad ideas! Also, it's much better to brainstorm with others; we can't think of all the good ideas ourselves and variation in perspectives brings bigger badder storms so make your group diverse. Splash down every person or group who might care about this project and set it aside for a minute. Don't edit yet although I know you want to.
Concentric circles exercise:
In this exercise we are going to think of the project as the center of a circle. Picture it in your mind or draw it. I’ve provided an example for you here. First, list everyone who is closest to the circle; who touches it? If you (as an individual) were the center, this first ring would be your family, your partner(s), your best friend who you talk to frequently. For a project these "insiders" are the project team, project sponsors, and initiators. Yes, these people are stakeholders. Also included in this group can be people most invested or immediately impacted by the change. In an IT project these would be testers and end users. Think about the Change Impact analysis you have hopefully already done and who will be most affected.
Now think about the next level out. If you were the center of the circle, these would be coworkers, friends, people you interact with regularly, but aren’t in your inner circle. For our project these are going to be other users who may be impacted less than our main user group, application owners, customers; whoever is going to feel the ripple effects once the project goes live. Keep going to the next level and the next level: acquaintances and strangers in our individual person analogy. These are peripheral stakeholders who may not be affected much but may need to know, be curious, or who might affect the project from the outside. These might be other departments within your organization. If this is an IT project, think of other IT groups who might own connecting IT systems, helpdesk who field tickets from users having trouble, it might be other business groups outside of IT who use the system or use data that comes out of the system you are working on. Think about compliance, are there governmental or regulatory agencies who might have an interest in what you are doing? How does your project affect other companies or competitors in your industry, vendors, or business partners. Stakeholders may be outsiders who may put pressure on the project or who may pose some kind of risk such as environmental, political, social, or financial stakeholders.
Some projects are going to affect the community or our society outside of our own organization. These are certainly stakeholders. Think about social media companies and how their work has affected our society including how teens socialize and view themselves, how businesses market and sell their products, how political campaigns and elections are conducted. I’m certain these impacts were not completely understood at the outset of those projects; however, we have a duty to consider how our work effects stakeholders and understand what the unintended consequences have been, evaluate, and adjust based on our values.
Chronological exercise:
In this exercise, we are going to imagine we are going live today. As soon as we “flip the switch”, who is going to be calling (or sending you messages) wondering what the heck is going on? What would their concerns be? What would they want to know?
Now think about a few days or weeks down the road, who else would eventually figure out that something had changed and what would their concerns be? Keep in mind that you may have already listed these people in the previous exercises. That’s ok. We are using different techniques to hopefully gain different perspectives.
Now imagine you are at the close of the quarter or year. People are running reports, they are filing taxes, they might be conducting audits. Will any of that trigger someone to notice the change or need information about the change? Lastly, imagine we are a few years away from the change, who owns it and maintains it? How were subsequent changes decided and communicated?
Next Steps
Feel free to use the image I've created as a reminder of which groups you should be considering and think about which you frequently forget about. Hopefully I've mentioned somewhere in this article a group of stakeholders and you thought, “I never add that group to my stakeholder analysis”. These are just exercises which you might find helpful to ensure thoroughness if not prescience.
But listing stakeholders is just the first step in a stakeholder analysis. We touched on this briefly, but the next steps are to try to understand how influential each stakeholder is, what their current level of support is, and desired level of support is. We also want to put ourselves in their shoes and understand from each stakeholder's perspective what concerns they might have as well as what kinds of support they might need to successfully move through the change you have planned. We want to try to anticipate the natural resistance we might encounter during and after the change. But that's another article for another day.