Achieving ERP Success – Critical Factors Causing Failure – Mythology

> Blog > Achieving ERP Success – Critical Factors Causing Failure – Mythology
Critical Factors Causing ERP Failure – Mythology

Succeed by engineering against failure
In the process I have been through with regard to troubleshooting and turning around dozens of
failed and sub-optimal ERP projects I have identified seven “Critical factors causing ERP project
failure” and seven “Critical factors for ERP investment success”.  These are not what most people
would think.

In considering this discussion it is important to define what is meant by “success” – in my experience
this is a system implementation which results in the organisation being more competitive, more
profitable, more efficient — success at a tangible level that is evident to the shareholders in a cash
return on investment. Failure is, per definition, anything that does not achieve these objectives and
is best determined via a private, off the record interview with the Chief Executive – most C suite
executives are very reluctant to admit failure in public and on-the-record.
Mythology, hype and tradition – 30%
The first factor causing failure is “mythology, hype and tradition”, this is a huge subject. The
business systems industry is rich in mythology, hype and tradition and light on delivery. Perhaps the
biggest myth is a seemingly deep conviction that the current ways of doing things, that have such a
poor track record, will, one day, if executed really well, turn around and produce different results.
What I term “process obsession” is perhaps the single biggest myth around.

In understanding this point, consider the statistics reported above – the ERP failure rater, per
Gartner, exceeds 75% — yet, as a whole the industry persists in endeavouring to get better in the
very processes and methods that are delivering the high failure rate.

Let me give an example:
Large vehicle leasing client.
Two year project with one of the top four global consultancies and one of the top global ERP’s – no
expense spared. No indication that they were close to going live – deadlines repeatedly missed.
Dedicated in-house team that were increasingly concerned they were no longer relevant to the
Dedicated implementer team.
I was brought in to investigate. In three days, having interviewed all key client personnel, all key
implementer personnel and having a detailed walkthrough of the configuration I established that:

  1. A critical strategic requirement had been completely overlooked – this was the defining
    requirement for the project in the first place. It required a piece of clever bespoke software

which, if correctly designed and implemented, would potentially have voided the requirement
for the big brand ERP. Most of what had been done was irrelevant!

  1. The configuration in the development system was what I call “scrappy”, the master data and
    validation data lacked structure and did not model the realities of the business in the data.
  2. The team had produced thick files of process documentation, flow charts, workflows, swim
    lanes, etcetera, all the classic process orientated textbook stuff.
  3. They were nowhere close to running live and no one had any idea how or when they would run
    live. They were just doing what they knew to do which was not geared to a successful outcome.
    Immediate drastic action was called for.
    The above is what I call “process obsession” the obsession with workflow / process at the expense of
    accurately modelling the strategic essence of the business in the configuration data and master data.
    I will touch on these elements more in subsequent articles and, in particular, share how the methods
    that I advocate and have applied successfully over many years avoid this type of situation.
    Next week I plan to discuss Executive Custody – the first factor for success.
    From consideration of the above it will be apparent that the real issue is not the ERP product, all the
    mainstream products are capable of delivering a quality outcome, it is the quality of the
    implementation and therefore the capabilities of the implementer that are critical.