Why the Same Infrastructure Project Fails Twice

A project fails. Someone writes up what went wrong. The recommendations get implemented: new supervision structure, tighter contractor vetting, and a revised payment schedule. Eighteen months later, a comparable project on a comparable site fails again, and the failure looks, on close reading, almost identical to the first one. Not the same contractor, not the same location, but the same shape.

This is common enough in Nigerian infrastructure delivery that it deserves a name: the re-failure pattern. A corrected project failing again, for a structurally similar reason, is not evidence that correction doesn't work. It's evidence about where the correction landed.

The pattern itself

A better way to evidence the re-failure pattern is to use projects where the delivery context itself makes documentation discipline visible. Dutum’s Purple Lekki project in Lagos was delivered as main contractor for Purple Group on a mixed-use building along Freedom Way, Lekki Phase 1. Dutum’s Sky Chef project in Abuja was also delivered as main contractor, this time for an airport catering facility with a basement, a regulated, time-sensitive aviation-support environment where sequencing and documentation failures carry sharper consequences.

Placed beside each other, Purple Lekki and Sky Chef give the article a stronger comparison than two generic real estate projects. One is a Lagos mixed-use development with public-facing commercial and lifestyle functions. The other is an Abuja aviation-support facility where the operating environment is more regulated and time-sensitive. If the same correction fails across both, the issue is less likely to be the personality of a site team and more likely to be a gap in the project framework itself.

Where the diagnosis usually stops

Most post-mortems in this sector stop at the level of the people and the site. Poor supervision. Contractor delay. A subcontractor who overpromised. Each of these is often true, and none of them explains why a corrected project reproduces the same failure under different people, on a different site, with a different subcontractor entirely.

The question a re-failure pattern should provoke isn't "who made the mistake this time." It's "what did the last correction actually change, and what did it leave untouched." Between Purple Lekki and Sky Chef, the useful comparison is not location or asset type. It is whether the same kind of scope, sequencing, approval, or payment ambiguity could still move through the system after the earlier correction had supposedly fixed it.

Execution failure and framework failure

An execution failure is a decision made badly inside a process that would have caught it if followed. A framework failure is a decision made badly because the process didn't require it to be caught at all.
Stricter contractor vetting addresses execution failure. It assumes the process was sound and the person operating it wasn't. A variation-order requirement that blocks continued work until scope changes are formalised addresses framework failure. It assumes the process itself had a gap that any reasonably motivated person, contractor or supervisor, could fall through.

These aren't always easy to tell apart from the outside. They usually become distinguishable only in hindsight, once a second failure repeats the shape of the first. That's the actual diagnostic value of a re-failure event: it tells you which kind of failure you're looking at, retroactively, in a way the first failure alone couldn't.

What a framework fix looks like in practice

A framework fix would therefore not be another supervision layer. It would be a documentation rule that travels from one project type to another: no scope expansion proceeds without a signed variation order, no payment milestone releases against work performed outside the documented scope, and no sequencing change is treated as approved until the commercial and technical consequences have been captured. That kind of rule is portable from Purple Lekki to Sky Chef because it governs the architecture of delivery, not the personality of a project team.

Why this matters to a capital allocator specifically

A one-off execution failure and a re-failure carry different risk profiles, even when the headline cause, a payment dispute or a delayed handover, looks the same on paper. An execution failure says something about the people on a specific project. A re-failure says something about the framework the sponsor runs every project through, which means it says something about every other project under that sponsor, not just the one that failed twice.

This is worth checking for directly, not inferring from a single post-mortem. Ask whether a sponsor's stated corrections after a failure changed a rule that applies regardless of who's on site, or changed who's watching a rule that was never written down in the first place. The first kind of correction travels to the next project. The second kind resets with every new team.