HKSM

A facilitated review held while the project is still underway to analyze recent incidents, decisions, and outcomes. It surfaces lessons and corrective actions early so the team can adjust course and share knowledge before more work is done.

Key Points

• Conducted during execution, not after project or phase closure.
• Blame-free and focused on learning, prevention, and rapid improvement.
• Time-boxed and data-informed, using facts from recent work.
• Generates specific actions with owners, due dates, and success measures.
• Feeds the knowledge repository and updates plans, risks, and processes.
• Scales from quick huddles to structured sessions depending on impact.
• Aligns with governance by documenting decisions and accountability.

Purpose of Analysis

Turn recent experience into immediate improvements that reduce risk and waste. Maintain transparency with stakeholders and support sound decision-making.

• Prevent recurrence of defects, delays, and outages.
• Validate or adjust assumptions, designs, and operating procedures.
• Strengthen controls, compliance, and safety.
• Accelerate throughput by removing bottlenecks and handoff issues.
• Capture tacit know-how before it is lost.

Method Steps

• Trigger and scope: define the event or pattern to review and the time window.
• Collect evidence: pull logs, metrics, change records, and relevant communications.
• Invite the right participants: people closest to the work plus decision-makers as needed.
• Set norms: state the goals, time box, and a blameless, fact-based approach.
• Reconstruct the timeline: map what happened, when, and who or what was involved.
• Identify contributing factors: people, process, technology, environment, and governance.
• Synthesize insights: distinguish root causes from symptoms; note what worked well.
• Define actions: remediation, prevention, and amplification of effective practices.
• Prioritize: use impact and effort to select a feasible set for the next cycle.
• Assign owners, due dates, and success criteria; capture decision rationale.
• Update artifacts: plans, risks, issues, SOPs, and the knowledge base.
• Follow up: review completion and effectiveness in the next stand-up or checkpoint.

Inputs Needed

• Event description, incident or defect reports, and helpdesk tickets.
• Performance metrics, monitoring dashboards, and test results.
• Change logs, deployment records, and configuration baselines.
• Schedule snapshots, WIP limits, and throughput or cycle-time data.
• Risk and issue registers, assumptions log, and decision logs.
• Stakeholder and user feedback, acceptance criteria, and quality standards.
• Policies, SOPs, and compliance requirements relevant to the work.

Outputs Produced

• Action list with owners, due dates, and measurable outcomes.
• Updates to plans, backlog items, and change requests where needed.
• Revisions to risks, issues, and assumptions with new response strategies.
• Improved procedures, checklists, templates, and guardrails.
• Knowledge article summarizing context, findings, and decisions.
• Stakeholder communication summarizing impact and next steps.

Interpretation Tips

• Look for system patterns across people, process, and technology, not a single culprit.
• Triangulate quantitative data with eyewitness accounts and artifacts.
• Separate facts from opinions; mark uncertainties for follow-up analysis.
• Beware hindsight bias; assess decisions relative to information available at the time.
• Favor changes that are testable within the next iteration or milestone.
• Track effectiveness using leading indicators such as defect escape rate or mean time to recovery.

Example

Mid-migration, performance degraded after a weekend release. The team holds a 45-minute in-progress postmortem using monitoring data and change records.

• Findings: autoscaling thresholds were misaligned with new instance types; load tests skipped due to a scheduling gap.
• Actions: correct autoscaling policy, add a pipeline gate for load-test evidence, update the deployment checklist, and post a knowledge note.
• Follow-up: verify improvement via response-time SLOs over the next two releases.

Pitfalls

• Blame or defensiveness that suppresses facts and learning.
• Meeting without data, leading to speculation and weak actions.
• Over-scoping the session so nothing is completed within the time box.
• Skipping owners and due dates, causing actions to fade.
• Running too rarely or too often relative to risk and impact.
• Failing to update official logs and procedures, so improvements do not stick.
• Excluding key stakeholders who must approve or implement changes.

PMP Example Question

During execution, a critical defect escaped to production. What should the project manager do to apply an in-progress postmortem effectively?

1. Delay the review until project closing to avoid distracting the team.
2. Hold a brief, blame-free session using recent data to identify causes and assign concrete actions with owners and dates.
3. Ask team members to email lessons learned at the end of the phase.
4. Escalate to the steering committee to initiate disciplinary actions.

Correct Answer: B — Hold a brief, blame-free session using recent data to identify causes and assign concrete actions with owners and dates.

Explanation: In-progress postmortems occur during execution, focus on facts and learning, and produce actionable improvements. Waiting or seeking punishment does not address root causes or enable timely correction.