The Misunderstood Business Analyst

Not sure this is complete but a good starter for ten if you are looking at business analyst skills here is the GDS view.

– Andrew Sandford (original LinkedIn post)

This was an interesting comment I saw on LinkedIn the other day and having worked as a Business Analyst in many large scale, UK public sector digital transformation programmes following GDS guidance, I felt moved to comment.

My personal experience is that the Business Analyst role is often misunderstood, sometimes maligned, and occasionally used in ways that serve individual agendas in transformation programmes rather than following the true intention of GDS.

Below are a couple of scenarios which I’ve seen time and time again where the Business Analyst finds themselves off course and wandering down the overgrown garden path…

I wanted to write this post as something useful to those involved in putting together teams with a Business Analyst in them, or alternatively those team members who work alongside a BA.

Anti-Pattern 1: Business Analyst isn’t allowed to speak to real users

The GDS requirement (as commonly interpreted) for a User Researcher, UI Designer and a Business Analyst to all be on the same Discovery team ‘collaborating’ together has often, and significantly sidelined the BA in what they can do, what they are allowed to do, and what they have to offer.

Recently the DWP wrote a blog post about how their Business Analysts work alongside User Researchers (How user researchers and business analysts work together to make a difference for users).

I personally don’t agree with implicit delineation DWP operates under that user researchers work “front of house” whilst the BA works “back of house”.

Is there a difference between public users and internal users / staff? Aren’t these all just people who have needs, painpoints, emotions, and intended goals in mind? 

Why aren’t they all just ‘leveled’ into ‘a user’ that is then investigated in an attempt to better understand their needs?

Not long ago before GDS came into being, many BAs were skilled and experienced in interacting with users, doing research, designing mockups, testing product features. A good BA who gathers system requirements doesn’t just ask “what do you want?”. They seek to understand environmental context and constraints around the intended user goals. How is this not UX?

My observation is that some user researchers working in government come from a “liberal arts / social sciences” background (nothing wrong with that per se) but as a result feel more comfortable working on open ended Discovery and exploratory work – often dropping out or moving on after the initial research is done. Rather than being comfortable and experienced in being more aligned to building a product and iterating it through testing and feedback

Recently I clarified with a Delivery Manager and also individual team members what their expectations were of the Business Analyst in their multi-disciplinary setup – the answer was “map backend systems, get API details, write JIRA tickets”.

I felt at the time, and still do, that view results in a terrible waste of a good role and something most experienced Business Analysts would think twice about signing up for at an interview. Plus it can be pretty monotonous doing just that kind of work all day, every day if you are used to having a more broader remit.

Perhaps the GDS Business Analyst role would be better off renamed to “Technical Architect” if they are to remain working back of house – that may make a lot more sense in many cases.

Anti-Pattern 2: Business Analyst does the job of the Product Owner or Project Sponsor

There’s another situation that commonly crops up for the Business Analyst in Government. This is where the BA is hired to work on a programme / project / workstream but then finds out that whilst the work has been approved “in principle”, the funding has not actually been released.

The Business Analyst may then discover a Product Owner that is absent, one who is not engaged, or simply that one has not even been appointed – with a request made of the BA to “draft a quick and simple” 1 page outline business case to get funds for ‘their team’.

That draft business case is then requested to become more formalised after a management review finds there is not enough “detail to satisfy the CFO” and the BA is then asked to do stuff like 5 year forward projections, VAT calculations on staff costs, detailed financial modelling and benefits realisation etc in order to release funds.

(Sometimes these calculations are required after-the-fact by the BA’s manager to justify hiring the BA in the first place, so it becomes a game of catch up… or chicken and egg. Plus in this scenario, the BA can often feel personally responsible for obtaining financial approval for their own role…)

This kind of situation arises because senior management effectively abdicate their programme responsibility (willingly or unknowing) and allow it to fall to to the most able member of the team, often the skilled Business Analyst.

Frank Ray

Frank Ray & Associates is a software engineering consultancy that builds high quality software for businesses.

We develop new applications, automate manual processes, integrate vendor packages, replace Excel workarounds, fix unreliable applications, retire end of life software and remove dependence on poor value suppliers.

Get in touch if you need our help