Find the expensive problems early.
Most software fails on decisions taken before the first commit: the process nobody wrote down, the edge case nobody mentioned, the integration that turns out to be a person copying a spreadsheet. We find those first, then write down what should be built and why.
What we do.
The part of a project that decides what everything after it costs.
- 01Map how the work is done now, including the parts that happen outside the system.
- 02Write requirements a developer can build from and a tester can check against.
- 03Pull the integrations apart, and find out which are APIs and which are people.
- 04Work out what the regulator, the auditor or the finance team will want from it.
- 05Cut the scope into something that can ship, and say what was cut and why.
The output is the list a build gets estimated from, and the list we hold ourselves to if we build it. A document nobody opens again wastes your money and our effort.
What you get.
- 01A map of how it works todayIncluding the steps that live in someone’s inbox, on a whiteboard, or in the head of whoever has been there longest.
- 02Requirements someone can build fromWritten as things the system must do, with acceptance criteria attached, so “done” means the same to you as it does to us.
- 03The risks, named and rankedWhat could blow the estimate, ordered by how likely it is and what it would cost. Nothing buried in an appendix.
- 04A scope you can affordWhat ships first, what waits, and what we think you should never build, with the reasoning attached so you can disagree with it.
- 05An estimate you can plan againstA range with its assumptions written beside it, and a note on which of those assumptions would move the number most.
- 06The reasoning, keptDecisions, the options weighed and why one won. Long afterwards, when somebody asks why it works this way, the answer still exists.
We write specs we could be held to.
An analyst who has never shipped writes requirements that are quietly impossible or accidentally enormous, and nobody finds out until the estimate comes back. The people writing yours have built and released software themselves. A requirement with a whole hidden project inside it gets flagged while it is still a sentence, not after you have budgeted for it. And the document is written to be handed to any developer, including one who has never heard of us.
Questions, answered.
Yes. Some clients take the analysis to their own team, and it is written to be useful either way. More often it becomes the first phase of a build we go on to deliver.
It depends on how much there is to look at and how many people we need to talk to. Long enough to reach the people who actually do the work, and not so long that the analysis becomes a project of its own. We agree the scope and the price before it starts, so it is never open-ended.
The people doing the work, not only the people managing it. An hour with someone in operations usually surfaces more than reading the documentation does, because the documentation describes the process as designed and they know it as performed.
Sometimes not, and we will say so. Where it earns its keep is checking the spec against what the business actually does, and pricing the parts that were written as one line and are really a project of their own.
Then we say so. That answer is far cheaper before a build than during one, and we would rather give it than take the work and watch it go badly.
Tell us what you’re trying to fix.
Describe the process or the product that isn’t working. You’ll get questions back, and a view on whether analysis is the right next step or whether you already know enough to build.