How do you write an executive summary that decision makers actually read?

What should an executive summary actually contain?

An executive summary should answer three questions in this order: what do you need from me, what is the current state, and what changed since the last time I looked. If a section does not directly help the reader answer one of those questions, it does not belong on the page.

The structure that works in practice is short and predictable. One paragraph at the top with the ask. Three small sections underneath labelled something close to "where we are," "what changed," and "what we need." A line at the bottom with a date and a name. That is the whole document.

What goes inside each section matters more than the headers. "Where we are" is the current status in concrete terms: scope locked or moving, budget burn against plan, milestone hit or missed, blockers active. Pull the underlying numbers from your project tool rather than typing them by hand. If you run projects in Breeze, the milestone view and time tracking reports already give you the inputs in the format you need, which removes a whole class of "is this number right" mistakes.

"What changed" is the part most writers skip and most readers want. Executives do not need a recap of the whole project. They need a delta. What moved since the last summary, why it moved, and whether it changes the trajectory. Three bullets is usually enough. If you cannot find three things that changed, you do not need to send a summary.

"What we need" is the ask. Be specific about what you want them to do, by when, and what happens if they do not. "Approve the additional 14 days of design runway by Friday so engineering can start week of the 12th" is an ask. "Awaiting executive guidance on next steps" is not.

Where most executive summaries fall apart

Most summaries fail in predictable ways. They bury the decision. They confuse motion with progress. They hedge instead of asking. Below are the patterns that show up over and over and the versions that actually move things forward.

The pattern under all of these is the same. Bad summaries describe activity. Good summaries surface decisions. Activity is what your project board is for. A summary that recaps activity is just a worse project board.

Why do most executive summaries get ignored?

They get ignored for three reasons, usually all at once. They are too long, the decision is buried somewhere on page two, and there is no clear ask at all. An exec opens the doc, scans the first paragraph, sees no question directed at them, and closes the tab. HBR writing guidance has made this same point for years. They are not being lazy. They are doing exactly what the document is asking them to do, which is nothing.

Length is the easiest fix and the one most writers refuse to make. The instinct is to include everything because everything feels important to the person who lived inside the project for two months. It is not important to the reader. The reader has eight other projects to track this week. Cut until it hurts, then cut more. If the summary cannot fit on one page in a normal font, the writer has not finished thinking yet.

The buried lede happens when the writer is uncomfortable with the ask. They warm up to it. They explain the context first. They lay out the history of how the decision came to be needed. By the time the actual question appears, the reader has either skimmed past it or moved on. The fix is to write the ask first and the support second, even though it feels backwards. The reader will get to the context if they need it. They will not get to the ask if it is in the wrong place.

The third failure is hedging. "We may need to consider revisiting the timeline" is not a request. It is a writer protecting themselves in case the answer is no. Executives notice this immediately and treat the whole document with suspicion. McKinsey research on executive communication finds this hedging instinct is one of the most expensive habits middle managers carry. Be specific. Name the option you want. If you genuinely do not know what to recommend, say that plainly and list the two or three real choices with the tradeoffs — the same instinct shows up in other new-PM mistakes worth knowing about.

A before and after that shows the difference

Here is the kind of opening paragraph that lands in inboxes constantly. It is real-sounding because most teams write something close to it.

Before: "This summary provides an update on the customer portal redesign project, which has been underway since March. The team has been working diligently across design, engineering, and content workstreams, and we have made meaningful progress against the original plan. Several challenges have emerged that the team is actively managing, and we wanted to share an update on the current state of the project as well as our outlook for the coming weeks."

That paragraph is 76 words and contains zero information. The reader knows there is a project, the team is working on it, things are happening, and there will be more updates. They cannot make any decision from it.

After: "We need approval to cut the live chat feature from the portal redesign by Friday. Cutting it lets us ship the rest on October 14 as planned. Keeping it pushes launch to November 6. The team recommends cutting; engineering estimates we can ship live chat in a follow-up release four weeks after launch."

