Stakeholders are defined as “anyone with viable interest in the business value delivered by the team, at all levels in the organization and even outside the organization”.
Stakeholder management is about how to involve, enthuse and activate the stakeholders that matter.
How to identify and involve your stakeholders
When you are involved in organizing IT delivery, for your team, a group of teams, or an organization as a whole, you have to answer the following questions:
- Who are the stakeholders?
- How can these stakeholders be involved?
- What is at stake for each stakeholder?
- What contribution can each stakeholder bring?
- What information does each stakeholder need?
Who are the stakeholders?
According to the definition “anyone” can be a stakeholder. In stakeholder management however, we mainly focus on the stakeholders that have a role in, or influence on, the decision-making process around the IT system and business delivery. Examples are product owners, business managers, program managers, solution train engineers, release train engineers, etcetera.
Although all team members of a cross-functional team also fit the general definition of stakeholder, in this section we will not address how to work with the team members since that follows the general practices and ceremonies of for example the Scrum framework.
When determining the relevant stakeholders start with making a “long-list” of people that might have some kind of stake or interest or influence in the business delivery. Start with obvious people, ask them for input and based on that extend the long-list, using the concepts of circles, starting with the inner circle and working towards the outer circles. An important question to ask every identified stakeholder is simply “who else is a stakeholder?”.
The people on the long-list are divided in four groups, the people that are accountable, responsible, consulted and informed.
Accountable people are also known as the principal stakeholders, they take the final decisions for example about budget and go/no-go.
Responsible people are important because they have a role in making sure that work gets done. In pure high-performance teams such as in Scrum or DevOps the team as a whole is responsible, in sequential or hybrid IT delivery models there are often project managers or similar roles responsible.
Consulted people have valuable information or opinions that must be heard prior to taking decisions. This may be high-level information or detailed information, so people may need to be consulted in very different stages of the IT delivery process.
Informed people are the kind of people that do not actively contribute to the IT delivery process but need to know what’s happening, for example to keep activities aligned across teams or across organizations. They are the informal influencers, people that don’t have formal power but do have influence on other people involved.
When determining which stakeholders need to be involved keep all four of these groups of stakeholders in mind. If you miss out on some of these groups (for example the consulted or informed people) that may cause a lot of trouble in a later stage when the business value is not at the level that all involved people expected.
Note regarding possible confusion: In SAFe®, the terms “Solution Train Engineer” (STE) and “Release Train Engineer” (RTE) are used. These roles are defined as “servant leader and coach”, thus actually a management type of role. So, don’t be misled by the word “engineer”, these roles are not involved in executing operational tasks like an engineer would be. Then why, you may wonder, are they called engineer? In northern America a “locomotive engineer” or “train engineer” is the person that drives the train, so this person is in charge of where the train goes, which is more like a management role than a technical role (although in the era of steam trains the train engineer needed technical knowledge and skills too).
How can these stakeholders be involved, and what is at stake for each stakeholder?
These questions are closely related. For a stakeholder who is expected to contribute to the goals of your team(s), the question ‘What’s in it for me’, must be addressed.
For some stakeholders the benefit is obvious, a business manager for example who is responsible for a specific business delivery will need support of the business process by IT systems and thus needs to invest budget and time in the process of IT delivery.
For other stakeholders the benefit may be less clear, for example the agile coach of a team that is not involved in any IT system for your business process, may still need to be informed because both teams make use of the same technology and thus can exchange useful knowledge and experience.
So, for each (group of) stakeholder(s) make a list of what is at stake for them. Their gain may be in terms of business benefits (e.g. financial or functional) but also in receiving relevant information or benefiting from mutual experiences, or even related to their personal goals such as advancement of their career.
And when you are in doubt whether a specific person is or is not a stakeholder, you can always just ask what they think is in it for them.
Involving stakeholders partially will be automatic when you follow the standard ceremonies or rituals of your IT delivery process (such as a daily stand-up, a retrospective meeting etcetera). For example, see the topic “Responsibilities & roles”. For other stakeholders you will need to specifically organize their involvement.
What contribution can each stakeholder bring?
For each (group of) stakeholder(s) make clear what contribution you expect them to bring to your team(s).
As a general rule: “Be clear. Be specific. Be direct.” Make sure it is easy for stakeholders to contribute what you need them to.
When asking for a contribution, be well prepared and to the point. And communicate information that matters for the specific stakeholder (not too little, not too much).
For each contribution make clear if you need a decision, commitment/approval, a mitigation or “just” information. And also mention what the stakeholder will get in return.
To easily classify the stakeholders, you can use a matrix with four segments that helps to identify your stakeholders and determine how to involve them. The four groups are:
- High power & high interest: manage closely and work together
- High power & low interest: keep satisfied and inform
- Low power & high interest: keep informed and consult
- Low power & low interest: minimize efforts and monitor
What information does each stakeholder need?
Each stakeholder needs to be informed, but every stakeholder may need a different kind of information. Ultimately the goal of informing stakeholders is to enable them to establish their level of confidence that the pursued business value will be achieved (as described in the VOICE model).
The information for all stakeholders must be gathered based on predefined indicators. Depending on the information needed, as described in the topic “monitoring & control” the indicators are selected, different stakeholders may require different indicators.
The level of information that a stakeholder needs will differ largely. As described in the topic “reporting & alerting” some stakeholders (for example high-level managers) will only need very high-level information that can be shown in some smileys, other stakeholders (for example project managers, STE’s and RTE’s) need an overview report, and people that are operationally involved (such as team members) will need all available details.
All information must be clear, to-the-point, honest, frequent, timely and consistently communicated.
The term “report” may be misleading. If you want to have an effective way of informing people you will need to tune the way of communication to the information-needs of each stakeholder but also to the preferred channel of communication of each stakeholder.
Some people indeed want to receive a regular document (for example people that are responsible for your financial budget), other people are better informed in a personal conversation or telephone/video call (these may be formal meetings but just as well informal chats over a cup of coffee). And yet other stakeholders only want to be contacted (alerted) when the IT delivery process tends to go beyond the tolerances that were agreed, for which reason such stakeholder will need to take a decision about how to adjust the IT delivery process in the best possible way.
In the topic “reporting & alerting” the distinction is that reporting is more about regular flow of information whereas alerting is about making specific stakeholders aware that they urgently need to act.
In a high-performance cross-functional team all team members have the possibility, but also the responsibility, to initiate alerting relevant stakeholders as soon as they become aware of some condition that brings risk to the team’s objectives. The way of alerting may differ very much. Some teams install a physical alert-button for the team that triggers some sort of alarm to the stakeholders. Other teams use more conventional communication channels to express the need for involvement of one or more stakeholders.
Different types of stakeholders and how to treat them
People are different. Their behavior is different. Their motivators are different. So, you need to treat them differently.
As an example, in this section we compare stakeholders to five birds to clarify different types of stakeholders and how to treat them. Always keep in mind that behavior cannot be changed easily, but when you anticipate on their behavior reaching the teams objectives will become easier.
An ostrich typically puts its head in the sand to not see problems.
This type of stakeholder tries to ignore problems in order not to be bothered with it. When it can’t be ignored, they underestimate the problem or actively try to downplay it. Otherwise they try to push the problem to someone else.
This type of stakeholder can be managed by making sure that they understand your message for instance by asking for a response or an action. Also make sure that you inform the influencers of this ‘ostrich’ the same way, so your information reaches him/her in multiple ways.
A cuckoo typically lays its eggs in the nest of another bird.
This type of stakeholder puts a lot of effort in pushing problems, decisions and/or responsibility on someone else’s plate.
This type of stakeholder can be managed by following the shift. That means that you must anticipate onto whom the problem or responsibility is shifted by the ‘cuckoo’. Act towards that person, but keep the ‘cuckoo’ in the loop. Make sure he/she is informed about your follow up.
A peacock tries to impress other birds with their feathers.
The kind of stakeholder addressed as peacock usually tries to impress other people, but often not with their own achievements but with other people’s achievements and successes.
This type of stakeholder can be managed by giving them the successes they want to have. However small the success may be, make sure you tell the ‘peacock’.
The owl stands for wisdom, peace and predictability. His knowledge is generally known and accepted.
This type of stakeholder can help to clarify problems. Use the owl to get rid of problems and obstacles, to reduce debates and to squash rumors in an argumented way.
An eagle is combative, his courage and strength are undisputed. His view is sharp and further than anyone can see.
Use his strong view and vision to see and predict what has to come, before anyone else can see it yet or just for inspiration.
The fire fighter
The ostrich, the cuckoo, the peacock, the owl and the eagle are types of stakeholders you commonly will find amongst stakeholders at management level.
At team level you may come across another typical behavior, the so-called fire-fighter. That’s the kind of person who takes pride in solving urgent problems. They often are good at that. The downside is they often don’t want to contribute to preventing problems or working towards long-term solutions because that would not give them chances to shine anymore. These fire-fighters will require specific effort to guide (or force) them in the direction of early quality and problem prevention. Try to keep them on board by involving them in finding solutions and asking for their expertise. They are respected in the organization for their knowledge and problem solving skills, so make use of that.
The key attitude in stakeholder management
Stakeholders usually don’t like surprises, so make sure you have regular meetings with the relevant stakeholders and make sure to share the proper information with stakeholders in a timely manner. Also make sure that each stakeholder only receives the relevant information, nothing less and nothing more.
The key attitude for effective stakeholder management is to “Grasp the nettle”. That is, if there is a (potential) problem, then don’t wait until it gets magically solved (because it probably won’t), but find the cause or source, act on it as soon as possible. Don’t put a problem on someone else’s plate before you have done your best to solve it yourself (as a person or a team).
Also key is to observe informal communication (such as gossip) and to act swiftly to prevent wrong signals in spreading until they are beyond control.
By creating a stakeholder-network-diagram you can gain insight in the relationships between stakeholders which may benefit communication with the right stakeholders and making sure they will get the right information in time. Be sure to choose the frequency of communication carefully. Too little information will make them nervous or suspicious, too frequent information will reduce their attention. In general a regular newsletter has little added value. Focused information at the moment there is specific news is much better to attract the attention required.
Responsibilities in an ARCI-matrix
An ARCI-matrix (also known as RACI-matrix) contains a list of deliverables and/or activities on the rows of the matrix and specifies the people involved in the columns. For every deliverable/activity the table shows per person in what way they are involved, the possibilities of involvement have starting letters ARCI, hence the name:
- Accountable: this person is the “owner” of the work. He or she must sign off or approve when the task, objective or decision is complete. This person must make sure that responsibilities are assigned in the matrix for all related activities. There is only one person accountable.
- Responsible: these people are the “doers” of the work. They must complete the task or objective or make the decision. Several people can be jointly responsible.
- Consulted: these are the people who need to give input before the work can be done and signed-off on. These people are “in the loop” and active participants.
- Informed: these people need to be kept “in the picture.” They need updates on progress or decisions, but they do not need to be formally consulted, nor do they contribute directly to the task or decision.
How we organize the interaction between stakeholders and the team(s) has a large effect on the process of IT delivery and the business value that is achieved.
- Book: The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois, John Willis, ISBN 978-1-942788-00-3
- Book: Quality for DevOps teams
- Presentation “stakeholder management” by Wim van Uden
Related Building Blocks
Responsibilities and roles
Governance in high performance IT