The IT failures blame game (part 1)

The IT failures blame game (part 1)

Summary: Few subjects are as controversial, emotionally charged, and fraught with misunderstanding as establishing blame for failed IT projects.


This is part one in a series on understanding blame in IT failures. Please also read part two.

Few subjects are as controversial, emotionally charged, and fraught with misunderstanding as establishing blame for failed IT projects. Unfortunately, because of high costs associated with IT failures, some folks use misplaced blame as a competitive weapon to gain negotiating or political advantage.

Of course, no one wants responsibility for causing the large economic losses and associated legal risks that arise from failed IT projects. Therefore, project participants often use blame to obscure the truth of why projects really fail, hoping to redirect responsibility from themselves by shifting fault to others.

Since finger pointing plays a central role in obscuring the true causes of failure, the study of blame is a worthwhile topic for discussion.

The IT Devil's Triangle. Enterprise implementation projects virtually always involve three parties: customer, technology vendor, and system integration consulting firm. We call this triad the IT Devil's Triangle, because relationships among these participants simultaneously involve shared goals mixed with conflicts of interests.

These relationships become dysfunctional when project participants focus on their own goals to the detriment of shared project objectives. From this perspective, we can say that late and over-budget projects result when competition overrides cooperation among project participants:

The Devil’s Triangle explains how economic pressures can drive software vendors and system integrators to act in ways that do not serve customer interests. It also offers insight into the ways some enterprise software customers damage their own projects.

Projects succeed or fail based on how Devil’s Triangle participants manage built-in tensions among themselves. The likelihood of success increases when the three groups align their individual goals and expectations in a spirit of cooperation and mutual benefit. Conversely, implementations fail when greed, inexperience, or arrogance emerge as prominent motivations and one party attempts to gain unreasonable advantage of another.

In his book Why New Systems Fail, project failures expert and author, Phil Simon, explains why the Devil's Triangle is a powerful tool for parsing relationships on IT projects:

[Each member of the Devil's Triangle] has its own agenda and goals during an IT project; often the goals of each do not overlap sufficiently, increasing the risk of finger pointing and ultimately a failed project.

In his second book, The Next Wave of Technologies, Phil calls the Devil's Triangle is a "vicious cycle." I asked him to describe the broader industry context into which the Devil's Triangle fits:

I have seen The Devil's Triangle in action many times as a consultant and have written about it in my books, blogs, and longer pieces. Twelve years ago when I started working on system implementations, the notion surprised me. A bit naive, I couldn't believe that everyone wasn't on the same page.

Fast forward to 2010. Now, I'm surprised when I don't see it. It really comes down to basic agency theory. Vendors, consulting firms, and clients each have their own agendas. In a perfect world, those agendas would entirely overlap and IT project failure rates would not nearly be as high as they are. While not exclusively the cause of so many botched IT projects, I can tell you from personal experience that The Devil's Triangle causes inter-party conflict. It creates certain issues and exacerbates others.

Understanding the causes of failure is a foundation element for running successful projects. The Devil's Triangle encourages all parties to acknowledge their responsibility and contribute to overall project success.

This post is part one of two in a series on understanding blame in IT failures. Please read part 2 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
  • Scapegoats rocks!

    Who doesnt want to find a good scapegoat when something goes south?
    Tommy S.
  • RE: The IT failures blame game (part 1)

    Michael, although I like the Devil's Triangle concept, it seems to be a bit limiting as it relates to project environments where these specific triangle participants actually exist. The reality is that projects fail in other circumstances, when run internally to organizations and no extenral vendors or consultants are present. The devilish aspect of the analogy is nevertheless correct as this little devil resides in each and every one of us and when disaster strikes the most natural reaction of self preservations kicks in. In such cases each stakeholder will take actions aimed at putting the blaim on someone or something else. We are all just little devils after all, aren't we?
  • Blame is Proporitional to Project Tragedy

    The intensity of finger pointing is probably proportional to the size or impact of project bust. My guess is if your project is over budget, or overshot the delivery date by 15-25%, but either delivers what user?s want or close to it, there isn?t much bashing or pointing of fingers.

    Projects that blow up, usually leave a trail of blood through the majority of the project. The solution provider feels like they?re eating the job, the software vendor has been pilloried, the implementation provider feels caught in a vise and that they're also eating the job, and the customer feels like they?ve been hoodwinked and robbed? even driven to the brink of going out of business. Every body is trying to defend themselves and everybody is attributing blame to someone else.
  • Build the past into future projects

    Be prepared and build the finger pointing and blame actions into future projects as active checkpoint lists to minimize failures, finger pointing, blame etc. and see them tread water if a failure occurs

  • RE: The IT failures blame game (part 1)

    Good points as well in the comments.

    Yes, I have seen internally-run projects fail. I'd argue that those are at least less likely to combust because there are fewer players and management teams involved.

    I've also seen first-hand "slight failures" result in much less finger pointing. As @elizb points out, blame is proportional to tragedy.

  • Collusion to Mask Project that are not outright failures

    The flip side of the blame game is that manager and consultants seem to conspire to market projects they were involved in as far more successful than they actually were. It is in their interests to talk up their success. So unless the project was an outright disaster, the project is chalked up as a success and everyone moves on with out the appropriate review and assessment taking place. Too many false positives prevent companies learning from their mistakes and getting value from their consultants.
    Jenny Sutton- Co-author of Extract Value from Consultants
  • India, Inc. is to blame

    Companies ruined or almost ruined by India, Inc.:

    AirBus (Qantas plane plunged 650 feet injuring passengers when its computer system written by India disengaged the auto-pilot).
    Sun Micro
    Bell Labs (Arun Netravalli - head, closed, turned into a shopping mall)
    Quark (Alukah Kamar CEO, fired)
    Skype (Madhu Yarlagadda fired)
    MIT Media Lab Asia (canceled)
    Intel Whitefield processor project (cancelled, Indian staff canned)
    Apple R&D CLOSED in India in 2006
    ComAir reservation system
    Boeing Dreamliner ILS and collision detection software (written by HCL)
    Lehman (Spectramind software bought by Wipro, ruined, trashed by Indian programmers)
    Dell, United, Delta call centers (closed in India because Premji's conmen don't even know how to use telephones, let alone computers)
    HSBC ATMs (software taken over by Indians, failed in 2006)
    AIG (signed outsourcing deal in 2007 in Europe with Accenture Indian frauds, collapsed in 2009)
    Qantas - See AirBus above
    State of Indiana $867 billion FAILED IBM project
    World Bank (Indian fraudsters BANNED for 3 years because they stole data).
    Let's talk about foreign-born founder startup Caymas - Indian CEO, French director of dev (Pierre Rafiq), and Chinese tech lead (Jeff Kaan). They got loads of America's VC money and hired lots of developers from China, India, Viet Nam. After 5 years of draining all this capital, the money ran out and Caymas went BELLY UP. One more fake immigrants startup that FAILED and wasted America's captial. Now that money is all sitting in foreign banks because the foreign guest workers sent all their paychecks home. No wonder our economy is such a disaster.
    I could post the whole list here but I don't want to crash any servers.