In regards to agile stakeholder management there are two important patterns I often see:
– Product Owners in general are really busy managing the “the business” or “the stakeholders” but no inventorisation and classification of these groups is being done.
– While the business or stakeholders are not mapped, we pretend to exactly know what “the business” wants and that we know “the business” will get mad if we do not deliver certain features on a certain time.
Buzzword bingo
The words business, business value and stakeholders function just as any other buzzword. Easy to use since most of us do not really understand the meaning. If someone tells us that “the business wants us to do something” we feel reassured. We have a purpose now and we are delivering business value. But this illustrious business isn’t one entity. It is a whole variety of people, departments and other forces with all their own specific interests and needs.
Without properly knowing stakeholders, business value is also an unknown.
Stakeholder mapping
There are many ways to create insights regarding stakeholders. One of my personal favorites is creating a stakeholder map. Easy to understand and to use. In a stakeholder map you plot each stakeholder based on influence and interest:
One very important remark is that a stakeholder map is dynamic. Just like roadmaps, product visions, product backlogs and other artefacts it will change from time to time. That is, if you actively use them.
Stakeholder map as tool for change
– When defining stakeholders in existing companies, end users often tend to end up as stakeholders with no influence and no interest. End users are out of reach of the teams.
– Stakeholder maps that are made for an existing situation will often reflect the current way a company is structured (relates to Conway’s law).
If your current stakeholder map isn’t the way you think it should be, you could use it as a tool that can facilitate a organisational change. I often create a current state and a desired state of it. After that I like to define sales pitches for each stakeholder in order to get them to a different quarter of the map. A very basic quick example from within an enterprise organisation:
Let’s say that this is the current story map. It is not yet how I like it to be. I would like my end users to be in the upper right corner and the managers more to the left. To be able to have it that way I first need the managers to buy my product/services in order to continue. My sales pitch is about cost benefits. I really want me and my team to be able to make our own technical decisions so I want the IT architect further away. My sales pitch is that my product is compliant to the companies standards. I’ll make sure I’ll get in contact with my end users so that the roadmap will be mainly fuelled by user requests and feedback. Those I value the most.
The orange lines show where I want my stakeholders to end up. The, very basic, sales pitch state the arguments I think will convince my stakeholders and get them on board.
TLDR;
– Without knowing you stakeholders and their influence & interests it is nearly impossible to create the right product.
– A stakeholder map is a snapshot and can changes over time or even per increment.
– A stakeholder map is a great way to visualise both the current and desired state and define the steps to take.