I’m not sure the term ‘stakeholder management’ is doing us any favours
Stakeholders are not build beasts to be feared and ‘managed’
As we stride around the sawdust circus arenas of our software development projects, we should beware of seeing our stakeholders as cantankerous lions that need to be kept at bay with the pointy end of a chair. We should rather see them as allies - fellow acrobats on galloping ponies. To do this I think we need to build empathy, trust and transparency, and maybe we also need to watch our terminology.
Who are our stakeholders?
In the context of software projects, stakeholders are people who have skin in the game usually because:
they have organised some or all of the funding
they or their team will be directly impacted by the software solution
their reputation will be impacted by the project outcome
Why are stakeholders dangerous and frightening?
Stakeholders often have the power, to request (sometimes demand) specific features or designs.
But because they usually aren't embedded in development teams they can't see the impacts - often painful - of demanding features with aggressive time frames, or wanting to change things at the showcase or part way through a sprint without being involved in the research that led to those solutions.
And it's easy for stakeholders to underestimate the size and complexity of tasks because they can't see the detail, and without the detail it's easy to think that something is easy. When you couple this with the fact that stakeholders often have the ability to cancel, discredit or de-fund projects, you can see how they become feared beasts.
But actually, our stakeholders are often scared
From the other side, I've seen business stakeholders, especially those that lean towards a slightly more formal style, worry that happy easy-going Agile teams are goofing off, inflating time estimates and making heavy work of features that appear quite simple.
They are scared; they are worried about their jobs, their money, their teams and their reputations.
Specifically they are worried that:
the money they fought hard to secure is going up in smoke
the project won't be on time
the quality or scope won't give them what they've committed to in the business case
their business as usual (BAU) teams won't get the benefits they need from the solution
Add to this, that many business stakeholders don't understand Agile or the technology in play; all they can see are walls of scruffy hand-written notes, rubber chickens and people dressed in jeans and geeky t-shirts (which I fully endorse, BTW). You can start to see how some stakeholders may worry that their budget isn't being spent well.
That's what showcases are for, right?
Showcases are meant to demonstrate progress to the business stakeholders. Ideally they provide a sense of progress and a forum to give feedback to the development team so stakeholders leave feeling calm, informed and empowered.
More often than not, however, stakeholders understand only half of what is being shown in the showcase because presenters inadvertently make the content too technical or they go too fast. And to be fair, I have occasionally seen project teams deliberately rush demonstrations to obscure the progress of features. This is, of course, because they are concerned about aggressive criticism, the future of the project or demands for changes and features that will weigh down an already heavy backlog.
It's easy to get to a point where 'the team' doesn't trust 'the business' and both halves of the equation are feeling fear, mistrust or resentment.
What about the product owner?
The product owner is meant to straddle the divide between business stakeholders and the development team. But in most projects that I've seen the product owner is clearly perceived to be either on one side or the other, never neutral. Which 'side' they're on usually depends on reporting lines, desk location or time they're allocated to the project.
If they're on the 'development' side they should be building bridges with the stakeholders with as much scaffolding as they can find. And if they're on the 'business' side, then it often falls to someone in the development team to entice them across along with the other business stakeholders.
Take the time to understand stakeholders
So how do we avoid a hostile situation?
Firstly we need to understand pressures and priorities our stakeholders are feeling. Even if we think we already know this, we need to listen like our whole project depends on it. Because it kind of does.
And even if we already knew it from documents, observation or other people, we need to listen to these people. We may know what they're going to say, but we must listen until they finish saying it so they know we know. Put your own stress aside and live theirs for a moment.
Take the time to educate stakeholders
We also need to entice our stakeholders to listen to us and understand the technical solution in some detail. It's not just a website, it's nearly 100 pages to be updated; it's not just a check out page it's the stock check and credit card verification; it's not just an address field it's integration with Australia Post to check the address and business process to keep this up-to-date in the future.
Sometimes you just have to expose a little bit of detail for the stakeholder to start to get a glimpse of what's involved. This helps them (a) trust that you know what you're doing because you're already thinking about things they wouldn't know to check, and (b) start to understand why stories take so long. This makes them less likely to challenge your team about time estimates. It also helps them to built trust, respect and empathy for the technical team.
Nothing beats a one-on-one
In general Agile practices aligns closely with default human behaviour, but sometimes I think we need to connect more one-on-one outside of the standard 'all-in' Agile rituals. Meetings are necessary, but done wrong they can leave people feeling anxious, bored or frustrated - sometimes all three. They are often forums for ego, anxiety, defensiveness and controlling behaviour. I have found that one-on-one meetings with stakeholders are hands-down the best way to understand concerns, explain complexity, discuss strategy and build trust. One-on-one meetings can provide multiple anchors for the technical team within the business.
I use one-on-one meetings to do three things:
To ask stakeholders what their concerns and challenges are, which builds trust, and really listen to their answers
To explain enough of the complexity behind the work as needed to help stakeholders help us make sensible decisions
To explain how hard the development team is working and how committed they are to the project (only when it's true, of course, but it pretty much always is)
Ask what stakeholders would like to deprioritise if they want specific features done quickly or suddenly
Conclusion
I try to sit down regularly with my stakeholders and listen, I mean really listen, without jumping in or justifying anything. Then, without getting defensive, I explain why certain decisions have been made, the rigor that exists in the team, and how we can do almost anything but there has to be a sequence and therefore a trade-off with something else (God bless the backlog).
I've worked in software development for 25 years and been an Agile business analyst and project manager for more than 10 so I've done a fair bit of 'stakeholder management'. In my experience it all comes together when you start really listening and building trust.
Let's collaborate rather than manage each other. And lets embrace the terms like stakeholder engagement, stakeholder collaboration and stakeholder consultation. Or maybe we can just use their names...
Thanks to: Alon Hadass and Andrew Ford for proofing and feedback, Alexas Fotos for prowling lion image on Pexels, Ingo Stiller for 'scary lion' photo on Unsplash, SK for 'worried lion' photo on Unsplash.