The IT failures blame game (part 2)

The IT failures blame game (part 2)

Summary: Further explorations on assigning blame for IT failures.


This post is part two of a series on the role of blame in IT failures. Please read part 1 now.

Placing blame accurately. The IT Devil's Triangle explains that all major participant groups share responsibility for project success in a balanced way. However, some observers apportion blame for failure unequally among Devil's Triangle participants. Unbalanced distribution might make sense when analyzing specific projects, but it becomes misleading when applied as a general guiding principle.

As the Devil's Triangle principle makes clear, one-sided generalizations apportioning blame are rarely accurate. In my experience, having written about 800 blog posts on the subject, causes of success and failure are typically shared among the three parties.

To understand the customer dynamic, let's turn to Todd Williams, an IT failures turnaround specialist currently writing a detailed book on recovering failed projects. In a post called Blame the Customer, Todd presents a reasoned description about the role of technology customers in contributing to failed IT projects:

I am always amazed how people on failing projects neglect to look at their own issues prior to blaming someone else. Yes, blame is easy and on red projects since no wants to be the source of the issues. The truth is, everyone is at blame, so before bringing in an auditor or recovery manager, tidy up your house first.

To be clear, I am not suggesting that customers deserve more blame than either technology vendors or system integrators. Project success only happens when all three groups work together effectively.

In another of his posts, Todd discusses the role of trust in overcoming negative relationships spawned by Devil's Triangle tensions and conflicts:

When looking at the aggregation of failed projects, vendors, customers, and integrators share culpability. Commencing a recovery (or a project, for that matter) with anything but an objective view of the genesis of failures, or their corrective actions, is counterproductive. Every project is different and, in the course of recovering a number of them, no single party has come out the winner for contributing to failure. To be sure, as many projects fail for customer ineptness, arrogance or any other problem, as there are that fail for the same reasons in vendors and integrators. Starting any action with blame only breeds mistrust.

Hence, blame serves no purpose.

In my experience studying IT failures, objections to the IT Devil's Triangle typically come from those using blame as tool to further their own personal interests or political agenda.

These arguments against the Devil's Triangle usually come from two camps:

  1. IT Devil's Triangle participants blaming each other for project-related problems. When a project runs late or over-budget, the customer and system integrator may blame each other. Software vendors also sometimes engage in a  war of words over blame.
  2. Independent consultants using "discredit tactics" to sell services. These folks usually adopt the position that vendors or integrators are the primary contributors to failure and then build arguments based on that faulty premise.

Such unbalanced tactics do not help anyone uncover true causes of failed projects or teach them how to avoid failures in the future.  People who begin an IT failure analysis with a presupposition of blame are rarely interested in uncovering the truth.

Is assigning blame unreasonable? Some serious observers argue that technology-related failures are so complex that assigning blame is a meaningless exercise.

Well-known author, Malcolm Gladwell, writes in the New Yorker magazine that analyzing failure may offer little benefit toward preventing downstream problems:

Over the past few years, a group of scholars has begun making the unsettling argument that the rituals that follow things like plane crashes or the Three Mile Island crisis are as much exercises in self-deception as they are genuine opportunities for reassurance. For these revisionists, high-technology accidents may not have clear causes at all. They may be inherent in the complexity of the technological systems we have created.

IT failures expert and author, Rob England, echoes this view in a post on his IT Skeptic blog:

Complex systems are by definition broken. They will always break and sometimes they will break when everybody did what they are supposed to. Fixing the problem won't necessarily reduce the risk of another incident.

Rob references a paper called How Complex Systems Fail, that describes how inherent complexity drives failure, irrespective of blame. I wrote a summary of that paper, and commented:

Enterprise systems are inherently complex, often involving many business processes, people, and organizations across a company. Given this built-in complexity, it’s no surprise that failures abound; it’s amazing these systems function at all.

My take. Successful projects result when all major parties associated with a project accept responsibility for process, outcome, and delivered value. Projects succeed to the extent customers, technology vendors, and system integrators share these common goals.

This post is part two of a series on the role of blame in IT failures. Please read part one now.

