We regularly hear of failed or unsuccessful ERP implementations. And while there are many factors contributing to a good or bad outcome in such complex projects, there are parameters and precautions that will help you walk on the safe side and achieve the results you set out to get.
A good contract ensures that there are no surprises during the project. It states clearly all tasks, responsibilities, deadlines, and the impact of potential changes. But such contracts are almost always drawn up by the supplier, not the customer – a clear power imbalance. To ensure that a project goes in a mutually beneficial way, pay attention to these factors:
Be Specific
For the protection of both customer and supplier, a contract should state very clearly what is to be provided. Phrases such as “Supply and implementation of the ERP system” are far too imprecise. What does 'implementation' mean – that the system has to work? Agreed functionality, acceptance tests? Sit together with your team and write down exactly what you expect from your new ERP and then talk to your implementation partner. If they’re good, they will listen carefully and tell you truthfully what is possible and what not.
Pro tip: pay close attention to verbal agreements during the presale phase and get them in writing as well.
Look for Measurable Results
Closely linked to the previous section, this problem is most easily identified in a contract by the word 'improve'. It’s a relative and vague term in the best of cases. In a worst case scenario – if a company is dissatisfied with the delivered system and the dispute goes to arbitration or to court, how easy would it be to prove, or disprove, that something had not been 'improved'? The best solution: be specific and set measurable results for your project’s goals.
Set Achievable Project Goals
Recognizing some of the above problems, some companies try to get around problems by writing their own contracts or at least having clauses that they, or their attorneys, have written inserted into the supplier's contract.
The problem is that no sensible system provider is going to sign a contract that sets unreasonable (i.e. vague) goals tied to post-implementation performance because not even the best system can guarantee that. Rather set out for an achievable goal from the beginning: your trusted implementation provider will help you find a framework that works for both sides!
Stay Realistic
This one, too, is closely related to the previous section: unprofessional sales people can be tempted to promise (although not usually in writing) benefits that, in real life, won’t be achievable.
Such too-good-to-be-true stories often come with caveats: “Many customers have achieved.....”, or, “Used properly, the system can ….”. These statements may sound impressive but if things go sour, they are next to meaningless. If it sounds too good, it probably is!
Pro tip: Check out reviews of former clients – most companies have whitepapers, case studies, or testimonials on their website.
Timely Execution
When companies launch an ERP project, they will have a target launch date in mind. This date can be just a nominal date to focus attention, but it can also represent a critical deadline – for example, if support for their legacy system is being discontinued or if planned business developments mean that a new functionality is essential. When the go-live date is important, it must be written into the contract, but doing so effectively is not always easy. The problem is that the supplier can only commit to completing the work that is specified in the contract, and it is not unusual for new tasks or requirements to be identified for a successful conclusion after the contract is signed. If the scope of work changes, it might be unrealistic to hold the supplier to the original promise.
Project Change Management
It’s happened: the project needs a formal change control procedure, and the details and how this step impacts delivery promises needs to be explicitly stated: time-line, slippage, changes in resource requirements, costs, and potentially new stakeholders need to be discussed. It can even happen that a supplier has to pull the original team members out of a project because they’re needed elsewhere, so you might have to take several steps back and that takes time.
Long-term Maintenance Considerations
Within the lifetime of an ERP system, the company running it will probably change. It may get bigger and it may get smaller, and that will mean a changing number of users on the system. If you’re relying on a cloud-based system, the amount of storage required as files get bigger and bigger will also increase.
The initial contract must spell out in clear terms how these changes will be reflected in monthly and yearly charges. Given that the system is likely to be in use for at least ten years, the contract must also specify what increases in charges over that time would be considered reasonable and how they will be calculated. Some Tier 1 customers have recently had massive shocks when their supplier changed from charges based on the number of users to transaction-based charging.
Companies also need to be aware that, for a number of reasons, some ERP implementations disappoint or even fail entirely. If that were to happen, they need to know how they can (or rather if they can) extract themselves from the contract so that they are not left with fees and charges long after a system has been abandoned.
One final remark: there is a lot of good advice out there on ensuring that projects go well. In taking advantage of that information, companies should always remember that, until they sign a contract, they are the ones with the power advantage. Never sign a bad contract, even if that means spending a fraction of the total project budget on good, independent advice.