Business analysis has an image problem it largely inherited from its own paperwork. Ask most executives what a business analyst does and the answer involves requirements documents, process maps and workshops, all of which are true and all of which describe activity rather than outcome. The outcome that matters is a decision made with enough clarity that it does not need to be revisited three weeks later.
Reframe the role around that outcome and a lot of practice changes. The analyst stops being the person who writes down what stakeholders say and becomes the person who forces the stakeholders to say something decidable in the first place, which is a much harder and much more valuable job.
Requirements documents are not the product
A forty-page requirements specification feels like progress because it took effort to produce and it is comprehensive. Comprehensiveness is not the same as decision-readiness. Many specifications are comprehensive precisely because nobody was willing to make the hard trade-off calls that would have made them shorter, so every option got documented instead of a choice being forced.
The discipline worth building is asking, of every requirement, what decision does this inform and who is going to make it. If neither answer is clear, the requirement is not ready to be written down. It is ready to be argued about, which is a different and earlier stage of work.
A requirements document nobody has decided to act on is not an output. It is a well-formatted delay.
Analysis exists to close decisions
The most effective business analysts behave less like scribes and more like people running a negotiation. They come into a workshop with a hypothesis about what the answer should be, use the discussion to stress-test it against the people who actually know the process, and leave with either a confirmed decision or a specific, narrow question that still needs answering. What they do not leave with is a long list of open items to be chased later, because that list is where decisions go to die.
This requires a different set of skills than pure requirements elicitation: the confidence to propose an answer rather than only ask questions, the judgement to know which disagreements are substantive and which are semantic, and the discipline to write down a decision the moment it is made rather than waiting for a tidier version of it to arrive later.
- 路Ask what decision a piece of analysis is meant to inform before starting it
- 路Bring a hypothesis into every workshop, not just questions
- 路Write down decisions the moment they are made, in the room
- 路Treat a growing list of open items as a warning sign, not a normal artefact
Measuring the role differently
If the outcome is decisions, not documents, then the metric should follow. Documents produced, workshops run and requirements logged are activity measures that can all be high while a programme is still stuck. Decisions closed per week, and how long each decision took from being raised to being resolved, measure something a sponsor actually cares about.
This is uncomfortable for analysts used to being judged on the quality of their artefacts, and it should be. It is a harder standard, but it is the standard that maps to what the business is actually paying for, which is momentum, not paperwork.
None of this diminishes the craft of good analysis. It sharpens it. Understanding a process deeply enough to know exactly which decision needs making, and framing that decision so it can be made in the room rather than escalated indefinitely, is harder than writing it all down and hoping someone else resolves the ambiguity later.
The programmes that move fastest are usually not the ones with the most detailed documentation. They are the ones where every piece of analysis has a decision attached to it, a named owner, and a date by which it stopped being a discussion and became a fact the delivery team could build on.