So you’ve decided to replace your Enterprise Resource Planning solution. I’m sure you’re aware of the poor record for success in these implementations – the majority tend to be over-budget, past due on their intended timelines, and not offering the intended deliverables. Check here for an example of industry research backing this up. So how can you maximize your chances of coming through with a successful implementation?
Responsibility
First things first. Whose implementation is this? Right, it’s your implementation, not the implementation of the vendor/reseller – so you need to take sufficient responsibility and control to ensure it goes according to plan. If they don’t ask you about the areas covered below, prompt them – don’t wait for things to go bad. If you haven’t yet purchased a solution, don’t restrict your selection to product features, remember that the professionalism and know-how of the company behind the implementation is a major factor in the success or failure of the implementation, and judge them accordingly.
This starts with the way that you structure the selection process. We see a range of approaches to this, from customers who ask for a demonstration without any definition of what should be presented, through to those that provide a questionnaire of sometimes over a thousand questions. Although we favour the concept of a “short form” selection document, it’s not actually the structure that tends to be wrong behind any of these approaches, so much as the intent. For example, if you present a list of a thousand questions, even if you prioritize them into categories such as whether they require customization or are in the standard solution, there is usually no summary guidance within the document that assists the vendor in determining whether to quote to deliver all one thousand features, or (as is normally assumed by the vendor) to quote against an average quantity that would be expected by a reasonable customer. Immediately you have scope for a misunderstanding between customer and vendor – a misunderstanding caused by lack of communication, ironic perhaps given the volume of communication involved in such questionnaires.
Conversely, it is possible within a 2-5 page document to summarize the features that are most important to a business, and to set the expectation of the level of functionality that will be required. If it is critical to your business for a given feature to run on iPads, and unthinkable for order processing to take longer than a minute to take an order over the phone, don’t bury these at question 979 amid 200 other questions that are defined as “mandatory”, give the flavour of the importance of these to the selection process right up front. This will instantly improve your long or short lists of appropriate vendors, as most vendors will disqualify themselves from a sales process if they are lacking a feature you have described as critical – or will at least attempt to persuade you that the feature cannot be critical to you.
If you do not have time to prepare a selection document or even a demo script yourselves, you need to accept some measure of responsibility for the likely inaccuracy of vendor responses to you – and the risk this gives for an unsuccessful implementation. Of course a professional vendor will try to address this area for you, typically by performing a “discovery” process involving a question and answer session to identify important elements of the implementation. Many customers, however, are in a sufficient hurry when they reach the selection stage that they don’t make time for this process, or do not field appropriately qualified staff. Also because customers normally expect this step to be free, and yet busy vendors want to maximize their billable hours, there is pressure on the vendor to minimize this step – again increasing your risks.
Indeed is it even fair for a well-prepared customer who has engaged an external consultant to prepare a crystal-clear document to be charged no less than a poorly-prepared customer who has simply requested a demo and asked that you meet his budget of $50,000 for a 15 user system?
Communication
The summary of all this is that you need to communicate to each possible vendor what it is you are trying to achieve, before you select them. The pressures explained above will lead vendors to prefer to fill gaps in communication during the chargeable implementation, not the unpaid sales process. If they find something at this point handled poorly by their software, who is responsible for the additional cost to address this – always assuming that the solution can be achieved at all with their software? This risk doesn’t exist for the customer that defined their must-have’s during the sales process.
Poor definitions
Most businesses with division of responsibilities between staff will benefit from ERP rather than a simple accounting system. However, the definition of what is required, and the identification of return on investment for specific areas and benefit more generally actually requires a high degree of skill, and is not always done well. If you sense that your documentation of requirements is not well done, you should consider alternative ways of addressing this. Frequently vendors can be persuaded to assist in such documentation as part of the sales process. Alternatively investing further in the initial definition of the project may be your most important investment. As a minimum, get vendors to explain the detail behind their initial quotation, and make sure that you understand what this estimate does and does not cover.
Feature creep
If you fail to define what you want up front, the intentions behind the implementation become a moving target. You may have a budget for the implementation, but this was given against an estimate of the work required before there was any clear understanding of what that work would be. Many vendors will have a clear process for extending the implementation – explaining to you that further work is required to cover additional requirements that surface after the original budget was set. However, regardless of their processes for charging you, it is feasible that you will want functionality to address each new requirement that is uncovered. This is known as “feature creep”, and in a poorly managed implementation, with poor up-front definition, can lead to rampantly exceeding the initial budget and timeframe expectations.
Vendor lack of skills
Each vendor has a range of staff with different skills. A successful implementation generally involves skills such as:
project management – planning what needs to happen when, and who is responsible, managing the consequences of failing to meet deadlines. Project managers control keeping to the budget, or even up-selling additional features – but nonetheless are invested in ensuring that deliverables match customers’ expectations. In an implementation where the customer has set a tight budget, often project management is the area that is squeezed by the vendor. The result is less time spent on planning, and also on analyzing how the project is doing against that plan – with the risk of greater surprises as overruns start to occur.
ERP understanding – generally the most effective ERP implementation consultants have at least two years of experience with ERP (usually much more), as they need to have an understanding of general business processes as well as the software itself. Whatever your view on whether “best practices” really exist in a given industry, it should be clear that the more your consultant has seen of how other businesses do things, the better the chance that they can implement your specific requirements appropriately.
software knowledge – the larger the ERP system, the more training and experience is required to understand it. Typically it takes six months to get a consultant to be profitable, and several years before they really understand the important aspects of a mid-level solution.
development skills – if any level of customization is required, the vendor will need to use developers to write them. Consultants with ERP skills need to write the specification for the developers, and if it is a programming specification then those consultants also need a strong knowledge of the software and even in many cases the development language. The developers may need business skills, particularly if specifications are more business requirement oriented than programming specifications, as well as the ability to create strong solutions within the programming language available.
Add in further skills, such as training and support, and you can see how diverse a good vendor needs to be. The best way to address this area in advance is to get vendors to give details of their intended implementation team. Try to find the stronger resources available to you and ask for them – you could ask any reference customer you visit for specific details on individuals at the company to assist with this, plus don’t forget LinkedIn and other social media as a research tool.
Customer lack of skills
Of course you’re good at what you do! However, if that is not software implementation, you shouldn’t feel guilty if you can’t field staff with sufficient skills to ensure a good implementation. This isn’t always an issue of competence, often it’s more about availability – you’re just too busy. Bear in mind that a successful project will require a meeting of minds: you know about your business but not the software, and the vendor knows the opposite; you need to meet in the middle. Some compromises are possible, some are not:
customer project manager – if you don’t have one person in charge of the project, independent of the vendor, you’re at considerable risk. That person will need significant available time for the project, and ideally should have a good grasp of processes in your business. If you hire them for the project, it is unlikely they will have sufficient understanding of your business – although it can be possible to address this if other members of the project team are given this responsibility
customer project team – you need to make people available to the project who have enough seniority in the business to take quick decisions on points of detail.
If you don’t have people for these roles, you should seriously question whether you can afford to attempt an ERP implementation.
Buy in
This is a surprisingly prevalent issue – if your staff members feel insufficiently invested in the decision to buy a solution, they can often (consciously or otherwise) derail the implementation by lack of proper cooperation. “I’m the person who knows most about purchasing, why wasn’t I consulted? They can’t possibly know about how we authorize requisitions, and if they can’t even be bothered to ask me, why should I tell them…” You don’t want to find out about these processes during the training, after the design and build.
Consider whose input is really necessary during the implementation, and try to make sure that these people are included within those that see the vendor solutions before you buy them. Give them input to the decision-making process, even if the main weight of the decision is not shared with them.
Training
Last but not least, ensure there is a sufficient investment in training. Make sure you understand the basis on which the vendor has quoted for training – for example will they field their own staff to all training courses or is a train-the-trainer approach being recommended? Will they be performing generic training or courses tailored to your specific requirements? The latter can generally be done faster, but need more preparation time on the part of the vendor. If users end up with insufficient training, adoption is seriously compromised regardless of the quality of the solution.
… and what should happen if a project starts to fail?
Some projects will fail, regardless of the precautions taken. Early warning signs include functionality not working as expected, vendors not meeting deadlines, and staff confused about what they’re doing. I strongly recommend that your first reaction should not be to reach for the phone number of your lawyer, but to go back over everything in this article. This is the time you most need to communicate with your vendor, not draw up battle lines. Even if you do end up fighting your vendor in court (or otherwise!), you are best protecting yourselves by doing everything possible to explain what is the problem – articulate why your expectations are not being met, and what you feel needs to happen. This gives the project the maximum chance of success, and investment in this objective has an order of magnitude higher return on investment than time and money spent with a lawyer chasing your vendor.
Bottom line, at all stages of the implementation it’s in your best interests to invest in high quality communication with your vendor. Tell them what you want in as much detail as you can afford, and give them regular feedback on how they’re doing.