Reg reader tips for ERP success

Workshop When we asked Reg readers to tell us about the factors that impacted the success or failure of the last ERP implementation they were involved with, 50 of you came back with your insights.

Of these, about a third had experience of actually managing an implementation, with most of the remainder having worked as part of an ERP implementation team or provided consultancy on ERP projects. One reader admitted that while he hadn't been directly involved, he was commenting from observing the antics of a bunch of consultants who had been squatting in his IT department for quite some time.

And speaking of consultants, one of the things we were exploring in the poll was generally where the point of weakness usually is in an ERP implementation – does it lie with the software, the external consulting, or the internal resources working on the project? It's something we touched on in a previous article where we postulated that lack of willingness/ability of the business to make the right internal people available on the project to provide input on requirements and make key decisions where required was a common problem. Quite a few comments that came back echoed this, such as:

“Companies happily shell out millions of Euros, but they think they do not have the time to sit down with the consultants/developers of a complex IT system to clearly define what they want. Or what the existing business processes are. Or how they must be changed for the new system.”

“When you hire *any* professional they are here to give expert *advice*. But at the end of the day final decisions *must* be made by key people in the business (either directly knowledgeable or under advice from internal staff with deep understanding). If you don't you're not in control of your own business. They'll either sideline the work on that module or decide based on their experience. Might work, might be epic fail.”

It therefore came as no surprise that the overall top three most common challenges on ERP implementation projects highlighted in our poll were to do with internal resources not being as available as required, conflicts among senior management over requirements, and that old chestnut of keeping control of scope creep (Figure 1).

Figure 1

This second most common challenge to do with senior management not always pulling in the same direction is also something we have previously discussed, and again, was reinforced by readers. This time though some of the tips for success you came back with, included:

“If you cannot get unambiguous and committed engagement from key business leaders...do not do the project.”

“Ensure strong communication between stakeholders.”

“Top down command and control of the process to keep the stake holders in line.”

The reference to control in this last comment is clearly also relevant when considering the scope creep challenge, which highlights the need for effective project management. Some readers also had tips on this:

“Have an organised PMO [Project Management Office] team”.

“Appoint a full-time internal Project Manager”

With this last comment in mind, and considering the fact that the implementation partner (e.g. the consulting firm) will always appoint their own project manager, it is telling that readers participating in the poll put much more emphasis on the internal role (Figure 2):

Figure 2

It is also worth highlighting this comment that was elicited by one of the aforementioned previous articles, which underlines the importance of the project manager being a business oriented animal:

“I entirely agree about the need to ‘have a good strong business-oriented project manager overseeing the whole process from the organisation's perspective’. I expect that a large proportion of ERP implementations have been screwed up due to having a techy IT PM in place instead.”

Even the best project manager, however, can only keep things on track if requirements have been properly defined and activities and resources planned:

“Define scope, make sure you know what the key objectives/benefits of the project will be.”

“Define the processes in detail, however long it takes, so the business understands what it's signing up to.”

“Document everything ... Get a full list of required reports”

And, of course, don't forget the contingency element:

“After having done estimates on calendar time, resources and funds. Then do a risk analysis and put aside extra calendar time and funds to be able to absorb unforeseen challenges.”

“Make sure that you can get your hands on extra technical resources if need should arise, and that you have the funds for such emergency 'staff ups'.”

As with all polls and surveys, you can never be sure you have covered all of the options when asking multiple choice questions, which is why we always leave room for readers to provide freeform feedback in addition to ticking boxes. In this case, the thing we missed was the importance of considering data migration, but a number of readers fortunately picked that up with comments such as:

“If migrating data from legacy systems, cleanse data before importing to new platform.”

“Start data cleansing and preparation as early as possible.”

Then, of course, we received more feedback on the familiar question of whether to change the process to match the package or vice-versa:

“If you buy a package, use the standard functionality without too much change.”

“A willingness to adapt business process to how the new software works is crucial.”

“Align business process with how the software works”

If you haven't got the message on this yet, then go back over some of the earlier articles and poll results from this workshop, and the reader feedback that time and time again underlines the importance of minimising customisation work to prevent cost and rigidity issues down the line.

To finish off, here are some nuggets of advice from readers that particularly stood out to the team here at Freeform Dynamics as representing the voice of experience and wisdom:

“Keep timelines as short as possible. The longer a project runs the more chance of seeing staff turnover. Bringing new people into an ERP core team results in delays (at best) and changes to scope (at worst).”

“Don't neglect all your in house IT workers that do at least as much as that army of ERP consultants for a fraction of the money.”

“Set expectations early, users were sold on the premise of 'the software will make their lives easier' by the sales people in the selection process but were disappointed when interim processes (due to a phased implementation) caused more work.”

And perhaps our favourite comment so far:

“When one client said that their users wouldn't be able to cope with the new ERP system, their external auditor suggested, with some feeling, that they get new users.”

Feel free to chip into the debate and add your own two pence in the comment area below.