ERP contradictions in 2014: Smaller projects, more delays

ERP contradictions in 2014: Smaller projects, more delays

Summary: New research concludes ERP budgets are shrinking but project length and delays have increased. Why the contradictory data?


For the last four years, Panorama Consulting Solutions has conducted an annual survey (registration required) of ERP buyers, to gauge project success and customer satisfaction among ERP buyers.

The 2014 results paint an interesting, and somewhat paradoxical, picture of ERP projects and buyer satisfaction. Although most projects run late and over-budget, with buyers reporting less benefit than in the past, most respondents consider their project successful.

Also read:

2013 ERP research: Compelling advice for the CFO

2011 ERP survey: New IT failure research and statistics

ERP implementation benchmark: Comparing SAP, Oracle, and Microsoft

ERP failure: New research and statistics

The following table shows a year-by-year summary comparison of core survey results from 2010 to the present:

Panorama ERP survey 2014 data summary by year

The summary reveals the following key points:

  • In 2013, projects significantly decreased in size, relative to past years, although implementation times are more or less unchanged
  • Cost overruns have remained relatively constant over the last few years
  • Duration overruns are increasing, which is interesting since overall project costs have declined
  • An increasing number of respondents report reduced level of benefit from their ERP system

Therefore, we see smaller projects, lasting longer, with increasing delays, and reduced benefit. How can we explain these apparently contradictory results?

The report states that "organizational issues" were the primary contributor to time overruns, with more than half of respondents spending between 0-25 percent of their budget on change management. While this explanation makes sense, it does not fully explain why less costly projects in 2013 took longer to run, and delivered lower benefit, than those in prior years.

The research attributes lower project budgets to smaller companies implementing ERP:

The main driver of smaller costs is that more small- to mid-size companies are implementing ERP software compared to years past, which is evident when you look at the cost as a percent of revenue numbers.

In fact, as shown in the following diagram, almost 70 percent of the respondents work for companies with under $300 million in revenue:

ERP research 2014, respondent size

To explain why smaller projects take longer, but deliver less benefit, we should consider two additional factors that are specific to smaller companies implementing ERP:

  1. Smaller organizations are generally less experienced with ERP, than larger ones, so their projects may take more time and be run less efficiently
  2. Smaller buyers may perhaps spread their implementation over a longer time horizon, to manage the rate at which the project consumes cash

The influence of cloud probably also helps explain what's going on. Although only 22-percent of respondents implemented cloud ERP, many (but not all) of those organizations did anticipate, or realize, cost savings:

cloud ERP cost savings

Aside from specific cost savings, relative to on-premise implementations, most companies tend to run cloud projects on a more iterative basis than on-premise efforts. These projects roll out features slowly over time, which could explain why smaller projects took longer than reported in the past.

The study also shows that 77 percent of respondents implemented ERP in two or more locations, although Panorama did not gather these numbers in previous years. With two-tier ERP, in which remote offices implement a cloud product to connect with the main system at headquarters, costs would remain relatively low while overall project durations (including both the main and remote locations) would likely increase.

Advice to the CIO and CFO

The research leads to three clear lessons for any company planning an ERP implementation:

1. Be realistic. ERP is complicated to implement, especially for smaller organizations without significant implementation experience. Regardless of what your system integrator may claim, the project will take longer, and be more expensive, than planned. That's actually okay, if your business case is clear and can withstand the reduced ROI associated with delays and possible unplanned increases in implementation cost.

2. ERP is a long-term investment. Be sure to distinguish between short-term implementation costs and longer-term expected benefit. The pain of implementation only matters in relation to the longer term benefit the company will receive. As with any investment, separate long- and short-term costs and expected results.

3. Don't underestimate change management. The real benefit of ERP often lies in process improvement rather than in new technology alone. For this reason, be aware that process change can create significant impediments during an ERP implementation. Plan for change and anticipate the likelihood of bumps along the way.

ERP is critically important to many organizations and the statistics should not scare off potential buyers. However, as with any technology, success depends on applying the right skills to the problem. Unless you implement ERP on a regular basis, which includes virtually no companies apart from the largest, then get qualified partners to assist. Hold their feet to the fire of meeting goals, but also listen to their advice.

Those are key points needed for a smooth implementation!

Topics: CXO, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • El-Cheapo Coders and "Project Managers"

    Far too many software development and business integration efforts rely on huge layers of bean counters (and associated crapware) in an attempt to get decent work out of low-skilled, communications-challenged, low-ball coders. The problem exists whether these "resources" are offshored or nearshored.

    Lots of attempts are out there (scrum, agile, buzzword du jour) to reconstruct software development environments with the high productivity and quality experienced prior to the 1990s. Hoever buying a book or hiring a talking head to spout these patent medicine methodologies doesn't solve the problem.

    The key is to cultivate quality software development teams over an interval of many years. Better compensation gets you better candidates and helps retain your experienced staff. Free sody-pop and snacks or ping-pong tables are not an answer to retention as much as stripping away levels of faux managers constantly wanting progress, bug fix, etc. metrics. Pay the folks as professionals and treat them as professionals.

    The alternative is a continuation of the steady decline of software development. Project overruns get worse and worse, budgets get blown worse and worse as body counts are raised assuming it is a matter of quantity rather than quality.
    • Depth of experience

      What I have noticed in other industries is a tendency to undervalue experience and wisdom in favor of hot-whatever-du-jour buzz. An experience person with wisdom would more likely recognize the problems sooner and be more proactive about fixing the problems.

      Also, outsource means the knowledge is not internal but is external.
  • Change is the hard part of ERP implementation

    After ocer two decades of ERP implementations, I wholeheartedly agree with these points.
    But business process change management is always the hardest and most fundamental hurdle to success.

    Process improvement needs involvement from all levels, and also requires support from the top levels to make the changes occur. Over time with good communication, wisdom, and diligence with this process improvement be realized.
  • Using Cost Savings as the Metric of Value is a Root Problem

    The problem with companies assessing "benefit" or "value" of an enterprise system is that they limit the benefit assessment to cost savings rather than placing a value on achieving a business outcome.

    This goes to the heart of the rationale and motivation for implementing a new enterprise system of any flavor,-- roll your own, off-the-shelf / package software, on-premise, or Cloud / SaaS.

    If a company is not thinking about achieving business outcomes and how technology can help, then technology implementations can only miss the mark in terms of value because their metric for success is "saving on cost". So there is no or little tolerance to make adjustments that deal with reality (technology in real live use).

    For example, what is the impact on the company of chronically loosing 10% of inventory to loss or theft? What is the worth of fixing the problem? How could technology help lower the loss / theft rate say to 5% or 2%? What is the cost (order of magnitude) of putting such as system in place (for example, RFID, sensors, infrastructure, software, integration with ERP)? The value is if the cost of the remedy versus the impact of the problem over some period of time.
  • Smaller Projects Taking Longer

    "Smaller buyers may perhaps spread their implementation over a longer time horizon, to manage the rate at which the project consumes cash."

    This is the most common reason I see smaller implementations taking longer and longer. Also, sometimes it's hard for managers and other decision makers to bite the bullet in restricted business environments. When I'm working with smaller organizations it becomes apparent that even though implementing the plan faster will equal long-term savings, being beholden to short-term targets has made many decision makers skittish. Larger companies can tend to be less emotional and more rational when it comes to capital investments for the future.

    Brian TMC