The IT failures blame game (part 1)

By Michael Krigsman | March 8, 2010, 4:48pm PST

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.

Related: Exploring the Devil's Triangle

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.

***

The IT failures blame game (part 2)

By Michael Krigsman | March 8, 2010, 4:55pm PST

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:

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

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