Technical Project Management
Help a team make and maintain credible delivery commitments. Start at the user's
current decision; do not restart a healthy project or impose a new methodology.
First move
Read existing project artifacts before asking questions. Identify the outcome,
current phase, immediate decision, decision-maker, constraints, and evidence gaps.
Infer experience from the request and artifacts; ask about preference only if it
matters. For teams without a PM, provide a small usable working system and explain
unfamiliar concepts in context. For experienced TPMs, lead with the delta, options,
recommendation, and decision needed; omit introductory lessons.
Choose the entry point
| Starting condition |
First action |
Primary output |
| New or inherited project with unclear mandate |
Read Engagement and initiation |
Proposed brief with authority and evidence gaps |
| Approved work with a delivery method but weak control |
Read Control and communication |
Current control record and decision brief |
| Slipping date, cost, scope, or dependency |
Read Forecasting and schedule analysis and Change and recovery |
Conditional forecast and recovery options |
| Cross-team, supplier, or mixed-method handoff |
Read Hybrid and dependencies |
Dependency agreement and acceptance evidence |
| Delivered work, retirement, or decommissioning with unresolved ownership or benefits |
Read Closure and transition |
Conditional closure, accepted transition, or decommissioning record |
| Technical uncertainty needs staged learning |
Read Adaptive delivery |
Evidence-backed decision among PoC, prototype, pilot, or stop; none alone proves production readiness |
| Forecast, deadline, or resource-feasibility question |
Read Forecasting and schedule analysis |
Conditional forecast stating model, assumptions, capacity, and feasibility limits |
| Material risk, issue, assumption, or decision needs control |
Read Control and communication |
Record with owner, signal/trigger, response, authority, and next review |
| A supplier or team handoff lacks readiness or acceptance evidence |
Read Hybrid and dependencies |
Agreement with provider, receiver, definition of ready, evidence, fallback, and escalation |
Do not call a desired date a commitment, a forecast an acceptance, or a diagnostic brief an approved plan.
Before proposing a commitment, identify who can authorize scope, dates, capacity, acceptance, and external communication. Mark each as accepted, proposed, unknown, or disputed. Read-only diagnosis may proceed; external updates require authorization.
Operating loop
- Establish mandate and authority; separate approved commitments, forecasts,
assumptions, and unknowns. A diagnostic or options brief can precede approval;
do not turn it into an approved implementation plan.
- Select the smallest adequate management approach. Preserve effective existing
practices and specify any changed decision rights, cadence, and handoffs.
- Reuse the implementation plan and maintain milestones, dependency commitments,
remaining work, resource availability, risks, issues, and decisions.
- Compare evidence with the baseline and tolerances. Investigate contradictions;
missing evidence means unknown, not green. Surface forecast changes immediately
when material; do not wait for a scheduled report.
- Present feasible options when scope, capacity, cost, or dates conflict. Keep the
baseline history; an authorized change is not permission to hide prior variance.
- Close only on acceptance and explicit residual ownership. Distinguish project
closure, release readiness, service operation, and later benefit realization.
Reference routing
Read only what the current task requires. Each reference includes applicability,
procedures, failure signals, and an observable exit.
A multi-project initiative with a shared outcome, cross-project dependencies, or
program-level benefits belongs to technical-program-management; a single bounded
project remains here.
| Decision phase / situation |
Read |
Exit artifact or evidence |
| New or inherited project, no PM, expert collaboration |
Engagement and initiation |
Proposed brief with mandate, authority, and evidence gaps |
| Choosing or questioning a methodology |
Method selection |
Approach decision with adaptations and revisit trigger |
| Predictive planning, stages, tolerances, fixed constraints |
Predictive and stage governance |
Baseline, tolerances, and gate evidence |
| Scrum, iteration, incremental delivery, discovery uncertainty |
Adaptive delivery |
Learning/increment evidence and inspect/adapt decision |
| Flow, shared specialists, critical chain, appetite-based work |
Flow and constrained capacity |
Capacity/WIP or appetite decision with owner |
| Mixed methods, cross-team or vendor interfaces |
Hybrid and dependencies |
Dependency agreement and interface acceptance evidence |
| Estimates, forecasts, budgets, schedule model |
Forecasting and schedule analysis |
Conditional forecast with assumptions and feasibility limits |
| Weekly control, stakeholder disagreement, escalations |
Control and communication |
Status/update or decision brief with next checkpoint |
| Scope changes, troubled projects, recovery |
Change and recovery |
Change/recovery record preserving the baseline |
| Acceptance, cancellation, operational handoff |
Closure and transition |
Closure or transition record with residual owners |
| Real examples or transferability checks |
Case studies |
Source-limited analogy, not a guarantee |
| Research provenance, edition, evidence limits |
Source index |
Traceable evidence ledger |
| Skill purpose, coverage, research decisions |
Research brief |
Coverage and limitation record |
| Validation scope and behavioral evaluation protocol |
Evaluation guide |
Reproducible evaluation record |
Templates and calculation
Adapt existing project documents rather than creating parallel sources of truth.
Use only artifacts that answer a current decision.
| Need |
Artifact |
| Establish mandate and working agreements |
Project brief |
| Explain method choice and adaptation |
Approach decision |
| Maintain milestones and evidence |
Project control record |
| Coordinate a supplier or receiving team |
Dependency agreement |
| Report a change and ask for a decision |
Status and decision brief |
| Assess scope changes or recovery options |
Change and recovery record |
| Accept, cancel, or transfer ownership |
Closure record |
| Calculate a small dependency network |
Example schedule |
Run python3 scripts/schedule.py --input templates/schedule-example.json --json
from this skill's directory when dependency arithmetic helps. Read forecasting
first: the result is an unconstrained earliest schedule, not a commitment or a
resource-leveled plan. The script only reads input and writes stdout/stderr.
Run python3 -m unittest discover -s scripts -p 'test_*.py' for its tests.
When not to use
Authority and completion
This methodology prepares decisions. It does not invent stakeholder consent,
assign accepted commitments on someone else's behalf, or approve risk. Updating
external project systems or sending communications changes external state:
Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation.
Apply existing session authorization; do not ask repeatedly for the same scope.
Destructive actions need an explicit directive. Keep prepared drafts visibly distinct
from issued communications. Do not monitor people or turn activity counts into
individual performance judgments.
Complete a requested management cycle when the artifact or update is delivered,
claims have evidence or explicit uncertainty, and unresolved decisions have an
accountable route and next review trigger. Do not imply ongoing monitoring without
an authorized mechanism. If three diagnostic passes yield no new evidence, stop
with the missing input and affected decision; do not manufacture certainty.
1---2name: technical-project-management3description: Manage technical projects from initiation through delivery and closure: choose and tailor predictive, iterative, Scrum, flow-based, or hybrid approaches; coordinate teams and vendors; track milestones, risks, issues, dependencies, forecasts, scope changes, and recovery. Use when a team has no project manager, a TPM needs decision-ready analysis, a project is slipping, or commitments and handoffs need coordination. Use `technical-program-management` instead when multiple related projects, teams, vendors, shared capacity, or benefits must be coordinated toward one outcome. Adapt depth to the user's expertise. Do not use for a standalone coding task, product discovery or strategy, only writing an implementation plan, only diagnosing Kanban flow, operating a ticket tool, incident command, or a release go/no-go decision; route those to specialists.4license: MIT5---67# Technical Project Management89Help a team make and maintain credible delivery commitments. Start at the user's10current decision; do not restart a healthy project or impose a new methodology.1112## First move1314Read existing project artifacts before asking questions. Identify the outcome,15current phase, immediate decision, decision-maker, constraints, and evidence gaps.16Infer experience from the request and artifacts; ask about preference only if it17matters. For teams without a PM, provide a small usable working system and explain18unfamiliar concepts in context. For experienced TPMs, lead with the delta, options,19recommendation, and decision needed; omit introductory lessons.2021### Choose the entry point2223| Starting condition | First action | Primary output |24|---|---|---|25| New or inherited project with unclear mandate | Read [Engagement and initiation](references/engagement-and-initiation.md) | Proposed brief with authority and evidence gaps |26| Approved work with a delivery method but weak control | Read [Control and communication](references/control-and-communication.md) | Current control record and decision brief |27| Slipping date, cost, scope, or dependency | Read [Forecasting and schedule analysis](references/forecasting.md) and [Change and recovery](references/change-and-recovery.md) | Conditional forecast and recovery options |28| Cross-team, supplier, or mixed-method handoff | Read [Hybrid and dependencies](references/hybrid-and-dependencies.md) | Dependency agreement and acceptance evidence |29| Delivered work, retirement, or decommissioning with unresolved ownership or benefits | Read [Closure and transition](references/closure-and-transition.md) | Conditional closure, accepted transition, or decommissioning record |30| Technical uncertainty needs staged learning | Read [Adaptive delivery](references/adaptive-delivery.md) | Evidence-backed decision among PoC, prototype, pilot, or stop; none alone proves production readiness |31| Forecast, deadline, or resource-feasibility question | Read [Forecasting and schedule analysis](references/forecasting.md) | Conditional forecast stating model, assumptions, capacity, and feasibility limits |32| Material risk, issue, assumption, or decision needs control | Read [Control and communication](references/control-and-communication.md) | Record with owner, signal/trigger, response, authority, and next review |33| A supplier or team handoff lacks readiness or acceptance evidence | Read [Hybrid and dependencies](references/hybrid-and-dependencies.md) | Agreement with provider, receiver, definition of ready, evidence, fallback, and escalation |3435Do not call a desired date a commitment, a forecast an acceptance, or a diagnostic brief an approved plan.3637> Before proposing a commitment, identify who can authorize scope, dates, capacity, acceptance, and external communication. Mark each as accepted, proposed, unknown, or disputed. Read-only diagnosis may proceed; external updates require authorization.3839## Operating loop40411. Establish mandate and authority; separate approved commitments, forecasts,42 assumptions, and unknowns. A diagnostic or options brief can precede approval;43 do not turn it into an approved implementation plan.442. Select the smallest adequate management approach. Preserve effective existing45 practices and specify any changed decision rights, cadence, and handoffs.463. Reuse the implementation plan and maintain milestones, dependency commitments,47 remaining work, resource availability, risks, issues, and decisions.484. Compare evidence with the baseline and tolerances. Investigate contradictions;49 missing evidence means unknown, not green. Surface forecast changes immediately50 when material; do not wait for a scheduled report.515. Present feasible options when scope, capacity, cost, or dates conflict. Keep the52 baseline history; an authorized change is not permission to hide prior variance.536. Close only on acceptance and explicit residual ownership. Distinguish project54 closure, release readiness, service operation, and later benefit realization.5556## Reference routing5758Read only what the current task requires. Each reference includes applicability,59procedures, failure signals, and an observable exit.6061A multi-project initiative with a shared outcome, cross-project dependencies, or62program-level benefits belongs to `technical-program-management`; a single bounded63project remains here.6465| Decision phase / situation | Read | Exit artifact or evidence |66|---|---|---|67| New or inherited project, no PM, expert collaboration | [Engagement and initiation](references/engagement-and-initiation.md) | Proposed brief with mandate, authority, and evidence gaps |68| Choosing or questioning a methodology | [Method selection](references/method-selection.md) | Approach decision with adaptations and revisit trigger |69| Predictive planning, stages, tolerances, fixed constraints | [Predictive and stage governance](references/predictive-and-stages.md) | Baseline, tolerances, and gate evidence |70| Scrum, iteration, incremental delivery, discovery uncertainty | [Adaptive delivery](references/adaptive-delivery.md) | Learning/increment evidence and inspect/adapt decision |71| Flow, shared specialists, critical chain, appetite-based work | [Flow and constrained capacity](references/flow-and-capacity.md) | Capacity/WIP or appetite decision with owner |72| Mixed methods, cross-team or vendor interfaces | [Hybrid and dependencies](references/hybrid-and-dependencies.md) | Dependency agreement and interface acceptance evidence |73| Estimates, forecasts, budgets, schedule model | [Forecasting and schedule analysis](references/forecasting.md) | Conditional forecast with assumptions and feasibility limits |74| Weekly control, stakeholder disagreement, escalations | [Control and communication](references/control-and-communication.md) | Status/update or decision brief with next checkpoint |75| Scope changes, troubled projects, recovery | [Change and recovery](references/change-and-recovery.md) | Change/recovery record preserving the baseline |76| Acceptance, cancellation, operational handoff | [Closure and transition](references/closure-and-transition.md) | Closure or transition record with residual owners |77| Real examples or transferability checks | [Case studies](references/case-studies.md) | Source-limited analogy, not a guarantee |78| Research provenance, edition, evidence limits | [Source index](references/source-index.md) | Traceable evidence ledger |79| Skill purpose, coverage, research decisions | [Research brief](references/research-brief.md) | Coverage and limitation record |80| Validation scope and behavioral evaluation protocol | [Evaluation guide](references/evaluation-guide.md) | Reproducible evaluation record |8182## Templates and calculation8384Adapt existing project documents rather than creating parallel sources of truth.85Use only artifacts that answer a current decision.8687| Need | Artifact |88|---|---|89| Establish mandate and working agreements | [Project brief](templates/project-brief.md) |90| Explain method choice and adaptation | [Approach decision](templates/approach-decision.md) |91| Maintain milestones and evidence | [Project control record](templates/project-control.md) |92| Coordinate a supplier or receiving team | [Dependency agreement](templates/dependency-agreement.md) |93| Report a change and ask for a decision | [Status and decision brief](templates/status-and-decision.md) |94| Assess scope changes or recovery options | [Change and recovery record](templates/change-and-recovery.md) |95| Accept, cancel, or transfer ownership | [Closure record](templates/closure-record.md) |96| Calculate a small dependency network | [Example schedule](templates/schedule-example.json) |9798Run `python3 scripts/schedule.py --input templates/schedule-example.json --json`99from this skill's directory when dependency arithmetic helps. Read forecasting100first: the result is an unconstrained earliest schedule, not a commitment or a101resource-leveled plan. The script only reads input and writes stdout/stderr.102Run `python3 -m unittest discover -s scripts -p 'test_*.py'` for its tests.103104## When not to use105106- A coding fix or architecture design: use the applicable engineering skill.107- Validating needs or choosing product investments: use108 [product-discovery](../product-discovery/SKILL.md) or109 [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md).110- Only decomposing an approved requirement: use111 [implementation-planning](../implementation-planning/SKILL.md).112- Detailed board, WIP, or service-flow diagnosis: use113 [kanban-guru](../kanban-guru/SKILL.md).114- Shaping a bounded product bet: use [product-shaping](../product-shaping/SKILL.md).115- Product-wide decision rights: use116 [product-operations-and-governance](../product-operations-and-governance/SKILL.md).117- Executive-office support: use118 [chief-of-staff-methodology](../chief-of-staff-methodology/SKILL.md).119- Release mechanics or launch approval: use120 [release-engineering](../release-engineering/SKILL.md) and121 [production-readiness](../production-readiness/SKILL.md). This skill may track project implications after that decision, but does not approve the release.122- Live incident command: use123 [site-reliability-engineering](../site-reliability-engineering/SKILL.md).124- Ticket operations alone: use [jira](../jira/SKILL.md) or125 [linear](../linear/SKILL.md). Use [financial-modeling](../financial-modeling/SKILL.md)126 for financial model construction, and [legal-strategy](../legal-strategy/SKILL.md)127 for contract interpretation.128129## Authority and completion130131This methodology prepares decisions. It does not invent stakeholder consent,132assign accepted commitments on someone else's behalf, or approve risk. Updating133external project systems or sending communications changes external state:134135> Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation.136137Apply existing session authorization; do not ask repeatedly for the same scope.138Destructive actions need an explicit directive. Keep prepared drafts visibly distinct139from issued communications. Do not monitor people or turn activity counts into140individual performance judgments.141142Complete a requested management cycle when the artifact or update is delivered,143claims have evidence or explicit uncertainty, and unresolved decisions have an144accountable route and next review trigger. Do not imply ongoing monitoring without145an authorized mechanism. If three diagnostic passes yield no new evidence, stop146with the missing input and affected decision; do not manufacture certainty.
magnus919