3 Reasons Why ERP Projects Experience Budget Overruns

To utilize a somewhat militarist perspective to illustrate a commercial technology point; business is like war, someone wins, someone loses, but everyone is impacted by the experience. I came to this conclusion years ago, the very first time I came face-to-face with the responsibility for a large-scale technology project that appeared to be straightforward, but in the end wasn’t; leading to much scurrying about and hair-pulling to get the project done somewhere close to being on-time, and at least within shouting distance from its original budget cap.

Consequently, I have decided to take a look at ‘why’ ERP budgets lose cohesion and fall off the road. In looking at the myriad ways that can things can go wrong, I came up with three central areas of discussion that are universal while in the end offering significant ‘gotchas’ that typically plague ERP project management.

1. Not ‘Knowing’ What You Don’t ‘Know’; Before You ‘Know’ It:

Executing a major ERP project is not for the faint-of-heart. Simply accepting the central character of an ERP project alone is not enough, and should cause pause during any planning evolution.

Given today’s independent modules requiring active interaction in order to create series’ of legitimate reports, these elements offer all kinds of ways to drive a projected budget through a cost ceiling. That said, however, there’s something even worse, and that is missing something during the ERP planning phase well ahead of pulling the trigger, also known as the “oops” quotient.

In this case, it’s not good enough to project a paper plan once, twice or even three times based on ‘good’ requirements established on earnest deliberation, and work with senior, line, employee or customer interactions, but instead project ahead of the cost curve by expecting the unexpected because, to be blunt, that’s just the way it is, and everything always costs more than you think it will.

For what its worth, my budget-plus rule is usually 30%, and was derived from my first busted budget. Since that experience, I never busted another, and figure it this way, if you’re under the extended ERP budget total you’ll be a hero, or if you hit your target you’ll be accurate. Either way, though, you’ll be safe enough to fight another day.

2. The Wages Of ‘Soft Costs’:

This failure is as typical as it is pervasive but always damaging to a project budget. You have done all the hard work to develop a set of systems requirements that make sense, and you’ve canvassed your enterprise’s workforce from top to bottom; so what’s left when doing a final budget?

Well, how about calculating the cost of training time, also known as non-productive hours, potential operational downtime, or external contract cost like buying a support program to cover your shiny new cloud-based system? Or, how about additional in-direct costs associated with extended telecommunications bandwidth and hard infrastructure in the case of a private network, or additional overall extended enterprise costs associated with the operation of virtual off-site smart device connectivity?

All of these costs are typically unidentified with the more obvious direct costs of mounting, or upgrading an ERP system. So beware, because these ‘soft’ bites hurt just as much as ‘hard’ costs do when an audit partner or CFO comes around to call.

3. When The Tail Wags The Dog:

This failure is sometimes referred to as ‘horizontal scoping’, or when practical constraints begin to alter the process capabilities of an ERP system. This is particularly irritating since the evolution is like pulling a thread from linen; once a failure starts its usually painful and costly to correct if at all.

In this case, modern ERP systems offer a host of positive values to an enterprise; however, each system harbors its own operating characteristics. However, if a manager has done a poor job understanding and validating how the enterprise works at a daily basis, there is a good chance the manager may run the chance of buying the wrong ERP system for the wrong company.

This error typically leads to multiple attempts to tailor an ERP system that offers one kind of value, when another would have a better job in the first place. So, from the outset of an ERP requirement run, understand thyself first. Only then, will the manager be able to insure that the potential of this kind of screw up is nothing more than a bad dream.