Who Decides, and By When: Ending the Slow Drift of Deferred Choices

There is a sentence that costs UK projects more time than almost any other: we will come back to you on that. It is courteous, it is usually sincere, and it is frequently the beginning of three quiet weeks in which nothing moves and nobody is at fault.

The difficulty is not that clients defer decisions. They are entitled to, and often right to. The difficulty is that deferred decisions are rarely recorded anywhere the client can see them. They live in a meeting note, in someone's inbox, or in the memory of whoever was in the room. By the time the delay becomes commercially awkward, the conversation about it has become personal rather than procedural.

Deferral is normal; invisible deferral is not

A decision ledger is a one-page register of the choices currently outstanding on a piece of client work. It is shared, not internal. It is plain language, not risk language. And it does one thing well: it makes the cost of waiting visible while there is still time to avoid it.

Five columns are enough.

• Decision. The choice required, written as a question with a yes or no answer where possible.
• Owner. A named individual on the client side. Not a team, not a department, not the client in the abstract.
• Needed by. The date after which the decision begins to cost time, money or quality.
• Consequence of slip. One sentence describing what stops, what is resequenced, or what is incurred.
• Default path. What we will proceed with on that date if no instruction arrives.

That is the whole instrument. It fits on a page, it survives a change of personnel, and it removes the need for anyone to guess.

A worked example

Consider a website replacement for a mid-sized UK business. Three decisions sit open: which legacy content is migrated, whether the old domain redirects for twelve months or permanently, and who signs off the accessibility statement before launch.

Written into the ledger, the third item reads: decision — confirm sign-off owner for the accessibility statement; owner — the client's operations director; needed by — 14 March; consequence of slip — launch moves by one week because the statement must be reviewed after content freeze; default path — the firm's standard statement is published at launch and replaced within ten working days.

Nobody is being chased. The client can see the trade-off, choose to accept it, and move on. In practice, most decisions are made within a day of appearing in that form, because the cost of not making them has become legible.

The default path is the confidence test

Defaults are where this approach earns or loses its credibility. A default must be reasonable, proportionate, and agreed at the outset rather than announced after the fact. It should be reversible where possible. It should never be a device for committing a client to expenditure they have not approved.

A firm that can propose a sensible default has demonstrated that it understands the work well enough to proceed without instruction. That is a mark of professional confidence. A firm that cannot propose one is, in effect, saying that every unanswered question stops the project — which is rarely what the client wants to hear.

Fifteen minutes a week

The ledger only works if it is kept alive. A fixed slot each week — the same slot — to review open items, close what has been decided, add what has emerged, and circulate the page to the client contact. Two lines in the regular update note will do: three decisions open, one overdue, default path applies from Friday.

This is not additional governance layered onto existing governance. In most engagements it replaces part of it, because it absorbs the chasing that would otherwise happen by email and the ambiguity that would otherwise be resolved by assumption.

Why this is not bureaucracy

There is a reasonable suspicion of new registers, and it is worth addressing directly. A risk log is internal, defensive and written for the firm's protection. A decision ledger is shared, enabling, and written for the client's benefit. One records what might go wrong; the other records what is currently waiting.

The distinction is not merely semantic. Internal logs tend to accumulate items nobody reads and categories nobody understands. A client-facing ledger stays short precisely because it is visible, and visibility is a discipline of its own.

Where it goes wrong

Three failure modes are common. Too many items, so the page becomes a project plan in disguise. Unowned items, which quietly convert an agreed action into a shared hope. Defaults that surprise the client, which turns a helpful mechanism into a source of grievance.

A fourth is subtler: using the ledger as a record of fault. The moment a page like this is deployed to demonstrate that the delay was theirs, it stops working. The client stops contributing to it, and the firm is back to chasing by email with an audit trail nobody wanted.

A quieter kind of confidence

Projects rarely stall because of a single dramatic failure. They stall in small increments, in choices deferred politely and then forgotten. Recording those choices openly, with a date, an owner and a fallback, does not make a firm look bureaucratic. It makes the firm look organised, and it gives the client something they can act on rather than something they must remember.

That is a modest ambition, and it is usually enough.