Project Rescue

Find where the project is actually breaking. Fix the system, not just the incident.

Project Rescue is an AI-powered software project diagnosis and recovery system built for Technical Program Managers (TPMs), Project Managers, Product Managers, founders, and technology leaders.

Use it when a software, SaaS, or technology project feels off-track, a deadline is under pressure, the team knows something is wrong but cannot clearly explain why, or you want to identify risks before they become serious delivery problems.

Unlike a generic project-management assistant, Project Rescue is designed to separate symptoms from root causes, identify the few blockers that actually matter, challenge unrealistic assumptions, test deadline realism, and turn messy project information into an executable recovery plan.

What Project Rescue Can Do

Diagnose troubled projects

Provide whatever project information you currently have, including:

• project status
• deadline and timeline
• Jira or task summaries
• sprint history
• completed vs. remaining work
• QA and testing status
• bug lists
• dependencies and blockers
• team structure and capacity
• scope changes
• stakeholder commitments
• customer feedback
• adoption or usage signals
• meeting notes
• free-form descriptions of what feels wrong

You do not need to complete a rigid questionnaire.

Project Rescue first analyzes the information already available, identifies what can and cannot be concluded, and asks only the most important missing questions when additional evidence is required.

Core Analysis

Project Rescue evaluates the project across relevant dimensions such as:

• Schedule
• Scope
• Team & Capacity
• Workflow / Process
• Quality & Testing
• Dependencies
• Technical Risk
• Stakeholder Alignment
• Communication
• Product / Customer Value

It separates:

Facts
from
assumptions, opinions, unknowns, and inferences.

This helps prevent executive optimism, team perceptions, or incomplete information from being treated as established facts.

Follow the Bottleneck, Not the Blame

Project problems often become visible around a particular person, role, or handoff.

For example:

"QA is always too slow."

Project Rescue does not automatically conclude that QA is the problem.

It traces the workflow:

Development → Handoff → QA → Rework → Regression → Release

The visible QA bottleneck may actually be caused by:

• developers delivering work in large batches
• unclear acceptance criteria
• excessive rework
• poor upstream quality
• capacity imbalance
• incomplete requirements
• weak handoff rules

People are useful signals, but they are not automatically the root cause.

Deadline Reality Check

Project Rescue does not hide bad news behind vague language.

It classifies the current deadline as:

• REALISTIC
• AT RISK
• UNREALISTIC UNDER CURRENT CONDITIONS
• CANNOT DETERMINE — INSUFFICIENT EVIDENCE

If the current deadline is unrealistic, Project Rescue explains why and identifies which constraints must change.

Possible recovery levers include:

• reducing scope
• moving the deadline
• reallocating resources
• changing implementation strategy
• resolving or replacing dependencies
• phased rollout
• feature flags
• prioritizing critical-path testing
• freezing requirements
• improving acceptance criteria
• changing handoff processes
• clarifying ownership
• team or role-specific training
• escalating critical decisions

Fix the System, Not Just the Incident

Project Rescue does not stop at:

"How do we survive this release?"

It also looks for structural conditions that may cause the same failure again.

Examples include:

• unclear ownership
• inconsistent Definition of Done
• weak Acceptance Criteria
• poor QA entry/exit criteria
• excessive work in progress
• single points of failure
• lack of backup ownership
• poor escalation processes
• misaligned incentives
• weak communication
• inconsistent workflow execution

A good recovery plan should solve today's problem while reducing the chance of the same problem returning.

Product and Customer Reality Check

Sometimes the biggest project risk is not software execution.

The project may be technically successful while solving a problem customers do not consider urgent enough to adopt or pay for.

Project Rescue can identify signs such as:

• weak customer adoption
• low repeat usage
• little willingness to pay
• positive feedback without behavioral evidence
• internal enthusiasm that exceeds customer urgency
• continued feature development without stronger market validation

When supported by the evidence, Project Rescue can recommend:

• CONTINUE
• CONTINUE WITH CHANGES
• PAUSE
• FREEZE
• PIVOT
• STOP

The objective is not to protect the original plan.

The objective is to protect the outcome.

Default Output

A normal Project Rescue analysis contains eight modules:

1. Executive Diagnosis

A direct assessment of the project's current condition and the most important management implication.

2. Facts / Assumptions / Unknowns

Separates what is known from what still requires evidence.

3. Project Health Map

Evaluates the relevant project dimensions and highlights Red, Yellow, Green, or Unknown areas.

4. Critical Path & True Blockers

Identifies the few conditions most likely to determine whether the project succeeds or fails.

5. Root Cause Analysis

Separates visible symptoms from immediate causes, contributing conditions, and likely root causes.

6. Recovery Scenarios + Trade-offs

Provides multiple realistic recovery paths and explains the impact on scope, deadline, quality, resources, and risk.

7. Recommended Action Plan

Prioritizes concrete actions for:

• the next 24 hours
• the next 7 days
• the next release or major project gate

8. Deadline Reality Check

Provides a clear conclusion about whether the current delivery commitment is realistic.

Example Input

We have a software release in 8 working days. The team has 8 developers, 1 QA, and 1 PM. Developers say they are almost finished, but QA currently has 31 tickets waiting and many tickets are being returned for rework. I feel like QA is too slow. We still need regression testing before release. Diagnose what may actually be going wrong and tell me whether the deadline is realistic.

Example Analysis Direction

Project Rescue may determine that QA is the visible bottleneck but not necessarily the root cause.

It may investigate:

• developer-to-QA batching
• QA capacity
• rework rate
• missing Acceptance Criteria
• remaining critical development
• regression-testing requirements
• release-critical vs. non-critical scope

Instead of simply saying "add another QA engineer," Project Rescue may recommend a combination of scope prioritization, smaller handoffs, improved acceptance criteria, queue triage, and a revised release strategy.

Early Warning Mode

Project Rescue can also be used before a project officially fails.

For example:

We are technically still on schedule, but work has been carrying over for the last two sprints, Product keeps adding small requirements, and integration testing has not started.

Project Rescue can identify the likely failure path, recommend preventive actions, and explain what evidence should be monitored before the risk becomes critical.

Methodology-Neutral

Project Rescue does not force every team to use Scrum.

It adapts to:

• Scrum
• Kanban
• Waterfall
• Hybrid delivery models
• custom software development workflows

The methodology is a tool.

The goal is successful delivery and sound decision-making.

Core Principles

Evidence over optimism.

People are signals, not automatic culprits.

Follow the bottleneck, not the blame.

Fix the system, not just the incident.

Protect the outcome, not the original plan.

Important Notes

Project Rescue is designed primarily for software, SaaS, and technology projects.

For best results, provide as much relevant context as reasonably available while avoiding unnecessary confidential information.

Do not provide passwords, API keys, authentication tokens, private keys, credentials, or production secrets.

When possible, anonymize confidential client or employee information that is not necessary for the project analysis.