Analysis & architecture
Frame it and architect it before you build it.
Many projects fail before the first line of code: the need is badly framed, the scope is unrealistic, the architecture is chosen out of habit. An analysis phase exists to produce documented decisions and to establish what will not be done. It is not always necessary, and we will say so.
When an analysis phase helps
When a structural decision is at stake and opinions diverge.
You are torn between buying an off-the-shelf product and building custom software.
A project has been quoted by several suppliers with gaps nobody can explain.
You have to replace a core system and you do not know where to start.
Several teams have different views of the same requirement.
A previous project stalled halfway and you want to understand why before restarting.
You have to present an investment case and you need figures that hold up.
What an analysis covers
Understand what exists, establish what is genuinely being asked for, then decide.
Understand what exists
- Mapping of applications, flows and dependencies
- Reading the code and the infrastructure in place
- Business rules buried inside current tools
- Points of fragility: unmaintained dependencies, knowledge held by one person
Establish the need
- Interviews with the actual users, not only the sponsors
- Describing processes as they are, before how they should be
- Separating requirements from preferences and habits
- Explicit prioritisation, including what is out of scope
Decide
- A reasoned comparison of the options, including changing nothing
- Architecture decisions documented with their trade-offs
- Estimates of build cost and running cost
- A staged trajectory rather than one monolithic project
What an analysis pushes back
Each step removes unknowns before a line of code is written. This is the moment when decisions are cheapest to change.
- 01
Business problem
The symptom, before any solution
- 02
Process & users
What actually happens, workarounds included
- 03
Scope
What is in, and above all what is out
- 04
Architecture
The structural choices and their trade-offs
- 05
Priorities
The build order and its dependencies
- 06
Solution to build
A project that can be priced, split into stages
- 01
Business problem
The symptom, before any solution
- 02
Process & users
What actually happens, workarounds included
- 03
Scope
What is in, and above all what is out
- 04
Architecture
The structural choices and their trade-offs
- 05
Priorities
The build order and its dependencies
- 06
Solution to build
A project that can be priced, split into stages
Uncertainty never reaches zero. The goal is to get it low enough to commit a budget without gambling.
When an analysis is not necessary
Billing a study phase on an already clear requirement helps nobody.
- The need is already framed
- If the process is understood, the scope stable and the decision made, go straight to building. A study will only delay the first useful version.
- The scope is small
- On a short project, a preliminary study can cost more than building a first version and adjusting it in use.
- The decision is already taken
- When the choice has been settled for reasons that are not technical, an analysis only dresses it up. We would rather say so than produce a justification document.
How an analysis engagement runs
An analysis is short and bounded: the report-back date is fixed before work begins. If it lasts longer than the first stage of the project it prepares, it has missed its purpose.
- 01
Frame the question
What decision do you have to make, by when, and with whom? Without that question, an analysis produces a document with no recipient.
- 02
Gather
Interviews, reading the code and the data, observing real processes. We talk to the people who use the tools, not only to those who commission them.
- 03
Weigh the options
Each option is assessed with its costs, its risks and what it rules out later. Including the option of changing nothing.
- 04
Report back
A live walkthrough with the decision-makers, a document that stands on its own, and a recommendation we are willing to defend.
What can be produced
Not everything is needed on every engagement. The deliverable is agreed at scoping, based on the decision at hand and on who will make it.
- 01
Map of the existing landscape
What actually runs, what depends on what, and what is no longer maintained.
- 02
Decision paper
The options considered, their trade-offs and a reasoned recommendation.
- 03
Target architecture
The intended design and, above all, a realistic staged path to get there.
- 04
Cost estimate
Build cost and running cost, with the underlying assumptions written down.
- 05
Roadmap
A breakdown into deliverable stages, with dependencies and risks identified.
- 06
Requirements document
When you need to go to market, a document that produces comparable responses.
How we work
An analysis runs as a short engagement. It can lead to a project, to supporting your teams, or to nothing at all if that is the right conclusion.
Consulting & team extension
Our consultants join your team to bring the skills you need: development, functional analysis, technical analysis, business analysis or architecture.
Learn moreCustom project
We take responsibility for the whole thing: analysis, design, development, integration, delivery and evolution.
Learn more
Related use cases
Modernise business software
The application still works but is becoming expensive to maintain, hard to change and dependent on a handful of people.
Automate a business process
The same information is entered several times, approvals happen by email, and nobody can say where a file currently stands.
Connect systems that don’t talk to each other
Your ERP, your CRM and your business tools each hold part of the truth, with no reliable exchange between them.
Frequently asked questions
Can we run an analysis without giving you the build afterwards?
Yes, and it happens regularly. The deliverable is designed to be usable by any team, including your in-house developers or another supplier. A paper only its author can act on is not a deliverable.
What if your recommendation is to do nothing?
We give it anyway. Some situations resolve through a process change, a configuration change, or dropping a badly framed project. That is an outcome of the engagement, not a failure.
Do we need a specification before contacting you?
No. Many requests arrive as a symptom: "our teams are losing time", "this system will not hold". That is a sufficient starting point. A specification written too early usually freezes a solution before the problem has been stated.
Will you work with a supplier already in place?
Yes. An analysis is not there to disqualify the existing team. In several situations the conclusion is that the scope or the prioritisation needs clarifying, not that the supplier needs changing.
Does the analysis include a budget estimate?
It can, provided the assumptions are written down. An estimate without explicit assumptions cannot be defended in a steering committee and does not survive the first surprise.
Let’s talk about the decision ahead
Tell us which trade-off is blocking you. We will tell you whether an analysis phase is justified, and what it should produce.