#033 - The irony of being a business analyst
Welcome to Issue #033 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
✍️ Insights: How business analysts use their skills to help their clients but not always themselves.
🤔 Made me think: Covert communications in meetings.
👨💻 Worth checking out: How to ask a stranger for a portrait.
How business analysts use their skills to help their clients but not always themselves.
In my 20+ year career as a business analyst (BA), the irony of BAs not applying what they do for clients to themselves still surprises me.
It reminds me of the phrase, “the cobbler’s children have no shoes”.
If you’ve not come across this before, it means the shoemaker is so busy making and mending shoes for his customers that he doesn’t have time to do any for his own family. He’s intent on treating his customers well so that he can retain them. But, at the cost of his family having to go without.
The corollary is this an old African proverb: “family must look after family”. As BAs, whilst we put our clients first, we also need to ensure that we also don’t put ourselves a distant second. It might be survivable in the short-term but it’s not sustainable for the long-term.
We don’t speculate, we elucidate
As BAs, we don’t second guess what our stakeholders want. Instead, our role is to proactively engage with them, to challenge their views, and to collaborate with them on what’s needed. All to draw out and definitively synthesise the underlying problems so that we can confidently design and built the right solution for them.
But, not every client understands what that really means in practice.
So, to illustrate, I give them a quick 5 min exercise for each of them to sketch out a typical UK family home.
Unsurprisingly, I get a lo-fi rendition of one of the main housing styles above. Occasionally, an apartment building or a perhaps a houseboat on a canal. Sometimes, the sketch isn’t even a face-on view of the building but drawn isometrically in 3D.
Regardless of what they each draw, without fail, they won’t be anywhere close to being the same.
That’s the analogy I use to explain that my role is to get them to a point where they all have the same view of the same thing we’ll be designing and building together. From the core elements (how many rooms and what types of rooms), to what needs to connect and what doesn’t, and to how it’s all going to flow when you make use of it.
Each parameter, and many more that I’ve not listed, can have multiple options. And each option can result in a multitude of impacts on other parameter. So, there’s typically not a single “right” answer, only what someone thinks is the “best” answer.
And whilst we aren’t creating a physical house but configuring and customising a digital software application, the concept remains the same: we all need to have the same end-state in mind for project success.
But we don’t use what we know to help ourselves
The irony is that whilst we are good at understanding our stakeholders and eliciting their requirements, we’re not as good in doing the same for ourselves to elucidate what we need to be successful.
To deliver effective business analysis, it’s critical that we have the time and the capacity to plan our approach, manage our process, and monitor our deliverables.
This isn’t the sexiest or exciting part of what we’ll do on a project.
Often we skip over this because of time constraints. Or, because we ourselves speculate that we know what’s needed for the client and intuitively know how to do achieve it. Even though, we also know that each project is never the same as previous projects we’re basing that assumption on.
That’s not all. I’ve also noticed that, as BAs, we tend not to share how we go about managing our delivery to our end-stakeholders and usually only with the project manager. It’s as if there’s a unspoken rule that the stakeholders should need to know or mustn’t peer behind the curtain to see how the magic happens.
But, it needn’t be that way.
Doing this fundamental work is foundational to how successful we are as BAs. If we don’t apply the same rigour to our own “internal” work as to what we do for our clients, then it’s not only a disservice to them but also to ourselves.
We, more than most, have experienced the pain and the impact of skipping over or speculating on requirements. For a few, you might get away with it, but in aggregate, it’ll eventually lead to substantive re-work, reduced quality, and increased costs. It’s the same if we don’t adequately plan our delivery.
Over a multitude of client projects, I’ve found that the ones that delivered the best outcomes were the ones where the client and I were equal partners. The ones that were underpinned by trust and transparency between us. And that included me being open and upfront with them about not only how I was going to manage my delivery but also how they could see when I was deviating.
Undoubtedly, there was the risk that this could’ve been a “rod for my own back” but, instead, we collaborated and came up with a better end-state for my BA artefacts than I had originally planned.
If you don’t ask, you don’t get
What you need as a pre-requisite to be successful on a project will vary.
For some it’s going to be asking for a realistic amount of time. Whilst, for others it’s going to be asking for sufficient resources upfront. Whether that’s regular access to subject matter experts or to some critical tooling.
Here’s two tactics that I employ:
Pro-actively and directly tell people what you need and why so they can help you achieve it.
I know it sounds simple but, too often, I see BAs mumble their request into the ether as if they are hoping the client will know by implication.
The most important part of the ask is the why behind the what. It’s the same with requirements, the why is the element that justifies the need and helps convince people to meet it.
Signal repeatedly, but in a measured way, what you need so that you remain top of mind in those you’re asking.
The only person where you’re top of mind, is … well, you. For everyone else, you are simply 1 of 99 problems they are contending with.
So, depending on who your ask is going to, you must balance making sure they don’t forget you yet not annoying them in the process. A difficult tightrope and one I’ll be discussing in a later issue.
At the end of the day, if you ask and they say no, you’re in no worse position than you were before you asked. In fact, you are in a better position as you’ve now raised a project issue because your need isn’t being met.
But if you never ask, no-one will know until it’s too late. There’s little that’s more frustrating than knowing that this was avoidable if only you had made the ask.
Think about your current project. What should you have asked by now? The best time is past, but the next-best time is now, so just ask.
🤔 Made me think
Covert communications in meetings
As much as non-verbal communication is a substantive component of communication, that alone isn’t enough to effectively getting your message across and understood.
Only when your verbal communication aligns with how your present your message, then your ask can land effectively with your stakeholder.
🧑💻Worth checking out
🔗 How to ask a stranger for a portrait | Wesley Verhoeve
One of the most intimating things to overcome when you get into documentary photography is asking someone if you can take their photo.
It’s one thing organising a shoot with a model or with friends and family. It’s quite another when you’re on the street. Especially if you’re doing travel photography but don’t speak the language and aren’t sure of the cultural norms.
So, most photographers will default to by zooming in from a distance or surreptitiously taking a shot without the subject noticing. There’s an argument for wanting to take candid (e.g. unposed shots). But, is that the real reason or simply a convenient excuse?
A couple of key points from this interview related to this week’s insight:
The more you ask, the easier it gets with practice.
If you don’t ask, you’ll wonder what could’ve been if you had.
Respect the stranger’s time by being clear about your ask.
Finally, if they do agree to your ask, find a way to give back to them.
You can read more about how to ask in Wesley’s article.
🖖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.