You can usually tell when a project is in trouble before anyone says it out loud. Milestones slip by a few days, then a week. The budget report looks worse than the progress report. Status updates get vaguer, and the client starts asking for calls instead of emails.
If that sounds familiar, here is what to do if a project goes wrong: stop and get the facts, stabilize the work, find the root cause, tell stakeholders early, pick a recovery option (rescope, replan, add resources or stop), reset the plan, and monitor it closely until it is stable. The rest of this guide explains each step, how to handle the most common project problems, how to recognize project mismanagement, and when stopping is the better choice.
- Signs your project is going wrong
- What to do if a project goes wrong: 7 steps
- How to handle common project problems
- When the problem is project mismanagement
- When to stop a project instead of saving it
- After the recovery: capture lessons learned
- How to keep the next project from going wrong
- Use actiTIME before project management goes wrong
- FAQ
Signs your project is going wrong
A project goes wrong when it can no longer meet its agreed scope, schedule, budget or quality without a change of plan. The earlier you notice, the more options you have. Watch for these signs:
- Milestones are missed, or the team keeps moving them by “just a few days.”
- Hours or money are being used faster than work is being finished.
- The task list keeps growing while the deadline stays the same.
- Status reports say “on track” but nobody can show the numbers behind it.
- The same problems come up in every meeting and nothing changes.
- Team members are working late, getting short with each other, or asking to move to other work.
- Stakeholders go quiet, or start escalating past you.
Some of what goes wrong is outside your control and some is not. It helps to separate the two, because the response is different.
Unavoidable issues
- A staff emergency, such as illness or a family situation
- Technical failures, outages or lost data
- A client who changes their mind about the overall focus or the deliverables
- A supplier or vendor who delivers late or not at all
You cannot prevent these, but you can have a response ready. That is what the contingency plans later in this guide are for.
Avoidable issues
These usually come from gaps in planning or follow through, and they are the ones a project manager can fix:
- Missed task deadlines
- Deliverables completed incorrectly
- Overspending
- Resources requested at the last minute
- Unhappy, overloaded team members
- Missing project details
- Project goals that got lost along the way
Being available to your team, answering questions quickly and keeping stakeholders informed prevents many of these. For a longer list of what makes schedules slip, see our guide to the causes of project delays.
Recommended
What to do if a project goes wrong: 7 steps
The instinct when a project slips is to push harder on the same plan. That rarely works, because the plan is usually part of the problem. Work through these steps instead. On a small project the first four steps can fit into a single day; on a large one they take longer.
1. Stop and get the facts
Before you change anything, find out where the project really stands. Compare planned and actual dates for each milestone, hours and money spent against the budget, and the work that is done against the work that remains. Talk to the people doing the work, not only to the leads, because they know which “almost done” tasks are nowhere near done.
The output of this step is a short, honest picture: how late, how far over budget, and what is left.
2. Stabilize the project
Stop the situation from getting worse while you work on a fix. Freeze new scope requests for now, pause work that is not on the critical path, and make sure people are not pulled onto other projects in the middle of the recovery. If something is actively broken, such as a failed release or a supplier who missed a delivery, deal with that first.
3. Find the root cause
Missed deadlines and overspending are symptoms. To fix them, you need the cause. A simple method is to ask “why?” several times: the release is late because testing found 40 defects; the defects appeared because requirements changed after design; requirements changed because the client never signed off on the scope. Now you know the real problem is an unapproved scope, not slow testers.
Keep the conversation about the process, not about who is at fault. People share real causes only when they do not expect to be blamed. Also be honest about your own part: if you approved a deadline you knew was tight, say so.
4. Tell stakeholders early, with options
Bad news gets worse with age. As soon as you understand the size of the problem, tell the sponsor and the client. Explain what happened in plain language, what it means for the date and budget, and what you propose. Bring two or three options with their costs instead of a single request, so the decision is theirs and the trade offs are clear. If the problem needs money or a decision above your level, escalate it now rather than at the next scheduled review.
5. Choose a recovery option
Most recoveries use one of these options, or a mix of them:
| Option | When it fits | What it costs |
|---|---|---|
| Reduce scope | The date is fixed and some features can wait | Less delivered now; a second phase later |
| Move the date | Scope is fixed and the date is not tied to an external event | Stakeholder trust, plus team cost for the extra time |
| Add people or budget | Remaining work splits into well defined tasks | Money, and time spent bringing newcomers up to speed |
| Reorder work to run in parallel | Tasks that were planned in sequence do not truly depend on each other | Higher risk of rework if assumptions are wrong |
| Stop the project | The reason for the project no longer holds, or finishing costs more than it is worth | Money already spent is lost; people are freed for other work |
Be careful with adding people late. New team members need time and help from the existing team before they are productive, so on a project that is already behind, extra people can slow things down at first.
6. Replan and reset the baseline
Once stakeholders agree on an option, build a new plan from the remaining work, with fresh estimates based on how long similar tasks actually took on this project. Confirm owners and dates for every task, write down what is now out of scope, and get the new plan approved. This becomes the new baseline that progress is measured against.
7. Monitor closely and communicate often
A recovering project needs more attention than a healthy one. Check progress against the new plan at least weekly, compare estimated and actual hours on the open tasks, and send stakeholders short, regular updates even when nothing dramatic has happened. A simple project status report template keeps those updates consistent. Return to the normal rhythm once two or three reporting periods in a row are on plan.
How to handle common project problems
Not every problem needs the full recovery process. For many everyday issues, the right first move is enough to keep them small:
| Problem | First move |
|---|---|
| Scope keeps growing | Route every request through one change process and show its effect on date and budget before saying yes. See our guide to scope creep. |
| A task is late | Check whether it is on the critical path. If not, note it and move on; if yes, find out what is blocking it today. |
| Budget is running out | Compare spending with work finished, find the tasks that overran, and raise it with the sponsor before the money is gone. |
| A key person leaves or falls ill | Reassign their critical tasks first, and ask them (if possible) for a short handover of work in progress. |
| Client changes direction | Treat it as a change request: document the new direction, estimate its effect, and agree on the new scope in writing. |
| Team conflict | Talk to each person separately first, then agree on roles and how decisions get made. |
| Vendor misses a delivery | Get a firm new date in writing, check the effect on your schedule, and activate a backup supplier if you have one. |
Our article on project management challenges goes into more of these situations.
When the problem is project mismanagement
Sometimes nothing outside the project went wrong. The trouble is how the project is being run. Project mismanagement usually looks like one or more of the following:
- No written plan, or a plan nobody has opened since kickoff
- Unclear ownership, so tasks fall between people
- Decisions made in meetings but never written down
- A project manager stretched across too many projects to follow any of them closely
- Status based on opinions rather than data
- Problems hidden from stakeholders until they become crises
If you recognize your own project here, the fix is less dramatic than it sounds. Write a short plan for the remaining work, name one owner for every task, keep a decision log, and agree on a weekly status that uses actual numbers. If you have inherited a project in this state, say so to the sponsor in the first week and present the reset as part of taking over. Our introduction to project management covers the basics if you need a refresher on planning and roles.
When to stop a project instead of saving it
Not every troubled project should be rescued. Consider stopping when:
- The business reason for the project no longer exists, for example because the market or the client’s strategy changed.
- The cost of finishing is higher than the value the result will bring.
- The sponsor has left and nobody is willing to take ownership.
- Every recovery option still leaves an outcome nobody wants.
The money and time already spent should not decide the question, because they are gone either way. Ask only whether the remaining cost is worth the remaining benefit. If you stop, close the project properly: tell stakeholders and the team, hand over or archive what was built, settle contracts, and record why it ended. If you want to look at the broader reasons projects collapse, see why projects fail.
After the recovery: capture lessons learned
Whether the project was saved or stopped, take an hour with the team to review it while memories are fresh. Ask what happened, why, what you would do differently, and what you would repeat. Write the answers down in a shared place, tag them by project type, and read them at the start of the next similar project. A lessons learned document nobody can find is not worth the meeting it came from.
How to keep the next project from going wrong
The best recovery is the one you never need. Two habits help most.
Plan for problems before they happen
When you build the project plan, add a short list of what could go wrong. Brainstorm it with the team: anything that could block a task or move a date belongs on the list. For each likely problem, write down what you would do and who would do it, for example:
- Backup vendors or alternative sources for critical materials
- Named substitutes for key people in case of an emergency
- Shared online storage and backups so a broken laptop does not stop work
When one of these problems shows up, you already know the first move, and a potential emergency becomes a short interruption.
Monitor progress so delays show up early
Delays are easiest to fix when they are a few days old. Keep an eye on progress with a mix of:
- Regular meetings with individuals and with the whole team about task progress and overall project status
- Status reports that list completed tasks, current tasks and upcoming tasks, and flag whether each person is on track, at risk or behind
- Time tracking against tasks, so you can see where hours run over the estimate and who might need help
Our guide to project progress monitoring explains which numbers to watch.
Use actiTIME before project management goes wrong
Most of the steps above depend on knowing where the project stands, and that is the part actiTIME handles. Your team logs hours against tasks in a weekly timesheet, a calendar view or the mobile app, and each task can carry an estimate, a deadline, a priority and a workflow status.
- The Estimated vs. Actual Time report shows which tasks are running over, which gives you the facts for step 1 in minutes.
- Time, cost and billing budgets at the customer, project or task level show a progress bar that turns red once a budget is exceeded.
- The Cost of Work report shows hours and the related staff costs for each user, including overtime and leave.
- The Kanban board and workflow statuses show which tasks are stuck, and task comments keep decisions next to the work they affect.
Projects still go wrong with good data, but you find out sooner, while you still have options. Start a free 30-day trial, or book a demo if you want a walkthrough.
FAQ
What should you do first when a project goes wrong?
Get the facts before changing anything. Compare planned and actual dates, budget spent against work finished, and what remains. Then pause new scope requests and non critical work so the situation does not get worse while you plan the fix.
How do you handle problems in a project?
Decide first whether the problem affects the critical path or the budget. If it does not, note it and keep going. If it does, find the root cause, tell the stakeholders with options, agree on a change of scope, date or resources, and track the fix until it is closed.
How do you fix a failing project?
Stabilize it, find out why it is failing, and choose a recovery option with the sponsor: reduce scope, move the date, add resources, reorder work, or stop. Then build a new plan from the remaining work and monitor it weekly until it stays on track.
What is project mismanagement?
Project mismanagement is when the way a project is run causes its problems: no current plan, unclear ownership, undocumented decisions, status without data, or problems hidden from stakeholders. It is fixed with basic discipline: a plan for the remaining work, one owner per task, a decision log and weekly status based on numbers.
How do you tell a client that a project is in trouble?
Tell them early, in a meeting or call rather than buried in a report. Explain what happened, what it means for date and cost, and what you propose, with two or three options. Follow up in writing with the agreed next steps.
When should you cancel a project?
Cancel it when the reason for doing it no longer holds, when the cost of finishing exceeds the value of the result, or when no recovery option gives an outcome stakeholders want. Ignore the money already spent; only the remaining cost and benefit matter.
How do you keep projects from going wrong?
Agree on scope early, plan responses to the most likely problems, keep one owner per task, and track progress with real data such as hours against estimates. Problems are much cheaper to fix when they are a few days old than when they are a few weeks old.
