Ask a team when a project will finish and you usually get a date. Ask them how they arrived at it and the honest answer is often that someone worked forwards: this task takes a week, then that one, add a bit of contingency, land on a Friday. It feels rigorous. It is also the reason so many projects are late from the very first day without anyone realising.
Working forwards has a built-in optimism problem. Each step is estimated in isolation, as if the people doing it had nothing else on, the supplier replied the same afternoon, and nobody went on holiday. The plan is a description of the best case, and the best case almost never happens.
Start at the end
The alternative is to fix the date first and walk back from it. If the conference is on the 14th, the venue needs the final numbers by the 7th, which means registration has to close on the 5th, which means the invitation has to go out by the 15th of the previous month, which means the programme has to be locked a week before that. Suddenly the real deadline for the programme is six weeks earlier than anyone had assumed, and it is already in three days’ time.
That discomfort is the point. Backwards planning surfaces the constraint that is actually going to hurt, and it surfaces it while there is still time to do something about it.
What it looks like in practice
We do this at the start of every engagement, usually on one page. The immovable date goes at the right-hand edge. Then we ask, for each stage, what has to be true before it can start, and how long the person doing it will honestly need given everything else on their plate. We write down the dependencies on other people, because those are where the time disappears: legal review, a sign-off from a director who travels, a supplier’s lead time.
A few things reliably fall out of this exercise. Somebody’s approval turns out to sit on the critical path and nobody has told them. A task that everyone thought was small needs a decision that has not been made. The last two weeks before the date are full of things that could have happened in the first two.
The date at risk is information, not failure
When the backwards plan does not fit, and it often does not, you have learnt something useful early. You can move scope, move people, or move the date while moving it is still cheap. What you have avoided is the version where the same news arrives three weeks before launch, delivered as a surprise.
Telling a client early that a date is at risk feels uncomfortable. Telling them late is worse for everyone, and it is the version that damages trust. A plan that was built backwards gives you the evidence to have the early conversation calmly, with options attached.
None of this needs software. It needs one honest hour, one sheet of paper, and a willingness to put the date at the end and see what the rest of the page tells you.