Two builds, one difference

Two planning implementations, started four months apart, run by overlapping teams. Both were mid market groups, both were replacing spreadsheets with a proper platform, both had a sponsor in the finance leadership and a budget that was adequate rather than generous.

The first went live in nineteen weeks and closed its first cycle on the new model without a parallel run. The second is in its fourteenth month and has been in user acceptance testing since February. We have thought about this pair a lot, because on paper they should have gone the same way.

The things that were not the difference

It was not the platform. Same product, same version, same partner.

It was not seniority of sponsor. If anything the second had the stronger one, a group CFO who chaired the steering committee personally and pushed hard on dates.

It was not team quality. Two of the same consultants worked on both, and the second client’s internal team was, individually, better.

It was not requirements volume. The second had a slightly smaller scope by any measure we can construct after the fact.

The difference

The first client named one person who could decide, and let her decide.

She was a group finance manager, not a director. She had a standing forty five minute slot with us twice a week, and she had been told, in front of the people who might later disagree, that her call was the call. Over nineteen weeks she made perhaps two hundred decisions of the kind that stall a build: which driver, whose definition, how far back to load, what happens to the two entities that report late. Some of them were wrong. Wrong decisions made in week three cost a day to unwind. The same decisions deferred cost a fortnight each.

The second client routed those questions to the steering committee. The committee met monthly, had eleven members, and was chaired by someone who correctly saw his job as challenge rather than adjudication. A question raised in week two returned an answer in week seven, by which time the build had either gone around it or stopped. Most went around, which is how a fourteen month project acquires the workarounds that make user testing impossible to finish.

Why sponsors resist this

Delegating the decision looks like delegating the outcome, and a CFO who has signed for the money wants the outcome. It also looks risky, because the named person will get some calls wrong and will be visibly responsible for them.

The arithmetic goes the other way. On a build of this size, decision latency compounds faster than decision error. A wrong call caught in the following week is cheap, because nothing has been built on top of it yet. A right call that arrives five weeks late has already been designed around twice.

What we ask for now

We ask for the name before we quote. One person, backed in public, available twice a week, with the authority to be wrong. If a client cannot produce that name, we say what it will cost, because we now know roughly what it costs.

It is not a governance preference. It is the single strongest predictor we have of whether a build lands.