Podcast: What Would Your Failed Enterprise Software Implementation Say if it Could Talk?

In this podcast, we speak with Bill Baumann, Director of Software Expert Witness at Panorama. He shares lessons learned from Panorama’s ERP Expert Witness engagements.

Podcast Summary

1. Why does someone retain an ERP expert witness and what value do they bring to the litigation process?

2. What are the most common issues you see in failed implementations?

3. Are all software contracts, MSA’s, SOW’s relatively the same in terms of content or do they differ by developer?

4. Can you explain the difference between fixed cost, not-to-exceed and time-and-materials billing for implementation services?

5. Are contracts for SaaS, hosted and on-premise solutions very different?

6. What if I’ve tried to work out cost overrun problems with my systems integrator, but they have threatened to abandon my project unless they receive more unplanned money?

7. In my system demo I was shown a lot of functionality that is not present in the version of the system that was implemented. Is this fraud?

8. Can you expect any out-of-the-box system to meet 100% of the functionality required?

9. How can I protect myself from excessive charges for things like modifications and integrations?

10. How tolerant of overruns in time and cost should I be?

11. Is a roles and responsibilities section something the systems integrator should have included?

12. Should I sign off on the go-live decision if the systems integrator says they will correct the bugs after go-live?

13. Do I have any recourse if I’m being forced to migrate because my system is being sunset?

14. What’s the average cost of an expert witness?

1. Why does someone retain an ERP expert witness and what value do they bring to the litigation process?

When a failed enterprise software implementation leads to an ERP lawsuit, an ERP expert witness may be brought in by the attorney – either for the plaintiff or defendant – to provide an expert opinion as to what they believe were the causes of failure.

We’ve been providing expert witness testimony for over 15 years. About 60% of the time we’ve represented the developer, and the other 40% of the time, we’ve represented the client.

Typically, when there’s a suit, depending upon who’s not getting paid or who feels that their enterprise software implementation is bad, they’re going to sue the developer of the systems integrator or in the other case, the developer systems integrator will sue the client.

In some of the larger cases we have, there are people within the client organization that have a fairly decent ERP background, understand what business process management is, etc. The problem is that they don’t have the level of experience we have, so they bring us in to opine on particular areas.

We go back forensically through the project documents and build a story or a kind of a timeline in terms of what happened. What went wrong? What went right and where did the ultimate causes lie? That’s our main methodology in terms of how we create what’s ultimately going to be a report.

Sometimes, we are deposed as well. In a lot of cases, the judge does not have the technical capabilities to be able to look at these discovery documents and say, “Oh, I see exactly what the issues are.” The attorneys are better equipped for this, but they still need someone like us to help put these documents into terms that either the judge or the jury can make sense of.

Essentially, we provide an opinion – not a legal opinion but a technical opinion on what actually occurred and why the implementation failed.

2. What are the most common issues you see in failed implementations?

About 80 to 90% of the implementation failures we see have one common element: a lack of or insufficient organizational change management.

Typically, if the software has been correctly selected, the software is going to work. That comes down to making sure you did proper requirements gathering. This is sometimes an issue but not often.

We also sometimes see issues with the processes that support the software. Did the client focus on business process management? Where did the client try to modify the software so it did things the way they do things? Again, this is not as common of an issue as organizational change management.

Within the statement of work that you receive from your systems integrator or developer, change management is almost always addressed. It’s a question of what detail there is.

The most reoccurring issue we see is a lack of communication with employees. While the organization might have done employee training, they didn’t deal with change resistance. Many people are resistant to change, especially if they’re seeing a system come in that’s going to change the job they have.

One of the biggest things you can do to protect yourself from a failed implementation is to ensure you don’t have an ambiguous statement of work (SOW). You need something that very clearly defines the deliverables. When are they going out? Who’s responsible? Leave no room for guesswork in terms of who’s doing what.

Another common issue is a lack of commitment from senior management. They’re behind the project and they’re funding it, but they’re not out there being cheerleaders for it.

In addition to executive buy-in, you need the right resources assigned to the project. You need your A-team, the folks that know the business the best. Sometimes, you don’t see that happen.

Last but not least, we see ERP project management issues in the planning of the project. If you don’t plan well and you don’t execute to a plan, the project will come off the rails at some point.

3. Are all software contracts, MSA’s, SOW’s relatively the same in terms of content or do they differ by developer?

When it comes to SOWs and MSA, you’d be surprised at the variation in level of detail and professionalism. As you might suspect, the Tier 1 vendors set clear expectations, but as you move down into the Tier 2 and 3 vendors, you might only get a one-page document.

