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.