You really have to wonder, does any organization spend millions of dollars on SAP (or any other software) with the goal of failing?
The scope of a typical ERP project impacts almost every aspect of the organization and the implementation risks are real. It is not unusual when actual project timelines exceed the original schedule by well over 100%. The cost of consulting services alone can grow to 4 – 5 times the cost of the ERP software (with even greater upside risk potential). Finally, we have all heard the horror stories…expensive ERP initiatives that never go-live, or worse yet those that do and hamper the business for years after cutover. That is in spite of all the “proven implementation methodologies”, an alarming number of ERP projects have unhappy endings.
While the help of consultants is probably required, leaving the fate of your ERP project in the hands of consultants in many cases only creates a false sense of security. Regardless of the right intentions and what we may like to believe, software consultants are not all knowing, they benefit from cost overruns, and in the end have limited control of the key factors that enable ERP success (discussed later).
Software consultants certainly want the client to succeed, but in world of ERP consulting the game is “billable hours”. When it comes to ERP software vendors I can say only one thing, regardless of what the sales people claim the software can do, they will be long gone when it comes time to implement. Therefore, more internal project responsibility, ownership and managing vendors is the key to developing better business solutions, mitigating project risk, and significantly reducing implementation cost.
In many cases consulting firms or software vendors take the heat (and lawsuits) for ERP disasters when in fact it was the organizations own doing. Any list of the “top five reasons for ERP failure” makes it clear the organization is more than partially to blame.
When the client becomes disengaged and the project falls hopelessly behind schedule, consultants are left with no choice but to do it on their own. This not only feeds the consulting cost frenzy but management is left scratching their heads wondering why their ERP software (used successfully by many in the same industry) failed to meet their business needs.
Yes, many clients like to blame software vendors and consultants for their ERP failures; and in many cases it may be true. However, guess who bought the software and selected the consultants? On the other hand, why would any consulting firm not want the client organization to be knowledgeable, feel accountable and fully engaged? Sure consultants make a lot of money on uninformed or disengaged clients, but no consulting firm wants a black mark on their resume.
The reality is consultants and software vendors have no direct authority to “make” management or anyone else in the organization to do much of anything.
Consultants can provide expertise, perform tasks, make suggestions and can “insist” on many things; but at the end of the day only the organization can:
- Insure executives are educated, on board and understand their roles.
– Own the business case and drivers for the change.
– Clearly define, own, and communicate project objectives.
– Implement internal measurements systems to support the desired changes.
– Approve and contain the project scope.
– Require (not just sell) the cooperation of employees at all levels of the organization.
– Assign the right internal employees to the project team.
– Free-up the required time for those assigned to participate.
– Expect (not hope) the internal team and IT support eventually become software experts.
– Hire as internal employees people with the right skills and knowledge when necessary (you will need them longer than you think).
– Plan and utilize outside project management, application consultants, technical consultants, and programmers correctly.
– Hold functional (middle) managers, the project manager, the project team, and IT staff accountable for doing what they are suppose to do.
– Make necessary changes in business policies, practices, and procedures to take advantage of the software.
– Limit software modifications through business justification or changing business processes.
– Remove the people barriers and naysayers that get in the way.
– Tackle project business issues and decisions in a timely fashion.
– Take end-user training seriously and require employees attend.
No matter how great your consultants or ERP software, these are things only the organization can really do. In addition, these factors have the biggest impact on project success. Finally, they are just a few more reasons why consultants and software vendors cannot save the day (or own your project even if they want to).
No one said it would be easy; but an important question to ask is….. Why would any management team spend hundreds of thousands or perhaps millions of dollars on ERP with the goal of failing? The other question is: Do people rise to senior management levels within most organizations because they are totally incompetent? Generally the answer is no. So what gives? One answer is organizations do not plan to fail rather they fail to plan. However, it actually goes much deeper than that.
Implementing an ERP system is not something most organizations do every day. Unlike more frequently occurring internal projects such as new product development or pure technology projects, not everyone knows the ERP implementation drill, subtle pitfalls, and the consequences of certain decisions. ERP comes along every ten years or so and the opportunity for learning through repetition simply does not exist. Also, those involved with the previous ERP project have probably left the company or want to stay as far away from this project as humanly possible.
The good news is ERP project management deals primarily with management issues that decent managers can understand and do something about. The old saying “you don’t know what you don’t know” certainly applies. However, successful ERP does not require a PHD in computer science but a management team with practical insight, some common sense, and one that is willing to expect something from internal folks. No doubt, some outside coaching from consultants is normally necessary but this is very different from a “consultant driven” project.
Believe it or not, management can understand what must be done, the important questions to ask, the key decisions to be made and the potential implications of those decisions. Furthermore, this can be accomplished without spending a boatload of money on outside consultants. In addition, companies can develop and/or acquire the internal software expertise to be successful. Organizations have been doing this for years and ERP is really no exception. Contrary to popular belief, the need for the right internal skills and software knowledge does not end when the system is initially implemented. That is unless you want to spend a fortune in consulting fees for many years after go-live for the support typical of any ERP system (on-going training, configuration changes, future phases, upgrades, etc).
In many ways, controlling your ERP destiny is about getting “street smart” on how to implement ERP; since there are plenty of important things that most consultants and software vendors are not going to tell you. This enables the organization to engage their project, leverage internal resources, manage vendors, and make informed decisions that yield predictable results.
The author runs a blog called “Street Smart ERP” from the perspective of an ERP practitioner with over 25 years of IT and ERP experience. For more information please see
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.
- when an erp implementation fails who is to blame?
- can manager be blamed for organigations success or failure
- sap failures in organizations
- testers are often blamed for implementation failures
- The blame game of a failing ERP system
- who is responsible for failed erp projects
- whos factor responsible for failure erp implementation
- whose to blame when software fails