June 2024. A panicked e-commerce client calls at 10 PM: his site was supposed to launch before Black Friday, the redesign is still in revision round four, and the front-end developer is on holiday until December 2nd. The original project schedule? Two Excel columns put together in one hour during the kick-off. Basically nothing.
Every agency project manager has been there at least once. And yet we keep treating backplanning as an administrative formality rather than the backbone of any project. Big mistake.
Why Most Project Schedules Are Useless
Most agency project plans share the same flaw: they're built left to right, from project start to deadline, stacking tasks optimistically. That's exactly backwards. A real backplan starts from the delivery date and works backwards. You set the non-negotiable client deadline, then subtract testing time, correction rounds, and sign-offs. Then production phases. Then briefs and workshops. What's left is your real start date. Honestly, that date is often already past when you do the exercise properly.
"We started building our project schedules backwards 18 months ago. The on-time delivery rate went from 41% to 78%. Just by reversing the direction of the plan." - Production Manager, 12-person digital agency, Lyon
The 4 Classic Mistakes
First mistake: ignoring client validation delays. Back-and-forth approvals account for 30 to 40% of total project duration on average. We forget them every time. The project is technically ready but stuck for two weeks waiting for the Marketing Director who's travelling abroad.
Second mistake: theoretical FTE allocation. You write "front-end development: 5 days", but that developer is 60% on another project and has a training session on Thursday. 5 days becomes 12 calendar days. Working in calendar days rather than man-days avoids this trap.
Third mistake: zero buffer. Adding 15 to 20% margin on each major phase isn't cheating, it's being honest. An 8-week project with no buffer consistently lands at 10 weeks. With a planned 9-week buffer, you hit 8.5. Fourth mistake, and the one that genuinely frustrates me: the backplan is never updated after kick-off. A plan that isn't refreshed weekly is a dead document.
5-Step Method to Build a Solid Backplan
Step 1: lock the anchor date. The contractual go-live date, non-negotiable. Everything flows from this. Step 2: break down into macro milestones, not granular tasks yet. Framing, design, production, testing, delivery. Each milestone gets its own deadline calculated backwards from go-live.
Step 3: map dependencies. SEO can't start before the site architecture is approved. Brand guidelines must be signed off before front-end development begins. Mapping these in your tool of choice, whether Notion, Asana, or Clynt, prevents late-stage disasters. Step 4: assign resources in real calendar days, accounting for holidays, training days, and parallel projects. Step 5: share and formalise. A client who has approved the schedule upfront can't claim the deadline was "unrealistic" three weeks before delivery.
Backplanning and Agile: Contradiction or Complement?
There's a persistent myth that backplanning is old-school and incompatible with Scrum or Kanban. That's a confusion. Backplanning fixes contractual macro milestones. Agile sprints organise production within those milestones. They coexist perfectly. At a retail client in 2023, the tech team ran two-week sprints, but the macro backplan with beta and go-live milestones was permanently visible in Slack. Zero surprises for the client, and the team always knew which story points needed to land in which sprint.
What to Do When the Schedule Slips
It always happens. The question isn't to prevent every slip, it's to catch it early. Two simple indicators: actual velocity vs planned velocity mid-sprint, and percentage of intermediate milestones hit on time. The moment you identify a 3-day delay on any intermediate milestone, you have three options: reduce scope to MVP, add resources if the budget allows, or renegotiate the deadline with the client using facts. The worst option? Hoping to catch up in a last-minute sprint. It never works.
FAQ
What is the difference between a backplan and a classic Gantt chart?
A classic Gantt chart is built left to right, from start to finish. A backplan starts from the delivery date and works backwards through time. This reversal forces you to confront real deadlines from the outset, eliminating the wishful thinking that plagues traditional planning.
How do you handle unpredictable client approval delays in a backplan?
Build contractual validation windows into your backplan. For example, stipulate that the client has 5 business days to approve each deliverable. If approval runs over, the final delivery date shifts by the same number of days automatically. Make this explicit in the contract or at minimum in the purchase order.
How many intermediate milestones should a website redesign project have?
For a standard 2 to 4-month redesign, plan 5 to 7 milestones: kick-off, architecture and wireframe sign-off, brand guidelines approval, internal testing, client acceptance, final corrections, go-live. Fewer than 5 milestones and the tracking becomes too coarse to catch delays in time.
Should the full backplan be shared with the client?
Not necessarily. Share the macro milestone version with the client to align expectations and set validation dates. The detailed operational version with internal resource allocation typically stays in-house. The client doesn't need to know that Jean-Baptiste is 60% on their project and 40% on another.