Introduction
It was 2024, and we were working with an insurance client to digitalise a claims notification process. The specification was finished, the development team had it, and everyone had nodded. Six weeks later, at the first demo, the client asked: "But where is the claims handler's approval step?"
Nobody had left it out deliberately. It was in the BA document - but in different wording and a different context, and the client and the developers had interpreted it differently. Three days of redesign, two weeks of delay and an awkward meeting followed.
That wasn't a developer error, nor a client error. It was the price of the illusion that a BA's work ends when the document is sent.
I have thought about this a lot since, and concluded that a BA's work has no real end point. But contrary to what you might first think, that isn't a complaint.
The illusion of the document
On most IT projects, the BA's role is imagined roughly like this: the analyst gathers the requirements, writes the specification, hands it to the developers, and from there it is their job. The BA is "done".
On paper, this model is logical. In reality it almost never works.
Not because the BA does a poor job, but because business requirements are, by nature, alive. They change when market conditions change. They change when a stakeholder shifts priorities. They change when development reveals that a process actually works differently from how it was described.
On a financial services project - with compliance requirements, several departments involved and complex system integrations - this is doubly true. What you specified in early January is already partly out of date by February. Not because you did a poor job, but because the organisation learned in the meantime.
The document isn't the result of a BA's work. It is a snapshot of it.
The BA as translator - and why it is harder than you think
The BA role is often described as a "bridge" between business and IT. That is true, but it oversimplifies. A bridge is static. In reality, the BA performs continuous translation between two parties who think in different conceptual frameworks - and both believe they are communicating perfectly clearly.
Here is a concrete example. When an insurer's head of compliance says a process must run "immediately", they mean: on the day the claim is reported, during working hours, before the claims handler goes home. A developer hears the same word and thinks: asynchronous processing with a delay of a few minutes - technically "real time". And the customer understands: if the claim is reported at 10 pm, it should be processed by 8 am.
Three different interpretations of a single word. The BA's job is to recognise that gap - not just once, but continuously throughout the project lifecycle.
That isn't administrative work. It is active, critical thinking that can never be switched off.
Three signs that a BA's work is truly effective
I don't like metric-based approaches to assessing BA effectiveness. "Number of documents produced" or "share of requirements closed" is misleading. I look at behavioural signals instead.
The first sign: developers ask the BA, not the project manager. If a developer has a question about business logic and their first instinct is to go to the BA, it means the BA has real authority over the requirements. That isn't a given. It is built on trust, slowly, during the project.
The second sign: the business calls the BA before making a decision. When the client turns first to the BA - not the project manager - with a new request or change, it shows the BA is seen as a real partner, not an administrator.
The third sign: testers understand the specification on first reading. This is one of the most honest pieces of feedback on the quality of a BA's work. If the QA team needs lengthy explanations before it can write test cases, the specification isn't concrete enough. If they can work from it on first reading, the BA has done a good job.
What I do differently now
Twenty-five years ago, when I started working around IT projects, I thought a good specification was the goal. Today I know a good specification is only a tool - and not always the most important one.
What I do differently today: I start working with developers and testers much earlier. I don't wait until the document is "finished" - because it never is, only "good enough for the next step".
What I do differently today: I ask about what lies behind the business need, rather than working only on the surface. "Why is this feature needed?" is often a more important question than "Exactly how should it work?" The answer to the first often fundamentally changes the second.
What I do differently today: I accept that a BA's work has no moment of closure - and I don't experience that as a burden, but as the nature of the role. A good BA doesn't "finish" and move on. A good BA remains the owner of the requirement until implementation reaches the point where the business need has genuinely been met.
This mindset has shaped how we see the BA role at FrontX. Our BAs don't hand over the document and move on to the next project. They are there for questions that come up during implementation, at the first demos, and when testers find the first inconsistency in the specification. Because these aren't failures - they are part of the job.
A question for you
When do you think a BA can say they are done?
My conclusion: at the earliest, when the first live user successfully completes the process the BA specified - without needing an explanation, help or a workaround.
If you see it differently, or have different experience, I'd be glad to read your comments.
