Have you ever been through an SAP or Oracle implementation?
How long did the supplier say it would take? Usually around 12 to 14 months.
How long did it actually take? Maybe 24 months? Or is it still going on with no end in sight?
Now here's the more painful question.
Has an ERP implementation ever gone over budget?
My guess is every single time.
There are many possible reasons for that. But in our experience, most of the time it's because the client didn't agree on clear acceptance criteria with the software vendor.
Need help with a software negotiation?
We've gone to battle with all the big software vendors and saved millions for our clients. To find out how we can help you, click here to request a phone call.
Welcome back to the five essential rules of software negotiations. Today we're going to talk about one of the most commonly overlooked or omitted terms in software contracts, especially ones that have a services component for development or testing. That's acceptance criteria.
Have you ever been through an SAP or Oracle implementation? How long did the supplier say it would take? 12 to 14 months. How long did it actually take? 24 months, or is it still going on with no end in sight?
Now the more painful question, has an ERP implementation ever gone over budget? The correct answer there would be, every single time. But it's not just ERP systems. Most software implementations suffer from scope creep and they go over budget.
Sometimes it's because the customer wasn't clear on their requirements, or they changed them mid-stream. I totally get that.
But most of the time, when we're called in to do a root cause analysis on these bloated software projects, what we find is that a good acceptance process would have helped to prevent many of the cost overruns.
Let's begin by understanding what an acceptance process is within the context of software negotiations. When you buy enterprise level software, it will require some level of development, configuration, and testing before it goes live.
When a supplier is pitching you their solution, they'll dazzle you with fancy PowerPoint slides, and graphs, and charts, but they'll never actually produce a project plan with real timelines and milestones.
When you ask them for that, they'll usually say something like, "Well, we'll work with you to put a project plan in place once the contract has been signed, and we've assigned people to the project." That's a huge red flag.
Our contract management tool, OneView, is enterprise level software that we sell to corporate clients. So I know exactly what steps I need to take and how long it's going to take us to get a client up and running on our software.
I need to know that because that's how I can figure out what to charge the client. Every other software vendor out there knows that as well. So don't take that as an answer, force them to give you a project plan with real timelines and milestones and make it part of the contract. That's the first hurdle.
The next challenge is getting the suppliers to actually adhere to those timelines. This is where the acceptance process comes in. Every milestone in a project plan should have a deliverable, a piece of code, a test report, a status update.
Your acceptance criteria should establish the parameters for you to receive those deliverables, a period of time for you to actually review the deliverables, and an option to accept or reject the deliverables.
This is the most important part. Every milestone payment should be tied to the acceptance of a deliverable. This puts skin in the game for the suppliers and forces them to adhere to those timelines that they'd signed up for in the beginning.
Crafting good acceptance processes and getting software companies to agree to them is one of the more challenging aspects of software negotiations, especially with the bigger software companies that just expect their clients to roll over and pay millions of dollars above what they'd budgeted for.
It's difficult, but it's not impossible. If you're in the middle of one of these negotiations right now and you'd like to bounce some ideas off of us, please feel free to reach out to us. We'd love to offer our thoughts on this topic. We'll see you next time when we talk about mainframe ISPs.