Punch lists, and the items that are still open three years later

A punch list is the register of everything found and not yet fixed. It grows through construction and commissioning, and at handover it represents the difference between what was specified and what was delivered.

The characteristic failure is not that items exist. It is that the list is transferred to operations at handover with no categorisation, no owner and no closure mechanism, at which point it becomes an archive of known defects.

Categorise before handover

Every item needs a decision, taken jointly, before the project team leaves.

Must be closed before startup: anything affecting safety, protective functions, or the ability to operate.

Time records can help teams compare planned engineering effort with the work actually completed. For a related reference, see time tracking software.

For process facilities, the surrounding management framework is covered in OSHA process safety guidance.

To be closed during the support period: defects that do not prevent operation, with a date and a named owner on the contractor side.

Accepted: items the site has decided to live with, recorded as a deliberate acceptance with the reason.

Converted to a change request: items that are actually scope changes rather than defects, which need funding rather than fixing.

The categorisation conversation is the hard part

Whether an item is a defect or a change determines who pays, which makes the discussion commercial as well as technical.

Holding it while the contractor is still on site and still has retention outstanding produces a very different outcome from holding it six months later. Deferring the conversation is the single most expensive mistake available at this stage.

Items that hide behind workarounds

A defect with an available workaround tends to be downgraded, because the plant can operate. Over time the workaround becomes the procedure and the defect is forgotten.

The cost is real and invisible: an extra operator action per shift, or a manual check that would not otherwise be needed, continuing for the life of the plant.

Recording the workaround alongside the item, with an estimate of what it costs per year, makes the trade explicit.

Tracking after handover

Once the project closes, the punch list needs a home in the site's normal work management system rather than a project spreadsheet, or it becomes invisible.

Items transferred into the maintenance backlog get prioritised against everything else, which is usually correct. Items left on a project list get prioritised against nothing.

Retention as the mechanism

Contractual retention held against punch list closure is the most reliable tool available, and it only works if the list is agreed before final payment.

Sites that release retention on a schedule rather than against closure lose their leverage precisely when they need it.

Reviewing the closed list

At the end of a project, the punch list is a record of what went wrong and is worth reading as such.

Patterns — a category of fault recurring across many loops, a supplier whose items dominate, a design decision that generated repeated problems — inform the next project. This review is rarely done because everyone is exhausted, and it is the cheapest available source of lessons.

Distinguishing defect from incomplete

Punch lists mix two different things: work that was done wrongly, and work that was not done at all. They need different handling.

Incomplete work is a scheduling matter with a completion date. A defect requires diagnosis, correction and retest, and may indicate a systematic problem affecting items not yet found.

Separating them makes the list more useful and prevents the pattern where a defect affecting many items is closed individually forty times rather than being addressed at its cause.

Sampling for systematic faults

When a defect is found, the question is whether it is isolated or an instance of a pattern. A wiring error in one loop may be one mistake or the same mistake in every loop wired by the same person on the same day.

Sampling adjacent items when a defect is found is a small additional effort that occasionally reveals a much larger problem while it can still be fixed under the contract.

Closure evidence

An item marked closed should carry evidence: what was done, by whom, when, and the result of the retest.

Closure recorded as a tick allows items to be closed by assertion, which is how lists shrink rapidly toward the end of a project without the underlying work being completed.

Visibility to those who need it

The punch list matters to people beyond the project team: operators who will work around open items, maintenance who will inherit them, and whoever authorises startup.

A list held in a project system that operations cannot see produces the situation where the control room discovers a known defect by encountering it.

Publishing the open items relevant to operations, in a form they will actually see, is a small step that avoids a predictable frustration.

The list as a project metric

The open item count and its trend is one of the more honest indicators of project progress, because it is difficult to improve except by doing work.

Tracking additions and closures separately is more informative than the total: a flat total with high addition and closure rates describes a project finding and fixing problems, while the same total with neither describes one that has stopped.

Handling items nobody will fund

Some items are genuine deficiencies that neither party will pay to correct, and they sit open indefinitely because closing them requires someone to accept them.

Forcing the acceptance decision — with a named person recording that the site will live with this, and why — is uncomfortable and better than an open list that everyone has stopped reading.