14 KiB
name, description, license, compatibility, metadata
| name | description | license | compatibility | metadata | ||
|---|---|---|---|---|---|---|
| technical-program-management | Manage technical programs made of multiple related projects, products, teams, or vendors: establish the program mandate and benefits, align component work, manage cross-project dependencies and shared capacity, govern risks and decisions, coordinate transformation and adoption, and communicate program health to executives, delivery teams, and partners. Use when the work is a coordinated change larger than one project or when component projects are locally green but the combined outcome is at risk. Do not use for single-project control, detailed implementation planning, product portfolio or capital-allocation decisions, enterprise architecture design, release approval, or live incident command; route those to the named specialists. | MIT | Platform-agnostic methodology and Markdown templates. No runtime dependency. |
|
Technical Program Management
Program-level control can fail even when every component is on its own track. Use this skill to see and manage the seams, not to replace project managers or product governance.
First move: prove the program boundary
A program is not a larger project: it exists because coordination, shared constraints, or benefits across components require decisions that no component owner can make alone.
Read existing strategy, business case, component plans, dependency records, benefits assumptions, and recent status evidence before creating ceremony. Establish:
- the shared outcome and why the components belong together;
- the senior accountable owner and program decision rights;
- component projects/workstreams, owners, interfaces, and operational recipients;
- expected benefits, benefit owners, measures, baselines, timing, and disbenefits;
- shared capacity, funding, architecture, vendors, environments, and policy constraints;
- the current phase, critical decision, evidence gaps, and stop/revisit conditions.
If the work is one bounded project, route to technical-project-management. If the work is only a collection of unrelated investments, route to product-roadmapping-and-portfolio or strategy-frameworks.
Reference routing
Read only what the current decision requires:
| Situation | Read |
|---|---|
| Program mandate, component map, or shared constraints | Program brief template |
| Integrated status, dependency, risk, or recovery problem | Program control and troubleshooting |
| Benefits, governance, or evidence boundary | Research ledger |
| Benefits dependency mapping, tranche decisions, or disbenefits | Benefits dependency and tranche control |
| Adoption, operating-model change, or benefit drift | Benefits and transformation |
| Integrated control record needs filling | Integrated control template |
| Audience-specific status or decision update | Stakeholder update template |
| Independent assurance or troubled-program intervention | Assurance and intervention |
| One project needs detailed control | technical-project-management |
| Product portfolio or capital-allocation choice | product-roadmapping-and-portfolio or strategy-frameworks |
Routing to adjacent skills
- For a single bounded project's milestones, forecasts, dependencies, recovery, or closure, use technical-project-management.
- For product roadmap and portfolio sequencing, use product-roadmapping-and-portfolio.
- For recurring product decision rights and product governance, use product-operations-and-governance.
- For enterprise target-state architecture or architecture governance, use enterprise-architecture.
- For approved work breakdown and detailed rollout planning, use implementation-planning.
Program operating loop
- Mandate. Confirm the outcome, component boundaries, authority, funding horizon, success measures, and assumptions. Do not convert a strategic aspiration into an approved program without an accountable sponsor.
- Shape the architecture of work. Define component charters, interfaces, shared milestones, integration evidence, decision rights, and escalation paths. Preserve each component's appropriate delivery method; coordinate outcomes, not ceremonies.
- Build the integrated view. Maintain one program control record containing dependency health, integrated milestones, shared-capacity conflicts, benefits, risks/issues, decisions, forecasts, and changes. Link to component records rather than copying them.
- Manage the seams. Review cross-project dependencies by provider, receiver, definition of ready, acceptance evidence, needed-by date, fallback, and escalation owner. A component marked green does not make an unmet program dependency green.
- Steer by evidence. Compare actuals and forecasts with the program baseline and benefits hypothesis. Surface variance, confidence loss, benefit drift, and emerging disbenefits immediately. Missing evidence is unknown, not green.
- Make trade-offs. Present options across scope, sequence, capacity, funding, quality, risk, adoption, and benefits. A local optimization that harms the shared outcome is a program issue. Preserve history when the mandate or baseline changes.
- Realize and transition. Coordinate adoption, operating-model change, capability transfer, and benefits measurement. Use Benefits dependency and tranche control when components must produce a shared benefit in stages. Use Assurance and intervention when evidence, governance, or the integrated outcome is materially disputed or off track. Close or reshape the program only when the outcome decision, residual ownership, operational handoff, and benefits follow-up are explicit.
Method selection
Use the smallest adequate program model. Keep governance separate from component cadence.
| Conditions | Program pattern | First test |
|---|---|---|
| Stable outcome, fixed external gates, staged component delivery | Predictive/stage-governed program | Are component interfaces and decision gates feasible with real capacity? |
| Uncertain solution or benefits, learning must change the roadmap | Iterative/adaptive program | Is there an evidence checkpoint that can change funding or scope? |
| Many products or teams release increments into one capability | Incremental/release-train coordination | Is each increment usable and does integration evidence accumulate? |
| High dependency density and shared specialists | Flow/network coordination | Are dependency aging, capacity contention, and escalation visible? |
| Mixed hardware, software, vendor, regulatory, or organizational change | Hybrid program | Is one integrated decision view connecting the different cadences? |
Do not prescribe a branded method because the program uses multiple teams. Explain the trade-off, authority, cadence, evidence, and revisit trigger. A program manager coordinates; they do not acquire component owners' architecture, product, engineering, or risk-acceptance authority by tracking their work.
Communication contract
Tailor the same evidence to the stakeholder's decision:
- Sponsor/executive: outcome confidence, material variance, options, recommendation, decision required, latest useful decision date, and consequence of waiting.
- Component leads: dependency changes, interface acceptance, shared-capacity trade- offs, decisions needed, and what remains within their authority.
- Operations/adoption owners: capability readiness, training/process change, support model, adoption evidence, residual risk, and handoff date.
- Vendor/partner: provider and receiver obligations, definition of ready, evidence, commercial/technical constraint, escalation route, and next checkpoint.
- Affected users or customers: what changes, when, impact, support, uncertainty, and how feedback changes the plan. Do not publish internal risk detail that is not appropriate for the audience.
Never make a component dashboard, meeting count, or percentage complete stand in for program health. Report health by dimension: outcome, schedule, dependency, capacity, quality, adoption, benefits, and risk.
Troubleshooting patterns
- All projects green, program red: inspect integration, shared capacity, benefit ownership, and adoption; do not average component status.
- Dependency dispute: reconstruct the provider/receiver contract and evidence, then escalate the decision the local owners cannot make.
- Benefits are slipping while outputs ship: test the benefit hypothesis, adoption and operating assumptions, and disbenefits; re-scope or stop rather than declaring output delivery equal to value.
- Program has become a project list: restate the shared outcome, remove unrelated components, and route independent investments to portfolio governance.
- Sponsor changes direction midstream: preserve the original mandate and variance, record the new decision, assess component and benefit impacts, and rebaseline only with authority.
- Shared team is the bottleneck: show competing demand and consequences; do not promise that adding work or meetings creates capacity.
- Transformation resistance: identify affected roles, decision rights, incentives, training, feedback channels, and adoption signals. Route organizational design to org-design; keep program coordination here.
- No evidence after repeated reviews: stop after three non-converging diagnostic passes, name the missing evidence and decision owner, and escalate or pause.
Routing table
| Need | Route |
|---|---|
| One project's milestones, vendor handoff, forecast, recovery, or closure | technical-project-management |
| Approved requirement into work breakdown and rollout plan | implementation-planning |
| Product bets, roadmap sequencing, or portfolio allocation | product-roadmapping-and-portfolio |
| Product decision rights and recurring product governance | product-operations-and-governance |
| Enterprise capabilities, target/transition architecture, or architecture authority | enterprise-architecture |
| Technology adoption posture or standards governance | technology-radar |
| Release mechanics or launch authorization | release-engineering and production-readiness |
| Live outage or responder command | site-reliability-engineering |
| Capital allocation, corporate strategy, or M&A | strategy-frameworks |
| Organizational structure and talent design | org-design |
| Independent assurance or troubled-program intervention | Assurance and intervention |
| Post-delivery adoption evidence or benefits learning | product-adoption and product-lifecycle-learning |
Output contract and completion
Produce the smallest useful artifact: program brief, integrated dependency/control record, benefits map, governance decision, escalation brief, stakeholder update, recovery options, or transition/closure record. Separate evidence, inference, assumptions, commitments, options, and unknowns. Link to component sources and name owners rather than inventing agreement.
Complete when the requested program decision or artifact is delivered, the shared outcome and component boundaries are explicit, material dependencies and benefits have owners and review triggers, unresolved authority is escalated, and no claim exceeds the evidence. Do not imply ongoing monitoring without an authorized mechanism.
Research basis and limitations
This synthesis is informed by a deep, source-grounded research artifact retained with the development record, including PMI's The Standard for Program Management, Fifth Edition (2024), UK Government Project Delivery guidance, Local Government Association dependency guidance, and NASA risk management guidance. The deep run confirmed the value of benefits dependency mapping, tranches, disbenefits, enterprise risk categories, and independent assurance. It directly consulted three sources; the NASA handbook PDF and some UK pages remained inaccessible to the scraper, so claims requiring those exact documents are not presented as verified here. The sources provide principles and jurisdiction-specific requirements, not a universal operating model or proof that any method guarantees success. Use formal organizational or regulatory standards when they govern the actual program.