Most project deadline failures follow the same pattern. The deadline is set. The work starts. There's a confident early phase. Then comes a growing awareness that the various components of the project require more time than initially assumed. Then there's a crunch. Then there's either a missed deadline, a compromised output, or a tense conversation with a stakeholder. The failure isn't usually caused by laziness or incompetence — it's caused by forwards planning, which means people work forward from the start date without fully calculating whether the available time is actually sufficient for all the stages required.
Backwards planning — starting from the deadline and working backwards to determine when each stage must start — consistently produces more realistic timelines because it forces every stage to be accounted for before the project begins, not discovered during it.
The Backwards Planning Method
Start with the final deadline. Work backwards, stage by stage, subtracting the time required for each phase. The date when the first stage must start is the project start date. If that date has already passed, either the timeline needs compressing (more resources, reduced scope), or the deadline needs negotiating.
Example: a marketing campaign launching on 1 June. Working backwards:
- Launch date: 1 June
- Final approvals and upload: 28 May (3 working days before launch)
- Design amendments from feedback: 21 May (requires 5 working days)
- Stakeholder review period: 14 May (1 week review window)
- Design production: 5 May (requires 7 working days)
- Creative brief approved: 1 May
- Brief writing and internal approval: 24 April (requires 5 working days)
Project must start: 24 April. If you're beginning this exercise on 28 April, the timeline as designed doesn't work. Something has to give.
Use our date calculator to find the exact working days between any two dates, accounting for weekends and public holidays. This is critical for accurate backwards planning — calendar days and working days diverge significantly across periods containing bank holidays.
Working Days vs Calendar Days
This distinction causes more deadline failures than almost any other planning error. A two-week period sounds like 14 days. Over a fortnight containing a bank holiday Monday and a weekend either side, available working days might be 9 rather than 10. In a period spanning Christmas and New Year, a "two-week" window might contain only 5 or 6 actual working days.
Always calculate deadlines in working days. Use the days between dates calculator to get the accurate working day count between any two dates, then subtract any known leave or holiday periods for the people doing the work. The number you land on is the real available resource.
Buffer Time: Planning for Reality
Realistic project plans include buffer time between stages. Buffers absorb the inevitable small slippages — a stakeholder slightly delayed in reviewing, a technical issue taking an afternoon to resolve, a meeting running long. Without buffer time, a single small delay cascades through all subsequent stages and produces a missed deadline from a problem that would otherwise have been completely manageable.
Rule of thumb for buffer allocation: add 20% buffer to any stage with external dependencies (waiting for approvals, deliveries, third-party actions), and 10% to internally controlled stages. For a project with six stages totalling 30 working days: build in 5–7 additional buffer days. Deliverable the day before the deadline rather than the day of.
For managing time within working days and across tasks of known duration, our time duration calculator helps plan daily task schedules — useful when multiple deliverables need to fit within a working week.
Milestones: Making Progress Visible
A single deadline at the end of a multi-week project provides no early warning of problems. Milestone deadlines throughout the project create regular checkpoints at which progress can be verified, delays identified, and corrective action taken while there's still time to take it.
Milestones should be at genuinely significant project points — when a major deliverable is completed, when a decision must be made, or when a dependency for the next phase is required. They should not be artificially frequent status updates that create reporting overhead without improving decision-making. Three to five milestones in a six-week project is typically about right.
Communicating Deadline Risk
One of the most valuable outcomes of rigorous backwards planning is early identification of unrealistic deadlines. If the backwards plan demonstrates that a requested deadline requires all stages to have zero contingency and assumes everything goes perfectly, that's a risk worth communicating to the stakeholder before the project starts — not after the deadline is missed.
Presenting a backwards timeline to a client or manager when accepting a brief (rather than just a start date and an end date) demonstrates planning maturity and makes resource requirements visible before they become crises. "Based on the scope, here's what has to happen in what order and when it needs to start" is a considerably more compelling brief response than "we'll get it done by the deadline."
When the Backwards Plan Doesn't Fit
When the backwards plan reveals that the deadline isn't achievable with the available time and resources, there are only three responses: reduce scope, add resources, or negotiate the deadline. There is no fourth option. Understanding this clearly — and communicating it early — is one of the most valuable contributions a project manager or senior individual contributor can make.
The Project Management Institute's resources on schedule network analysis cover backwards planning (the "backward pass" in critical path methodology) for more complex multi-stream projects where dependencies between parallel workstreams need to be modelled.