Retrospective

A retrospective is a structured internal review conducted after an engagement closes to capture what worked, what failed, and what the team should do differently on the next engagement of that type.

What a retrospective covers

A useful retrospective addresses four areas:

1. What went well. Practices, tools, or decisions that produced good outcomes and should be repeated on similar work.
2. What did not work. Problems encountered, missteps made, and their root causes. The goal is root cause, not blame.
3. What surprised the team. Assumptions that proved wrong, risks that materialized without warning, or client behaviors that were not anticipated.
4. What will change. Specific, actionable changes for the next engagement of this type.

The standard for action items is specificity. “Better communication” is not an action item. “Send a written status update to the client sponsor every Friday by 3 PM” is.

Timing and format

The retrospective should take place within two weeks of engagement close-out, while delivery details are still accessible to participants. Waiting longer produces vague, reconstructed recollections rather than precise observations.

For long engagements of six months or more, a mid-engagement retrospective prevents the team from discovering correctable problems only at the end.

The session runs best with the full delivery team present, including subcontractors who played a significant role. The engagement manager facilitates. Partners attend as participants, not reviewers. Treating the retrospective as a performance evaluation discourages honest input from the people with the most direct delivery knowledge.

Common failure modes

• Held too late. When the retrospective occurs months after close-out, the detail needed for actionable findings is gone.
• Too senior. Run as a partner debrief rather than a delivery team session, it captures management observations but misses the ground-level problems that actually drove outcomes.
• No documented output. Observations discussed verbally but not written down cannot be retrieved or acted on later.
• No feedback loop. Findings that do not change templates, checklists, or estimating models have no effect on future engagements.

Making findings actionable

A retrospective is only useful if its output changes something. Findings should feed back into the firm’s delivery system:

• Estimating models. If an engagement overran, the retrospective should identify why and by how much, and that data should adjust baseline assumptions for similar future engagements.
• Proposal and scope templates. If certain scope assumptions repeatedly prove wrong, the template should reflect the correct assumption.
• Delivery playbooks. If a process failed, the better process should be documented for the next team.
• Risk checklists. If a risk materialized that was not in the risk register at kickoff, it should be added for similar engagements.

Firms that run consistent retrospectives and route findings back into their delivery system produce measurably better estimates and fewer repeated delivery failures over time. The retrospective is the mechanism by which lessons learned accumulate into institutional knowledge rather than disappearing when a project team disbands.