Stakeholder mapping should be the first step to any large scale project. It will give you valuable insights that you can use on every step along the way. It will also help you figure who to talk to when things aren't working out. Today we show you how to do it.
You know what? I'm not going to act like mapping stakeholders is fun. I mean come on, at the end of the day, it's just a table that explains everyone's role and influence on the project. In a lot of companies, this isn't relevant, since roles are so blended. However, in a more traditional company, and in massive scale enterprises, this little sheet of paper is crucial. If roles are rigid, and if there is a lot of politics in your organization, this can reduce headaches greatly. Even if roles don't matter as much, this can prove to be an interesting foray into your company culture. Maybe it will highlight some flaws, in other words, it can't hurt.
Get off the beaten path.
First of all, don't base this off your company's organizational chart. It might be accurate, but let's get real, most of the time, it isn't. Power often lies where it shouldn't, people have tasks that don't fit their title, and decision makers aren't always who you think. Base this on reality, not on what it should be. Hey, maybe that will solve other problems, you know? Also, don't stick to a model if it doesn't fit. I provide one at the end, but it isn't optimal by any means. Companies are wildly different these days. Collaboration projects might breeze through one, and get stalled repeatedly in another.
Then act on it. If you follow this blog, you'll find out that one of my biggest pet peeves is people producing useless documentation. If you do stakeholder mapping and then shelve it, congrats, you just wasted your time. Use this information to drive your project forward. It will help you understand and decode signals. Why is this getting stopped? Did I give proper notice or credit to this person? Am I even talking to the right person? All the answers will be in this table if you do it right.
The end game is simple here. This is a boring process, but if done right, it can end up being your best tool when navigating the different priorities of your coworkers. It's pointless to just bash your head against the wall, try to understand how it was built, and maybe then you can actually smash it with your head. Figure out who does what, and suddenly everything goes easier. This might look like an old school way, but face it, it just works.
Here is a really basic example of what it should look like in the end. (You can make it prettier to look at, obviously.)
- Selling the software of their choice to IT
- Robust blogging
- All employee communication method
Medium - Will bring various choices and do first pick through of options
- Overloaded with number of platforms used
- Managing BYOD
- Built in security
- Low management solution
- SOC2 compliant
High - Final decision as far as security and compatibility goes
- All projects are clumsily done through email
- Version tracking on documents
- Easy way to locate talent within company
- Simple file sharing
Low - No decision power per se, but ultimately will be the ones who affect adoption.
- Evaluating ROI
- Getting a quick overview of the business
- Direct communication method with all employees
- Way to track projects at all times
- Low overall cost
Very high - Final decision, controls the budget
Still have questions around intranets? Chat with one of our intranet experts on how to implement your solution.