project-recovery
Skill0 starsChanged yesterdayMITView on GitHub
Get a late, over-budget or stuck project back under control: measure the real gap, find the causes, compare the recovery options (cut scope, move the date, add money or people, change the approach), choose with the decision owner, and announce a new credible plan. Use when a project is late, over budget, stuck, or when someone asks "how do we save this project?". Triggers: "project is late", "behind schedule", "over budget", "rescue the project", "projet en retard", "dépassement de budget", "sauver le projet", "le projet dérape", "proyecto retrasado", "fuera de presupuesto", "rescatar el proyecto".
In this repository15 other files it gives its agents.
- decision-makingSkill
- delegation-briefSkill
- meeting-toolkitSkill
- project-budgetSkill
- project-charterSkill
- project-scheduleSkill
- responsibility-matrixSkill
- retrospectiveSkill
- risk-registerSkill
- scope-changeSkill
- stakeholder-mapSkill
- status-updateSkill
- vendor-selectionSkill
- weekly-reviewSkill
- work-breakdownSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
When a milestone slipped or the budget is going beyond its reserve.
- Distinctive: line 21
When the people involved no longer believe the plan.
- Very specific: line 22
Not for a single new request that changes the scope: use scope-change.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project recovery
A late project rarely recovers by working harder on the same plan. This skill measures the real gap, finds why it happened, and puts honest options in front of the person who decides.
When to use
- When a milestone slipped or the budget is going beyond its reserve.
- When the people involved no longer believe the plan.
- Not for a single new request that changes the scope: use
scope-change.
Inputs
- The current plan, the budget and what has been done.
- The latest status (
status-update) and the risk register. - The fixed constraints: dates that cannot move, money that cannot grow.
Method
- Stop and measure: remaining work re-estimated from scratch by the people doing it, against the time and money left. No "we will catch up".
- Find the causes: underestimated work, scope that grew, missing people or skills, external delays, decisions that were not made. Ask "why" until the cause is something that can be acted on.
- List the options, usually a mix of: cut or postpone scope (deliver the essential first), move the date, add money, change the approach (simplify, buy instead of build, outsource), stop the project. Adding people late tends to slow work down in the short term, as Brooks observed for software teams: check whether the newcomers can be useful quickly.
- Compare them on time, cost, quality and risk (
decision-making), and recommend one. - Decide with the decision owner, then rebuild the schedule and the budget from the new baseline, with buffers.
- Announce it to everyone concerned: what happened, what changes, the new dates, and what is done so that it does not happen again (
stakeholder-map,status-update).
Output
### Recovery plan: <project> (<date>)
Gap: … days late, … over budget | Main causes: 1. … 2. …
| Option | New date | Extra cost | What we give up | Risk |
|---|---|---|---|---|
Recommendation: … | Decided by: … on <date>
New milestones: … | Message to the people involved: …Quality bar
- The remaining work is re-estimated, not assumed.
- Causes are named and acted on, not only symptoms.
- At least three options, including cutting scope and stopping.
- The new plan has buffers and is announced to everyone concerned.
- Written in the user's language, with the terms below.
Terminology
| English | Français | Español |
| Recovery plan | Plan de redressement | Plan de recuperación |
| Baseline | Référence, plan de base | Línea base |
| Root cause | Cause racine | Causa raíz |
| Scope cut | Réduction du périmètre | Reducción del alcance |
| Replanning | Replanification | Replanificación |
| Go or no-go | Décision de poursuivre ou non | Decisión de continuar o no |
Sources
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- Flyvbjerg, B., & Gardner, D. (2023). How Big Things Get Done. Currency.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.