Blog

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:

• 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.

What’s your opinion?