It’s incumbent upon the client to ask the systems integrator or vendor for further clarification. For example, if change management is missing, ask them how you should deal with that. If they’re expecting you to hire a third party, it’s important to ensure collaboration between the three organizations.

4. Can you explain the difference between fixed cost, not-to-exceed and time-and-materials billing for implementation services? What kind of implications do they have for my organization?

The problem with fixed cost is it incentivizes the provider to potentially cut corners. Not all of them do that, but because it’s fixed cost, they’re going to make more money if they can deliver using fewer hours than they estimated.

Some companies ask for a not-to-exceed agreement. Let’s say the contract is for $100,000. If they only use $70,000 worth of time, they can only bill for $70,000. They don’t get that $30,000 difference like they would in a fixed-cost contract. Typically, if somebody asks for a not-to-exceed contract, there’ll be a premium attached to make up for the fact that they don’t have any potential additional profit.

Most companies we work with work on a time-and-material basis. If the systems integrator provided you with an estimate and they’ve been very specific in their statement of work of what hours are assigned to what deliverables, you can hold them accountable. Do these look like reasonable amounts of hours being assigned for particular deliverables?

Not every job uses every single hour assigned to every single deliverable task, but as a general rule, look for somewhere between 10% over to 10% under on a time-and-material contract. That’s an acceptable amount of variance.

If they start getting over 20%, they should be issuing change orders because something’s happened. Either they didn’t do a good job in terms of collecting requirements or the client has changed things or hasn’t participated well.

5. Are contracts for SaaS, hosted and on-premise solutions very different?

SaaS is a subscription model where you’re billed monthly. There’s a term on the contract, and typically you’re paying X number of dollars per user each month. You don’t own the software, and upgrades are done as often as twice a year.

When the upgrade is coming, you’re given an advance notice that within six months, or whatever timeframe is in your contract, you’re going to be moving to the new version regardless of whether you want to or not. If you don’t want to, you risk falling out of support.

With a hosted model, on the other hand, you own the software and you’re on someone else’s hardware. This is ideal for smaller organizations that want to save money. Another benefit of the hosted model is you’re not forced to do upgrades.

A hosted contract looks a lot different than a SaaS contract because you have a large expenditure. Typically, it’s a capital expenditure.

Then, there’s the traditional model we’re all familiar with, the on-premise model. You have your own hardware, servers and firewall. You are responsible for maintenance, so if there’s going to be an upgrade, you decide when that happens.

You can imagine owning an asset versus more or less renting an asset is a much different looking contract. Sometimes, it’s very difficult to compare these two types of contracts.

6. What should I do if I have tried to work out cost overrun problems with my systems integrator, but they have threatened to abandon my project unless they receive more unplanned money?

It’s important to ensure there’s a good escalation clause procedure in terms of what’s going to happen when you have a problem. How do we do our escalation? Where does it go? What happens if we’re not able to resolve it? Do we end up in mediation?

If the systems integrator has followed all the deliverables and your organization has followed the roles and responsibilities, but the systems integrator says they’re walking out on your project, there’s going to be some type of litigation.

If you’re in this situation, you may want to hire an ERP consultant that deals with SOWs on a regular basis to look for escalation clauses in the maintenance agreements and other details that someone who deals with these contracts on a regular basis is going to see that you may not see.

7. In my system demo I was shown a lot of functionality that is not present in the version of the system that was implemented. Is this fraud or just a common practice?

I’d like to say it’s a lot more uncommon than it is, but demos often show the latest and greatest, which means they may show beta versions. The next thing you know they’ve implemented a version back.

It all depends on how the licensing agreement reads. It may very well say that you are going to get version 8 even though you saw version 10 in the demo. Is that fraud? Is that misrepresentation? That’s up to your attorney.

To prevent this issue, you should ensure you have demonstration scripts so that all the vendors show you the same type of software and you can make sure that they are being consistent.

8. Can you expect any out-of-the-box system to meet 100% of the functionality required in even a simple implementation?

As soon as you start talking about the production floor, scheduling, work orders, etc., that’s typically when you’re starting to see modifications.

If you’re somewhere between 10% and 12%, that’s an acceptable level of modification of the software. However, if you’re modifying over 50% of the code in your software, this is a result of one of two things: One is you picked the wrong software because your requirements were done incorrectly, or two is you have such a unique company that the only way you could meet your business needs is through a best-of-breed strategy.

A best-of-breed strategy means you select the best piece of software for different functional areas. While this may be cheaper than buying a full ERP system in terms of licensing, the problem becomes the integration.

It’s important to try to consolidate things. Otherwise, if you want a financial report, you must export data from all these different data sources.

