The role of consultants in an ERP project

It is incontrovertible that companies should do as much as possible of the work involved in their ERP  projects, for several reasons, including:

• it keeps costs down
• it makes user buy-in easier because the system always belongs to the company and not to the consultants
• it ensures that hard-won experience and knowledge stay within the company after the consultants have left.

But equally undeniable is that it is almost impossible for companies to have all the necessary skills required for a successful conclusion to the project. These skills include:

• comprehensive knowledge and understanding of ERP
• an ability to write good requirements specifications
• the experience of project managing an ERP project
• the ability to manage change
• detailed knowledge of the strengths and weaknesses of the selected system (all systems have strengths and weaknesses).

Many organizations, especially the larger ones, will have some of these skills but none will have all, so a look at each of these areas will help to identify where external assistance is likely to be necessary.

Understanding ERP

Some companies are not interested in understanding ERP and what it can and, just as importantly, can't do. They just want a modernized version of their old system but, if we chose cars that way, we would still be driving Model T Fords. Implementing a new system is the best chance that an organization will have in years to review what it does, why it does it, and how it does it.

So organizations need to look forward; not backward. They need to consider doing new things, and doing old things in new ways and, to do that, they need to understand what ERP can offer so that they can explore new possibilities. But, at the same time, they need to be realistic about what they can achieve and most organizations benefit from input from people with extensive and varied experience.

It may be that new employees can bring these fresh perspectives with them but just a few days of genuinely independent advice can help identify both opportunities and potential pitfalls for a fraction of a percent of the project budget.

System specification and selection

A written specification of what the new system is required to do is essential. Firstly, it allows competing systems to be objectively compared and measured against actual requirements. Secondly, it sets the scope of the project and by doing so, limits 'mission creep', as anything that is not in the requirements spec is not in the project unless proper change management procedures authorize it to be there.

And, lastly, if using external consultants or system integrators to implement the software, it tells them (if properly written) clearly and unambiguously what they are required to deliver. The keywords here are in the phrase 'properly written' because ERP salespeople are predisposed to answering 'yes' to questions about their software's capabilities and, even though the clever ones will not lie, they can often 'interpret questions advantageously'!

Project management

Many companies already have good project management teams in place and may not need much help in this area, but even they will benefit from a day or two with experienced external consultants. One primary job of project managers is to estimate the amount of time that tasks will take and then build in contingencies to cope with unidentified tasks and for when things go wrong.

Things will go wrong and, when trying to identify what is likely to go wrong, there is no substitute for having walked the path before – several times. System providers and system integrators should be able to help but can be drawn to being over-optimistic to ensure that they get, and retain the contract.

System integrators will make a case for providing project management but it is rarely a good idea for external contractors to manage themselves.

Change management

For many years change management consultancy was, at best, a 'nice to have': something to put in the plan to bump up the budget but always the first thing to be pulled when costs had to be reined in. The main reason was that it was easy for companies to convince themselves that all that was changing was the screens that users were looking at because buyers would continue to buy, order entry clerks would continue to enter orders and accountants would continue to account.

All that was required, they felt sure, was some training and perhaps some work to make the new system look and feel like the old one. But they were wrong. No system is a carbon copy of the old one (and, if it was, there would be little point in changing), so there will be different options, different routines, and different ways of doing things.

When change is underestimated, some people can feel overwhelmed. Experienced hands will have gone from perceived experts in the old system to complete novices in the new, and many will find that difficult; as can their less-experienced colleagues who have relied on them for advice and assistance in the past.

On the other hand; allowing them to think that the change may be greater than they can cope with can make them decide to move on to less-threatening environments, with the result that the organization loses good people at the very time that it needs them most.

Good communication, clearly explaining what is going to happen and why, undoubtedly helps but, as with many aspects of ERP, talking in advance with someone who has trodden the path before helps to ensure that there are no nasty surprises.

Implementation consultants

Implementation consultancy can come from two places: Tier 1 systems are generally implemented by teams of consultants from one or other of the large management consultancies; whilst, with Tier 2 and Tier 3 systems, companies are usually restricted to choosing from amongst the ERP author's value-added resellers (VARs) or dealers.

For all companies, picking a good implementation partner is as important as, perhaps even more than, choosing a good system. But not all consultants are as knowledgeable and as experienced in the software that they are implementing as the customer has the right to expect.

Every implementation consultancy, from the biggest to the smallest, has consultants who are either new to the job or new to the software package that they are working with. When a large team of consultants is working on a Tier 1 project, the weak and inexperienced consultants can be shielded by giving them tasks out of the client's gaze, where they can be coached and monitored whilst they build up their knowledge (albeit at the client's expense).

Things are more difficult with Tier 2 systems, which are typically implemented by small teams of consultants (perhaps one per business area), and even more so with Tier 3 systems, where frequently just one 'all-rounder' consultant will be assigned to cover all aspects.

In Tier 2 and Tier 3, inexperienced consultants inevitably come into direct customer contact and so the risk of the client being given inadequate, or down-right bad, advice is very much greater.

Ironically, though, the problem can be easier to fix at these levels because companies generally have a greater choice of implementation partner and can interview competing contenders, and even individual consultants, to ensure that the skill sets of those consultants match the tasks that they will be asked to perform: something that is impractical on a large project where dozens, or even hundreds, of consultants, will be involved.

In summary; several skills are required for a successful ERP implementation and, although some companies will rely on just one consulting organization to provide everything from change management to software-specific end-user training, history shows this to be a risky strategy because it puts the client in the hands of those consultants in an environment where the odds are stacked heavily in the consultant's favor.

The most obvious risk occurs when the same consultants are involved in both system selection and system implementation. But equally risky is having the implementation partner, or system integrator, provide both project management and implementation services because then they will be monitoring and managing themselves.

It is in the customer's best interests that there are at least two sets of consultants involved, so that all important decisions can be properly debated and, where necessary, challenged. One last thought: before the contract is signed, all consultancies will be putting their best people in front of the client.

But clients frequently find that, for all sorts of reasons, some of the most impressive consultants become 'unavailable' for subsequent phases, and their replacements are less impressive: a situation not improved by having to re-educate these new consultants about the company, its culture, and its needs.

Companies should always remember that they have the right to choose which consultants will be working on their projects: if the contracts they sign preclude them from doing so, then they have signed a bad contract.