Part 3: Having the right approach and attitude to an ERP implementation
“Change is not made without inconvenience, even from worse to better.” Samuel Johnson
Do you know how complex Microsoft Word and Excel are?
Because Word and Excel look so easy, people under-estimate how complex other standard systems, like an ERP, can be. If business users knew how complex those two Microsoft applications really are, they would be more thoughtful and careful when embarking on a complex software project.
The statistics on ERP project failures are staggering. However you measure it, the figures don’t look good when it comes to software project success. There is a blog dedicated just to software project failures and a recent Harvard Business Review article highlighted the unexpected risks of major IT projects. Ironically ERP project failures keep occurring despite research that started more than 10 years ago on the critical success factors of ERP implementations, and which has been repeated several times since then.
While an ERP implementation is an IT project, it is also much more. Its main drivers and objectives are business-related, and it has a major impact is on people, processes and culture. Some important non-technical aspects of ERP projects were recognized early on:
“…large, complex projects, involving large groups of people and other resources, working together under considerable time pressure and facing many unforeseen developments.”
The way, therefore, to ensure that an ERP project is successful is not just to focus on IT issues but to have the right approach and attitudes. (Having the right people in the right place during the implementation is the topic of another blog series). The following are critical attitudes and approaches for a successful ERP project:
- Top management support
- Clear goals and objectives
- Management of expectations
- Change management, communication and user education
- Project/program management
Let’s look at each of these briefly.
Top management support
While top management initiate an ERP project, giving it their blessing to start, the tendency to delegate the project once it is underway should be challenged. Top management needs to remain not only accountable but also responsible for the project. The question of who in the executive team should be the ERP guardian is debated on numerous projects. One commentator has a strong argument that the CEO is the only proper person to be custodian of the ERP system.
Clear goals and objectives
Too many software projects use the metric of ‘on-time, on-budget’ to measure project success, but as a recent ERP project failure showed, if you only use those metrics other important objectives can get omitted, such as customer or user satisfaction. At the outset of the project, before software selection is done, success should be truly and clearly defined. How do we know the stakeholders will be happy? What specific measurable benefits should the system deliver? Put another way – what does DONE look like?
Management of expectations
One reason why a senior executive should be in charge of the project is so that it is ‘owned’ by the business, rather than by the implementation consultants who often develop the project plan. The project’s scope, planned deliverables and schedule have a significant influence on setting expectations.
Deciding on deliverables and schedules without sufficient executive and staff buy-in can produce an environment where legitimate concerns are ignored and distrust is created. When determining the scope, focus only on what is ‘in scope’ (which only implies what is excluded), but also make explicit what is ‘out of scope’ – this aims to avoid those difficult conversations of “but I thought XX was going to be included.”
Change management, communication and user education
There’s a saying in change management:
“Old organization + New technology = Expensive old organization”
An ERP project can succeed or fail through the commitment of the people who use it. Therefore it makes sense to communicate with employees – early, often and in-depth.
I mentioned in a previous blog that one of the aspects of managing an ERP project is how to handle business process changes. A Forrester Research comment on change management was:
“Any business process change is strongly related to personal change — that means your people — and this is often the component that gets shortchanged.”
The change management and training programs should commence in the early stages of the ERP project, not, as is often the case, near Go Live date.
When it comes to training, there are some basic mistakes to avoid.
- Training should not be considered a secondary, optional aspect of the project
- Users need to be educated (taught the inner workings and reasons) as well as trained (how to complete a task)
- Training should be planned for the long term
- A variety of training methods need to be employed
Project and program management
ERP projects can be complex and long; organizations therefore need to invest in a project management capability. This means they need to understand the principles of project management relating to software projects, and be prepared for the challenges of managing a project.
Projects costs money. Don’t spend the money? Then, as Dr. Phil says, “how’s that work’in for ya?”
Finally, since an ERP project has long-term consequences, businesses need to develop a program mentality when it comes to their ERP application. This is to ensure that the system receives ongoing attention, oversight and support throughout its life cycle.
(My thanks to Glen Alleman and Michael Krigsman for continually providing ideas, evidence and pointers on how projects should be managed.)
