ERP Disasters - Finding the Culprits
Friday, June 28, 2013
With so many ERP projects running into problems the natural tendency is to find someone to blame. We have discussed on a number of occasions the interaction of the three main parties; The ERP software vendor, the software implementers (project managers) (a division of the software vendor) and the end using client. The term used to describe this is the “Devils Triangle,” each party has direct involvement in the implementation process and has a direct impact on the success or failure of the project.
The software house, whom the buying client relies on for expertise, responds to a request for quote or to a requirements document by submitting a proposal for a solution. The client, after discussions, selects a package based upon the proposal and subsequent discussions with the vendor agrees to the project.
The software implementer’s project manager assumes guidance for the project, based upon their expertise in implementing ERP projects alongside of an in-house project manager appointed by the implementing company and prepares a project implementation plan typically part of the software vendors claimed “Proven Path” methodology.
The ERP client formulates his own internal project team, under guidance from the vendor‘s project manager and the project commences in accordance with the plan.
In the beginning a lot of goodwill exists and the project commences and all appears to be going well. A few issues along the way that are resolved are to be expected and the progress reports all indicate the project is proceeding in accordance with the plan with the end golive date being maintained.
As the project progresses bigger issues start to arise that were not anticipated and that can carry a big price tag. These include software functionality issues, hardware issues, resource issues, disputes over what was in the contract and verbal guarantees given by the software salesmen at the sales stage but not documented, unresolved issues awaiting decisions from senior management and a general internal confusion over the direction of the project. At this point cracks start to appear in the goodwill evident at the beginning of the project and the project starts to become problematic and consumes greater financial and people resources than budgeted for or intended.
Typically implementing organisations take the view that they have sunk substantial amounts of money and resources into the project and have to continue but look for ways to take shortcuts to reduce the cost and impact on the company. By this time it is quite likely that the budget overruns are very significant and in many cases more than double and triple the original project budgets. This is typically a creeping scourge on the project and the costs build up over time until someone realises that the costs are out of control and raises the red flag of panic.
The customer, who always foots the bill now puts pressure on to turn the system on, even though it is not ready, in the belief that if turned on they can get some form of company benefit from the system. The resulting disaster of turning on a system that is not ready, hasn’t been properly tested or the work in data clean-up that has not been completed and checked now creates operational chaos that can literally financially wound or harm the company.
In some cases the company muddles on with the software getting little, if any benefit, from the software but feel locked in to using it whilst others simply turn it off and revert to their legacy systems. In the most extreme cases companies are operationally damaged to the point of bankruptcy.
Whilst all parties of the devils triangle are involved in the overall project one way or another it is the client who wears the ultimate consequences of whatever outcomes are achieved. To identify the reasons and culprits to assign some form of accountability is a difficult undertaking as fault can be apportioned to all parties. For many organisations they will simply write off the experience and make the best of what is a disastrous undertaking.
The reality is that whilst the client shoulders the ultimate outcomes for the project the other parties to the project, who had the expertise and the guiding hand on the project cannot simply wash their hands and walk away unblemished by the outcome. Most simply blame the buying company, point out their shortcomings and walk away.
Supplier expertise and proven path methodologies, touted at the sales stage, play a big part in the software selection process as the client has little or no experience in implementing ERP systems and relies heavily on the claimed expertise of the selling organisation.
In the post disaster wash-up of ERP projects the verbal guarantees given to the client but not contained within the contract are denied and the details in the contract, often vague are relied on as a defence against the hapless clients assertion that the software did not do what the seller said it would do.
Of course these details should have been spelled out in the contract but the point to remember is that the client is an in-expert amateur when it comes to ERP systems and has relied heavily on the expertise and integrity of the ERP software seller.
The up-side for aggrieved clients is that they can have their projects analysed to identify the many failings of the software company and their implementers against their own proven path methodologies as the basis for a mediated or litigated settlement or judgement against the vendor for failing to comply with their own undertakings against the project.
It is very pertinent that the client is not an expert and relied heavily on the ERP vendor and their implementing team to advise them on the implementation process and ensure the disasters do not happen.
With up to 70% of ERP projects failing to provide the expected outcomes companies are more likely to experience serious problems than successful outcomes and this needs to be taken into account for organisations undertaking or looking at undertaking an ERP project.
The construction of a model and detailed up-front requirements that the software is fully tested against before agreeing to buy the software is the best protection against the downstream problems outlined here.