QUICK ANSWER
What should a project post-mortem template include?
A project post-mortem template should include review scope and safeguards, stated expectations, observed outcomes with evidence and limitations, project-level turning points, positive and negative observations, contributing conditions that avoid unsupported causal claims, bounded learning with applicability limits, action proposals with external decision references, role owners, follow-up dates, and an independent human review that grants no closure or acceptance authority.
A useful project post-mortem is a bounded review of one completed or stopped project. It compares stated expectations with observed outcomes, reconstructs project-level turning points, records positive, negative, and mixed observations, tests contributing conditions without declaring a root cause, and hands learning and action proposals to the systems that own later decisions.
The downloadable pack includes an editable worksheet, validator-clean draft, fictional completed example, closed JSON Schema, dependency-free semantic validator, 40 positive and mutation tests, and deterministic exact-allowlist builder. It checks the internal record contract, not evidence truth, project closure, deliverable acceptance, incident causation, personnel performance, lesson reuse, action approval, or future results.
Run one project review without stealing adjacent decisions
Prepare from authoritative records, facilitate a bounded discussion, preserve uncertainty and dissent, and finish with explicit handoffs. A project post-mortem can improve the review trail without becoming the final project-governance packet or a universal lessons database.
Freeze the project boundary and review safeguards
Identify the exact project or phase, review window, evidence cutoff, facilitator role, independent reviewer role, controlled evidence access, retention-authority reference, participants by role, ground rules, and known participation or evidence limits. The Government of the Northwest Territories describes its resource as a project post-mortem session template; this article adds explicit authority and evidence boundaries rather than treating that older form as a universal standard.
Sources: [nwt-project-postmortem], [postmortem-pack]
Compare stated expectations with observed outcomes
Copy no new baseline into the post-mortem. Reference the authorized expectation, measure, and target, then record the observed result, evidence, and limitation. Northern Ireland guidance separates review of how the project was managed from later review of overall success and benefits, so timing and review purpose stay visible.
Sources: [finance-ni-review], [postmortem-pack]
Reconstruct project-level turning points from records
Order the major project decisions, discoveries, changes, or external dependencies that altered the observed path. Link the decision and evidence, describe the observed effect, and leave unknown authority or missing records explicit. This is not the minute-by-minute impact and response timeline owned by an operational incident postmortem.
Sources: [capmf-closing], [google-sre-postmortem], [postmortem-pack]
Record positive, negative, and mixed observations
Use neutral statements linked to inspectable evidence, with confidence and uncertainty beside each one. Keep the discussion about decisions, conditions, systems, and project behavior rather than ratings or blame about individuals. Preserve material disagreement as a limitation or separately supported observation instead of forcing consensus.
Sources: [uk-lessons-guidance], [postmortem-pack]
Test contributing conditions without certifying root cause
Connect each proposed condition to one or more observations and evidence references. Classify it as an assumption, decision, process, dependency, or context, then use an appropriate reviewer role to validate, reject, or request evidence. If an operational incident or safety event needs causal investigation, hand it to the accountable incident or RCA process.
Sources: [google-sre-postmortem], [postmortem-pack]
Bound learning and route action proposals outward
State where each learning applies and does not apply. Link an action only to reviewed learning, name the receiving planning, policy, backlog, or decision system, and keep it proposed until that external system records acceptance or rejection. UK guidance distinguishes identified lessons from implementation and evaluated learning; this post-mortem cannot make those later claims.
Sources: [uk-lessons-guidance], [postmortem-pack]
Validate the portable record, then obtain human review
Run the closed-schema and semantic checks, inspect the fictional example, preserve every limitation, and require a reviewer role distinct from the facilitator. JSON Schema declares the object contract and RFC 2606 reserves .test names used by the examples. The final review still grants no project closure, acceptance, incident-cause, personnel, compliance, or action authority.
Sources: [json-schema-2020-12], [rfc-2606], [postmortem-pack]
The project post-mortem ownership boundary
This owner covers one facilitated end-of-project or end-of-phase review record. It receives evidence from project systems, produces project-specific observations and candidate improvements, and links to the records that own formal decisions and durable reuse.
Included
- Project and review identity, evidence cutoff, facilitator and reviewer roles, ground rules, evidence access, retention authority reference, and known limitations
- Stated expectations, observed outcomes, stable evidence references, result limits, project-level turning points, and recorded decision references
- Positive, negative, and mixed observations, confidence, uncertainty, contributing conditions, review status, bounded learning, and applicability limits
- Action proposals, receiving systems, role owners, due and follow-up dates, success measures, external decision references, and human review
- Editable Markdown, validator-clean JSON, fictional completed example, closed schema, validator, mutation tests, deterministic builder, and exact eight-file ZIP
Not included
- Formal project closure, cancellation, deliverable acceptance, custody transfer, open-obligation transfer, benefit realization, budget or records closeout, or sponsor authorization
- Recurring sprint-retrospective facilitation, voting, one-sprint experiments, backlog commitments, or the Scrum event itself
- Operational incident impact, incident timeline, response and recovery chronology, exclusive root-cause claims, safety investigation, or corrective-action certification
- A durable validated lessons register, organization-wide applicability, recommendation implementation, effectiveness evaluation, or proof that learning is embedded
- Personnel evaluation, individual fault, legal advice, audit opinion, compliance assurance, incident resolution, or performance ratings
- A post-event report, event debrief, final status report, project plan, change approval, release authorization, or future-result guarantee
DOWNLOADABLE RESOURCE
Download the project post-mortem template pack
Start from the draft or worksheet, replace every fictional reference with a stable authorized source, compare the completed example, and run the included validator before the independent human review.
Project post-mortem template pack
An eight-file end-of-project review pack for expectations, outcomes, turning points, observations, contributing conditions, bounded learning, action handoff, and independent review.
Format: Markdown, JSON, closed JSON Schema, dependency-free Node.js validator/tests, and deterministic ZIP builder
Locally reproduced August 1, 2026. SHA-256: 4f77de129f7f9b0024f419b810834aa8a9dd69ce31863f556ca298b95bf92125
Included
- Editable project post-mortem worksheet with explicit closure, incident, personnel, and action-authority boundaries
- Validator-clean draft that preserves unknown closure and action decisions
- Fictional completed knowledge-portal project review with three expectations, outcomes, turning points, observations, conditions, learning records, and actions
- Closed JSON Schema Draft 2020-12 contract and dependency-free semantic validator
- Forty deterministic positive and mutation tests for shape, IDs, references, dates, states, evidence, roles, handoffs, overclaims, and unsafe values
- README and fixed-time exact eight-file builder for reproducible ZIP bytes
Verification boundary
Validated the draft and completed fictional records, ran 40 tests, checked every closed object definition, compared page source, public files, fresh extraction, and archive bytes, rebuilt across time zones, scanned for credentials and network calls, and locked the archive hash. This cannot authenticate evidence or authorize closure, acceptance, incident causation, personnel judgment, lessons, actions, or outcomes.
Three project-review shapes with the same bounded record
The project result may differ, but the post-mortem job stays consistent: compare expectations with observations, preserve the path and limits, review contributing conditions, and route learning and action proposals without stealing authority.
Completed project with mixed outcomes
Use when: The project has an external closure or acceptance record and the team needs a separate review of delivery expectations, turning points, working practices, shortfalls, and future proposals.
Reference the authorized baselines and closure decision, compare each expectation with evidence, record positive and negative observations, validate bounded conditions, and hand proposed changes to future planning.
Structure
- One outcome for every stated expectation, with evidence and limitations
- Chronological project turning points, reviewed conditions, bounded learning, and external action decisions
Watch for: The post-mortem references closure and acceptance but cannot grant either one or certify that the project succeeded.
Sources: [nwt-project-postmortem], [finance-ni-review], [postmortem-pack]
Stopped project with evidence gaps
Use when: An accountable external process stopped or cancelled the project and the review needs to preserve what is known, unknown, transferable, and inappropriate to conclude.
Keep missing outcomes and decision references explicit, review the sequence that records support, preserve dissent and uncertainty, reject unsupported conditions, and route open questions outside the post-mortem.
Structure
- Draft or in-review state until required outcomes and reviewer evidence exist
- No manufactured acceptance, closure, root cause, lesson validation, or action approval
Watch for: A stopped project may need contractual, financial, legal, safety, personnel, or incident processes beyond this learning review.
Sources: [capmf-closing], [uk-lessons-guidance], [postmortem-pack]
Phase review before a separately authorized next project
Use when: One bounded phase is complete and its evidence can inform a different project or phase without authorizing that future work.
Name the exact reviewed phase, compare its expectations and outcomes, limit every learning to comparable conditions, and send action proposals to the future planning authority.
Structure
- Phase-specific review window and evidence cutoff, not a recurring Sprint Retrospective
- Action proposals with receiving system, role owner, decision reference, success measure, and follow-up
Watch for: A phase post-mortem does not authorize the next phase, replace a Sprint Retrospective, or prove that one practice will travel safely.
Sources: [scrum-guide], [uk-lessons-guidance], [postmortem-pack]
Route each end-of-project question to its accountable owner
The template becomes more credible when it refuses to answer decisions that belong to governance, incident, learning, personnel, or future-work systems.
The project still needs a formal close, acceptance, custody, or obligation decision.
Choose: Use the project closure report and authoritative acceptance records. Link their stable references after the accountable human decision exists.
Tradeoff: The post-mortem may wait for a reference or remain in review, but it never acquires closure authority.
The team wants a lesson reused across projects or called implemented and learned.
Choose: Hand the candidate to the lessons learned record for independent applicability validation, external acceptance, implementation, and effectiveness follow-up.
Tradeoff: The project review owns less, but a local observation does not become an unsupported organizational rule.
The record concerns one recurring iteration or Sprint.
Choose: Use the sprint retrospective owner for the team session, themes, small experiments, and next-iteration follow-up.
Tradeoff: The cadence stays useful without making the end-of-project post-mortem a recurring meeting template.
An outage, safety event, or other operational incident needs impact and causal review.
Choose: Use the incident postmortem and root-cause processes. Reference only their validated conclusions when they materially inform the project review.
Tradeoff: Several bounded records may remain, but incident evidence, response, causes, and corrective actions keep their accountable owners.
A proposed action has no receiving system or external decision reference.
Choose: Keep it proposed, name the planning or policy system that owns the decision, and record acceptance or rejection only from that system.
Tradeoff: The action may remain open longer, but the post-mortem does not manufacture approval or execution.
START WITH THE DRAFT STATE
Download the project review pack and inspect every handoff
Use the worksheet, preserve unknown evidence and authority, compare the fictional completed review, and run the validator before independent human review.
Download the post-mortem packThe fictional editorial pack checks internal consistency. It cannot authenticate evidence, authorize closure or acceptance, evaluate people, establish incident cause, approve actions, or prove improvement.
Keep formal closeout in the project closure report templateThe post-mortem reviews the project. The closure report owns the final governance decision packet.
What the pack and validator cannot establish
A strict review record improves traceability, not truth. Professional judgment, evidence quality, participation, authority, causal analysis, learning validation, action delivery, and later outcomes remain outside structural validation.
- The validator checks shapes, references, dates, state gates, and bounded language, not whether source evidence is complete, authentic, representative, or correctly interpreted.
- Project turning points record sequence and observed effects. They do not establish exclusive causes or replace incident investigation and root-cause analysis.
- A reviewed post-mortem does not close the project, accept deliverables, transfer custody or obligations, reconcile benefits, or authorize future work.
- A candidate learning is not a validated reusable lesson until the accountable lessons process reviews applicability and later evidence.
- An accepted external action decision does not prove implementation or effectiveness; follow-up evidence belongs in the receiving work and learning systems.
- A facilitated project review cannot evaluate individual performance, settle a grievance, issue legal advice, provide an audit opinion, or establish compliance.
- The article targets the explicit project post mortem template query, not generic postmortem template intent, which can mean an operational incident review.
- This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.
Sources and verification record
The downloadable pack is the source for its fictional records and tests. External sources establish project-review, closure, lessons, Sprint, incident, schema, and fictional-reference boundaries without certifying this original template.
[postmortem-pack] Playcode:Project post-mortem fictional example
Checked August 1, 2026. Supports: The locally reviewed fictional record, closed schema, evidence and reference rules, boundary flags, validator, mutation tests, and deterministic archive. Public availability remains unverified until deployment.
[nwt-project-postmortem] Government of the Northwest Territories, Department of Finance:Project Post-Mortem Template
Checked August 1, 2026. Supports: An official project post-mortem session resource and its stated use around project close. The form dates to 2014 and does not make this article or pack a government standard.
[finance-ni-review] Northern Ireland Department of Finance:Post programme or project review
Checked August 1, 2026. Supports: The distinction between reviewing how a project was managed, reviewing overall project success after closure, and collecting lessons, with timing and role guidance. It is public-sector guidance, not a universal rule.
[capmf-closing] California Department of Technology:California Project Management Framework: Closing
Checked August 1, 2026. Supports: California framework-specific closing, lessons-session, post-implementation-evaluation, sponsor, project-manager, and handoff distinctions. It does not grant authority outside that framework.
[uk-lessons-guidance] UK Cabinet Office:Lessons Management Best Practice Guidance
Checked August 1, 2026. Supports: Non-statutory guidance on evidence, validation, applicability, ownership, implementation, evaluation, and why identifying a lesson is not the same as implementing and learning it.
[scrum-guide] Ken Schwaber and Jeff Sutherland:The 2020 Scrum Guide
Checked August 1, 2026. Supports: The Sprint Retrospective purpose and its placement inside the Sprint, which keeps a recurring Scrum event distinct from an end-of-project post-mortem.
[google-sre-postmortem] Google Site Reliability Engineering:Postmortem Culture: Learning from Failure
Checked August 1, 2026. Supports: Blameless, evidence-led incident postmortem practices and action ownership. It is cited to define the incident boundary and transferable review discipline, not as project-governance authority.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The schema dialect declared by the downloadable closed JSON Schema.
[rfc-2606] RFC Editor:RFC 2606 Reserved Top Level DNS Names
Checked August 1, 2026. Supports: Use of reserved .test domains for fictional records and evidence references.
Project post-mortem template questions
What is a project post-mortem?
A project post-mortem is a bounded review after a project or phase ends. It compares expectations with observed outcomes, reconstructs major project turning points, records evidence-backed observations, reviews contributing conditions, captures bounded learning, and routes action proposals. It should preserve uncertainty and avoid individual blame or unsupported causal claims.
Is a project post-mortem the same as a project closure report?
No. The project post-mortem owns the learning review. The project closure report owns the final governance packet for authorized baselines, acceptance references, custody, continuing obligations and benefits, administrative and records evidence, and the named human closure decision. The post-mortem may link that record but cannot close the project.
How is a project post-mortem different from a sprint retrospective?
A Sprint Retrospective is a recurring Scrum event for one Sprint and plans ways to increase quality and effectiveness. This owner reviews one broader completed or stopped project or phase, links project records and turning points, and routes project-specific learning and action proposals. It is not a replacement for the team cadence.
How is a project post-mortem different from an incident postmortem?
An incident postmortem owns a stabilized operational incident: impact, timeline, detection, response, recovery, contributing factors, and corrective-action governance. A project post-mortem owns expectations, delivery outcomes, project decisions, working conditions, learning, and handoff. Reference an incident record rather than copying its timeline or declaring its causes.
Should a project post-mortem include root causes?
Do not declare a root cause from a general review discussion. Record evidence-linked contributing conditions with status and reviewer role. If a material incident, safety issue, or complex failure needs causal analysis, use the accountable incident and root-cause process and reference its validated conclusion later.
Who should attend a project post-mortem?
Choose roles that can contribute relevant project, customer, delivery, operational, governance, and evidence perspectives. Separate facilitation from independent review where practical. Do not turn participation into personnel evaluation, force consensus, expose restricted evidence, or imply that attendance grants closure, acceptance, or action authority.
Can the validator prove that a learning or action is correct?
No. It rejects malformed records, broken references, unsafe fictional values, unsupported states, missing evidence, premature action acceptance, and explicit boundary violations. It cannot authenticate evidence, judge causation, validate general applicability, approve work, prove implementation, or demonstrate future effectiveness.
Create the next review surface
Turn project reflection into a bounded internal system
Describe the review, evidence, role, learning, and action-handoff workflow you need and build a first version with Playcode.
Build an internal toolThis ordinary informational article does not grant AI signup credits. Current product eligibility and limits apply.