Why Software Projects Stay 90% Complete for Months
Summarize with AI
Read summarized version with AI
- A project genuinely at 90% complete for one reporting cycle is normal. The same number repeated across multiple cycles usually means the definition of "complete" excluded work that has since resurfaced.
- The missing 10% is rarely one thing — it typically spans five categories that a weak definition of done leaves out entirely: integration, quality, deployment, security, and acceptance work.
- "Percent complete" measures effort already spent, not risk remaining. A status report that only tracks the first one will always look better than the project actually is.
- If a project has been reported at 90% complete for more than one consecutive cycle, that pattern alone is a legitimate trigger for an independent assessment.
"90% complete" sounds close enough to finished that asking for details feels almost rude, like second-guessing a team that is nearly there. That is exactly why it is the most dangerous number in a status report. A project that has been 90% complete for three consecutive status updates is not describing its progress anymore. It is describing a number nobody has revised, because revising it would mean admitting something nobody wants to say out loud yet.
This has a name software engineers have used for decades: the Ninety-Ninety Rule, coined by Tom Cargill of Bell Labs — the first 90 percent of the code accounts for the first 90 percent of the development time, and the remaining 10 percent accounts for the other 90 percent.
What is actually hiding inside the missing 10 percent?
The work that gets left out of an early "90% complete" estimate clusters into five categories, consistently, because these are the categories hardest to see until the feature-building phase is mostly finished.
- Integration work. Individual features frequently work correctly in isolation and fail in combination, because the interactions between modules, services, and third-party systems were never fully mapped during initial estimation.
- Quality work. Test coverage, regression testing, and defect resolution are frequently the first casualties of schedule pressure. A feature marked "done" without adequate test coverage looks identical, on a status report, to a feature that has actually been verified.
- Deployment work. Getting a system running reliably in production — with monitoring, rollback procedures, and load handling — is a distinct body of work from building the features themselves.
- Security work. Security review, access control verification, and data handling compliance are disproportionately likely to be scheduled "later" because they rarely block a feature demo.
- Acceptance work. Formal verification that the system does what the business needs — user acceptance testing, stakeholder sign-off, operational documentation — is frequently the first item compressed when a deadline is slipping.
| Category | What "90% complete" usually means here | What often actually remains |
|---|---|---|
| Integration | Individual features built and demoed in isolation | Cross-system behavior under real data, real load, real third-party responses |
| Quality | Features marked done in the tracker | Test coverage, regression testing, defect backlog actually resolved |
| Deployment | Working in a development or staging environment | Production-grade monitoring, rollback plans, environment configuration, load handling |
| Security | Core authentication and authorization features built | Security review, access control verification, data handling compliance |
| Acceptance | Engineering considers the feature set functionally complete | Stakeholder sign-off, user acceptance testing, operational documentation |
Why does a weak definition of done cause this, systematically?
Where a definition of done exists only as an implicit shared understanding, it tends to narrow under pressure — quietly, gradually, without anyone deciding explicitly to lower the bar. A feature that was meant to include test coverage, security review, and documentation when the project started can end up counted as "done" with none of those, because the informal standard for "done" eroded one deadline at a time.
How do you evaluate a vendor or team's claim of being 90% complete?
The most reliable single test is also the simplest: ask for a live, working demonstration of the specific remaining 10% today, not a description of what will be demonstrable next sprint. A genuinely near-complete project can usually produce this within a day or two. Beyond that, ask which of the five categories the remaining 10% falls into, whether the remaining-work estimate has changed across the last several reporting cycles, and whether there is a written definition of done the remaining work is being measured against.
A project stalled at 90% complete for months is frequently sitting inside the risk window where projects threaten the business — still being reported as nearly finished right up until it isn't.
Read Intelvision often? Add us as a preferred source in Google Search.
Add to preferred sources