The team in this story is imagined, but the pressure it faces will be familiar to anyone who has shipped a website for a client. Four people, one content management system, one launch date printed on a contract. The plan looked fine. What follows is an account of how the team lost a week to nothing in particular, then rebuilt its launch schedule around website launch buffers, and what the numbers on the board told them afterwards.
The original plan: five steps and no air
The project was a rebuild of a mid-sized service business site. The schedule had five blocks: content audit, design sign-off, template build, content migration and launch. Each block started the morning after the previous one ended. On paper the whole thing took six weeks.
The project lead, a careful person who liked spreadsheets, had padded nothing. Her reasoning was sensible: padding is dishonest, and clients dislike seeing days they are paying for with no visible work. So each estimate was her honest best guess, and the blocks sat shoulder to shoulder.
What actually happened
Design sign-off was supposed to take two days of client review. It took five, because the client’s marketing head was travelling and the approval needed a second person. That cost three days, but the template build could not start without the signed designs, so the developers sat waiting. When they finally began, they were already behind, so they rushed the page templates. The rushed templates produced layout bugs, and the bugs surfaced during content migration, which was the block that depended most on editors being available.
Analysing the delay later, the lead noticed something uncomfortable. No individual block was badly estimated. The developers built templates in roughly the time they had predicted. The editors migrated content at the expected pace. The week was lost in the joins: the approval that needed one more person, the handoff of files, the review that waited for an inbox.
The reconstruction: finding where time was really lost
The team laid out the project log and tagged each hour lost by cause. The categories were simple: waiting on an external person, waiting on another internal step, rework caused by an earlier rush, and genuine underestimation. The result was lopsided. Most lost hours fell into the first two categories. Genuine underestimation was a small slice.
That finding shaped everything that followed. If estimation was not the main problem, then better estimation would not fix the schedule. What the team needed was not more accurate tasks but protected space around them.
Rebuilding the launch schedule around website launch buffers
On the next project the team used the same five blocks, but changed three things.
- Gaps at the dependent joins. After design sign-off, they added a visible two-day gap labelled “client approval slack”. After template build, a shorter gap for a bug sweep.
- A closing reserve. Four working days before launch, held back and labelled so that nobody mistook it for spare capacity.
- Separate lines on the plan. Buffers appeared as their own rows, shown to the client, with a one-line explanation of what each protected.
To their surprise, the client liked it. Seeing a labelled slack row made the contract date feel more believable, not less, because it showed the team had thought about what could go wrong.
Where the structure of the site made the gaps matter
The team also learned that some content decisions needed more room than others. A site’s core pages take longer than people expect, because every one needs sign-off from someone senior. A useful read on this is a look at which pages a business site should have and how they fit together, which makes clear how many separate approvals a standard page set requires. Service pages in particular tend to be revised repeatedly, a point made well in an article on what makes a service page turn browsing into enquiries. The team gave those pages their own slack row, since late copy changes were the most common source of drift.
The numbers after the second project
The second project ran with the same headcount and a similar scope. Looking at the log, the team found the following.
- Two of the four buffers were drawn on, one heavily.
- The closing reserve was untouched until the final week, and about half was used.
- No block started late because of an earlier block, a first for the team.
- Total elapsed time was longer on paper by roughly a week, but the launch date held.
The lead’s comment in the retrospective was dry: the project did not get faster, it got predictable, and predictability was what the client had been paying for all along.
A parallel from the world of long trips
One of the editors on the team had been helping a relative plan a trip abroad for medical care, and the pattern was the same. She had been reading the pages of a facilitator for care abroad whose directory is organised country by country and which lets visitors send in an appointment request from the page, and she realised that the real risk to that trip was never a single big item but the gaps between flights, documents and lodging. She built the same kind of slack into the itinerary. Anything clinical remained a matter for qualified professionals, but the logistics got room to flex.
Lessons worth carrying forward
- Measure where hours are lost before deciding how to fix the schedule. In this team’s case the cause was handoffs, not estimates.
- Give buffers names and show them to stakeholders. Visible slack builds trust.
- Keep one reserve at the end that nobody may spend early.
- Review buffer use after each project and resize it from evidence rather than instinct.
The caveats
None of this is free. A schedule with buffers looks longer, and some clients will push back. The team’s answer was to show the log from the first project. Another caveat is that buffers can breed laziness if people treat them as spare time. The team handled that by tracking use openly, and by agreeing that anyone consuming slack explains why in a single sentence on the board.
It would be tidy to say that slack solves everything. It does not. Scope creep, unclear briefs and absent clients can all swamp a buffer. But on this team’s evidence, the commonest cause of lateness was not any of those. It was empty space missing from the plan, and adding it was the cheapest improvement they made all year.
