Decide by When: A Calm Register for the Choices That Hold Up Delivery

Most delivery plans are organised around a single prominent date: the go-live, the submission, the board paper, the December close. That date receives attention in status reports, steering meetings and calendar invitations. Yet the date that determines whether the final date is achievable is often absent: the date by which a named person must decide.

A decision deadline is not a reminder. It is the point at which an approval, sign-off, resource choice, scope change or supplier selection must be made so that downstream work can proceed. When it is left vague, teams continue on assumptions. By the time the assumption is tested, there is little room to recover. The result is not usually a dramatic failure; it is a quiet compression of the final fortnight.

The final date is not the controlling date

A final date tells you when work must finish. A decision date tells you when the work can start reliably. In UK organisations, decision latency is often longer than delivery latency. An approver may be in a fortnightly governance cycle. A finance sign-off may require a paper to be circulated five working days beforehand. A supplier may need written confirmation before it can reserve capacity. None of these constraints are unusual, but they are frequently left outside the plan.

This matters more in the run-up to the 2026 year-end. Annual leave, bank holidays and reduced availability compress the working calendar. A date that looked comfortable in October can become impossible in December. Naming the decision date does not remove the constraint. It makes the constraint visible early enough to manage.

Work backwards from delivery, then stop at the decision

Back-scheduling usually begins with tasks. It should also include choices. Suppose a team must deliver a report on 15 December 2026. Two working days are needed for final quality checks, three for production, and five for approval. The approval must therefore begin by 3 December, assuming no bank holidays intervene. If the approver is on leave from 4 December, the decision date is earlier still. This is simple arithmetic, but it is rarely recorded.

The same logic applies to resource choices. If a project needs a contractor to start on 1 December, the decision to appoint must be made before the recruitment or procurement lead time begins. If a team needs a subject-matter expert for a two-week review, the decision to release that person must be taken before the review window opens. Each choice has a latest sensible date. The register exists to name it.

Define what counts as a decision

A decision is not a review, a discussion or a general update. It is a specific question with options, an owner, evidence and a consequence. 'Sign-off' is too vague. 'Approve the December campaign budget of the stated amount, or select option B' is a decision. 'Confirm whether the supplier contract will be extended to 31 January 2027' is a decision. 'Review the plan' is not.

A useful test is whether the decision can be recorded in one sentence. If it cannot, it is probably too broad to schedule. Break it down until a named person can say yes, no, or choose between defined options. This makes the decision date meaningful rather than ceremonial.

Build a one-page decision register

The register should be short enough to review in a meeting and clear enough to act on. One page is usually sufficient. It should sit alongside the project plan, not replace it. A practical set of columns is:

• Decision needed: one sentence, with options where possible.
• Why it matters: the downstream task or commitment it unlocks.
• Owner: one named person accountable for obtaining the decision.
• Decider: the person or body with authority to decide.
• Evidence required: what the decider needs to see.
• Decide by: the latest date, not a target date.
• Consequence if missed: delay, cost, reduced scope or escalation.
• Status: on track, at risk or escalated.

Keep the number of live decisions manageable. If the register runs to several pages, it is probably capturing tasks rather than choices. A short register that is reviewed weekly is more useful than a comprehensive one that is opened once a month.

One owner, one date, one consequence

Every decision should have one owner. A committee may be the decider, but a committee cannot chase itself. The owner is the person responsible for preparing the evidence, confirming the date and escalating if the decision is not being made. They are not necessarily the most senior person in the room, but they must have the authority and time to drive the item forward.

The consequence column is equally important. It should state plainly what happens if the date is missed: 'If not decided by 24 November, the print deadline is missed and launch moves to January.' This is not a threat. It is information that allows the decider to weigh the cost of delay against the cost of deciding prematurely. Without it, urgency is felt but not understood.

Confirm the date with the person who must decide

Do not infer availability from a calendar. Ask the decider or their office what they need and by when they can realistically decide. Put a short decision meeting in the diary, with the evidence attached in advance. If the decider is unavailable, agree a deputy now rather than in the final week. If the decision requires a formal board or committee, work back from its scheduled meeting dates and paper deadlines.

This conversation also tests whether the decision date is credible. A date that the decider has not seen is a hope, not a commitment. A date that has been discussed and confirmed is a control point.

A short weekly routine

A ten-minute weekly review is enough for most teams. Check every decision due in the next ten working days. Confirm that the evidence is ready. Confirm that the decider is available. Mark items at risk and escalate those that cannot be recovered. In December 2026, consider reviewing twice weekly, because the working days are fewer and the cost of a missed handover is higher.

The routine should be calm and factual. The question is not 'why has this not been done?' but 'what is the latest date this can be decided without affecting the delivery date?' That framing keeps attention on the choice rather than on blame.

What this changes

A decision-deadline register does not make decisions for people. It makes the cost of delay visible while there is still time to choose. It moves ambiguity earlier, where it can be resolved, rather than later, where it becomes a shortfall. For UK teams facing a fixed year-end date, that is a practical form of protection. The final date remains important, but it is no longer the only date that matters. The date before the date deserves a name, an owner and a place on the page.