Most failed projects don’t fail technically. They get built against requirements nobody understood the same way. An analyst sits with your people, writes down how the work actually happens, and turns that into something you can estimate and build against.
Most budget overruns don’t start in development. They start earlier — at the moment somebody assumed that “everyone understands what we’re building”. A requirement written in one sentence means one thing to sales, another to the developer and a third to the user, and that gap is discovered only once the code is finished.
Business analysis is where the gap gets caught. We don’t write down what you tell us — we argue with it: why this step exists at all, what happens if it’s dropped, and who it creates value for. The output is requirements you can price and build from — and they remain yours even if you give the development work to somebody else.
Six pieces of work that usually travel together. On a smaller project they fit inside a two-week sprint; replacing a large system, the mapping alone takes several weeks.
A joint session with your key people and our engineers, architect and designer. Two days usually yields more than a month of email, because contradictions surface in the room straight away.
How the work actually runs today — not how it is supposed to. The gap between those two is usually exactly where a project later comes off the rails.
User stories with acceptance criteria, and the non-functional requirements — load, availability, compliance — written so they can be tested. Priorities are set by business value rather than by the order things were mentioned in.
Where a system already exists, we review the code, the database and the integrations before promising anything. Most unpleasant surprises are already visible here.
A high-level architecture and technology choice with the reasoning attached. Where an assumption is risky, we build a small proof of it rather than arguing about it in a meeting.
A phased plan where each phase has its own business outcome and its own order-of-magnitude cost. That lets you decide phase by phase rather than committing to everything at once.
The output of an analysis has to be readable a year later, by somebody who wasn’t in the room. So we use ordinary tools rather than templates of our own, and hand everything over in your accounts.
Not a deck, but a set of documents you can take to tender, defend a budget with, and start building from. All of it is yours even if you continue with somebody else.
Written so they can be priced and tested, rather than as a wish list.
The current and target state side by side, so the gap is visible to somebody who wasn’t in the room.
Enough architecture for the estimate to hold, and little enough that you are not yet committed to anything.
A phased roadmap where every step can be approved and costed on its own.
Business analysis is bought separately and paid for on its own, with no obligation to buy development from us. That is deliberate: an estimate produced by the party who also wants to build tends to be optimistic.
From your side we need one decision-maker and access to the people who actually do the work. The time cost is usually six to ten hours per key person, split across interviews and two review sessions. Most wrong assumptions come from asking a manager how the process runs rather than the person who runs it every day.
The estimate arrives only at the end of the analysis. Before that nobody has enough information, and a number given at that point is a sales argument. We estimate the whole delivery chain — analysis, design, development, testing, project management and meetings — because overruns almost always come from having costed only the time spent writing code.
The requirements are written by somebody who can also say what they cost to build. That prevents a document that reads well and cannot be delivered.
For every requirement we ask what happens if it is dropped. Most of the scope usually disappears in response to that one question.
The documentation is written so you can take it to tender. We don’t write requirements around our own technology preferences.
The expensive surprises — compliance requirements, data migration, an integration that doesn’t exist — surface in analysis rather than in testing.
The output is a document you can read and disagree with. Things agreed in a meeting do not stay agreed.
We are in Tallinn, in the same timezone and the same contractual framework. Data can stay entirely inside the EU.
Yes. It’s a paid two-week engagement, and the output — process maps, user stories, a data model and an estimated scope — is yours even if you give the development work to somebody else.
Typically six to ten hours in total per key person, split across interviews and two review sessions. We don’t ask for full-time commitment, but we do need access to the people who actually do the work.
Process maps of the current and target state, user stories with acceptance criteria, a data model, business rules, a risk list, and a prioritised scope with an order-of-magnitude cost for each phase.
Because “we know what we want” and “we have agreed what that means” are two different things. A requirement written in one sentence means one thing to sales, another to the developer and a third to the user. Most budget overruns don’t start in development — they start here, and are discovered only once the code is finished.
In practice the analysis has another effect people don’t expect: the scope shrinks. Ask of every requirement what happens if it’s dropped, and a significant part of what was originally requested usually disappears. That alone often pays for the analysis.
Yes, and that’s deliberate. The documentation is written so you can take it to tender: the requirements are supplier-neutral and we don’t write them around our own technology preferences.
It’s also why the analysis is bought and paid for separately. An estimate produced by the party who also wants to build tends to be optimistic — and you can’t check it until it’s too late. What you get from us is an estimate you can compare other bids against.
The estimate comes at the end of the analysis, not the start. Before that nobody has enough information, and a number given then is a sales argument.
We estimate the whole delivery chain rather than developer hours: analysis, design, development, testing, project management, meetings and non-working days. Overruns almost always come from having costed only the time spent writing code. The output is a phased roadmap where each phase has its own business outcome and order-of-magnitude cost — so you decide phase by phase rather than committing to everything at once.
Describe your situation in a couple of sentences. We reply within one working day.