{
  "schema_version": 1,
  "skill_name": "technical-program-management",
  "evals": [
    {"id":"program-mandate","prompt":"Four related platform projects are underway, but nobody can explain the shared outcome, authority, or why they belong together. Establish the smallest useful program mandate.","expected_output":"A program brief that defines shared outcome, authorization, sponsor, component boundaries, decision rights, and evidence gaps without inventing approval.","assertions":["States a shared outcome and coordination rationale.","Names missing sponsor/authorization as unknown rather than inventing it.","Lists components, owners, interfaces, and decision rights.","Separates proposed brief from approved program."]},
    {"id":"component-alignment","prompt":"Two component projects have different delivery methods and calendars. One wants to force the other into its sprint cadence. Advise the program manager.","expected_output":"A coordination model that preserves suitable component methods while aligning shared outcomes, milestones, interfaces, and evidence.","assertions":["Does not force one cadence without a demonstrated need.","Defines integrated milestones and interface evidence.","Preserves component decision rights.","Names a revisit trigger."]},
    {"id":"dependency-conflict","prompt":"Project A says its API is complete. Project B cannot integrate it because the schema is still changing and the test environment is unavailable. Prepare the program response.","expected_output":"A provider/receiver dependency decision with ready definition, acceptance evidence, impact, fallback, and escalation.","assertions":["Separates component completion from usable handoff.","Names provider, receiver, ready criteria, and evidence.","Shows program impact and fallback.","Escalates only the unresolved authority decision."]},
    {"id":"shared-capacity","prompt":"Three projects all need the same security architect in the next month, and each project claims its date is fixed. Give the sponsor a decision brief.","expected_output":"Options showing capacity conflict, consequences, sequencing or scope/date alternatives, and sponsor authority.","assertions":["States the shared-capacity conflict.","Does not promise capacity without a decision.","Provides at least two feasible options and consequences.","Preserves current commitments until authorized change."]},
    {"id":"benefit-drift","prompt":"All component projects delivered their outputs, but customer adoption is flat and operating costs are higher than expected. How should the program respond?","expected_output":"A benefits/disbenefits review that tests the causal chain, names owners and measures, and offers reshape, continue, or stop options.","assertions":["Does not equate output delivery with benefits realization.","Identifies adoption and cost evidence gaps.","Names benefit/disbenefit owners, measures, and review triggers.","Offers a decision beyond simply declaring success."]},
    {"id":"benefits-dependency-tranche","prompt":"A platform program can release a useful capability after three of five component projects, but the remaining projects carry adoption and operational dependencies. Build a tranche decision.","expected_output":"A benefits dependency map and tranche record connecting capability, operational change, behavior, benefit/disbenefit, evidence, exit choice, and next-tranche conditions.","assertions":["Distinguishes capability output from benefit.","Maps at least one operational/adoption dependency.","Defines entry and exit evidence for the tranche.","Preserves mandatory safety/security/release gates."]},
    {"id":"governance-escalation","prompt":"The program team is deadlocked over a cross-project architecture decision, and no role has authority to resolve it. What do you do?","expected_output":"An escalation record and bounded decision path, not an invented technical decision.","assertions":["Names the missing or contested authority.","Defines evidence and options for escalation.","Records impact of waiting.","Does not silently decide outside authority."]},
    {"id":"stakeholder-communication","prompt":"Write three versions of this update: one for the executive sponsor, one for component leads, and one for operations. The program is on schedule, but integration confidence is falling.","expected_output":"Audience-specific updates preserving the same evidence and decision need.","assertions":["Executive version leads with outcome confidence, impact, options, and decision date.","Component version names interfaces, actions, and authority boundaries.","Operations version names readiness, support, adoption, and residual risks.","None claims an unqualified green status."]},
    {"id":"troubled-recovery","prompt":"The program has missed two integrated milestones. Component teams want to add more work and meetings, while the sponsor wants the old date preserved. Prepare a recovery approach.","expected_output":"A bounded diagnostic and trade-off brief preserving history and identifying the limiting constraint.","assertions":["Preserves original mandate, commitments, and variance.","Diagnoses dependency, capacity, scope, quality, and authority causes.","Provides scope/date/sequence/capacity/pause/stop options.","Defines an evidence checkpoint and escalation path."]},
    {"id":"assurance-review","prompt":"A high-consequence program has conflicting green reports, unowned benefits, and a major funding decision next month. Define an independent assurance review.","expected_output":"A scoped assurance record with reviewer independence, evidence domains, findings/limitations, sponsor decision, conditions, and next checkpoint.","assertions":["Separates assurance from delivery ownership.","Inspects mandate, dependencies, forecasts, risks, benefits, and operational readiness.","Records evidence and limitations rather than asserting certainty.","Leaves decision authority with the sponsor or authorized governance body."]},
    {"id":"transformation-adoption","prompt":"A platform program is technically ready, but regional operations teams are not changing their processes. Build the next program decision.","expected_output":"A change/adoption response connecting affected roles, operating model, training, feedback, measures, and ownership.","assertions":["Treats adoption as part of program outcome, not a postscript.","Names affected groups and change/adoption owners.","Defines measurable signals and feedback channels.","Routes organizational structure questions to org-design when appropriate."]},
    {"id":"method-selection","prompt":"A program combines a regulated hardware migration, uncertain software integration, and a vendor transition. Select and tailor a program approach.","expected_output":"A hybrid program pattern with separate component cadences and one integrated decision/evidence view.","assertions":["Selects hybrid based on diagnosed conditions.","Separates mandatory gates from iterative learning.","Defines shared milestones/interfaces and review trigger.","Avoids claiming a method guarantees success."]},
    {"id":"project-routing","prompt":"I need to review one project's forecast, vendor handoff, and closure evidence, not coordinate a wider initiative. Which skill should I use?","expected_output":"Routes to technical-project-management and explains the program-level boundary.","assertions":["Routes single-project control to technical-project-management.","Does not answer as if a program is required.","Explains the boundary briefly and accurately."]},
    {"id":"portfolio-routing","prompt":"Which three investments should the company fund next quarter, and should we shut down the lowest-return one?","expected_output":"Routes capital allocation and portfolio choice to the appropriate portfolio/strategy skill.","assertions":["Routes to product-roadmapping-and-portfolio or strategy-frameworks based on context.","Does not invent a program mandate.","Distinguishes portfolio selection from program coordination."]}
  ]
}

