Call for IT Devil's Triangle research
My previous post discussed the IT Devil's Triangle, which offers a general principle explaining dynamics that contribute to failed IT projects. In a comment to that post, Vinnie Mirchandani correctly suggests the framework could be improved by quantifying levels of responsibility among IT Devil's Triangle participants.
The IT Devil's Triangle states that most IT implementation projects include three primary participant groups: enterprise customer, system integrator, and technology vendor. Since each of these groups has its own definition of success, conflicts of interest based on 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.
In his comment, Vinnie calls for distributing specific responsibility for failure among Devil's Triangle participants:
In insurance they apportion loss and blame across multiple parties. Can't you do that after years of studying the subject.
A model that quantitatively links IT Devil's Triangle participant contribution to project success and failure would be helpful to the industry. In general, most studies today describe project management practices that lead to failure, but I am not aware of a predictive model that quantifies the role of IT Devil's Triangle participants.
Linking buyer, vendor, and consultant responsibility to project outcomes could be expressed in this form:
| Project result: | 75 percent positive |
| Relative Contribution: | |
| Enterprise buyer | 33 percent |
| Technology vendor | 33 percent |
| System integrator | 33 percent |
Update 2/2/10: In a comment on the Enterprise Irregulars blog, industry expert Dennis Moore proposes a method for thinking about the research problem discussed in this post:
There are a number of statistical methods you could use if you have a large enough data sample – where “large enough” gets even larger when there is a lot of variation in the data, as I’m sure you’ll find in this data set.
You could also use an approach where you first study a number of real projects, identifying in each case the actions that contributed to failure. Just identifying them and attributing them to the erring party could help progress this discussion. For example, the vendor was at fault for not better controlling the promises made by the sales reps. The sales rep was at fault for making claims s/he did not know to be true. The customer’s IT shop was at fault for not verifying the accuracy of the sales rep’s claims. The customer’s purchasing group was at fault for not writing all requirements into the contract. And so on …
Fault is subjective in a complex situation like an IT (or other business process change management) project failure, unlike the simple (simplistic?) case of a car accident. In the case of the car accident, there are very clear laws/rules, generally a very small number of responsible parties involved, generally objective facts that can be proven or at least inferred with a high degree of certainty, generally very clear costs, and generally very clear outcomes. This subject area is just a little more complex – no clear rules, often very large number of responsible (or irresponsible?) parties involved, few objective facts, unclear costs, and unclear outcomes.
Go for it, Mike! Your research is important to the industry.
Please share your thoughts on quantifying the IT Devil's Triangle.
[Image from iStockPhoto.]