Written by Konda — Paddy & Water Inc. / Strategy

Diagnostic Checklist

Project Health Diagnostic Checklist — for PMO / Project Manager

July 2026

How to Use This Checklist

This checklist is a tool for project managers (PMs) and PMOs to systematically diagnose the “health” of an in-progress project. It can be used not only for the urgent assessment of a project that is already in trouble, but also as an early-warning diagnostic when something just feels “off.”

Severity	Meaning	Response Guidance
H (Red)	A risk that, if left unaddressed, will directly lead to project failure	Same-day response required. Consider escalation.
M (Orange)	A moderate risk that will worsen if left unaddressed	Formulate a response plan within one week
L (Green)	An item that would be good to improve, though not urgent	Add to improvement actions from next month onward

How to Calculate the Diagnostic Score

Step 1: Mark “☐” for every checklist item (check the items where “Yes = there is a problem”) Step 2: Count the severity of the checked items H: ____ items M: ____ items L: ____ items Step 3: Determine the severity level (use the severity matrix in Chapter 8) Step 4: Select a recovery plan (Chapter 9) Step 5: Determine whether escalation is needed (Chapter 10) * This checklist should be re-run periodically (monthly) to continuously monitor improvement progress.

Chapter 1: Definition of a Troubled Project and Early Warning Signs

1.1 What Is a “Troubled Project”?

A “troubled project” (sometimes called a project that is “on fire”) refers to a state in which multiple deviations from the plan occur together, making it significantly difficult to achieve the project’s objectives (scope, schedule, cost, and quality). Trouble does not appear suddenly — it surfaces as the result of multiple warning signs accumulating from an early stage. Whether the PMO/PM can read these warning signs early and take action determines whether the project succeeds or fails.

1.2 Early Warning Signs (Red Flags)

Check	Diagnostic Item	Severity
☐	The schedule delay exceeds two weeks, and there is no prospect of recovery	H
☐	The project manager is holding onto issues and risks alone, believing they can “solve it themselves”	H
☐	Reports to the steering committee are consistently “green (on track),” and issues are not being shared	H
☐	Team members are leaving one after another (or key personnel are hinting at taking leave or resigning)	H
☐	Requests to add scope (scope creep) are not being controlled	H
☐	The weekly status report keeps showing “no issues,” but the reality is different	M
☐	Decisions made in meetings are made after the fact, and what is decided is not being executed	M
☐	Progress is managed manually in tools such as Excel, and the actual status is unclear	M
☐	Team members have been in a state where “overtime is normal” for more than a month	M
☐	The same concerns are being raised repeatedly by the customer or stakeholders	M
☐	More than a month has passed since the project plan (WBS) was last updated	L
☐	The risk register is a mere formality and diverges from the actual risk situation	L

Chapter 2: Scope Diagnostics

2.1 Clarity of Scope Definition

Check	Diagnostic Item	Severity
☐	The project scope (what is in and out) is not documented, and stakeholders do not share a common understanding	H
☐	No agreement document on scope exists among stakeholders (e.g., a scope agreement or contract appendix)	H
☐	Scope keeps expanding on the assumption that “of course this is included” (scope creep)	H
☐	There is no scope change management process (or it is not functioning)	H
☐	The go-live date is fixed while scope cannot be reduced, resulting in an unreasonable schedule	H
☐	There is no prioritization of scope (e.g., MoSCoW analysis), and all features are being treated as equally high priority	M
☐	Additional requirements are approved verbally without going through the formal change process	M
☐	Development is proceeding while scope boundaries (e.g., the range of interfaces with other systems) remain undetermined	M
☐	A scope document exists, but the development team and business team interpret it differently	M
☐	The results of the fit-and-gap analysis are outdated and diverge from the design content	L

Key Focus Points for Scope Diagnostics

Ask not “has the scope been agreed?” but “can everyone draw the same picture of where the scope’s boundaries lie?” Try asking stakeholders, “Please name three things this project will NOT do.” If the answers vary widely, scope agreement has not actually been reached.

Chapter 3: Schedule Diagnostics

3.1 Planning Accuracy and Progress Management

Check	Diagnostic Item	Severity
☐	The critical path has not been identified, so it is unclear which delays would affect go-live	H
☐	There is zero schedule buffer, so a plan in which even a single day’s delay changes the go-live date	H
☐	It has become customary to treat “starting work” as equivalent to “progress,” with no definition of “done” (done criteria)	H
☐	Milestone completion criteria are vague, and whether something is “done” is judged subjectively	H
☐	There is no concrete recovery plan for making up lost time	H
☐	The WBS (work breakdown structure) is too coarse-grained to track progress on a weekly basis	M
☐	Dependencies (sequencing constraints between tasks) are not reflected in the WBS	M
☐	The baseline (planned values) has been changed, and the extent of deviation from the original plan is unclear	M
☐	Delays in external dependencies (customer deliverables, pending approvals) are not reflected in the schedule	M
☐	The schedule for testing, UAT, and user training keeps being compressed	M
☐	The Gantt chart is updated only once a month	L
☐	The aggregation of actual effort is left up to individual team members, and the PM has no visibility into it	L

Chapter 4: Resource and Organization Diagnostics

Check	Diagnostic Item	Severity
☐	The project manager holds concurrent responsibilities and cannot devote full attention to the project	H
☐	Commitment has not been obtained from key users or process owners in the business department	H
☐	Vendor/system integrator personnel change frequently, and handovers are inadequate	H
☐	A staffing plan exists but diverges significantly from actual assignments	H
☐	A skill gap (a shortage of personnel with the necessary expertise) is being left unaddressed	H
☐	There is no RACI chart (responsibility assignment matrix) needed for team decision-making	M
☐	The decision-maker (the business department’s responsible manager) does not attend meetings, causing decisions to be postponed	M
☐	Multiple vendors are involved, but there is no one to oversee and coordinate among them	M
☐	Onboarding for newly joined members (sharing project context) is inadequate	M
☐	There is only one technical key person, and the project would stop if that person left (a single point of failure)	M
☐	There are signs that team motivation and psychological safety are declining	M
☐	There is no plan for training or knowledge transfer	L
☐	Management of outsourced work is inadequate, and the outsourcing partner’s progress is opaque	L

Chapter 5: Quality and Deliverables Diagnostics

Check	Diagnostic Item	Severity
☐	Quality standards (What is 'Done'?) have not been defined, making it impossible to judge whether deliverables pass or fail	H
☐	The project is moving to the next phase with insufficient testing (defects are being left unresolved)	H
☐	The number of bugs and issues is trending upward, and the resolution pace is not keeping up	H
☐	Go-live decision criteria (Go/No-Go criteria) have not been defined	H
☐	User acceptance testing (UAT) has not been carried out, or there is an attempt to finish it as a mere formality	H
☐	Design documents and specifications diverge from the implementation (code/configuration) and have not been updated	M
☐	The review process is a formality, and reviews are not actually being conducted thoroughly	M
☐	Verification of non-functional requirements (performance, security, availability) is not included in the test plan	M
☐	Test data diverges from production data, reducing confidence in test results	M
☐	The deliverable approval process is lengthy, and rework occurs frequently	M
☐	Version control of deliverables is inconsistent, making it unclear which version is the latest	L
☐	Documentation quality standards (required items and format) are not standardized	L

Chapter 6: Stakeholder Diagnostics

Check	Diagnostic Item	Severity
☐	Management or the project sponsor is either indifferent to the project or excessively optimistic about it	H
☐	Customers or end users are not involved in the project, making it impossible to confirm requirements	H
☐	Multiple decision-makers (executives, department heads) have conflicting intentions, and the direction cannot be settled	H
☐	Problems are not being reported due to an unspoken assumption that “we must not let this project fail”	H
☐	Trust in the PMO has been lost, and the team has stopped disclosing information	H
☐	Important decisions are being made on the ground without going through the steering committee	M
☐	No communication plan exists, or it is not functioning	M
☐	Coordination with parties outside the project (other departments, related projects) is inadequate	M
☐	Change requests flow directly from the business department to the development team, uncontrolled	M
☐	No minutes or records of agreements are kept, leading to later disputes over “who said what”	M
☐	A stakeholder map (who supports and who resists) has not been organized	L
☐	There are many meetings without agendas or unnecessary meetings, and the team shows signs of meeting fatigue	L

