Stalled Projects
Why Do Projects Stall, and What Should You Check First?
The budget is approved, the meetings continue, and the date keeps moving. These ten examples of stalled projects show where to look before choosing a fix.
Executive SummaryFind the reason for the stall before restarting the work
Start with the business result: what was expected, what happened, and whether the result is still worth pursuing. Then check the work needed to produce it, who owns that work, and where progress stopped.
A missing assignment, an approval queue, a system limitation, and conflicting priorities each call for a different response. Keeping an old process running may be necessary. Closing it too early can make the problem worse.
The ten examples below are illustrative scenarios, not client cases or evidence of how often these problems occur. Each gives a first check and a possible next step.
The status report says yellow. The steering meeting still happens. The go-live date moves another month.
Or the project is marked complete, but sales still uses spreadsheets and finance still builds the reports by hand. Delivery happened. The expected operating result hasn't followed.
A new project manager or a revised plan may help when coordination or execution is the problem. First, establish what's holding up the result. These examples show how to begin.
Ten stalled projects: what to check first
1. The ERP migration still runs in parallel
Go-live was eight months ago, but the old system is still running. Ask which transactions depend on it and inspect the exceptions that prevent retirement. Check who owns the transition and what must be true before shutdown.
Possible next step: Resolve the blocking exceptions and agree on retirement criteria with the operating owner. Set a switch-off date when those criteria can be met. Keep any necessary parallel operation explicit and under review.
2. The acquired company's order process never merged
A year after the acquisition, two order desks remain. Check whether a single process still makes business sense. Compare customer requirements, order types, and the handoffs between the desks, then establish who has authority to decide.
Possible next step: If consolidation remains justified, settle the process and responsibilities, then test representative orders before closing either desk. Separate desks may be warranted if the requirements differ materially.
3. Half the sales team ignores the new CRM
Reps still work from spreadsheets. Follow an actual sale through both tools. Does the spreadsheet handle a custom discount or multi-site account the CRM doesn't? Also check access, data quality, training, and whether the agreed process is being followed.
Possible next step: Correct the demonstrated gap. That might mean a configuration change, training, or reinforcing a workable standard. Retire a spreadsheet only after its necessary work is covered.
4. The warehouse automation pilot stopped at site one
The pilot had a vendor on the floor and an experienced supervisor. Site two has a different layout and product mix. Compare the pilot's staffing, support, exceptions, and operating results with what site two can sustain. Check who owns that assessment.
Possible next step: Assign and fund any justified adaptation work before committing to rollout. If the pilot's benefit depends on support the next site can't afford, reconsider the expansion.
5. Shared services is waiting on one decision
The accounts-payable transfer is waiting for a decision about ownership. Read the decision record: who can decide, what information is missing, and what depends on the answer? Establish whether the request is ready or has repeatedly returned for clarification.
Possible next step: Put a complete choice in front of the authorized decision-maker and agree on a decision date. If the options still lack essential information, assign that work first.
6. The new pricing model hasn't reached a quote
The model was approved in the first quarter. Trace what happened after approval. Price tables, quote templates, exception rules, and instructions for reps may need changes. Check which tasks were assigned, completed, tested, or left waiting.
Possible next step: Address the supported gap, whether it's an unassigned task, a blocked approval, or a technical problem. Validate representative quotes before wider use, including exceptions.
7. Two business units haven't adopted the vendor consolidation
The proposal counts purchasing savings at corporate level, while the units face switching work. Check the full cost, the service requirements, and the units' stated objections. Establish whether anyone agreed on who would fund and carry out the transition.
Possible next step: If the benefit survives those checks, settle the funding and operating responsibilities. If service requirements or switching costs undermine the case, revise the scope. A funding dispute alone doesn't prove why adoption stopped.
8. The customer portal is live and so is the old intake
Customers still phone and email. Follow those requests: can the portal handle them, can customers use it, and are any channels deliberately retained? Check the transition plan before assuming someone forgot to close the old intake.
Possible next step: Fix the demonstrated barriers and agree on which requests should move to the portal. Plan support and exceptions before setting a cutoff. Measure completed requests and service quality as well as portal use.
9. Finance still builds reports by hand
The data warehouse arrived on time, but month-end reporting hasn't changed. Compare a finished report with the available data, definitions, adjustments, and controls. Trace the manual steps to see which are necessary and which duplicate work.
Possible next step: Correct the specific data or reporting gap, then reconcile outputs before retiring a manual report. If the new process releases staff time, report that separately from any reduction in spending.
10. The AI pilot has been in review for five months
The demo worked, but approval hasn't followed. Inspect the legal and security review record. What remains unresolved, what evidence is required, and who must supply it? A successful demo doesn't establish readiness for live operations.
Possible next step: Assign the outstanding evidence or decision to the appropriate owner and agree on a review point. The result may be approval, a narrower pilot, further controls, or a stop. Don't assume the review is just a queue to clear.
What these examples can tell you
The same visible symptom can have different causes. A spreadsheet might cover a missing function, provide a necessary control, or persist because an agreed process isn't being followed. Its existence doesn't settle the question.
Before tracing a stalled project, check four things: whether the outcome is still worth pursuing, whether it's a chosen priority, whether the required capability, information, authority, and funding are available, and whether an external dependency controls progress.
Then examine the work required to get the result:
- Was necessary work identified and assigned? Check responsibility for local operating requirements, handoffs, retiring or deliberately retaining old processes, and absorbing the change. Confirm assignments against plans, agreements, and work records. An unknown owner is an unanswered question, not proof that nobody was assigned.
- Where did the work wait or return? Follow approvals, queues, decisions, dependencies, handoffs, and rework. Distinguish time spent working from elapsed time. Find out what a blocked step needs before removing it.
- Did working conditions contribute to errors or rework? If interruptions, switching, or competing demands are a plausible explanation, look for a decline from sustained performance, errors that cluster under those demands, and a similar pattern among people sharing the conditions. Busyness alone isn't evidence of cause. To test whether the effect is reversible, change the conditions and keep the same people. Both the operating result and the associated capacity pattern have to improve. Faster flow alone isn't enough.
Keep other explanations open, including capability, staffing, tooling, incentives, and execution discipline. More than one cause may contribute. It's also possible that neither work-path friction nor demand conditions explains the shortfall.
Before you fund the fix, find the right problem.
Choose the next step for one stalled project
Pick one result and reconstruct what happened from the work records. State the strongest supported explanation, what remains uncertain, and what evidence could change the conclusion. Your project manager, operations leader, or internal improvement team may be able to do this.
Where costs can be established, keep extra labor, elapsed delay, estimated opportunity value, and the cost of a proposed change separate. A delayed benefit isn't automatically lost revenue, and time released isn't automatically cash saved.
Agree on a next action, an accountable owner, and a review point. That may mean correcting a known problem, making a decision, gathering evidence, testing a change, or stopping work that no longer makes sense. More movement is useful only if it advances the result.
For a broader look at causes, read why projects fail and what to check first.
Still unclear what's holding up the result?
Emergent Skills is an operations consulting firm. We investigate why projects stall, results fall short, and problems keep coming back.
The Stalled Priority Snapshot focuses on one result: $1,500 fixed, a 90-minute session with up to three participants, and a written readout within 24 hours of the session. It sets out what the evidence supports, what remains uncertain, the costs we can establish, and the next step we recommend. No further engagement is required.