[Disclosure: My company, Asuret, markets equally to enterprise technology buyers, vendors, and consultants. Photo from iStockphoto.]

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Don't Blame the Coachman

    First of all, let me salute Michael, one of the two people in the community (Phil Simon is the other) who put project failures on the map. At a time when most people had no idea that these things even happened, Michael was saying that projects do fail, that a lot of them fail, and that everybody is a participant. Deciding that enough is enough and that it's time to speak up is real leadership.

    Unfortunately, one of the troubles with having a good idea is that other people follow after you and want to improve it. I look at Michael's now-familiar Devil's Triangle, and I ask, "Can it be improved?"

    In the blog post that Michael is replying to (, I assert something that should be completely obvious: when a catastrophe occurs, it's possible that some of the participants are more culpable than others. When this does happen, I argue, it's important to figure it out, because in some of these situations, when people don't know who should be held responsible, they blame the wrong person, sometimes, as in the cases I give, blaming somebody whose contribution is minimal or even blaming the victim.

    So, while there is a Devil's Triangle, sometimes, one or more apices are more devilish than the others.

    That said, the really difficult question is, "How do you tell?" In the post, I introduce a concept that I call presumptive responsibiity. The people who have the most control over the final outcome are presumptively responsible, I say, and people who have very little control do not.

    Thus, even if World War I starts because a coachman took a wrong turn down a side street in Sarajevo, you don't blame the coachman. Sure, the coachman made an error, and sure it was material. But in the larger scheme of things, it was nowhere near as important as what the gunman did.
  • RE: The IT failures blame game (part 2)

    As a general statement, your "take" on things is accurate. But when something fails, a project or a bridge, assigning blame is part of uncovering the truth. Bottom line for me, the blame for the majority of ERP failures lies with the consultants.

    I was involved with SAP R/3 ERP implementations for several years. Initially, I was a member of a project team at a company implementing SAP. Later, I became a consultant and worked for three different small consulting firms that usually partnered up with larger firms on various projects.

    If I categorized the projects I worked on as successes or failures, I'd break it out in this fashion:

    One complete success; on time, on budget, with all the functionality that the customer wanted.

    One partial success; the system had all the features the client wanted but it came in slightly late and was probably over budget.

    The rest of the projects failed. One project was pulled during global testing; the consulting group was fired and that one ended up in litigation with a hefty award going to the client. SAP later came in and redid the implementation. Another company went out of business before the project really got going. Another project eventually went live with SAP but years after the original scheduled dates and with a much narrower scope than originally planned. The last project I worked on was late, over budget, and the company almost shut down in the months after go live because the shipping department didn?t understand the system and the invoices weren't processed.

    Where would I assign blame for the failures? Primarily with the consulting companies, the "system integrators" to use your term. SAP had its problems and I worked with it through releases 2.2 through 4.6 although I was only certified in 3.0 (Production Planning). The Finance modules were always good, but the Logistics modules in the early releases while useable, were not nearly as functional. You could see that just based on the thousands of OSS Notes for each release; it was not nearly as integrated a system as SAP liked to believe. Nor was it flexible; businesses had to change their processes to adapt to SAP.

    That being said, for the most part SAP had a hands-off approach to implementations. They supplied the software but partnered up with consulting firms to do the actual installs. I worked with Price Waterhouse, Andersen, KPMG and HP. The smallest project team I worked on had eight consultants; the largest had over fifty. I don't know what everybody else's billing rates were, but the last project I was on (2003), my rate was $1,200/day. Normally my final billing rate to the client was between $2,500 and $3,000 a day. That's a lot of money. I mention my billing rates because without fail, from the three companies I worked for, to the consultants I worked with that were from the larger firms, the emphasis was always on billable hours. It wasn't on project success; it was on making sure you got in 40 hours a week at the client site. And if the project succeeded or failed, when it was all over, those consultants rolled off that client and onto a new one the following week.

    The consultants themselves for the most part were young, college graduates. They were IT guys. Few of them had any practical experience in manufacturing, or any real world business experience. They weren't able to grasp the customer's requirements nor did they have the desire to get down to the shop floor to obtain information firsthand, but they were all portrayed as "SAP experts." And every job I ever worked seemed to be treated as a brand new project even though there was a wealth of tribal knowledge out there (lessons learned) that never seemed to get passed on. Downtime between projects was never used to any good purpose like making the next project run better.

    Were the customers at fault? Sure, but they had been led down that road to failure for the most part by the consulting groups who often set unrealistic expectations from the beginning. On more than one occasion, I saw project requirement that I knew were impossible but that had been promised by the primaries and when asked about it, their response was that they would customize SAP to make it happen-but of course that never happened.

    On the customer side, one of the biggest problems that they face when implementing an ERP system is resources; you have to have a lot of your people on the implementation team for a long period of time. How do you do that? If you put your best people on fulltime, who does their jobs while they are working the implementation? And if you replace them for the duration of the project, will they have a job once the project is done? If they go part-time on the implementation, how do you compensate them for working 60-70 hour weeks for perhaps a year? And if you don't put your best people on your ERP project, you start spinning your wheels because you can't get the requirements right or the answers you need. It's a problem, and very few customers handle it right, so you can always point a finger of blame there.

    Whether it was a fluke or not, the successful projects I worked on both had one thing in common; they had a mostly adversarial relationship with their consulting partners. They were clear about who the customer was and who the vendor was and weren't afraid to voice any displeasures about performance early and often. Both of them also knew from the beginning that SAP was a good fit; they had done their homework and their business practices were fairly solid.

    The customers on these teams also communicated well and knew why they were implementing SAP; what they hoped to get out of the new system as opposed to what they currently had. On the projects that I was on that failed, when I would ask the folks I was working with why they were implementing SAP, I would either get an "I don' t know" answer or that their bosses decided to do it and that was it. You could blame the customer for that, not getting their own people on board, but the consulting groups never seemed to think it was a big deal either and wouldn't encourage the customer to better explain to their employees what was going on.
    Anyhow, good post and I enjoy your blog-good stuff.

    Sorry for the ramblin'

    Phil G
    • My favourite business bugbear

      "[i]The consultants themselves for the most part were young, college graduates. They were IT guys. Few of them had any practical experience in manufacturing, or any real world business experience. They weren't able to grasp the customer's requirements nor did they have the desire to get down to the shop floor to obtain information firsthand...[/i]

      This is the main problem with most modern businesses (and Governments), "know-nothings with a degree". These "experts" won't listen to anyone who doesn't have a degree. Since they know nothing about the business and its requirements, projects they work on tend to fail.

      If the management admit, that the consultants they hired caused the problem, they "lose face". Thus blame is shifted to someone else (lower down the chain).

  • Six Phases Of A Project

    4-Search for the guilty
    5-Punishment of the innocent
    6-Praise and Honours for all non-participants.

  • Don't Blame Anyone

    So, you find the gunman and the coachman and execute them. Does it stop the war?

    Let's bring this down to something closer to what can happen to anyone of us in the next few days. Read this post: If I blame the Physician's Assistant, would that help? The cardiologist? No. I have one more story like this that did not end up so nice. Assigning blame will not bring my son back. Finding out what went wrong and determining the best way to keep it from happening again is the correct answer. Approaching it in punitive manner, threatening lawsuits, and the problem is less likely to be solved because people spend all their time and energy on defense and not on prevention.

    Since, in a huge majority of cases, what we are talking about has nothing to do with starting wars, or even threatening lives, assigning blame makes it less likely to find the real problem because people are going to try to obfuscate its source. There is a great quote from Henry Ford, "Don't find fault. Find a remedy." Finding fault and laying blame solves nothing, it slows the process of correcting the problem.

    Mike Krigsman has already made my view clear on where you will find the source of problems--across an array of projects the source is evenly spread between customers, vendors, and integrators. A vendor oversells what they have on one project, an integrator oversells what they can do on another project, and a customer oversells how much they know about the process they are trying to automate on the next. One project goes one way and the next goes another. If you want to blame SAP or an integrator for an install going bad and come to the rescue of the poor customer, I need to ask what rock that customer was hiding under to think it was going to be a cakewalk to install the system. Ignorance is no excuse. To carry the initial gun analogy further, if I buy a gun and accidentally shoot myself, then by the big-bad-vendor logic I should blame the gun manufacture. All I need to say is that I did not realize there was risk involved in having a gun.

  • Take 2

    I would think that you could call it assigning blame or failure analysis or whatever and it makes little difference. Whenever I've looked at the reasons for project failures, I haven't much cared for the "gotcha" game; I've tried to do so that I can learn from the mistakes. But the bottom line is the same; over the last 30 or so years, the majority of IT projects have failed for one reason or another. We never seem to learn cuz the numbers haven't improved much even though I'm sure much scholarly debate and research has been devoted to the issue.

    Should customers have a better grasp of their business, a firm understanding of their business processes and an appreciation for the fact that their software implementation is likely to fail before going ahead with it? Sure. On the other hand, who's been hired to install the system? Who's making pretty large sums of money right now to install the system? It's your consultants, your contractors, your system integrators, and those are the guys who are primarily responsible for the success or failure of any large IT project-in my opinion.

    Probably most of these projects should never be started. The business isn't ready for it, the software isn't going to do what it says it will, and your consultants won't be qualified to install it. I'm not an IT guy, but from my perspective something has changed in the last several years and not for the better. The first software project I participated in was back in the 80's when I was a material planner at a company doing $80 million a year in sales. We put in ASK ManMan in less than two months with one consultant who worked part-time. It worked fine; the business ran fine. That same type of implementation done today would probably take a year, require a team of contractors, and cost millions.
  • Management Accountability for Consulting Failures

    Companies dont seem to care about whether they get value from their projects and consultants - only if the project blows up and it becomes messy do they take any action.
    Why dont more managers feel accountable for getting value from their consultants - it seems too easy just to hire "know nothings with degrees" and then let someone else be on the hook when things go wrong.
    Jenny Sutton - Author of "Extract Value from Consultants"