Recently I’ve read two disturbing articles about ERP implementation projects.
- Kanaracus, Chris. "ERP Software Project Failure on the Rise Says Report." Computerworld UK. Computer World (UK), 21 Feb. 2013. Web. 22 Feb. 2013.
- Arellano, Nestor E. "ERP Cost Overruns Still Plague Enterprise: Report." IT World Canada. IT World (Canada), 21 Feb. 2013. Web. 22 Feb. 2013.
The articles focus on just ERP implementations, but my suspicion is that the symptoms presented in the report are far more widespread.
Implementation Project Cost Overruns
This, of course, is old news. Cost overruns for IT projects are, unfortunately, no longer “surprises.” They haven’t been for the better part of two decades—probably, even, since the inception of “information technology” as a new foray in business.
I guess we can console ourselves by noting that cost overruns are declining slightly: from 74 percent of projects in 2010 to 56 percent in 2012 and, finally, down to 53 percent in 2012.
Of course, what we don’t know is the cause of this decline. Are cost overruns being reduced because VARs, vendors and systems integrators are getting better at estimating (or, perhaps, more honest), or is the implementation process simply getting more honed and efficient? Then, again, it may be that overruns are being reduced because the customers themselves have been through implementations more times, so they have learned how to cooperate more fully and effectively during the implementation.
What the reduction in cost overruns certainly does not tell us whether the cost of the project is actually any lower for the buyers of such implementations.
Implementation Project Schedule Overruns
While cost overruns are diminishing slightly—for whatever reason, schedule overruns are growing. Of the 172 implementations included in the report quoted in the articles, the average project duration was 17.8 months, with nearly two-thirds (61 percent) reporting that their implementation “would take longer than planned.” This compares to only 54 percent reporting the same in 2011.
Success and Satisfaction
As I said, overruns are “old news.” In fact, they are so commonplace as to be considered—sadly—the industry “norm.” But, let’s look at some more troubling information that surfaces in the report.
Fully three out of five (60 percent) survey respondents indicated that their firms’ received half or less of the business benefits they anticipated from their IT project.
Despite this dramatic failure, in my view, more than four out of five (86 percent) of decision-makers indicated that they were “satisfied” with the results of their project and most (60 percent) labeled the project “a success.”
It is, indeed, a vast understatement, then, when Eric Kimberling, managing partner of Panorama Consulting (which conducted the survey), states:
“[T]he delta between actual… implementation results and the self-reported satisfactory levels indicate that companies are setting expectations of the business benefits they should achieve from… [their] system far too low….”
Kimberling strikes the nail on the head, I believe, when he goes on to say:
When [project] durations stretch and scope increases…, it… becomes tempting to change the definition of success to just “getting the system up and running.”
Very low expectations, indeed
This is akin to deciding to buy a new car in order to take a family trip to Disney World and then settling for just being able to get the car started.
Of course, if the executives and managers in the enterprise view IT purely as an expense, they likely have not developed any effective means to estimate and measure POOGI (process of on-going improvement) project return on investment (ROI).
If not, please name any other corporate matter in which they would invest tens or hundreds of thousands of dollars without any expectation of real, measurable ROI? I don’t think there are many.
Estimating ROI for any POOGI project
We actually use a very simple formula for estimating POOGI project ROI. It is stated here:
TOC ROI
It reads: ROI is equal to (the change in Throughput less the change in Operating Expenses) divided by the change in Investment.
Of course, the figures used even in this formula will be estimates; but we use tools to help unlock “tribal knowledge” in a way that can aid you in getting to pretty solid numbers that will allow managers and executives to create metrics by which to actually measure post-project results against pre-project expectations.
We believe that this approach can rescue firms from the deadening effect of low expectations and money spent of IT (or other POOGI, such as supply chain) projects with little or no benefit being delivered in the end.
We would be delighted to hear your opinions on this important matter. Please leave your comments here, or contact us directly.
