Perhaps because the failure is hard to predict, define and to prove. Perhaps because failure is usually the perspective of the implementing organization but not necessarily the solution providers Viewpoint on the same situation. Does it startle you that in 2017 with Digital Disruption of Internet of Things, Big Data, Machine Learning and Cognitive Computing sweeping off the software industry and we still experience on a global scale, a failure or challenged projects rate approximately 60-ERP makers and Implementers have undergone decades of building experience, knowledge acumen with thousands of implementations yet something still goes wrong or rather unnoticed.

A steady success rate of 30-35% in the past six years daunts any organization seeking a full end to end information management solution and business automation. ERP Projects are the most infamous implementations in the software industry so there is no question that adopting a flexible agile methodology to software applications development has contributed to an increased success rate. The feedback loop between different stages of the implementation lifecycle as well as strong stakeholders’ involvement may mitigate some of the post-development/post-implementation risks of a long waterfall lifecycle. Yet there remains a missing cornerstone. From our decades of experience in business analysis, software design, implementations, testing, support as well as arbitration and mediation, we can confidently and unfortunately confirm that the problems (root causes) are still the same, their symptoms have evolved and implications have developed to greater extents but the causes are the same and are clearly identifiable and avoidable in advance.

  • Plan Before You Start

From our collective experiences, projects fell largely in three categories; those who forfeit a nice-looking plan in which they themselves had no confidence in achieving and the second category which waste the entire project lifetime in planning, and re-planning then some additional ‘replanning and finally a different planning approach. And the third category who claim that agility means work as you go .. and call it a plan. It is important to admit that we did belong to all three categories in many of the planning categories throughout our careers. What works best is a rolling wave approach to planning. It is inconceivable to plan what you will be doing 8 months from now and it is also chaotic to not have a clarity about this week’s or months work plan.

  • Requirements Vs. Business

It is very common for any organization and its stakeholder to mix up between their requirements and their business. They discuss both with you interchangeably. Understanding the clear distinction between both is as essential as understanding the difference between a jet plane and the sky. You will not start with the sky to understand the plane. Till this day, we see many even business analysts actually work in abstract looseness to define a clear requirement, they often confuse it for acquiring sufficient business knowledge.

  • Business is Complex

As independent BAaaS providers, we run into tens of businesses from retail, tourism, production to banking and technology and the notion that everyone carries around is that business is complex. If you work in an organization or implement ERP solutions and still see that the business operation that you are spending most of your life with is complex then trust me, the problem may lie beyond the business but in how you see it. It is a matter of fact that some subject areas are maliciously detailed, interrelated and interdependent but not so sure about complexity. Perhaps we interpret complexity as unpredictable or random, and in such case some human behavior may fall in the complex category as it is not entirely predictable and relies heavily on hundreds of variables such as; genetics, bringing up and past experiences. Business is straightforward simple when you are looking at from the right viewpoint.

  • Reliance on the Software Provider for solution; to define your ERP Business Needs

Seems awkwardly clear that when you ask someone what you really need to efficiently run your business that it would happen to coincidently be exactly what they sell!

What an independent third party provides is a transparent honest monitoring and status reporting and remedial actions for incomplete functionality implementation workarounds, poor customization design, sufficient testing coverage or potentially solution stability threats. Again, what do you expect when you ask someone to build or deploy a system and evaluate their own performance through acceptance testing. User and business acceptance testing should have performed in total isolation from ERP providers designers, developers, and implementers. We have seen cases where clients had to pay to fix solution bugs that were part of the commercial package

  • Jumping to Conclusions

We need business automation fast to meet critical deadlines then perhaps later, process analysis and improvement. There are thousands of case studies projects where automation took place in parallel or prior to significant process assessment and enhancements. It is true that processes are evolving but segmental business automation is the essence of agility.

  • Lack of Emotional Maturity

We would consistently argue from our field jobs, and witnessed change resistance that a good share of software failures, ERP included is the act of the devil, egos of the team members, business stakeholders and leadership involved. We often confuse our identities and doubted the sense of self-worth for choices we make in our day to day work. When egos collide with the best interest of the project, most unconscious human beings will act in favor of their ego comfort and they won’t even know it.  This is hardly taught in business schools, and that’s what hiring and staffing should focus on. You should never question the dismissal from a project team; a key knowledge stakeholder, a brilliant functional implementer, testing or genius analyst if their ego was bigger than their emotional maturity. They act as poisonous valves in any project and create a fabricated sense of tension.

  • Leadership

Selecting who leads the initiative is a make it or break it decision. A lead is someone with a clear vision of the final implemented ERP, great communication skills and an experience in successful implementations. Someone who can make fast informed decisions and take full accountability for each decision taken. Please put aside all the dull talk about the servant leader, if the project team needs someone to serve them then it is hardly a self-organized highly skilled team. We have witnessed many servant leaders or project manager or product managers who only add an unnecessary node in the communication and decision-making chain. These are bottlenecks to your ERP Implementation. A leader is an integrator, someone who can and does see the big picture at all times to swiftly and boldly correct deviations.

Blind Conformance to Norms

There is no concept as constant business norms, and those who live or work today by the rules of yesterday are doomed to fail. They are just held captive in a world that has finished with sunset.

Excessive meaningless communication

When business is clear, the process is well defined, then there is no need for excessive communication. Endless meetings and hundreds of emails are a crystal-clear sign that many are not working. If we work on a new project and get bombarded with 8 meeting invitations every week and 20 emails every day then we quickly withdraw from the scene. Emailing is not progress; excess communication is most of the time resolving team’s lack of knowledge and shortage in skill sets or a way to avoid actual accountability.