An ERP Implementation project has an equal chance of success or failure in the beginning. What makes it go well and what makes it go bad?
There was an interesting post about the evils of ERP Consultants on ITToolbox: Are Some ERP Consulting Firms Crooks?
Reading it, you understand why so many ERP projects fail. It seems like that is all people talk about are the failures in ERP project implementations. Is it really the consultant who makes it fail? I think the real question is “who really runs the ERP implementation”.
If what you read in the above mentioned article holds true, then there should not be any successful implementations. I take a different stand and believe that most ERP consultants, and their firms, are trying to do the right thing, there are, however, circumstances that derail a project. Further, I believe that it is the customer’s responsibility to stand up for their rights and protect their investment.
When initiating the project, it is important that the project team interviews each of the consulting team’s staff-members around their experience and their ability to deliver in the role slated. If at any point in the project, you feel that any of the consulting team members are not performing or are being difficult to work with, bring it up to the consulting project manager or the firm’s account manager. They have a vested interest in you getting along well with the team so that the project runs well. Sometimes success or failure is a matter of personalities.
Frequently, ERP implementation projects are run by the consultants who drive it based upon a methodology that has worked for them in the past. It is usually a derived form of Initiate, Design, Build, Test, and Cutover. These five steps have been used in variation for decades now. The methodology has moved from being a rigid waterfall method to a more agile iterative approach, but it still follows the same theme.
If consultants follow the same methodology (in one form or another), why do some projects go well and why do some fail? I believe the answer lies in the project governance. Who manages the project? Who takes ultimate responsibility? What is the culture of collaboration? These are all key questions that need to be addressed before the first day of the project and readdressed along each status meeting.
My experience has shown me that projects that go well are the projects where the client “owns” the success of the outcome, along with the consultants. If the client is not “bought into” their own success, then how can the consultant drive the project to success?
At the same time, there needs to be collaboration. The value of consultants is the experience they bring in executing implementations over-and-over. The consultants will tend to drive the project based on their methodology and their experience, however, the client needs to step up and ask “why?” and “how?” Then they need to assess if it is a sound direction. They need to either accept the recommendation, or push back if they think it will not work for their company.
A professional consultant should listen and explain their reasoning. It should not turn into an ego-fest of who knows best. Rather options and solutions should be presented. A lot of this collaboration depends also on the people involved in the project. Within the same implementation team, you may have a driver style personality who sees all client requests as out-of-scope and must push for a change order. At the same time you may have collaborative team members who gets what the client is asking and realizes that the request is part of the iterative process of reaching a desired solution.
A skilled project manager negotiate with the different personalities and must make the decision to determine where the solution is going. Is it outside the bounds of the work agreement? Or, if by following that path, will it lead to a joint success. This can only be reached through meaningful discussions.
There are consultants who focus too much on billable hours and not on client needs. There are other consultants who focus on client needs only and as a result blow-up the budget. In both cases, the client needs to call foul if they see project effort going too far in the wrong direction.
On a recent project, a client realized that the technical development was over engineering the solution. The client is not technical, but could see that the solution presented was too much for the goal. Working with the consulting project manager they refocused the team and got things back on track.
Bottom line, if you as the client are not collaborating, and working through issues daily with the implementation consultants, you will be driven to a solution that is not one of your own choosing. On the other hand, if you drive the project with too much zeal and force, you may miss the valuable design experience that the consultants bring.
The success of the ERP project weighs as much on the internal team and their project manager as much as it does on the consultants. Where projects go bad, it is often due to the lack of participation of the implementing company’s team or the lack of direction from their project manager. In these cases, the consultants end up driving and will likely make system decisions based on experience, but not based on the operations of the company. So if you want to have success in your ERP implementation, you must own the project and work collaboratively with the consultants each and every day.