Chapter 7: Risk and Issue Management Diagnostics

Check	Diagnostic Item	Severity
☐	No risk register exists, or it exists only as a formality and is not actually used	H
☐	Response strategies (avoid, mitigate, transfer, accept) for identified risks have not been determined	H
☐	Major issues are piling up without being closed	H
☐	A risk of cost overrun has been identified but has not been communicated to the sponsor	H
☐	Go-live is approaching while the post-project maintenance and operations structure remains undetermined	H
☐	A risk owner (who is responsible for addressing it) has not been assigned	M
☐	Changes in the external environment (regulatory changes, industry trends, supplier changes) are not recognized as risks	M
☐	There is no prioritization of issues, and all issues are managed as “urgent”	M
☐	Problems described as “unforeseen” occur frequently, indicating low accuracy in risk identification	M
☐	The review frequency for risks and issues is low (monthly or less), and responses tend to be delayed	M
☐	Failure cases from past, similar projects are not being used to identify risks	L
☐	The communication flow for when a risk occurs (the escalation path) is undefined	L

Chapter 8: Severity Assessment Matrix

8.1 Aggregating the Diagnostic Score

Tally the items checked in the Chapter 1 through Chapter 7 checklists, and use the matrix below to determine the project’s severity level.

Severity Level	Number of H (Red) Checks	Number of M (Orange) Checks	Assessment and Recommended Response
Critical	5 or more	No limit	Convene an emergency steering committee immediately. Request independent PMO intervention or outside support. Seriously consider postponing the go-live date.
Serious	3–4	5 or more	Introduce weekly executive reporting. Formulate a recovery plan (within two weeks). Provide focused support to the problem areas.
Warning	1–2	3–5	Strengthen monthly status reporting. Manage risks intensively (clarify risk owners). Conduct root-cause analysis of priority areas.
Minor	0	1–2	Handle through the normal change management process. Check progress at the next (monthly) review. Create an improvement action plan for L items.
Healthy	0	0	Maintain the good state. Continue re-running the checklist periodically. Consider sharing knowledge with other projects.

8.2 Area-by-Area Heat Map

Fill in the number of H items for each of the checklist’s seven areas in the table below to visualize weak areas. The area with the most H items is the top priority for recovery.

Diagnostic Area	Number of H Items (fill in)	Number of M Items (fill in)	Priority Assessment
Chapter 1: Early Warning Signs	____	____
Chapter 2: Scope	____	____
Chapter 3: Schedule	____	____
Chapter 4: Resources and Organization	____	____
Chapter 5: Quality and Deliverables	____	____
Chapter 6: Stakeholders	____	____
Chapter 7: Risk and Issue Management	____	____
Total	____	____	(Severity determined in Chapter 8)

Chapter 9: Recovery Plan Options

9.1 Recovery Options for the Critical Level

Recovery Option	Overview	Applicable Conditions	Risk
Scope reduction (phase split)	Move lower-priority features to a second phase while keeping the go-live date	Scope is prioritized, and stakeholders can agree to the split	If a critical feature is omitted, problems will occur after go-live
Postpone the go-live date	Redraw a realistic schedule and secure adequate testing time	The sponsor can approve the delay, and the business impact is within an acceptable range	Loss of business opportunity; accountability to management
Strengthen the project structure	Bring in outside support (consultants/specialists) and strengthen the PMO function	Additional budget approval can be obtained, and the necessary skills are lacking internally	Takes time to get up to speed; impact on the team
Interim rollout (avoid a big-bang launch)	Go live first at a subset of sites/features only, then expand the scope in stages	The system can support staged go-live, and running the legacy system in parallel is feasible	Dual-management cost; complexity during the parallel-run period
Suspend the project and replan	Organize the current situation and rebuild the plan from zero, prioritizing the root cause	There is a fundamental problem with the scope or architecture	Loss of stakeholder trust; the cost of replanning

