Research
Why Projects Stall
Projects rarely stall because people stop working. They stall because one condition on the critical route cannot clear, while activity continues around it.
A stall is execution drag with a single address. Same two routes, friction in the work path and demand conditions that reduce reliable access to existing skill. The parent page names that condition across your operation. This page traces it on one outcome, where there is a record and a date.
Start the Stalled Priority Snapshot Run the Execution Drag Calculator
Executive SummaryWhat a stall actually is, and how we find the condition.+
A stall is execution drag with a single address. One condition on the critical route cannot clear, and nobody has enough ownership, authority, information, or available capacity to clear it. Work continues around it, which is exactly why it stays invisible.
The activity is the disguise. Status meetings, updates, partial work, and revised schedules all keep producing output while the value bearing route is blocked. Two decades of research on project status reporting says this is not accidental. Bad news travels upward slowly, and status gets biased more often than not.
Eight mechanisms produce stalls, in three tiers. Two sit upstream of the work path and were set at the point of approval. Four live on the work path, leave timestamps, and can be traced in one session. Two are conditions of authority and change. The tier tells you whether the fix is a design change or a decision the sponsor has to make.
Reports miss it because they measure the wrong quantities. Percentage complete, tasks closed, budget consumed, and status color are measures of activity. Waiting time, decision age, dependency age, reopen count, and approval concentration are measures of flow. A project can report 80% complete for months on activity alone, while the remaining 20% holds the thing the whole outcome rests on.
Four signatures locate it: work waits, work loops, work piles up, or work routes through overloaded people. These are the same four we use at the system level. On a single outcome they get sharper, because one outcome has one record.
We read the record, not the room. Approval logs, ticket transitions, decision logs, document version history, and calendar traces. A record nobody can produce is a finding on its own.
Three instruments run in order, and confusing them is how a diagnosis gets overclaimed. Five gates screen whether the outcome is traceable at all, or whether it is a strategy, specification, resourcing, or external problem wearing a stall's clothes. The trace establishes work-path friction on its own evidence, with no claim about anyone's state required. The Four Tests apply only to the narrower claim that demand conditions have also reduced reliable access to existing skill, and most Snapshots do not need that claim.
Some fixes are not ours. Tooling and platform consolidation, staffing levels, incentive design, and external dependencies can all produce real drag and all fall outside what we remediate. If that is where your stall lives, you will hear it in the first session.
The usual first step is a $1,500, 90-minute Stalled Priority Snapshot on one stuck priority. We reconstruct the actual path, identify the strongest observable work-path pattern, estimate a directly traceable drag floor, and design one 14-day routing experiment. It produces a credible local routing hypothesis, not a measured outcome. If the pattern extends beyond one priority, the half-day Work Demand Diagnostic is the next step, and we will tell you when it does.
The project is moving administratively. The value bearing route is blocked. Everyone in the room can describe activity, and nobody can name the condition that has to clear before the next real result exists.
A project stalls when a condition on its critical route remains unresolved and nobody has sufficient ownership, authority, information, or available capacity to clear it.
That definition is narrow on purpose. It rules out the two explanations organizations reach for first, effort and talent, and it points at something you can locate: a decision, a dependency, a deliverable, or a shared resource that is stuck, and an owner who is missing.
Evidence
What the research shows
Complexity is now the operating environment
In the Project Management Institute's 2026 Pulse of the Profession, 81% of project professionals said projects have become more complex in recent years, with 37% describing a significant increase. Almost all of them, 97%, had managed at least one complex project in the past year. Of the complex projects, 31% failed to achieve the full scope of their intended benefits, more than twice the rate PMI reports for projects overall.
PMI attributes the rise to unclear governance, siloed teams, misaligned objectives, competing incentives, faster technology cycles, and external volatility. Worth reading precisely: those are named as drivers of complexity, not as direct causes of failure. They describe the conditions in which a route gets long and hard to see. PMI 2026 Pulse of the Profession
Decisions do not clear
McKinsey surveyed more than 1,200 managers and found that fewer than half considered their organization's decisions timely, while 61% said at least half the time spent making them was ineffective. The estimated opportunity cost at a typical Fortune 500 company was around 530,000 manager days a year, roughly $250 million in wages. Three keys to faster, better decisions
The mechanism behind the number is specific. When decision roles are assigned loosely, too many stakeholders end up holding a vote or a veto, delegated decisions get escalated back up for cover, and agenda items never declare whether they exist to decide, discuss, or inform. McKinsey's own prescription is the useful part: give more people a voice and fewer people a vote. The limits of RACI
Governance itself can be the delay
A 2025 UK Treasury review of mega projects found that immature plans, unrealistic early estimates, convoluted approvals, blurred accountability, low approval thresholds, and stop-start annual budgeting produced expensive mid-project resets. Two figures carry the argument. On one rail programme, every £1 of scope deferred to meet an annual budget added an estimated £1.25 to total cost. On a £31 billion submarine programme, the delivery agency had to seek approval for any spend over £250,000.
The review also supplies a positive control, which is rarer and more useful. Once the 2012 London Olympics had a realistic budget, tiered contingency, and permission to move money between years, it delivered on time and within budget. One design detail stands out: approvers were required to confirm their decisions within four weeks of the review meeting. A hard clock on the approval queue. Value for money study: mega projects
These are mega project findings and should not be applied mechanically to ordinary corporate work. The mechanisms are recognizable at any scale.
Sponsorship is a behavior, not a title
Prosci's practitioner research reports that 72% of respondents with extremely effective sponsors met or exceeded objectives, against 29% of those with extremely ineffective sponsors. This is self-reported data from a change management vendor, so treat the size of the gap with care and the direction as credible.
The behavior that matters is active tradeoff making, coalition building among peers, protecting resources when they are contested, and visible reinforcement over time. A sponsor who cannot resolve a tradeoff is a stall waiting to happen. Prosci sponsorship research
Late work hides, and so does the stall
This is the best evidenced part of the picture and the least discussed. Ford and Sterman named the 90% syndrome: a project appears on schedule through the first 90% of scope, then late discovery of errors and rework stalls progress, and finishing the last 10% takes about as long as the first 90%. Their companion work showed that under schedule pressure people conceal known rework from managers and colleagues, which degrades schedule and quality further.
Two decades of research on project status reporting points the same way. Status is selectively reported, bad news is withheld upward, and one study estimated that project managers bias their status reports roughly 60% of the time. So recollection is not evidence. If you want to know how long something has been waiting, read the record, not the room.
Projects are authorized on best case assumptions
Bent Flyvbjerg identifies strategic misrepresentation, optimism bias, uniqueness bias, the planning fallacy, the base rate fallacy, and escalation of commitment among the ten behavioral biases that most affect project management. His central point is easy to miss: cognitive bias is only half the story, and political bias is the other half.
The projects that get approved are the ones that look best on paper. The ones that look best on paper are the ones with the largest cost underestimates. Flyvbjerg calls the result survival of the unfittest.
That is why a stall trace has to test whether the commitment was ever deliverable on its stated terms before it labels anything execution drag. Top ten behavioral biases in project management
Patterns
Eight recurring stall mechanisms
The first two sit upstream of the work path and were set before the project started. The next four live on the work path itself, produce timestamps, and can be traced in a single session. The last two are conditions of authority and change. Knowing which tier you are in tells you whether the fix is a design change or a decision the sponsor has to make.
1. An immature project is approved
The outcome, requirements, benefits, delivery route, or constraints are not sufficiently understood at the point of commitment.
Observe: repeated discovery, missing requirements, unresolved assumptions, early re-baselining.
2. Too many priorities remain active
Shared people and resources are divided across more work than the system can finish, so every commitment borrows capacity from another.
Observe: starts exceed finishes, priorities change constantly, milestones all move right together.
3. Decisions cannot clear
The decider is unclear, too many people hold a veto, or the decision waits for a meeting that meets every other week.
Observe: aging decision log, repeated discussion of settled questions, postponed approvals, reversals.
4. Dependencies cannot clear
Progress depends on another team, a vendor, a specialist, a system, an approval, or information nobody has requested in writing.
Observe: blocked days, handoff count, follow-up touches, queue age.
5. Work repeatedly reopens
Requirements, completion criteria, reviewer involvement, or quality expectations arrive after the work was already done once.
Observe: revision count, reopened tasks, repeated review, late defects, a definition of done that moved.
6. Scarce judgment becomes the constraint
Difficult work routes through the same manager, expert, or sponsor. In one study across 300 organizations, 3% to 5% of employees accounted for 20% to 35% of value adding collaboration. Work does not progress until they have weighed in.
Observe: approval concentration, rescue work, escalations, after-hours intervention.
7. Sponsorship or adoption weakens
Nobody with authority protects the project, resolves conflicts between it and competing work, or changes the operating conditions adoption requires.
Observe: unresolved tradeoffs, conflicting messages, workarounds, old and new processes running in parallel.
8. Conditions change but the plan does not
Technology, regulation, customer requirements, leadership, staffing, or strategy moved, and the schedule was revised without a genuine replan.
Observe: schedule revisions with no scope decision, hidden work, assumptions nobody has revisited.
These mechanisms compound. An unclear requirement creates a loop. The loop reaches an overloaded expert. The expert's queue creates waiting. The delay triggers escalation. The escalation adds meetings and approvals. The new controls lengthen the route further.
Measurement gap
Why project reports miss the stall
A stalled project usually has a current, accurate, well formatted status report. It measures the wrong quantities. The parent case is that dashboards miss the condition across the system. This is the narrower version: on one outcome, the report will not tell you how long it has been waiting.
What reports show
- Percentage complete
- Tasks completed
- Budget consumed
- Milestones
- Red, amber, or green status
- Risks and issues
What they leave out
- Percentage of elapsed time spent waiting
- Age of unresolved decisions
- Age of dependencies
- Number of reopenings
- Approval concentration
- Work in progress competing for the same people
- Changes to the definition of done
- Time spent reconstructing context
- Work added without an explicit tradeoff
- Whether the next milestone has a clear route to completion
Everything in the first column is a measure of activity. Everything in the second is a measure of flow. A project can report 80% complete for months on the strength of the first column alone, while the remaining 20% holds the integration, the acceptance, the decision, or the dependency the entire outcome rests on.
That is the 90% syndrome under a different name. Waiting is reported in calendar days. Work is reported in touch hours. The gap between the two numbers is the finding.
How we read it
Four observable signatures
These are the same four signatures we use on execution drag at the system level. On a single stalled outcome they get sharper, because one outcome has one record. Every mechanism above leaves one of the four traces in that record. We start with the trace, because the trace carries a timestamp.
Work waits
On decisions, approvals, information, dependencies, or authority. Measured in elapsed calendar days.
Work loops
Unclear requirements, late review, rework, completion criteria that moved after the work was done.
Work piles up
Too many active commitments, unresolved issues, and priorities colliding over the same people.
Work routes through overloaded people
Concentrated judgment, concentrated approval, and rescue work absorbed by whoever is willing.
These signatures do not explain every root cause. They show where to begin tracing. What they buy you is a starting point that is not a person.
We keep three explanations separate, and we say which one we are making. First, direct friction in the work path. The trace establishes this on its own, with no claim about anyone's state required. Second, a capacity mediated effect, where accumulated demand has reduced reliable access to skill people already have. That narrower claim is held to the Four Tests before we make it: a baseline shift, a load signature, shared conditions, and reversibility. Third, explanations that are simply better than ours, including the wrong strategy, a genuine skill gap, poor role fit, or ordinary human error.
There is also a fourth category worth naming early, because it saves everyone money. Some conditions produce real drag and fall outside what we remediate: tooling and tool consolidation, staffing levels, incentive design, and external dependencies. If the honest answer to your stall is buy a tool or hire a specialist, that is a real fix and it is not ours. We will say so in the first hour rather than the fourth month.
Reduced access to skill is an amplifier, not the presumed cause. A firm that refuses an available claim is worth more than one that reaches for it.
Method
Trace one outcome, not the project
A project is too large to trace in 90 minutes, and tracing it produces a survey rather than an answer. So we do not. We trace one concrete thing that should already exist:
- The milestone that should have moved
- The decision that has not landed
- The deliverable that keeps coming back
- The dependency blocking the next step
- The approval sitting in a queue
The eight opening questions
- What tangible result should exist by now?
- What was the last meaningful movement toward it?
- What must happen next?
- What is preventing that from happening?
- Who owns clearing that condition?
- How long has it been waiting?
- How many times has the work returned or changed direction?
- What other priorities compete for the same people or decisions?
Questions two, six, and seven are answered from the record. Approval logs, ticket transitions, decision logs, document version history, calendar traces. The status reporting research is unambiguous about why: the people closest to a stalled outcome have measurable incentives to misremember exactly these three answers. If the timestamps cannot be produced, that is itself the first finding.
Five gates before we trace
Some outcomes are not stalled. They are cancelled, deprioritized, unfunded, or were never deliverable on the terms they were committed to. Tracing those produces a persuasive account of waiting and looping that explains nothing, so the gates run first, out loud, in front of the sponsor.
- Is the intended outcome still valid?
- Was it ever achievable as specified?
- Is leadership still choosing this work over the alternatives?
- Are the required skill, tooling, information, staffing, and funding available?
- Is an external dependency controlling the pace?
Gate two exists because of Flyvbjerg. A trace run against a commitment that was never deliverable will find plenty of waiting and looping, and will confidently mislabel a specification failure as execution drag. Gate four is where our scope boundary sits: a yes means we can work on it, and a no means the fix belongs to someone else.
How the gates and the Four Tests fit together
Two instruments, two different jobs, and they run in order rather than instead of each other. Confusing them is how a diagnosis gets overclaimed.
- The five gates screen the outcome. They decide whether this is a stall worth tracing, or a strategy, specification, resourcing, or external problem wearing a stall's clothes.
- The trace establishes the work-path route. Waiting, looping, piling up, and routing through overloaded people are read from the record. Friction in the work path is execution drag on its own evidence. No claim about anyone's state is needed to make it.
- The Four Tests gate the second route only. If we want to say the demand conditions have also reduced reliable access to existing skill, that claim has to clear a baseline shift, a load signature, shared conditions, and reversibility. Most Snapshots do not need it. We say so when they do not.
A stall can be fully explained by the work path. The capacity claim is optional, it is narrower, and it costs more to make. We only make it when the evidence carries it.
The point
What this changes
Most organizations do not need another project management assessment. They need to find the specific condition preventing the next important result from moving, and to know what the waiting has already cost.
When most of an outcome's elapsed life is spent waiting rather than being worked on, speeding up the work barely moves the date. Removing a wait state moves it substantially. That ratio is measurable on your own record.
Start with the blocked outcome. Not the project plan, and not the people.
Bring the outcome that should have moved.
One milestone, decision, or deliverable, and the record behind it. The usual first step is a $1,500, 90-minute Stalled Priority Snapshot on one stuck priority. We reconstruct the actual path, identify the strongest observable work-path pattern, estimate a directly traceable drag floor, and design one 14-day routing experiment. It produces a credible local routing hypothesis, not a measured outcome. If the pattern extends beyond one priority, the half-day Work Demand Diagnostic is the next step, and we will tell you when it does.
If you would rather size the exposure before talking to anyone, the Execution Drag Calculator takes three inputs and under two minutes.