From 2a458aba1096bd94f6ef97dba19217c53d9c61d9 Mon Sep 17 00:00:00 2001 From: Magnus Hedemark Date: Sat, 5 Sep 2026 17:39:54 -0400 Subject: [PATCH] feat: add technical program management skill Merge research-grounded technical program management skill with routing, templates, evals, and repository validation. --- .claude-plugin/marketplace.json | 11 +- .codex-plugin/plugin.json | 1 + README.md | 4 + enterprise-architecture/SKILL.md | 3 + implementation-planning/SKILL.md | 3 + llms.txt | 3 +- product-operations-and-governance/SKILL.md | 1 + product-roadmapping-and-portfolio/SKILL.md | 1 + references/skill-triggers.md | 1 + technical-program-management/README.md | 34 ++++ technical-program-management/SKILL.md | 190 ++++++++++++++++++ technical-program-management/evals/evals.json | 18 ++ .../references/benefits-and-transformation.md | 33 +++ .../references/program-control.md | 42 ++++ .../references/research-ledger.md | 22 ++ .../templates/integrated-control.md | 38 ++++ .../templates/program-brief.md | 38 ++++ .../templates/stakeholder-update.md | 35 ++++ technical-project-management/SKILL.md | 8 +- 19 files changed, 483 insertions(+), 3 deletions(-) create mode 100644 technical-program-management/README.md create mode 100644 technical-program-management/SKILL.md create mode 100644 technical-program-management/evals/evals.json create mode 100644 technical-program-management/references/benefits-and-transformation.md create mode 100644 technical-program-management/references/program-control.md create mode 100644 technical-program-management/references/research-ledger.md create mode 100644 technical-program-management/templates/integrated-control.md create mode 100644 technical-program-management/templates/program-brief.md create mode 100644 technical-program-management/templates/stakeholder-update.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 9551993..a98bc03 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -1238,6 +1238,15 @@ "strict": false, "description": "Create and review technical documentation, including READMEs, agent-facing instructions, API references, and CLI help. Use when documentation must help someone complete real work. Do not use for marketing copy, brand messaging, or long-form editorial content." }, + { + "name": "technical-program-management", + "source": "./", + "skills": [ + "./technical-program-management" + ], + "strict": false, + "description": "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." + }, { "name": "technical-project-management", "source": "./", @@ -1245,7 +1254,7 @@ "./technical-project-management" ], "strict": false, - "description": "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. 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." + "description": "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." }, { "name": "technology-radar", diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 1f9a3ae..a33cbc9 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -155,6 +155,7 @@ "./systematic-debugging", "./tailscale", "./technical-documentation", + "./technical-program-management", "./technical-project-management", "./technology-radar", "./telemetry", diff --git a/README.md b/README.md index 9b74986..33ba109 100644 --- a/README.md +++ b/README.md @@ -563,6 +563,10 @@ Self-hosted Tailscale/Headscale VPN ecosystem. Seven sub-skills covering Headsca Make documentation useful at the moment someone needs to install, operate, extend, or troubleshoot a system. +### [technical-program-management](technical-program-management/SKILL.md) + +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. Complements technical-project-management rather than replacing single-project control. + ### [technical-project-management](technical-project-management/SKILL.md) Manage technical projects from initiation through closure: choose and tailor delivery approaches, coordinate teams and vendors, maintain credible forecasts, handle scope changes, recover troubled projects, and hand off operations. Adapts to teams without a PM and experienced TPMs. Ships a research source ledger, four real-world cases, focused references, seven templates, a tested read-only schedule calculator, and output-quality evals. Routes detailed planning, Kanban, product choices, and release mechanics to their specialists. diff --git a/enterprise-architecture/SKILL.md b/enterprise-architecture/SKILL.md index a4172eb..8bbca43 100644 --- a/enterprise-architecture/SKILL.md +++ b/enterprise-architecture/SKILL.md @@ -77,6 +77,9 @@ assumption, decision, or open question and have a source or named owner. enterprise architecture may use its findings as evidence. - Approved cross-system execution belongs to `implementation-planning` and `migration-engineering`, not this skill. +- Cross-project program coordination, shared capacity, integrated benefits, and + transformation delivery belong to `technical-program-management`; this skill + provides the architecture evidence and decision-rights inputs. ## When Not To Use diff --git a/implementation-planning/SKILL.md b/implementation-planning/SKILL.md index ab0efc2..d0e301e 100644 --- a/implementation-planning/SKILL.md +++ b/implementation-planning/SKILL.md @@ -65,6 +65,9 @@ sequencing, risk, and verification. For ongoing milestone reviews, forecast changes, sponsor decisions, and project closure after planning, route to [technical-project-management](../technical-project-management/SKILL.md). +For coordination across multiple related projects, shared capacity, program benefits, +or a transformation outcome, route to +[technical-program-management](../technical-program-management/SKILL.md). Keep detailed work breakdown and dependency-plan maintenance here. ## Entry gate: prerequisite approval diff --git a/llms.txt b/llms.txt index dd260fd..b5d4a09 100644 --- a/llms.txt +++ b/llms.txt @@ -139,7 +139,8 @@ - [systematic-debugging](systematic-debugging/SKILL.md): Diagnose root causes with a four-phase debugging protocol. Use for ANY technical issue — test failures, production bugs, unexpected behavior, performance problems, build failures, or integration issues. ESPECIALLY when under time pressure, when "one quick fix" seems obvious, or when previous fix attempts have failed. Do not use this skill for unrelated requests; route to the nearest named specialist. - [tailscale](tailscale/SKILL.md): Deploy and manage the self-hosted Tailscale/Headscale ecosystem: a Headscale control server, tailscale clients, ACL policies, node lifecycle, subnet routing, DERP relays, and backup/migration. Use when the user mentions Tailscale, Headscale, tailnet, mesh VPN, WireGuard mesh, or self-hosted VPN infrastructure. Do not use this skill for unrelated requests; route to the nearest named specialist. - [technical-documentation](technical-documentation/SKILL.md): Create and review technical documentation, including READMEs, agent-facing instructions, API references, and CLI help. Use when documentation must help someone complete real work. Do not use for marketing copy, brand messaging, or long-form editorial content. -- [technical-project-management](technical-project-management/SKILL.md): 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. 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. +- [technical-program-management](technical-program-management/SKILL.md): 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. +- [technical-project-management](technical-project-management/SKILL.md): 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. - [technology-radar](technology-radar/SKILL.md): Build and maintain technology radars for adoption, trial, assessment, and hold decisions, and choose proportionate architecture-governance paths for technology portfolios. Use when governing technology choices, build-versus-buy decisions, architecture standards, exceptions, or engineering portfolio risk. Do not use for enterprise capability or target-state architecture, writing ADRs, implementing systems, security engineering, or operational incident/runbook work. - [telemetry](telemetry/SKILL.md): Operate the observability stack that deploys as one unit: Prometheus scrape configuration, recording and alerting rules, relabeling, retention, and high availability; OpenTelemetry Collector pipelines (receivers, processors, exporters, sampling, trace/span correlation); and Loki ingest, LogQL, retention, and label design — with a bundled read-only telemetry-check script for Prometheus rule sanity and scrape-target reachability. Use when running, tuning, or troubleshooting a Prometheus, OpenTelemetry Collector, or Loki deployment, or reviewing the collection/ingest/retention layer, including bounded PromQL and LogQL query construction, semantic review, and no-data diagnosis. Do not use for observability strategy, SLI/SLO design, or paging policy (that is platform-engineering), Grafana dashboards, panels, and Grafana-side alerting (that is grafana), or Tempo/tracing operations, which remain deferred to a future named-tool skill. - [tempest](tempest/SKILL.md): Query hyper-local weather from a WeatherFlow Tempest station over its REST API and the hub's local UDP broadcast: current conditions, forecast, historical observations, and real-time decoded datagrams (obs_st, rapid_wind, evt_precip, evt_strike, hub_status). Use when the user asks about weather, temperature, rain, wind, humidity, or forecast data from their own Tempest/WeatherFlow station, or wants to parse the hub's UDP port 50222 broadcast. Do not use this skill for generic or city forecasts without a Tempest station (public weather services serve those), for Shakespeare's play The Tempest or other literature questions, or for weather hardware from other vendors - the REST endpoints require a personal-use token and the UDP broadcast only exists on a Tempest hub's LAN. diff --git a/product-operations-and-governance/SKILL.md b/product-operations-and-governance/SKILL.md index d86237b..a0926b0 100644 --- a/product-operations-and-governance/SKILL.md +++ b/product-operations-and-governance/SKILL.md @@ -181,6 +181,7 @@ Every exception and escalation gets a dated record with accountable owner and re | Product vision, North Star, competitive positioning | [product-strategy](../product-strategy/SKILL.md) | | Tactical prioritization (RICE, MoSCoW), decision logs, specs | [product-methodology](../product-methodology/SKILL.md) | | Outcome roadmaps, strategic bets, portfolio sequencing | [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) | +| Multi-project technical coordination, shared capacity, program benefits, transformation delivery | [technical-program-management](../technical-program-management/SKILL.md) | | Experiment design, method selection, guardrails, readouts | [product-experimentation](../product-experimentation/SKILL.md) | | Post-launch learning, lifecycle decisions, assumption updates | product-lifecycle-learning (prose — same-wave skill) | | Executive decision memos, CoS methods, board materials | [chief-of-staff-methodology](../chief-of-staff-methodology/SKILL.md) | diff --git a/product-roadmapping-and-portfolio/SKILL.md b/product-roadmapping-and-portfolio/SKILL.md index 575d8aa..9e85983 100644 --- a/product-roadmapping-and-portfolio/SKILL.md +++ b/product-roadmapping-and-portfolio/SKILL.md @@ -86,6 +86,7 @@ Executive narrative, team view, external/customer view — each tailored. ## When Not to Use - **For tactical prioritization mechanics** (RICE scores, MoSCoW buckets, Kano categorization, OST trees): route to `product-methodology` or `product-strategy`. This skill references these frameworks only to describe *where* they fit, never to re-explain formulas or mechanics. +- **For cross-project program coordination** (integrated dependencies, shared capacity, program benefits, or transformation delivery): route to [technical-program-management](../technical-program-management/SKILL.md). This skill sequences product bets; it does not coordinate their technical program execution. - **For project scheduling, Gantt charts, or milestone tracking:** route to [technical-project-management](../technical-project-management/SKILL.md) for ongoing project control; use [implementation-planning](../implementation-planning/SKILL.md) for detailed planning of approved work. This skill owns outcome roadmaps. - **For delivery-flow management:** route to `kanban-guru`. - **For corporate capital allocation and M&A portfolio decisions:** route to `strategy-frameworks`. diff --git a/references/skill-triggers.md b/references/skill-triggers.md index f63b0e1..90eca4e 100644 --- a/references/skill-triggers.md +++ b/references/skill-triggers.md @@ -99,6 +99,7 @@ Each skill's `description` field is the canonical routing contract. This conveni | "remote system administration", "remote administration", "remote SSH", "SSH administration", "Ansible administration", "Paramiko automation", "remote Linux", "remote FreeBSD", "remote NetBSD", "remote OpenBSD", "remote macOS", "remote service", "remote firewall", "remote package update", "fleet administration", "fleet rollout", "remote launchctl", "remote rcctl", "remote systemctl" | [remote-systems-administration](../remote-systems-administration/SKILL.md) | | "resilience", "recovery", "graceful degradation", "disaster recovery", "DR plan", "game day", "restore test", "failover drill", "RTO", "RPO", "recovery plan", "resilience plan", "data integrity after restore", "recovery exercise", "follow-up work ledger", "recovery communication", "dependency loss", "circuit breaker resilience", "degradation path", "feature shedding" | [resilience-and-recovery](../resilience-and-recovery/SKILL.md) | | "restic", "restic backup", "restic repository", "restic restore", "restic prune", "restic forget", "restic check", "restic snapshots", "encrypted backup", "backup retention", "restore drill", "backup integrity", "repository lock", "S3 backup", "SFTP backup" | [restic](../restic/SKILL.md) | +| "technical program management", "technical programme management", "program management", "programme management", "TPgM", "program governance", "cross-project dependencies", "integrated program plan", "benefits realization", "transformation program", "program recovery", "program steering committee", "component projects", "shared program capacity", "program-level stakeholder update" | [technical-program-management](../technical-program-management/SKILL.md) | | "technical project management", "TPM", "no project manager", "project recovery", "milestone tracking", "scope change", "vendor handoff", "project closure", "sponsor decision" | [technical-project-management](../technical-project-management/SKILL.md) | | "technical-documentation", "technical documentation" | [technical-documentation](../technical-documentation/SKILL.md) | | "secure software engineering", "build securely", "secure by design", "security requirements", "security acceptance criteria", "threat model this design", "secure code review", "secure defaults", "authorization design", "multi-tenant isolation", "tenant trust boundary", "control-plane security", "application-plane security", "tenant identity propagation", "support impersonation security", "tenant backup security", "tenant export security", "tenant deletion security", "noisy neighbor security", "resource exhaustion tenant", "release evidence", "SBOM", "software supply chain", "AI security", "LLM security", "prompt injection", "tool authorization", "RAG security" | [secure-software-engineering](../secure-software-engineering/SKILL.md) | diff --git a/technical-program-management/README.md b/technical-program-management/README.md new file mode 100644 index 0000000..095ee2b --- /dev/null +++ b/technical-program-management/README.md @@ -0,0 +1,34 @@ +# Technical Program Management + +Coordinate the work that spans projects, teams, vendors, and organizational boundaries so a collection of locally successful efforts produces the outcome it was meant to produce. + +## Why Install This Skill + +A program can be full of green project dashboards and still be failing. The integration path is late, the shared specialist is committed three ways, the benefits belong to nobody, and each team has optimized its own deliverable while the larger change quietly comes apart. This skill gives an agent a way to see and manage those seams. + +It helps establish a real program mandate, connect component projects to a shared outcome, manage cross-project dependencies and capacity, surface trade-offs to the people who can decide them, and keep benefits and adoption from becoming somebody else's problem. It complements `technical-project-management`, which owns the control of one bounded project. + +## What You Get + +| Contents | What they provide | +|---|---| +| `SKILL.md` | Program-level operating loop, method selection, troubleshooting, communication, and routing | +| `references/` | Research ledger, program controls, benefits, dependency networks, transformation, and failure recovery | +| `templates/` | Program brief, integrated control record, benefits map, dependency agreement, decision brief, and stakeholder update | +| `evals/` | Portable output-quality cases for realistic program decisions | + +## Quick Start + +Ask: "We have four projects modernizing one platform. Each is reporting green, but integration and adoption are slipping. Help me build an integrated program view and prepare the sponsor decisions." + +## Triggers + +- Coordinating multiple related technical projects, products, teams, or suppliers toward one outcome. +- Managing cross-project dependencies, shared capacity, funding, architecture, or release sequencing. +- Tracking program benefits, adoption, transformation, and disbenefits. +- Preparing executive, component-team, vendor, or operations communication about program health. +- Recovering a troubled program whose component projects look healthy in isolation. + +## Requirements + +No service, API key, or runtime is required. The skill is platform-agnostic and uses Markdown artifacts. Route project-level control, detailed implementation planning, product portfolio decisions, enterprise architecture, release approval, and incident command to their owning skills. diff --git a/technical-program-management/SKILL.md b/technical-program-management/SKILL.md new file mode 100644 index 0000000..1b69c03 --- /dev/null +++ b/technical-program-management/SKILL.md @@ -0,0 +1,190 @@ +--- +name: technical-program-management +description: >- + 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. +license: MIT +compatibility: >- + Platform-agnostic methodology and Markdown templates. No runtime dependency. +metadata: + tags: technical-program-management, program-governance, benefits-realization, + dependency-management, transformation, stakeholder-communication +--- + +# Technical Program Management + +Coordinate related delivery efforts toward a shared technical and organizational +outcome. 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. + +## First move: prove the program boundary + +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](../technical-project-management/SKILL.md). +If the work is only a collection of unrelated investments, route to +[product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) or +[strategy-frameworks](../strategy-frameworks/SKILL.md). + +## Reference routing + +Read only what the current decision requires: + +| Situation | Read | +|---|---| +| Program mandate, component map, or shared constraints | [Program brief template](templates/program-brief.md) | +| Integrated status, dependency, risk, or recovery problem | [Program control and troubleshooting](references/program-control.md) | +| Benefits, governance, or evidence boundary | [Research ledger](references/research-ledger.md) | +| Adoption, operating-model change, or benefit drift | [Benefits and transformation](references/benefits-and-transformation.md) | +| Integrated control record needs filling | [Integrated control template](templates/integrated-control.md) | +| Audience-specific status or decision update | [Stakeholder update template](templates/stakeholder-update.md) | +| One project needs detailed control | [technical-project-management](../technical-project-management/SKILL.md) | +| Product portfolio or capital-allocation choice | [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) or [strategy-frameworks](../strategy-frameworks/SKILL.md) | + +## Routing to adjacent skills + +- For a single bounded project's milestones, forecasts, dependencies, recovery, or closure, use [technical-project-management](../technical-project-management/SKILL.md). +- For product roadmap and portfolio sequencing, use [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md). +- For recurring product decision rights and product governance, use [product-operations-and-governance](../product-operations-and-governance/SKILL.md). +- For enterprise target-state architecture or architecture governance, use [enterprise-architecture](../enterprise-architecture/SKILL.md). +- For approved work breakdown and detailed rollout planning, use [implementation-planning](../implementation-planning/SKILL.md). + +## Program operating loop + +1. **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. +2. **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. +3. **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. +4. **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. +5. **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. +6. **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. +7. **Realize and transition.** Coordinate adoption, operating-model change, capability + transfer, and benefits measurement. 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](../org-design/SKILL.md); 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](../technical-project-management/SKILL.md) | +| Approved requirement into work breakdown and rollout plan | [implementation-planning](../implementation-planning/SKILL.md) | +| Product bets, roadmap sequencing, or portfolio allocation | [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) | +| Product decision rights and recurring product governance | [product-operations-and-governance](../product-operations-and-governance/SKILL.md) | +| Enterprise capabilities, target/transition architecture, or architecture authority | [enterprise-architecture](../enterprise-architecture/SKILL.md) | +| Technology adoption posture or standards governance | [technology-radar](../technology-radar/SKILL.md) | +| Release mechanics or launch authorization | [release-engineering](../release-engineering/SKILL.md) and [production-readiness](../production-readiness/SKILL.md) | +| Live outage or responder command | [site-reliability-engineering](../site-reliability-engineering/SKILL.md) | +| Capital allocation, corporate strategy, or M&A | [strategy-frameworks](../strategy-frameworks/SKILL.md) | +| Organizational structure and talent design | [org-design](../org-design/SKILL.md) | +| Post-delivery adoption evidence or benefits learning | [product-adoption](../product-adoption/SKILL.md) and [product-lifecycle-learning](../product-lifecycle-learning/SKILL.md) | + +## 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 PMI's *The Standard for Program Management, Fifth +Edition* (2024), UK Government Project Delivery programme governance guidance, and +NASA program/project management guidance. Those sources provide principles and +jurisdiction-specific requirements, not a universal operating model or proof that any +method guarantees delivery success. Use formal organizational or regulatory standards +when they govern the actual program. diff --git a/technical-program-management/evals/evals.json b/technical-program-management/evals/evals.json new file mode 100644 index 0000000..6f7cd9c --- /dev/null +++ b/technical-program-management/evals/evals.json @@ -0,0 +1,18 @@ +{ + "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":"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":"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."]} + ] +} diff --git a/technical-program-management/references/benefits-and-transformation.md b/technical-program-management/references/benefits-and-transformation.md new file mode 100644 index 0000000..4eee8b1 --- /dev/null +++ b/technical-program-management/references/benefits-and-transformation.md @@ -0,0 +1,33 @@ +# 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. diff --git a/technical-program-management/references/program-control.md b/technical-program-management/references/program-control.md new file mode 100644 index 0000000..0034c42 --- /dev/null +++ b/technical-program-management/references/program-control.md @@ -0,0 +1,42 @@ +# 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. diff --git a/technical-program-management/references/research-ledger.md b/technical-program-management/references/research-ledger.md new file mode 100644 index 0000000..527375e --- /dev/null +++ b/technical-program-management/references/research-ledger.md @@ -0,0 +1,22 @@ +# Research ledger + +**Accessed:** 2026-09-05 + +This skill is an original synthesis. The sources below ground the distinctions and practices, 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 247-page 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 identifies accountable senior ownership and establishes how programmes and projects are managed; dependencies and decision rights require explicit control. | UK government context; transferable practice is our inference, not universal law. | +| 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 | [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. | +| S05 | [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; our risk practices are adapted, not claimed NASA compliance. | +| S06 | [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) | Program-level planning connects objectives, architecture, technical performance, schedule, cost, safety/risk, and internal/external agreements. | Complex spaceflight context; not a universal process template. | + +## 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; and stakeholder views that reconcile local delivery with the shared outcome. + +## Interpretation discipline + +Source findings, inferences, and proposed practices must remain distinct. A component project's status is evidence about that component, not proof of program health. Benefits are hypotheses until measures and owners exist. A program is not justified merely because several projects share a technology or executive sponsor; they need a common or complementary outcome and coordination value. diff --git a/technical-program-management/templates/integrated-control.md b/technical-program-management/templates/integrated-control.md new file mode 100644 index 0000000..4e8afb6 --- /dev/null +++ b/technical-program-management/templates/integrated-control.md @@ -0,0 +1,38 @@ +# 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: diff --git a/technical-program-management/templates/program-brief.md b/technical-program-management/templates/program-brief.md new file mode 100644 index 0000000..7ad88ef --- /dev/null +++ b/technical-program-management/templates/program-brief.md @@ -0,0 +1,38 @@ +# 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: diff --git a/technical-program-management/templates/stakeholder-update.md b/technical-program-management/templates/stakeholder-update.md new file mode 100644 index 0000000..2f26ba3 --- /dev/null +++ b/technical-program-management/templates/stakeholder-update.md @@ -0,0 +1,35 @@ +# 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: diff --git a/technical-project-management/SKILL.md b/technical-project-management/SKILL.md index 6eaec00..21e77a8 100644 --- a/technical-project-management/SKILL.md +++ b/technical-project-management/SKILL.md @@ -6,7 +6,9 @@ description: >- 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. Adapt depth to the user's expertise. Do not use for + 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. @@ -70,6 +72,10 @@ Do not call a desired date a commitment, a forecast an acceptance, or a diagnost 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](references/engagement-and-initiation.md) | Proposed brief with mandate, authority, and evidence gaps |