# Program assurance and intervention

**Applicability:** Load when a program is high-consequence, materially off-track, disputed, or approaching a major tranche, transition, or funding decision.

## Assurance is independent of delivery

Assurance asks whether the program's evidence, governance, forecasts, dependencies, and benefits case are credible. It is not a status meeting and should not be performed only by the team seeking approval. Define the assurance scope, reviewer independence, evidence requested, decision to inform, and response owner. Independence is a control boundary, not a claim that an external review is automatically correct.

At a proportionate checkpoint, inspect:

- mandate, authority, funding, and continued justification;
- component scope, integrated architecture/dependencies, and shared capacity;
- actual progress and forecast logic, including contradictory status;
- technical, security, safety, compliance, supplier, and operational readiness evidence;
- benefit dependency map, adoption signals, disbenefits, and measurement ownership;
- open risks/issues, decision latency, escalation history, and residual obligations.

Record findings as evidence, interpretation, limitation, recommendation, owner, and due date. The program sponsor decides whether to accept risk or change the mandate; an assurance reviewer does not silently become the decision-maker.

## Troubled-program intervention

Trigger a bounded intervention when integrated outcomes breach tolerance, critical dependencies lack credible recovery, benefits assumptions fail, authority is absent, or repeated reports conflict with observable evidence. Freeze neither all work nor the historical record by default.

1. Name the intervention sponsor and decision horizon.
2. Preserve the original mandate, baselines, commitments, and variance.
3. Reconstruct components, dependencies, capacity, funding, benefits, and evidence gaps.
4. Identify the limiting constraint and distinguish symptoms from causes.
5. Present recovery, reshape, pause, transfer, or stop options with consequences.
6. Obtain an authorized decision and record residual risks and conditions.
7. Recheck at a dated or event-triggered evidence checkpoint. Rebaseline only when authorized.

If three diagnostic passes produce no new evidence, stop and escalate the missing input and affected decision. Do not convert assurance into ceremony or use a new dashboard to disguise an unchanged constraint.

## Boundaries

Route detailed project recovery to [technical-project-management](../technical-project-management/SKILL.md), release evidence to [production-readiness](../production-readiness/SKILL.md), live incidents to [site-reliability-engineering](../site-reliability-engineering/SKILL.md), and organizational design to [org-design](../org-design/SKILL.md). This skill coordinates program-level intervention and assurance inputs across them.

# Benefits and transformation

**Applicability:** Load when the program's value depends on adoption, operating-model change, capability transfer, or outcomes after component delivery.

## Benefits map

Trace each benefit through the chain:

`component capability -> changed behavior/process -> measurable outcome -> accountable benefit owner`

