What causes ERP projects to fail?

Introduction

IT projects can be divided into two key types:

• those initiated by the technology provider (a presentation was given, and it was well received)
• those initiated by the client (we have a problem)

IT projects initiated by the client are business-driven (the problem is real and has been identified); they are far more likely to succeed than those initiated directly by system suppliers (the problem has not been identified; the supplier entices the client with benefits during the presentation).

The main reasons for this difference

Projects initiated by the client:

• High level of adoption: The client has a specific need (e.g. to automate a repetitive task or solve a particular problem), which makes their staff more willing to use the new tool.
• Clear business objective: The project is set up to solve a real operational problem or increase efficiency, rather than to ‘implement technology’.
• Better alignment with processes: The client understands their specific context and its unique challenges.
• Greater commitment: The client feels responsible for the project’s success, as they were the one who conceived it.

Projects initiated by system suppliers:

• Low adoption rate (resistance to change): Systems proposed by external suppliers are often perceived as being imposed from above. Staff do not understand why they should change their existing habits.
• Forced creation of needs: Suppliers propose solutions tailored to their own (off-the-shelf) products, rather than necessarily to the company’s needs.
• Risk of mismatch: Off-the-shelf modules or advanced functionalities offered by the vendor often prove to be unnecessary or too complex for employees’ day-to-day tasks.
• Focus on technology: The vendor concentrates on delivering the software as per the contract, rather than on bringing about real organisational change within the company.

Key success factor

In the IT industry, it is commonly said that technology is merely a tool; yet, at the same time, companies ‘force’ their proposals onto clients. The highest success rates are achieved by change-oriented projects initiated by company boards, because the aim is to solve real problems, and these almost always originate from within the organisation.

But there’s a catch

Projects that have a genuine business objective but begin by selecting a technology provider end up just like those initiated by suppliers, and for the same reason: the focus is on the technology being offered, rather than the client’s problem.

A second point: the focus should be on the company’s business objectives, not on local problems or the status quo of employees, as this merely treats the symptoms rather than addressing the root causes. That is why interviews with employees are not about gathering requirements for software, but about identifying problems to be solved by the business analyst and designer.

That is why we must first analyse and test the idea against the business model, and only bring in the solution provider at the very end, once we ‘know what we want’ – that is, once we know the solution and simply need to select its supplier or contractor.

Am I writing about myself here? Yes (but not only). Is this an advertisement? No. It is simply my experience, corroborated by many other authors. Like many others in my line of work, I am engaged by experienced company boards (project sponsors) to ensure that the technology provider is brought in as late as possible and works under the supervision of the client.