BlogTemplates
Project kickoff notes template
A project kickoff notes template records agreed scope and exclusions, success criteria, dependency owners, evidence and next steps after a kickoff meeting. Use it to carry the discussion into delivery without turning a proposal into a commitment. Fill it from your notes or an authorised transcript, keep source references beside observations, and mark missing answers as unknown.
Short answer
- Use this after a kickoff to capture what people agreed and what still needs an answer.
- Name agreed exclusions explicitly; an omitted feature is not an agreed exclusion.
- Give each success criterion an observable measure and a place to check it.
- Record whether each dependency owner accepted; a missing answer means “Not confirmed”.
What should I record after a project kickoff meeting?
- For
- A project team after a kickoff, including one that left scope unsettled
- What it does
- Records agreed scope, success criteria, dependency owners, evidence, open questions and next steps.
- 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.
You can join the Candor waitlist at candor.inc. [1]
Use the Copy button on the blank block, or select it and copy. For a plain-text fallback, keep the labels and write each table row as labelled lines. In Google Docs, start a blank document using Create, then paste the text and check every field. [5]
Template
Project kickoff notes
Use after the kickoff. Mark unknown answers "Not confirmed" or "Not set".
Keep unaccepted assignments proposed. Record a declined assignment only with evidence.
Repeat rows for each scope item, success criterion, dependency or discussion topic.
Keep source references beside claims; write "Source unknown" if a reference is missing.
If no next step was agreed, write "None confirmed" and label any proposal explicitly.
## Meeting details
- Project:
- Meeting date and time (include time zone):
- Facilitator:
- Notes prepared by:
- Participants and roles:
- Source documents, versions and locations:
## Scope recorded
| Item | Included or excluded | Evidence or reference | Status: agreed, proposed or open |
|---|---|---|---|
| | | | |
## Success criteria recorded
| Intended result | Measure or observable evidence | Evidence source and where to check | Check date | Confirmed by | Open question or status |
|---|---|---|---|---|---|
| | | | | | |
## Dependencies
| Input or decision needed | Dependency owner | Acceptance: accepted, declined, not confirmed or unassigned | Needed by | If late, what is blocked? | Evidence or reference | Status or next check |
|---|---|---|---|---|---|---|
| | | | | | | |
## Evidence and follow-through
| Topic | Observed evidence and source locator | Interpretation, if any | Open question | Agreed next step | Owner | Due date |
|---|---|---|---|---|---|---|
| | | | | | | |
## Decisions and record location
- Decision recorded (or “None confirmed”):
- Evidence or transcript reference:
- Confirmed by and when:
- Updated project plan location and version:
- Next review date, or “Not set”:
Filled example
This is an original fictional example. The project, people, documents, dates and transcript references below are invented; they describe no real team or tested result. The criteria are future checks, not results.
Project kickoff notes
## Meeting details
- Project: Harbor receiving dashboard pilot
- Meeting date and time (include time zone): 21 October 2026, 14:00–14:45 India Standard Time (UTC+05:30)
- Facilitator: Devika Rao, product lead
- Notes prepared by: Omar Khan, delivery lead
- Participants and roles: Devika, product; Omar, delivery; Ritu Sen, warehouse operations; Arjun Mehta, engineering; Leena Das, IT support.
- Source documents, versions and locations: Pilot brief v0.6, 19 October 2026, fictional /Harbor/Pilot/brief; screen mock-up v0.3 in the same folder; fictional meeting transcript HARBOR-KO-2026-10-21.
## Scope recorded
| Item | Included or excluded | Evidence or reference | Status: agreed, proposed or open |
|---|---|---|---|
| Receiving staff can view incoming deliveries and flag a count mismatch | Included for Harbor East and Harbor West | Transcript HARBOR-KO-2026-10-21, 00:12:08–00:15:40 | Agreed |
| Forecasting and supplier self-service | Excluded from this pilot | Transcript HARBOR-KO-2026-10-21, 00:16:02–00:18:11 | Agreed |
## Success criteria recorded
| Intended result | Measure or observable evidence | Evidence source and where to check | Check date | Confirmed by | Open question or status |
|---|---|---|---|---|---|
| A receiving clerk can find a delivery and flag a count mismatch | In a planned walkthrough, complete the mismatch flow without a facilitator hint | Planned walkthrough sheet, section “Mismatch flow”; no run recorded | 13 November 2026 | Ritu Sen; criterion and check date agreed at transcript 00:24:30 | Which shift can attend? Ritu agreed to ask; open |
## Dependencies
| Input or decision needed | Dependency owner | Acceptance: accepted, declined, not confirmed or unassigned | Needed by | If late, what is blocked? | Evidence or reference | Status or next check |
|---|---|---|---|---|---|---|
| Confirm two pilot tablets can reach the test network | Leena Das, IT support | Accepted in the meeting | 28 October 2026 | Scheduling the tablet walkthrough | Transcript HARBOR-KO-2026-10-21, 00:29:14 | Leena agreed to report device models and test window |
| Decide how staff label a mismatch when a delivery has no purchase-order number | Not assigned | Unassigned | Not set | Finalising the mismatch reason options | The brief v0.6 section 4 has no rule; transcript 00:32:40 records the question only | Open; proposed follow-up: ask Devika to identify the process owner; acceptance not confirmed |
## Evidence and follow-through
| Topic | Observed evidence and source locator | Interpretation, if any | Open question | Agreed next step | Owner | Due date |
|---|---|---|---|---|---|---|
| Mismatch flow | Mock-up v0.3 has a “flag count” control; transcript 00:22:05 records the team asking for a reason field | The screen may need a reason field; this is a design reading, not a decision | Which reasons should staff choose from? | Ritu to send two synthetic examples from the training guide by 27 October; agreed at transcript 00:26:10 | Ritu Sen | 27 October 2026 |
| Tablet availability | No device list appears in the pilot brief; transcript 00:29:14 records Leena accepting a check by 28 October | No conclusion recorded | Which models are available? | Confirm models and test window; agreed | Leena Das | 28 October 2026 |
## Decisions and record location
- Decision recorded (or “None confirmed”): Limit the pilot to the receiving workflow at Harbor East and Harbor West; forecasting and supplier self-service stay out of scope.
- Evidence or transcript reference: Transcript HARBOR-KO-2026-10-21, 00:12:08–00:18:11.
- Confirmed by and when: Devika Rao, product lead, and Ritu Sen, warehouse operations, at the kickoff on 21 October 2026.
- Updated project plan location and version: Proposed destination: fictional /Harbor/Pilot/plan; update not confirmed, version not set.
- Next review date, or “Not set”: 30 October 2026, agreed in transcript at 00:42:10.
When to use this
Use these notes after a kickoff, including one that left scope unsettled. The agenda plans the discussion; these notes preserve its outcome. PMI's July 1995 launch-meeting article discusses scope exclusions, task-owner acceptance and dependencies as advice, not a mandatory notes format. [3] The University of Waterloo's project-initiation guidance includes measurable success criteria. [4] An evidence location tells the next reader where to check a criterion; it does not report a result.
The meeting minutes template hub covers general records, including attendance, quorum, votes and sign-off. This page adds kickoff scope and success criteria, with dependency acceptance and evidence locators for follow-through. It does not replace a formal record your organisation requires.
What to customise
Keep scope and evidence when tracing work into delivery. If the team has one shared project record, replace the source-document list with its version and location. Add a column only if it changes what someone must do. Delete unused rows, but preserve unresolved questions. An explicit “unknown” is more useful than a guessed value.
Change role labels and date format to match your team. Include a time zone when people join from different places. Use “Not confirmed” when acceptance is unknown, “Declined” only for an explicit refusal, and “Unassigned” when nobody owns the dependency. A name in a table records an assignment; it does not prove acceptance. (An absent person's name is especially easy to volunteer.)
Field-by-field guidance
| Field | What to enter | Where to get it | Common mistake |
|---|---|---|---|
| Meeting details and source documents | Project, date and time zone, facilitator, note writer, participants and roles; document versions and locations | Invite, attendance notes and current project brief | Treating an invitee as proof they attended, or linking an old brief |
| Scope recorded | Included and excluded work, source reference and agreed, proposed or open status | Discussion notes, brief and people authorised to set scope | Treating an omitted feature as an agreed exclusion |
| Success criteria recorded | Intended result, observable measure, evidence location, check date, confirmer and open question | Sponsor and the people who will check the result | Writing a desired outcome as though the team has already achieved it |
| Dependencies | Input needed, owner and acceptance, needed-by date, blocked work, evidence and next check | The person supplying the input and the team waiting for it | Treating assignment as acceptance, or an unknown answer as refusal |
| Evidence and follow-through | Observation and source locator, separate interpretation, open question, agreed next step, owner and due date | Your notes or an authorised transcript | Turning an interpretation into a fact, or inventing a due date |
| Decisions and record location | Decision or “None confirmed,” evidence reference, confirmer, maintained-plan location and next review | Meeting record and project workspace | Copying a suggestion into the decision field |
“Observed evidence” should point to something a second person can inspect: a document section or transcript timestamp, for example. A source locator works like a shelf number in a warehouse: it tells the next person where to look, but cannot tell them whether the contents are right. In the fictional example, the mock-up contains a “flag count” control; adding a reason field is a separate proposal. Keep that distinction in the notes.
Before sharing, send disputed entries to the people who can resolve them. Keep both source references if accounts conflict. Then copy confirmed changes into the maintained project plan and record its version here. (Circulating notes does not make silence an approval.)
Voice and AI workflow
- Dictate a short recap after the meeting. Give each point a note ID, document section or transcript timestamp.
- Remove confidential and identifying details before using an AI tool. Do not upload confidential records. If removing the details makes the task impossible, fill in the template yourself.
- Ask the model to map the recap into the fields below. Keep each source reference beside the statement it supports, and leave missing answers open.
- Check every name, decision, owner and due date against the source. Ask dependency owners to confirm assignments; keep unaccepted work proposed.
For an authorised transcript, see working from a transcript. For recording questions, see recording meetings. A transcript is a source to inspect; it does not prove that every suggestion was accepted.
Copy this prompt with the blank template and a non-confidential recap:
Turn the supplied project kickoff recap into project kickoff notes in Markdown.
Keep the blank template's headings, field names and order. The output is notes,
not an agenda or a general minutes document.
Fill in meeting details and source document versions and locations. Then map
the recap into: scope recorded (item, included or excluded, evidence or
reference, agreed/proposed/open status); success criteria (intended result,
measure or observable evidence, evidence source and location, check date,
confirmer, open question or status); dependencies (input or decision needed,
dependency owner, acceptance status, needed-by date, work blocked if late,
evidence or reference, status or next check); evidence and follow-through (topic, observed
evidence and source locator, interpretation if any, open question, agreed next
step, owner, due date); and decisions and record location (decision, evidence
reference, who confirmed it and when, updated project plan location and
version, next review date).
Keep unknowns unknown. Do not invent facts, people, agreements, source
references, owners or dates. Separate observations from interpretations and
proposals from confirmed decisions. Preserve each evidence reference next to
the statement it supports. If sources conflict, show both references and mark
the point unresolved. Write "Source unknown" when a reference is missing.
Use "Not confirmed" for unknown owner acceptance, "Declined" only for an
explicit refusal, and "Unassigned" when no owner is named. Keep proposed work
labelled proposed; if no next step was agreed, write "None confirmed" before
any proposal. Write "Not set" for a missing due date. Do not infer agreement
from silence or turn a planned success check into a completed result.
Before pasting input, remove confidential or identifying information. A human
must confirm every name, decision, dependency owner and due date against the
source record before sharing the notes.
Non-confidential recap:
Questions
What items need to be included in a project kickoff meeting?
This template records agreed scope and exclusions, success criteria, dependency owners, evidence and next steps. It also lists meeting details, participants and roles, source documents, and where the decision record and updated project plan are kept.
As a project manager, how do you capture meeting minutes without missing anything?
Fill the notes from your own notes or an authorised transcript, and keep a source reference beside each claim. Mark missing answers 'Not confirmed' or 'Not set', and write 'Source unknown' when a reference is missing. Keep unaccepted assignments as proposed rather than recording them as commitments.
How will you know if your project has met its goals?
Give each success criterion an observable measure and a place to check it. The template also records a check date, who confirmed the criterion and any open question, so each criterion stays a future check rather than a result.
What this page can't tell you
These notes cannot establish an owner's capacity or a decision-maker's authority. Ask the people responsible and check your project's governing documents. The fictional example supplies no real project evidence. Each block has a Copy button; there are no downloadable files.
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. [2]
Sources
- Candor homepage — https://candor.inc/ — checked 2026-11-04
- Candor privacy policy (last updated October 30, 2026) — https://candor.inc/privacy — checked 2026-10-31
- How to manage a project launch meeting, Joan Knutson, PMI — https://www.pmi.org/learning/library/manage-project-launch-meeting-10440 — checked 2026-11-04
- Initiation, University of Waterloo VPAF Project Management Office — https://uwaterloo.ca/vpaf-project-management-office/methodologies/project-management/initiation — checked 2026-11-04
- Create, view, or download a file, Google Docs Editors Help — https://support.google.com/docs/answer/49114?hl=en — checked 2026-11-04