Who is actually accountable for the success of ERP projects?

Michael,

Unfortunately, many project managers become scapegoats when projects fail…hence the fear.

The executive/business sponsor should be held accountable for the failure, even if the PM is incompetent and/or waited until the project was beyond resuscitating (incompetent), since the executive sponsor should have interceded by coaching or removing the PM. The executive sponsor should never be surprised when a project takes a bad turn. The executive sponsor’s responsibilities include defining the project, funding the project, resourcing the project, managing project risk, change management and more. The executive sponsor should be very visible to the stakeholders, business and IT teams during each project phase. After all, it’s the executive sponsor that wants to impress the board with the ROI numbers when a project is successful.

As for CIO’s having short tenures in some organizations, there are many reasons. From a personal perception, I think IT consistently sells itself short by talking about “IT alignment with the business” as if IT is not a business function. As long as IT continues to communicate to other business teams that IT is not a business team, CIOs will continue to be “outsiders” in many organizations.

Concerning project management, CIOs need to help the business understand that all projects are business projects. IT people should lead very few projects outside of pure infrastructure work. The ERP, BI, process improvement, CRM, SCM, etc. initiatives, while involving many IT components, are business initiatives/projects. A business leader should be the project manager while an IT project leader helps manage the project technology components.

Michael, you are correct about the level of complexity, still when all is said and done, the executive sponsor is accountable for project failure (or success). An effective leader would accept responsibility for the failures but share the responsibility for successes.

Thanks!

Mike

Bill, I completely agree it is a difficult question. Absolutely, I agree that ultimately the buyer is responsible, because good or bad, it is the *buyer's* project in the end.

However, that is not a satisfactory answer for two reasons:

1. What do we mean by the "buyer"? Is the economic buyer, who writes the check? Well, probably not, because that means procurement or finance, and certainly they don't know the functional requirements. How about the CIO? Well, what about the lines of business. Yuck, it's a big mess.

2. In general, buyers don't have the experience or information that the software vendors and SIs possess. Except in the largest organizations, the vendors actually are more knowledgeable than internal folks. But still, the customer must be responsible because he or she pays the bills and made the decision to buy.

Like you, I just don't have a good answer to this conundrum of a question. I think there is no single silver bullet that can solve all these problems, but instead it requires multiple groups to work together to a common goal. Unfortunately, poor communication and politics sometimes conspire to prevent project success.

For all these reasons, aligning goals for the project and facilitating good communication are critical components in the overall chain that leads to success.

I always enjoy hearing your views, so thanks for contributing!

Mike, While I appreciate your point that the buck stops at the executive sponsor, why do so many project managers fear for their professional lives when delivering the bad news about late or over-budget projects? In addition, how do you explain the short lifespan of CIOs in many organizations?

I'm not meaning to give you a hard time, but I see lots of complexity in these situations! Please share your thoughts.

Michael,

The buck stops at the executive/business sponsor of the project.

Thanks!

Mike

Just to add to the thought process -- I have seen that in situations where ERP / any enterprise system implementation has been a reasonable success has come out of the client organization looking at the enterprise system implementation as just one part of a larger business initiative whereby they land a sponsor / lead for the initiative from the Business at large. Organizations where this does not happen expose themselves to failure of the enterprise systems implementation. Considering that a large part of the organizational impact out of enterprise systems are reflected at the operational - business process level, the operations head of the organization should be squarely responsible for such projects and hence their success or failures. Buy?

Thanks for the feedback... I've been toying a lot with the idea of Risk - Reward sharing arrangements that are spelled out through a contract. Just not sure what might be an optimal structure.

Like you however I agree that vendors and SIs tend to have the upper hand in their ability to work the arrangement. When you combine that with most customers do not do a thorough job of defining requirements and then managing the RFI / RFP process it is even more difficult...

It appears safe to say that after 20+ years of experimentation...ERP is a cluster*%#@. Think of it this way: I want to paint a room in my house. If my house is ERP I have to start in the basement. I have to identify the supporting wall that keeps that room upright. Then I have to identify all of the plumbing and electrical that run near that wall. Then I have to identify all the adjacent walls. Once I've gathered my requirements, I have to excavate the wall that supports the room. Since it was built to sustain 1 coat of paint I now need to fortify it to support two coats of paint...oh wait...the second coat is a different color...AND you are going to use primer? Oh boy...time and material. Months pass, I still want my builder white walls simply cream color and my contractor is telling me it will take longer and cost more. In the mean time my brushes and a couple of cans of paint sit idle. By the time they even consider excavating the wall cream is no longer my choice...I want blue.

Silly as this example is it correlates to any "cosmetic" change to an enterprise system. Is it any wonder that the project is doomed to fail. And guess who gets blamed...not the person who is choosing the color...not the person that sold me the house that requires excavation of the foundation anytime I want to paint a room....the PM. That dumb, poor bastard couldn't manage his way out of a paper bag....

This is why IT is the Dept. of NO! Simple, innovative and even seemingly cosmetic changes gut the foundation of the house. $250B a year spent on enterprise IT...for this? No wonder the average age of an ERP is 11.5 (average, mind you). No wonder the initial project costs, budget overruns and delays cause the IT department to shudder any time anyone shows up with a color sample. Maybe I should try this with my wife the next time she says...you know what would be pretty?

I learnt the six most important words about projects 15 years ago from a very wise man. They are "Never work harder than your sponsor". I now realise that the business sponsor I had at the time (for a large company wide transformation) was by far the best that I have ever had. I have had less than a handful of good business sponsors in all those years.

So, I agree with the various comments above. This is complex, there is no silver bullet, it is more art than science, and always situational. I would therefore be wary of consultants walking in with methodologies and prescriptive solutions.

As a CIO I nearly always work harder than my sponsor (working harder in this context is about commitment not effort) because I want to ensure that the business benefits are realised even if I am not accountable for them. Again, this is situational as I have learnt that I have to, occasionally, manage my boundaries and observe the looming train wreck. I don't find this at all easy to do but you cannot always fight other people's battles.

One thing occurred to me today. The issue of accountability should be an early and initial discussion by the steering committee participants.

Then, a second tool I think would make a HUGE difference is something I used to think was a little silly--, a RACI chart. That RACI chart would have all of the project deliverables, spelled out from start to finish of the project, and the Responsible, Accountable (or approval), Consulted, and Informed stakeholders / participants.

A couple of major problems I see in all of these projects are around improper (or lack of) expectation setting and a lack of clarity around deliverables / accountability / execution activities.

While this may not resolve all of the issues it will certainly provide more clarity around responsibility, accountability, and project success.