Lessons learned reviews sit at the end of every project plan and get cut from almost every project schedule. On traffic signal infrastructure projects, that gap is costly. The technical complexity of these deployments, combined with the coordination demands across civil contractors, signal technicians, transport authorities, and local councils, means that each project generates a significant body of knowledge. When that knowledge isn't captured, the next project inherits the same gaps.
Bob Panich Traffic Signals runs lessons learned reviews as a structured part of project close-out, not as a box-ticking exercise. What follows is a practical account of how these reviews work, what they tend to surface, and why the format matters as much as the content.
Why most lessons learned reviews fail to produce usable output
The most common format is a single meeting held after practical completion, usually when the team is already moving to the next job. Attendees are tired. The meeting runs long. Someone takes notes in a Word document that gets filed and never opened again.
Three structural problems drive this outcome. First, the review is too far removed from the events it's meant to examine. A commissioning issue that caused two days of delay in week four is hard to reconstruct accurately in week sixteen. Second, the output isn't linked to any process or template that the next project team will actually encounter. Third, there's no distinction between findings that are specific to this project and findings that reflect a systemic issue worth addressing at the organisational level.
Fixing all three requires changing when, how, and where the review happens, not just whether it happens.
Running phase-based reviews instead of a single close-out meeting
The most effective structure is a short debrief at the end of each project phase: design completion, procurement close, civil works finish, and commissioning sign-off. Each debrief takes 30 to 45 minutes and focuses on three questions: what slowed us down, what went faster than expected, and what would we change about how this phase was set up?
These short reviews accumulate into a structured record. By the time the project reaches close-out, the team isn't trying to reconstruct events from memory. The findings are already documented. The close-out meeting becomes a synthesis exercise, not a memory test.
For traffic signal projects specifically, the phases worth debriefing match the delivery sequence. Design review catches issues with site survey data, civil design assumptions, and the accuracy of equipment specifications. Procurement review surfaces supplier lead time problems, specification gaps, and approval delays from transport authorities. The civil works debrief is where site condition surprises, utility conflicts, and access restrictions get documented. Commissioning review covers testing failures, software configuration issues, and any defects that emerged during functional testing.
Projects that include quality assurance checkpoints aligned to each delivery phase tend to produce better phase debrief data, because issues are already logged against defined criteria rather than recalled anecdotally.
What traffic signal projects consistently surface in lessons learned reviews
Across delivery projects, certain findings recur. They're worth naming because recognising a pattern is the first step to addressing it at a process level rather than treating it as a one-off.
Utility conflicts during civil works appear in the lessons learned review of almost every project that didn't include a utility potholing program during design. The finding is usually the same: the as-built drawings for existing services don't match what's in the ground. The fix is equally consistent: include potholing in the design scope, not as a construction contingency.
Equipment lead times are a second recurring theme. Signal controller hardware, detector loops, and pedestrian push-button assemblies procured without confirmed supplier availability dates frequently arrive late. Late equipment delays commissioning, which pushes the project into council road-opening permit extensions, which creates cost and stakeholder friction. The lesson is always the same: confirm lead times at the time of purchase order, not at the time of design.
Scope additions during construction are a third consistent pattern. A council requests an additional pedestrian phase mid-build. A transport authority asks for a new detection loop that wasn't in the approved design. These changes are often reasonable in isolation, but they accumulate. Scope creep on traffic signal projects is one of the most predictable sources of budget and programme pressure, and the lessons learned record provides the evidence base for enforcing a proper variation process on the next project.
How to separate project-specific findings from systemic ones
Not every finding from a lessons learned review belongs in a process update. Some issues are genuinely specific to the project: a particular contractor's performance, a site condition that won't recur, a council requirement unique to that local government area. Treating these as systemic issues and writing them into standard procedures creates process overhead without benefit.
A useful filter is to ask whether the same finding has appeared in the last two or three reviews. If it has, it's systemic. If it hasn't, document it for the project record but don't escalate it to a process change.
Systemic findings that do warrant a process update should be assigned to a named person with a completion date. A finding with no owner and no deadline is an aspiration, not an action. The most useful lessons learned registers treat each systemic finding as a corrective action item, tracked through to closure the same way a project defect is tracked.
Connecting lessons learned to handover documentation
Lessons learned reviews generate findings about how the project was delivered. Handover documentation records what was delivered and what the operating authority needs to maintain it. The two should cross-reference each other. A commissioning finding about a configuration quirk in the signal controller, for example, belongs both in the lessons learned register (as a process note for future projects) and in the handover package (as an operational note for the maintenance team).
Getting this connection right requires that the project manager treat the lessons learned review as a source document for the handover, not a separate exercise. Handover documentation on traffic signal projects that incorporates project-specific findings from the lessons learned review is more useful to the operating authority than a generic as-built package.
Making the output accessible to future project teams
A lessons learned register that lives in a project folder is accessible only to the people who know to look for it. Most future project managers won't. The output needs to exist in a format that a new project manager will encounter at the start of a project, not discover by accident.
The practical solution is a short summary document, two pages maximum, that sits in the project initiation template. It draws on the last three to five completed projects in a similar category: urban intersection upgrades, arterial corridor works, large-venue signal installations. The summary doesn't reproduce the full register. It highlights the three or four findings most likely to affect the new project, with a reference to the full record for anyone who wants to go deeper.
That's a small format change with a measurable effect. Project managers who start a job knowing the common failure modes of similar jobs make different decisions in the first two weeks. Those early decisions are where most of the avoidable problems on traffic signal projects are either prevented or locked in.