Expert Perspective: Lessons on Transformation Analytics

The deliverables landed; the transformation did not

I have sat in a steering committee where the RAG dashboard was green on every workstream, the milestone tracker showed every deliverable on time, and the budget burn was within tolerance. Six months after programme close, the business unit was being restructured because the capability the programme was supposed to build had not embedded.

The deliverables had landed. The transformation had not.

That is not a rare outcome. McKinsey's transformation research consistently shows fewer than 30% of large-scale transformations achieve their intended outcomes. Prosci change effectiveness data sits in the same range. The Standish Group's CHAOS research has tracked this for three decades and the success rate has not fundamentally improved. What has changed is the understanding of why: programmes instrument the project and neglect the change.

Programmes measure what was built, not what was learned

Most transformation programmes are flying blind — not because they lack data, but because they are pointing their instruments at the wrong thing. They track what was built, not what was learned. They monitor delivery velocity, not capability accumulation. When the programme closes, nobody can say with confidence whether the organisation is actually more capable of operating differently.

Digital accelerators (D6 of the 6xD framework) are defined by one property: they compress the feedback loop between what was built and what was learned. Transformation analytics belongs in that category precisely because it shortens the lag between a capability decision and the evidence that the decision worked — from months to weeks.

The metrics that matter exist, but no one builds the infrastructure to capture them

The deliverables-complete, capability-absent pattern has a specific structural cause: the measurement system tracked delivery, not change. Nobody saw it coming because nobody was measuring the right thing.

The metrics that constitute a meaningful transformation measurement framework are not difficult to identify. Capability maturity by domain. Platform adoption depth — not rollout breadth, but the degree to which the platform has been embedded in actual decision workflows. Decision latency reduction. Architecture rework rate between capability waves.

None of these are standard project KPIs. All of them are available if you design the measurement infrastructure at programme inception, not at close. The most common failure mode is not a lack of analytics ambition. It is that the analytics infrastructure was never built, the metrics were never defined, and by the time someone asks the question, the programme resources are already committed to close.

Sort your metrics into project versus transformation before the next workstream

Before your next workstream starts, pull your current metrics set and sort them into two columns: project metrics (on-time, on-budget, on-scope, milestone completion) and transformation metrics (capability accumulation, platform adoption depth, decision quality, architecture rework rate). Count each column.

If the project column is longer, you have a measurement gap. That gap is not a reporting problem. It is a steering problem. You are navigating a complex programme with instruments that tell you about the road, not about the destination.

Define three to five transformation-level metrics before the next workstream starts, with named owners and defined collection methods. Bring them to your next steering conversation. The quality of that conversation will change immediately — because the questions the metrics force are the questions that determine whether the transformation will be real or merely complete.