What Is Project Triage?

The short answer

Project triage is the fast, structured process of figuring out what's actually wrong with a struggling project, before you commit to a fix. It's not a status report and it's not a plan. It's the diagnostic step that has to happen first, because you can't fix what you haven't correctly identified.

The word comes from medicine for a reason. In an emergency room, triage isn't treatment. It's the rapid sort that decides what gets attention first and what can wait. Project triage does the same job for a project that's gone sideways: it separates the real problem from the noise around it, fast enough to be useful before the next meeting.

Two different things get called "project triage"

Worth clearing up early, because the term gets used for two jobs at very different altitudes.

Portfolio triage is the one you'll find in most project management literature. You have thirty projects and finite money, so you sort them into three piles: the ones running fine that need nothing, the ones to stop before they burn any more budget, and the ones that need intervention right now. It's a prioritisation exercise, usually run quarterly by a PMO or a steering group, and the output is a funding decision. Genuinely useful, but it operates on a spreadsheet of projects, not on any one of them.

Single-project triage is the other kind, and it's what the rest of this piece is about. One project is in trouble. You're the person who has to work out what's actually wrong with it, usually quickly, often having arrived mid-flight. Portfolio triage tells you this project needs intervention. It doesn't tell you what's broken inside it. That's a different diagnosis, and it's the one that decides whether the intervention works.

The two get conflated constantly, and the conflation costs people time: a steering group marks a project red, everyone agrees it needs help, and then the "help" arrives as more governance instead of a diagnosis. Knowing which job you're doing is most of the battle.

Why triage, specifically

Most struggling projects don't fail from a lack of effort. They fail because everyone in the room is solving a different problem, usually the loudest one (a missed deadline, an angry stakeholder, a scope argument) rather than the one underneath it. Triage exists to surface that underlying problem before more time gets spent on the symptom.

It matters most in one specific moment: when you're new to a project, or a project has just gone visibly wrong, and you have limited time before you have to say something intelligent about it. Nobody walks into a project mid-flight and understands it immediately. Triage is how you compress the "getting my head around this" phase from weeks into hours.

The seven questions that matter

A proper triage isn't a vague gut check. It's a specific set of questions, answered in order, because each one exposes something the last one couldn't.

1. What is the project supposed to deliver?

Not the task list. The actual deliverable, stated in one sentence. If you can't get a clean answer here, that's already the finding.

2. Who is the key stakeholder?

Every project answers to someone specific, even when it's been described as a team effort. Naming that person changes what "success" means.

3. Who is the team, and what are their blockers?

Capability and capacity are different problems with different fixes. This question tells you which one you're actually looking at.

4. What does the deadline look like?

Not just the date. Whether it's real, negotiable, contractual, or self-imposed. Deadlines carry very different weight depending on their source.

5. How is information flowing between the business and the team?

A huge share of "delivery" problems are actually communication problems wearing a delivery costume. This question finds them.

6. What does good look like?

If different people in the room would describe success differently, you've found the problem before you've even started triaging the delivery itself.

7. What happens if we stop this project tomorrow?

The most important question, asked last on purpose. Nobody's actually suggesting you stop, but the answer tells you what the project is really for: revenue, a regulatory deadline, a promise to a customer, or something nobody's said out loud yet. Everyone firefights the visible symptoms. This question puts the actual reason the project matters back in the room.

Answered honestly, those seven questions surface the real issue: not the one that's loudest, the one that's actually driving everything else.

Triage vs. a replan

These get confused constantly, and they're not the same job.

A replan assumes you already know what's wrong and just need a new schedule, new resourcing, or a new set of milestones to get there. It's a planning exercise.

Triage happens before that. It's diagnosis, not prescription. You don't replan a project until you know what actually broke, otherwise you're just building a more detailed version of the same mistake. Triage tells you whether you even need a replan, or whether the real issue is a stakeholder misalignment, a capability gap, or a "what does good look like" problem that no amount of rescheduling fixes.

Skip triage and go straight to replanning, and you risk producing a beautifully detailed plan for the wrong problem.

When it's already too late for triage

Triage is a first-hours tool, not a rescue tool. It's most useful in the window before positions have hardened: before the stakeholder has decided who's to blame, before the team has stopped raising blockers because nobody's listening, before "what does good look like" has quietly split into three incompatible answers that everyone's stopped questioning out loud.

Once a project is in that state, triage alone won't get you there. You need the harder, slower work of rebuilding trust and realigning people before any plan will stick. Triage is still worth doing at that point, because you still need the diagnosis. Just don't expect the seven questions alone to fix a project where the real problem is that nobody trusts each other anymore.

Try it

If you're new to a struggling project, or you're the one who has to explain what's actually going on before the next meeting, the project triage tool walks through these seven questions and produces a one-page brief you can take into the room. It won't do your thinking for you. It structures it, fast, so you walk in with the real problem instead of the loud one.

Steve Drew built the triage tool after years of walking into struggling projects mid-flight, as a contractor, and needing to get his head around them fast. Read why.