The Elephant in the ERP Room: What Makes Implementing Big Projects So Risky?

July 14 2009

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.

About Vjekoslav Babic

Vjekoslav Babić is an independent Microsoft Dynamics NAV consultant, trainer, author and blogger, with 10 years of experience in NAV and 16 years of experience in IT.

As a solutions architect and a project manager with a leading Microsoft Dynamics President's Club service provider company, as a Microsoft Dynamics NAV consultant with Microsoft Services, and as an independent consultant, he has been working on Microsoft Dynamics NAV implementations ranging from tiny one-man-bands to international mega-corporations, delivering services and trainings all over the world.

In 2008, Vjekoslav co-authored the acclaimed book "Implementing Microsoft Dynamics NAV 2009". Vjekoslav runs an active blog about NAV implementation, project management and development best practices, acts as a columnist and editorial advisory board member at MSDynamicsWorld.com, and as a columnist in a number of other web or printed periodicals in Croatia and worldwide. Vjekoslav is also a frequent speaker at Microsoft or Microsoft Dynamics conferences.

Since spring 2010, Vjekoslav has been awarded the prestigious Microsoft Most Valuable Professional (MVP) award for Microsoft Dynamics NAV.

More about Vjekoslav Babic

Comments

axone's picture

Some good points made, however when looking at the title of the post, it seems to me that its fairly obvious why ERP projects, big or small are so risky. The deeper the cut (ERP GO Live), the bigger the risk of the operation going wrong. Perhaps, the ERP go live phase for most projects should be more incremental, I.E more like a series of mini GO Lives, rather than the Big Bang that we all seem to use.

MattKeyes's picture

Comments are spot on here and have been part and parcel of my experience. However, I think it is always advantageous to offer a positive with a negative - i.e. how can a company with a new ERP implementation overcome this? Outsourcing project management? Training PM in-house? Etc.. etc... pros and cons of both.

mohtarahul's picture

For large (risky) projects, it is good to have a number of leaders in the team. Philosophy I agree with: Leaders are like BINARY :):) Managers are like ANALOG :) Cheers!!!

dbaker's picture

This describes the "Perfect Storm" that I've been witness to in my only implementation experience thus far. I wouldn't be surprised if this happens more than you think (though I hope that is not the case). In addition to the disadvantages of a functional organization you mention, other contributors to the risk in our experience have been as follows: 1. Intention of the ERP implementation. Why are we doing this in the first place and is the reason a sound one? The implementation of the project was solely by IT. There was very little responsibility by other departments. Because of some (or all) of the reasons you mention (e.g. needs of a single department overshadowing the whole business), the driving factor for the implementation was for IT benefit, not necessarily for the whole business. The business was never ready for change. As a result, the (positive/negative) way the system impacted other departments came up after implementation because they were minimally involved in the first place and they were not prepared to change. 2. Lack of trust in consultancy. I got the impression that some in our organization became disenchanted with consultants due to some experiences we had with them in the past. As a result, more work was attempted in house. Of course, this interfers with our day-to-day responsibilities. Additionally, our collective internal ERP experience was relatively minimal compared to what might be expected of a consultant so there was some obvious suffering there. My feeling is that for a new ERP implementation, a key understanding of what the business wants from the system is needed. Also, management needs to be very much involved so that they can delegate work and dictate change. Change should be a key motivator for implementing ERP and as such, a change management process should be firmly in place before delving into ERP. Do not get into thinking that just implementing a system will solve problems. By understanding (and avoiding) the risks and perils of other implementation experiences, you will be much better off in the end.