Hire Business Analysts for Enterprise Programmes

Why the specification decides most of the cost

Most of the cost of a programme is decided in the specification, and the specification is the part most often treated as paperwork to be got through. “The system should allow the user to approve” is not a requirement. It is the title of one. Who approves, on what basis, what happens to the thing they did not approve, what the next person sees, and what an auditor can reconstruct six months later — that is the requirement, and if nobody writes it down the developer will decide it by accident.

As documented, versus as actually run

The second failure is describing the process as it is documented rather than as it is run. The documented version has no exceptions in it. The real one has a supervisor who overrides a price by phone, a spreadsheet that tracks the twelve orders the system cannot represent, and a rule everyone knows that is written nowhere. A system built from the documented version goes live and immediately acquires a shadow spreadsheet, because the exceptions never went away.

The way to find the real process is to follow one live case end to end, with the person who handles it, and to ask at every step what they do when it does not go that way. Workshops produce the documented version. Sitting next to somebody produces the other one.

The requirements live in the exceptions

So the useful analyst is the one who asks what happens when it goes wrong, and keeps asking. Anyone can describe the happy path. The requirements live in the exceptions, and the exceptions are where the arguments — and the change requests — come from later.

Exceptions are also where the disagreements between departments surface, which is the second reason to go looking for them early. A rule that finance and operations each believe they own is a change request in month five and a conversation in week two.

What an acceptance criterion has to survive

An acceptance criterion is finished when a tester can make it fail. That sounds obvious and it disqualifies most of what gets written, because “the report should be accurate” and “performance should be acceptable” cannot fail — they can only be argued about.

The version that survives names the input, the expected outcome, and the conditions under which the outcome changes. It also names what should not happen: the document that must not post, the user who must not see the record, the second submission that must not create a second order. Negative criteria are the ones most often missing and most often the reason a defect is disputed.

Data is part of the specification

A specification that describes behaviour and says nothing about the data it will run on is half a specification. Which records are migrating, what the system should do with the ones that are not, what happens to an open transaction that references something that did not come across — these are functional decisions and they arrive at cutover if they are not taken earlier.

The analyst’s contribution here is not to run the migration. It is to make sure every mapping decision has a named owner from the business, and that the reconciliation somebody will eventually sign has been defined while there is still time to change it.

Working inside your process, not around it

We staff analysts to work inside your process rather than around it: your tooling, your ceremonies, your definition of done, and your people signing off what they will have to live with.

That includes being present after handover. An analyst who writes a specification and leaves before UAT never learns which of their assumptions were wrong, which is the only way the next specification gets better.

When a business analyst is not the missing piece

If the process is well understood, agreed between the departments it touches, and already written to a level a developer can build from, adding an analyst adds a translation layer. That is a real cost and it is occasionally paid for no reason.

If what is actually missing is a decision — somebody senior enough to settle a disagreement between two functions — an analyst will document the disagreement carefully and it will remain unsettled.

This role earns its place where nobody can currently state the process end to end, where the same requirement has been rewritten three times, or where the exceptions are being handled in spreadsheets that nobody has looked at.