When a transformation programme slips, the explanation usually points at delivery: a vendor, an integration, a defect count. In our experience the real delay happened earlier and quieter — in the decisions about process, data ownership and risk that were assumed to be settled but never actually were.
The decision debt that accumulates silently
Every programme starts with a plan that assumes certain things are already true: that the business agrees how order-to-cash should run, that someone owns the customer master, that the risk appetite for cloud hosting has been stated. When those assumptions are wrong, nobody notices immediately. The programme proceeds on the assumed answer, and the correction arrives months later as rework.
This is decision debt. It behaves like technical debt but is harder to see, because nothing breaks visibly — meetings just get longer, design documents get vaguer, and the same questions keep returning to the steering committee.
Why the hard decisions get deferred
The decisions that stall programmes share a pattern: they cross organisational boundaries, they create a visible loser, and they cannot be reversed cheaply once built. Agreeing a single chart of accounts, naming one owner for vendor master data, or accepting a standard process over a local one all redistribute power. Deferring them feels like keeping options open; it is actually choosing to pay more later.
Delivery pressure makes this worse. Once build has started, every reopened decision threatens the date, so teams learn to work around ambiguity instead of resolving it — and the workaround becomes the design.
What deciding early actually looks like
The programmes that avoid this do three things differently. First, they list the decisions the business case depends on before mobilisation — not the plan, the decisions — and assign each one an owner and a date. Second, they make divergence from standard an explicit, written choice rather than a negotiation held during configuration. Third, they treat data ownership as an operating-business decision, not an IT task.
None of this requires more governance. It requires naming, early, the small set of decisions that everything else hangs from — and refusing to let them stay open by default.