Project Health: How to Know If a Project Is in Trouble

Every project manager knows the feeling: the status report says “on track,” the team is busy, the dashboard is green — and then, without warning, the project is six weeks late and 20% over budget. The uncomfortable truth is that troubled projects rarely announce themselves. They send quiet signals for weeks or months first: a milestone that slips by two days and is never mentioned again, a stakeholder who stops answering emails, a scope change that was “just approved quickly,” a core team member who quietly checks out. By the time the project is visibly failing, most of the damage is already done.

This guide explains how to assess project health honestly — before a project gets to that point. You will learn what project health really means, how it differs from project status, the specific dimensions to check, the early-warning signs that predict trouble, how to run a health check, and the difference between a project that is delayed and one that is actually failing.

Quick Answer: How Do You Know If a Project Is in Trouble?

A project is in trouble when at least one of its core constraints — schedule, budget, scope, quality, or resources — is significantly off its baseline and the trend is getting worse, or when the team and stakeholders no longer believe the objectives can be met. The reliable way to know is not a gut feeling; it is a systematic health check that looks at lagging results (variance against plan) and leading signals (forecasts, risks, team morale) together.

The nuance that matters: trouble is a trajectory, not a snapshot. A project that is slightly behind schedule but has a clear corrective plan and healthy team morale is not necessarily in trouble — it is being managed. A project that is exactly on schedule but has lost its product owner, is hiding risks, and is consuming scope through uncontrolled changes is in deep trouble. Health is about whether you can still see a credible path to the objective, and whether the path is getting clearer or foggier.

What Is Project Health vs Project Status?

The direct answer: project status is a backward-looking report of where the project is right now against its plan; project health is a forward-looking judgment of whether the project can still reach its goals, including how it is trending and how capable the team and stakeholders are.

This distinction is the foundation of honest project management. A status report answers “where are we?” — percent complete, spend to date, milestones hit. A health assessment answers “can we still win, and what is in our way?”

The practical difference shows up in the RAG ratings. A project can be status-green (on schedule, on budget) and health-red at the same time: the schedule is fine today, but the only developer who understands the system just resigned, the sponsor has disengaged, and the requirements are shifting weekly. Conversely, a project can be status-amber (behind on a milestone) but health-green — the delay is understood, the corrective plan is funded, and the team is confident. Status tells you what happened; health tells you what is coming.

What Makes a Project Healthy? The Core Dimensions

The direct answer: a healthy project is one where schedule, cost, scope, quality, resources/team, and stakeholders/risk are all under control and trending positively — because each dimension can kill the project independently.

1. Schedule health

The project is producing value at the planned rate. Milestones are being hit or the delays are explained and corrected. The critical path is visible and actively managed, not discovered at the end. Watch for: repeated small slips, a widening gap between plan and actual, and “schedule games” where tasks are marked complete but the work is not actually done.

2. Cost health

Spend is tracking the value delivered — not just the calendar. Cost health is best measured with earned value (cost performance index and estimate at completion), because “we spent 40% of the budget by week 5” tells you nothing unless you also know how much value you got for it. Watch for: budget spend outrunning progress, unbudgeted scope entering without approval, and rising rework costs.

3. Scope health

The scope is defined, approved, and controlled. Changes go through a process that assesses cost and schedule impact before approval. Watch for: scope creep, requirements that keep “clarifying” into expansions, deliverables being added without re-planning, and stakeholder disagreement about what was promised.

4. Quality health

Deliverables meet the agreed standard the first time. Quality is a leading indicator of both schedule and cost trouble — when rework rises, schedule and cost will follow. Watch for: rising defect rates, growing rework effort, acceptance criteria that keep moving, and testers being squeezed to hit dates.

5. Resources and team health

The people doing the work are available, not overloaded, and still believe the project can succeed. This is the dimension managers most often skip, and it is the one that kills projects fastest when ignored. Watch for: key-person dependence, unplanned turnover, overloaded individuals, quiet disengagement, and people doing work outside their role for weeks.

6. Stakeholders and risk health

The sponsor is engaged, stakeholders agree on the objective, decisions get made, and risks are being actively managed. Watch for: an unresponsive sponsor, decisions that stall, stakeholders who want different outcomes, a shrinking risk register (nobody is finding new risks), and hidden problems being discovered late.

What Are the Early Warning Signs That a Project Is in Trouble?

The direct answer: the most reliable early warnings are behavioral and trend-based, not numbers: repeated small slips, growing rework, uncontrolled scope, team disengagement, stalled decisions, and hiding — and they usually appear weeks before the schedule or budget is visibly broken.

Here are the specific signs to watch, roughly in order of how early they appear:

