A Status Report That Lies Is a Status Report That Kills the Program.
The integration milestone missed. The vendor wanted Amber. The PMO Lead surfaced a bank-specific governance rule that made Red the harder and better choice.
43 Percent Is Not 75 Percent
The July status report was due on the 18th. The program manager’s normal rhythm: draft on the 14th, Tier 1 pre-reads dispatched on the 15th, 1:1s on the 16th and 17th (Post 04 cadence), report published on the 18th. On the 15th, Raman sent the integration test coverage metric that broke the rhythm.
M3a checkpoint number two was the first formal test milestone under the core banking integration workstream after the milestone converted from Proposed to Committed on 3 April (Post 05). The checkpoint target was 75 percent integration test coverage. Actual coverage on 15 July was 43 percent. The gap was not marginal. It was a miss.
Volkov called the PM that afternoon. His position was clear, and within his own frame, entirely reasonable.
The temptation was to agree. Volkov was credible, the recovery plan sounded plausible, and avoiding a Board Risk Committee conversation in the middle of a tight schedule would feel like the prudent choice. The PM had seen junior program managers make this call dozens of times. They were usually wrong. The reason is not obvious from inside the program; it becomes obvious when you look at what Amber and Red actually mean inside Atlas Bank’s governance rules.
Ahmed Hassan, reading the draft on 16 July, flagged a bank-specific governance rule the PM did not know. A Red rating on a monthly status report triggers automatic Board Risk Committee notification within 10 business days. That was the rule Volkov wanted to avoid. Hassan surfaced the second part of the rule, which changed the calculation: two consecutive Amber-to-Green transitions without documented remediation count as a Red for governance purposes, triggering the same Board Risk notification but with the added finding that the program was gaming the rating. Amber today that fails to land Green in August would be worse, not better, than Red today.
The PM now had three options. Show Red honestly and accept Board Risk Committee notification. Show Amber and accept the risk of the two-strike rule firing next month. Or invoke a third category Atlas Bank’s PMO rarely used called Amber-Red for situations in transition. The third option looked clever. It was not.
Red Is Not a Verdict. It Is a Request for Help.
The PM went back to Volkov on the morning of 17 July with a framing that changed the conversation. The argument was not that Red was punishment for missing the checkpoint. It was that Red got the program the support it needed faster than Amber did. Idris’s calendar clears in hours for a Red conversation. It clears in weeks for an Amber one. The Board Risk Committee notification forces Volkov’s own senior partner at the integrator firm to appear in a room where the question “why is this happening” gets asked at a level that can actually answer it. That conversation does not happen under Amber.
Volkov did not love the call. He agreed to it. The status report was published on 18 July with M3a Red, schedule variance on the Build and Integration phase at minus three weeks, and an explicit recovery plan with time-bounded milestones and named owners. The recovery plan attached to the Red rating is what turned it from a verdict into a commitment.
Raman’s diagnostic, produced on 16 July: the coverage gap was concentrated in the core banking query paths that hit legacy tables with indexes never designed for the access patterns Falcon generated. The Post 05 data profiling baseline had been accurate at profiling volume. Production-equivalent load patterns revealed index gaps that profiling had not exercised. Fix: $340K of core banking indexing work, delivered in three sprints across July and August.
The indexing work was exactly the scenario R07 (legacy core query performance under load) had been budgeted for. Post 06 had allocated $340K against R07. The Red rating triggered the contingency drawdown. R07’s full $340K went to the indexing work. R08 (vendor under-delivers at milestone) held $400K; $340K was also drawn to cover the re-baselining work from the integrator side (additional integration test cycles, not penalty offset). Both drawdowns were documented in the status report with references to the Risk Register and the authorising steering minutes.
The decision itself was not hard. The work to prepare for the decision had been done months earlier. R07 was in the Risk Register with an allocation against exactly this scenario. R08 was there too. The Financial Plan (Post 09) had the structure to document the drawdowns against the three views. The Engagement Plan (Post 04) had the 1:1 pre-read mechanism that meant Idris was not seeing Red for the first time in the steering meeting. When the moment arrived on 17 July, the question was not how to design a response. It was how to execute a response the earlier posts had already designed.
Drafting the Status Report
The prompt below uses SPACE: Situation, Problem, Audience, Context, Example. SPACE earns its slot here because the Audience dimension matters for status reporting in a way it does not for most templates. The same facts produce different documents for the program team, for steering, and for the Board Risk Committee. Forcing the prompt to specify audience prevents the “one report serves everyone” failure that produces status reports that serve nobody well. SPACE is less widely cited than RACE or CRAFT, but for any artifact where the same data needs framing for different readers, Audience earns the dimension.
Status Report Draft, Extract
The AI produced a status report structured around the SPACE framework. The RAG summary and three flagged items are shown below; the full recovery plan and risk register cross-references went into the published artifact.
Overall program rating: RED. Rationale: M3a checkpoint 2 missed by material margin (43% actual vs 75% target); schedule variance -3 weeks on Build and Integration phase; contingency drawdown engaged against two named risks (R07, R08).
By workstream:
- Core banking integration — RED. M3a checkpoint 2 miss. Recovery plan attached.
- Microservices platform — AMBER. Two sprint velocities below baseline; team health concerns.
- Mobile app — GREEN. On schedule, on scope.
- Regulatory reporting — GREEN. On schedule; Post 09 Financial Plan published supporting audit trail.
- Infrastructure — GREEN. Scale Plan capacity gate fired 18 June per Post 02; expansion completed on schedule.
1. Rating rationale requires explicit metric citation. Default status report structure allows rating without evidence. Recommend every RAG rating carries a “status rationale” row citing the specific fact driving the rating. Without this, auditors and steering cannot distinguish genuine ratings from PM judgment.
2. Recovery plan as narrative vs time-bounded milestones. Current draft writes recovery as prose. For a Red rating, recovery must be executable: time-bounded milestones, named owners, escalation triggers that convert the Red to sustained Red if not met. Prose recovery is aspirational; structured recovery is a commitment.
3. Governance impact of Red rating not named. Red triggers Board Risk Committee notification within 10 business days per Atlas Bank PMO rules. This consequence should be explicit in the status report so the audience knows what the rating sets in motion. Omitting it means the program is sending a signal without naming it.
July 2025 Status Report, Extract
Published 18 July 2025. RAG summary, workstream detail with status rationale, governance impact, and variance tracking shown below. Recovery plan and contingency draw log on the next page.
| Workstream | Rating | Owner | Status Rationale |
|---|---|---|---|
| Core banking integration | RED | Volkov | M3a checkpoint 2 coverage 43% actual vs 75% target. Legacy core query paths indexing gaps. Source: Raman diagnostic 16 Jul. |
| Microservices platform | AMBER | Raman / Park | Sprint velocity 32 points actual vs 48 points baseline for sprints 11 and 12. Source: Jira velocity report. |
| Mobile app | GREEN | Park | On schedule, 3 of 4 Phase 2 milestones complete; no defects above P2. Source: Jira board + QA report. |
| Regulatory reporting | GREEN | Okonkwo | Monthly CB reporting feed operational since 1 Jul, baseline score 3.4/5 (Post 08 B09 target 4.5). Source: CB quarterly assessment. |
| Infrastructure | GREEN | Alemu | Scale Plan capacity expansion completed 18 Jun per Post 02 gate; production-like environment stable. Source: Dynatrace APM. |
| Metric | Plan | Actual | Variance | Commentary |
|---|---|---|---|---|
| M3a integration test coverage | 75% | 43% | -32 pp | Materially under target; indexing remediation in flight. |
| Phase 2 schedule | On plan | -3 weeks | -3 weeks | Recovery plan targets parity by end-Aug. |
| Program spend to date | $4.52M | $4.43M | -$90K | Slight under-spend; timing rather than saving. |
| Reserve position (unallocated) | $328K | $328K | $0 | Drawdowns from allocated risk buckets, not reserve. |
Time-bounded milestones with named owners and explicit escalation triggers. Recovery plan is a commitment attached to the Red rating; failure to hit any milestone converts Red to sustained Red and escalates to Board.
| Milestone | Target | Owner | Escalation Trigger |
|---|---|---|---|
| Indexing sprint 1 complete | 29 Jul 2025 | Raman | Coverage below 52% on 30 Jul → sustained Red. |
| Indexing sprint 2 complete | 5 Aug 2025 | Raman | Coverage below 62% on 6 Aug → sustained Red + Board escalation. |
| Indexing sprint 3 complete | 12 Aug 2025 | Raman | Coverage below 70% on 13 Aug → sustained Red + formal recovery review. |
| M3a checkpoint 3 target | 22 Aug 2025 | Volkov | Coverage at or above 80%. Red resolves to Green on confirmation. |
| Date | Risk | Purpose | Draw | Allocation balance |
|---|---|---|---|---|
| 17 Jul 2025 | R07 Legacy core query performance | Core banking indexing work across 3 sprints (Jul/Aug) to close query paths identified by load testing. | $340,000 | $0 / $340K |
| 17 Jul 2025 | R08 Vendor under-delivers | Integrator re-baselining: additional integration test cycles, recovery-plan validation support, extended vendor engagement through August. | $340,000 | $60K / $400K |
| Total drawdowns this month | $680,000 | From allocated risk buckets; unallocated reserve unchanged at $328K | ||
For Sponsor (Idris). Approve Board Risk Committee notification dispatched 18 July. Status: approved verbally 17 July; paperwork dispatched 18 July.
For Steering (3 August). Ratify R07 and R08 drawdowns against Risk Register allocations. Status: scheduled for 3 August steering agenda item 4.
For Board Risk Committee (30 July). Acknowledge Red rating and recovery plan; no decision required unless sustained Red at August checkpoint.
- Added status rationale row under every RAG rating. AI produced ratings with narrative explanation. PM added explicit rationale column citing the specific metric and data source. No rating appears in the published report without evidence the auditor can verify.
- Restructured recovery plan as time-bounded milestones with escalation triggers. AI wrote prose recovery. PM converted to table with 4 milestones, named owners (Raman for indexing, Volkov for vendor re-baselining), and explicit conversion triggers that turn Red into sustained Red if milestones are missed.
- Added governance impact banner at the top of the report. AI omitted the Board Risk notification consequence. PM added a dedicated banner stating the notification timeline, Idris briefing status, and Board Risk meeting date. The rating and its governance consequence travel together.
- Linked drawdowns explicitly to Risk Register IDs. AI referenced risks generically. PM cited R07 and R08 with allocation balances (R07 fully drawn, R08 $340K of $400K). The Financial Plan from Post 09 is the reference; every dollar traces.
- Held the line on Red when Volkov requested Amber. Not an edit to the AI output; an edit to the PM’s first instinct. Amber with August catch-up plan would have been easier to write. The bank governance rule Hassan surfaced made Red the honest rating, and honest ratings get the program the support it needs.
The Board Risk Committee notification triggered by the Red rating put the integrator’s senior partner in a room with Idris on 30 July. The conversation surfaced what Volkov had not raised: his team had been under-resourced for three weeks due to a competing client emergency. Two senior engineers had been temporarily reallocated without Falcon leadership’s knowledge. Resource augmentation was agreed within five business days. The indexing work landed as planned. M3a checkpoint 3 on 22 August hit 82 percent coverage against the 80 percent target. Red converted to Green at the August status report. The month-7 vendor dispute that was foreshadowed in Post 01 resolved through governance discipline, not through confrontation. If the July status report had lied, the August conversation would never have happened, and the miss would have compounded.
A fictional case study for teaching purposes. Atlas Bank, Project Falcon and all named individuals are invented. Technologies are industry-standard and publicly available.