Why Implementations Fail: The Human Factor

Dec 26, 2003

Allen Bernard

Simply put, nine system failures out of ten, it's the human factor. And even that 10th example probably has a very strong human component hiding somewhere

"Even if the solution doesn't work, it's still a human failure," said Tony Gerth, vice president of Enterprise Resources Transformation for EDS. "Either because of inadequate design decisions or inadequate testing; there would have always been places in the project lifecycle to catch that problem."

In his experience, most enterprise-grade technology works. He has never seen an example of system failure because the technology was inherently flawed. More often than not, if that appears to be the case, what you probably have is an application installed in the wrong environment. And this is a human failing. The technology works but somewhere, somehow someone did not do enough due diligence to ensure the application would run as advertised in your environment, on your infrastructure.

"It may get packaged as a technical problem by somebody down-the-pike," agreed Tom Topolinski, a Gartner analyst, "but typically, if it's a technology problem, it's not because of bad technology. We don't see that much. What we typically see is it's a bad fit because somebody bought something that wasn't a good fit to their requirements."

But this is only one definition of failure: where a solution does not run well or as expected because of technical problems. More often failure comes from a flawed change management plan that either overlooks end users or tragically underestimates the importance of their buy-in into the project, said Gerth.

"I've found people are typically pretty reasonable," he said. "So, if you do an adequate job explaining why is this of strategic importance to the company, why is important for you to support this, what kind of benefits you are going to get ... the majority of people will buy into it and work hard to make it happen."

But, if change management is handled by decree, where top management expects buy-in (and therefore, the quick productivity gains or cost savings promised by the vendor) simply because they say so: "[t]hat's not what I would call effective change management," said Gerth.

Another measure of failure can be poor ROI, but this may (and probably is) be caused by inadequately trained personnel. Again, a human failure in planning and execution as much as a technology issue, said Carl Frappoalo, co-founder and executive vice president of the Delphi Group.

"I'm always amazed at how people will make a purchase like this without really, fully knowing what it is they need and what its going to take," he said. "You've got to look at the whole issue: what impact is this system going to have on the users, the user desktop, the network, traffic on the network, and is all this configured for all of that? Which, to me, is a human issue."

To avoid these, and the many other definitions of failure, planning is key. But, even more important is the proper execution and follow-through of the plan since what a new system really comes down to is an exercise in change management. What business processes will have to be changed in order to accommodate the new system? How will users react? Do they know why the system is being change? What are the key infrastructure components that will have to integrated to make the new system work? And so on and so on.

Without this process of close and careful evaluation of existing technology resources, capacities, capabilities and business processes, the likelihood of your new ERP or CRM or SCM, or other acronym-laden system failing, increases exponentially.

There are all kinds of things that can be done to help smooth the process and, compared to the cost of the technology are not very expensive. In Gerth's experience, most large implementation budgets allocate less that five percent of the overall budget to change management issues like training and communication. This is low, he said. A good budget would be somewhere around 10%.

Frappoalo suggests spending those dollars in the following order of importance:

  • Do an information, business process and legacy system inventory so you know your starting point;
  • Determine exactly what you want the system to do and how you are going to get that performance;
  • Communicate the impact of the new system to all levels of the organization; and
  • Don't skimp on the training: make sure people know how to use the new system.
  • Simply put, said Topolinski, leave as little to chance as possible. "Do your homework."


    0 Comments (click to add your comment)
    Comment and Contribute

    Your comment has been submitted and is pending approval.



     (click to add your comment)

    Comment and Contribute

    Your name/nickname

    Your email


    (Maximum characters: 1200). You have characters left.