program-management git:20260916.e72e404A

Immutable. This exact content is served forever at /api/v1/blob/38a1496a9ebc6f86.

---
name: program-management
description: Plans and drives cross-functional programs to delivery — scope, sequencing, dependencies, status, risk, and the escalations that keep work moving. Use this to run a multi-team initiative, recover a program that is slipping, build a delivery plan with dependencies, structure status reporting, or diagnose why cross-team work keeps missing dates.
---

# Program management

Programs fail at the seams between teams, not inside them. The job is the seams.

## Set up

- **One outcome, stated as a business result** with a date. Programs with several equal objectives
  have none.
- **A named accountable owner** — one person, not a committee. The program manager drives; the owner
  decides.
- **Scope written as inclusions and exclusions.** The exclusions do the work; unwritten exclusions
  return as assumptions.
- **Dependencies mapped and agreed by the teams that owe them**, with dates they have actually
  committed to. A dependency in your plan that the owning team has not agreed to is a wish.

## Sequencing

Order by dependency and risk, not by team convenience. Front-load the things that could invalidate
the plan — the technical unknown, the vendor decision, the approval that might not come. Discovering
in month four that the plan was impossible is the characteristic program failure.

Build in slack at integration points, not at the end. End-loaded buffer gets consumed early and
silently.

## Status that is worth reading

Three things, every time: are we on track for the date, what changed since last time, and what
decision or unblock is needed. Everything else is appendix.

Track status against **committed dates**, not effort. "80% complete" is not information; "the
integration is done, the migration starts Monday, the sign-off is the risk" is.

Escalate early and specifically. An escalation naming the decision needed and the date it is needed
by gets resolved; a general statement of concern gets acknowledged and nothing happens.

## When it slips

Establish whether it is a scope problem, a capacity problem, or a dependency problem — the remedies
are entirely different and applying the wrong one makes it worse.

Then present options with consequences: cut scope (name what), extend (say by how much and what else
is affected), or add capacity (which rarely helps late, and often hurts).

Re-baseline once, visibly, rather than slipping a week at a time. Serial small slips destroy
credibility far faster than one honest reset.

## Sources

`references/sources.md` in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.

## Never

- Report green on a program with an unresolved blocker.
- Accept a dependency date the owning team has not confirmed.
- Add people to a late program and assume it accelerates.