• Repeated micro-slips. A milestone moves two days, then four, then a week. Each slip is small enough to skip reporting, but the trend is real. Add up the slips and you have a month.
• Percent complete stops making sense. Tasks sit at “90% complete” for weeks. That number is the classic symptom of work that is stuck and nobody wants to say so.
• Rework creeping up. The same deliverable gets redone, “just small fixes,” until the rework effort is larger than the original work.
• Scope entering without a paper trail. Changes are discussed in meetings and implemented without going through change control. The budget impact is invisible until it is not.
• The sponsor goes quiet. Meetings get cancelled, emails go unanswered, decisions stall. Disengagement is a leading indicator that the project’s value is being questioned — or already lost.
• Team disengagement. The people who used to flag risks have stopped. Attendance at stand-ups drops. The team has mentally checked out and is waiting for the project to be cancelled.
• Risk hiding. The risk register is not growing. No new risks are being found. That does not mean the project is safe — it means the team has stopped looking, or stopped speaking.
• Stakeholders disagree on the objective. If the question “what are we actually building and for whom?” gets different answers from different stakeholders, the project is not healthy no matter what the numbers say.

What Is the RAG System and How Do You Use It Honestly?

The direct answer: the RAG system is a traffic-light rating — red, amber, green — applied to each health dimension and to the project overall, and it only works if each color has a written definition and a trigger, so the rating is not a matter of opinion.

A workable definition set looks like this:

• Green: the dimension is within the agreed tolerance (e.g., schedule variance within 5%), trends are stable or improving, and no intervention is needed beyond normal management.
• Amber: the dimension is outside tolerance but a credible corrective plan exists, is resourced, and is being executed. Amber means “managed risk,” not “bad news coming.”
• Red: the dimension is materially off (e.g., >15% schedule or cost variance), or there is no credible corrective plan, or a critical factor (sponsor, key resource, requirement) has failed.

The honesty rules for RAG: a rating must be justified by data and a written trigger, not a personality. The PMO or a peer should challenge ratings rather than accept them at face value. And amber must not become the default comfortable color — if a project has been amber for three consecutive reviews, either the plan is not working or the rating is dishonest.

How Do You Run a Project Health Check? (Step by Step)

The direct answer: run a health check on a fixed cadence using a fixed set of questions, gather data from more than the status report, rate each dimension honestly, and end every check with a decision and an owner.

Step 1: Set the cadence

Active projects in execution: weekly or biweekly. Slow-moving, low-ambiguity projects: monthly. Critical phases (integration, testing, go-live): weekly or more. The cadence must be faster than the rate at which problems compound.

Step 2: Use a fixed question set

Ask the same questions every time, so trends are visible. A good starting set per dimension:

• Schedule: What did we plan to finish by now, what did we finish, and what is the trend in the gap?
• Cost: Are we spending faster than we are earning value? What is the forecast (EAC)?
• Scope: Did any scope enter without approval? Is the objective still unambiguous to all stakeholders?
• Quality: Is rework rising or falling? Are acceptance criteria stable?
• Resources: Who is overloaded? Is any critical role dependent on one person? How does the team feel about the project?
• Stakeholders and risk: Are decisions getting made on time? Is the sponsor engaged? What is the top new risk, and who owns it?

Step 3: Collect honest data

Do not rely only on the status report the PM wrote. Sample a few task-level records, check the actual schedule against the baseline, ask a couple of team members directly (outside meetings), and look at trend data rather than single snapshots.

Step 4: Rate, decide, and own

Assign a RAG rating per dimension with the trigger-based definitions, then for any amber or red rating define: the corrective action, its cost, the owner, and the review date. A health check that produces no decisions is a meeting, not a health check.

Step 5: Escalate deliberately

When a dimension goes red, escalate to the sponsor or steering committee with a clear framing: here is the problem, here is the root cause we have identified, here is the decision we need. Red is not a personal failure; hiding red is.

Scenario: The 95% Complete Software Build

A software project for a logistics company has been “on track” all quarter. The status dashboard is green: on schedule, within budget. Then the integration test reveals that the “90% complete” modules do not integrate, the delivery date moves from April to June, and the client’s legal review adds 40 days of unplanned work.

A health check that looked at more than the status report would have caught this earlier. The signals were all present in March: modules sitting at 90% for two weeks (a stuck-work pattern), integration tests being delayed “to save time,” and a known legal-review risk that was on the register but never given an owner or a date. The cost of the missed signals: a two-month delay and a client-facing crisis. A weekly health check with a fixed question set and a rule that any module over 90% for a week gets investigated would have surfaced the truth in March, when there was still time to act.

Scenario: The Unkillable Marketing Project

A corporate marketing project has grown from a “simple website refresh” into a 14-team cross-department program with no change control and a sponsor who approves everything. Health-wise, the schedule is green because the deadline keeps moving.

The health red flag here is objective clarity, not schedule. Stakeholders give three different answers to “what does success look like?” — one wants a lead-gen machine, one wants a brand page, one wants an e-commerce shop. No amount of on-time delivery fixes a project whose objective is disputed. The health check exposes it: the project is green on schedule, amber on scope, and red on stakeholder alignment. The decision that results is brutal but necessary — stop work for two weeks, get the leadership team in a room, and re-scope with a single agreed objective and a formal change control process. The project comes back smaller, slower to start, but healthy for the first time.

