#042 - The double-edged sword of stakeholders
Welcome to Issue #042 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
✍️ Insights: The necessity yet fallibility of working with stakeholders.
🤔 Made me think: The flip side of “asking the 5 Why’s”.
👨💻 Worth checking out: The illusion of understanding.
The necessity yet fallibility of working with stakeholders.
Walking out of the playback session, I was deflated.
Days had gone into doing the build. Hours had been spent on practicing and perfecting the playback. But it only took a few minutes for the wider stakeholder group to dismiss it out of hand with the phrase that no business analyst (BA) wants to hear: “this isn’t what we expected”.
This happened early on in my BA career and proved to be a pivotal point for me in understanding the difference between the theory of my discipline versus the reality of practicing it in the real world.
The importance of stakeholder engagement
During my time at Accenture, one of the more useful skills I developed was maintaining situational awareness about which projects were currently looking for resources, the reputation of those projects, and the quality of the people staffed on them.
It meant that when I had to find a new project, I could be pro-active in manoeuvring myself to the ones that I did want to work on with the people I wanted to work with. Otherwise, you’d inevitably find yourself working on the project that everyone else was avoiding like the plague.
One such project was the infamous NHS National Programme for IT. Set up by the UK’s Department of Health, it had the ambitious and laudable aim of creating a single nationwide electronic health record system. But to those on the project and those in the know, it was known as “the meat grinder”.
Originally budgeted at £2.3 billion when the programme was launched in 2002, it was eventually dismantled in 2011 with an estimated expenditure of £20 billion. Accenture actually withdrew from the programme in 2006 having already written off a $450m loss on it. Yet, for all that time and money spent, the programme was deemed a catastrophic failure.
One of the root causes, as outlined by the House of Commons Public Accounts Committee, was the programme’s lack of engagement with health professionals - the end users - at the outset of the process.
Ironically, this lack of stakeholder involvement wasn't even a novel root cause. It’s been a commonly known reason for project failure for decades because if you don’t effectively engage your stakeholders (which includes your end-users) then you run the risk of:
Poor solution quality: The technical team don’t have clear and confirmed set of requirements to work from nor the detailed context that underpins them. So, the result is unlikely to address what’s the end-users need - let alone be user-centric for them to use.
Poor expectations management: The stakeholders misunderstand the solution they will get or are unrealistic about what benefits it will deliver and when. So the result will likely be underwhelming and disappointing to them.
Poor user adoption: By only engaging stakeholders at the end when the solution is going live, the stakeholders will rightly feel that change is being done to them, rather than for them. So, the result will be a distinct lack of “buy in” which cascades down to ignoring, resisting, and even actively rejecting using the solution.
As these risks are avoidable, it’s instinctual that best practice would be to properly engage your stakeholders throughout the project delivery lifecycle. In our role as BAs, working with stakeholders is bread and butter for us as we interface between the business teams and the technical delivery teams. So, mastering the art of stakeholder management is fundamental to our success - not to mention our project’s success.
It’s so important that business analysis textbooks devote at least one full chapter (if not more) to this topic where the emphasis is on:
Identifying all your stakeholders so that you don’t miss key constituents that unexpectedly emerge at the late stage to derail your project.
Analysing your stakeholders so that you can plan the correct strategy for effectively yet efficiently engaging with them.
Understanding your stakeholders’ perspectives so that you can determine where they are coming from, the shared areas of interest and concern, and the potential points of conflict from a difference of opinion.
Collaborating with your stakeholders so that you can tailor your approach to how you best work with them, negotiate with them, and resolve conflicts with them.
These are all central, all useful, and all necessary to our BA role; yet doing all that doesn’t even guarantee success.
The road to hell is paved with good intentions
Going back to that disastrous playback session, my lesson learnt was not to put my stakeholders on a pedestal and take what they said as gospel.
Don’t get me wrong though - my stakeholders were unquestionably important. They were my subject matter experts on the process and the problems they had, they were my testers to make sure that solution was acceptable, and they were my end-users who were going to be living with the solution. But, they were also not infallible.
There were two gaps that I hadn’t accounted for.
Firstly, a stakeholder didn’t necessarily have the full picture when they were providing context, their requirements, and their feedback. Such as:
Not fully understanding why a long-standing process was the way it was. Yet they still had strong beliefs on how it should be changed.
Passing off hearsay and accepted truths as fact. Such as why the process had to be done in a certain way or the supposed business rationale for why a requirement was a must-have.
Secondly, even when a stakeholder was providing accurate information, they turned out not to be that representative of their team. Such as:
Having a different skillset and a different “way of working” than the rest of their team which shaped what they thought the process should be done. So, whilst it worked for them, it either created unnecessary friction for their colleagues or was unusable.
Having a narrower remit than their fellow team members which meant that not all the requirements were captured and certainly not to the depth needed. Especially the must-have requirements needed by their colleagues which left the solution being incomplete for them.
My stakeholders weren’t trying to deliberately sabotage the project. They were doing their best to be helpful, to be accurate, and to be collaborative to deliver a good solution. They had good intentions and without them, the playback session simply wouldn’t have even happened.
But, as both of these gaps show, they were not omniscient and nor were they the Oracle.
Whilst stakeholders are fallible, the answer is not to go to the opposite end of the spectrum and be cynical about your stakeholders and their intentions. Nor is it to interrogate everything they say. For the project to be successful, a BA does need a good working relationship with their stakeholders.
My approach lies somewhere in the middle and is best described by this Russian proverb: “trust, but verify”.
🤔 Made me think
The flip side of “asking the 5 Why’s”.
On paper, the technique of asking why 5 times to get to the root cause of a problem makes sense. It helps you to avoid dealing with the symptoms on the surface rather than the fundamental issue buried beneath.
But, in practice, life isn’t that linear nor logical. Occasionally, a business problem will have a straightforward root cause that can be addressed. Most of the time, when you ask why, you’ll reveal a “family tree” of connections that endlessly branches out like a fractal. Each reason linking to other reasons at the parent level, the child level, and so on.
It can be overwhelming and you stop seeing the wood for the trees.
That’s not to say that the technique shouldn’t be used, just that it should be used judiciously and only until where the benefit outweighs the opportunity cost of the time and effort being spent.
🧑💻Worth checking out
🔗 The illusion of understanding | Phil Fernbach at TEDx
The more passionate and the more supremely confident your stakeholder is about something, the more you should verify that they can explain it adequately.
The “illusion of explanatory depth” bias is when we believe that we understand a concept but, in reality, we don’t understand it enough. Just think of a question that a kid asked you which sounded easy at first to answer but then the details of it stumped you?
By getting your stakeholder to explain what they want rather than provide reasons for why they want it, you’ll confirm they do know what they are talking about. Or, you’ll create an opportunity for both of you to figure it out together.
🖖Until next Thursday ...
If you enjoyed this newsletter, let me know with the ♥️ button or add your thoughts and questions in the comments. I read every message.
And, if your friends or colleagues might like this newsletter, do consider forwarding it to them.
For now, thank you so much for reading this week's issue of The Forcing Function and I hope that you have a great day.
PS: Thanks to P for reading drafts for me.