This section establishes the foundational context of the project. Accurate documentation here ensures future teams can understand the project's origins, scope, and initial ambitions. Be precise and objective.
Project Name or Codename
Project Classification
Sunsetted Project (intentional shutdown)
Failed Pilot (did not meet success criteria)
Unsuccessful Experiment (hypothesis invalidated)
Other
Project Start Date
Project End Date (or Sunset Date)
Core Team Size (peak number of people)
Total Budget/Resources Invested (approximate)
Original Project Goals & Objectives (as stated at kickoff)
Success Metrics & KPIs Defined at Start
Key Stakeholders & Sponsors
Was this project part of a larger strategic initiative or program?
What primarily prompted the initiation of this project?
Customer or user request/feedback
Identified market opportunity
Internal innovation or R&D
Competitive pressure or threat
Strategic business priority
Regulatory or compliance need
Other
This section captures the gap between what you believed would happen and what actually occurred. Honest assessment here is critical for validating or invalidating organizational assumptions and improving future forecasting.
Central Hypothesis or Core Assumption
How Did You Plan to Validate This Hypothesis?
Hypothesis vs. Outcome Matrix
Key Hypothesis or Assumption | Expected Result/Success Criteria | Actual Result & Evidence | Variance Explanation & Learnings | |
|---|---|---|---|---|
Did you observe any unexpected positive outcomes or side-effects?
Did you observe any unexpected negative outcomes or side-effects?
At what project stage did deviation from expected outcomes first become apparent?
During initial planning or design
During development or execution
During testing or QA
During pilot or soft launch
After full launch/market release
Never clearly identified
Other
Key Performance Metrics Deep Dive
Metric Name | Target Value | Actual Value | Performance vs. Target (1=Far Below, 5=Exceeded) | Root Cause for Gap | |
|---|---|---|---|---|---|
Customer/User Feedback Summary (if applicable)
Did external market conditions change significantly during the project?
This section drives deep introspection into why outcomes diverged from plans. Focus on systemic issues, not individual blame. Identify patterns that could affect other teams.
Primary Root Cause Category
Technical or architectural issues
Product-market fit problems
Resource or budget constraints
Strategic misalignment or pivot
Execution or delivery gaps
External factors (regulatory, competitive, economic)
Team or organizational dynamics
Other
Detailed Root Cause Analysis (5 Whys or similar)
Timeline of Critical Events & Decisions
Date | Event or Decision | Impact on Project | Category | |
|---|---|---|---|---|
Technical | ||||
Business | ||||
Resource | ||||
Significant Obstacles Encountered (select all that applied)
Technical debt or legacy system constraints
Critical skill gaps in team
Budget overrun or funding cuts
Unrealistic timeline pressure
Stakeholder conflict or priority shifts
Regulatory or compliance hurdles
Aggressive competitive response
Key team member turnover
Vendor or third-party failures
Inadequate tools or infrastructure
Other
Rank the Top 3 Most Impactful Obstacles (1=Most Impactful)
Technical debt or legacy system constraints | |
Critical skill gaps in team | |
Budget overrun or funding cuts | |
Unrealistic timeline pressure | |
Stakeholder conflict or priority shifts | |
Regulatory or compliance hurdles | |
Aggressive competitive response | |
Key team member turnover | |
Vendor or third-party failures | |
Inadequate tools or infrastructure |
Were key risks properly identified and documented during project planning?
Did the team possess the right capabilities and capacity to execute?
Were there decision-making process challenges?
Did communication breakdowns contribute to the outcome?
Technical Challenges & Architecture Lessons
Resource Constraint Details
External Factors Impact Analysis
Every project creates value, even in failure. Identify what can be salvaged, reused, or built upon. This transforms sunk costs into future accelerators.
Are there reusable code components, libraries, or technical modules?
Are there reusable datasets, models, or research findings?
Are there reusable processes, frameworks, or methodologies?
Top 3-5 Key Strategic Insights Gained
What Would You Do Differently Next Time? (Specific Actions)
What Would You Repeat or Double-Down On?
Best Practices Identified
Anti-Patterns & Pitfalls to Avoid
How complete is the documentation of this project's artifacts, decisions, and rationale?
Completely undocumented
Partially documented
Adequately documented
Well documented
Comprehensively documented
Are there any patentable innovations, IP, or unique discoveries?
What new capabilities or skills did the team develop?
Technical skills (specify in comments)
Domain or market knowledge
Project management techniques
Stakeholder management
Data analysis or experimentation
Crisis management
Other
Estimated Value of Reusable Assets (if quantifiable)
Learning is only valuable if shared. Create a concrete plan to ensure insights reach those who need them. Think broadly about audiences and formats that maximize impact.
Which Teams or Functions Should Prioritize Learning from This? (select all that apply)
Engineering & Architecture
Product Management
Design & UX
Marketing & Growth
Sales & Business Development
Data Science & Analytics
Leadership & Strategy
All Teams
Other
Recommended Primary Sharing Format
Written post-mortem report (detailed)
Presentation to leadership
Interactive workshop for peers
Recorded video summary
Internal blog post or newsletter
Case study for training library
Lunch-and-learn session
Other
Urgency of Knowledge Sharing (1=Low, 5=Critical)
Key Messages for Different Stakeholder Groups
Specific Preventive Measures for Future Projects
Specific Teams or Individuals to Brief Personally
Repository Location for All Artifacts & Documentation
Are there specific follow-up actions needed to act on these learnings?
Is there an opportunity for team members to mentor others on these learnings?
Proposed Metrics to Measure Impact of Knowledge Sharing
Additional Comments or Reflections
Analysis for Project Post-Mortem & Learning Capture Form
Important Note: This analysis provides strategic insights to help you get the most from your form's submission data for powerful follow-up actions and better outcomes. Please remove this content before publishing the form to the public.
This post-mortem form represents a masterclass in organizational learning documentation, meticulously structured to capture the full spectrum of insights from failed or sunsetted projects. Its five-section architecture directly addresses the critical phases of project retrospection: establishing context, measuring outcomes against hypotheses, diagnosing root causes, salvaging value, and ensuring knowledge propagation. The form's greatest architectural strength lies in its mandatory field strategy, which compels teams to document essential information while respecting their time and cognitive bandwidth by keeping supplementary details optional. This balance ensures both high completion rates and rich, actionable data quality.
The form excels at transforming the uncomfortable process of documenting failure into a structured, blame-free learning exercise. By forcing objective documentation of original goals, success metrics, and central hypotheses before exploring what went wrong, it creates an evidence-based narrative that prevents revisionist history and finger-pointing. The inclusion of both quantitative fields (budget, dates, team size) and qualitative analysis frameworks (root cause analysis, strategic insights) ensures a multi-dimensional organizational memory that serves multiple stakeholder needs—from finance planning future budgets to engineering teams avoiding technical pitfalls.
The opening section's mandatory fields establish an immutable foundation for all subsequent analysis. Project Name or Codename serves as the primary key in organizational knowledge bases, enabling future teams to quickly locate and reference this post-mortem when considering similar initiatives. Without this mandatory identifier, the entire knowledge management system would fragment, rendering the learning inaccessible when needed most.
Project Classification is crucial for organizational pattern analysis, as the lessons from a "Sunsetted Project" differ significantly from a "Failed Pilot" or "Unsuccessful Experiment." This categorical data enables leadership to identify systemic issues across similar project types, making it indispensable for strategic portfolio management. The follow-up specification option for "Other" classifications provides necessary flexibility without compromising data integrity.
The mandatory date fields—Project Start Date and Project End Date—provide temporal context essential for understanding project duration, seasonal market effects, and organizational capacity during specific periods. This chronological anchor prevents misattribution of failures to current conditions when they may have been influenced by past circumstances, ensuring accurate organizational learning.
Core Team Size (peak number of people) and Total Budget/Resources Invested (approximate) capture resource allocation data that is fundamental to ROI analysis and future planning accuracy. These mandatory quantitative metrics enable organizations to calculate the true cost of failure, assess whether resource constraints contributed to outcomes, and build more realistic forecasting models for future initiatives.
Original Project Goals & Objectives (as stated at kickoff) and Success Metrics & KPIs Defined at Start are perhaps the most critical mandatory fields in the entire form. They create an objective baseline against which all subsequent analysis is measured, preventing the hindsight bias that often plagues post-mortem discussions. By documenting what success originally looked like, the form ensures that lessons are grounded in historical reality rather than rewritten narratives.
The mandatory question Was this project part of a larger strategic initiative or program? reveals organizational interdependencies that might otherwise remain hidden. This field is essential for understanding cascading effects and ensuring that parent initiatives learn from subsidiary failures. Similarly, What primarily prompted the initiation of this project? captures the original motivation, helping identify whether failures stemmed from flawed inception logic or execution challenges.
This section's design brilliantly captures the experimental nature of modern product development. The Central Hypothesis or Core Assumption question forces teams to articulate their fundamental belief, making it impossible to obscure core flaws behind technical details. This mandatory field is essential for organizational learning as it reveals whether failures were due to invalid assumptions (strategic error) or poor validation methods (execution error).
The mandatory yes/no questions about unexpected positive outcomes or side-effects and unexpected negative outcomes or side-effects demonstrate sophisticated understanding of innovation dynamics. Many failures contain seeds of future success, and these fields ensure serendipitous discoveries are documented and can be leveraged by other teams. This prevents valuable insights from being discarded with the "failed" project.
At what project stage did deviation from expected outcomes first become apparent? provides crucial timing data that can inform early warning systems and stage-gate reviews for future projects. This mandatory field helps organizations understand whether they need better monitoring during development, testing, or post-launch phases, directly impacting future project management methodologies.
The Did external market conditions change significantly during the project? mandatory question acknowledges that not all failures are internal, capturing contextual factors beyond team control. This prevents unfair blame attribution and ensures organizational learning accounts for market volatility, competitive dynamics, and regulatory shifts that might necessitate different strategic responses in future initiatives.
The optional Hypothesis vs. Outcome Matrix and Key Performance Metrics Deep Dive table provide structured frameworks for detailed analysis without creating mandatory burden. Their design as optional fields respects the time constraints of teams while offering pathways for deeper reflection when warranted.
This section forms the diagnostic core of organizational learning. Primary Root Cause Category with its structured options ensures consistent categorization across projects, enabling pattern analysis at the organizational level. This mandatory field is indispensable for leadership seeking to identify whether systemic issues cluster around technical architecture, product-market fit, resource constraints, or strategic misalignment.
Detailed Root Cause Analysis (5 Whys or similar) is the most important mandatory field in this section. It demands deep systemic thinking, preventing superficial finger-pointing and uncovering structural issues in processes, culture, or strategy. The requirement for multiline text encourages narrative depth that reveals interconnections between causes, providing rich qualitative data for organizational development.
The Significant Obstacles Encountered multiple-choice question with mandatory selection creates a quantitative dataset of common barriers across the organization. This enables leadership to identify and address widespread issues—whether technical debt, skill gaps, or stakeholder conflicts—through targeted interventions rather than assuming each project's challenges are unique.
The series of mandatory yes/no questions—Were key risks properly identified and documented?, Did the team possess the right capabilities and capacity to execute?, Were there decision-making process challenges?, and Did communication breakdowns contribute to the outcome?—systematically probes common failure points. This diagnostic checklist ensures comprehensive analysis rather than selective storytelling, revealing process improvements needed in risk management, staffing, governance, and collaboration.
The optional Technical Challenges, Resource Constraint Details, and External Factors Impact Analysis fields provide depth without overwhelming the core root cause analysis. Their optional status respects team bandwidth while offering pathways for specialized learning in areas most relevant to each project's unique circumstances.
This section's mandatory fields drive the critical mindset shift from viewing projects as sunk costs to recognizing them as sources of future acceleration. The three mandatory yes/no questions—Are there reusable code components, libraries, or technical modules?, Are there reusable datasets, models, or research findings?, and Are there reusable processes, frameworks, or methodologies?—force teams to actively search for salvageable value rather than discarding everything in disappointment.
Top 3-5 Key Strategic Insights Gained is a mandatory field that codifies the most valuable organizational learning. It transforms experiential knowledge into shareable intelligence, ensuring that hard-won understanding about customers, markets, or technology doesn't remain siloed within the project team. This field directly feeds organizational knowledge bases and strategic planning processes.
What Would You Do Differently Next Time? (Specific Actions) is the most actionable mandatory field in the entire form. It translates reflection into concrete behavioral change, providing future teams with specific guidance on what practices to avoid, what processes to modify, and what assumptions to challenge. This field is essential for preventing repeated mistakes.
The optional fields about what to repeat, best practices, and anti-patterns provide additional texture without overwhelming the core insights. The documentation rating question helps assess knowledge management maturity, while the IP question ensures valuable innovations aren't overlooked for legal protection.
This final section ensures learning escapes the post-mortem document and actively influences organizational behavior. Which Teams or Functions Should Prioritize Learning from This? is a mandatory question that forces teams to think beyond their immediate circle, identifying affected stakeholders and preventing siloed knowledge. This field is essential for targeted knowledge dissemination.
Recommended Primary Sharing Format and Urgency of Knowledge Sharing are mandatory fields that create a concrete dissemination plan rather than vague intentions. They ensure decisions are made about how and when to share, making it more likely that learning will actually reach those who need it.
Key Messages for Different Stakeholder Groups is a mandatory field that ensures tailored communication. It recognizes that leadership needs different takeaways than engineering teams, and product managers need different insights than marketing. This mandatory requirement prevents one-size-fits-all communication that often fails to resonate.
Specific Preventive Measures for Future Projects is a mandatory field that bridges reflection to action. It ensures teams don't just identify problems but propose concrete solutions, process changes, or safeguards. This field transforms post-mortems from complaint sessions into improvement roadmaps.
The mandatory Are there specific follow-up actions needed to act on these learnings? question with its embedded action item table creates accountability. It ensures that insights lead to assigned actions with owners and deadlines, closing the loop between learning and implementation.
Mandatory Question Analysis for Project Post-Mortem & Learning Capture Form
Important Note: This analysis provides strategic insights to help you get the most from your form's submission data for powerful follow-up actions and better outcomes. Please remove this content before publishing the form to the public.
Project Name or Codename
Mandatory status is essential because this identifier serves as the primary key for knowledge management systems. Without a standardized, required name, future teams cannot reliably search for and learn from similar projects, rendering the entire organizational learning effort ineffective. Unique identification is the foundation of any searchable lessons-learned database.
Project Classification
This field must be mandatory to enable organizational pattern analysis across failure types. Categorizing projects as sunsets, failed pilots, or unsuccessful experiments allows leadership to identify whether systemic issues are concentrated in experimental work versus strategic initiatives, informing where to allocate oversight and support resources for maximum impact.
Project Start Date and Project End Date (or Sunset Date)
These mandatory date fields provide critical temporal context for understanding project duration, market conditions, and organizational capacity. They enable analysis of whether failures correlate with specific time periods, leadership changes, or market cycles, making them indispensable for accurate root cause analysis and future planning.
Core Team Size (peak number of people)
Mandatory collection of team size data enables organizations to assess whether resource levels correlate with outcomes. This data is fundamental for building realistic resource forecasting models and identifying whether failures stem from understaffing, overallocation, or team composition issues rather than execution quality.
Total Budget/Resources Invested (approximate)
This mandatory financial data is crucial for ROI analysis and understanding the true cost of failure. It enables leadership to make informed decisions about future investment thresholds, risk tolerance, and whether certain types of projects consistently exceed budget while delivering poor outcomes.
Original Project Goals & Objectives (as stated at kickoff)
Mandatory documentation of original goals prevents hindsight bias and ensures objective evaluation. Without this required baseline, teams could rewrite history to make failure appear inevitable or success criteria vague, destroying the integrity of organizational learning and leading to repeated strategic errors.
Success Metrics & KPIs Defined at Start
This field must be mandatory to create objective success criteria. Required documentation of specific, measurable targets ensures that failure is judged against stated intentions rather than shifting perceptions, enabling fair post-mortem analysis and preventing teams from moving goalposts after the fact.
Was this project part of a larger strategic initiative or program?
Mandatory status is essential for mapping organizational interdependencies. This field reveals whether failures cascade from parent initiatives or represent isolated issues, enabling leadership to address systemic problems at the correct organizational level rather than treating symptoms.
What primarily prompted the initiation of this project?
This mandatory field captures the original motivation, helping identify whether failures stemmed from flawed inception logic or execution challenges. Required documentation enables pattern analysis of whether projects triggered by certain factors (e.g., competitive pressure) consistently underperform versus those driven by customer needs.
Central Hypothesis or Core Assumption
Mandatory articulation of the core hypothesis is fundamental to organizational learning. Without this required field, teams cannot distinguish between strategic errors (invalid assumptions) and execution errors (poor validation), leading to misdirected improvement efforts and repeated mistakes based on unchallenged beliefs.
Did you observe any unexpected positive outcomes or side-effects?
This mandatory yes/no question ensures teams actively search for serendipitous discoveries rather than discarding everything in disappointment. Required documentation of positive surprises prevents valuable innovations from being lost and enables other teams to build on unexpected findings, transforming failure into future opportunity.
Did you observe any unexpected negative outcomes or side-effects?
Mandatory documentation of negative side-effects is crucial for organizational risk management. This required field ensures that harmful unintended consequences are captured and can be prevented in future projects, protecting the organization from repeating costly mistakes that might not be obvious in standard success metrics.
At what project stage did deviation from expected outcomes first become apparent?
This mandatory timing data is essential for building early warning systems. Required documentation enables organizations to identify whether deviations typically appear during planning, execution, or post-launch phases, informing where to implement better monitoring and stage-gate reviews to catch issues sooner.
Did external market conditions change significantly during the project?
Mandatory status ensures external factors are considered in failure analysis. Without this required field, organizations might unfairly blame teams for outcomes beyond their control, leading to demoralization and missed opportunities to improve environmental scanning and strategic agility.
Primary Root Cause Category
This mandatory categorical field is essential for organizational pattern analysis. Required classification enables leadership to identify whether systemic issues cluster around technical architecture, product-market fit, resources, or strategy, allowing targeted interventions rather than scattered, ineffective improvements.
Detailed Root Cause Analysis (5 Whys or similar)
Mandatory deep analysis prevents superficial blame and uncovers systemic issues. This required narrative field ensures teams dig beneath symptoms to reveal structural problems in processes, culture, or strategy, providing rich qualitative data that drives meaningful organizational development rather than scapegoating.
Significant Obstacles Encountered (select all that applied)
Mandatory selection of obstacles creates a quantitative dataset of common barriers across the organization. This field is crucial for identifying widespread issues that require systemic solutions, such as technical debt or stakeholder conflicts, rather than assuming each project's challenges are unique.
Were key risks properly identified and documented during project planning?
This mandatory yes/no question is essential for improving risk management processes. Required documentation reveals whether failures stem from poor risk identification or inadequate risk response, informing whether the organization needs better forecasting or better contingency planning.
Did the team possess the right capabilities and capacity to execute?
Mandatory assessment of team capabilities is crucial for talent management and future staffing decisions. This required field helps identify skill gaps and capacity issues that affect multiple projects, enabling proactive workforce planning and training investments.
Were there decision-making process challenges?
This mandatory field is essential for diagnosing governance issues. Required documentation of decision-making problems—whether slow decisions, unclear ownership, or lack of data—helps leadership identify where to clarify roles, improve data access, or streamline approval processes.
Did communication breakdowns contribute to the outcome?
Mandatory documentation of communication failures is critical for organizational effectiveness. This required field reveals whether issues stem from within-team, stakeholder, or cross-functional communication, informing targeted improvements in collaboration tools, meeting structures, or information sharing protocols.
Are there reusable code components, libraries, or technical modules?
Mandatory yes/no status ensures teams actively search for technical salvage value. Without this required prompt, reusable code is often lost in repository abandonment, leading to duplicated development effort and wasted resources that could accelerate future projects.
Are there reusable datasets, models, or research findings?
This mandatory question prevents valuable data assets from being discarded. Required documentation ensures that research findings, trained models, or collected datasets are identified and made accessible to other teams, maximizing the return on data collection and analysis investments.
Are there reusable processes, frameworks, or methodologies?
Mandatory documentation of process innovations ensures organizational learning extends beyond technical artifacts. This required field captures improvements in how work gets done, enabling other teams to adopt and adapt successful practices, accelerating organizational maturity.
Top 3-5 Key Strategic Insights Gained
This mandatory field is the cornerstone of organizational learning. Required documentation ensures that hard-won understanding about customers, markets, technology, or business is explicitly captured and can be shared, preventing experiential knowledge from remaining siloed within the project team.
What Would You Do Differently Next Time? (Specific Actions)
Mandatory status transforms reflection into concrete improvement. This required field ensures teams don't just identify problems but propose specific behavioral changes, providing future teams with actionable guidance that directly prevents repeated mistakes.
Which Teams or Functions Should Prioritize Learning from This? (select all that apply)
Mandatory audience identification ensures knowledge reaches relevant stakeholders. Without this required field, post-mortems often remain siloed within the project team, preventing cross-functional learning and allowing other teams to repeat similar mistakes.
Recommended Primary Sharing Format
This mandatory field creates a concrete dissemination plan rather than vague intentions. Required selection of format ensures decisions are made about how to share, making it more likely that learning will actually reach audiences in an accessible, actionable way.
Urgency of Knowledge Sharing (1=Low, 5=Critical)
Mandatory urgency rating is essential for prioritizing dissemination resources. This required field helps leadership prioritize which post-mortems need immediate workshops versus simple documentation, ensuring critical learnings are rapidly propagated.
Key Messages for Different Stakeholder Groups
Mandatory tailoring of messages ensures communication resonates. This required field prevents one-size-fits-all dissemination that often fails to connect, ensuring leadership, engineering, and product teams each receive relevant, actionable takeaways.
Specific Preventive Measures for Future Projects
This mandatory field bridges learning to action. Required documentation of specific safeguards, checks, or process changes ensures insights lead to implementation rather than remaining theoretical, directly reducing the probability of repeated failures.
Are there specific follow-up actions needed to act on these learnings?
Mandatory action planning creates accountability. This required field ensures insights lead to assigned actions with owners and deadlines, closing the loop between learning and implementation and enabling measurement of whether lessons actually change behavior.