Skip to content

Digital Transformation

Process, platform and people — the third of which decides whether the first two matter.

When this fits

  • Technology has been replaced before and the way of working did not change with it.

  • A programme spans several departments and nobody owns the whole outcome.

  • The organisation has bought capability it does not use.

How we work within it

  1. Process before platform

    Automating a broken process makes it fail faster. What the work actually is gets settled before what runs it.

  2. Delivered in slices that produce value alone

    Each slice is useful on its own, so a programme that stops early has still delivered something rather than leaving a half-built platform.

  3. Adoption is a deliverable

    Training, change support and measurement of actual use. A system nobody uses has the same business value as one nobody built.

What you get it on

Digital Transformation, across these domains

A delivery model is not a product. These are the technology domains we work in through it — start from the one your problem sits in.

All technology domains

Engagement and pricing model

Programme-based with defined phases, each with its own scope and exit. Deliberately not one large fixed price: a multi-year number nobody can estimate honestly is a number that gets renegotiated anyway.

What we commit to, and what we measure

  • Adoption — measured by actual use, not by licences issued.

  • Cycle time for the process being transformed, before and after.

  • Phases that delivered standalone value versus phases that only made sense as prerequisites.

Targets are set per engagement and written into the agreement. We do not publish a number here, because a service level that is not attached to a specific scope is not a commitment.

Questions we are asked

  • Is this just consulting with a longer name?

    Consulting produces a decision. This runs the programme that acts on one, across departments, over phases — including the parts that are about people rather than systems.

  • How do you avoid the usual outcome, where nothing changes?

    By treating adoption as a deliverable with its own measurement, and by slicing the work so value arrives before enthusiasm runs out. Most transformation failures are sequencing failures.

  • Who leads it, us or you?

    You own it; we run it with you. A transformation programme owned by a supplier ends when the supplier does, which is the outcome it was supposed to prevent.

  • What if priorities change mid-programme?

    The phase structure exists for that. Each phase has its own exit, so re-planning between phases is normal rather than a crisis.

  • How do you measure whether it worked?

    Against measures agreed at the start, in the business's own terms. Choosing them afterwards guarantees a flattering answer.

Start with an assessment

The fastest way to a useful answer is a short, scoped look at what you already have.