Disaster Recovery – the Price to Pay for Self-Inflicted Disasters

“A stitch in time saves nine” is a well-known saying. However, “familiarity breeds contempt” as they also say, and knowing your maxims off by heart doesn’t automatically mean taking the appropriate action. The “stitch in time” in IT terms is a proper plan, or good change management, together with backup planning if things don’t work out the way you thought they would. Yet IT disasters aren’t only about servers frying or a diggers hacking through a mains cable. They’re also about bad implementation of new enterprise applications like ERP. So what’s the “stitch” or the approach that can help companies avoid disaster in this case?

While ERP crops up frequently as the villain of the piece, other strategic applications for CRM (customer relationship management) and SCM (supply change management) can also do major damage. ERP disasters just seem to be documented more often. A classic case is that of the Levi Strauss Company and its $5 million project that mushroomed into a $200 million loss. But just to show that CRM and SCM can also wreak havoc, Hershey, the American foods company, took three years to put in a combined application for all three that blocked orders and shipping for 3 months.

Avoiding such IT disasters, the consensus is that such projects need to be business aligned, not technology aligned. So far so good, but opinions differ somewhat as to how the programming or configuration should be done after that. One approach is the Agile one, where frequent phased releases are supposed to help deliver benefits rapidly and keep the project aligned to real business needs. Others suggest that sticking to the initial schedule and resisting changes to project scope are the way to go. However, what they have in common is that if the project concerned becomes unsuccessful, terminating it early may stop a self-inflicted problem from becoming a catastrophe.