Why software projects derail, and how to defuse the switchover

A large software project rarely falls over on the day you expect. It sinks away. A release slips a quarter, a module moves to the next phase, the old and the new environment run side by side for months. By the time the big switchover arrives, half of what was promised turns out not to be there. The bill has already been paid by then.

The pattern has been measured

Together with the University of Oxford (2012), McKinsey studied more than 5,400 large IT projects, each with an initial price above 15 million dollars. On average they ran 45% over budget and 7% over time, and delivered 56% less value than forecast beforehand. Half exceed the budget substantially. A larger budget offers no protection, it only raises the stakes.

Why it goes wrong

The cause is rarely one wrong technical choice. It is the setup. A replacement is tendered as one large block, with one end date on which everything has to go live at once. The scope is nailed down in advance, while the business keeps changing in the meantime. The further the project progresses, the more money is in it, and the heavier it weighs to stop or adjust. Bad news travels slowly to the top, because nobody wants to be the one who brings it.

That is how a project arises that is too big to fail and too unwieldy to succeed. The decision to carry on has already been made at every moment, long before anyone can see whether it works.

Do not assume this only concerns projects of 15 million dollars. The mechanics scale down. An ERP migration, a new point-of-sale system, a CRM that finally connects to the accounts: it is the same setup of one big bang on one date. For a company of two hundred people, a failed switchover is as threatening as a write-off of tens of millions for a large group. What counts is the proportion to revenue, not the absolute amount.

The switchover is the real risk

Ask an executive team where the pain sits, and the answer is almost always the same: the cutover. The day on which the old tool goes off and the new one goes on. Everything that worked on paper for months now has to work all at once, with real data, real customers and a front desk that cannot wait. If that day fails, the business falls back on the system it just wanted to let go of.

That is where a big bang shows its price. All the risk is saved up for one moment. Anyone who wants to reduce that risk has to break that moment into pieces.

A project that is too big to fail is also too big to steer. The only real control is the freedom to stop after every step.

Waves instead of a big bang

We build in waves. Each wave delivers one working piece of the platform, in production, with real users, before the next one begins. At the end of every wave there is a go/no-go. Not a steering committee leafing through a status report, but a decision based on something that runs.

A gate only turns green when that working piece meets a few hard conditions:

• the users do their real work in the new module, not in a test environment
• the data is migrated and checked by the people who work with it every day
• the measurable goals of that wave are met, in figures, not in impression
• finance has seen the costs of the step and co-signed them

Until a wave meets that threshold, the legacy simply keeps running. You never switch off a working system for something that still has to prove itself. The old and the new module run side by side until the new one is stable, and only then does the old one go. There is no longer a day on which everything has to succeed at once, because there is never more than one wave at stake at a time.

Something in hand quickly, and the freedom to stop

The first wave delivers a working result within 90 days, something that stands in production and that your people really use. No demo, no report that asks for trust on credit. From that point you take every next wave separately. If a go/no-go turns out no-go, the base fee stops. You do not keep paying for a direction that does not prove itself, and you are not tied to anything, because the code sits in your own repository from day one.

That reverses the logic of the large project. The momentum no longer lies with carrying on because so much is already in it. It lies with proving. Every step has to earn itself before the next one begins. And because the legacy keeps running until that proof is there, a no-go costs you time and some tuition, not a business.

A software replacement does not have to be a bet on one date. Anyone who builds in waves knows after the first 90 days whether the approach is right, and keeps the choice at every step to stop, adjust or push on. The next wave only begins once the previous one runs in production and the figures are met. That is not slower. It is the difference between a project that keeps slipping and one that delivers something you can use every month.