When IT implementation turns sour

Last week's discussion of IT implementation struck a personal chord with me. When it comes down to it, companies can choose to build their IT system from scratch or adopt a package deal - and when the packaged software requires business practices to change friction is bound to surface. [1]

For experts in the supply chain management field this isn't new news. In a chapter on Information Technology in a Supply Chain recommendations are given to "take incremental steps" and "select supply chain IT systems that are able to give a company an advantage in the areas most crucial to the success of the business." [2]

Of course, this advice sounds fine on paper, but in industries from manufacturing to human services it is far easier said than done.

About one year ago a large scale IT transformation was set in motion at my workplace. Perhaps luckily, I came on board some six months after the initial database launch, but what I found was the system was still hitting regular roadblocks. Rather than build a new database from scratch, the organization had elected to hire a team of developers to adapt the system used by a partner agency to our needs. This would give both systems a crucial advantage by allowing for a uniquely integrated data collection system and information sharing capabilities. If it worked, it would be an analysis goldmine.

Unfortunately, the system was launched before many aspects of it were finalized. The plan to gradually bring providers on board and to add elements of the process to the database in phases over time was a textbook plan. Literally. The strategy avoided the pitfall of attempting a "big bang" approach to IT implementation. [3]

As it turns out however, this too comes with its own set of problems. By gradually implementing the system, necessary interim work-arounds and temporary business processes were implemented to keep the process flowing despite limitations of the database. Then, as changes requested months earlier were finally implemented, the system no longer worked with the business processes that had been adopted. The work flow was evolving faster than the IT solutions could be adjusted simply out of necessity. Now, almost a full year since its launch, the system is still requires duplicate record keeping and additional work outside of the database just to keep things running.

Thinking of my own frustrations from dealing with this process on a day-to-day basis, I wondered, what other organizations or companies have found new IT implementations to be less than they'd hoped? Where have their been flat out disasters? A 2009 list of top ten IT disasters published by CIO Magazine offers tales both humerous and tragic of IT woes at companies and organizations from Hershey to the University of Massachusetts. My personal favorite among these is the tale of Nike whose i2 Demand Planning software implementation led to a 20% stock dip in large part because it couldn't support the company's business model. [4]

So what does all this mean for IT innovation? Are we better off investing in custom software, or steering clear of change altogether? Maybe not, but how can we be sure to avoid implementation projects that shoot past budgetary and timeline goals by a mile?


Sources:
[1] Tom Mochal, "Why do package implementation projects take so long?" Tech Republic, 2001, www.techrepublic.com/article/why-do-package-implementation-projects-take-so-long/1059124 .
[2] Sunil Chopra and Peter Meindl, "Chapter 16: Information Technology in a Supply Chain," Supply Chain Management, 4th ed., Pearson Education (USA), 2009, pp.464.
[3] Ibid.

[4] Thomas Wailgu, "10 Famous ERP Disasters, Dustups and Disappointments," CIO Magazine Online, 2009, http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments?page=1&taxonomyId=3009 .