Template for a project summary: a one-page wrap-up

A project summary is a one-time document that answers three questions for someone who was not in the room: what was this project, did it work, and what happens next? It is not a status report (that recurs while work is in flight) and it is not a closure report (that is the formal sign-off). It is the short, durable artifact a stakeholder reads in two minutes, six months later, to remember what you actually shipped. Write it for that reader, lead with the result measured against the original goal, and keep it to one page.

This page gives you a copy-pasteable template, a filled-in example, and clear rules for what to leave out. The hardest part of a project summary is not the format. It is resisting the urge to narrate the journey. Nobody reading a summary wants the diary. They want the outcome and the lessons.

What a project summary is for (and what it is not)

The word "summary" gets stapled onto a lot of different documents, and they are not interchangeable. A project summary is the standalone overview, written once, usually at kickoff (to align everyone on intent) or at close (to record what happened). It is short by design. The detailed plan, the running status reports, and the formal closure paperwork live elsewhere.

People conflate it with three things it is not:

• A status report. That is the recurring snapshot of an in-flight project: where it stands this week and what decision you need. If you want that, use the project status report example instead. The two link, but they do different jobs.
• A closure report. That is the formal, often signed document that confirms deliverables were accepted and the project can be shut down. Per the PMBOK Guide, the final report at close measures the project against the success criteria in the charter: scope, schedule, cost, and quality (PMI / PMBOK 6th edition summary). A project summary can feed that report, but it is lighter and meant for humans to read, not to file.
• A project plan. That is forward-looking and detailed. A summary is the compressed version a sponsor reads instead of the plan.

A project summary template you can copy

Here is the full template. It works as a kickoff summary or a closeout summary; the section that changes is "Outcome." Paste it into a Notion doc, an email, or a Confluence page and fill it in. Keep it to one page.

PROJECT SUMMARY

Project:        [Project name]
Owner:          [Name / role]
Date:           [YYYY-MM-DD]
Status:         [Planned | In progress | Complete | Cancelled]
Timeframe:      [Start] to [End or target end]

PURPOSE (1-2 sentences)
[Why this project existed. The problem it set out to solve and for whom.]

GOAL AND SUCCESS CRITERIA
- [The single measurable outcome that defined success]
- [Any secondary targets: scope, budget, deadline]

SCOPE
- In scope:  [What the project covered]
- Out of scope: [What it deliberately did not, to prevent re-litigation later]

OUTCOME (for a closeout) or PLAN (for a kickoff)
- [Result against each success criterion above. Hit, missed, or partial.]
- [Headline deliverables shipped, with a link]

KEY DECISIONS
- [Decision]: [why, and what it ruled out]

RISKS AND OPEN ITEMS
- [What is still unresolved, who owns it, by when]

LESSONS LEARNED (closeout only)
- Keep:   [What worked and should be repeated]
- Change: [What to do differently next time]

NEXT STEPS
- [The handful of actions that follow from this summary, with owners]

Two choices make this template work. First, "Goal and success criteria" comes before "Outcome," so a reader can judge the result against the bar you set, not a moving target. Second, "Out of scope" is explicit. Six months on, the most common argument is "I thought this project would also do X." Writing down what you did not do is cheap insurance.

A worked example, filled in

Abstract templates are easy to nod at and hard to copy. Here is the same template filled in as a closeout summary for a fictional onboarding revamp, so you can see the difference between reporting an outcome and narrating activity.

PROJECT SUMMARY

Project:        New-user onboarding revamp
Owner:          Priya Shah, Product Lead
Date:           2026-06-14
Status:         Complete
Timeframe:      2026-03-01 to 2026-06-10

PURPOSE
First-week drop-off was 48% and support tickets from new users were
rising. This project rebuilt the first-run experience to get users to
their first saved project faster.

GOAL AND SUCCESS CRITERIA
- Cut day-7 churn from 48% to under 35%
- Ship without slipping the Q2 release date

SCOPE
- In scope:  signup flow, first-run checklist, three in-app tooltips
- Out of scope: pricing page, mobile app, email nurture sequence

OUTCOME
- Day-7 churn: 48% -> 31%. Beat the target.
- Shipped June 10, inside the Q2 window. Hit the date.
- Support tickets from week-one users down 22% month over month.

KEY DECISIONS
- Cut the mobile flow from v1 (decided Apr 9): kept the date but
  leaves mobile onboarding unchanged for now.
- Chose a checklist over a guided tour: lower build cost, tested better.

RISKS AND OPEN ITEMS
- Mobile onboarding still uses the old flow. Owner: Priya. Scope a
  phase 2 by July 15.

LESSONS LEARNED
- Keep:   weekly usability tests caught the tour problem early.
- Change: lock scope sooner. The mobile debate cost us two weeks.

NEXT STEPS
- Scope mobile onboarding phase 2 (Priya, by Jul 15)
- Roll the checklist pattern into the team-invite flow (Marco, Q3)

