There's no such thing as a free lunch
Uppdaterad: 19 nov 2020
ERP & Friends has a lot of experience from implementation projects with huge problems in regards to not reaching go live dates or overran the project budget. We have been engaged in such projects in late phases where our assignment has been to turn around the project to a success. So far, we have been successful in our assignments.
In a series of articles I will give you true stories including our findings, actions and lessons learnt. We hope these learnings will help you in your work to succeed with your implementation project.
ERP vendors use different methods in order to win business from you as client. No matter which product they are selling.
ERP vendors know that apart from functionality which supports the clients business, good references are sometimes crucial to get the deal. All large ERP vendors on the market support most business processes. There are of course exceptions also her but in general, this is true.
But other factors might have a big impact as well. Project cost is one such parameter, knowledge about the clients specific industry is one other. If the vendor’s delivery organization has knowledge about the specific industry then the quality of the delivery will be increased.
A true story about trying to get a "free lunch"
In this article I will tell you a true story about a company who wanted to implement a new ERP solution at minimal cost. We can call the company for Terra AB. It’s a well-known company in Sweden with a reputation of manufacturing items to customers with very high quality. Their items are expensive but customers who wanted quality was willing to pay the price.
Terra AB contacted a number of ERP vendors and after an internal validation of three quotations from the three vendors on the short-list they decided to go for the cheapest offer, Oneerp Ltd, which is one of the top six ERP vendors in the world.
Oneerp Ltd wanted Terra AB as customer mainly because Terra AB was associated with quality and had a strong brand. They offered an implementation project to a cost which was close to zero. Their idea was to staff the project with trainees, which participated in a trainee program and wasn’t budgeted for any revenue.
Project team selection
Terra AB assigned the CFO, Carl, as their Project Manager. Carl was very busy with his normal duties but expected the vendor to drive the project. Carl was told that Oneerp Ltd. have their own proven implementation methodology, which contains a huge amount of document, processes and plans. In addition Oneerp Ltd. has many clients from the same industry as Terra AB.
The project started but after the configuration was done and Terra’s process owners got to see the solution a lot of gaps was identified. Solution of each gap was discussed and often the solution was to customize.
After some time Carl understood the project would not meet the scheduled go live date. In addition his project members complained about the solution, which according to them will not support their needs. Carl became very upset and asked for an extra Steering Committee (SC) meeting.
Call in the help!
I was asked to audit the project in order to understand what had gone wrong. Below are a few of my findings;
The consultants, who were all trainees, had used many more hours than budgeted. Their manager had ignored this because Oneerp didn’t expect any revenue from the team.
The PM from ONEerp was experienced but recently employed. He didn’t know much about the implementation methodology used by Oneerp and nothing about the software he was implementing.
Terra’s PM Carl (the CFO) didn’t have enough of time for the project; in addition he lacked knowledge about running an ERP project (or any project). He didn’t allocate much time for the project.
Many of the solutions for the newly identified GAPs could have been solved by standard but the trainees didn’t have enough of knowledge about the software or any industry specific experience. Further, the trainees listened too much to the client’s process owners instead of going back to their more senior colleagues for support.
Several of the customizations didn’t meet the client’s expectation.
Based on my findings I created a list of proposed actions, which I presented for the SC;
The client PM must dedicate time for the project, every week.
The vendor PM need a QA resource to support the PM
Senior business consultants were assigned as mentors to each trainee
One Technical Project manager was assigned to set up a customization process and ensured this was followed by both the client and the business consultants.
Change management activities were planned in order to mitigate the risk of unnecessary customizations
The project plan, customized based on the clients situation, needed to be updated according to proposed changes.
What can we learn from this project? I have below highlighted a few of the learnings;
Cheap is not always best. There are no free lunches.
The client is always the owner of the project and must take responsibility for plans, quality and change management.
The client project members must have dedicated time for their involvement in the project
Scope and business objectives must be very clear to make the right expectations for the customer's employees.
The project must have expertise in the specific industry. It’s not enough the client have it, the vendor team members must have as well. Always ask for CV on all team members. You must ensure the consultants have the expected knowledge.
Proof of concept, business impact analyses prior to the project start is mandatory. Identified GAP’s late in a project always cause problems and very often also delays and unforeseen cost.
You’re welcome to discuss this with me in this forum, mail or in a meeting. ERP & Friends has a lot of experience from projects which have almost failed, been stopped etc. We have been asked to help in such situations and so far with very good result.