Many project management authorities assert that from project management stance all projects are equal. I dare saying that some projects are more equal than others.
In my last post, I argued why I believe software (and ERP) projects are different. But something came to my mind today, and it’s really an important differentiator of ERP projects from other kinds of projects.
When I was attending my PMP course last year, there was a lot of confusion in the audience about the position from which PMBOK addresses some project management activities, especially about procurement management.
Much procurement management activities are focused on acquiring products or services from external parties. This almost unilaterally places the bulk of project management on the party to which in the world of software or ERP implementations we refer to as the customer.
However, what happens far too often is that the bulk of project management activities happen almost exclusively on the side which we call the implementer, the partner or the consultancy (my preferred term), in any case on the side which PMBOK mostly refers to as the seller.
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 climate, eh?)
With ERP, the level of involvement of the organization which in fact often doesn’t even know how to run projects is significant. The organization implementing ERP spends several times as much time on 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. In fact, consultancy is merely the facilitator of the process which happens inside the customer organization.
So, what happens when ERP projects come along? Disruption.
Disruption happens at three levels:
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.
What’s your opinion?