9.2 Focused Measures for the Serious Level

How to Run a 30-Day Recovery Sprint

Week 1: Understand the current situation and identify priority issues ・Hold individual interviews with all team leads (get honest, candid input) ・Take a full inventory of issues, risks, and concerns (brainstorming format) ・Share the current status honestly with stakeholders (“here is what is actually happening”) Week 2: Root-cause analysis and response planning ・Select the 3–5 most critical issues (H items) and perform root-cause analysis (5 Whys) ・For each issue, decide “who,” “by when,” and “what will be done” ・Create a realistic replanning proposal for scope and schedule Week 3: Propose the replan to the steering committee ・Explain the current situation honestly (without sugarcoating) ・Present the risk scenario that “if things continue as they are, the project will fail” ・Present a comparison of the recommended recovery plan against alternatives ・Obtain a clear decision from the sponsor Week 4: Roll out the recovery plan and begin execution ・Roll out the agreed recovery plan to the team ・Strengthen weekly progress/issue reviews (report to the steering committee every week) ・Set improvement metrics (KPIs) and begin monitoring

Chapter 10: Escalation Decision Framework

10.1 Principles of Escalation

PMs tend to view escalation as “admitting failure,” but escalating at the right time is one of a PM’s most important responsibilities. Holding on to problems alone, believing “I can solve this myself,” is one of the biggest factors that lets a project spiral out of control. Organizations do not entrust PMs only with projects where every problem is something the PM alone can solve.

Escalation Trigger	Escalation Recipient	Timing
A scope change affects budget or schedule (e.g., additional requirements increase cost by more than 10%)	Project sponsor, steering committee	Same day it occurs
A determination is made that the go-live date needs to change	Sponsor, management	As soon as the determination is made, same day
Budget overrun becomes certain (e.g., CPI < 0.8 per EVM)	Sponsor, finance lead	Before the overrun is confirmed (at the earliest sign)
A major delivery delay from an external vendor (at a level that affects the project)	Vendor executives, internal procurement/legal	Within 48 hours of the delay being confirmed
A serious conflict among team members (at a level that affects the project)	Department head, HR	When it occurs
Security or compliance risk	CISO, legal, compliance	Same day it is discovered
A technical/architectural problem that affects whether the project can continue	Technical lead (CTO/EA), sponsor	Same day it is discovered

10.2 The “Seven Reporting Principles” for Escalation

The Seven Principles of Escalation Reporting That PMOs Should Practice

1. Facts first: Convey “what is happening” based on facts, without emotion Bad: “Everyone is working hard, but…” Good: “The number of completed tests is at 40% of plan, and this is affecting the go-live schedule” 2. Quantify the impact: Show “how serious this is” in terms of scope, days, or cost Bad: “This is a pretty bad situation” Good: “If this continues, the go-live date could slip by three months” 3. State the cause concisely: Summarize the root cause in one sentence using the 5W1H framework Good: “The main cause is a shortage of test staff (planned: 4, actual: 2)” 4. Have your own view: Always bring a recommendation as the PMO/PM Bad: “Please decide what we should do” Good: “I have prepared three options. I recommend Option B” 5. Ask for a decision: Do not stop at reporting — clearly state “what you would like approved” Good: “I would like to obtain approval for Option B here today” 6. Clarify the next action: State who will do what, and by when, once approval is given Good: “Once approved, we will roll this out to the entire team by tomorrow” 7. Keep a record: Always document the fact that the issue was escalated, and the resulting decision, in the meeting minutes

10.3 The Courage to “Say the Hard Thing”

Post-mortem analyses of troubled projects repeatedly show cases where “the PM recognized the problem early on but could not bring themselves to say it.” While raising the organization’s psychological safety is important, PMOs/PMs are also required to build, on their own initiative, a structure that makes it possible to say the hard thing. Securing regular “candid one-on-ones” with the people you would escalate to, and positioning problem reporting as “risk management” rather than “failure,” are the fundamental prescriptions for preventing projects from becoming troubled.

— End —