A snag list that actually closes

Snagging is the last thing that happens on a project and the first thing to be organised badly. A walk is done, defects are noted, a list goes to the contractor, and then the list does not close. It gets reissued, and longer at each reissue, because each walk finds new items and cannot tell which of the old ones were fixed.

The list is not failing because the fixing is slow. It is failing because of what a snag record does not contain.

Why the list never shrinks#

No identity. A snag is a line in a document, not a thing with a number. The same cracked tile is reported by the architect on Tuesday, the client's representative on Thursday, and the facilities engineer next month, in three different wordings. Nobody can tell they are one defect, so it is fixed once and closed nowhere.

No owner. The list is addressed to "the contractor". A project at handover has many contractors, and a defect that belongs to everybody belongs to nobody. This is the ordinary mechanism by which tasks stall between people: the item is not refused, it is simply never picked up.

No location precise enough to return to. "Bathroom tile chipped" is useless in a building of identical bathrooms. The man sent to fix it has to find it first, and if he cannot, he fixes the nearest plausible one.

No evidence of the original defect. Three weeks later the fixer says it was always like that, or that it was damaged after his work. Without a dated photograph of the defect as first seen, this is one person's word against another's, and it is usually settled by whoever is more senior rather than by whoever is right.

No closure test. "Done" is a message. Somebody says it is done, the line is struck through, and nobody looked. At the next walk the same item reappears and the list has lost the little credibility it had.

No state between open and closed. A snag waiting for material, a snag disputed, a snag that cannot be reached until scaffolding returns — all of them sit in the same "open" bucket as a five-minute job, so the count tells you nothing about what is actually blocked.

Four different things wearing one name#

Treating every line as "a snag" is why the list feels endless. There are at least four categories, and they need different handling and different money.

A defect. Work that was done and done wrongly. The contractor fixes it at his cost. No argument in principle, only about whether it is a defect.

Incomplete work. Not defective — absent. A socket that was never installed. This is not snagging at all; it belongs against the original scope and against the bill, and putting it on a snag list disguises the fact that the work is not finished and should not have been offered for handover.

Damage caused by another trade. The painter marks the finished floor, the plumber cuts the finished wall. The defect is real and the party who must fix it is not the party who owns the element. Without a category for this, the tiler is asked to redo work he did correctly, and he refuses, and the item sits.

A change the customer wants. Not a defect. A different colour, a socket moved. It has to leave the snag list and enter the variation process with a price, otherwise the list becomes the route by which unpriced scope enters the job at the end.

Recording the category at the moment of raising costs nothing and decides who pays, which is the argument that would otherwise happen twice.

The second walk, and the third#

Re-snagging is normal and should be designed for, not treated as failure.

The first walk produces the list. The second checks the fixes and finds new items, because access has changed and protection has come off. A third is common. What matters is that each walk can tell, item by item, what it is checking: a closed item being verified, an open one being chased, or something genuinely new.

That requires the snag to be the same object across all three walks. A list regenerated from scratch each time cannot do it, which is why the reissued spreadsheet grows.

Two failures deserve naming.

Closure by the fixer. The party who did the work marks it done. This is not closure, it is a claim of completion. Closure is an act by somebody else.

Closure by exhaustion. The date arrives, the list is long, and the remaining items are agreed to be "minor" and carried into a document nobody opens again. Six months later the same items arrive as complaints.

The shape that works#

One snag, one row. On that row:

• One identifier. Assigned when raised, never reused, never renumbered.
• One location. Unit, floor, room, element — precise enough that a man with the identifier and no other context can stand in front of it.
• One photograph of the defect as first seen, dated and located. What makes such a picture evidence rather than decoration is the subject of a site photograph is a record.
• One category — defect, incomplete, damage by others, customer change.
• One named owner, a person, not a firm.
• One closure photograph taken after the fix, from the same position.
• One closing party who is not the fixing party.

That last line decides whether the list closes. Everything else is bookkeeping; separating doing from accepting is what makes "done" mean something. It is the same principle that makes a handover fail or hold: somebody other than the man who produced the work has to accept it.

Why the spreadsheet gives up exactly when you need it#

A spreadsheet is fine for thirty items on one walk. It fails at the moment the list gets long, and it fails in a particular way.

Several people walk different floors on the same day and each fills a copy. The copies are merged by hand, so duplicates survive and identifiers collide. Photographs live in a phone gallery or a WhatsApp group, in neither case attached to the row. And the file has no history, so when a closed item reopens nobody can see who closed it or on what basis.

Whatever the list is kept in, the requirement is the same: a snag must be a record with a life, not a line in a regenerated document. And the list in the state it was on the day, open items named and owned, belongs in the handover file — not a clean sheet that pretends there were none.

The short version#

A snag list closes when each snag is a thing rather than a sentence: one identifier, one location, one photograph, one category, one owner, one closure photograph.

The person who fixes must not be the person who closes. And incomplete work and customer changes must be taken off the list entirely, because a list that contains four kinds of item cannot be finished — only abandoned.