Project Meeting Summary Template

A project meeting summary template for status meetings: overall status with a reason, milestones planned vs forecast, risks and issues with owners, dependencies on other teams and decisions. Download it free in Word or PDF, no sign-up, with an example below.

Download .docx Download .pdf

Free. No sign-up.

Dalm is a Mac app that records a meeting — a call or a room — and drafts notes from the transcript. Get early access

A project meeting summary records one status meeting for one project: where it stands against its milestones, what is at risk, what the team decided and who does what next. Its most useful line is the overall status, and that line is a judgment, so it always carries a reason — “at risk, because the backend API is a week behind” rather than a bare colour. The rest of the summary backs that judgment up: planned dates next to forecasts, risks with names against them, and the dependencies on other teams that most often explain why a date moved.

What’s in the template

The file follows a status meeting from the overall picture down to the next step:

• Header — project, date, project manager, attendees, and the overall status: on track, at risk or off track.
• Summary — two or three sentences.
• Milestones — a table: milestone, planned date, forecast and status.
• Progress since last meeting — a list.
• Risks and issues — a table: risk or issue, impact, mitigation and owner.
• Dependencies — a table: what we wait for, from whom and by when.
• Decisions — a list.
• Action items — action, owner and due date.
• Next meeting — when the project group meets again.

The template opens with one line on its purpose: a summary of a project status meeting — where the project stands against milestones, what’s at risk, what was decided and who does what next.

Project meeting summary example

Example (fictional). Names and events are invented.

Project	Customer portal redesign
Date	28 October
Project manager	Marina
Attendees	Marina, Ilya, Anya, Sergey
Overall status	At risk — backend API is a week behind

Summary
Design is finished and front-end is on schedule. Backend API slipped one week because of a dependency on the billing team. The launch holds if the API is ready by 13 November.

Milestones

Milestone	Planned	Forecast	Status
Designs approved	20 Oct	20 Oct	Done
Backend API ready	6 Nov	13 Nov	Late
Public launch	1 Dec	1 Dec	At risk

Risks and issues

Risk	Impact	Mitigation	Owner
Billing team hasn’t shared the invoice endpoint	API delayed further	Escalate to billing lead	Ilya

Dependencies

We wait for	From	By
Invoice endpoint documentation	Billing team	2 Nov

Decisions

• Keep the 1 December launch; review again on 13 November.

Action items

Action	Owner	Due
Escalate invoice endpoint to billing lead	Ilya	29 Oct
Prepare a fallback launch plan without invoices	Marina	not set

Two things here are worth copying. The status line names its reason, so nobody has to ask why the project is at risk. And the one dependency shows up three times — as the cause in the summary, as a risk with an owner, and as a dated row under dependencies — which is what makes escalating it the first action on the list.

How to fill it in

A project meeting summary is only as useful as its dates are honest. The five rules in the template keep it that way: the status comes with a reason instead of a colour, the plan and the forecast stand side by side so a slip cannot hide, every risk has a person who owns it, dependencies on other teams get their own table because they are the most common cause of delay, and nobody is given a task or a date in the summary unless it was actually said in the meeting.

1. Status is a judgment, so give a reason. “At risk — design is two weeks late” is useful; a bare colour isn’t.
2. Forecast vs plan. Show both dates so slippage is visible.
3. Every risk gets an owner, or it’s just a worry.
4. Dependencies on other teams are listed separately — they’re the most common reason for delays.
5. Owners and dates only if named.

Planned vs forecast: how to report a slipping milestone

Take the backend API row from the example. The plan said 6 November; the team now expects 13 November. The summary does not overwrite the plan with the new date — it keeps both, marks the milestone “Late”, and the slip of one week is visible to anyone who reads the row. Then it follows the slip through. The cause is a dependency, so the billing team’s endpoint appears under dependencies with its own date. The consequence is a risk to the next milestone, so the public launch keeps its 1 December forecast but changes status to “At risk”. And the decision says when the date will be judged again — on 13 November — so the next summary has a clear question to answer: did the API land, and does the launch still hold?

Which record for which meeting

You need	Use
A status record for one project: milestones planned vs forecast, risks, dependencies	This project meeting summary template
A weekly working record for a team or department	Staff meeting minutes template
A one-page summary of any meeting for people who missed it	Meeting summary template
A one-page brief for leadership: bottom line, decisions, requests with a recommendation	Executive meeting summary template
What the team takes into the next sprint: goal, backlog, capacity	Sprint planning notes template

Every other template is on the templates page.

If you would rather not take notes at all

You can fill in this template by hand. If you would rather follow the discussion, Dalm is a Mac app that records the meeting — a call, or a conversation in the room through the Mac’s microphone — and drafts notes from the transcript to start from. The draft is its own document rather than this template filled in: you correct it line by line and save it as PDF, Word (.docx) or Markdown.

See plans · For teams