ERP and bespoke software projects: what the contract must say so you can claim if things go wrong
Expert reports on failed ERP, CRM or mobile app implementations show the same pattern again and again: the technical problem is real, but the contract cannot prove what was supposed to be delivered, or when.
What contracts usually lack
- A defined scope (Statement of Work): which modules, features and processes the system must cover.
- Verifiable milestones and deliverables per phase, tied to payments.
- Acceptance criteria: how to check that a feature is finished.
- A signed acceptance and go-live record.
- Change management, risks and each party's responsibilities.
What to document during the project
- Every issue, in writing and dated.
- The versions delivered and the tests you run on them.
- The hours your own staff spend on it: they are quantifiable damage if the project fails.
- Any invoice for items you did not order.
If the project has already failed
- Do not shut down the environments or delete data: direct inspection of the systems is the strongest evidence.
- Gather the contract, quotes, invoices and emails.
- An expert can compare what was contracted with what was delivered, feature by feature, and quantify the loss.