3 reasons why your Big Bang legacy replacement will most likely fail miserably!

This morning I was listening to the radio and first, there was an item about a large government organization that had spent 4 years and a boatload of money on a Big Bang legacy replacement. The project was canceled and had been a complete waste of time, energy and money.

Right after this item, there was a commercial from a company that made the promise to rebuild your legacy software easy peasy. All you had to do was give them your code (and probably a nice sum of money) and they would build it again with the latest and greatest tooling and you could, in a Big Bang, replace your legacy software with their new and improved version. I have a very hard time imaging how this would work for any complex system (and are not most systems complex?).

After working in IT for more than 30 years, I am baffled by this fondness for Big Bang replacements. In my experience, they are a guaranteed recipe for disaster. If you go for a Big Bang, that might be exactly what you will get. An explosion that leaves you with ringing ears and a lot of debris.

This blog is not so much meant for the IT-people, because I assume they are aware of the Big Bang risks. This blogpost is meant for the business managers and purchasers that still make the mistake of thinking that a Big Bang is safer than a gradual replacement. And I agree, on paper, it can look like a viable option. In the real world, however, it almost never is.  

In my opinion, here are 3 main problems with the Big Bang approach, namely:

1. Big Bang is per definition a very high-risk project, but the risks are almost always underestimated;
2. Big Bang will lead to an unmotivated team;
3. Big Bang projects lack management, costs and steering measurements.

These problems are elaborated on below.

High-risk project.

There are many dangerous aspects of a multi-year project and I tried to summarize some of them below.

• It is not possible to understand how the new system should look and which features are going to be important 2-3 years from now. Technology changes very rapidly, for instance, look at how AI has changed our lives in the last years.
• Real customer feedback will be after the Big Bang. Hence, if you were going the wrong way, you will not know before it is too late!
• The world is changing fast and most changes are beyond your influence. You can just sit and see it happen. New laws, new political power (did you see Trump coming?? Or the Brexit??) and they will affect your way of doing business and, hence, your systems;
• Often the ambition for a big project is just too high and our understanding of the complexity of the system and the world around it is too low.

Unmotivated team.

• A long-term project seems to be all about making a planning and steer with it. However there is an anti-pattern there, namely, the developers tend not to feel responsible for the planning and not pay attention to it. Project leader: How much work will be implementing this feature? Developer: I have no idea. I really have to dive into it, do some research and even then. Project leader: I need a number for the planning. Just give me an optimistic and pessimistic number. Developer: Mmm optimistic maybe 2 weeks but it could also be 3-4 months. The project leader will write down 2.5 months in the planning, however, the developer does not feel it is his number and looks at the project leader as an annoying entity from a different galaxy.
• The Big Bang replacement focuses on the implementation of many features instead of creating a solution for a business problem. Developers will start to implement the features that are fun, easy to do and work. The headache features are most likely postponed until the end of the project. You probably heard of the saying that 80 percent of the work is done in 20 percent of the time? This is the reason why.
• At the start of the project, developers will need a Project Start Architecture (PSA) and this can’t be an evolving architecture. No, it has to be right and be able to support everything. This generally leads to a general purpose architecture, that slows down the developers, because they have to find ways to get around the architecture. The architecture will not support the development team but restricts them.

Lack of management, costs and steering measurements.

The common pitfalls are:

• Everybody realizes this is a complex project, and create a complex organization around the project with steering committees, change boards, project management teams and project teams meetings. However -and this is the paradox- this will make decision making only more difficult. Tough decisions tend to be pushed around, back and forth between the layers and slow down the project. Furthermore, there is a lot lost in the communication between the layers;
• The further we are with the project and the more money that has been spent, the more difficult it will be to decide to stop the project. There has already been so much money and time spend, that it is impossible to declare defeat.
• Management can only make GO/NO-GO decision when reaching certain milestones.

Conclusion

Summarizing, do not lightly start a Big Bang project, but go with a more agile, gradual project. Keep thinking about making or replacing 1 step at the time in the smartest way and when you have completed that step, start thinking about the next step.

More information from Trifork: