Approach · Delivery path
Delivery path.
Five stages from ambiguity to an owned system, each with a purpose, an output and an exit condition.
From ambiguity to an owned system.
Each stage has a purpose, an output and an exit condition. The exit condition is what prevents a stage from becoming an open-ended conversation.
A delivery path is a sequence of decisions that reduces uncertainty in the right order, not a schedule. The stages below are how we structure that sequence for a typical build, migration or integration engagement.
The time spent in each stage depends on the problem. A well-understood enhancement may move quickly; a complex legacy replacement may need more discovery and architecture. The boundaries stay the same.
What happens, what it produces and when it is done.
The artefacts are the evidence that the next stage has a stable foundation, not bureaucracy.
Discover — establish the problem
We clarify the operating problem, the people affected, the constraints, the current systems and the measures of success. We review existing documentation and interview the owners of the process. Output: a discovery brief, a current-state map and an agreed problem statement. Exit: the client confirms the problem and the measures.
Architect — define the system
We define boundaries, data ownership, interfaces, security posture, deployment model and delivery sequence. We test the design against the constraints and document the alternatives considered. Output: target architecture, decision record, risk register and delivery plan. Exit: architecture review and client approval of the plan.
Build — prove the increments
We deliver in tested increments, each with acceptance criteria and a demonstration. Progress is measured by working capability, not by effort consumed. Output: working software, tests, documentation and a release note for each increment. Exit: acceptance of the agreed increment and confirmation of the next.
Integrate — make the boundaries work
We connect systems, data and partners with explicit contracts, authentication, failure handling and monitoring. We test normal, degraded and failure conditions. Output: integration contracts, runbooks, monitoring and reconciliation procedures. Exit: end-to-end process acceptance and operational readiness review.
Support — transfer ownership
We complete documentation, knowledge transfer, support procedures and the operational handover. Where required, we remain involved through a retainer or support agreement. Output: handover pack, support model, known issues and improvement backlog. Exit: the client confirms operational ownership and the support path is active.
What can go wrong at each stage.
Most delivery failures are known risks that were never given a decision point. We design the path so that those risks have a place to surface.
Discovery without access
If the people who do the work are not available, the problem statement becomes a summary of assumptions. We ask for access to the operating reality, including the exceptions.
Architecture without authority
An architecture with no one accountable for enforcing it is ignored. The engagement needs a decision owner who settles boundaries and priorities.
Delivery without acceptance
If acceptance criteria are vague, the end of the project becomes a negotiation. We define them before build and demonstrate against them during build.
Handover without ownership
If no one owns the system after launch, support defaults to the original author or to nobody. We agree the operating owner and the support path before go-live.
How we keep progress visible.
Visibility is the ability to see what has changed, what is blocked and what decision is required, not a weekly status email.
Demonstrate, do not describe
Each increment is shown in a working environment. A slide that says “80% complete” is not evidence of anything.
Report the risk, not just the colour
Status includes decisions needed, assumptions tested and risks that have changed. Green is not a substitute for information.
Record the decision
Scope, architecture and risk decisions are written down with the rationale. The record is the basis for the next change, not a memory test.
A worked example of the path in a legacy replacement.
Consider a legacy case-management system that must be replaced while the program continues to operate. Discovery maps the active cases, the rules, the documents, the interfaces and the reporting obligations. The problem statement is “move active casework to a maintainable platform without losing the audit history or interrupting the service”, not “replace the system”.
Architecture defines the case record, the document store, the identity model and the integration with the legacy database. The first build increment covers intake and assessment for one program. Integration connects the new case record to the existing correspondence and reporting services. Support includes a read-only view of historical cases and a transition plan for the remaining programs.
The sequence is kept narrow. It produces a working capability, evidence about the operating model and a set of decisions the next program can reuse. The legacy system remains available until each program has moved and the audit history has been verified.
Want to see the path applied to your system?
Tell us where you are starting from. We will propose a first stage and a clear exit condition.