Integration usually doesn’t have to be custom written, but if it is, that pricing can well exceed the cost of implementing the software.

That’s one of the “gotchas” that we look for in SOWs – how many integrations are there? You basically want to look at a software map of the different pieces of software. What has to be integrated? What’s the effort to be integrated? How long will it take?

Extensive integration can cause many problems during the implementation process.

9. How can I protect myself from excessive charges for things like modifications and integrations?

This needs to be laid out inside of your SOW. Most systems integrators giving estimates are not going to give you the high end, just the low end. However, some will give you a range.

While systems integrators can give an estimate based on requirements, it’s difficult to give an exact number, especially when it comes to integrations.

10. How tolerant of overruns in time and cost should I be, and what can I do if they are above that percentage?

If you go to litigation or mediation, you’re going to have to retain an attorney that is familiar with this type of work. They’re expensive, so you have to make a determination of whether it’s worth it.

Somewhere in your total cost of ownership you need to build on a contingency. We recommend 20% as a contingency factor for things like overlooking something during requirements gathering, buying another company or anything that can influence the scope of the implementation.

If the overrun is less than 20% and you built that contingency in, you already have the budget for it. However, if you start seeing anything over that, then you might want to bring someone in to determine if the overrun is reasonable based on the level of modification or if the systems integrator is trying to make up for the fact that they underbid the project to begin with.

11. My systems integrator says they are unable to complete my project on time due to lack of capacity/capability of my core team. They keep referring to the roles and responsibilities section of my SOW, but it doesn’t dictate how much time each role will need to commit. Is this a detail they should have included and if so, what can I do about it?

Unfortunately, not every SOW we’ve seen has roles and responsibilities dictated.

Setting expectations should be a collaborative process between the systems integrator and the client. You need at least some kind of projection for each of the people on the ERP project team. This is important because the core team is often comprised of the best people in your company, and their day-to-day responsibilities need to be covered when they are working the project. You want to either bring in somebody temporarily or you may want to hire somebody.

12. My systems integrator says that even though they haven’t resolved all the bugs in my system that I should sign off on the go-live decision document and they will correct them later after we are live. Is this normal?

Sometimes, systems integrators push for go-live even if there are bugs because they have fixed fees and they want to get out of the project as soon as possible.

When working on a case, we typically go through all the support tickets to find out what users are struggling with and categorize them. Some issues come down to how the configuration or modifications were done.

If your systems integrator is pushing for go-live, we don’t recommend singing off on anything if system issues are significantly impacting functionality to point where you can’t live with it. For example, if the issue is something that could potentially hold up orders, then don’t sign off on go-live.

There’s usually a lot of pressure coming down from senior level management. They’re spending a lot of money, and they’ve made a lot of promises. They may pressure project managers to vote for go-live even though it would be far better to incur the expense of three months of delay than experience a failed implementation (which might hurt the company’s reputation or put the company out of business).

We recommend at least three conference room pilots to test user acceptance and technical issues before signing off on go-live.

13. My software developer was just bought by a larger firm and they are going to sunset my system over the next two years. This means I have to migrate to their flagship system. Do I have any recourse?

This is an important issue to anticipate when you’re doing your selection. While you may find a solution that can meet your requirements, it’s essential to understand the product roadmap for that solution.

The ERP vendor may be planning to sunset your system, which means you’ll eventually be migrating over to their flagship product – or you’ll lose support. So, you don’t have much choice in the matter.

Guess who gets to pay for the migration? The vendor isn’t going to pay for you to get your data out of the old piece of software and into the new piece of software and make any configurations or modifications so it works in their platform.

14. What’s the average cost of an expert witness?

If have a large implementation, then getting legal representation from a firm that knows what they’re doing is going to be expensive.

Typically, an expert witness for a large case will run anywhere from $200 to $500, sometimes even more, per hour. This can be 10-15% of the total budget of the legal firm you hire.

You must determine if it’s worth it to spend this much money on litigation based on how strong your case is. However, you may need the help of an expert witness to determine the strength of your case. An expert witness can produce a feasibility document that outlines what things were done wrong that are so glaring that your chances of winning your case are pretty good.

You have an especially good chance of winning if there’s been fraud or misrepresentation in the sales process. If that’s the case, then it removes the cap on how much money you can recover. Normally, you can only sue based on what you paid the systems integrator.

In other cases, it may not worth the money to litigate. Sometimes, companies like ours are engaged for a project recovery before the client pursues litigation.

Be Aware of Red Flags

If you’re considering ERP litigation or are noticing red flags during ERP selection or implementation, you may benefit from our ERP Project Recovery services. Request a free consultation below to learn more.