A practical diagnosis for failing projects
Failing Projects: Why Projects Fail and What to Check First
Projects can fail because the project itself is wrong, its constraints are unrealistic, or it lacks the funding, authority, capability, or sponsorship required to succeed. Others begin failing while people are still working because a critical decision, dependency, or handoff cannot clear.
The warning signs are ordinary. Dates keep moving, dependencies age, completed work reopens, and the same questions keep returning to the same managers. Emergent Skills checks the project itself first, then traces the work path when the evidence points there. That is how we distinguish a bad premise or an outside constraint from the waiting, looping, and rerouting we call execution drag.
The first question is arithmetic. What share of this outcome's elapsed life was spent being worked on, and what share was spent waiting? That ratio is its flow efficiency. Many organizations do not routinely calculate it for their most important stalled work or price what the delay has already consumed. Those numbers rarely appear together on a standard project dashboard, but both are recoverable from records you already keep.
Start the Stalled Priority Snapshot Run the Execution Drag Calculator
Executive SummaryWhat a stall is, and where the evidence lives.+
A stalled project usually has one condition controlling whether the outcome can move, but that condition may sit before, inside, or outside the work path. The intended result may no longer be valid. Funding, capability, information, authority, or sponsorship may be missing. An external dependency may control the date. When those checks hold and the route remains blocked, work often continues around the blockage. Status meetings, updates, partial work, and revised schedules keep producing activity while the value-bearing route waits.
On time, the argument reduces to one number most status reports omit: the share of a stalled outcome's elapsed life spent waiting rather than being worked on. That ratio is its flow efficiency. Whatever the share turns out to be, the remainder is the ceiling on everything aimed at the work itself, including training, tooling, headcount, process improvement, incentives, effort, and AI assistance. That is an identity rather than a research finding, and it holds at any ratio. What it does not settle is how much of the waiting is removable, or which waits sit on the critical route rather than in parallel with it. A Snapshot answers that from your own record.
On cost, two things are establishable from one outcome's record, and they are reported separately. The hours you can defend are the labor the stall consumes in meetings, context reconstruction, escalation, and rework, countable from the calendar. The elapsed delay is reported on its own and never folded in, because valuing it rests on your assumptions about benefit rather than on our evidence. What one outcome cannot price is the load the stall put on the people carrying it, or the exposure from it recurring. Both belong to the operation rather than the instance.
Eight recurring conditions can produce or prolong a stall, in three groups. Two were set at the point of approval, before the work path existed. Four sit on the work path, leave timestamps, and can be established in one session. Two are conditions of authority and change that show up indirectly. The group tells you where the evidence lives, not who owns the fix.
Three instruments run in order on a Snapshot, 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 it. The Snapshot page carries the full method.
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, ending in one 14-day experiment designed to be capable of failing. When the pattern reaches past one priority, the Work Demand Diagnostic is the next step.
Before the work-path diagnosis
Check the project before tracing the path
Some projects are compromised before execution begins. Harvard Business Review identifies five broad failure conditions: the wrong project, unrealistic constraints, ineffective leadership, excessive complexity, and basic project-management failures. A route analysis cannot rescue a project that should not proceed or one that was never given what success requires.
Emergent Skills screens five questions first: Is the intended outcome still valid and clearly defined? Is it still a genuinely chosen priority? Are the necessary capability and information available? Do the people carrying it have the funding and authority required to act? Does an external dependency control the date?
If one of those conditions explains the failure risk better, that is the finding. If they hold and the work is still waiting, looping, reopening, or routing through overloaded people, tracing the actual path becomes useful.
Flow efficiency and the cost of waiting
Flow efficiency: separate work from waiting
Waiting is reported in calendar days. Work is reported in touch hours. The gap between the two numbers is the finding.
A stalled project usually has a current, accurate, well-formatted status report. It measures the wrong quantities. Project-management dashboards show activity, status, and deadlines, but they rarely expose the project bottlenecks creating the delay. At the system level, why execution stalls explains how that pattern spreads across an operation. This page asks the narrower question: how long has this outcome been waiting, and why?
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 and dependencies
- Number of reopenings, and whether the definition of done moved
- Approval concentration
- Work in progress competing for the same people
- Whether the next milestone has a clear route to completion
The first column measures activity. The second measures 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.
So take your most important stalled outcome. What share of its elapsed life has been spent waiting, rather than being worked on by anyone? Flow literature calls that ratio flow efficiency.
Most status reports do not answer that question about the work that matters most.
It is not on any dashboard. It is recoverable from records you already keep. And it is the number that decides where improvement is available, which is why we establish it before anything else.
Here is why, and this part is arithmetic rather than research. Suppose one fifth of elapsed time is touch work and four fifths is waiting. If the waiting remains unchanged, eliminating every touch hour reduces elapsed time by no more than one fifth.
Some of that waiting is created by the rate of work itself, and that part does move when the work gets faster or when another pair of hands arrives. The rest comes from approval cadence, shared-resource queues, batching, dependencies, and priority competition, and none of it moves when this team gets faster. The ratio shows where elapsed time accumulates. The trace determines what can change it.
You can check which kind you have. If total touch time across the whole route is small relative to a single step's elapsed time, the route is not congesting itself, and the waiting is arriving from outside it.
We are not going to hand you a benchmark. Published flow efficiency figures for knowledge work exist, and quoting one would invite the only response it deserves, which is that your organization is different. It probably is. Your record has your number in it, and extracting it takes hours.
The ratio also does not tell you which waits sit on the critical route and which sit in parallel with it, where halving them changes nothing. That is a question for the trace.
Time lost and labor consumed
What the stall has already cost
One outcome's record supports two numbers, and we keep them apart on purpose. Combining them produces a bigger figure and a weaker argument.
One: the hours you can defend
Meetings called to discuss the stall. Time spent reconstructing context after each handoff or reopening. Escalation calls, and the people pulled into them. The rework itself. All of it sits on a calendar somewhere, attributable to this outcome rather than estimated for it.
Countable from: calendar entries, meeting logs, revision history, escalation threads.
Two: the elapsed delay, reported separately
The calendar days spent waiting rather than being worked on. That is the cost of delay, and it stays out of the labor figure above, because pricing a day of delay rests on your assumptions about the benefit that day would have delivered, not on evidence we can produce.
Countable from: stalled outcome's elapsed time, minus the touch time already established in the trace.
Neither number prices what the stall cost the people carrying it, or what it costs to have this happen again. Both belong to the operation, not to one outcome, which is what the Work Demand Diagnostic is for.
Where project failure begins
Eight recurring causes of project delays
These eight conditions include competing priorities, decision bottlenecks, missed handoffs, rework, manager bottlenecks, and changing operating conditions. 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 that rarely produce their own record and instead show up in the effects of the other six.
The groups tell us where to look for evidence and how confidently a condition can be established in one session. They do not tell us who owns the fix, which is decided case by case and often sits with the sponsor regardless.
Whatever the condition, its effects reach the record in one of four ways. Work waits, work loops, work piles up, or work routes through overloaded people. We start with the effects, because they carry a timestamp and the conditions behind them often do not. What that buys you is a starting point that is not a person.
1. The project is approved before it is understood
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. Competing priorities create capacity constraints
Shared people and resources are divided across more work than the system can finish. Work in progress climbs, workloads become harder to manage, and every new commitment borrows capacity from another priority.
Observe: starts exceed finishes, priorities change constantly, milestones all move right together.
3. Decision bottlenecks form
The decider is unclear, too many people hold a veto, or the decision waits for a meeting that convenes every other week. Slow decision-making usually traces to one of those three.
Observe: aging decision log, repeated discussion of settled questions, postponed approvals, reversals.
4. Missed handoffs and dependencies create queues
Progress depends on another team, vendor, specialist, system, approval, or piece of information. The handoff has no clear owner, acceptance rule, or response time, so the dependency waits in a queue.
Observe: blocked days, handoff count, follow-up touches, queue age.
5. Rework returns completed work to the queue
Requirements, completion criteria, reviewer involvement, or quality expectations arrive after the work was already done once. The resulting rework loop consumes capacity without moving the outcome forward.
Observe: revision count, reopened tasks, repeated review, late defects, a definition of done that moved.
6. Manager bottlenecks constrain the critical route
Difficult decisions, approvals, and rescue work route through the same manager, expert, or sponsor. Across more than 300 organizations, Cross, Rebele, and Grant found 3% to 5% of employees accounting for 20% to 35% of value-adding collaboration, and described those people becoming bottlenecks whose input everything else has to wait for. Collaborative Overload
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 causes 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.
Different questions call for different methods. A gap analysis defines the distance between the intended result and the current one. Bottleneck analysis identifies the constraint currently setting the pace. Root cause analysis asks what created or sustains the problem. This page helps you decide where to begin; the specific outcome still has to supply the evidence.
Diagnose the priority that should have moved.
Bring one stalled milestone, decision, or deliverable and the record behind it. The usual first step is a $1,500, 90-minute Stalled Priority Snapshot. We reconstruct the actual work path, establish how much elapsed time was waiting, identify the strongest observable bottleneck, put a conservative number on the hours you can defend, and design one 14-day routing experiment with its rejection condition written down in advance. It produces a credible local routing hypothesis, not a measured outcome. If competing priorities, manager overload, or work demand are creating the same delay elsewhere, the Work Demand Diagnostic is the next step, and we will tell you when it is not.
If you would rather size the exposure before talking to anyone, the Execution Drag Calculator takes three inputs and under two minutes.