The ERP Project Plan Trap
Friday, February 08, 2013
I have recently visited a new client who has asked for an evaluation of their ERP project plan prior to committing to the purchase of software. This client has read about the disasters experienced by many organisations and obviously wants to ensure they don’t fall into the same trap.
A very quick look at their project plan highlights the typical problem organisations fall into with their ERP projects. They see ERP as a technology project and the activities centre around the specification, demonstrations, purchase and implementation of ERP software.
The non-software issues of management acquisition rationale, risk assessment, education, business case etc., have all been glossed over with motherhood statements with little understanding of the impact some of these areas can have on the success of the project. The software company has said the package complies with the functional requirements of the company but no model has been produced or been tested against to ensure the functionality actually fits the business.
The budget makes a number of assumptions in terms of activity and time that has not been tested with the reality of the work that has to be done internally. In addition a go-live date has been mandated based upon new financial year for the company and again assumptions are made that the work will be completed.
The interesting part of this is again the software house that wants to sell them the package has agreed to the budget and the go-live timing as they feel to propose an alternate will jeopardise their sales prospects. Timing and budgets are a major factor in legal action against software providers agreeing and then not delivering.
This scenario highlights the many issues facing organisations wishing to embark on an ERP project! The involvement of the software house too early simply means you join the software house agenda and their end interest will not be yours. Software salesmen’s job is to sell you software and then move on to the next customer. The legacy of whatever promises they make on functionality, implementation time etc., is left to others to deal with. The nice salesperson has gone and you are left with reality.
In short we have run a gap analysis on the 26 steps to an ERP project and they are now putting the software purchase on hold to ensure the other non-software issues are resolved before they move on to software acquisition and implementation.
Management now agree that they were vulnerable to an ERP failure even though they thought they had all the issues covered.
The only unhappy people are the software sales people who will have to now simulate their product through the newly developed model and details of how the company wants the function to work.
Contact us for details of the “Self- Assessment” process.