Backward planning: schedule a project in reverse

The seminar is on December 4. The date is in everyone's calendar, the venue won't move, and the invitations have gone out. What's still unclear is everything else: when to book the caterer, when to finalize the program, when to print.

Backward planning answers that question by tackling the problem from the end.

What is backward planning?

Backward planning means building a schedule in reverse. You set the delivery date first, then work back in time to place each step, until you reach today. It's also called reverse planning or reverse scheduling, and in French, rétroplanning.

It contains the same elements as a regular schedule (dates, milestones, tasks). Only the order in which it's built changes, as Asana's guide to retroplanning points out.

The difference shows when you track progress. A schedule built forward from the start says "this is when we'll be done, if all goes well". A backward plan says "this is what has to be done by which date to hit the deadline". The first one discovers the delay at the end; the second one shows it from week two.

Building a backward plan in 5 steps

1. Set the deadline, and nothing else

The starting point is the date that doesn't move: the event, the filing deadline, the launch date announced to the client. If it can slip, backward planning isn't much use.

2. Place the milestones, working backward

A milestone is a checkpoint you can verify: "venue booked", "program approved", "materials printed". It has no duration; it's either reached or it isn't.

Start from the deadline and ask yourself: what has to be wrapped up just before? And just before that? Four to six milestones are enough for a project lasting a few weeks.

3. List the tasks between two milestones

Between two milestones, write down what needs doing to get from one to the next: request three quotes, follow up with the speakers, send out the registration form.

4. Estimate durations, and don't trust yourself

Almost everyone gets this wrong, and in the same direction. In 1994, psychologists Roger Buehler, Dale Griffin and Michael Ross asked students to estimate how long it would take them to finish their thesis. They predicted 34 days on average; it took them nearly 56, and only about 30% finished within the time they had announced. The study, published in the Journal of Personality and Social Psychology, illustrates what Daniel Kahneman and Amos Tversky named the planning fallacy: we underestimate our own tasks, even when the previous ones have already run over.

To estimate, look at how long a similar task actually took you last time, not how long it should take.

Also spot the dependencies: you can't print a program that hasn't been approved. The longest chain of dependent tasks sets the project's minimum duration; that's the critical path. A delay on that chain pushes back everything else.

5. Reserve the buffer before the deadline

Reserve the buffer as one block, just before the deadline, rather than adding a day here and there. An empty week at the end absorbs a late supplier or an approval that drags on.

If, once realistic durations are in place, the backward plan starts yesterday, the scope is too broad. Better to cut now than on the evening of December 3.

Backward planning example: a seminar on December 4

Back to the seminar. Deadline: Friday, December 4. Let's work backward.

Read from bottom to top, it's a work plan. Read from top to bottom, it's a set of questions: to print on the 27th, you need a program on the 20th; to lock in the program, you need to know how many people are coming, so registration has to close on the 13th.

The critical path stands out: registration, program, printing. If registration runs a week over, the buffer is used up.

📍The milestone test

A milestone is checked with a yes or a no

“Make progress on the program” is not a milestone. “Program approved by management” is one.

Common backward planning mistakes

• Starting from a wished-for date. Pinned to a date nobody actually set, the backward plan loses its constraint, and with it its reason to exist.
• Forgetting other people's lead times: a quote to obtain, a sign-off from management, a printer who needs five business days. That time doesn't depend on you, and it's often what runs short.
• Scheduling the last task for the day before. Without a buffer, the slightest delay lands on the deadline.
• Doing it once and never opening it again. It should be reviewed every week: which milestone was due, was it reached? If not, adjust right away.
• Planning everything day by day. Beyond a few weeks, only detail the period coming up.

For exams, the same logic is covered in detail in the revision schedule.

Keeping your backward plan in Flots

A backward plan on paper doesn't warn you about anything. In a tool, you see where you stand every week without redrawing the table.

In Flots, the project serves as the backward plan:

• The seminar becomes a project, with its tasks and notes in one place.
• The project's milestones serve as checkpoints: you see at a glance what's left to cover.
• Dated tasks appear in the Planning view. In week view, you move them from one day to another when a milestone shifts.
• A reminder on "follow up with the printer" saves you from discovering the delay on printing day.

If you're running several deadlines at once, each with its own backward plan, the challenge changes in nature: see managing several projects in parallel.

Start with the deadline and the last milestone before it: the rest of the backward plan builds itself as you work back, one question at a time.