Delivery Reporting That Drives Decisions

The Problem With Most Delivery Reports

The typical weekly status report is a multi-page document listing everything that happened, every risk that exists, and every metric that moved. Leadership skims it, says "looks fine," and moves on. When something goes wrong two weeks later, everyone asks "why didn't we know?"

The problem isn't that the information wasn't there. It's that it was buried in noise. Effective reporting is not about completeness — it's about signal. What does the reader need to decide or act on right now?

The Three Audiences

Different audiences need different reports. Never send the same report to everyone.

Executive Leadership (CTO, VP Engineering, Sponsors)

What they need: "Should I be worried? Do you need anything from me?" Format: 3-line summary + RAG + one ask Cadence: Weekly (or fortnightly for stable programmes) Length: Maximum one page. Ideally 3 paragraphs.

Template:

• Progress: [One sentence on what was delivered or achieved]
• Risk: [One sentence on the biggest threat to delivery]
• Ask: [One specific decision or resource you need from them]

Example: "Checkout migration is 70% complete, on track for June release. Risk: payment provider API changes may require 2 additional sprints of integration work — we'll know by Friday. Ask: approve the contingency budget of £15K for extended testing if the API change is confirmed."

Stakeholders (Product, Business, Operations)

What they need: "What's coming, when, and what might change?" Format: Milestone tracker + dependency status + upcoming decisions Cadence: Fortnightly Length: One page + appendix if needed

Content:

• Milestone status (on track / at risk / delayed) with dates
• What was delivered since last update
• What's planned for next 2 sprints
• Dependencies on their teams or decisions
• Decisions needed from them (with deadline)

Delivery Team (Scrum Masters, Tech Leads, Engineers)

What they need: "Where are the problems and what are we doing about them?" Format: Dashboard + blocker list + improvement actions Cadence: Weekly (in the delivery review meeting) Length: Dashboard view — no written report needed

The "Progress / Risk / Ask" Framework

The most effective executive reporting format is three sections:

Progress: What moved forward. Not a list of tickets — a narrative of value delivered. "Users can now export reports in PDF format" not "Completed JIRA-1234, JIRA-1235, JIRA-1236."

Risk: What could prevent future delivery. Be specific and quantified: "If the vendor doesn't deliver the API spec by June 5, the integration sprint slips by 2 weeks, pushing the release from July 1 to July 15." Not: "There are some vendor risks."

Ask: What you need from the reader. A specific decision, resource, or action with a deadline. "Please approve the additional £15K testing budget by Friday" not "We might need more budget."

If there's no ask, say so explicitly: "No decisions needed this week. Next decision point: June 5 (vendor API spec deadline)."

Writing for Busy Readers

Lead with the conclusion

Don't build up to the point. State it first, then provide supporting detail for those who want it.

Bad: "The team completed 34 story points this sprint. Velocity has been trending upward over the last 3 sprints. However, we encountered a blocker with the payment API that consumed 2 days of the senior developer's time. Despite this, we achieved our Sprint Goal of completing the checkout flow. Overall, delivery is on track."

Good: "Delivery is on track. Sprint Goal achieved despite a 2-day payment API blocker. Velocity trending up for 3 consecutive sprints."

Use RAG with teeth

RAG status only works when Red actually means Red. Define your thresholds explicitly and stick to them:

• Green: On track. No intervention needed.
• Amber: At risk. Mitigation in progress. Leadership awareness needed.
• Red: Off track. Intervention required. Decision or resource needed from leadership.

If your report is always Green, you're either incredibly lucky or not being honest. Recalibrate.

Quantify everything

"The project is slightly behind schedule" means nothing. "We're 1.5 sprints behind the baseline plan, with a recovery plan that adds 1 sprint to the timeline" means something actionable.

One page maximum for executives

If your executive report exceeds one page, you're including too much detail. Move supporting data to an appendix or linked dashboard. The main report is the signal; the appendix is the evidence.

Automating Reporting

Manual report writing is time-consuming and error-prone. Automate what you can:

• Metrics: Pull directly from Jira/CI/CD tools into a dashboard. Never manually calculate velocity or cycle time.
• Milestone status: Link to the project plan. Status updates automatically when dates change.
• Blocker list: Auto-generated from flagged items in Jira older than 48 hours.
• Dependency status: Pulled from the dependency board.

The Delivery Manager's job is to add interpretation and narrative — not to compile data. If you're spending more than 30 minutes per week on reporting, you're doing too much manually.

Measuring Reporting Effectiveness

• Read rate: Do recipients actually read the report? (Ask them)
• Decision speed: Are decisions made faster because of the report?
• Surprise rate: Do stakeholders ever say "I didn't know about that"? If yes, reporting failed.
• Action generation: Does the report produce at least one action or decision per cycle?
• Time to produce: How long does it take to write? Target: <30 minutes per week.

If the report takes 2 hours to write and nobody reads it, stop writing it. Replace it with a 5-minute conversation or a dashboard link.

---

Download the [Stakeholder Update template](/templates) for a ready-to-use Progress / Risk / Ask reporting format.