Business Analysis
Getting what the business needs out of people's heads and into something a team can build from, describing the operation as it really runs.
Nobody had counted
There is what the process document says. There is what the system actually does. And there is what the team does at half past four when the system will not let them do the right thing. These are rarely the same process, and a build that assumes they are goes wrong in the last month rather than the first.
Our job is to find where they diverge, write down which version is the one worth building for, and say why. That means watching the work and asking for examples rather than descriptions - people give you the tidy version from memory and the real one from a story about a bad Tuesday.
Where two parts of the business want opposite things, we put the disagreement in writing and take it to whoever can settle it. Finding that in a workshop costs an afternoon. Finding it in user acceptance testing costs a release.
One of our four consultancy limbs. The others are architecture, software delivery and delivery diagnosis.
Four ways we get brought in
Most of this work starts as one of these. You don't need to know which before you talk to us.
Requirements definition
What the system must do, what it must not, and which constraints are real rather than habit.
Process discovery and workshops
Where the process lives in several heads and none agree. We run the sessions and write up what was said.
Written specifications
A document a supplier can price and a team can build from without ringing you every second day.
Data and reporting analysis
What the operation holds, where it disagrees with itself, and what honest reporting would take.
What we go looking for
- The exceptions
- The happy path is easy and nobody argues about it. The cost of a build sits in the cases people describe as "that hardly ever happens", which on inspection happen several times a week.
- The workarounds
- A spreadsheet beside the system is a requirement nobody wrote down. It is also the fastest way to find out what the system was supposed to do and doesn't.
- What the numbers are for
- Reports get requested by habit. Asking who reads a figure and what they do differently because of it removes more scope than any prioritisation exercise.
- Who has to agree
- Named, early. Most specifications that stall are waiting on a decision nobody realised was theirs to make.
What lands on your desk
- A written specification
- Of the operation as it really runs, including the exceptions and the workarounds.
- The open questions
- Named, with who needs to settle each one.
- What we deliberately left out
- And why - the half that makes the rest of it honest.
What it looks like when it works
Finding what is actually there is the work. A national operator turned out to be billing through 10 to 12 billing types and thousands of separate prices for the same services; nobody had counted before. The consolidation that followed became a review that has run every year since.
| Item | Result | Notes |
|---|---|---|
| Manual invoicing | 10 hrs a week | down from 20, after consolidating 10 to 12 billing types and thousands of separate prices for the same services |
| Customer base analysed | 310,000 | by a team of three, sizing a regulated rollout before it started |
| Households rolled out to | 72,000 | inside the regulator's 12-month deadline |
Common questions
We already know what we want. Do we need this?
Sometimes not, and we will say so. It is worth doing when several parts of the business want different things and nobody has noticed yet, or when the people who know how the work really happens are not the people writing the requirements.
Is this just writing user stories?
Stories are one output and rarely the useful one on their own. A story says what somebody wants; it does not say what the rest of the operation assumes, what the edge cases cost, or which of the four teams involved disagrees. That is the part we go after.
How do you get it out of people's heads?
Mostly by watching the work and asking what happens when it goes wrong. People describe the tidy version of a process from memory and the real version from an example, so we ask for examples - including the awkward ones nobody puts in a document.
What if two parts of the business want opposite things?
That is normal, and finding it early is the point. We write the disagreement down plainly and take it to whoever can settle it, rather than picking one quietly and letting it surface halfway through a build.
Do you hand over a document and leave?
The document is the deliverable, but it is not much use on its own. We stay close enough to answer the questions that only come up once somebody starts building, because that is when a specification gets properly tested.