Every software development organization runs a series of software projects. These projects result in applications. Those applications require great features to be successful. Agile teams push those applications from source code to production. In the heart of these processes is the Product Owner. Stakeholder management is one of their key tasks. A Product Owner needs to identify the correct stakeholders and know how to deal with them. As speed of delivery and high quality of the applications being developed is important, things might go wrong in the rush to get code to production. This is why stakeholder management is important; read on to find out the do’s and don’ts of stakeholder management in a DevOps world.
Stakeholders?
First of all, it should be clear who or what a stakeholder really is. According to the website of project-manager.com, the definition of a stakeholder is:
“A stakeholder is either an individual, group or organization who is impacted by the outcome of a project. They have an interest in the success of the project, and can be within or outside the organization that is sponsoring the project.”
In my view this captures it all. A critically important side note here is the following:
“Stakeholders can have a positive or negative influence on the project.”
This makes the definition more interesting. Stakeholders can help you push your project and application forward but also frustrate it. Imagine what a stakeholder with great power can do to your project if it influences them in a negative way. To keep them all happy, it is important to involve them in your project and to act based upon their input.
Communication
In every organization, communication is important to collaborate together. Teams may be distributed across different geographic regions and team members might have different (cultural) backgrounds. Stakeholder management becomes very difficult in these situations. Where to start from here?
Start your journey to create a so-called “RACI-chart”. RACI charts can be used for different purposes (e.g. conflict resolution, or work assignment) as well as to capture various stakeholders and their position to your project. The letters in RACI stand for: Resposible, Accoutable, Consulted and Informed.
You should split your stakeholders into different groups. This makes communicating and interacting with them a bit easier since you know how to target your efforts. It also shows other people in the organization who and what influences your project.
- First identify the stakeholders who will be responsible for the work. It is very likely that you work with them on a daily basis. This group can be your agile team, and they have a big influence on the outcome of your project. You should know them very well.
- Second, find the person who is ultimately accountable for the project. Build a deep relationship with this person since you need them at important moments along the way. Keep in mind that they also have to report to someone else. And be sure there is a “replacement” if this person is not available. If there is no replacement, your project can be severely delayed.
- At the next level there are the stakeholders that should be consulted. For example: subject matter experts. They are not actively involved. However, their advice helps the team to make the right decisions.
- And last but not least, the stakeholders which need keep informed since they are not impacted so much by any project outcome.
It’s obvious that the first two groups are the most important success factors for your project. The RACI chart is simple to create and it greatly proves its power since it’s very practical.
Getting them on track
Aside from communication, the active involvement of stakeholders is also important. Stakeholders can help you steer the project in the right direction. They can provide you with valuable feedback on the next iteration of your application. So how do you keep them involved and engaged?
The engagement scale
The goal of the engagement scale is to make a plan on how to move each stakeholder from his current level of engagement to the next one. These are the levels from least engaged to most engaged:
- The indifferent level. Stakeholders at this level are not interested and don’t make sufficient time to really help you with your project. Feedback is very hard to get from them.
- The neutral level represents supportive and interested stakeholders. They attend your sprint demos and provide feedback.
- And the last level, the most desired level, encompasses stakeholders who are highly motivated and helpful. They are pro-active and might want to execute tasks for you to make sure you achieve your project goals.
Stakeholders from the last level are the ones you really want. Once you get the majority of them at this level, your project is much more likely to be successful.
Involve them as early as possible
Don’t wait weeks or months before you involve your stakeholders. Involve them as early as possible so they can help you get things off the ground. A lot of stakeholders have specific requirements. It’s important to have them clear before you start creating user stories. Of course you can always adjust them later on but fixing the core concepts of your application is very hard when you have started a long time ago. Even this is an example of “shift left“.
As time progresses and you learn from the involvement of your stakeholders, there is room to adjust your RACI chart.
Attend every review
Sprint reviews are very important in an agile world. Live demos are a great showcase to demonstrate new features to stakeholders. To keep them on track, it’s vital to invite them for every review so they can see the product progresses from one version to another. Chase stakeholders who do not show up a number of times in a row. Perhaps they have their own reasons (e.g. filled-up agenda, lack of time, other priorities, etc). In case they are less interested you need to adjust your RACI chart or motivate them to move up in the engagement scale.
Resolve conflicts
Conflicts arise in every project and also within every team. Resolve them as early as possible to keep the team spirit high. Multiple stakeholders can have different interests and these interests can conflict with each other. Their projects and/or products can also conflict with yours. This makes a toxic cocktail.
Try to bring them together to align on requirements and expectations. Share regular updates about your product and also collaborate with their projects to show your willingness to help them. Ask for feedback and try to incorporate that into your activities. Hopefully this will improve the collaboration and resolve the conflicts.
Give them a job
Give stakeholders something to do that contributes to your project. This is a very powerful way to engage them. However, they should agree and don’t feel pushed. Besides, they should have enough time and the right knowledge.
Applying this method can even turn a negative stakeholder into a positive one. Imagine you need a commitment from the senior management to get budget for a costly operation (e.g. introduce a new tool). A stakeholder who is always negative about new tools could be your sparring partner to evaluate the financial pros and cons. This helps to create a strong business case. This stakeholder’s approval could persuade senior management to approve the plan and budget.
Pitfalls
There are a number of pitfalls that kill the engagement of any stakeholder.
Wrong assumptions
One of the biggest pitfalls is to assume your stakeholders don’t want to be engaged at all. Perhaps they are stressed to get their project being delivered. Try to capture their attention and be sure to use their time efficiently. Create proper agendas for each meeting and balance the work you require from them. For sure, don’t give overloaded stakeholders a job which puts more pressure on them. Never forget: keep them at least informed so they don’t feel forgotten.
Don’t listen
Perhaps one of the most difficult habits: listen carefully to your stakeholders. It does not help the organization if you just push your own features. Improvements that do not contribute to the goals of the stakeholders, even if they’re useful to the product itself, are hard to push.
Don’t assume things, you might be wrong since you can’t read the mind of your stakeholders. So listen.
Listen to their wishes and try to come with a better solution than expected. Even in case they are not very clear on what they really want (or need), try to capture their thoughts and come back with a proposal. If you’re right about it, write down the specifications together. Be sure to check back regularly to verify if you’re still doing the right things.
Requirements versus expectations
It’s great if you have your requirements captured in user stories. Once these are prioritized, your team can work on them in their next sprint. People tend to underestimate the effort it takes to finish them according to the Definition of Done. In the end, it’s all about expectations.
Requirements and expectations are different things. Most of the time, expectations are derived from requirements. A pretty strong example is the following:
What is the personal impact of the project on the position of the stakeholder in the organization?
Perhaps he will use the project for his own benefits so he gets a big promotion at the end of the year. You should know the background of the requirements they come up with. In all cases it should serve the business, not only the individual stakeholder.
It is advised to have the difference between requirements and expectations clear. You should be able to answer the question: what’s in it for the stakeholder and the business itself. Keeping stakeholders engaged will be a lot easier now.
Keep everything to yourself
Don’t try to keep everything to yourself. Stakeholders will be much more engaged if they are part of a successful project. It’s impossible to do everything yourself, so be sure to hand over tasks to the stakeholders.
Make all of the work transparent and share timelines of features. For example: create a proper roadmap of features you plan to work on in the near future. It should not be set in stone, it’s still an agile world. So you need to be able to adjust it as soon as stakeholders change their mind or other external factors influence your project.
Don’t overwhelm
A stakeholder is, just like you, a busy colleague. Don’t overwhelm them with a lot of details about your project. When you collaborate with them, ask for the best time, the best format and the level of details of the information you provide.
It’s very difficult to estimate which level of detail is appropriate for stakeholders. You should actively ask for feedback and provide more details to those stakeholders with questions. Proper follow-up of every meeting is essential.
Call to action
Every communication touchpoint (meeting, email, phone call) should have a call to action. Without a concrete follow up, all of the efforts are a waste of time. Stakeholders can’t read your mind or guess what you think if you don’t provide a follow-up. If you request an action from them, try to limit it to a single topic. This will increase the likelihood of getting a valuable answer from them. However, don’t overwhelm them by sending too many small requests.
If you don’t (need to) ask them for any concrete action, you can always ask them if they have any questions themselves so they feel welcomed to get (back) in touch. It will help you build that special relationship with them.
Final words
Every Product Owner deals with stakeholders that influence their project. For various reasons, getting them engaged is not easy. Once you get them on the desired engagement level, they can really push your project forward. I hope you will try out the do’s and watch out for the pitfalls so you become even better in your job. In the end, the organization grows with your successful projects.
