project-management

Program Status Report

Write program status reports that surface risks and decisions, not just progress — with executive summaries, workstream tracking, dependency maps, and escalation frameworks.

status-reportprogram-managementreportingriskstracking

Works well with agents

Engineering Manager Agent Project Manager Agent Technical Program Manager Agent

Works well with skills

Ticket Writing

$ npx skills add The-AI-Directory-Company/(…) --skill program-status-report

program-status-report/

SKILL.md

Markdown

1
2	# Program Status Report
3
4	## Before you start
5
6	Gather the following from the user before writing:
7
8	1. What program or initiative does this cover? (Name, scope, and target completion date)
9	2. Who is the audience? (Executive leadership, steering committee, cross-functional stakeholders, or the working team)
10	3. What reporting cadence is this? (Weekly, biweekly, monthly — this determines the right level of detail)
11	4. What happened since the last report? (Milestones hit, milestones missed, scope changes, team changes)
12	5. What decisions or escalations are needed? (Blockers that the audience has authority to resolve)
13
14	If the user says "just summarize where we are," push back: "A status report that only reports progress is a changelog. What risks, blockers, or decisions does your audience need to act on?"
15
16	## Status report template
17
18	### Program header
19
20	State the program name, reporting period, overall status (Green/Yellow/Red), report author, and distribution date. The status color must reflect the worst-case workstream, not an average.
21
22	```
23	Program: Platform Migration \| Period: Mar 3-14, 2025
24	Overall Status: YELLOW \| Author: J. Martinez
25	Distribution: Steering Committee, Eng Leadership
26	```
27
28	### Executive summary
29
30	3-5 sentences maximum. Structure as:
31
32	1. Overall trajectory — Are we on track to hit the program milestone? State the milestone and date.
33	2. Key progress — The 1-2 most significant accomplishments this period.
34	3. Primary risk or blocker — The single biggest threat to the timeline and what is needed to resolve it.
35
36	Executives read this section and nothing else. If the report were only these 5 sentences, the audience should still know whether to worry.
37
38	### Status by workstream
39
40	Use a table with one row per workstream. Every row must include:
41
42	\| Workstream \| Owner \| Status \| Progress this period \| Next milestone \| Risk \|
43	\|---\|---\|---\|---\|---\|---\|
44	\| Data migration \| @Lee \| GREEN \| Migrated 3/5 schemas \| Schema 4 by Mar 21 \| None \|
45	\| API cutover \| @Patel \| YELLOW \| Auth integration delayed 3 days \| Auth complete by Mar 18 \| Vendor response time — see Risks \|
46	\| Frontend rebuild \| @Chen \| GREEN \| Search page shipped \| Settings page by Mar 25 \| None \|
47
48	Status rules:
49	- GREEN: On track, no blockers, will hit the next milestone on time
50	- YELLOW: At risk — a known issue threatens the milestone but a mitigation plan exists
51	- RED: Off track — the milestone will be missed without intervention from outside the team
52
53	Never mark a workstream GREEN when it depends on a YELLOW or RED workstream.
54
55	### Milestones
56
57	List the next 4-6 milestones in chronological order. For each, state the target date, responsible owner, current confidence level (High/Medium/Low), and any predecessor dependency.
58
59	```
60	1. Auth integration complete — Mar 18 — @Patel — Medium (blocked on vendor)
61	2. Schema 4 migration — Mar 21 — @Lee — High
62	3. Settings page shipped — Mar 25 — @Chen — High
63	4. End-to-end staging test — Mar 28 — @Martinez — Medium (depends on #1, #2)
64	```
65
66	### Risks and mitigations
67
68	List every active risk. Each risk entry must include:
69
70	- Risk: What could go wrong (specific, not vague)
71	- Impact: What happens to the program if it materializes (timeline, scope, or cost)
72	- Likelihood: High, Medium, or Low
73	- Mitigation: What is being done to reduce the likelihood or impact
74	- Owner: Who is responsible for executing the mitigation
75	- Escalation trigger: The condition under which this risk becomes a blocker requiring leadership action
76
77	```
78	Risk: Vendor has not responded to SSO integration questions in 5 business days.
79	Impact: API cutover delayed 1-2 weeks, pushing program completion past Q1.
80	Likelihood: Medium
81	Mitigation: Escalated to vendor account manager; parallel-pathing with in-house SAML implementation.
82	Owner: @Patel
83	Escalation trigger: No vendor response by Mar 17 — will need leadership to engage vendor VP.
84	```
85
86	### Decisions needed
87
88	List decisions that require action from the report audience. For each, state the decision, the options, the recommendation, and the deadline. If no decisions are needed, state "No decisions required this period" — do not omit the section.
89
90	### Key metrics (if applicable)
91
92	Include 3-5 quantitative indicators of program health: burn rate vs budget, velocity vs plan, defect count, test coverage, or adoption metrics. Show trend direction.
93
94	## Quality checklist
95
96	Before delivering the report, verify:
97
98	- [ ] Executive summary is 3-5 sentences and conveys trajectory, progress, and the top risk
99	- [ ] Every workstream has a named owner, a status color with justification, and a next milestone with date
100	- [ ] Status colors follow the rules — no GREEN workstreams with unresolved dependencies on YELLOW/RED workstreams
101	- [ ] Every risk has a specific mitigation, an owner, and an escalation trigger
102	- [ ] Decisions section states options, a recommendation, and a deadline — not just "we need to decide"
103	- [ ] Milestones include confidence levels and dependency chains
104	- [ ] The report can be skimmed in under 2 minutes by reading only the header, executive summary, and status table
105
106	## Common mistakes
107
108	- Reporting activity instead of progress. "We had 12 meetings and reviewed 3 design docs" is activity. "Auth integration is 80% complete, on track for Mar 18" is progress. Report outcomes, not effort.
109	- Hiding bad news in the middle. If a workstream is RED, it belongs in the executive summary, not buried in a table footnote. Executives should never be surprised.
110	- GREEN status with caveats. "GREEN — on track assuming the vendor responds by Friday" is YELLOW. If there is a conditional, the status is not GREEN.
111	- Risks without mitigations. Listing a risk without a mitigation plan is complaining, not managing. Every risk needs an action, an owner, and a trigger for escalation.
112	- Skipping the decisions section. If leadership reads the report and does not know what you need from them, the report failed its primary purpose. Be explicit about asks.
113	- Inconsistent reporting periods. Mixing "this week" and "this month" data in the same report makes trends unreadable. Pick one cadence and stick to it.
114