Business Analysis
Budgets get approved against documents that describe a wish rather than a process. We write down what the system has to do, in language a delivery team can build from and price.
Most failed projects were mis-specified long before anyone wrote code. Someone produced a list of features, procurement priced it, and the mismatch with how the work runs surfaced in user testing, when it was expensive to fix. Requirements get argued out between people who disagree, written in a form an engineer can build against, then owned by someone with the authority to say no.
A wish list is not a specification
Ask around and you get as many versions of the process as there are people answering, most sincere, several incompatible. Nobody in the room has the standing to choose between them, so the contradiction stays in the document, survives sign-off, and is found by a developer halfway through the build.
- Requirements written as features people want, not as the work they do
- Conflicting answers recorded side by side, with nobody named to settle them
- The real process living in a team lead's head and a spreadsheet
- Exceptions nobody mentions until testing, because to the people doing them they are normal
Analysis that never ends is its own failure
Discovery can expand forever. There is always another stakeholder to interview, another edge case to chase, and a version of this work that quietly becomes a permanent consulting engagement. So this is scoped like any other piece of delivery: a fixed set of artefacts, a date they are due, and named people who sign them off.
What you get back is meant to leave the room. A procurement team should be able to price against it, and a delivery team, ours or anybody else's, should be able to start building from it without a second round of interviews. If a document only makes sense with one of us in the room explaining it, it is not finished.
How we get to a specification
Four things have to happen before a requirement is worth building against: watch the work, write down the exceptions, settle the arguments, and get a name against the result.
Start from the work, not the wish
We sit with the people who do the job and follow a real case through the system, including the parts that happen in email and on paper.
Requirements with a reason attached
Every requirement carries the problem it solves and the name of whoever asked for it. When the budget tightens, you can cut on evidence instead of instinct.
Data before screens
What each record means, where it comes from, who owns it and what state it can legitimately be in. Most late surprises in a build are data surprises.
Sign-off from the desk
Agreement from the people who will use the result, not only from the steering group. The steering group approves the budget; the desk knows the exceptions.
What you take away
| Deliverable | What it contains | Signed off by |
|---|---|---|
| Process map | Current flow, handoffs, exceptions | Process owner |
| Requirements catalogue | Numbered requirements, priority, source | Business sponsor |
| Data model | Entities, ownership, retention rules | Data owner and architect |
| Acceptance criteria | Testable conditions per requirement | QA lead and sponsor |
| Cost envelope | Scope options with build estimates | Sponsor and procurement |
The awkward questions
Yes, and it happens often. The output is written for a delivery team that is not us: a process map, a numbered requirements catalogue and acceptance criteria any competent supplier can quote against. We would rather the specification be good than be the ones holding the build contract, and saying so up front keeps the analysis honest.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.