If anything positive can be taken from recent ERP disasters (Lidl, National Grid, Waste Management etc), it is that these failures happened before those systems went live. Compare that with, for example, the Hershey debacle (now frequently used as a case study in how not to implement ERP) and it would appear that at least some progress is being made in that, although companies are still wasting prodigious amounts of money on failed projects, they are not to the same extent suffering catastrophic failures in their daily operations as Hershey did.
They at least recovered from their experience but a lot of smaller companies don't and that leads some people to shy away from the big bang approach that Hershey felt forced to take. It might appear obvious that going for a phased or incremental go-live is the best choice because it is less risky but even that approach has its pro's and con's. Arguments for it are:
But, countering that, there are problems with a phased approach:
A look at those points in detail to gauge their possible effect on implementations may be worthwhile.
One obvious disadvantage of a phased approach is that the benefits of having a company-wide integrated system are delayed. A phased implementation can mean a doubling or trebling of implementation time; sometimes more. That means that the increased efficiency that justified the expenditure on the software will not arrive for months or years later than could have been the case. Things will happen in those intervening months or years: members of the implementation team will move on, other projects will start up and will compete for money and resources, new managers will come in with different ideas and will want changes.
More damagingly, people will get tired and it will get harder and harder to keep the enthusiasm and the momentum going. The implementation will be in real danger of just fizzling out before it is completed, and companies will be left with half a system and a forest of spreadsheets and other manual systems. Frequently there will be no formal decision to halt the implementation and it may even become a cozy institution, with some team members happy to continue having regular meetings in a comfortable room with coffee and biscuits even though nothing results.
Increased costs will be experienced in several areas. Companies are going to have consultants around for much longer. True; there will be fewer of them on site at any one time but, if they are there a long time, having them around can become a habit that is hard to break. There will always be opportunities to find them more to do and, believe me, they will be actively looking for more work themselves.
Another thing to consider is the cost of having key people tied up on the project for longer than is necessary. Even if it is only a case of missed opportunities to use them elsewhere, there is a cost.
Re-work is another consideration. The longer the project goes on, the more chance that new managers will come into the company with different ideas on what is required. And alterations during the latter stages frequently mean that work done in the early stages has to be revisited and revised.
Leaving the big one until last; the costs incurred in running two systems is obviously greater than running one. There may be continuing support charges on the old system and hardware. There will definitely be greater data entry costs, as many transactions cross departmental boundaries. For example, if the first phase of the implementation is the financial area, companies may be raising and receipting purchase orders in their old system and processing supplier invoices in their new. None of these problems is insurmountable but all manner of interim manual procedures will have to be put in place to keep both systems synchronized. These procedures will require extra work and, inevitably, extra staff.
One last thought on phased implementations. In a phased implementation, it usually makes sense for the financial ledgers to go in first. Even if care is taken to ensure that the finance department does not have a disproportionate influence in the way the system is set up (and it is very difficult for the lead department not to have a disproportionate influence, regardless of which department it is), there is a very real danger that the rest of the company will see it as being primarily a finance system.
So, as can be seen, the choice is not always straight-forward and what is best for one company is not necessarily best for another. Off course, no system should ever go-live without rigorous and complete testing (when we say 'system', we include in that the processes, procedures and people elements also) and without a fall-back plan if something serious and insurmountable unexpectedly occurs. But, before making the decision, companies should think things through carefully and take all the advice that they can get. Nobody wants to be the next case study in failure.