Scenario: The Quietly Exhausted Team

An agency is running an 8-week client project with a small team. All the numbers are green: milestones on time, budget fine. But the health check’s resource question — “who is overloaded?” — reveals that the lead designer is 120% utilized, the project’s only developer is covering a colleague on leave, and both have stopped volunteering information in stand-ups.

The manager treats team health as a leading indicator rather than a soft topic. The fix is concrete: pull a non-essential deliverable off the critical path, bring in a contract designer for two weeks (cost $4,000), and protect two focus blocks per week for the developer. The project finishes on time, and — importantly — the team does not. The lesson is that a project can be numerically green and still be one resignation away from red, which is why team health belongs in the health check, not just in the coffee chat.

What Tools Help You Track Project Health?

The direct answer: the tool matters less than the discipline, but project management platforms that combine live task data, baseline tracking, dashboards, and team load give you health signals without manual work.

Real options with honest trade-offs:

Jira. Pros: excellent trend data for agile teams — sprint burndowns, cumulative flow, cycle time — which are leading indicators. Cons: cost and budget tracking are weak natively, and health has to be assembled from custom dashboards. Good for software teams.

Asana. Pros: clean dashboards, workload view for resource health, easy adoption across non-technical teams. Cons: EVM-style cost health is not native. Good for marketing, operations, and general business projects.

Smartsheet. Pros: strong for PMO-style health reporting — status roll-ups, dashboards, and alerting across a portfolio. Cons: needs deliberate setup to reflect real-time data. Good for organizations that report health up to a PMO.

Microsoft Project. Pros: robust baseline and earned-value tracking for predictive projects. Cons: desktop-oriented, and health reporting is only as good as baseline discipline. Good for construction and engineering.

Power BI / Tableau. Pros: the best way to build a portfolio health dashboard pulling from many systems. Cons: needs maintenance and a data owner. Good for enterprise portfolios with many projects.

The pattern to avoid: buying a tool to automate a health process that does not exist yet. The health check — fixed questions, honest data, decisions with owners — is the process. Software then makes it cheaper to run.

To be transparent: Doitify is our product, which is why we know its capabilities from the inside. Its design maps directly onto this guide’s dimensions: Kanban boards, Gantt charts, sprints, task owners and due dates, quality control, resource and workload management, and work and performance reports give you schedule, cost, and team-load signals from live project data. If you are running this health-check process for a team of a few people, simpler tools are the honest starting point; for a team that wants health signals to update from the work itself, Doitify is worth evaluating.

Common Mistakes

The most common ways project health monitoring fails:

• Treating status as health. Reporting where the project is, without asking whether it can still reach its objective, turns the health check into a formality.
• Chasing green. Teams rate projects green to avoid uncomfortable conversations, and the rating becomes a negotiation instead of a fact. Trigger-based definitions help, but culture is the real fix.
• Trusting only the PM’s report. The PM is the most invested person in the project. Cross-check with task-level data, other team members, and stakeholders.
• Ignoring trends. A single amber month is a data point; three amber months is a problem. Review trend, not just snapshot.
• Skipping the team dimension. Resources and morale are treated as soft and skipped. They are the most predictive dimension there is.
• No decisions from the check. A health check that ends without an owner and a date for each action is a meeting that produced nothing.
• Changing the baseline to fix the color. Re-baselining is legitimate with approval; re-baselining to make a red project green without addressing root cause is how projects die quietly.
• Discovering problems at the gate. Health checks exist so that integration, testing, and delivery are not the first time the truth appears.

Know This Before You Choose

Before you commit to a health-monitoring approach, ask yourself:

• Do I know the difference between status (where we are) and health (can we still win), and is my reporting set up for both?
• Do my RAG colors have written triggers, or are they opinions?
• Do I cover all six dimensions — schedule, cost, scope, quality, resources/team, stakeholders/risk — or just the two that are easy?
• Do I have leading indicators (trends, forecasts, morale, risk) or only lagging ones (variance)?
• Do I have a fixed question set and cadence, or does the check happen “when someone worries”?
• Who challenges my ratings? If nobody, my ratings are only as honest as I am on that day.
• Does my tool surface health from live work, or will I be manually assembling it?
• When a dimension is red, is there a defined escalation path to the sponsor?

Conclusion

You know a project is in trouble long before the schedule explodes — the problem is that nobody is looking at the right signals. The fix is not a new tool; it is a discipline: define health as a forward-looking, multidimensional judgment rather than a status report; rate six dimensions (schedule, cost, scope, quality, resources/team, stakeholders/risk) against written triggers; watch leading indicators like trends, rework, morale, and risk; and run a fixed health-check ritual that ends in decisions with owners.

Start this week. Write your six-dimension question set, assign RAG triggers, and run the first check — not on your most obvious problem project, but on the one that looks healthiest. That is where the surprises hide. A project that is assessed honestly, early, and continuously is a project that can be steered. The alternative is finding out in the integration test, at the go-live, or from the client — and by then, health was never the issue; the issue was not looking.