Updated · All guides
The short answer
A good weekly executive status report fits on one page and reports by exception. It opens with one headline sentence, shows the portfolio at a glance, ranks the projects that need attention by risk, gives the cause of each problem, and ends with the decisions leadership must make this week. Everything else is detail that belongs in a link, not in the report.
The template
Copy it into an email, a document or a slide. Replace the brackets; delete any section that is empty this week rather than writing "nothing to report".
WEEKLY DELIVERY BRIEF: [Portfolio name], week of [date] 1. HEADLINE [One sentence: the overall state, and the one thing leadership must know.] 2. PORTFOLIO AT A GLANCE Active projects: [n] Green: [n] Amber: [n] Red: [n] Last week: Green: [n] Amber: [n] Red: [n] Forecast confidence: High [n] · Medium [n] · Low [n] 3. PROJECTS THAT NEED ATTENTION (highest risk first) [Project]: [Red/Amber], [worse/same/better] than last week Cause: [the main driver, with a number] Ask: [decision, help or "none, team is handling it"] 4. COMMON BOTTLENECKS [Bottleneck, e.g. blocked work]: [n] projects 5. DECISIONS NEEDED [Decision]. Owner: [name]. Needed by: [date]. 6. LAST WEEK'S ACTIONS [Action]: [Done / Not done, because ...] 7. CAPACITY WATCH [Teams over capacity, or leave that affects a delivery date] 8. CONFIDENCE NOTE [Forecasts that rest on missing estimates or due dates]
What each section is for
- Headline. Many readers stop here. If they read nothing else, they should know whether to worry and about what.
- Portfolio at a glance. Counts by status, compared with last week. The trend matters more than the snapshot: one red project that was amber last week is news; one that has been red for a month is a different conversation.
- Projects that need attention. Only amber and red projects, ranked by risk, three to five at most. Each needs a cause stated as a fact ("three payment tickets blocked for more than five days"), not a feeling ("some delays").
- Common bottlenecks. Problems that repeat across projects, such as blocked work or overloaded teams, usually need a portfolio-level fix rather than a project-level one.
- Decisions needed. The reason the report exists. Each decision has one owner and a date.
- Last week's actions. Closes the loop. Without it, the same asks reappear every week and nobody notices.
- Capacity watch. Approved leave and over-allocated people explain many slips before they happen.
- Confidence note. A forecast built on missing estimates is a guess. Saying so protects you when the date moves.
A worked example
Here is the template filled in for a portfolio of twelve projects. The data is illustrative.
WEEKLY DELIVERY BRIEF: Sample Portfolio, week of 2 November 1. HEADLINE 4 of 12 projects need attention; Customer Portal is red because payment work is blocked. 2. PORTFOLIO AT A GLANCE Active projects: 12 Green: 8 Amber: 3 Red: 1 Forecast confidence: High 5 · Medium 4 · Low 3 3. PROJECTS THAT NEED ATTENTION Customer Portal Revamp: Red (risk 78) Cause: 3 work items blocked more than 5 days; two engineers overloaded Ask: approve moving one engineer from Partner Onboarding for two weeks Mobile Checkout: Amber (risk 61) Cause: estimate coverage fell below 60%, so the release date is uncertain Ask: none; team is re-estimating the QA cycle this week API Gateway Hardening: Amber (risk 54) Cause: behind plan two weeks running (SPI below 0.9) Ask: confirm whether the security review can start in parallel 4. COMMON BOTTLENECKS Blocked work: 3 projects · Team overload: 2 projects 5. DECISIONS NEEDED Engineer move to Customer Portal. Owner: CTO. Needed by: Wednesday. 8. CONFIDENCE NOTE 3 forecasts are low confidence; treat their dates as planning gaps.
Sections 6 and 7 were empty this week, so they were left out. The whole report takes under five minutes to read, and the one decision that matters is impossible to miss. See the same portfolio as a full executive brief.
Rules that keep the report useful
- Report by exception. Green projects get a count, not a paragraph.
- Give every red a cause and an ask. A red with no ask tells leadership to worry without telling them how to help.
- Use numbers for causes. "Blocked for more than five days" can be checked; "some blockers" cannot.
- Keep colours consistent. Green, amber and red should mean the same thing every week and on every project. Define them once, for example by a risk score band.
- Separate the forecast from your confidence in it. "Likely to land on 14 March, low confidence because half the work is unestimated" is more honest than a firm date.
- Send it at the same time every week. A predictable rhythm is what turns a report into a habit.
Common mistakes
- Status set by the project manager alone. Self-reported status tends to stay green until the problem is impossible to hide. Base status on signals such as delay, blocked work and team load.
- Too much detail. Sprint burndowns and full issue lists belong in project reports. Executives need the exceptions and the asks.
- No comparison with last week. Without a trend, leaders cannot tell a new problem from an old one.
- Hours spent compiling it. If the PMO copies numbers from Jira into slides every week, the report arrives late and goes stale fast.
Producing it without the manual work
Most of this template can be computed rather than typed. A software delivery intelligence tool scores each project for risk from the underlying signals, ranks the portfolio, names the main bottleneck and reports forecast confidence separately.
Exentras does this from your Jira Cloud projects, team allocation and approved leave, and produces a weekly executive brief in the same shape: headline numbers, projects ranked by risk with their main bottleneck, active alerts and forecast reliability. You add the decisions and context only you know. See how the Jira connection works or compare plans.