The complexity and wide encompassing nature of ERP means that there are inherent challenges in any ERP implementation. The issue is to ensure that these challenges enhance the project and final outcome rather than become problems or disasters that undermine the project's viability.
According to Carol Ptak, failure is "an implementation that does not achieve a sufficient return on investment identified in the project approval phase. Using this definition, it has been found that failure rates are in the range of 60-90 per cent."
This is a fairly uncompromising definition of failure. The industry and the media are rife with stories of more dramatic IT project failures, and sometimes even disasters, and these are occasionally even backed up with reliable information and data. The Standish Group's oft-quoted and on-going CHAOS study suggests that two out of every three IT projects fail - ie succumb to total failure and cancellation, or suffer cost overruns, time overruns, or a rollout with fewer features or functions than promised. Sometimes these failures have disastrous consequences beyond time and budget, and can seriously impact on the continued existence of the organisation itself.
But every IT implementation need not end in disaster. In fact, by studying the nature of past failures and finding common elements, mistakes and problems can be avoided.
R. Ryan Nelson (MIS Quarterly Executive, June 2007) investigated a number of 'infamous' IT project failures that in some instances involved sums in the billions of dollars. A post-mortem of these projects revealed that "While some of the projects experienced contractor failure, others cite poor requirements determination, ineffective stakeholder management, [over-extended] research-oriented development, poor estimation, insufficient risk management and a host of other issues."
And what is our reaction when something does go wrong? Nelson says that "We tend to make some mistakes more often than others. In some cases, these mistakes have a seductive appeal. Faced with a project that is behind schedule? Add more people! Want to speed up development? Cut testing! A new version of the operating system becomes available during the project? Time for an upgrade! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him!"
Nelson cites an on-going study at the University of Virginia into the reasons for project failure. During 2006, the students in the Master of Science degree in the Management of IT program studied 99 projects to elicit any common lessons, regardless of whether or not the project was ultimately considered a success.
"The first major finding," he reports, "was that the vast majority of the classic mistakes were categorised as either process mistakes (45 per cent) or people mistakes (43 per cent). The remaining 12 per cent were categorised as either product mistakes (8 per cent) or technology mistakes (4 per cent). None of the top 10 mistakes was a technology mistake, which confirms that technology is seldom the chief cause of project failure. Therefore, technical expertise will rarely be enough to bring a project in on-schedule, while meeting requirements. Instead, the finding suggests that project managers should be, first and foremost, experts in managing processes and people."
He goes on to add that, while scope creep did not make the top 10 mistakes, "the fact that roughly one out of four projects experienced scope creep suggests that project managers should pay attention to it, along with its closely connected problems of requirements and developer 'gold plating'".
"Two other surprising findings were contractor failure, which was lower than expected at #13 but has been climbing in frequency in recent years., and adding people to a late project, which was #22, also lower than expected.
"The third interesting finding is that the top three mistakes occurred in approximately one-half of the projects examined. This finding clearly shows that if the project managers in the studied projects had focused their attention on better estimation and scheduling, stakeholder management and risk management, they could have significantly improved the success of the majority of the projects studied."
Recognising problems and potential problems is one thing; doing something about them, preferably before they occur or incur great harm, is another.
Below is a summary of "six fatal mistakes" in ERP implementations, along with methods that can be employed to avoid or, at worst, rectify them.
The failures and methods to avoid them are:
Ineffective project leadership.
There are many different aspects to this and they are by no means all controlled by the Project Sponsor and the Project Manager. Leaders in all areas affected by the project need to have a clear understanding and commitment to the reasons for the project and its end goals. Without their support, the project team will often be side tracked on insignificant issues by end users with their own personal agenda. Commitment starts with the Project Charter which should clearly articulate key aspects of the project. Project Charter approval should not be taken lightly in an effort to achieve an early milestone. Many Project Managers have been frustrated by people who have signed off a Project Charter without fully understanding what they have committed to. This always manifests itself during the tough times when it is least helpful.
Leadership also embraces the management of risks both from a project perspective and the management of the on-going business during the implementation. The company cannot afford for either to fail, yet it is often key resources who are forced to make priority decisions instead of the company leaders who should understand the overall picture.
Modifications to the standard system are at the forefront of potential mistakes. The leadership has an important role to play. Any modification that is proposed should be endorsed by the business leader most affected by the modification. This endorsement should incorporate clear reasons why the standard solution cannot be used and what benefits will be achieved. Where possible the benefits should be built into operational budgets to ensure they are realised.
Lack of frequent and realistic milestones throughout the implementation project.
In developing your project plan, you should always have the ability, at any time, to answer three critical questions - where are we? are we there yet? and how do we confidently know we are there? By setting frequent milestones at key points along the project timeframe, you will be able to quickly measure your progress and more importantly celebrate achievements with the team. Of course, this is also the time to make adjustments if, for whatever reason, the project is not going to plan. The important thing is to ensure that any milestones set are simple and realistic.
Having no dedicated, high quality people in your implementation team and no compensation scheme in place for them.
The reality is that the people you really need in your implementation team are undoubtedly your best people, and it is almost guaranteed that they are also the busiest and least able to find additional time for the project in hand.The best thing you can do is to offload some of their daily workload onto junior staff. And by giving junior staff the chance to prove themselves at a higher level, you also gain a wider spread of skills in the business and identify potential promotions at the same time.
The many different ways of rewarding project staff for their achievements range from revised job descriptions and salary scale to higher duty payments. The most effective, is a double bonus scheme, made up of a financial bonus against achieving major milestones and a public recognition or even celebration at each relevant stage. An extended leave at the end of the project may also be effective.
In the overall scope and cost of your project, the additional bonus and public recognition will pay dividends well past the life of the project. Bonuses should be significant enough so that recipients feel proud and respected rather than cheated.
Lack of adequate budget for training users on the new system.
Almost every organisation approaching systems implementation fails to budget sufficient dollars and time for training and the end result is that uptake on new systems, processes, policies is slow and the immediate effect is longer time to benefit. It is normally true, he adds, that whatever figure you have budgeted for training, you should double.
Making modifications to the standard system without carefully weighing benefits against risks.
There is a tendency in many organisations to quickly modify the system in areas where it does not match present business processes. The end result of this is a system where future upgrades become extremely difficult to apply and any help desk support is always compromised because of the need to know the modifications as well as the standard system before any help can be offered. The approach is to apply three "whys":
- Why are we considering this request for a modification and what is the proven measurable benefit?
- Why haven't we looked at all the alternatives and their risk/benefit first before choosing to modify?
- Why don't we see what other companies have done in this area? Unless we are the first, there must be lessons out there that we can learn from.
Failing to protect and insure the most critical parts of your business.One example is of a managing director of a large pharmaceutical firm who wanted three guarantees before signing a contract for a new system:
- That his system would never, never put him in a position where he couldn't take orders from customers,
- That his new system would never, never prevent him from dispatching customer orders from his warehouse, and
- That his new system would never, never put him in a position where he couldn't accept his customers' payments and put their money in his bank account.
The lesson of this is to take a hard look at your business and identify the critical areas that you need to have available 24/7 and then talk to your hardware and software vendors to make sure they can provide adequate backup/recovery options to keep you operational when the unexpected happens.
Even with so many catastrophic examples of companies going bankrupt due to failed software implementations, many companies still don't pay enough attention to the risks involved. Adequate planning and preparation is essential to help you identify and manage potential risks. Previewing is just as important than reviewing, certainly when it comes to avoiding potential disasters. By previewing your current business practices, goals, risks and articulating a solid implementation plan, you can go some way (at least) to making the life of your ERP project that much less risky.
References:
- Nelson, R. Ryan, "IT project management: Infamous failures, classic mistakes, and best practices", MIS Quarterly Executive, June 2007
- Ptak, C., "ERP: Tools, techniques and applications for integrating the supply chain", 2000, St Lucie Press (as cited in Wong et al)
- Wong, A., Scarbrough, H., Chau, P.Y.K., and Davidson, R., "Critical failure factors in ERP implementation".
