- Setting up Auditing & Logging of Files/Objects Using Native Windows File Server Tools - 16th October 2020
- Designing Key Performance Indicators (KPI) - 15th July 2020
- DDOS Attacks and Website Hacking - 6th July 2020
Stakeholder Management: Using the Power-Interest Grid to Manage Stakeholders Better
Using the Power-Interest Grid to Aid in Stakeholder Management
I’ve come across, during my career as well as studying for certification, various takes on the same theme – stakeholder management using the Power Interest Grid. In this blog, I will cover my approach for classifying and managing stakeholders using the grid, and recommendations for engaging with the different stakeholder groups.
Stakeholder management is a critical function of a Programme or Product Manager. Having technology adopted, particularly within an organisation if that technology is enabling a larger transformation objective, is critical to the success of the initiative. What makes, or breaks, an initiative meeting a target, I have found, is the level of support stakeholders give the initiative. It’s crucial to the success of a product or initiative to engage the right stakeholders and to work with them in the right way. But first, we need to define what stakeholders are, as there are slight variations between what Scrum define it as, and the way most people use it at work.
Stakeholders – What are They?
A stakeholder generally means anyone who has a stake in the something – in our case a programme or product. A stakeholder is someone who is affected by, or who shows an interest in, that programme or product. This is the definition most people use at work – it’s a definition that closely matches the actual definition of the word and is intuitively true to us.
However, for managing a programme or initiative, it’s better if we’re a little more exact and set the boundary for what is a stakeholder. While the above definition includes customers and users, it is commonly used to refer to the internal stakeholders, i.e. people working within the programme or on the product. I personally prefer to include the Programme Manager, Product Owner and Scrum Master in this definition, however, strictly speaking, the Scrum framework excludes them (as they are responsible for managing the product or programme and thus aren’t stakeholders to be managed).
Generally speaking, stakeholders are people whose help you need to develop, release, and provide the something to meet an objective. Who these people are obviously depends on the nature of the organisation and specifics of the programme or product. For a commercial product, the group will (or should) include marketing, sales, support, and management. For an organisational change programme it might comprise legal, finance, and human resources. For a platform used internally, such as a data warehouse, the stakeholders may be operations, business units, and management.
Now that we know what a stakeholder is, the question is, how to we identify them and classify them into groups so that we can focus our efforts into managing them more effectively.
Our goal for stakeholder analysis is to manage stakeholders better by focusing our efforts into an approach that
- Allocates our resources better. This means we know how much effort to spend on each type of stakeholder. i.e. we don’t spend more time/effort, than is necessary, on a stakeholder group that is less important than another group.
- Uses messaging that matches the interests and influence of the stakeholders.
- Generates stakeholder buy-in through using an appropriate engagement format
- Keeps them involved by giving them an appraisal of the situation and having them do what we need them to do in order to make progress.
For this, a common technique used is the Power Interest Grid. The grid essentially classifies stakeholders into 4 groups based on their high-or-low interest in what we’re doing and their high-or-low power over what we’re doing. This grid is shown below.
The grid classifies stakeholders into 4 groups, based on a rising scale of the interest and power/influence they have in the programme or product.
A stakeholder will usually be interested if the programme or product affects them or their department by some form of action they have to perform, such as providing development resources for the programme or adopting a product they now have to start using in place of another for their business function.
A stakeholder will have high power if the person can influence the decisions, such as, if a feature is implemented or when activities take place in a schedule.
The way I engage with each type of stakeholder is explained as follows.
Collaborate and Manage Closely
These stakeholders are of the most importance in this model and need to be collaborated with and managed the closest. I invite them to product strategy and roadmapping workshops, Programme Iteration events and sprint review meetings.
My objective with them is to secure their buy-in, leverage their ideas and knowledge, and establish a close and trusting relationship. I want to ensure they remain involved with the product continuously to avoid knowledge gaps.
I try and ensure that for a departmental level stakeholder, e.g. marketing, we have one assigned single point of contact (SPOC), who will be the stakeholder I will engage with and manage. It avoids considerable complexity and effort if there is one stakeholder representing a department or group to the product/programme on a continuous basis instead of a department sending a different representative every time, for e.g. to a strategy workshop or review meeting.
Collaboration requires leadership and I try and ensure that all parties are open and collaborative but decisive at the same time – the person representing a department needs to be empowered to make decisions when they attend a decision-making event.
I strive to build a consensus with the stakeholders and encourage them to raise any difficult topics they feel must be included in meeting agendas before hand so that the agenda can be circulated prior to the meeting and all attendees come prepared.
These stakeholders have low interest but high power. They affect the product or programme’s context but they take little interest in the product itself. For e.g. the person in charge of the engineering team will be a stakeholder the programme will have to keep satisfied. If this stakeholder does not provide engineering resource then the success of the programme would be at risk.
I ensure these stakeholders are included in any discussions and that their opinions, concerns, and ideas are being listened to. I regularly consult them, for example, by having one-on-one meetings. As a Programme Manager or Product Owner, I usually setup regular one-to-one meetings with any departmental lead or provider of critical resources to any of the programmes in my portfolios. In these meetings I discuss the status of the initiatives that their resources are working on, the risks and issues impacting the programmes, the activities their resources are performing and what, if anything, I need from those resources and how the lead/department head can help.
This ensures that I have a regular opportunity to explain how things are going and what I need from them. It also gives them an opportunity to have their ideas and concerns heard. And it further helps avoid unexpected outcomes.
I find that if these stakeholders are pushy or obstinate, it’s mainly because of the view that they have of the situation around the programme. To reach common ground and collaborate on a way forward, my approach is to invite the subject matter experts from the project team, such as the engineers assigned from their department and any engineers and departmental heads from other departments that are dependent on their output, to a meeting where we work towards agreeing on an optimum option for the issue at hand.
These stakeholders have high interest but low power. They feel affected by the product and are keen to influence it but they can’t veto or change decisions. These stakeholders can make great allies who can help increase buy-in. I keep them engaged by inviting them to sprint review meetings or programme status review boards and encouraging them to share their feedback.
If they make requests that are outside of the current requirements backlog I use the product strategy and roadmap to consider if adding that requirement would be beneficial.
These are stakeholders with low interest and low power. As they are not very interested and don’t influence decisions, it’s usually sufficient to just keep them informed, for instance, by giving them access to the requirements backlog or update them on important developments in the form of a regular programme status document.
|Stakeholder Type||Frequency||Example Engagement Approaches|
|Collaborate and Manage Closely||Every week, or two weeks or once per Sprint||Collaborative workshops, strategy and roadmap events, sprint review meetings, programme status reviews, one-to-one meetings.|
|Satisfy||Weekly or monthly||Sprint Reviews, Programme Boards, one-to-one meetings.|
|Inform||Weekly or monthly||Sprint Reviews, Programme Boards.|
|Monitor||Weekly or monthly||Email updates programme status summaries.|