Business management
Business analysis, so you build the right thing before building it well
Most failed software projects were built competently. They solved a problem that had been described inaccurately — which is a cheaper mistake to catch before development than after.
The situation
The requirement is the hard part
Development is expensive, so the temptation is to start it quickly. Almost every expensive rework we see traces back to a requirement nobody had written down properly.
- A requirement expressed as a solution rather than a problem
- Departments describing the same process differently
- A quote that varies wildly between suppliers, because the brief is ambiguous
- No agreement on what success would look like
- A previous project that delivered what was asked but not what was needed
- Documentation that describes the process as designed, not as run
What it covers
What business analysis covers
Process mapping
How the work actually runs, established by observation rather than by asking a manager to describe it.
Requirements
What the system must do, written so a developer can build it and you can test whether they did.
Stakeholder alignment
Surfacing where people want different things, before that disagreement becomes a change request halfway through.
Options and trade-offs
What could be built, what each option costs, and what it would rule out later.
Success criteria
How you will know it worked, agreed at the start rather than argued about at the end.
A brief you can procure against
Documentation good enough to get comparable quotes — from us or from anyone else.
How we work
How an analysis engagement runs
Short and self-contained. Analysis that outlasts the appetite for the project it was meant to enable has failed at its own job.
Observe
Watch the work being done and talk to the people doing it, not only to the people who own it.
Map and question
Document the current process and challenge the steps nobody can justify, which is often where the real finding is.
Define
Write requirements, options and success criteria in language the business and a developer can both use.
Hand over
A brief you own and can take to any supplier, including one that is not us.
Outcomes
What you are left with
- A documented view of how the process actually runs today
- Requirements specific enough to build and test against
- Disagreements surfaced before they become change requests
- Options with real costs attached rather than one proposal
- Agreed criteria for what success looks like
- A brief you can take to any supplier
Common questions
Questions we are usually asked
You can, and for a small, well-understood change it is often the right call. For anything substantial it tends to be a false economy: the cost of building the wrong thing is always higher than the cost of establishing what the right thing was.
Possibly not. If you can state the problem, the process, the constraints and how success will be measured, you may have already done the analysis. Where it usually helps is when different parts of the organisation would answer those questions differently.
No. The output is a brief you own. It is deliberately written so you can take it to any supplier and get comparable quotes — which is also the fairest test of whether the analysis was any good.
Usually weeks rather than months, and it should be scoped tightly. Analysis that runs longer than the enthusiasm for the project it was meant to enable has defeated its own purpose.
Then it has paid for itself many times over. Some of the most valuable engagements end with a recommendation to change a process, buy a product, or do nothing at all.
The people who do the work, not only those who manage it. The gap between how a process is described and how it is actually performed is where most requirements go wrong.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Change managementGetting a new system actually adopted rather than merely delivered.
- Project managementDelivery run by people accountable for the outcome.
- Business automationTaking the repetitive administration out of a process.
- Bespoke business applicationsSoftware shaped around how you work, when nothing off the shelf fits.
- Digital process automationApprovals, workflows and handoffs that currently sit in an inbox.
- Operational systemsThe systems that run the day-to-day work of the business.