The most dangerous project is the one nobody calls a failure

Aviation is modernising. Most of the money will land in the one outcome nobody thinks to worry about.

Ten years ago I started writing an article about why big enterprise IT projects destroy value. I got as far as a diagram and one technique, and then it sat in a folder. I found it again this month. It reads like it was written about aviation, so I am finishing it here, where it belongs.

We operate the most advanced machines on earth. Aircraft that navigate themselves across oceans, maintained to a standard measured in single events per million. Then we land one, and the record of that landing goes into a spreadsheet, a paper log, or an email attachment that somebody retypes at month-end.

The distance between the sophistication of what we fly and the sophistication of how we account for it is the widest gap in our industry, and it has been for thirty years. We know this. It is why almost every airport, group and air navigation service provider is running some kind of modernisation programme right now.

What we discuss far less honestly is how those programmes usually end.

Four ways it can end

The same money is either an investment or a cost. Which one it turns out to be is decided long before go-live.

FailThe project is cancelled and the lawyers are called. Money, time, opportunity and good people are burned. In the worst case the operation is left weaker than it was before anyone touched it.

PrecipiceThe project passes the point of no return. Going back to the old system is now more painful and more expensive than funding the new one to completion, so more money is found. Not because it is working, but because stopping costs more. Senior people resign. Long days, shifting accountability and defensive posturing become the working climate.

EfficientThe project team reports success against time and budget. Change requests stayed inside palatable limits. Scope was quietly trimmed at some point to keep those two numbers true. Nothing in the operation is measurably better. The next phase is where the value lives, we are told.

EffectiveThe return outweighs the investment, and visibly. Constraints the operation had simply lived with are gone. People are pulling for the next thing rather than bracing for it.

The dangerous one is Efficient

Fail and Precipice are loud. Everybody in the building knows, and eventually somebody is forced to fix it. Efficient makes no sound at all. It lands on time, it lands on budget, it gets signed off, it gets a photograph. And because nobody ever calls it a failure, nobody ever comes back to it.

Look at where it sits on the curve. Efficient is not slightly positive. It sits exactly on the crossing point: the full cost paid, and the operation standing precisely where it started.

In aviation this is the default outcome, because of what we choose to measure. Went live. On budget. No safety event. All three can be true while air traffic, maintenance, apron, operations and finance quietly fall back to their own spreadsheets, each holding a different version of the truth, and the number the executive sees at month-end matching none of them.

The spreadsheet is the tell. When a new system goes live and the old workbook is still open beside it, that is not a training problem. It is the operation telling us the system does not fit the way the work is actually done, so people have routed around it. Maintenance plans in one workbook. Apron services scheduled in another. Operations keeps a third because neither of the first two has what it needs. Finance rebuilds all of it at month-end. Every one of those files is a private version of the truth, and none of them reconcile.

Four years later somebody asks why the numbers do not tie, and the honest answer is that they never did. The system changed. The data did not.

What actually causes it

Not incompetence. In my experience the teams are good. What causes it is deadline pressure meeting a scope that has to fit inside it. Something has to give, and the thing that gives is always the invisible thing: the data.

Import the old register exactly as it is, we will clean it later.
Leave that field as free text, we will standardise it later.
Take the default code even though it does not match how this airfield actually works, we will configure it later.

Every one of those decisions is defensible on the day it is made. None of them is ever revisited. The real cost of a shortcut is never the shortcut itself. It is the four years of ambiguous data it creates, and everything that then has to be done by hand or by memory on top of it: the maintenance forecast nobody quite trusts, the apron roster built from what the supervisor remembers about last winter, the capacity conversation with the regulator that becomes a rebuilding exercise, the executive report assembled by hand every month because no two sources agree.

It shows up wherever you look for it. In one legacy register we took over, several thousand recorded movements could not be reliably tied to an aircraft or an owner at all. That single gap is a billing problem, a maintenance-history problem, a capacity-planning problem and a compliance-record problem simultaneously, because all four are asking the same underlying question: what actually happened, and to whom. Nobody set out to lose that answer. It was lost years earlier, one reasonable shortcut at a time.

Scenario planning before project planning

This was the technique in the original article, and it holds up. Before we plan the project, we plan the scenarios.

Agree the low road and the high road for this specific operation. Not a generic risk register, the two stories that could actually play out here.
Name the events that could swing it, inside our control and outside it. A regulator whose records are still on paper. The one person who knows the legacy data leaving. A tariff gazette landing mid-migration. A database nobody has credentials for anymore.
Define the flags that tell us a scenario is starting to play out, while there is still room to steer.
Prepare the contingency for each flag before we need it.

Then the part that is actually hard: monitor the flags and act on them. Instrument them so they are visible rather than felt. Say them out loud the moment they appear. Take them to the steering committee and enact the contingency.

Almost every project I have watched end on the Precipice raised every one of its flags internally, in corridors and side conversations, and escalated none of them.

Doing it properly is not the expensive option

When we say we do not take shortcuts, the fair question back is whether that makes us slower and dearer. It does not, and the reason is a distinction we hold to strictly.

When time is short we cut scope. We never cut quality. Fewer things, each one finished properly, beats more things each one three-quarters done. A scope cut is honest, visible and reversible: everyone knows what was left out and it can be added later. A quality cut is none of those things. It is invisible, it is permanent, and it charges interest.

What "properly" means, in practice

Culture claims are cheap. Every supplier in this industry says it does things properly. So here are the specific rules we work to. They are not aspirations, they are how the work runs, and they are things you can hold us to.

We clean the data at migration, not afterwards.Dirty data imported on day one is dirty data forever, because there is never a quiet week to go back for it.
We will not write ambiguous data, ever.If a faster path produces a record that somebody has to interpret later, that path is closed to us regardless of what it saves today.
We configure, we never fork.Every airport we run sits on one codebase. There is no private branch quietly rotting somewhere with your name on it.
The release is gated, not trusted.Automated gates block a deployment that fails our own standards. If the work is incomplete, the gate stops it and no human judgement call can wave it through.
Operations can veto a release.Keeping what is already live running beats adding to it. Every time.
One green check is not proof.We verify independently before we call anything done, and we say what remains unverified.
We name what is not finished.Out loud, in writing, at the time. Deferred work that is declared is a decision. Deferred work that is quietly shipped as complete is a defect.

Aviation does not need to be persuaded to modernise. That argument was won years ago. What we need is to stop counting a project as a success because it landed on a date, and start counting it on whether the operation underneath it actually changed.

The system is not the asset. The data underneath it is. Everything we build is arranged around that one idea.

"We would rather not show it than show something we are not proud of."
— Hein Pretorius, Founder, Ironwood Aero