Files
Magnus HedemarkandGitHub 22d141de75 feat: add research-grounded technical project management skill (#468)
* feat: add research-grounded technical project management skill

* test: retain isolated project coordination regression evidence
2026-09-04 23:56:40 -04:00

57 lines
3.5 KiB
Markdown

# Change control and troubled-project recovery
Use for scope additions, missed milestones, lost sponsors, unreliable plans, or
repeated surprises. S07 distinguishes issues from changes; C01/C02 show why
requirements and oversight deserve scrutiny. The recovery sequence is synthesis.
## Handle a proposed change
1. Capture source, reason, urgency, and outcome sought. Identify whether this is
clarification, defect correction, new scope, or a proposed baseline change.
2. Compare the accepted scope and acceptance criteria. A defect may consume capacity
without being new scope; it still affects the forecast.
3. Obtain technical impact from relevant owners. Assess scope, schedule, cost,
quality, risk, dependencies, operations, and benefits.
4. Present accept, reject, defer, and swap-scope options where feasible. Show the
impact of doing nothing. Do not assume every dimension can remain fixed.
5. Route to the authority matching the affected tolerance. Record their decision.
6. If approved, version the baseline and notify affected parties within authorized
scope. Keep the prior baseline and reason; update forecasts and handoffs together.
Pre-approval analysis is allowed. Treat estimates as conditional; do not commit
another team's capacity or begin dependent execution merely because an option exists.
## Recover a troubled project
Start with a bounded diagnostic, not a ceremony overhaul. Agree the decision horizon
and preserve the record of what was previously promised.
- Reconstruct accepted scope, actual deliverables, remaining work, funding, and
critical dependencies from evidence. Treat percentages without evidence as claims.
- Identify the limiting condition: unclear outcome, technical uncertainty, resource
contention, supplier failure, missing authority, or quality/rework.
- Protect essential work while evaluating reversible changes. An active incident
goes to incident command; this skill manages the subsequent project implications.
- Compare recovery choices: reduce scope, resequence, add a genuinely useful
capability, move date, stage delivery, pause, or stop. Adding people has onboarding
and coordination cost; overtime is not automatically feasible or sustainable.
- Get explicit acceptance for the chosen path and its residual risks. Publish a
revised forecast immediately, even if baseline authorization is still pending.
- Verify recovery at a short evidence checkpoint. A newly green report is not
evidence that the underlying constraint was removed.
## Hard cases
| Condition | Required response |
|---|---|
| Sponsor insists on same scope/date/cost despite infeasibility | State conflict, assumptions and consequences; seek authorized tradeoff, do not fabricate a compliant plan |
| Sponsor leaves | Identify interim authority; preserve commitments and escalate decisions that cannot wait |
| Vendor conceals progress | Request acceptance evidence and contract-authorized remedies through procurement/legal |
| Risk acceptance requested without technical review | Obtain specialist evidence; a PM status decision cannot waive reserved approval |
| Team proposes deleting the old baseline | Retain history; distinguish revised plan from original performance |
| Requirements are not approved | Produce diagnosis/options; route formal implementation planning upstream rather than bypass its gate |
Complete when a recovery/change decision is supported by evidence and authority,
or when the exact blocked decision and missing input are reported. Stop after
three non-converging diagnostic passes; do not cycle through frameworks indefinitely.