What is a punch list?

A punch list is a closeout document, borrowed from construction, that lists every remaining defect or unfinished task a project needs resolved before it counts as truly complete. In building work it's compiled at substantial completion—when the project looks finished—and final payment is only released once every item is confirmed done. Applied to knowledge work, a project punch list turns the vague feeling of "almost done" into a specific, owned, finite list you can actually drive to zero.

Why does the last 10% of a project take so long?

Because the last 10% is a different kind of work than the first 90%. The early phase is the interesting, buildable part that's easy to estimate; the tail is edge cases, polish, documentation, and cleanup that nobody enjoys or scopes up front. The ninety-ninety rule captures it as a joke—the remaining 10 percent takes "the other 90 percent" of the time. The real culprit is that "almost done" has no checklist, so it never reaches zero.

What's the difference between a punch list and a definition of done?

A definition of done is a standing policy: it describes, in general, the quality bar any deliverable must meet. A punch list is operational and specific: it's the actual list of what's still wrong with *this* deliverable, right now, found by walking through it. You need both—the definition of done sets the standard, and the punch list proves a particular piece of work has actually reached it.

How do you run a punch list on a remote team?

Recreate the construction walkthrough as one live, shared session instead of scattered async messages. Get the team into a video call, open the actual deliverable, and go through it end to end together. Capture every defect on a shared surface—a canvas or doc everyone can see—and assign each item to one person on the spot. Then freeze scope to those items only and tie sign-off to the list hitting zero.

What is the 90-90 rule?

The ninety-ninety rule is a tongue-in-cheek aphorism in software engineering, attributed to Tom Cargill of Bell Labs and popularized by Jon Bentley in a 1985 "Programming Pearls" column. It states that the first 90 percent of the work takes 90 percent of the time, and the remaining 10 percent takes the *other* 90 percent. It deliberately sums to 180% to make a serious point: teams routinely underestimate the difficult, unpredictable tail of a project.

The Punch List: How to Finish the Last 10%

There's a famous rule in software engineering that's secretly a joke. It says: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." It's called the ninety-ninety rule, attributed to Tom Cargill at Bell Labs, and it adds up to 180% on purpose. The math is broken because the experience is broken: the part you swear is almost done is exactly where the time disappears.

You've lived this. A project hits "basically finished." The demo works, everyone mentally moves on, and then it sits at 90% for three weeks while a long tail of small, unglamorous tasks refuses to die. This is the most expensive stretch of any project, and almost nobody plans for it.

The fix isn't grinding harder on the last 10% of a project. It's borrowing a hundred-year-old tool from construction: the punch list. This guide covers what the punch list is, why "we're almost done" quietly lies to you, and exactly how to run one—including on a remote team.

Why the last 10% of a project takes 90% of the time

The first 90% of a project is the fun part. You're building the thing that didn't exist, solving the interesting problem, watching it come to life. That's also the part that's easy to estimate, because it's the work you pictured when you started.

The last 10% is a completely different kind of work. It isn't the crux of a project—the single hard problem you have to crack. It's the boring tail: edge cases, error states, copy fixes, documentation, the empty-state screen, the handoff, the thing that breaks only on Safari. None of it is glamorous, none of it demos well, and almost none of it gets estimated up front.

Developers describe this with painful honesty. On his blog Coding Horror, Jeff Atwood wrote a whole post called "On Our Project, We're Always 90% Done." One engineer in it admits, "I can hand off my code today and call it 'feature complete,' but I've probably got three weeks of cleanup work to do once I hand it off." Feature complete is not done. It just feels done.

That gap is expensive at scale. McKinsey, in partnership with the University of Oxford, studied more than 5,400 large IT projects and found they run on average 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. Projects don't usually blow up in the fun first 90%. They bleed out in the tail.

Here's the deeper reason the tail won't converge: "almost done" is a feeling, not a measurement. A feeling has no items in it, so there is nothing to cross off, and nothing to cross off means nothing ever reaches zero. Your brain knows this, which is why unfinished work nags at you. Psychologists call it the Zeigarnik effect: open loops occupy your attention until they close. The punch list is how you give the loop something to close around.

