An executive summary for a project status report is a short paragraph that tells an executive whether the project is on track, what changed since the last report, the one risk or blocker that matters and what it will cost, and the decision or help you need, from whom, by when. Write it last, put the status first, and keep the same order in every report. A fixed order makes bad news hard to bury.
Templates usually give the summary a place but not the wording: the ProjectManager executive status report template puts the executive summary in the report header and includes a separate section for dependencies and decisions needed.
What goes in a status report executive summary?
A status report executive summary needs four parts, each one sentence where possible: overall status and trend, what changed, the top risk or blocker with its impact, and the decision or help needed with an owner and date. If a part is empty, say so in a few words rather than dropping it.
Use this formula as written:
- Status and trend. "[Project] is [green / amber / red], [improving / steady / worsening] since [last report date]."
- What changed. "Since the last report, [deliverable or milestone] was [completed / delayed / approved], which means [effect on the plan]."
- Top risk or blocker. "The main risk is [risk]. If it is not resolved by [date], [milestone] moves to [date] / costs [amount]."
- Decision or help needed. "We need [person] to [decide / approve / unblock] [specific item] by [date]. Without it, [consequence]."
When nothing is needed, the last sentence still appears: "No decision needed this period; the next sign-off is [item] on [date]." Keep the request as the last sentence so a sponsor always knows where to find it.
How do you choose green, amber or red before writing?
Choose the rating from criteria agreed with the sponsor in advance, then write the summary to match it. The rating should come from schedule, budget, scope and open blockers, not from how the team feels. Write the criteria down once and attach them to the report template so every project manager rates the same way.
The ProjectManager template refers to green, yellow and red indicators without defining each one, so you will need to set your own. A starting set you can adapt:
| Rating | Schedule | Budget | Blockers | What the summary must do |
|---|---|---|---|---|
| Green | Milestones on plan or within [agreed tolerance] | Forecast within [agreed tolerance] | None needing the sponsor | Confirm, note the next sign-off |
| Amber | A milestone at risk, recoverable with action | Forecast outside tolerance but recoverable | One needing a decision soon | Name the risk, the recovery plan and the decision |
| Red | A committed date will be missed without intervention | Forecast exceeds approved budget | One the team cannot resolve | Lead with the impact and the decision |
Agree the tolerances with your sponsor before the first report, not when a project first slips.
What does a good executive summary look like for each status?
A good executive summary uses the same four parts at every rating; only the emphasis changes. Green confirms and points to the next sign-off. Amber names the risk and the recovery plan. Red opens with the impact and the decision. The examples below are illustrative, with placeholders for every name, date and figure.
Green example
[Project] is green and steady. Since [last report date], the team completed [deliverable], and [next milestone] remains on track for [date] within the approved budget. The main risk is [risk], which is being managed by [owner] through [action]. No decision needed this period; the next sign-off is [item] on [date].
Amber example
[Project] is amber, down from green, because [cause]. [Milestone] is at risk of moving from [date] to [date]. The team will recover [amount of the slip] by [action], provided [condition]. We need [sponsor] to decide between [option A] and [option B] by [date]; after that, the later date becomes the plan.
Red example
[Project] is red: [milestone] will miss [date] by [period] unless [intervention]. This happened because [cause], confirmed on [date]. The impact is [effect on launch, cost or dependent teams]. We need [sponsor] to [approve / decide / provide] [specific item] by [date]; our recommendation is [option], which brings [milestone] back to [date] at a cost of [amount].
How should the summary change when the project is amber or red?
When a project is amber or red, move the impact and the decision request up, and cut background. The reader should know what is late, what it affects and what you need from them before reaching any explanation. Explanation can follow in the body of the report.
Three checks for an off-track summary:
- The first sentence contains the rating and the consequence, not the history.
- The decision request names options and your recommendation, so the sponsor can answer rather than investigate. Plan.io's guide shows this approach with a resource decision framed as costed options.
- The cost of waiting is stated in plain terms: what slips, by how much, if no decision arrives by the date.
How do you write a decision request a sponsor will answer?
A decision request a sponsor will answer names one decision, the options, your recommendation, the deadline and what happens if the deadline passes. Ask one person, not "leadership". Put the request at the end of the summary and repeat it in the email subject line or meeting agenda.
Template:
Decision needed from [name] by [date]: [question]. Options: [A], which [effect], or [B], which [effect]. We recommend [A] because [reason]. If we have no answer by [date], [default action or consequence].
In Unblockd, a sponsor answers asks by email with one-tap answers (no account), or by replying to the email.
What does a before-and-after rewrite look like?
Start with a typical draft that lists activity, then rewrite it so the rating, the cause, the impact and the request come first. Instructional Solutions shows this move with a status report example whose effective version leads with the delay, who paused the work and the immediate next action.
Here is the same move on a typical draft, with placeholders.
Before (illustrative):
This period the team held [several] workshops with [department], continued configuration of [system], and worked through a number of vendor questions. Some items are taking longer than expected. We remain committed to the go-live and will keep monitoring.
After:
[Project] is amber, down from green. Vendor delays on [component] put the [date] go-live at risk by [period]. The team can hold the date if [vendor] delivers by [date]; otherwise go-live moves to [date]. We need [sponsor] to escalate with [vendor contact] by [date].
The first version describes effort. The second gives a rating, a cause, an impact and a named request.
How do you keep a weekly or monthly summary consistent?
Hold the four-part order fixed from one report to the next and change only the content. A weekly or monthly summary should say what changed since the last report and which way the trend is moving, so the sponsor can lay reports side by side and see the direction of the project.
Most organizations report weekly, with bi-weekly for moderate activity and monthly for long-term or portfolio work, according to ProjectManager.
Practical habits:
- Open last period's summary before writing the new one, and state the rating change explicitly: "amber, up from red".
- If last period's decision request was answered, say so and say what the team did next. If it was not, repeat it with the new consequence.
- Keep risk names identical between reports so a reader can track them.
- Retire a risk in writing ("[risk] closed on [date]") rather than letting it vanish.
How do you get project managers to write summaries the same way?
Put the formula, the rating criteria and one filled-in example inside the report template your project managers already use. Then review the first few summaries from each person against the same checklist, and give feedback on the summary before anything else in the report. Shared wording makes summaries comparable across projects.
A review checklist you can paste into your template:
- Does the first sentence give the rating and the trend?
- Does the rating match the agreed criteria, given the dates and budget in the body?
- Is there a named risk with a stated impact?
- Does the last sentence name a person, an action and a date, or state that nothing is needed?
- Could the sponsor act on this without reading the rest of the report?
Make it safe to report amber early. Say in your team meeting: "An early amber with a recovery plan is a good report. A green that turns red without warning is the problem." When the summary format forces a risk and a request every time, a project that looks green on top but has problems underneath shows up sooner.
What mistakes should you check for before sending?
Before sending a status report executive summary, check that it is not a list of activities, that the rating matches the evidence in the report body, and that the request has an owner and a date. Check for these faults before sending:
- Activity instead of status. "Held workshops" tells the reader nothing about the plan. Replace with the effect on a milestone.
- Rating without reason. Every amber or red needs a cause in the same paragraph.
- Jargon and internal codes. Use the deliverable names your sponsor uses.
- A request to nobody. "Leadership support is needed" becomes "[Name] to approve [item] by [date]."
- Writing it first. Draft the report body, then write the summary from it, so the two agree.
Your next step: copy the four-part formula and the rating table into your current status report template, then rewrite this period's summary with it before the next sponsor meeting.