The method

Four stages, sixteen deliverables,
one standing rule.

Foundation before operating model. Operating model before AI. Every engagement runs in that order, and each stage ends with a clear decision point rather than rolling forward on momentum.

01

Assess

What happens

A short series of structured conversations, before either side commits to anything. The ground being covered: who owns the problem, whether there's a real budget behind it, what access to systems and people would actually look like, and whether leadership genuinely wants an honest answer or a validation exercise.

Just as importantly: whether this is really a technology problem at all, rather than a staffing, funding or leadership problem wearing a technology costume.

What it produces

  • A clear go/no-go, with the reasoning stated
  • If it's a go: a scoped engagement letter covering the work ahead

What it ends with

Either a signed engagement, or a courteous no with the door left open. A well-handled no is worth as much as a yes.

02

Discover

What happens

The deep dive. Structured interviews across finance, technology and operations leadership, and, just as importantly, the people who actually run the workflows day to day, since that's usually where the truth lives.

Three layers get examined in order. The foundation: the data estate, its structure and ownership, the systems of record, how they connect, and what the whole stack is actually costing. The operating model: walkthroughs of the workflows that make the money (order-to-cash, procure-to-pay, record-to-report), plus a census of the shadow spreadsheets holding things together, and the single points of failure nobody has written down. Then the AI layer: what's already in use, sanctioned or otherwise, how AI-literate the teams really are, and a first honest sift of genuine candidates from noise.

What it produces

  • A system and data map: everything running, what talks to what, and what it costs
  • A red/amber/green assessment against benchmarks built from three decades of comparable programmes, with the evidence behind every score
  • A keep / fix / replace position on every material system and process
  • A risk and dependency register: the failures waiting to happen, ranked
  • A findings readout, written for a board rather than an IT department

What it ends with

The findings walked through with leadership in person, headline priorities agreed, and a decision on whether to proceed to Design.

03

Design

What happens

The target design across whichever layers matter for this business, sequenced so that each initiative only starts once the thing it depends on is actually true.

This is also where the “not yet” advice lives. AI initiatives appear here only if the foundation genuinely supports them, and where it doesn't, they go into a conditions-to-unlock list instead. Where a new system is genuinely in play, this is where thirty years of implementations earns its keep: most platforms in a category are broadly comparable, and the useful question is never which is best in the abstract, but which fits this specific situation.

What it produces

  • A target design and sequenced roadmap, with indicative effort and cost ranges
  • A delivery path assessment
  • Depending on the path: a shortlist of well-suited partners with the reasoning stated, or an honest review of the partner already in place
  • A negotiation position: target terms, walk-away points, and the accountability mechanics worth writing into any delivery contract

What it ends with

Roadmap signed off, delivery path confirmed, and a mandate to act on it.

At the design stage

Not every engagement needs a new delivery partner.

Design is often assumed to end in a shortlist of vendors. In practice it branches three ways, and working out which one applies comes before recommending anyone.

No existing capability

A shortlist is drawn from the qualified network, and the terms are negotiated on the client's behalf.

Capability already in-house

No partner is brought in at all. The client's own team delivers, with oversight and design support around them.

A partner already in place

Frequently the real situation, and sometimes the reason for the call. The existing relationship gets assessed honestly against the same criteria used to qualify anyone new, with a clear keep, fix or replace position attached.

A shortlist of new suppliers is the easy recommendation. Correctly identifying that a business already has what it needs, and simply needs better oversight of it, is the harder and more useful answer.

04

Advise through delivery

What happens

Delivery contracts are signed directly between the client and the delivery partner. The negotiation, the terms, the milestones and the accountability mechanics are all shaped on the client's behalf, and then policed.

In practice that means attending steering and milestone reviews as the client's advisor: translating delivery-speak, testing progress claims against what was actually designed, and raising flags early rather than diplomatically late. It does not mean attending daily stand-ups or managing the delivery team.

Accountability runs both ways. The partner is held to the design and the contract; the client is held to their own commitments: data access, decision speed, staffing the change properly. Most programmes that fail, fail on the client side, and saying so plainly is part of the value.

What it produces

  • An agreed oversight cadence: which forums get attended, what gets reviewed, how flags escalate
  • Short, plain-English assurance notes at each milestone: on track, off track, or what has to change
  • A record of every commercial event in the delivery relationship, and the position taken on each

What it ends with

Per project, defined at contract signature, continuing as a light advisory relationship for as long as it's genuinely earning its place.

Four stages, sixteen named deliverables, and a standing rule: foundation before operating model, operating model before AI. Never the other way round.

Start with a conversation,
not a pitch.