The 90 % syndrome: why projects stall just short of the finish line
The project reports 90 percent complete. Then it grinds to a halt. Week after week the number barely moves, even though the team is working harder than ever. Sound familiar? The pattern has a name: the 90 % syndrome, and it was thoroughly described by researchers Tarek Abdel-Hamid and Stuart Madnick in their 1991 book Software Project Dynamics.
Their work focused on software projects, but the mechanisms they uncovered show up in most projects: hidden defects discovered late, schedule pressure that creates new problems, and forecasts built on what we believe is done rather than what actually is.
What does the research say?
Abdel-Hamid and Madnick built what is known as a system dynamics model of a project – a simulation model in which staffing, planning, progress tracking and the work itself are interconnected and influence each other over time. Instead of studying the parts in isolation, they could run the whole project as a simulation and see how different management decisions played out.
The model explains the 90 % syndrome like this: some of the work reported as complete contains errors that no one has discovered yet. This undiscovered rework stays hidden until testing and integration begin – in other words, late in the project. Then it surfaces as new work, and the progress figure freezes despite everyone working flat out. The project was never 90 percent done; it only looked that way.
They also showed how schedule pressure works like a loan at a high interest rate. When the team is pushed to go faster, the pace increases for a while – but so does the error rate. Errors cost more to fix the later they are found, so today's pressure becomes tomorrow's delay. And throwing extra people in late rarely helps, because newcomers have to be trained by exactly the people who are already stretched the thinnest.
What does this mean for you as a project manager?
Don't trust percentage figures based on self-reporting. Instead, ask for things that are verifiably done: tested features, reviewed documents, accepted deliverables. The gap between "done" and "done and verified" is exactly where the 90 % syndrome hides.
When the steering group or the client wants to squeeze the schedule, make the trade-off visible: a faster pace now means more errors later. You don't have to say no – but you should be able to describe what the pressure will cost, so the decision is made with open eyes instead of on hope.
Plan for rework to be discovered. If your forecast assumes there are no hidden defects, it is almost certainly too optimistic. A project that tests and reviews early moves the discovery of errors forward – and that is the cheapest insurance there is. And when the number does freeze at 90 percent: don't read it as the team losing momentum, but as the hidden work finally becoming visible. It's uncomfortable, but it's also the first step towards an honest forecast.
How to practise this
Understanding these dynamics in theory is one thing – standing in the conversation where a client demands an earlier delivery is another. In Project-simulator you can practise exactly those conversations against AI counterparts: explaining why the number is lying, negotiating schedule pressure and reporting deviations honestly, with feedback that points to your own wording. Try it free for a week and get a feel for it before it counts for real.
In Project-simulator you practice these conversations against an AI counterpart and get feedback grounded in research like this.
Try free for 7 days