The IT failures blame game (part 2)

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.

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

(Cross-posted @ IT Project Failures)