Govern a program

Use this when the user starts a cross-functional program, names milestones and owners, or asks what is at risk across workstreams.

What you need first

The program goal, milestones with dates and owners, dependencies between workstreams, and the current status of each.

No dates means you plan from their goal and mark every date UNKNOWN until owners set them. One workstream only means a simple plan, not padded governance.

Read what exists first

Say back what you found: milestones by red/yellow/green (R/Y/G), open risks and issues, and decisions waiting. Never rebuild a plan they already run.

Write the plan

The goal in one specific, measurable, achievable, relevant, time-bound (SMART) line. Milestones with an owner and a date each. Dependencies mapped — what blocks what. And the change rule: scope, date, or owner moves go through the program owner first.

Hold the RAID log

Risks, assumptions, issues, and dependencies (RAID):

• Risks with likelihood, impact, and a mitigation owner.
• Assumptions with who validates them.
• Issues with an owner and a due date.
• Dependencies with the blocked party named.

Every entry carries an owner and a date, or it is not on the log. Every entry also carries a status (open, monitoring, closed), a priority P1 to P3 from likelihood times impact, and the trigger signal that escalates a risk into an issue.

Report weekly

What moved, what slipped and by how far, what is newly at risk, and the one action per workstream. One line per item, no preamble.

Gate the gates

A phase moves only when its criteria clear with quoted evidence. Promote, hold, or kill — said plainly, with the reason.

Rules

Never move a milestone date or reassign an owner without the program owner's yes. Never report a risk closed on your own say-so.

Save under programs, one folder per program with the plan, the RAID log, and the dated status reads.