How we work
A delivery method built to remove the ways these projects usually fail.
Digital transformation projects rarely fail on technology. They fail on scope drift, unrehearsed data, absent ownership and automation applied to a process nobody agreed on. This is the methodology we apply, and the controls we recommend at each stage - shaped to the scope of each engagement.
At a glance
- Method
- Discover, Analyse, Design, Implement, Automate, Optimise.
- Structure
- Phased delivery with agreed outputs at each stage.
- Handover
- Documentation written so the system can be maintained internally.
Method
Six phases, each with an output you can review.
Our recommended approach is that no phase starts before the previous one has produced something you have read and agreed to.
01
Discover
Interviews with the people doing the work, a walk of the actual process, and a systems and data inventory - including the spreadsheets and workarounds keeping the business running. Checkpoint: A documented current state you can read and correct.
02
Analyse
Where time, margin and visibility are lost, quantified with your own numbers where they exist. Checkpoint: A prioritised list of constraints, not a feature wishlist.
03
Design
Target operating model, data model, integration boundary and platform fit. Checkpoint: Decisions recorded with the reasoning and the date.
04
Implement
Standard-first configuration in phases, rehearsed data migration, UAT run by your team against real scenarios, and a cutover plan with rollback criteria. Checkpoint: Agreed acceptance criteria met before cutover.
05
Automate
Automation and AI added once the process is stable and the data is trustworthy. Automating a broken process only makes the error rate faster. Checkpoint: A baseline measured before the change, and after.
06
Optimise
Post go-live review against the outcomes agreed in Analyse, then a rolling improvement backlog owned jointly with your team. Checkpoint: A named internal owner holds the backlog.
Each phase ends at a checkpoint you review before the next begins. If a checkpoint concludes the work should be smaller, later, or different, that is a legitimate outcome. After go-live, Optimise feeds back into the same cycle - improvements are prioritised against the same constraints the engagement started from.
Governance
How we design engagements to run.
Clear accountability
We design engagements around a named point of accountability rather than passing you between a salesperson, an architect and a build team with no continuity.
Written decisions
Material decisions - scope, data, integration boundary, exclusions - should be recorded with the reasoning and the date. Scope disputes usually come from undocumented assumptions.
Phased structure
We recommend structuring work so each phase is a genuine decision point. If analysis shows the project should be smaller, or should not proceed at all, that is a legitimate outcome.
Change is priced, not absorbed silently
Changes should be estimated and approved before work starts. Silent absorption is how projects end late with quality quietly reduced somewhere else.
Risk
How implementation risk is reduced.
We do not publish client logos or case metrics we cannot evidence. What we can show you is the methodology, and the controls that typically address each common failure pattern.
How projects fail
Common failure patterns
- Platform chosen before process is understood
- Migration attempted once, at cutover, with no rehearsal
- UAT demonstrated by the implementer, not run by users
- No named internal owner after go-live
- Automation layered onto an unstable process
- Documentation that only the implementer can read
Controls we recommend
How a robust project counters it
- Discovery before any platform recommendation
- Rehearsed migration runs with reconciliation output
- Scenario-based UAT with agreed acceptance criteria
- A named internal owner and admin enablement before go-live
- Automation staged after process stabilisation
- Plain-language configuration and process documentation
Controls
What each control is intended to protect you from.
| Control | What it protects |
|---|---|
| Discovery before build | Scope and estimate are based on your real process, so the build quote is not a guess that later becomes a variation. |
| Phased delivery | Value lands earlier and each phase is a genuine decision point instead of an all-or-nothing commitment. |
| Rehearsed migration | Data defects surface in a build environment before cutover, not on the morning the old system is switched off. |
| User-run UAT | Adoption problems appear while there is still time and budget to change the design. |
| Support through the first business cycle | The period when finance and operational exceptions actually surface is covered rather than left to the team alone. |
| Documented handover | Configuration and process documentation written so the system can be maintained without depending on any single provider. |
Frequently asked questions
- Do you start with a platform recommendation?
- No. We start with the process, the data and the constraint. A platform recommendation that arrives before anyone has mapped how work actually flows is a sales position, not advice.
- How is a project scoped?
- Through a discovery stage sized to the project. Discovery typically produces a documented current state, a target operating model, a phase plan and an indicative estimate range, so the scope is based on your real process rather than assumptions.
- Why does automation come after implementation in the method?
- Automating a process that is still changing multiplies the rework. We recommend stabilising the process and the data first, then removing the manual movement of information.
- What should a good post go-live plan include?
- A defined support period covering the first full business cycle, an owner for the improvement backlog, and a documented handover so the configuration can be maintained internally or by another provider. The specifics are agreed per engagement.
Ask us how we would run your project.
Bring a process that is not working. We will talk through how discovery would approach it and what the first phase would need to prove.