Prove before you expand: why long transformations fail

Most transformation programmes do not fail because the idea was wrong. They fail because the exit was delayed.

The decision to stop, change direction or cut scope is available at the start of a programme and gets progressively more expensive to exercise. By the time the evidence arrives that something is not working, the cost of acting on it includes budget already committed, reputations already attached, and a steering group that has spent a year explaining the plan to a board.

The mistaken diagnosis

When a programme disappoints, the post-mortem usually finds requirements. They were unclear, or they changed, or the business did not engage.

That is a description rather than an explanation. Requirements are always partly wrong at the start — that is the normal condition of designing a change to a business you are still learning about. A well-shaped programme expects to be wrong early and cheaply.

The failure is structural: the programme was designed as a single large bet that only pays out at the end. Everything before that point is progress reporting, and progress reporting is not evidence. So the first genuine test of the design arrives at the moment the organisation is least able to respond to it.

Big bet and reversible bet

The distinction is worth holding precisely, because it is the whole argument.

A big bet has large upfront spend, identity and politics attached to it, a long interval before feedback, and a delayed exit. Its defining property is that adaptability falls over time. The longer it runs, the less able the organisation is to change its mind, and the more the programme’s continuation depends on people who cannot afford it to stop.

A reversible bet is a small slice, delivered whole, that produces real operating evidence quickly. Its parts are modular and replaceable, feedback arrives while the design can still absorb it, and pivoting early is a normal outcome rather than an admission. Adaptability stays roughly constant.

Both can deliver the same end state. They differ in what happens when the first assumption turns out to be wrong, and one of your assumptions will be.

What a thin slice has to contain

A slice is only useful if it is thin in scope and complete in depth. Delivering half a chain proves nothing, because the failures live at the joins.

For a professional services firm, the slice that produces the most evidence for the least scope is the operating spine: a governed job record that carries what was sold, what was delivered, what is earned, and what is billable — for one service line, on live engagements, through a real invoice cycle.

That is deliberately narrow. It excludes most reporting, most integration beyond the ledger, and every service line but one. What it does not exclude is the part that has to work: an invoice line that links back to the time, cost, approval and contract clause that produced it. If that holds for one service line through one cycle, you have evidence. If it does not, you have found out in weeks, for a small amount of money, with the option to stop still intact.

Our approach to sequencing that first slice is described on the QuickStart page, and what it means for delivery and time capture specifically is on the delivery and time page.

What makes a thin slice dishonest

The whole argument depends on one condition, and vendors — including this one — should be held to it.

A thin slice is only reversible if the second slice is genuinely optional. If the first phase leaves you with a half-configured platform, a service line that now depends on it, and a roadmap you have not priced, then the reversible bet was never reversible. It was a big bet with a smaller invoice at the front, and the exit closed at the same moment it would have anyway.

The test to apply before you sign: ask what happens if you stop after phase one. If the honest answer involves the word “well, you would want to”, the slice is not thin. Ask for the answer in writing, and ask what data you would take with you.

Where slicing is the wrong shape

Some changes genuinely cannot be sliced, and pretending otherwise is its own failure mode.

A merger where two firms must operate on one model by a fixed date. A re-platform driven by a product reaching end of support. A regulatory obligation with a deadline attached. In each case the value only exists at the whole-of-business level, the deadline is external, and a series of small proven slices does not add up to compliance on the required date. Those are real programmes and they need real programme governance.

Slicing also has a cost that rarely gets stated. Delivering in slices means designing the seams, and seams are work — you will build interim states that you later throw away, and you will spend time on sequencing decisions that a single big design never has to make. For a firm that already knows exactly what it wants, that overhead is not free.

The position, restated: the unit of change should be the smallest thing that produces real operating evidence, and the value of that unit is the option it preserves rather than the speed it demonstrates. Before committing to any programme, ask what you will know at the end of the first slice, and what you can still do about it.