Assume It Has Already Slipped: A Short, Blame-Free Risk Review for Fixed Dates

There is a particular kind of quiet that settles over a team once a fixed date has been agreed. The date is in the plan, the plan has been circulated, and everyone has decided, privately, that it will probably be fine. It is a reasonable instinct. It is also the reason so many December deliveries arrive in a hurry, half-checked, and accompanied by an apology.

The difficulty is not that people are careless. It is that a date agreed in September is a statement of intent, not a forecast, and the gap between the two is filled by assumptions that nobody has written down. A short risk review at the start of a fixed-date delivery closes some of that gap. Not all of it — nothing closes all of it — but enough to matter.

Start from the ending, not the plan

The conventional approach is to walk through the plan and ask what might go wrong. This tends to produce a list of technical risks, because that is where attention naturally goes. It also tends to produce nothing at all, because asking a team to speculate about failure while the plan still looks tidy invites optimism.

The alternative is to begin by assuming the outcome has already happened. The date has passed. The deliverable did not go out, or went out and was not accepted. No one is at fault; the exercise is not an inquest but a rehearsal. From that position, ask a single question: what are the most plausible reasons we are sitting here?

Working backwards from a known failure is easier than forecasting one. People are noticeably more candid when the failure is hypothetical and the blame is explicitly off the table. The answers tend to be specific and slightly uncomfortable, which is exactly the material worth having.

The twenty minutes

The exercise does not need a facilitator, a workshop room, or a slide deck. It needs the people who will actually do the work, a whiteboard or a shared document, and a clock. Twenty minutes, structured as follows, is usually enough.

Minutes 1 to 5 — set the scene. State the date, the deliverable, and the fact that the review is about the plan rather than about any individual. Anyone who has been through a difficult delivery will recognise the difference immediately, and will say so.

Minutes 5 to 13 — list the causes. Ask each person to write down, without discussion, the three most likely reasons the date would be missed. Silent writing first, then a round-robin. Expect between eight and fifteen causes from a team of five or six. Do not debate them yet; debate at this stage rewards the loudest voice rather than the most experienced one.

Minutes 13 to 18 — convert to warning signs. Take each cause and ask what would be visible a fortnight before it became a problem. "The client's legal team is slow" becomes "we have not received their comments within ten working days of sending the draft". A cause you cannot observe is not yet a risk you can manage.

Minutes 18 to 20 — name a check-in. For each warning sign, record a person and a date. Not an owner in the abstract — a name, and a specific day on which they will confirm whether the sign has appeared. This is the step most often skipped, and the one that decides whether the exercise has any effect at all.

The failure modes worth expecting

Across most UK teams working to a client or regulatory date, the same handful of causes recur. They are worth naming in advance because they are so easily mistaken for background noise.

• The approval that belongs to someone else. Internal sign-off from finance, legal, or a director is routinely treated as a formality. It is not. It is a dependency with its own queue, and queues lengthen in December.
• The annual leave nobody checked. A delivery that runs through late November and into the Christmas period will collide with booked leave, school holidays, and the general thinning-out of the office between Christmas and the new year. Check the actual calendar, not the assumption that everyone is available.
• The single point of knowledge. One person holds the context, the client relationship, or the only working copy of the file. If that person is unwell in the final week, the date is at risk and nobody will say so until it is too late to act.
• The assumed acceptance. The deliverable is produced to the team's own standard, and the client's standard turns out to be different. This one surfaces late because it only becomes visible when the work is shown, which is often the point of no return.
• The quiet scope addition. A small extra request, accepted politely in a call, that adds two days of work nobody has recorded. Three of these and the plan is fiction.

Keep the output short enough to use

The temptation, once a list exists, is to turn it into a risk register with scores, likelihood ratings, and a colour-coded dashboard. Resist it. A register that takes an hour a week to maintain will be abandoned by the second week of December, and an abandoned register is worse than none because it creates the impression that risk is being managed.

A single page is sufficient: the warning sign, the person, the date of the check-in. Fifteen lines at most. Circulate it to the delivery group, not to the whole organisation, and review it at the check-in dates rather than in a standing meeting. The point is not documentation. The point is that someone has agreed, in advance and in writing, to look.

What it changes

The value of the exercise is not prediction. Most of what a team lists will not happen, and some of what does happen will not have been listed. The value is that the conversation happens while there is still room to act, rather than in the final week when the only remaining options are escalation and apology.

It also changes the tone of the final weeks. When a warning sign appears, it is not a crisis or a surprise; it is the thing that was written down in September, and the person who wrote it down is expected to mention it. That is a considerably calmer way to run a fixed date, and it costs twenty minutes at the start.