ERP implementation projects vary in expectation, scope, size, and complexity and risk.
So its no surprise that there are various proposals, duration, cost and different degrees of success and failures.While numbers vary, failure rates are high and even worse overall customer dissatisfaction is even higher. Its always surprising to me that new erp adopters somehow feel that the guidance of professionals and the evidence of many years of erp implementation experience don’t apply to them.
Experience is always important and helps to build a framework which guides the implementation project from inception to conclusion. All projects have a similar framework, you have to have some sort of organisation, some sort of definition of requirement, some design some build, some testing, some training and so on.
Each project an, project team and company is also very unique. Companies have unique cultures. They have different approaches to how optimize the trade off between the long and the short term, between optimisation of profit, quality and service, They have different ideas about empowerment, and knowledge sharing and control and segmentation of duties. Some have fixed polices and budgets, others are more agile and adaptive. Companies all to often indulge in wishful thinkng expect erp to subetitute for managerial shortcomings in such areas.
Implementation partners also confuse the process- they claim to have an agile philosophy but implement every customer the same way. While an accelerator or blueprint or core build makes sense for rollout across the same group where operations are similar e,g a retail chain, or a franchise, in a staple industry e.g. making bricks – it does not necessarily transfer so well to: another group in the same vertical, or across a group with diverse verticals, or to a group which is more fashion or design orientated.
Team roles vary and members have unique personalities, and hugely variable experience and skills both in their day to day functions and for project implementation. Often functions are in daily conflict-sales want instant production flexibility, manufacturing wants long runs. Purchasing wants to buy in bulk at a low cost, finance wants to conserve cash and reduce carrying costs. Marketing want to run a large tv advertising campaign manufacturing want the money to build a new factory. So it may take time to build a team. Often team members don’t know how their own business works outside their own function.
Change management and team building is a process. You have to do something for it to work. Its not enough to throw people together and talk about it for 10 minutes at the kick off. Those with ideas may not be the best documenters. those with most knowledge may not be the best trainers. Those with most project experience may not understand the business.
Managers have a unique style of leadership which impacts employees and creates unique interactions between the vendor and users. One individual in authority can overshadow decision making. Often IT or finance led projects do little for the operational areas who fid themselves tied up in layers of security and approval and budget control bureaucracy. Other mangers may sit on the fence until they see whether the project tis a failure or a success.
Companies strive for a unique competitive advantage which impacts the solution deliverables. The point important to understand. Even with a proven implementation methodology, there are variables within each unique implementation project which need to be managed to achieve a successful go live.
A Clearly Defined Project Scope Document – The goal of the project scope or user story document is simple; define how the “out-of-the-box” software will be used and agree what customizations or workarounds (if any) are required to fill in the gaps between the capabilities of the software and unique needs of the customer.
While the goal is simple, the creation and execution of the scope document is often a complex exercise. There are a couple of reasons for this.
First, there are differences in interpretation. As an example, a WMS might have specific cycle count capabilities. However, the customer’s expectation of what cycle counting provides may be different from that of the software. If this gap isn’t identified in the project scope then the delivery of cycle counting will not be satisfactory to the customer.
Second, it is very common for the customer to identify and document 95% of their operations. But it is the 5% that comes up at testing or after Go-Live that causes considerable problems.
Report definitions are left late and it turns out the out of the box report is not so useful, and necessary data is not captured in the transaction to create new report, and now re-engineering is needed.
So expect to invest time in the early stages of a project in enough training to understand the out of the box features and to do early protoyping different options. Plan a detailed walk through of every screen and function of the software is performed.
Detailed Security and report definition just be done as part of the design not be bolted on afterwards.
A gap is not identified, if it is not documented. Once the scope document is finalized and agreed to by the any issues that arise that were not covered in the scope document are understood to be handled as out of scope changes. Before you ask for a customisation define the test script – that is the easiest way to avoid later dispute and to minimize rework.
Understand the respective roles of the customer and the implementation partner – It takes two hands to clap. Its customer’s project not the partner’s. Its not construction project built to an external architect’s design with a fixed set of plans.
What is expected of the Implementation partners – are they just hired to perform specific tasks like install and configuration of a standard design ads fast and as cheap as possible, or to lead change, and to introduce best practise. Does it make a difference what skills and experience are needed to meet the different objectives of the different project and expectations of each customer?. If implementers are expected to be obligated to perform those tasks competently and within the project budget. then the customer also has the obligation to assign the correct resources an skills and to take the timely decisions necessary to meet the project objectives.
A problem that all customers face is that an implementation project is above and beyond their normal work or company role. Nobody ahs the luxury of a full time project team sitting around. For many manager’s due to competitive pressures they are already stretched and overloaded due in their full-time role. Within the project, the manager must assume additional roles which take considerable time and effort and new skills. Few companies really understand this workload nor do they properly look a the constraints – they expect a partner to provide a detailed time and cost plan, before design is done and without any consideration of their won resource constraints(holidays exams, maternity, exams, audits , visits exhibitions, month ends, other projects…) nor do they seek ways to address those constraints with e.g. temporary staff, or temporary lightening of routine workloads, or paying for the consultant to do more of the work..
If the new roles are outside of the comfort zone of the employee(s), then they will attempt to shift the responsibilities to others and often back to the implementation partner. A warehouse manager spending an additional 20 hours per week testing may not be able to cope and will try to shift that effort to the vendor. This causes the vendor to consume budget hours more quickly which then results in cost overruns and the testing which should be done under the careful scrutiny of the customer is less likely to be successful. It is important to define the roles, responsibilities and expectations of the project team up front. The Project Charter should be created up front and be signed by the Executive and the project team- Maybe 5% of project teams get around to do this. Those tend to be the successful ones.
A realistic timeline – which is based on realistic resource availability and realistic scope – with a short as possible path to completion –
“Time kills all deals”. Projects that are planned to be long often lack focus and urgency short term. Those projects lose momentum, and struggle to allocate resources for such a long time, must contend with staff turn-over, and change in business needs and change in solution technology – eventually the initial design eventually become irrelevant leading to failure.
It is also problematic when a project is rushed to completion with only half the work done. Like Goldilocks, the project team must develop a timeline that is “just right” balancing the need to complete the project tasks thoroughly while striving to minimize delays. This is easier said than done. First, determine the timeline required to do the project tasks. A critical chain approach plans fast but builds in contingency. Each milestone is completed and signed off before the next starts.
Determine the possible Go-Live dates (notice the plural). Find the Go-Live date that fits the timeline but also allows you to schedule “flex” or “catch-up” blocks before critical milestones. These blocks drive the project back on schedule.
Customer Dedication to the Project – I can’t over emphasize the importance of the entire customer team being dedicated to the success of the project. And yet there are projects where members of the executive management team provide little or no assistance to the success of the project because they didn’t vote for it. There are internal politics between departments resulting in resources not being adequately allocated at key tasks. All too often there is a picture painted by both customer and vendor that it is the almost sole responsibility of the vendor to do the work. This approach almost guarantees failure. A successful implementation project requires dedication from upper management and throughout the department stake holders. A project needs a project champion. Everyone in the business is impacted if management is tied up so they all need to understand its importance to the company and to their future. That needs a communication plan.
Prototype and Test, – Your project plan timeline should have one of its largest allocation of time set aside for training and testing. Prototyping identifies how changing parameters can better impact operations. Testing investigates specific scenarios and data to identify and problems before Go-Live. It helps to identify process variations that might have been missed in the Scope Document. It provides training reinforcement which, in turn, makes users more proficient on the system. Create a large and high quality volume of test data – this is useful training practise. A good test will involve hundreds (yes hundreds) of transactions as will a good pilot dress rehearsal. You can test inquiries, reports, and response time with a few transactions.
Progress Meetings – At the end of the day, the customer should want to know whether the project is on-track or failing. Regular status meetings keep lines of communication open between the team members. These should be short (10 to 15 minutes) but can be longer if there are important issues which need to be discussed. At a minimum the team should review the project plan providing an update on tasks that were assigned during the previous week and an overview of tasks assigned for the upcoming week. Tasks that are no longer on schedule need to be addressed immediately and a plan created to get the tasks completed and the project back on track.
Steering committee reviews are also needed to review risks, resources, constraints, budget, scope changes, policy decisions where users cannot agree, etc.
Even more important is the post go live support- and what happens next. Users are frightened of new systems, They need hand holding to avoid early rejection. As they get familiar personalisations and fine tuning needs a rise. Initial month ends in areas lime inventory close, financial close, payroll runs neall ed expert guidance.
Once the system is operational system maintenance tasks become important. Staff turnover, new upgrade releases , wider use of system feature and enhancement of operations, new customer or statutory demands means there should be periodic reviews and expected investment in system maintenance and enhancement. Will the same consultant be around to do this?. How stable is that partner, and his team? Are they local, offshore or freelance? What is the worthwhile premium for a system that works. What does the reference evidence show – does the partner consistently deliver, what is his support track record?
In house or external You may be happy with your in house implementation but are you really qualified to judge? You may not know that you don’t know enough. Is the server and database really optimised and maintained? Are you still driving a Ferrari in first gear without knowing how to tune the Sat Nav, or radio,
There tasks it makes sense to do in house e.g adding new users, taking back ups, fine tuning workflows and security, data retention policies, update of costs and prices and budgets, external reporting etc.
However self medication and surgery can be dangerous. Maybe be not now but in 3 month or 1 2motmnhs alter when] slow running code or overblown tables start to hit performance or database back ups shoot up in size. Or worse you start coding or working manually when there is out of the box functionality readily available. You develop new code but who does the best practise checks, the documentation, the move form dev to test to live, the recompilation. And yes those are some of the reasons why projects fail.
A recent survey indicated that senior mangers are broadly equally happy with successful erp projects form any of the major software authors i.e. a round 85%satsifactiion . However when it came down to end users there as a significant i.1. around 20% preference for Microsoft systems. Whether the end user adopts the system willingly is a major factor in both the short and the long term success, especially when new users are taken on and expert users leave.
