On July 6, 2013, Asiana Flight 214 touched down on the runway at San Francisco International — too low, too slow, correction too late. Three people died. The investigation found no single cause. It was a chain. The autopilot had been inadvertently deactivated. The crew noticed the airspeed loss too late. None of the four pilots in the cockpit called out the decaying speed — until seven seconds before impact.

Aviation calls the model behind this "Swiss Cheese": every safety layer has holes. A crash only happens when the holes in all layers happen to align.

IT projects crash by the same principle. We just don't name the holes.

The Swiss Cheese Model — Why One Mistake Is Never Enough

James Reason, the British psychologist behind the model, arrived at a core insight: complex systems never fail at a single point. They fail when multiple weaknesses become permeable at the same time.

In aviation, the layers are well defined — checklists, Crew Resource Management, automated warning systems, tower control. Each layer catches errors that slipped through the previous one.

In IT projects? The layers theoretically exist too: a briefing process, a scoping document, a sprint review, a change request form. But honestly — how often are those layers actually airtight? Who has a change request form that someone actually fills out before "just a small tweak" creeps into the project?

The Standish Group's CHAOS program has tracked IT project outcomes for three decades. In 2020, the success rate — projects delivered on time, on budget, on scope — stood at 31%. Less than a third.

The remaining two thirds? Not all outright failures. Many "challenged" — completed, but with blown budgets, pushed timelines, or reduced scope. Some abandoned entirely. And the post-mortem almost always reveals the same pattern: it wasn't the one mistake. It was the chain.

The Chain Reaction — From Vague Requirements to a Dead Project

Let's walk through a typical scenario. It starts innocently enough.

Layer 1 permeable: The vague brief

The client says: "We need a dashboard." What they mean: an interactive data visualization with filters, export options, and role-based access. What the proposal says: "Dashboard development, approx. 40 hours." The first hole in the cheese. But on its own, it doesn't cause a disaster — vague briefs happen, experienced teams catch them in the next step.

Layer 2 permeable: No structured scoping

Except the next step doesn't happen. Instead of a detailed scoping document, there's a half-hour call where everyone nods. The holes in layer two now overlap with those in layer one. If you want to spot delays before they cascade, you need a clear baseline — and that's missing now.

Layer 3 permeable: Scope creep without change control

Three weeks in. "Could we add a second chart real quick?" Then: "The CEO would like a PDF export." Then: "Actually, we'd need this on mobile too." Each change sounds small. Together, they're 60 extra hours — but nobody counted because there's no process for it.

This is scope creep in its purest form. Not malicious intent, not incompetent clients, not lazy developers. Just the absence of a structural layer that absorbs change.

Layer 4 permeable: No real-time transparency

The project budget is gone by week six. But nobody knows — because time tracking lags three weeks behind and actual costs aren't reconciled against the estimate. The last cheese slice goes permeable. All the holes now align. The project crashes.

Scope Creep Isn't the Problem — Missing Structure Is

Here's where it gets interesting. Most articles about scope creep recommend something like: "Learn to say no." Or: "Define the scope clearly." Solid advice, as far as I can tell. About as useful as "Don't fly into the mountain."

Because what is scope creep, really? It's not some mysterious phenomenon. It's the symptom of a missing layer in the Swiss Cheese model. If your project management has no change control process — not as a PDF form buried in a SharePoint folder, but as a lived routine — then scope creep isn't the cause of your problems. It's the logical consequence.

PMI confirmed this in a 2021 study: projects with structured change control experience an average of 7% scope variation. Projects without: 52%.

7% vs. 52% scope variation. The difference isn't willpower or discipline — it's a process.

The pattern repeats across other delivery bottlenecks too. Treat only the symptom, and it comes back. Seal the layer, and you prevent the chain reaction.

Structural Solutions Over Symptom Management

After every crash, aviation didn't replace the pilots — it redesigned the systems. Crew Resource Management was introduced after investigations showed co-pilots weren't challenging their captains. The solution wasn't "Be braver" — it was a procedure that made dissent mandatory.

Applied to IT projects, that means: not "Define scope better" — but building systems that prevent undefined scope from growing unnoticed.

Four layers that need to hold

Layer 1: Structured scoping. A proposal that doesn't just name a price, but explicitly lists what's included — and what isn't. "Out of scope" isn't rudeness. It's professionalism.

Layer 2: Change control as routine. Every change — no matter how small — gets logged, evaluated, and approved. Not to block clients. But to jointly decide what the change means for budget and timeline.

Layer 3: Real-time transparency. If you only learn how your project stands at month's end, you learn about problems too late. Projects need an instrument that makes current capacity and utilization visible — not retroactively, but now.

Layer 4: Review rhythm. Not the annual post-mortem after everything's gone wrong. Short, regular check-ins that ask: Are we still in scope? Does the budget hold? Are there shifts we need to address now?

None of these layers is spectacular. None requires a master's degree in project management. But — and this is the point — they need to exist simultaneously. The Swiss Cheese model works both ways: one solid layer compensates for holes in the others. Three solid layers make a project nearly indestructible. But zero layers? Then a vague brief is all it takes for the chain reaction.

Data from the Standish Group's CHAOS program shows consistently over decades: projects with more than two structural checkpoints fail significantly less often. The difference isn't developer quality. It's the system.

Black Boxes, Red Numbers

Aviation investigates every crash. Not to find someone to blame, but to improve the system. The black box — the flight data recorder — is the tool for that. It records what actually happened. Not what the plan said.

Most IT service providers don't have a black box. They have proposals nobody reconciles with actual hours. Timesheets filled out three weeks late. And a gut feeling that says: "It'll be fine."

Preventing scope creep isn't a mindset problem. It's an infrastructure question. A question of layers that keep the holes from aligning.

We built Leadtime because in 15 years of running IT services, we flew enough projects without a black box. Not because we're better pilots — but because we finally wanted to know why the landing was so rough.