For each benefit, record the baseline, target, timing, data source, confidence, dependencies, disbenefits, and the decision triggered by missing or adverse evidence. A delivery team may own a capability; it does not automatically own the benefit.

## Failure signals

- Outputs are complete but behavior has not changed.
- Adoption is concentrated in an easy early cohort and absent in the target population.
- The benefit depends on a policy, process, incentive, or training change outside the delivery teams' authority.
- Costs, workload, risk, or service degradation rise while the headline benefit improves.
- Nobody can name who will measure the benefit after the program closes.

## Work through the problem

1. Reconfirm the outcome and beneficiary, then test whether the component outputs are necessary and sufficient.
2. Segment adoption and affected groups. Identify workflow, role, incentive, training, support, and policy barriers.
3. Establish a measurement baseline and a review interval. Separate observed results from attribution assumptions.
4. Give the benefit owner options: change the operating model, adjust adoption support, reshape scope, extend learning, accept a disbenefit, or stop.
5. Transfer ongoing measurement and action to an accepted operational or product owner, with a date or trigger for review.

Do not keep the entire program open indefinitely because outcomes mature later. Close only when the receiving ownership and benefits review are explicit. Do not declare benefits realized because a component shipped or because activity increased.

## Boundaries

Route product adoption measurement to [product-adoption](../product-adoption/SKILL.md), outcome instrumentation to [product-analytics-and-measurement](../product-analytics-and-measurement/SKILL.md), organizational structure and talent design to [org-design](../org-design/SKILL.md), and standalone strategic investment choices to [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) or [strategy-frameworks](../strategy-frameworks/SKILL.md). This skill coordinates the program-level change and handoffs among them.

# Benefits dependency and tranche control

**Applicability:** Load when a program's value depends on several components, changed behavior, staged releases, or benefits that mature after delivery.

## Benefits dependency map

A benefit is not a feature and a component output is not a benefit. Map the causal chain:

`program capability -> required operational change -> changed behavior -> benefit or disbenefit -> measure`

For each link record its owner, evidence, assumption, dependency, timing, and failure consequence. Mark links as observed, inferred, asserted, or committed. A benefit with no accountable owner, baseline, data source, or review trigger is an unvalidated hypothesis.

Check whether the components are jointly necessary, whether another dependency is required, and whether one component creates a disbenefit for another stakeholder. Do not count activity, adoption, or delivery percentages as benefits without a causal and measurement argument.

## Tranche and release decisions

Use tranches when the program can deliver a useful capability or learn enough to change the next investment decision before every component is complete. Each tranche needs:

- a bounded capability and intended benefit;
- entry evidence and a named decision owner;
- integration, operational, adoption, and safety evidence;
- a benefit hypothesis and early signal;
- exit choices: continue, reshape, pause, stop, or transfer;
- dependencies and conditions for the next tranche.

A tranche is not permission to weaken mandatory approval, security, safety, or release gates. Coordinate tranche timing with component projects, but do not force every component into the same cadence.

## Benefit drift and disbenefits

Review expected versus observed outcomes at the program level. If an output ships but the benefit does not move, test the missing link: adoption, process, incentive, data, capability, operating ownership, or the original causal assumption. Track negative consequences such as workload, cost, service degradation, control burden, or displacement of other outcomes. Give the accountable owner options to mitigate, accept, compensate, reshape, or stop.

## Boundaries

Route roadmap sequencing and investment choices to [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md); route measurement design to [product-analytics-and-measurement](../product-analytics-and-measurement/SKILL.md); route adoption intervention to [product-adoption](../product-adoption/SKILL.md); route organizational structure to [org-design](../org-design/SKILL.md). This skill owns the cross-component causal map, tranche decision, and handoffs among those specialists.

# Program control and troubleshooting

**Applicability:** Load for integrated status, governance, dependency, risk, or recovery work.

## Integrated control record

Maintain links to component records, not copied status prose. At minimum record:

- shared outcome, current program phase, and accountable sponsor;
- component project/workstream, owner, current forecast, and acceptance state;
- cross-project dependency, provider, receiver, ready definition, needed-by date, and evidence;
- shared capacity/funding constraint and competing demand;
- benefit/disbenefit, owner, measure, baseline, target, timing, and confidence;
- program risk/issue, decision, assumption, change, escalation, and next checkpoint.

Use status by dimension: outcome, schedule, integration, dependency, capacity, quality,
adoption, benefits, and risk. Unknown is a valid status when evidence is missing or stale.

## Common failure patterns

