BlogTemplates
Project status meeting notes template
A project status meeting notes template records milestone variance against the agreed plan, dependency status and decisions needed, with owners and next checks. It keeps each revised forecast beside the agreed date so the slip stays visible, and labels variance in calendar or working days. Use it for a recurring project status review rather than a full meeting record.
Short answer
- Compare each milestone's agreed date with its current forecast; label the variance as calendar days or working days.
- For each dependency, record what is needed, who supplies it, when it is needed and who will check next.
- Keep a decision open until the person with authority confirms it; record a recommendation separately.
- Carry unresolved items into the next review with the same reference and an updated check date.
What should project status meeting notes cover?
- For
- A project team holding recurring status reviews
- What it does
- Records milestone variance, dependency status, decisions needed and the actions agreed before the next review.
- Works in
- Plain Markdown; paste into any notes or docs app
Disclosure. Candor is an app that will compete with some products named here. We describe every product, including Candor, from its own documentation, and we'll test them all with the same published method.
Use the Copy button on the blank block, or select it and copy. There are no downloadable files.
Template
## Project status meeting notes
## Meeting details
- Project:
- Reporting period:
- Meeting date, time and time zone:
- Facilitator:
- Notes owner:
- Participants present:
## Status at a glance
- Current status (team's label):
- Main change since the last review:
- Evidence or source references:
## Milestones
Repeat one row per milestone discussed. State calendar days or working days in the variance; for working days, identify the project calendar. Keep the agreed date visible when the forecast changes.
| Milestone / reference | Agreed date | Current forecast | Variance and calendar basis | Evidence / cause to check | Owner | Next check date |
|---|---|---|---|---|---|---|
| | | | | | | |
## Dependencies
Repeat one row per dependency that could change project work or timing. Include the next check date and its owner.
| Dependency / reference | Status and evidence | Needed by | Provider / owner | Effect if late | Next check date / owner |
|---|---|---|---|---|---|
| | | | | | |
## Decisions needed
Repeat for each decision discussed. Mark unresolved decisions as open; record a confirmed decision with its source and confirmation date.
- Question to decide:
- Decision owner:
- Needed by:
- Options or constraints discussed:
- Recommendation, if any:
- Recorded decision or open status:
- Decision evidence or reference and confirmation date, if decided:
## Discussion notes
Repeat for each topic. Separate an observation from its possible meaning.
### Topic:
- Observed facts and source:
- Interpretation or concern:
- Open question:
## Actions agreed
Record only agreed actions. Repeat one row per action; mark missing owners or dates as unknown.
| Action | Owner | Due date | Related milestone / dependency / decision | Status |
|---|---|---|---|---|
| | | | | |
## Open issues
Repeat for each unresolved issue.
- Issue and evidence:
- Owner for the next check:
- Next check date:
- Escalation or decision needed, if any:
## Next review
- Date, time and time zone, if set:
- What must be ready before then:
- Sharing status and intended recipients:
Copy the block as Markdown, or paste without formatting for plain text. Plain-text tables keep their separators; they may need manual spacing. Google documents viewing Word files in Docs, but that does not establish this template's import layout. [1]
Filled example
Fictional example. All people, records and project details below are invented. The forecast remains conditional on an unresolved dependency.
## Project status meeting notes
## Meeting details
- Project: Harbour billing migration
- Reporting period: 12–23 October 2026
- Meeting date, time and time zone: 23 October 2026, 14:00–14:35 IST (UTC+05:30)
- Facilitator: Isha Menon
- Notes owner: Kabir Rao
- Participants present: Isha Menon, Kabir Rao, Leena Das, Omar Khan
## Status at a glance
- Current status (team's label): At risk
- Main change since the last review: Reconciled test data is forecast for 28 October, six calendar days after the agreed date.
- Evidence or source references: Test record BILL-184; export checklist dated 22 October.
## Milestones
| Milestone / reference | Agreed date | Current forecast | Variance and calendar basis | Evidence / cause to check | Owner | Next check date |
|---|---|---|---|---|---|---|
| Reconciled test data / BILL-184 | 22 Oct 2026 | 28 Oct 2026, if corrected export arrives by 26 Oct | +6 calendar days | Export checklist, 22 Oct: two tax-code fields absent; mapping cause unconfirmed | Omar Khan | 26 Oct 2026 |
## Dependencies
| Dependency / reference | Status and evidence | Needed by | Provider / owner | Effect if late | Next check date / owner |
|---|---|---|---|---|---|
| Corrected finance export / FIN-72 | At risk: two fields absent in 22 Oct checklist; replacement date unconfirmed | 26 Oct 2026 | Finance / Leena Das | Two tax cases remain blocked; 28 Oct milestone forecast needs review | 26 Oct 2026 / Leena Das |
## Decisions needed
- Question to decide: Start unaffected test cases while the two tax cases wait?
- Decision owner: Isha Menon
- Needed by: 26 October 2026
- Options or constraints discussed: Start unaffected cases; hold the whole run. Both tax cases require the corrected export.
- Recommendation, if any: Omar recommends starting unaffected cases and keeping the tax cases blocked.
- Recorded decision or open status: Open. Isha will decide after finance's update.
- Decision evidence or reference and confirmation date, if decided: BILL-184 review note, 23 October. No confirmed decision recorded.
## Discussion notes
### Topic: Export completeness
- Observed facts and source: Two tax-code fields are absent, per the 22 October export checklist.
- Interpretation or concern: Waiting for all fields could delay work on unaffected cases; the time effect has not been estimated.
- Open question: Will finance deliver the corrected export by 26 October?
## Actions agreed
| Action | Owner | Due date | Related milestone / dependency / decision | Status |
|---|---|---|---|---|
| Confirm corrected export delivery date | Leena Das | 26 Oct 2026 | FIN-72 | Open; agreed in the review |
| Draft a split test run for Isha to consider | Omar Khan | 26 Oct 2026 | BILL-184 / decision on starting unaffected cases | Open; agreed in the review |
## Open issues
- Issue and evidence: Replacement export date is unconfirmed, per FIN-72.
- Owner for the next check: Leena Das
- Next check date: 26 October 2026
- Escalation or decision needed, if any: Isha to decide on a partial start by 26 October; review the milestone forecast if delivery slips.
## Next review
- Date, time and time zone, if set: 27 October 2026, 14:00 IST (UTC+05:30)
- What must be ready before then: Finance's delivery update; split-run draft; Isha's decision or an explicit open status.
- Sharing status and intended recipients: Draft; Kabir to share with the project team after checking names and commitments.
When to use this
Use this optional layout for recurring project reviews where dates or outside inputs affect the next step. For a meeting without a tracked delivery plan, use the short form on the general minutes template hub. Follow your organisation's process for an official record; this worksheet does not specify one.
Treat a milestone like a delivery appointment: keep the booked date beside the supplier's latest estimate. Replacing the booked date each time the estimate moves hides the delay. If the team agrees to a new baseline, keep a reference to that approval and the previous date.
What to customise
Rename milestones to match your deliverables. Use your team's status labels and explain what each means. Set one date format and time zone for the series; if variance uses working days, name the calendar, including its holidays. (A six-day calendar slip need not be six working days.)
Remove sections with no bearing on the project. Keep enough detail to distinguish a dependency, such as a required export, from a general risk, such as a possible staff shortage. Add source references rather than copying whole threads. If the cause of a slip is disputed, record the competing explanations as unconfirmed and assign a check.
Field-by-field guidance
| Field | What to enter | Where to get it | Common mistake |
|---|---|---|---|
| Meeting details | Project and reporting period; meeting time with zone; facilitator, notes owner and people present | Invite and attendance check | Listing invitees as attendees |
| Status at a glance | Team's status label, change since last review and supporting references | Project record and owner update | Treating a status colour as evidence |
| Milestones | Reference, agreed date, forecast, variance with calendar basis, evidence or unconfirmed cause, owner and next check | Baseline plan and dated update | Replacing the agreed date with the forecast |
| Dependencies | Required input and reference, status with evidence, need-by date, provider, effect if late and next check owner/date | Provider update and delivery plan | Writing “waiting” without a named provider or next check |
| Decisions needed | Question, decision owner, deadline, options, optional recommendation, confirmed decision or open status, reference and confirmation date | Discussion and the person with decision authority | Turning the preferred option into a decision |
| Discussion notes | Topic; observed fact with source; interpretation; open question | Notes or authorised transcript | Treating an inferred cause as established |
| Actions agreed | Agreed step, owner, due date, related reference and status | Confirmed commitments | Converting an idea into an assigned task |
| Open issues | Unresolved issue with evidence, next-check owner/date and any escalation or decision needed | Current issue record | Dropping an item because the meeting ended |
| Next review | Time with zone, preparation needed, sharing status and intended recipients | Calendar and notes owner | Saying “shared” while notes are still a draft |
For a completed milestone, put its actual completion date in the forecast cell and label it “actual”. For an unchanged item, keep its reference and update the evidence date. If a deadline passes while a decision remains open, record that explicitly and use the team's escalation process.
Voice and AI workflow
- Dictate a post-meeting recap into an approved tool, or map an authorised transcript into the blank block yourself.
- Remove confidential or identifying data before submitting any text to an AI tool. Use only material your organisation permits you to share with that tool; if the recap cannot be shared, fill the template yourself.
- Paste the permitted input after the prompt below. Keep source references or transcript timestamps beside claims, and preserve gaps as “unknown”.
- Have the relevant participants confirm each name, decision and due date against the source. Carry open items forward under the same reference, then share the checked notes through the team's normal channel.
A request to flag sensitive text is no substitute for removing it before submission. (The prompt cannot take back the input you already sent.) For source-checking steps, see minutes from a transcript; for recording questions, see recording meetings.
Copyable prompt:
Turn the permitted meeting recap or authorised transcript below into project status meeting notes. Output these sections in order:
Meeting details: project, reporting period, meeting date/time/time zone, facilitator, notes owner, participants present.
Status at a glance: team's status label, main change, evidence references.
Milestones: milestone/reference, agreed date, current forecast, variance with calendar basis, evidence or cause to check, owner, next check date.
Dependencies: dependency/reference, status and evidence, needed-by date, provider/owner, effect if late, next check date/owner.
Decisions needed: question, decision owner, needed-by date, options or constraints, recommendation, recorded decision or open status, source reference and confirmation date if decided.
Discussion notes: topic, observed facts and source, separate interpretation, open question.
Actions agreed: action, owner, due date, related reference, status.
Open issues: issue and evidence, next-check owner, next check date, escalation or decision needed.
Next review: date/time/time zone, preparation needed, sharing status and intended recipients.
Preserve unknowns as "unknown". Do not infer attendance, names, dates, owners, decisions or agreement. Keep recommendations separate from confirmed decisions. Record only explicitly agreed actions. Preserve source references and transcript timestamps; never invent them. Calculate variance only when both dates and the calendar basis are supplied; otherwise mark it unknown. Keep conditional forecasts conditional. Flag conflicting evidence for a human to check. Leave unresolved decisions open.
Remind me to remove confidential or identifying data before supplying input. If any is still apparent, stop without reproducing it and ask for a permitted version; do not claim that you can detect or remove all sensitive data. A human must confirm every name, decision and due date before sharing the notes.
Input (remove confidential or identifying data before pasting):
What this template can't tell you
The notes cannot establish the cause of a delay or whether a forecast will hold. Check those with the owner and the underlying evidence. This page also does not establish recording permission or your organisation's requirements for an official record.
The template makes no claim about an AI tool's accuracy or data handling.
Questions
What are some tips for presenting a status report on an ongoing project?
Compare each milestone's agreed date with its current forecast, and label the variance as calendar days or working days. For each dependency, record what is needed, who supplies it, when it is needed and who checks next. Keep each decision open until the person with authority confirms it.
How do you tell stakeholders a project is behind schedule?
Keep the revised forecast beside the agreed date so the slip stays visible. In the page's fictional example, a milestone forecast moved six calendar days and its cause was still marked unconfirmed. Record the evidence, the cause to check, an owner and a next check date.
What should I tell my boss if a project probably won't meet its deadline?
Give the current forecast next to the agreed date, not just a status label. Add the evidence and any dependency that affects timing, such as a late input from another team. If a decision is needed, name the decision owner and the date it is needed by.
About this page
Candor is being built as personal voice intelligence for everyone. You can join the Candor waitlist at candor.inc. Candor's own documentation is at candor.inc/docs.
Candor's docs on this page's topic: What the summary includes.
Last checked: 4 November 2026. Report an error to support@candor.inc.
Sources
- Create, view, or download a file, Google Docs Editors Help — https://support.google.com/docs/answer/49114?hl=en — checked 2026-11-04