Study: Why IT implementations go bad

It's every IT buyer's nightmare: Your company decides to invest in complex management software. You spend months -- or years -- implementing the system and training staff in its use. And in the end, you find yourself with an expensive, nonfunctional mess.

Industry consultant and Harvard Business School Assistant Professor Andrew McAfee has been watching that situation play out for nearly a decade, as he works with organizations deploying such technology as ERP (enterprise resource planning), CRM (customer relationship management), supply-chain management, e-commerce and procurement systems.

In an article published this week in the Winter 2003 issue of the MIT Sloan Management Review, McAfee examines the common flaws underlying troubled implementations. With anywhere from 30 percent to 75 percent of new software systems failing to meet expectations, according to various studies McAfee cites, it's a problem pertinent to many in the IT industry.

"I wrote a lot of case studies, so I could teach about different situations. The more I did that work, the clearer it became to me that the problems faced were not separate things, they are all examples of the same thing, which is basically an effort to change business processes using IT. Once I had that lens on it, a whole bunch of things fell into place," McAfee said in an interview. "I started to see that the problems experienced with all these different categories of projects could be divided into a few categories fairly easily."

His key premise is that IT implementation failures often stem from attempts to follow a "universal checklist" of deployment to-dos. Items on that list too frequently have "all the value of a bumper sticker," McAfee writes in his article.

Advice like "secure top management support" sounds good, but in some cases -- such as straightforward limited projects -- high-level support isn't necessary. Other times it's critical. The hard but essential part of IT change is determining what elements are key to an individual project, he suggests.

McAfee threads his article with mini-case studies supporting his arguments. There are the now-familiar cautionary tales, such as Nike Inc.'s disastrous implementation of supply-chain software from i2 Technologies Inc. The culprit there was misspecification, McAfee says -- where a company finds itself with software that technically works but not in the way the customer expected it would.

There are also success stories, notably that of online secondhand-books merchant Alibris Inc., which McAfee cites as a rare model of an exchange that links together independent businesses effectively. Exchanges are particularly difficult systems to make work, McAfee argues, because they require members to cede some decision-making to a party outside their own organizational borders, and few companies are willing to yield that authority.

McAfee offers in the article his own brief checklist of "ground rules that apply in all situations." His suggestions:

  • Treat new systems as a business change, not a technology switch, with clear project responsibility and leadership from the organization's business ranks.

  • Don't skimp on resources devoted to the project.

  • Don't oversell the system. Set clear goals and a scope at the outset, and keep them from expanding.

  • Track the project's progress and results. (That sounds obvious, McAfee admits, noting that a shocking number of organizations nonetheless neglect such vigilance.)
  • Test everything before it goes live, but don't try to run old and new systems in parallel.

  • Consider carefully what frequent pitfalls are likely to afflict the specific project in question.

"The idea that I really want to get across is that one size is never going to fit all here," McAfee said. "I really want to see how that comes across to people. Too often, the starting point is looking at the specifics of supply chain vs. ERP vs. CRM and so on. But the technology, I think, is the wrong starting point for analysis. I think the right starting point is the questions I ask in the article, about people, project complexity, the importance of the business process the project is going to define. Questions about your specific implementation and your specific implementation challenges."

A brief overview of McAfee's article, "When Too Much IT Knowledge Is a Dangerous Thing," is available online at http://smr.mit.edu/past/2003/smr44211.html.

Join the newsletter!

Error: Please check your email address.

More about Harvard Business Schooli2i2 TechnologiesMcAfee AustraliaMITNikeVigilance

Show Comments

Market Place

[]