What should I do to ensure that my IT implementation does not go off track? (part 1)
A software or ERP implementation should accelerate your business, but in practice it often ends in project stress and cost overruns. This is rarely due to one major mistake; more often than not, it is the result of unclear expectations at the outset. Unclear expectations are a common thread that we see running through the many cases we have handled for our clients over the years. Today, we are launching part one of a two-part series on concerns surrounding IT implementations.
Read part 2: My IT implementation is going off the rails, what can I do?
The core
A successful IT implementation does not start with the first workshop, but with the contract phase. Investing in advance in a clear scope, strict acceptance criteria, and a clear ‘exit’ prevents you from finding yourself with your back against the wall later on. Legal control at the outset is not mistrust, but the basis for a healthy collaboration.
Why it often goes wrong: expectation management
Clients and suppliers often start with different perspectives. The supplier relies on methodologies and standard contracts. As a client, you are looking for predictability: a fixed price and a working system. As long as everything goes well, there is no problem. But as soon as the first setback occurs, it often turns out that the basic agreements are too vague.
6 Concrete steps to prevent derailment
To stay in control, you need to nail down the following points during the quotation and contract phase:
1. Clear scope and change control
Specify exactly what will be delivered (modules, links, migration). But even more importantly, agree on how you will deal with changes. A strict change request procedure prevents ‘additional work’ from becoming a bottomless pit.
2. Measurable milestones and acceptance
When is a phase complete? “When it works” is too vague from a legal perspective. Define functional acceptance criteria, performance requirements, and security standards. Link recovery times to these.
3. Governance: who decides?
A steering group is not a tea party. Establish who has what mandate and how the escalation lines run. This prevents decisions from getting stuck.
4. Pay for results
Link payments to demonstrable delivery and acceptance. Do not blindly pay in advance for software licenses that do not yet work.
5. Consider the worst-case scenario (Exit)
It may sound unpleasant, but arrange the separation before you get married. Make agreements about data portability, transfer of documentation, and migration assistance in case you do have to part ways.
6. Liability and risk
Check whether the supplier’s liability limitations are proportionate to your business risk. Does the standard ‘cap’ match the impact that a failing system would have on your process?
Frequently asked questions
When should I engage an IT lawyer?
Ideally, in the preliminary phase (quotation, scope, contract). Do not wait until the first major escalation; by then, the rules of the game have already been determined.
Is it wise to include deadlines (such as go-live)?
Yes, but only if the consequences of exceeding them have also been agreed (such as suspension, a recovery plan, or a penalty). A date without consequences is just a wish.
What should the minimum acceptance criteria be?
What you test, how you test, when something is approved or rejected, and within what timeframes recovery and retesting take place.
Agile working: do I still need a ‘fixed’ contract?
Yes. With Agile, you do not specify the exact end solution, but you must have agreements on governance, prioritization, budget frameworks, and the ‘definition of done’. Otherwise, Agile becomes a license for non-commitment.
Advice
Do you have any questions about this article? Our ICT lawyers are ready to advise you! Contact one of us by email, phone, or fill in the contact form for a no-obligation initial consultation.
