Turning post-mortems into lean improvement actions

Project post-mortems often become well-written archives: the timeline is reconstructed, causes are debated and a list of lessons is filed. That record has value, yet it can fail at the point where development work needs to change. Teams return to the next project with the same overloaded handoffs, unclear approvals, recurring defects and meeting-driven decisions. The missing step is not more documentation. It is a disciplined path from evidence to a small set of tested improvements.

A lean approach treats every project review as a learning cycle. Findings are separated from assumptions, improvement work is prioritised according to expected value, and responsibility for testing the result is made visible. This shifts the focus from explaining past performance to changing future work. It also gives project managers, engineering leaders and continuous improvement teams a practical way to connect lessons learned with Kanban, standard work, pull planning and digital visual management.

Rebuild the review around evidence

Begin with the artefacts produced during delivery rather than with personal recollections alone. Bring together the approved scope, baseline plan, milestone records, change log, issue history, inspection results, meeting decisions and cost information. Reconstruct what happened in sequence, identifying where the planned and actual paths diverged. This creates a shared fact base from which the team can examine constraints, missing information and process weaknesses without turning the discussion into a search for someone to blame.

Separate observations from interpretations. A delayed approval is observable; “the sponsor was unresponsive” is an interpretation that may obscure a missing decision rule or an overloaded governance structure. Look for recurring patterns across functions such as requirements, procurement, design, testing, production and handover. Useful evidence can include schedule variance, rework, blocked time, first-pass yield, change churn, late supplier responses, safety events and customer impact. Quantifying these conditions makes it possible to distinguish an isolated issue from a systemic problem worth addressing.

The review format must also reflect Australian delivery conditions. Project teams in Melbourne, Sydney and Brisbane frequently work across offices, subcontractors and remote sites, with participants joining from different time zones. Mining and energy projects may add fly-in, fly-out crews whose handover information depends on concise written standards. Australian workplaces often value direct, pragmatic communication and relationship-based coordination, although those customs vary between organisations. Reviews should therefore make decision rights, record keeping and escalation paths explicit rather than relying on informal understanding.

Project Visit’s coverage of Sweden’s lean tradition offers a useful reference, including Volvo-related experience, but Australian teams should adapt the lessons to local workplace consultation, regulatory and supply-chain conditions rather than copy them wholesale.

Convert findings into a prioritised action backlog

Not every observation should become a task. A retrospective covering a complex program can easily generate dozens of recommendations, most of which will lose momentum in competing project commitments. Group observations into recurring themes, then describe each theme in terms of the process gap, its affected stakeholders and the evidence supporting it. Distinguish symptoms from probable causes and proposed solutions. This prevents the action backlog from becoming a list of disconnected fixes aimed only at the most visible event.

Assess each candidate improvement against its expected effect, effort, confidence in the evidence, dependencies and potential risk. Safety, compliance and irreversible customer impacts naturally require priority, while a minor reporting inconvenience may not justify interrupting delivery. Confidence matters as much as scale: a modest countermeasure supported by strong evidence may be more useful than an ambitious proposal based on speculation. Limit the selected work so the team can test it properly and compare the result with the baseline established during the review.

Digital tools can make this prioritisation clearer, provided they preserve the reasoning behind each decision. Project Visit’s example of automating task prioritisation illustrates how a lean task board can represent priority, ownership, status and flow. The board should show a small number of active improvement items rather than reproduce every project issue. WIP limits, blocked-time visibility and a clear pull rule help teams move from discussion into execution while preventing the improvement stream itself from becoming overloaded.

A reliable action set for every review

Turn the selected countermeasure into executable work. A useful action identifies the current condition, the change to be tested, the person accountable for coordinating it, the people contributing and the date on which its status will be reviewed. “Improve communication” is too broad to manage. “Introduce a two-day approval window for supplier technical queries and measure response time over the next four weeks” can be tested. Accountability should clarify commitments without recreating the blame avoided during the review.

Run the action through a compact PDCA cycle: plan the test, do it on a limited scale, check the evidence and standardise or adjust the result. When the countermeasure works, incorporate it into standard work, training, work instructions, checklists or system rules. When it fails, record what the team learned and return it for another cycle. This prevents the post-mortem from ending at a list of good intentions and connects the review directly to lean improvement practices such as mistake-proofing, visualisation and just-in-time response.

• State the gap using an observable fact, a baseline measure and the stakeholder affected.
• Select one countermeasure with a defined expected effect, test period and operational risk.
• Name one accountable owner, identify the contributing team and record a review date.
• Define the metric, success threshold and response if the expected effect is not achieved.
• Place the action in the live visual workflow and update standard work after the result is confirmed.

Connect learning to visual planning

Improvement actions need a place in the operating system of the organisation. For software and engineering teams, that can mean a digital task board connected to requirements, risk, testing and delivery milestones. For physical projects, it may involve visual construction planning, production boards, quality controls or handover checklists. In each case, the team should be able to see what is planned, what is active, what is blocked and which decisions are overdue. The project post-mortem then feeds the next planning cycle instead of remaining outside it.

This is particularly important in Australian markets where automotive, mining, energy and infrastructure programs combine global suppliers with local contractors. Volvo-related networks and other Tier 1 supply chains often require decisions to travel across organisational and geographical boundaries. Procurement relationships may support rapid cooperation, yet informal approvals can still create delays that disappear from the formal plan. A shared visual board can expose those delays while preserving the local custom of practical, direct communication.

Avoid automating a weak process simply because a tool is available. Enterprise systems should capture the agreed workflow, standard work and decision rights rather than add another reporting layer. Teams also need capable facilitators and leaders who ask about the reliability of the change. For organisations building that capability, FDI learning resources can support practical development, while the review itself should remain grounded in project evidence and the people who performed the work.

Measure whether learning is changing the work

Measure both the completion of improvement actions and the effect they produce. Closure rates are easy to report, but they can reward teams for completing trivial tasks. Pair them with indicators such as reduced rework, shorter approval cycles, fewer repeat defects, improved schedule reliability and lower blocked time. Compare the result with the baseline and note any conditions that affected the test. A countermeasure that worked in one project but failed to transfer should trigger a review of its assumptions, scope and standardisation.

Institutionalise useful learning by maintaining a searchable record of validated countermeasures and the conditions under which they performed. Connect that library to risk reviews, design standards, procurement requirements and onboarding. Communities of practice can compare evidence across projects, while project leaders can include unresolved lessons in stage-gate decisions. Over time, this creates a feedback loop in which project experience changes enterprise systems and current project work benefits from earlier experience.

The practical takeaway is that every project review should leave behind one visible improvement action, one accountable owner, one measure and one scheduled check on the result.