There is an old engineering joke that the first 80% of a project takes the first 80% of the time, and the last 20% takes the other 80%. It endures because it is true. 'Eighty percent complete' is the status at which the most projects quietly begin to fail — because the remaining work is the hardest, least visible, and most frequently under-reported part of the whole.
Why 'almost done' so often isn't
Progress is usually reported by feature count — screens built, tickets closed. But a feature that renders is not a feature that is finished. Between 'it works on the developer's machine' and 'it is ready for your users' lies integration, edge-case handling, error states, security hardening, performance under load, testing, bug-fixing and documentation. This is real, heavy work, and it is precisely the work that a feature-count status hides.
Test completion against evidence, not assertion
- Acceptance criteria — is each feature complete against a written, objective definition of done, or just demonstrable?
- Non-functional state — has performance, security and scale actually been tested, or only assumed?
- Test coverage — does automated testing exist, and does it pass?
- Defect trend — is the open-defect count falling or quietly rising?
- Deployment reality — has it been deployed to a production-like environment, or only run locally?
- Documentation — does the handover material exist yet, or is it 'to be done at the end'?
A project that is genuinely 80% complete can produce evidence for most of these. A project that is 80% reported and 50% real cannot — and the gap is usually visible within a day to someone independent who knows where to look.
Your vendor says the project is 80% complete. The only honest way to know is to verify it against evidence, not against the vendor's status deck.
This is the purpose of an independent project health check: to replace an asserted percentage with an evidence-based one, estimate the effort genuinely remaining, and give you a real number to plan and negotiate around.