top of page
John Talio

“The Real Reasons” ERP Project Fail!!! - Part 1


Note to reader: This is the first in a series of 4 blogs on this topic.


"The Real Reasons" ERP Projects Fail!!! - That sounds intense!


Let me explain – in ERP Project Success: The Roadmap to Prevent Failure I mention that my philosophy “pokes holes in 40 years of ERP implementation standard practice” that almost all implementation consulting firms utilize - I know as I have worked on both sides of the table – as a client, as client advocate and an ERP Implementation consultant.


Don’t get me wrong, I love the business that I have been engaged in primarily as a Project Manager; however, there are things that clients don’t realize are “happening to them” – especially if this is their first exposure to undertaking something as monumental as implementing a new ERP system.


Based on the past 25 years doing project work as a consultant and client; I believe there are four key foundational and never discussed “non-traditional” reasons that cause ERP Implementations to fail:

  • Confrontational Model of ERP Implementations

  • The Project Team Isn't a Team

  • Business Team Engagement Model

  • Contrasting Definition of Success

Let's discuss the - Confrontational Model of ERP Implementations


This might be hard for many of my colleagues to hear but every ERP implementation is a “conflict” between the client and the implementation firm. That's right your heard me – a conflict and in fact it's about the ERP System that we are trying to implement – don’t believe me read on!!!


I know what you are thinking -” John, you are totally off base on this one. How could the thing that we are both trying to make successful be the foundation of the conflict? – That is total – Bull!!!


Okay, let me see if my argument can convince you. For those of you that are clients and have never had the pleasure of doing an ERP implementation project my comments might be shocking or ever alarming to you! For those of you that have completed an ERP implementation (client or consultant) what I am saying will be clear to you – you may not agree with me, but it will be truthful and factual. 😊


Let’s start – before we really start – the software has been selected, consulting firm determined, contracts signed and all the executives from each company are all smiles, have shaken hands and patted themselves on the backs, all the “Kumbaya” moments are over the real work starts - let's get the project team together.


Now, what if I told you that both groups - the client project team and the implementation consulting team are coming from a completely different bias and perspectives. They are in direct conflict with each other. Don’t believe me huh? Okay let’s start with an easy issue that exhibits itself almost immediately in the Confrontation Model of ERP Implementations – project expectations of one another! – Looking forward to hearing comments on this blog if you think I am wrong! 😊





Below I am listing actual comments/statements/expectations that I have heard from my past clients and consulting teams during my past ERP Projects.


Typical Client Expectations of Consulting Firm




  • Client believes the consulting firm is going to make their project a success and that the consultants will do the majority of the work during the engagement.


  • Client believes that the “best consultants” will be assigned to the project and that they are all “experts” in their functional or technical areas.





  • Clients believes that the consultants will assist in designing “the best" processes that will specifically suit their organization needs.


  • Clients believe that the consultants are assigned to the project from start to finish and won’t leave until well after the project is finished.

Wow, if only consultants were really like this – wouldn’t the project be amazing. Truth be told these “expectations” by clients are almost completely wrong.


Reality of Expectations for Consulting Firms




  • Consultants are responsible to configure the application - that's it - that's all. The client is expected to do the majority of the work – document requirements, define processes, complete all testing cycles, define the organizational change impacts, create training material, conduct end-user training, clean and map company data, validate data conversion, support cutover, - guess who's doing the majority of the work to ensure “project success.”


  • Consultants are assigned to project based on complexity of the project; senior consultants do more complex project and the consulting firm determines if your project is complex or simple. But sometimes even that isn’t always the case – sometimes who’s available ("on the bench") is often who is assigned. Period. Getting an “expert” may not be the case for your project.


  • Consultants will tell you what process/transaction is available based on the functionality in the application and determine how you can conform to that model. Especially in a SaaS application – you are often limited to what you purchased and you will have to make your organization adapt to the application. Not the other way around.


  • Consultants are people – they get promotions, they resign, they get fired – sometimes even clients ask consultants to be removed. There are no guarantees that the consultants that start the project will be there for the end of the engagement. And once your system is live - clients only interact with the assigned support team not the implementation consultants.


Hold on a minute – don’t act too outraged Mr./Ms. Client – it’s not like you are being completely “honest” with the consulting firm either.


Typical Consulting Firm's Expectation of Client




  • Client Executives have a clear vision and strategy for the ERP implementation.


  • Client Project Team Members are given complete decision-making accountability for system design and configuration.


  • Client Project Team Members assigned to the project on a full-time basis.


  • Client Project Team Members are completely trained on the functional or technical areas of the application for which they are accountable.


Wow, if only clients were really like this – wouldn’t project be amazing. Truth be told these “expectations” by consultants are almost completely wrong – but since they do this for a living – they already know this – but they can always hope. 😊



Reality of Expectation for Client




  • Often executives think that the project team are the ones truly accountable to make the project a success – nothing could be further from the truth.


  • Most clients aren’t comfortable giving the accountability for system decision only to the members of the project team – which often results in delays and rework.


  • Rarely are client project team members assigned to the project on a full-time basis – even if they are when issue with “normal’ business operations occur project team members are “pulled back” into normal work.


  • Clients that look for ways to cut costs often cut application training as a result this impacts the Consultants who assumes that all members of project team understand what is being configured resulting in delays and confusion.


This Confrontational Model of ERP Implementations is fundamentally based on this disconnect/dishonesty regarding expectations between both groups – and it's absolutely no way to start any relationship – especially an ERP Implementation. But unfortunately, that is the case in most projects – and when you do an analysis of failed projects – you will see this is exactly how they start.

Knowing that these types of disconnects/dishonesties (and there are many, many more) are inherent from the start; is critical in reframing how these two groups will work together over the long challenging ERP project journey that they will be undertaking.


John Talio Consulting exists to address this situation and be the client advocate that ensures both sides of the ERP implementation are set up for success. Feel free to contact us and we can help you navigate all the future obstacles that you will face on your ERP project.

37 views0 comments

Comments


bottom of page