Why The Last Ten Percent Of A Project Eats A Third Of The Time

The last ten percent of a project eats a third of the time because finishing is a different job from building, and almost nobody plans for it. The building phase is your team, working on things they control. The finishing phase is sign-offs, edge cases, handover and training, and most of it depends on people outside the team who have other priorities. You estimated the first job and got handed the second.

The fix is not to work faster at the end. It is to treat finishing as its own phase, with its own owner, its own list and its own time in the plan.

What is actually left at ninety percent

When a team says a project is ninety percent done, they usually mean the main path works. Here is what is still sitting there:

• Approvals from people who have not looked at it yet
• The odd cases: bad data, the user who does the steps backwards, the customer with a name field twice as long as anyone expected
• Handover to whoever will run it day to day
• Training, and the questions training produces
• Documentation somebody will actually read
• The small fixes that come out of a real person using it for the first time
• Whatever the security or legal review asks for

Not one of those items is building. They are a different kind of work, and they run on other people's calendars.

Waiting is the biggest line

The reason finishing runs long is rarely effort. It is waiting. A review that takes forty minutes of someone's attention can sit for a week because that someone is busy. Then their feedback arrives, you make the change, and it goes back into the queue for another week. Two rounds of that is a fortnight of calendar time for under two hours of actual work.

Building work does not behave this way. Building is your team, in a room, moving. Finishing is a series of handoffs, and every handoff has a queue in front of it.

That is why the arithmetic feels wrong. You are estimating the work and getting billed for the waiting.

Edge cases arrive late by design

Edge cases show up at the end because that is the first time anyone touches the thing with real material. Test data is polite. Real data has blanks, duplicates, wrong formats and one record from 2011 that nobody can explain.

Each of these is small. There are just more of them than anyone guessed, and each one takes a decision as well as a fix. Decisions need people. People need meetings. That is the third of the time.

Plan finishing as a phase

Give it a start date, an end date and a name that is not "wrapping up". Put it in the plan as a block of real length, sized from what finishing took on your last project rather than from optimism. That number only exists if you have been tracking your estimates against what actually happened.

Give it one owner. Not the person who built the most. Someone whose job for those weeks is chasing approvals, running the handover and keeping the fix list moving. A person who is good at asking the same question a third time without annoying anyone is worth more here than the strongest builder on the team.

Then write the list before you get there. Halfway through building, sit down for an hour and list every sign-off, every handover, every training session and every group whose approval you need. Doing that early is the difference between a phase you planned and a month of surprises.

Book the reviewers in advance

Approvals sit in queues because nobody warned the approver. So warn them. Ask for a slot in their calendar three weeks before you need it, tell them roughly how long the review will take, and tell them what they are approving.

A reviewer with a booked hour is a fast reviewer. A reviewer who gets an unexpected email with a link in it is a slow one.

This is the single cheapest change most teams can make to their end-of-project timeline, and it costs one message per approver.

Say ninety percent less often

The word "ninety" tells the person listening that there is a week left. Say what remains instead: the three approvals, the handover, the training, the fix list. A stakeholder who hears a list understands the shape of what is coming. A stakeholder who hears a percentage starts counting days, and gets the wrong answer. The same care applies to dates, where naming a target, a promise or a hope decides how the number is heard.

For your next project, take the finishing phase from the last one, count its calendar days, and put that number in the plan before anyone asks you for a date. Then defend it, because that is the part of the estimate you can actually back up with evidence. If it moves anyway, tell the client early and bring options.