Most software projects are now based on implementing existing application software, such as ERP, rather than bespoke development. This makes, or should make, the process cheaper and much less risky but there is still a steady flow of such projects that fail and ultimately end up in court.
The argument between client and supplier usually goes something like this;
You said this would be easy. You said most of our needs would be met Out of the Box and there’s only a little bit of customisation required. But you’re xx months late, the system is full of bugs and still doesn’t do what we want.
Client X
The requirements you gave us were vague, your business reps didn’t turn up to meetings/kept changing their minds and refused to accept the OOTB system. No wonder we’ve had to develop loads of extra software.
Supplier Z
The common thread in most of the ERP disputes I’ve worked on isn’t the ERP software itself (none of the big names is immune) it’s the gap between the software and the client’s requirements. This can result from any of the following;
- Lack of requirements analysis – there’s a high level set of requirements but there was no budget from either party to take them to the next level of detail, so the project is based on a poor understanding of the gap.
- The gap is understood, but it turns out the product isn’t as configurable as expected so more customisation is needed to fill the gap.
- Slick demos and a lack of hands on activity mean functionality that users thought would be OK isn’t, so they are refusing to accept OOTB.
The bottom line is that time spent working through business scenarios using the vanilla product, what’s often called a conference room pilot, will be worth the effort in the long run.