Another Large IT Project Failure – and How it Could Have Been Avoided

The City of Birmingham can be added to the long list of organizations that went bankrupt trying to replace their ERP system. They were running a heavily customized SAP system and tried to implement Oracle Fusion. As often happens in this kind of project, the costs exploded from the initial estimate of $25 million to $125 million by the last count. They are not done yet, and since they’ve stopped paying their bills, they might never be.

When you are faced with a legacy system no longer fit for purpose, don’t fall prey to the dangerous illusion that you can run one large project to replace it. A project is a collaborative enterprise intended to reach a well-defined goal. But for a large IT project, the project duration alone (four years and counting in Birmingham) ensures that the goalposts will have moved several times before you are done. Your Program Manager is not likely to be among the few hundred people in the world with the exceptional project and change management skills needed to pull off such a project.

A series of smaller projects to carve out and replace functionality in smaller chunks does not promise to solve all your problems in one fell swoop. But it has a much higher chance of success.

Are You Monitoring Your Automated Systems?

It is hard to anticipate the real world. I’m sure the wet concrete on the road in Japan looked just like solid ground to the delivery robot. Consequently, it happily trundled into the urban swamp and got stuck. The story does not report whether the delivery company managed to get their robot out before the concrete hardened…

This is why you need careful monitoring of all the fully automated systems you are deploying. The first line of defense is automated metrics and their normal interval. For a delivery robot, the distance covered over a minute should be greater than zero and less than 270 (if you have limited the robot to e.g. 10 mph). The second line of defense consists of humans who will evaluate the alarms and take appropriate action. The third line of defense are developers who will fix the software and the alarms.

Too many automated systems are simply unleashed and depend on customers to detect that something is wrong and complain. You want to figure out you have a problem before the image of your robot encased in concrete starts trending on Twitter.

Irrational Optimism

Beneficial Intelligence is out. This week: Irrational optimism. IT people are too optimistic about schedules and business cases. It is a natural consequence of our ability to build something from nothing. As a CIO or CTO, you need to make sure you have some pragmatic pessimists to point out the things that might go wrong. Because IT is too optimistic and Legal & Compliance is too cautious, IT organizations often turn to outsiders like me.

Listen here or find “Beneficial Intelligence” wherever you get your podcasts.