By Vjekoslav Babic, NAV Consultant, Microsoft Services

Why are ERP projects so often so disruptive in organizations that are otherwise accustomed to managing and planning all variety of marketing and manufacturing projects?

The reason is simple: companies implementing ERP don't specialize in project management, and they rarely have a dedicated or a formally trained project manager. They are also purchasing products and services that they often know little about, and effectively they don't do project management in its traditional sense.

Companies that have no project or project management experience are by large functional organizations, which is by itself a risky environment for projects. But with ERP, the risk is multiplied, because ERP projects are almost exclusively cross-functional and they span several functions at the same time. All disadvantages of functional organization structure come screaming at you:

  • Nobody has (or wants) full responsibility for the project.
  • Needs of a single department often overshadow the needs of the whole business.
  • Cross-functional issues rarely have an owner, and often end up not being taken care of at all.
  • The project is out of focus, since each department is primarily concerned about their own work.
  • People involved in the project lack motivation, because the project is their secondary responsibility. They are often measured for work performance, and rarely for project performance.

(A perfect storm, eh?)

Typically, the problems come to a head when the organization implementing ERP spends several times as much time on a project as the consultancy: one consultant often works with several users, and for one consumed consultant/day the customer spends several man/days of their own effort. The inevitable disruption occurs at three levels:

  • Daily routine: this is obvious. People have to spend their time doing project work. They have to engage in activities outside their normal work duties, which take away a significant amount of their time. Yet, they frequently still have to do whatever it is they are normally doing, requiring a lot of extra effort from them. So, their daily routine is disrupted and their productivity plummets.
  • Mindset: functional organizations don't know how to manage projects and execute project work, yet they do majority of project work. They don't know how to do project accounting to measure productivity and project cost performance, and they must ensure project ROI. They don't know how to organize, or even how to establish and manage cross-functional reporting structures. Many organizations can't handle the necessary change in mindset, which sometimes results in confusion, and sometimes in outright obstruction.
  • Outcome: finally, when ERP is ready to go live, total disruption often happens, because the cut is made, and users get out of their comfort zones all at once. Trainings are nice, but when you get to run the new beast live, especially if it required change in the way how you do business, total confusion can happen.

I may be totally wrong, I haven't built any roads or researched cure for AIDS after all, but I believe these disruptive elements rarely happen, or at least rarely come together, in many other project disciplines. ERP projects put enormous pressure on organizations which don't specialize and don't have (enough) experience in projects. Ignoring the disruptive nature of ERP projects can easily lead to failed projects.