| Signal | Diagnose | Response |
|---|---|---|
| All components green, program red | Integration, dependency aging, shared capacity, or benefit assumptions | Reconstruct the seam and prepare an owner-authorized trade-off |
| Outputs ship, benefits do not move | Adoption, operating model, measurement, or causal assumption | Test the benefit chain and change funding/scope or stop |
| Every decision escalates | Missing delegated authority or unclear tolerance | Map decision rights and reserve escalation for exceptions |
| Program is a project list | No shared outcome or coordination value | Remove unrelated work or route it to portfolio governance |
| Status is disputed | Different baselines, definitions, or evidence dates | Reconcile source records; publish disagreement rather than averaging it |
| Shared specialist blocks several projects | Hidden demand and priority conflict | Show scenarios and consequences; do not promise capacity into existence |
| Sponsor changes direction | Mandate and component commitments diverge | Preserve history, assess impacts, and authorize a revised mandate |
| Adoption resistance persists | Affected roles, incentives, training, or feedback are unaddressed | Name change owners and signals; route org design when structure is the issue |

## Recovery

Run a bounded diagnostic. Reconstruct the original mandate, component outcomes, accepted
commitments, current forecasts, benefits assumptions, and material dependencies. Identify
the limiting constraint. Present options to reduce or stage scope, resequence, add useful
capacity, move dates, pause, reshape, or stop. Record the decision authority, consequences,
residual risks, and review trigger. Never erase the original baseline or call a forecast a
new commitment without authorization.

After three diagnostic passes with no new evidence, stop and report the exact missing input,
affected decision, owner, and escalation path. Do not run a ceremony loop indefinitely.

# Research ledger

**Accessed:** 2026-09-05

This skill is an original synthesis. Sources ground the distinctions and practices below, but do not endorse this exact workflow or guarantee program success.

