Why Software Projects Stay 90% Complete for Months
"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.
Recognised this situation?
Five business days, fixed scope — a clear recommendation on what to do next.
Was this useful?
Related Expertise and Services
Frequently asked questions
Why does a software project stay at 90% complete for so long?
Usually because the original estimate covered visible feature work but not the integration, quality, deployment, security, and acceptance work that only becomes fully visible once the features are mostly built. The percentage reflects effort already spent on known work, not the risk remaining in work that was never fully scoped.
Is it normal for a project to say 90% complete for several months?
No. A single reporting cycle at 90% is normal. The same number repeated across multiple consecutive cycles, without the underlying remaining-work description changing, is a reliable warning sign that the definition of "complete" has drifted away from what the business actually needs.
How do I know if my team or vendor is being honest about 90% complete?
Ask for a live, working demonstration of the specific remaining work today, not next sprint. Ask which of the five hidden-work categories — integration, quality, deployment, security, acceptance — the remaining 10% falls into. A team that cannot answer either question specifically is likely reporting an eroded standard of done.
What is the Ninety-Ninety Rule?
A well-known piece of software engineering folklore, attributed to Tom Cargill of Bell Labs: the first 90 percent of the code accounts for the first 90 percent of development time, and the remaining 10 percent accounts for the other 90 percent. It captures a real, well-documented pattern of underestimating late-stage integration, testing, and refinement work.
What is a definition of done, and why does it matter here?
An explicit, agreed standard for what "complete" requires — typically including test coverage, security review, deployment readiness, and stakeholder acceptance, not just the feature working in isolation. Without a written one, the informal standard tends to erode under deadline pressure, which is the structural root cause of a status report that stalls at 90%.
Should we add more people to finish a project stuck at 90%?
Usually not as a first move. Most of what remains in a stalled project requires deep, specific system knowledge that new team members do not yet have, and onboarding them takes time away from the people who already have that knowledge. An independent assessment of what actually remains is a more reliable next step.