"The Real Reasons" ERP Projects Fail!!! – Part 3

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

If you have been reading this series in sequence, then my philosophy regarding the first two of the four “Real Reasons – Why ERP Project Fail” should be clear to you.

• Confrontational Model of ERP Implementations - Link to Part 2

• The Project Team Isn't a Team – Link to Part 2

• Business Team Engagement Model

• Contrasting Definition of Success

Now let’s discuss what I believe is the essential failure of most ERP projects that is repeated by virtually every customer. It is done with the explicit direction of the software company; their consulting partner, it’s even documented in the implementation methodology – and in my opinion it’s completely wrong; it's referred to as the – Business Team Engagement Model – let me explain.

Every ERP Implementation methodology expects – more like – demands that the client provide an internal group of Business resources to act as “Subject Matter Experts” or worse still “Project Leads” to ensure that the system is designed, configured, tested, deployed and supported to the “exact” expectations of their organization.

I can hear some of your thoughts as your read that last paragraph – “That sounds logical John!!! Well, they are the customer, aren’t they? They should know what they want. Makes perfect sense to me! Isn’t that how it has always done?”

Unfortunately, “Isn’t that how it has always done?” is exactly the catalyst for failure. Those of you that know me have heard me say…(many, many times😊)

“Doing the exact same thing, the exact same way and expecting a different result is the definition of Insanity”

Let’s say that you are one of the Client Executives that have a vested interest in this ERP Project being successful and you are trying to get key Internal Business resources lined up for this project.

I can hear you now making your pitch to the Business Team – “This project will be critical to our company and you will have a direct impact in making this happen!” This will be an exciting initiative and we think you can handle it!” “We know that you will do a great job and we are willing to provide you with $XX in compensation/bonus upon completion of the project!” “We see this as a great opportunity for your career development and as a future leader in our company!”

These statements are all probably true but are often “sugar-coating” or even misleading for the proposed Internal Business resource team. Why do I say that – well because you forgot to mention that this will one of the most complicated and challenging endeavors they will face in their entire career;

• they will be working 50–60-hour weeks,

• they will need to make critical business decisions on a weekly (if not daily) basis,

• they will need to become the “functional application expert” for which they are accountable,

• they will be a response to ensure that the system “works, is accurate and user-friendly”,

• they will be constantly under timeline pressures for months on end,

• they will be seen by their peers as “responsible” for the solution (good or bad) after go-live, and

• they may be required to support this system for years to come.

By the way, did you mention that they are completely untrained and may not be capable to do this type of project and that they will never do this type of work again once the system is live? These people are going to be pulled out of their “regular jobs”, someone might be hired as a “back-fill” while they are seconded to the project and the fact that you have probably told them “that this will be a great opportunity for their careers”.

Wow that sounds – awesome – where do I sign up for this gig!!!

Think about it – you are asking a group of people to successfully deliver your ERP solution, yet they may never have been exposed to any other aspect of the project – ERP Vision and Strategy; Requirements Gathering and Documentation; Software Evaluation and Contracting; Solution Implementation Partner Selection.

“Traditional” ERP implementation methodology says that Business Resources are required and mandatory to ensure the success of any project, the following topics outline the fundamental flaws in that approach:

Project Business Resource – Implementation Competency

• Most employees in a company have never done an ERP implementation in their career and will be as green as a new student hire when it comes to doing this type of project work.

• No real exposure to the true vision and expectations of the implementation. They are often unsure of the company's “true goals” and what they intend to achieve from the ERP project.

• Business Team members will need to make key business decisions that they currently don’t have accountability for in their “normal” roles.

• The internal project team will need to learn a new application, along with all the terminology, deliverables, and toolsets associated with the ERP implementation.

• These individuals will become the “Functional Expert” for their specific area and probably have not computer programming expertise to ensure that the system is being configured correctly based on the requirements

• Project Business resources will usually be required to attend “Functional Application” training. At best this will give them rudimentary knowledge of the application you are implementing and is usually repeated by the consulting team once the project is initiated.

• Usually, these individuals have no process reengineering experience and will want to re-create the existing processes, as that is with what they are comfortable with.

• Project Business Team deliverables and accountabilities are always originated from the Solution Implementers point of view and place greater accountability on the Business Resources – as a result the project is always more accountable to the client-side – but surprisingly few project team members are under that impression.

• Business Team members and Implementation Consultant resources are placed side by side (or in the same box) in the structure – since the biases of each group are often opposites – this can result in conflicts at every level and functional area of the project (see Part 2). Also, if you have two weak/incapable resources together in the same workstream can be catastrophic for your project.

• Project Team Members are responsible for all deliverables on the project and in some cases managing the Implementation Consultant deliverables. Consultants will take no accountability for the definition of your business process, data, security, reporting, and functional support. They are there to configure the system the way you tell them and will only push back if you are putting the application’s abilities at risk.

Project Business Resource Availability

• Clients “say” that project business resources will be assigned full time, but when the running of the active business operation is at risk these resources will be pulled back into the day-to-day operation – and that always puts the project at risk for failure.

• Project Teams that utilize a “part-time” allocation model – will always run over the original timeline and the team also “sees” the project as a non-critical initiative for the company.

• The Business Team members in this model will also make their “regular” job tasks more important than the project tasks as those are seen as “real work” as opposed to projecting work.

Back Filling With Project Business Resources

• Clients often talk about “backfilling” the project business resource with new hires. In theory, this makes sense – in practice what happens is that the new hire requires so much support from the project business resource that this “solution” turns into a distraction and impact to the project deliverables.

For example, Bob is the Compensation Functional Lead on the project, but new hire Jane is struggling and needs his help during the Annual Compensation Planning and Processing Cycle. Bob’s “regular boss” informs the Project Manager that Bob will not be engaged with the project during this critical time and will return upon the completion of this work.

Project Manager comment 😊- Looks like you can forget about the project being delivered on time and on budget!

In the next blog in this series, I will be reviewing how the Contrasting Definition of Success is the final ingredient to ERP Project Failure.

Don’t worry, I will explain the best way to ensure that you and our organization can be protected from making any of these major missteps in the final blog of this Series – ERP Success – Easy as 1,2,3!!! Please come back and learn what that my secret to ERP Success and if you can’t wait for that blog; feel free to contact – John Talio Consulting and we can help get you on that path today!!!