program-management
GitHub用于规划和管理跨职能项目，涵盖范围定义、依赖梳理、进度跟踪及风险升级。适用于启动多团队 initiative、挽回延期项目或构建交付计划等场景。
Trigger Scenarios
Install
npx skills add cbrock84/headcount --skill program-management -g -y
SKILL.md
Frontmatter
{
"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.
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.
Version History
- d58a7ee Current 2026-09-02 21:09
