“Behind good brands lie stakeholder companies.”: – Will Hutton
According to Dan Brown –
There are users — the people who will use your product.
There are collaborators — the people with whom you will build the product.
And then there are stakeholders — the people who perhaps don’t have a clear role, but do have an interest in your work.
Stakeholder management is a discipline that helps us to improve our relationship with our stakeholders. It involves systematically identifying stakeholders; analyzing their needs and expectations; and planning future engagements with them.
In Scrum, a stakeholder is anyone with a vested interest in the product who is not part of the Scrum Team. These are the people who’ll help you discover, develop, release, support and promote the product. A Product Owner has to be in constant touch with the key stakeholders to maximize the value of the product.
Why is it so Important?
As Product Owners we are delivering values to our end users. In Scrum, only way to measure the success or failure of an increment is via stakeholder feedback. For example, if after project Go-Live, a service response time is poor and you get a first-hand feedback from your stakeholder, then as a product owner, it is an opportunity for you to put corrective measures in the upcoming sprints.
So long as the Product Owners and the stakeholders are heading towards a common goal; receiving inputs and feedback from the different stakeholders becomes easier to manage. In most cases, hearing back from different perspectives can help outline any potential issues, risks or improvements Project Owners might have otherwise missed.
As I said in the beginning, stakeholders are not part of the Scrum team, that’s why sometimes stakeholders are considered as free resources can do the work with you, that’s why you as a Product Owner need to know how to manage them and keep them interested to that extent, how they will get involved and what will they gain from these involvements.
How to go about it?
The process of Stakeholder management consists of following phases:
* Identify Stakeholders
As a first step, one should have a list of all potential stakeholders. Without right set of stakeholders your Sprint review sessions are meaningless. Once created, list should be periodically updated and reviewed. For better accessibility, stakeholder list (map) should be kept at a central place like team SharePoint or Confluence spaces.
Usually identification is done towards the start of a new project. However, it (identification) can also be done post go-live, once service is operational. You can start stakeholder identification by asking the following questions in a brainstorming session:
- Who is affected positively and negatively by the project?
- Who makes the decisions about money?
- Who are the suppliers?
- Who are the end users?
- Who could solve potential problems with the project?
- Who is in charge of assigning or procuring resources or facilities?
* Stakeholder Analysis
Once you have the stakeholder map ready, it is very important to analyze every stakeholder as no two stakeholders will have same interest in your project work. Being a busy Product Owner, it is not possible for you to focus equally on each stakeholder. As a next step, you will have to categories your stakeholders based on their interest and influence on the project.
This categorization will help us in coming up with an engagement plan (at a later stage) based on the popular stakeholder Influence/interest framework.
Establishing a level of interest, influence and/or impact will enable you to interact more efficiently with a particular stakeholder.
To measure the possible influence of your stakeholders, identify their level on a scale of high, medium to low:
High: Stakeholder with strong ability to impact your project.
Medium: Stakeholder with a significant interest in, but a lower level of power to affect the project.
Low: Stakeholder with little ability to affect the project.
* Stakeholder Engagement
Once you have identified stakeholders, categorize them according to their interest and influence, next step is to come up with a detailed communication/engagement plan. Like Scrum being an empirical (based on what is experienced or seen and not on theory) process, this engagement plan has to be a live document which will keep on changing till the time project is LIVE.
Stakeholder engagement plan consists of:
- Name of the stakeholder
- Mode of communication (meeting, email, report)
- Frequency of communication (daily, weekly, monthly, need basis)
- His current level of engagement (e.g. supportive, neutral or difficult)
- Target/desired level of engagement
Altogether, I recommend three things that can be helpful to start with stakeholder management:
- Be aware of the fact that every product has its stakeholders. There are chances that you have not listed them yet or have not yet come up with a stakeholder map.
- Don’t worry, it’s never too late. Start with an initial stakeholder map, categorize them according to the interest/influence framework. Refine stakeholder map over time (In the true Agile way).
- Decide on specific ways of collaborating and communicating with each group/person.
Appreciate your feedback!