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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
On the next project the team used the same five blocks, but changed three things.<\/p>\n
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.<\/p>\n
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<\/a>, 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<\/a>. The team gave those pages their own slack row, since late copy changes were the most common source of drift.<\/p>\n The second project ran with the same headcount and a similar scope. Looking at the log, the team found the following.<\/p>\n 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.<\/p>\nThe numbers after the second project<\/h2>\n
\n
A parallel from the world of long trips<\/h2>\n