Ninety-percent done is still NOT done.

— #ProjectManagementTweet, Himanshu Jhamb & Guy Ralfe (2010)

Everyone has heard of the 80/20 rule. Pareto’s principle, in its many forms, carries one central message: don’t chase perfection. Get 80% of the way there, because in most situations the last 20% doesn’t return nearly as much as the effort it costs.

It’s a sound principle in many parts of life. It does not hold in software delivery.

Every team wants to say a piece of work is Done. It gets you to the next interesting thing. It fills the checkbox on the weekly status report, and the one that rolls up to the executives the following month. That instinct is one of the quietest, most dangerous pitfalls in software delivery — because it can have your project sitting comfortably in the “Green” zone right up until it lands, without warning, in Red.

In 2017, I watched exactly this happen — on a programme I was leading, with a team I trusted completely.

Chasing the Word “Done”

I was leading a delivery team of roughly 75 to 80 talented people, running quarterly Planning Intervals under the SAFE framework, on a multi-year programme. We were falling behind — gradually, in a way that was hard to pin down. Every workstream showed up to the regular status meetings and reported Green. And after every Planning Interval, we still failed to deliver something.

So I started digging. Instead of taking the status reports at face value, I began asking more pointed questions: what did “Done” actually mean — from each individual team’s perspective, and from the perspective of the combined deliverable?

What “Done” Actually Meant

What I found was telling. Developers, the moment they checked their code into the repository, considered themselves done. But deployment kept hitting snags, and more than once, testers received work that wasn’t even ready for basic testing.

Every team was technically right about their own definition of Done. There was just a gap — nobody had agreed on what the word meant once you looked at it from the perspective of whoever picked up the work next.

Redefining “Done”

The fix wasn’t a new process or a new tool. I asked every team to redefine “Done” — not from their own vantage point, but from the perspective of whichever team was next in the workflow, the one that had to pick up the baton and actually run with it.

Once every team aligned to that new definition, the slippage stopped. We even ended up with a bit of shorthand that stuck around long after: “Is it Done, or is it Done Done?”

What I Took Away

When throughput starts declining and nobody can point to why, go back to the basics before reaching for anything more sophisticated. Ask what your own terminology actually means, team by team, to the people using it.

Ninety percent done is one of the most dangerous numbers in the language of software delivery — not because anyone is lying about it, but because it rarely means the same thing to the person reporting it and the person relying on it downstream. The 80/20 rule is a fine way to prioritize effort. It is a poor way to define completion.

The gaps that stall a programme are rarely as large as they feel from the outside. More often, they’re a handful of teams using the same word to mean different things — and once you find it, the fix is smaller than anyone expects.

If your status reports keep saying Green while your delivery dates keep slipping anyway, the gap is probably closer to home than you think. I’m happy to help you find it.