ERP Implementations: The Problems with “Best Laid Plans”

When it comes to preparing for an ERP implementation, one question that always comes up is the appropriate (I hesitate to use the term “right”) amount of contingency to build into the budget.  In other words, if the project is being quoted at $10M, should you budget $11M, $15M, or something in between?  Furthermore, if you are engaging your Systems Integrator (SI) in a fixed-price contract, does that mean you don’t need additional contingency?

There are a number of factors to consider, and naturally, there is always going to be pressure to minimize this amount.  Nevertheless, when companies succumb to internal politics rather than approach this risk contingency decision strategically and objectively, they always end up regretting it.

To estimate how much contingency is appropriate for your project, you need to consider the three primary sources of overspend in ERP implementations:

Scope Adjustments

Scope creep is the perennial bane of project managers, which is one reason why companies adopt “out of the box” or “fit to standard” philosophies early on.  The reality, though, is that scope almost always increases over the life of an ERP project, because slogans quickly crumble once process owners and end users realize that “standard solutions” aren’t going to get the job done.  And typically, this realization happens in a big way at two points in the project: first, during the discovery phase, and again during integration testing.

It’s not uncommon to see a change order of 10% or more from the SI at the conclusion of the discovery phase, hence 10-15% is the range you should be thinking about when it comes to scope contingency.

Execution Contingency

Mike Tyson once remarked that, “Everybody has a plan ’til they get punched in the mouth,” and if there’s one thing you can be certain of on an ERP project, it’s taking a few punches along the way.   These are just a few that I’ve seen:

• Data quality is worse than expected?  That’s going to require another mock data load.
• Customizations and extensions are more complicated than expected?  Or what about those reports that were supposed to come directly out of the system but now have to be developed?  That’s going to require some additional development.
• Integration testing has revealed some critical defects and exposed gaps in the process design?   That’s going to require an extra cycle of testing.

Any number of things can happen along your ERP implementation journey that will necessitate changes to your project plan, some of which won’t impact your project schedule (like adding some developer capacity), while others may require replanning in order to ensure a smooth cutover (like additional test cycles/mock loads).

Either way, none of them are free and you need to be prepared to pay the bill from your SI.  So how much is enough?  Simple math tells you that a delay of 1 to 2 months on a 12- to 15-month project is an increase of roughly 10-15%, which makes it a pretty good range to use for estimation purposes.

It is worth noting that SIs build this premium into their estimates on fixed-price engagements, since they are assuming the risk of unforeseen complexities rather than billing you for each hour of additional capacity in a “pay-as-you-go” model.  And while this can seem like a good tradeoff to make when considering which contract structure to use, there are a few things you need to keep in mind:

• This premium only covers unforeseen complexities related to the initial, agreed-upon scope…not changes to scope.  In short, you still need to plan for 10-15% scope contingency independent of execution risk.
• This premium will not protect you from a change order if your SI’s initial assumptions were based upon faulty or incomplete information provided to them during the contracting phase.
• This premium will also not protect you from a change order if you fail to meet your contractual obligations, which in turn impede your SI’s ability to meet their own.  This caveat is particularly important when it comes to managing third-party providers on your project.  Unless those third-parties are sub-contracted through your lead SI, their failures to deliver according to plan effectively become yours.

“Rainy Day”/Client Contingency

Just as changes to staffing and schedule aren’t free for your SIs, neither are they free to you.  The same complexities that drive the need for additional resources from your SI will affect your internal team, so you need to be prepared to accommodate needs for extra resources as well as extended or unplanned commitments for project resources.

These unforeseen demands translate not only to unplanned internal project costs but could also require backfilling or even outsourcing to free them up quickly.  As such, the same math used for SI contingency provides a good rule-of-thumb, amounting to another 10-15%.

When you add it all up, that hypothetical $10M project can easily balloon to a $13-15M endeavor.  And while most company executives are going to balk at this bump in price, studies have shown that even at the low end of this range, finishing your ERP project around 30% over the initial estimate is still pretty optimistic.

Furthermore, even though you might be able to get by with a lower amount, it’s better to have the money available and not need it, than to need the extra money and not have it.  If nothing else, history has shown us that in spite of good intentions and the best laid plans, risk happens.

Follow me on Twitter @sstamp_ue.  Find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn. Learn more about Project Execution Advisory Support.