What a punch list actually is (and why "definition of done" isn't enough)

A punch list comes from construction. When a building is at "substantial completion"—the lights are on, the walls are up, it looks finished—the owner, the architect, and the general contractor walk the entire project together and write down every single defect. Per the standard definition, it's "a document prepared during key milestones or near the end of a construction project listing works that do not conform to contract drawings and specifications." In the UK and Australia the same thing is called a snag list.

The genius is in what comes next. Final payment to the contractor is only released when every item on the punch list has been confirmed complete. The list, not anyone's gut feeling, is the official definition of finished. You can't say "looks good to me" your way to a signed check.

Knowledge work has a polite cousin of this idea: the definition of done. The Scrum Guide calls it "a formal description of the state of the Increment when it meets the quality measures required for the product." That's good—keep it. But a definition of done is a standing *policy*. It tells you the bar in the abstract. It does not walk your actual deliverable, room by room, and catch the cracked tile in the corner. The project punch list is the operational version: a fresh, specific list of what's wrong with *this* thing, right now, before it ships.

A policy says what "done" means. A punch list proves you got there.

The punch list method: how to finish a project in 5 steps

Here's how to run the punch list on any project, from a feature release to a client deliverable to a website launch.

Step 1 — Declare "substantial completion," not "done"

Stop using the word "done" too early. Replace it with a checkpoint borrowed from the trades: *substantial completion*. It means the core work exists and basically functions—and explicitly does not mean shippable. Naming this stage honestly is what unlocks the rest of the method, because it tells everyone the unglamorous part is starting, not ending.

Step 2 — Walk the whole thing, together

Do the walkthrough. Open the actual product, the actual document, the actual deploy, and go through it end to end as if you were the customer using it for the first time. In construction, the owner and architect walk the building precisely because the people who built it have stopped seeing it. Do it as a group, out loud, with fresh eyes. This single hour surfaces more remaining work than a week of "I think we're good."

Step 3 — Write every defect as a discrete, owned item

Every issue you find becomes one line: specific, small, and assigned to one name. Not "polish the dashboard" but "fix overlapping labels on the dashboard chart — Sam." Vague items never close; that's exactly how action items fall through the cracks. There's a bonus here: psychologists Baumeister and Masicampo found that simply making a concrete plan for an unfinished task quiets the intrusive, nagging thoughts about it—even before you finish. Writing the punch list literally buys back focus.

Step 4 — Freeze scope to punch-list items only

This is the rule that protects the whole method: once the punch list exists, nothing gets added except defects against the original spec. No new features, no "while we're in here." Parkinson's law guarantees that an open project will expand to absorb any time you give it. A frozen punch list converts an infinite tail into a finite, shrinking list. The list is allowed to get shorter. It is not allowed to grow.

Step 5 — No sign-off until every item is checked

Borrow the contractor's leverage. Finished is not a vibe; it's a punch list with zero open items. Tie the milestone—the launch, the invoice, the "ship it"—to the last box being checked, not to the day someone feels ready. When the list hits zero, you're done. Until then, you're at substantial completion, and everyone knows the difference.

How to run a punch list on remote teams

Finishing projects on remote teams is harder, and the reason is structural. There's no shared "walk the building" moment, so the punch list lives in six different Slack threads, two Notion pages, and somebody's head. Worse, each loose end is *unowned*—the same diffusion-of-responsibility problem that makes launches break at the seams. Everyone assumes the last item is someone else's, so "almost done" becomes the team's permanent resting state.

The fix is to recreate the walkthrough as one shared, live moment. This is where a tool like Coommit earns its place: a single live session with HD video and an infinite canvas lets a remote team do the walkthrough together, build the punch list on the canvas where everyone can see it, and assign each item to a name in real time. Because Coommit's AI follows both the conversation and the canvas, it can surface the open items the room glossed over and turn "looks done" into an explicit, owned list before anyone signs off.

Run that session, freeze the list, and finish it. Then—and this matters—give the team a real safety stop after the crunch so the next project doesn't inherit an exhausted crew. A clean finish is also how you protect the start of the next thing.

Conclusion

The last 10% of a project isn't a smaller version of the first 90%—it's a different, harder, less fun kind of work, and "almost done" is a feeling that can drift forever because feelings have no items to cross off. Construction solved this a century ago by refusing to call a building finished until a walked, written, owned punch list hits zero.

You can borrow that discipline today. Declare substantial completion, walk the whole thing together, write every defect as an owned line, freeze the scope, and tie the finish line to the last checked box. The next time someone says "we're basically done," you'll have a better answer than hope: a punch list. And as remote work makes the tail harder to see, the teams that win will be the ones that make finishing a visible, shared ritual instead of a private guess.