Magic Quadrant for Enterprise Backup/Recovery

Workshop OK, so perhaps we were a bit ambitious with the title of this article. With so many variables and dependencies involved in an ERP implementation, it would be somewhat naive to claim there is a sure-fire formula for success. Nevertheless, feedback from Register readers in our current workshop and the general experience of those in Freeform Dynamics that have witnessed many ERP projects over the years suggest the existence of some things you can do that will stack the odds in your favour.

First, let's deal with the basics. As previously discussed, it's obviously necessary to define your requirements appropriately and select a package that fits. Indeed, one of the most prominent recommendations coming back from Reg readers is to minimise the amount of development work associated with customisations and extensions. You can only do this if you start out with a reasonable match between the software and your requirements. And of course when modifications to standard functionality are necessary it helps if the software you have chosen is based on an open platform that is easy to work with from a development and integration perspective.

So, it's easy then. All you need to do is define your requirements properly, select the right software, engage the right implementation partner, and you are home and dry – right? If only it were that easy.

Some of the guys in Freeform Dynamics have had the dubious honour of having to referee between parties when ERP implementation projects have gone off the rails or, worse still, figure out how best to clean up the mess when a project has seriously crashed and burned. When you have been through this enough times, you realise that in many (arguably most) cases, the behaviour of the customer is at least as responsible for the issues as software problems or consulting firm shortcomings.

At the most fundamental level, it's amazing how many organisations try to pass responsibility for success to an external party such as the consulting firm. The mentality is that they are paying the firm a significant sum of money to provide skills and expertise, so it's down to them to make the software work according to the requirements that have been written down. While troubleshooting failed projects, this is one of the first things to look for – organisations that have 'been implemented', ie had the implementation 'done to them'.

When you dig deeper, you typically find that the customer has relied too much on the implementation partner to make key decisions, rather than accepting that it's their business, not the consulting firm's. While the latter will be walking away at the end of the project, the customer will be living with the results of those decisions for a long time to come.

A similar problem arises when the customer doesn't acknowledge the criticality of making key people from the business available to provide input, guidance and deal with decision making on the project. And even if they are aware of what they should be doing, they fail to make the necessary arrangements with regard to cover so the relevant people can be freed up to contribute to the project when required.

Either way, the result is the same – decisions with far-reaching impact that you should be making yourself are delegated to an external party, and when a proportion of these are deemed to have created an undesirable outcome down the line, conflict arises, and additional cost, delay and risk is created.

We won't go into the details of what happens when the IT department is forced into the driving role, but suffice it to say that this is generally an unhealthy situation too.

The golden rule for business executives funding an ERP implementation is to accept that the project is theirs. It doesn't belong to a consulting firm or the IT department - it belongs to the business, and therefore needs to be run as a business project. In practice, this translates into accepting responsibility for success or failure internally. After all, you can write as many penalty clauses into a consulting contract as you like, but if the whole thing screws up and your organisation has been crippled, you still have a broken business.

In practical terms, this responsibility is enacted through measures that prevent the kind of issues we have highlighted above. Make sure that there is buy-in across the business to what is going on, and that corresponding commitments are made to release key people from their day jobs to work in the project. Then ensure you have a good strong business-oriented project manager overseeing the whole process from the organisation's perspective. This will preferably be a person on the payroll, but if you have to bring someone in from the outside, do it independently of the primary implementation partner (who will undoubtedly allocate their own project manager) and make sure they report into the organisation's senior management (not the consulting firm), with the right level of mandate and support to make things happen. And bang heads together when they don't.

So what do you think? Do you agree with the risks and recommendations we have discussed? Or do you have a different view? Either way, let us have your feedback in the comment area below. ®

Magic Quadrant for Enterprise Backup/Recovery