| ID | Source | Supported finding | Boundary |
|---|---|---|---|
| S01 | [PMI, The Standard for Program Management, Fifth Edition](https://www.pmi.org/standards/program-management-fifth-edition) | Programs coordinate related projects from initiation through benefits realization; the 2024 standard is principle-led and adds collaboration as a performance domain. | PMI product page, not a reproduction of the standard; professional guidance, not causal proof. |
| S02 | [UK Government Project Delivery, programme/project governance](https://projectdelivery.gov.uk/teal-book/home/part-d-managing-programmes-and-projects/chapter-13-the-governance-and-management-of-programmes-and-projects/) | Governance establishes accountable senior ownership and the framework for managing programmes and projects. | UK government context; this application is an inference. |
| S03 | [UK Government Project Delivery, managing a programme or project](https://projectdelivery.gov.uk/teal-book/home/part-d-managing-programmes-and-projects/chapter-15-managing-a-programme-or-project/) | Initiation follows authorization and includes a confirmed vision, justification, outcomes, and benefits. | Jurisdiction-specific standard. |
| S04 | [UK Government Project Delivery, transition into use](https://projectdelivery.gov.uk/teal-book/home/part-f-solution-delivery/chapter-36-transition-into-use/) | Transition into use includes moving a solution into its intended environment and formal handover of accountability. | Government delivery context; not a universal release gate. |
| S05 | [Local Government Association, manage dependencies](https://www.local.gov.uk/our-support/transformation/transformation-capability-framework/governance-dependencies) | Dependency management links programmes, projects, tasks, and resources so changes can be impact-assessed and managed. | Public-sector capability guidance, not independent outcome evidence. |
| S06 | [NASA, Risk Management](https://sma.nasa.gov/sma-disciplines/risk-management) | NASA treats risk management as a formal program/project discipline under agency governance and mission-success policy. | NASA-specific requirements; practices here are adapted, not NASA compliance. |
| S07 | [NASA Space Flight Program and Project Management Handbook](https://www.nasa.gov/wp-content/uploads/2024/09/pm-handbook-nasa-sp-2014-3705-2024jun.pdf) | The requested handbook is a primary candidate for program-level objectives, architecture, technical performance, schedule, cost, safety/risk, and agreements. | The GroktoCrawl run could not extract the PDF, so no handbook-specific claim is treated as verified in this revision. |

## Gap map against technical-project-management

The companion project skill owns one bounded project's mandate, method, milestones, risks, dependencies, forecast, change, acceptance, and closure. This skill adds the coordination layer: program mandate and component topology; cross-project dependency and shared-capacity trade-offs; benefit and disbenefit realization; integrated governance; transformation/adoption; program-level escalation; assurance; tranche decisions; and stakeholder views that reconcile local delivery with the shared outcome.

## Research findings versus proposed practice

**Source findings:** programs coordinate related work toward benefits; authorization, accountable ownership, dependencies, risk, and transition matter. **Our inference:** a technical program needs a causal benefits map, explicit tranche gates, and an assurance path because component outputs are not sufficient evidence of the integrated outcome. **Proposed practice:** use the new benefits/tranche and assurance templates, adapting their fields to the governing organization and risk class.

## Integrity limits

The deep GroktoCrawl artifact (retained as a session-side research record) consulted three sources and produced a useful synthesis, but source completeness was not achieved: the NASA PDF and some UK pages were inaccessible to the crawler. Do not describe those unverified documents as having supplied detailed requirements. Preserve uncertainty rather than filling the gap with plausible program-management doctrine.

# Independent assurance review

**Program:**
**Review scope:**
**Reviewer and independence basis:**
**Decision this review informs:**
**As of:**

## Evidence reviewed
- Mandate, authority, funding, and continued justification:
- Component scope, dependencies, architecture, and shared capacity:
- Forecasts, actuals, contradictions, and decision latency:
- Risk, security, safety, compliance, supplier, and operational evidence:
- Benefits, adoption, disbenefits, and measurement ownership:
- Escalation history and residual obligations:

## Findings
| Finding | Evidence | Interpretation | Limitation | Consequence | Recommendation | Owner | Due/trigger |
|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |

## Decision
- Sponsor decision: continue / reshape / pause / stop / transfer / accept risk
- Conditions:
- Residual risks:
- Next checkpoint:

# Benefits dependency map

## Program outcome
- Outcome:
- Beneficiary:
- Accountable sponsor:

## Causal chain
| Component capability | Required operational change | Changed behavior | Benefit/disbenefit | Measure and baseline | Owner | Dependency/assumption | Evidence | Timing | Failure consequence | Status | Review trigger |
|---|---|---|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |  |  |  |

## Tranche decision
- Tranche/capability:
- Entry evidence:
- Intended benefit signal:
- Required integration/operational/adoption/safety evidence:
- Decision owner:
- Exit choice: continue / reshape / pause / stop / transfer
- Next tranche condition:

# Integrated program control

**As of:**
**Program phase:**
**Accountable sponsor:**
**Overall status:** Do not use a single color when dimensions differ.

## Outcome and benefits
- Expected outcome:
- Benefits/disbenefits and confidence:
- Adoption/operational evidence:

## Component view
| Component | Owner | Forecast | Acceptance | Change since last review | Program impact |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## Cross-project dependencies
| Dependency | Provider | Receiver | Ready means | Needed by | Evidence/status | Fallback/escalation |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## Shared constraints
- Capacity and competing demand:
- Funding:
- Architecture/environment/policy:

## Risks, issues, decisions, changes
| Type | Statement | Owner/authority | Impact | Response | Trigger/date | Status |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## Decisions due
- Decision:
- Options and consequences:
- Decision owner:
- Latest useful date:
- Next evidence checkpoint:

# Program brief

## Mandate
- Program name:
- Shared outcome and rationale:
- Accountable sponsor:
- Authorization evidence and date:
- In scope / out of scope:

## Component map
| Component | Owner | Outcome | Forecast | Acceptance state | Key interface |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## Integrated constraints
- Shared capacity:
- Funding horizon:
- External suppliers:
- Architecture/policy constraints:
- Mandatory gates:

## Benefits and disbenefits
| Benefit or disbenefit | Owner | Measure/baseline | Target/date | Assumption | Review trigger |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## Governance
- Decision rights:
- Review cadence:
- Escalation route:
- Exception record:

## First decision
- Decision needed:
- Options:
- Evidence and unknowns:
- Latest useful decision date:
- Next checkpoint:

# Program stakeholder update

**As of:**
**Audience:** Sponsor / component leads / operations / partner
**Program outcome:**
**Overall status:** Use dimension-level status; do not average it into one color.

## What changed
- Evidence since the last update:
- Component or dependency change:
- Outcome/benefit/adoption implication:

## Decision needed
- Decision:
- Options:
- Recommendation and rationale:
- Decision owner:
- Latest useful decision date:
- Consequence of waiting:

## Audience-specific detail
- Component leads: dependency, interface, capacity, and action:
- Operations/adoption: readiness, support, training, and residual risk:
- Vendor/partner: provider obligation, receiver obligation, ready definition, evidence, and escalation:

## Evidence and uncertainty
- Observed:
- Inferred:
- Assumed:
- Unknown or disputed:

## Next checkpoint
- Owner:
- Evidence due:
- Date or trigger: