Troubled and Failed ERP Implementation

Causes, Cautionaries and Solutions

This paper was developed to provide general background to assist clients in understanding the causes of troubled and failed ERP (Enterprise Resource Planning) implementations, as well as approaches to solutions. ERPs primarily automate the transaction processing requirements of financial, distribution and manufacturing business processes.

1. Overview

Implementing ERPs may be the most complex and risky endeavor undertaken by a company. This is due primarily to the fact that the effort touches, perhaps drastically affects, and almost every business process within the enterprise. Change on such a scale is very difficult to accomplish, even in highly cooperative environments.

It is therefore not surprising given the complexity and the risk involved that ERP implementations sometimes encounter difficulties and sometimes fail. Difficulties alone can require expenditure of many millions of dollars that might have been saved had the difficulties been avoided. Outright failure can result in writing off the entire investment, which, for large companies, could run higher than $100 million. Severe difficulties or failure also could poison the atmosphere for other projects or for re-staging of the implementation: political capital, once lost, can be very difficult to reacquire.

A well-considered implementation plan in the right hands anticipates potential causes of difficulty or failure and provides means of addressing them should they be observed to develop during plan execution.

The remainder of this paper seeks to:

  • Identify major causes of difficulties encountered during ERP implementations, and what can be done to treat them so that they have minimum chance of actually arising; and
  • Should the implementation already be in trouble or acknowledged to have failed, how can the investment made to date be salvaged to the greatest extent possible by re-staging the implementation.

    2. Causes and Cautionaries

    This section identifies our view of the major causes of derailed ERP implementations, which are:

    1. 2.1 Incomplete Planning
    2. 2.2 Poor Change Management
    3. 2.3 Poor Expectation Management
    4. 2.4 Altered Internal or External Conditions

    Each subsection describes the cause and why it precipitates problems and what can be done to manage it as a set of symptoms before it becomes a problem.

    2.1 Incomplete Planning

    Any significant ERP implementation project should be planned employing a structured methodology that specifies activities, tasks, deliverables, and assigned human resources, in order to minimize the chance of missing key steps.

    When inadequate attention is paid to rigor in planning the result can be a series of unpleasant surprises during execution of the plan, surprises that may:

    • Require additional capital
    • Require additional elapsed time
    • Require more intense participation by internal personnel than had been anticipated by them.

    With too many such surprises and their effects, political capital with both management and key personnel will disappear. With the loss of political capital often comes effort on participants’ or management’s part to find reasons for failure, or at least to change project management, which can be highly destabilizing and further fuel the difficulties.

    Some key areas in which methodological rigor is particularly important in planning an ERP implementation include the following:

    • Project Organization – often, in companies with highly collaborative cultures, project organizational structures are constructed that are too highly matrixed at all levels. ERP implementation organization structures should be formed with an eye to effectively controlling thousands of interrelated tasks, many requiring little or no broad consensus.Effective command and control in support of timetables and budgets is the actual organizational objective. When legitimate and delicate disputes regarding policy arise, those who resolve them should be highly placed. Distinctions should be made between substantive policy disputes and less important ones, and people at each level authorized to decide them.
    • Too highly a matrixed structure can result in serious slippage in schedules and budgets as time are wasted trying to forge broad consensus in all areas.Too much slippage of this sort and confidence in the team’s ability to achieve its objectives will erode.


      Spend enough time during planning to adequately describe authority at each level of the organization, and then spend the time necessary to sell the idea throughout the company, explaining the reasons for the rules.

  • Business Process Reengineering – Too often companies overestimate (or are too effectively sold on) the adaptability of ERP products to unique business process requirements.
  • When the need to either modify business processes to satisfy the constraints of the ERP, or modify the ERP code to satisfy the requirements of the process, becomes very great and was unanticipated, then inadequate requirements definition is usually the cause. This suggests that the wrong ERP product was selected, which in turn usually reflects badly on those who did the selecting, who are often the same people who must address implementation problems. Consequently, it can be a very difficult political problem to address.

    Yet, if left unaddressed the problem can add so much cost and time to the implementation that failure could seem to be a blessing.


    During product selection, spend time identifying the business process areas that may contain unique elements, and particularly areas where the company has interest in improving processes. Do this with knowledgeable consultants from candidate vendors who can advise on product constraints, and who often can be engaged at cost because their companies are trying to close a software license deal. During product implementation planning, take the results of such sessions in to account when estimating related implementation tasks.

  • Report Definition, Interface Development, and Historical Data Conversion – The time and effort required to perform these implementation activities is often very highly underestimated. The impact of underestimating them is particularly severe because it usually is felt close to the end of the ordeal, when these activities, if not performed to schedule, could cause the roll-out to halt.
  • Tips:

  • With respect to Report Definition, make clear to management that this is a moving target, since users will approach the team many times over the course of a long implementation to add reports they had not considered before or complicate already-requested reports. Often, refusal is not an option. Identify consulting resources that can perform the commodity tasks of report definition and development, and have them ready to appear as needed. In this way, schedules might be minimally affected by adding the short-term hands necessary to perform the work within the overall schedule. Do not give management hard estimates as to the cost of this activity; rather, provide a range of most likely cost.
  • What is most often underestimated in Interface Development is the required complexity of the interfaces, rather than their number. Assume for estimating purposes that major interfaces require some re-design of the interfaced elements, which should result in safer over-estimation overall.
  • Often, when converting historical data across years it is determined but was not anticipated in planning that the same data entities had different meanings depending on the year: software was enhanced and the entity took on a different meaning. This affects the complexity of the conversion, since the data must be leveled across years in order to be converted. Assume for estimating purposes that five percent of the data entities will require leveling, which should result in safer over-estimation of the activity.

Equipment sizing – companies often underestimate the amount of computing power required to effectively support an ERP (which is nothing if not a hog). If this happens, the need to upgrade processor, memory or disk at very short notice to support an implementation can be a very expensive and time-consuming surprise.

Tip: While modeling throughput characteristics and implications, also require software vendors to introduce you to at least one, preferably several, customer(s) with similar transactional volume, and other sizing-sensitive characteristics. Ask why they sized equipment requirements as they did, and what experiences they had with sizing at implementation. Plan accordingly.

2.2 Poor Change Management

Change Management is the discipline that seeks to identify barriers to change in an organization and to formulate remedial programs that lower the barriers, thereby maximizing chances for success of the implementation.

Such barriers can include major cultural attributes, such as:

  • fear of change because the organization has been stable for many years with employees possessing substantial tenure; or
  • as simple as the outright refusal of a key individual to participate in the change; or,
  • again as complex as the clear and unavoidable obsolescing of skills possessed by large numbers of employees who may leave but are necessary through transition to the new environment.

In some highly complex and sensitive cases industrial psychologists are used to provide specialized insight to assist the implementation.

The primary objective of Change Management is to identify the substantive issues that could delay or complicate the implementation, or cause it to fail, to identify the implications of each change barrier, and to develop programs to mitigate the risks and lower the barriers. Contingencies also should be developed in the event that the primary programs do not succeed, and measurement schemes also should be developed to determine if the programs are on track through implementation.

A secondary but important objective of Change Management is development of a Communication Plan whose intent is to communicate implementation status to all stakeholders in the implementation.

When little or no Change Management is performed as part of implementation planning or as part of the actual implementation, significant risk is incurred. Some change barrier could surface to trouble or derail the implementation with no plan in place to manage the risk with sufficient speed to be effective.

The most important advice that can be given with respect to Change Management is to take it seriously. Many do not.

Inability to understand that people who feel threatened by change can derail an implementation in ways that are not easily identified or countered can result in barriers that become so high that they cannot be countered.

Often, internal personnel are too close to the underlying problems to be effective in identifying them. Independent consultants are best for this task. However, formulation of programs to manage the risk and lower the barriers absolutely require attention by senior internal personnel, guided by consultants, for only internal people possess the required organizational and cultural knowledge.


  • Communicate early with your people regarding the goals of the change, how those goals will be secured, what their participation will need to be, and what roles they will have in the new environment.
  • Be ruthlessly honest with yourselves about what affect the change will have on your people. They are probably intelligent and, sooner or later, will figure it out themselves. If the affect is negative and you create the perception that you care so little about their interests that you have not thought the matter through, they may react with anger and do what they can to derail the implementation. They may very well panic and seek other employment.
  • If their active participation in the company’s operations is key, at least through implementation, then such a reaction could pose serious danger to those operations.

2.3 Poor Expectation Management

This problem comes in two flavors, poor expectation setting, which involves the goals of the implementation, and poor expectation management, which is an on-going implementation problem. If unaddressed, either can derail the implementation.

The expectation manager in either case is the prime company mover of the implementation or a consultant who acts as his surrogate. Those whose expectations are both set and managed are senior management, who approve and fund action, and who expect business benefits to accrue from the investment.

If, in an attempt to secure management backing of an expensive and difficult project such as an ERP implementation, the prime mover successfully presents potential benefits that are too aggressive, then expectations have been poorly set. Sooner or later, usually later, after a great deal of capital has been consumed, it becomes evident that the benefits will not be secured, despite what might otherwise be a successful implementation. In management’s mind, this is a failure: an investment that did not produce anticipated benefits. If this is discovered at a point at which management believes that halting the implementation can prevent further loss, then it can fail. This is particularly so if project participants have been complaining about the extent of required involvement, the extra hours and pressure, all normal characteristics of an ERP implementation but additional ammunition to an unhappy management who feel betrayed.

When this happens, poor expectation setting might be traced to a consultant surrogate or to a software vendor, who may be overzealous in pursuit of his own interests, such as placement of a consultant team to assist in the implementation or closing of a software license deal.

The most important factor in managing expectations is usually project scope. Initial expectations of the implementation may have been set reasonably, but over time additional goals may be added, one by one, without subjecting them to the same achievability tests as the initial objectives. In such cases a cardinal rule of any already-complex undertaking is violated: do not try to do too much at once; if you do, you risk loss of focus, or the undertaking may develop beyond your span of effective control, and you may fail to achieve any objective.

If management is led to believe that additional goals are reasonable, and then realizes at some point that they will not be achieved, the same problems described above could develop.


  • When considering initial expectations of a major action such as an ERP implementation, particularly if consultants or vendors set such expectations, management should take great care to assure that the rational underpinnings of arguments used are tested thoroughly.
  • ERP program management should create a “phase awareness” in corporate management’s collective mind, to better manage expectations. In other words, when additional goals are presented, test them to determine that they can reasonably be added to the program. If they cannot, consider creating subsequent implementation phases to deal with them.

2.4 Altered Internal or External Conditions

Changes in internal or external conditions can trouble or derail an implementation because such changes can invalidate the premises that justified the implementation.

Significant change in a company’s management structure is a good example of altered internal conditions. Such change can fundamentally question the validity of the premises on which the ERP implementation was justified, because a different set of perceptions and values may rule. Additionally, new managements sometimes seek reasons to question initiatives taken by prior administrations. While this may sound irresponsible when millions of dollars are at stake, it is nevertheless very real.

Another example of altered internal conditions is divestiture of a significant piece of the business that was to be automated by the ERP, or acquisition of another company. Divestiture could call into question the cost/benefit value since a piece of the business that contributed the benefits is gone, while acquisition potentially introduces new requirements which could call into question the appropriateness of the ERP product selection, or the feasibility of the implementation plan.

Changed market or technology conditions are good examples of altered external conditions. For instance, a competitor might introduce a powerful new feature of customer service that threatens to bind customers more strongly to them, and the service is application software based, such as by an ERP.

In such a case, pressure could build to abandon the implementation to find and implement products that more effectively counter the competitive threat.

This is an example of a situation in which both market and technology conditions have been altered. A simpler example of altered technology conditions might be introduction of a new manufacturing approach that is automated by another ERP, which also could cause pressure to abandon an implementation and begin fresh with other products.


  • The potential for altered conditions sometimes can be anticipated, which could suggest re-scheduling the implementation for more stable times. For example, the management levels that normally approve major expenditures related to ERP implementation often are aware of imminent organizational changes before they happen. In such cases, it could be better to withhold approval until the new management team settles in and can take ownership of the effort.
  • On-going threat analysis is a useful technique for altered external conditions. As part of implementation planning, potential threats such as those described above could be identified and tracked through the implementation. Contingency plans in the event of threat materialization could be developed and could be ready for use to mitigate the threat or change direction in an orderly manner that salvages as much investment as possible.

Clearly, long implementation periods magnify the risk of these problems.


Given the high risk and cost of ERP implementations, it is clearly better to anticipate and effectively manage potential problems before trouble or failure occurs.

Doing so usually requires highly experienced professional help, at least to review plans and comment on potential gaps in appropriate safeguards.

Employing senior specialist consultants in this role allows leverage of a technique known as “pattern matching”. This technique requires professionals who have seen troubled and failed implementations, and who know what worked in a re-staging and what did not. Your problems fit a pattern, whose alternative actions and outcomes can be extrapolated from experience.

Actual re-staging of a troubled or failed ERP implementation absolutely requires the deft hand of a highly experienced professional. Regardless of whom you choose.

Share Button