Notice what this does. A reader who has never seen the project gets the result in the first line of the outcome (churn beat the target, shipped on time), then the decisions that shaped it, then what is still open. They understand the whole project in under a minute. That is the test. The next steps and open items, with owners and dates, come straight from how you track work day to day; see action item tracking and the action items template for keeping that list clean as the project runs.

Kickoff summary vs closeout summary

The template flexes for both ends of a project. The bones are the same; the emphasis shifts. Pick by where you are.

Kickoff summary

• Written: at the start, to align everyone
• Emphasis on purpose, goal, and scope
• Outcome section becomes a short Plan
• Pairs with a real kickoff agenda

Closeout summary

• Written: at the end, to record what happened
• Emphasis on outcome vs the goal you set
• Adds Lessons learned and Next steps
• Feeds the formal closure report

A kickoff summary is the one-page version of intent that you write so the team and the sponsor share the same picture before work starts. It is the artifact you point back to when scope drifts. If you are running the meeting that produces it, the project kick-off meeting agenda gives you the structure, and the summary is what you publish afterward.

A closeout summary is written at the end, and its center of gravity is the outcome and the lessons. The lessons section is the part teams skip and later wish they had. Write it while the project is fresh, not three weeks later when nobody remembers why you cut the mobile flow.

What to leave out

A project summary fails the same way a status report fails: it tries to prove the team was busy instead of telling the reader what happened. The fixes are mostly subtractive.

1. 1

   Cut the timeline narrative

   No week-by-week story. The reader wants the result, not the path. Decisions matter; the order you made them in usually does not.

2. 2

   Cut effort language

   'The team worked hard on...' is not an outcome. State what shipped and whether it hit the goal.

3. 3

   Cut anything that lives elsewhere

   Full requirements, the Gantt chart, the meeting notes. Link to them. The summary is a doorway, not a warehouse.

4. 4

   Keep it to one page

   If it spills past a screen, you are summarizing the process, not the project. Detail goes in the appendix or the linked plan.

Where the content comes from

The format is the easy part. The hard part is assembling a summary without spending an afternoon reconstructing what happened from memory. Most of a project summary is already sitting in two places: your project tracker (for deliverables, scope, and next steps) and your meetings (for the decisions, the reasons behind them, and the risks raised along the way).

The decisions and lessons are the parts people get wrong, because they live in conversation and rarely get written down in the moment. You remember that you cut the mobile flow; you do not remember it was April 9, or the exact reasoning, unless something captured it. If your project meetings are recorded and summarized, those decisions and owners are captured as they happen, and writing the summary becomes a copy-and-trim job. A browser-based notetaker like Scribbl records and summarizes Google Meet calls with no bot joining the room, so the decisions and action items from your kickoff and your retro are already structured by the time you sit down to write. Pull the decisions into "Key decisions," the open questions into "Risks and open items," and the retro takeaways into "Lessons learned." For the meeting side of this, see how to take better meeting notes and summarize a meeting.

That said, do not over-tool a one-page document. For a small project, the template above pasted into a doc and filled in by hand is the right call. The notetaker earns its place when you are running several projects at once and cannot hold every decision in your head; for that load, see how to manage multiple projects.

Frequently asked questions

What is the difference between a project summary and a status report?

A project summary is written once, as a standalone overview at the start or end of a project. A status report is a recurring snapshot of an in-flight project: where it stands this week and what decision you need from the reader. Use a summary to record what a project was and whether it worked; use the project status report example for the weekly update while work is happening.

How long should a project summary be?

One page. If a reader has to scroll past a screen, you are summarizing the process instead of the project. Lead with purpose and outcome, keep each section to a few bullets, and push full detail into the linked plan, tracker, or meeting notes. The summary is a doorway to the detail, not a replacement for it.

When should I write a project summary?

Twice, ideally. Write a kickoff summary at the start so the team and the sponsor share the same picture of purpose, goal, and scope before work begins. Write a closeout summary at the end, while the project is fresh, to record the outcome against that goal plus the lessons learned. Writing the closeout weeks later means the decisions and reasons have already faded.

Is a project summary the same as a closure report?

No. A closure report is the formal, often signed document that confirms deliverables were accepted and the project can be shut down; the PMBOK final report measures the project against the charter's success criteria of scope, schedule, cost, and quality (PMI / PMBOK 6th edition summary). A project summary is the lighter, human-readable overview that can feed the closure report but is meant to be read, not filed.

What should a closeout project summary include that a kickoff one does not?

Two sections. A closeout summary reports the actual outcome against each success criterion (hit, missed, or partial) and adds "Lessons learned" split into what to keep and what to change. A kickoff summary replaces the outcome with a short plan and has no lessons section yet. Everything else, purpose, goal, scope, decisions, and next steps, stays the same.