ERP Implementation

Why ERP Projects Are a Different Beast

Most companies underestimate ERP projects because they're comparing them to the wrong thing. Here's what actually sets them apart.


We've talked before in these articles that it is highly common for people to assume ERP projects are far quicker, simpler, and easier than they actually are. This is likely due to experience from other kinds of projects, whether configuring other types of packaged software or producing custom apps. The reality is that ERP projects are a completely different beast. Failing to understand this point is dangerous because if you do not appreciate the magnitude of implementing an ERP in terms of risk, staffing, and more, you expose yourself to a higher probability of failure.

So, what makes them different you ask? Below are some of the key areas that separate ERP projects from the rest of the technology project "herd."

Complexity and Regulations

What it takes to get it right

This is the point that drives all the others. The ERP is the financial backbone of the company. Not only does it need to be set up just right in order to perform properly and accurately, but just about every business event triggers some kind of financial transaction that needs to be tracked. Every single one of these workflows needs to be designed to work together. To make it harder, an ERP rarely operates alone. Usually, the business processes exist across multiple systems into or out of the ERP, adding complexity, and therefore, time and cost. Lastly, being a financial system, getting the solution right means ensuring the solution allows the business to adhere to accounting regulations, while at the same time, building business processes that support the business. Before you sign off on scope, make sure someone on your team has mapped which regulations and financial workflows the ERP actually touches. It's usually more than people expect.


Staffing and Internal Needs

The resource shock most companies don't plan for

A major shock many companies face is the amount of time required from their internal resources to successfully complete an ERP project. For certain resources, it is an amount of time that is disruptive, requiring a remediation plan, or even temporary backfill. These are things that must be planned for up front. Businesses will often try to negotiate this, and while it is completely fine to verify and confirm if your disruption is justified, drastically decreasing the time of involvement for your key resources will put your project at risk. These resources have knowledge of business process, as well as key perspectives that will help shape the solution. Taking this away will absolutely lead to a solution with holes, failing to meet core needs. Additionally, the less involved the business is in testing, the higher the risk as well. If a vendor tells you they can get by with a fraction of your key people's time, treat that as a red flag, not a relief.


Timelines and Cost

Longer than you think, and getting longer

There are very few technology projects that take as long as an ERP project. Projects can range from several months for small businesses, up to multiple years for enterprises. So, prepare for business disruption for some time as the project progresses. And with this increased timeline comes cost. ERP implementers have a high hourly rate. Multiply that across the number of months for the project and you're talking hundreds of thousands of dollars to even hundreds of millions for the larger enterprises.

A quick note on AI here, since it comes up constantly in vendor pitches: there are vendors claiming AI will bring these timelines down significantly. At this time, we are not seeing much real impact on that front. Treat any timeline built on that assumption with skepticism until you see it proven, not promised.


Cost of Failure

When it goes wrong, it can take the business down with it

The potential cost of failure for an ERP project is the last variable that truly sets these projects apart from others. Outside of some other key operational systems, which oftentimes are done as part of ERP projects, there are not many technology projects where failure can be catastrophic. If an ERP project is invested in and completed poorly, a company may not be able to conduct business at all. Orders may not be routed properly, money may not be able to be collected, and all kinds of other issues can surface. Simply go online to find examples of the most famous catastrophic failures. For example, Hershey's is probably the most well known. They compressed a timeline to hit a specific deadline right before their busiest season, Halloween. The resulting failure lost them more than $100 million in sales, with a 19% stock drop, and it took years for them to recover. If you find yourself doubting some of the estimates provided regarding time and staffing commitments on your side, spend some time reading failure stories like this one. Ask yourself if any of it sounds like a direction you are considering going. And keep in mind, implementation vendors usually underestimate how much time is required, meaning the timeline you may be looking at is likely shorter than it should be.


Simply knowing and understanding this will not be enough, though it is a critical step. This understanding must guide the decisions you make as you work with vendors to plan your project. Especially if you are a functional leader within the business, this is easier said than done, especially once the timeline and internal staffing needs are communicated. There is always room to negotiate, but understand that vendors are notorious under-estimators.

In an environment where price is often the largest deciding factor for a business seeking a vendor, and timeline is one of the core drivers of cost, paired with the high cost of change, a wildly common scenario plays out: a vendor wins the bid with an impressively short timeline (and therefore cost), and soon enough, the project is plagued by change orders.

That pattern alone should tell you something. The timeline, plan, and staffing estimates that you may be looking at right now are more likely an underestimate than an overestimate. So take serious consideration before pushing to decrease them further.


ERP Without the Chaos

Previous
Previous

Next
Next