That version is 54 words and the executive can act on it without reading another line. The rest of the summary becomes optional reading: the three milestones hit this month, the one that slipped, the vendor risk on the auth integration. Numbers and dates from the project dashboard, not adjectives. If those details live in Breeze or wherever the team tracks work, the writer is copying them, not inventing them, which makes the whole document more trustworthy.

When a summary is the right format and when it is not

An executive summary is the right tool when there is a decision to drive, a clear audience that can make that decision, and enough complexity that a verbal update will not stick. If any of those three are missing, the format is wrong and you should pick something else.

When a written summary fits

Use a summary when you need a yes or no from someone who is not in your daily standup. Budget approval, scope changes, timeline shifts, vendor decisions, go or no-go for launch. The reader needs to think about it, possibly forward it, possibly come back to it. A written one-pager works because it can travel and be referenced.

It also fits when multiple execs need the same information at the same time. A summary keeps everyone on the same page literally. If you brief one exec verbally and email another, the two will end up with different versions of the project in their heads and you will spend the next month reconciling them.

When a meeting is better

If the decision needs back and forth, the summary is the wrong format. Anything with real tradeoffs, anything where the answer depends on information the exec has and you do not, anything political. Put those in a 20-minute meeting and bring a one-pager as the pre-read, not as the deliverable. The summary becomes a starting point for the conversation rather than a substitute for it.

Meetings are also better when the project is in genuine trouble. A written summary of a failing project reads like an excuse, no matter how carefully it is written. Sit in a room. Take the heat. Leave with a decision.

When no format is needed

If there is no decision to drive and nothing has changed materially, do not send a summary. Post the status to the project board and let people pull it if they want it. Sending a summary for the sake of sending one trains executives to ignore your summaries, which means the next one, the one that actually matters, will also get ignored. Use the Breeze dashboard or whatever tool you run as the standing source of truth. Reserve summaries for moments that genuinely need a decision.

A practical recommendation for the next summary you write

Write the ask first, before anything else. One sentence. What do you need, by when, and what is the consequence if you do not get it. Do not move on until that sentence is sharp enough to stand alone.

Then write the three sections underneath. "Where we are" gets the current status in numbers pulled from your project tool. Milestone counts, budget burn, days ahead or behind, blockers active. Two or three lines each. The simple project plan you set up at kickoff is usually the right source for those baselines. "What changed" gets the delta since the last update, three bullets maximum. "What we need" restates the ask from the top in slightly more detail, with the options if there is more than one.

Cut every adjective you can find. "Significant progress" means nothing. "Closed 14 of 18 open tickets this sprint" means something. "Major risk" is filler. "Vendor delivery slipped from October 3 to October 17, which puts us inside our two-week launch buffer" is information. PMI guidance on project reporting says the same thing in more polite language. The discipline of trading adjectives for numbers will cut your draft in half and make it ten times more useful.

Read it once as the executive will read it: only the first paragraph. If you could make a decision from that paragraph alone, you are done. If you could not, the paragraph is wrong. Rewrite it before you touch anything else on the page. The rest of the summary supports the first paragraph; it does not replace it.

Pulling the supporting numbers from a live tool like Breeze, rather than retyping them into a doc, also means the next summary takes a fraction of the time. Most of the work is deciding what to say. The data should already exist.

Quick checks before you send

Can the reader make a decision from the first paragraph alone?

If not, the paragraph is wrong. Rewrite it before sending. This is the only test that matters.

Is there a specific ask with a specific date?

"Awaiting alignment" is not an ask. "Approve by Thursday so we can start Monday" is. If you cannot name a date, you are not ready to send.

Have you cut every adjective you can?

Replace "significant," "meaningful," "considerable," and "challenging" with numbers and dates. If the number does not exist, the claim probably does not either.

The one-paragraph test

The test for any executive summary is simple. Read only the first paragraph and try to make a decision. If you can, the summary works. If you cannot, the paragraph is wrong and no amount of polishing on the rest of the page will fix it.

Try it on the next summary you write. Write the ask first, draft the three sections underneath, then delete every adjective and check that the numbers came from your project tool rather than your memory. Send the version that passes the one-paragraph test. Throw away the version that does not.