A Replacement That Turned into a New Build: How Trying to Do Too Much Left Us with No System at All

Years ago, I experienced a spectacular failure on a system development project.

The project was supposed to rebuild an internal system that ran as a Windows desktop application as a web-based system.

In other words, it was a system replacement.

But the project was never completed, and the system was never released. The development company had to absorb an enormous financial loss, and the project ended as a full-blown disaster.

Looking back now, the cause of the failure is quite clear.

We tried to carry out a system replacement and a new development project at the same time.

While We Are Rebuilding It, We Might as Well Fix This Too

A system replacement is essentially the migration of an old system to a new technology platform.

In this case, it meant replacing a Windows application with a web application. Basically, the new system only needed to support the same business operations as before.

But once development began, all kinds of requests started to emerge.

“Since we are moving it to the web anyway, we should make this screen easier to use too.”

“The current workflow has a lot of waste, so let us review that while we are at it.”

“Could we add this new feature as well?”

I understand the impulse. If you are already spending a great deal of money to rebuild a system, you naturally want to fix the inconvenient parts of the old one at the same time.

But this is where a major trap lies.

If you are porting the existing system as it is, then at least you already have an answer for the business requirements: the current system.

Once you start reconsidering the design itself, however, you also have to reconsider that answer.

What is more, changing a single screen can affect the processing behind it and even the work performed by other departments.

In this way, a project that was supposed to be a straightforward migration gradually turned into a new development project involving business process reform.

The only things that remained unchanged were the replacement-level budget and schedule.

It would have been more surprising if that had worked.

When a Project Is on Fire, the Request Becomes “Just Give Us Something That Works”

Naturally, the design took a long time to finalize, and development fell behind schedule.

Then, when the schedule had become impossible to recover, the client made a request along these lines:

“Forget about improving the design. Just give us something that works.”

I understand that impulse too.

But if that was the goal, we should have done it from the beginning.

Development was already proceeding on the assumption of a new design. Returning to a simple copy of the current system at that point would mean throwing away what we had built and starting over again.

And there was no budget for that kind of rework.

We had intended to complete the system in a single attempt, but a change of direction halfway through forced us to build it twice.

We had wanted to keep costs down, yet we ended up choosing the most expensive approach possible.

Should We Have Treated It as a New Development Project from the Start?

Looking back, I think we should have clearly defined two options at the beginning.

The first was to commit to a pure system replacement.

We could first have moved the system to the web while preserving the existing business requirements. Once it was running reliably in the new environment, we could have addressed process improvements separately.

The second option was to treat it as a completely new development project from the outset.

If we were going to make piecemeal changes while remaining constrained by the old system’s specifications, it might have been better to redesign everything from scratch.

In that case, of course, both the budget and schedule would have needed to be estimated as a new development project.

I do not know which option would have been right.

What I do know is that the worst choice was to preserve the pretense that we were “migrating the existing system” while doing work that was closer to a new development project.

We took on all the constraints of a replacement and all the difficulty of a new build.

In the End, Nobody Benefited

The project was never released.

I do not know what the client did afterward. Perhaps they asked another company to rebuild it, or perhaps they continued using the old system.

The development company that accepted the contract, meanwhile, had to absorb the entire cost of the expanding project.

For me personally, it remains an unforgettable failure.

In system development, people often say, “While we are at it.”

While we are rebuilding it, let us improve this too. Let us change that as well. We might as well add a new feature at the same time.

Each suggestion sounds reasonable on its own.

But after combining all of them, we completed nothing at all.

In software development, “while we are at it” can be an extremely dangerous phrase.

There is a Japanese proverb about losing money by trying to buy something cheaply.

That is exactly what happened.

Except this time, we did not merely lose the money. We never even received the product we were supposed to be buying.