Turning concepts into reality: how business analysts make it possible

Once our user research team has determined if a service is useful, the question that immediately follows is: is this actually possible?

That’s where our business analysts (BAs) come in. Sitting at the centre of each project, they interact with every part of the team. They translate user needs into requirements, navigate technical constraints, and figure out how to turn a concept into something tangible that can be built, funded, and sustained.

But what does this look like in practice?

No two projects are the same

The answer is that things can play out very differently depending on the project.

Our BA team has worked with a wide range of UK government departments: Government Digital Service (GDS); Department for Work and Pensions (DWP); Ministry of Justice (MoJ); Department of Health and Social Care (DHSC); as well as on international projects and with organisations such as Citizens Advice. This variety is part of what makes their role so interesting.

“It’s not only that two days are not the same,  it’s that two projects are not the same, even if you are always a BA.”

From drafting financial cases for HM Treasury to analysing data flows across the justice system, the work spans discoveries, alphas, and betas across some of the UK’s most complex public services.

The tricky balance

Perhaps the most honest thing to say about BA work is that it lives in tension. User needs don’t always fit neatly within budget lines or technical realities, so how do you hold both?

The key, our team argues, is to stop thinking of them as opposites.

“If what we are suggesting is not affordable and sustainable in the long term, it will crash, and that definitely does not meet a user’s needs.”

Rather than thinking about “business needs” versus “user needs”, it’s more useful to think about service constraints,  the boundaries within which a service needs to exist. A service that perfectly meets user needs but can’t be funded after year one hasn’t actually helped anyone.

It’s also worth looking for where needs align rather than conflict. Take a simple example: a user wants to fill in a form quickly; a business needs accurate, detailed data. These sound like a clash but think it through and they’re actually pointing in the same direction. Accurate data means fewer follow-up contacts for the user. A faster form means higher uptake for the business. A well-designed form serves everyone. The BA’s job is to find those alignments and to help the team act on them.

Solving the unsolvable

Sometimes a project throws up a problem that nobody anticipated, and that’s where BA thinking really earns its place.

On our recent DHSC Compass project, the team was building a service to help NHS professionals make value-based procurement decisions on medical devices. Suppliers were initially considered out of scope. Then it became clear that, for legal compliance, DHSC would need to give suppliers visibility of evaluations related to their own products, but not their competitors’.

Overnight, something out of scope became a complex problem to solve. The team framed it around three core questions – the 3As:

• Access: what should suppliers be able to see?
• Agency:  what can they do if they disagree with an evaluation?
• Authentication: how do you verify that a supplier is who they say they are?

Using classic option mapping, they laid out every possible approach on a spectrum – from full supplier agency to none at all – before determining the pros, cons and trade-offs of each. This approach helped surface the best combinations quickly and gave the whole team a shared basis for discussion. Within roughly two sprints they had a fully sketched, workable solution.

Bridging the gap 

Crucially, the BA’s role is not to hold the business’s corner against users; it’s about making sure all the different parts of a team are speaking the same language. They are the ones who bridge the gap between the different parts of a multidisciplinary team and the business.

Key to this is their work translating needs into user stories. This shared language brings together researchers, developers, designers, and product owners and enables them to move forward in a way that addresses everyone’s priorities. 

Beyond the build

Like all good delivery work, BA work has to outlast the team that did it. The goal isn’t to build something brilliant and then abandon it, it’s to leave behind a service that a client team can actually understand, maintain, and build on.

Critically, handover shouldn’t be a final-week scramble, but a habit built throughout the project. To achieve this it’s essential to work in the open from day one. That means regular show and tells, weeknotes, and documentation that lives where the client team already works.

“Handovers should begin as early as possible… Add to the client’s Confluence pages rather than storing work in Word docs on a SharePoint that will disappear along with your team.”

Building a service is only half the job; the other half is making sure it doesn’t fall apart once you’re gone.

Final thoughts

Good BA work is rarely visible in the finished product, but it’s there in every decision that held up under scrutiny, every handover that didn’t unravel, and every team that stayed aligned when things got complicated. Ultimately, it’s the difference between a service that launches and one that lasts.

Find out more about the Delivery Services we offer at Oxford Insights, including business analysis.

Grid photo by Mika Baumeister on Unsplash