'Pain chains' and the IT Devil's Triangle

The IT Devil's Triangle binds together enterprise customers, technology vendors, and system integrators in an unholy trinity that leads directly to failed projects. These failures are fraught with "pain chains," a term used by Altimeter Group partner and enterprise strategy analyst, Ray Wang, to describe clusters of difficulty that cause angst between IT customers and their line of business counterparts.

The pain chains concept recognizes that the organizational impact of IT failure is multi-dimensional. Similarly, the Devil's Triangle states that broad, rather than narrow, conflicting agendas among the trinity of customers, vendors, and integrators cause failure.

• Related: Exploring the Devil's Triangle

The shared themes of interdependence, shared responsibility, and impact characterize both pain chains and the Devil's Triangle. Therefore, I view large, serious IT failures as a constellation of dysfunctional activities that come about from overlapping, conflicting, and distorted relationships.

In some cases, inexperienced customers bring higher cost and waste upon themselves through sheer mismanagement of their own affairs. Other times, unscrupulous external consultants or software vendors take advantage of the customer's lack of experience.

Either way, in the aftermath of failure it's tempting and easy to unfairly shift blame onto one party or another; however, such finger pointing often ignores shared and inter-dependent causes of failure.

Here are three examples that illustrate no-win situations spawned by the Devil's Triangle:

1. Software vendor's sales person promises something the software actually can't do.

Potential solution: Directly ask the software vendor for specific examples of organizations where it has successfully deployed the features in question. If you're buying software based on certain key features, perform plenty of due diligence on that particular functionality. Unfortunately, it's sometimes a practical impossibility to learn the truth about specific points of reliability until after you have bought the product.

2. System integrator makes technical scoping errors that remain undiscovered until mid-project.

Potential solution: To avoid such mistakes, try to define your requirements with greater accuracy (but I'm sure you already tried your best on that front, anyway). In general, try to keep the project scope tight, because larger projects are always more at risk than smaller ones. You can also hire independent experts to verify major project decisions before moving ahead. If may drive you batty to pay one expert just to check another's work, but that's why they invented auditing. In the end, however, the truth about bad scope decisions often don't emerge until after it's too late.

3. Customer's culture and IT capabilities are not up to the task.

Potential solution: You've hired the right resources, ensuring everyone involved has the correct technical skills, and still your project gets screwed because IT just doesn't have the chops. When you're done cleaning up the mess, it's likely you'll find the solution by looking in the mirror. Yes, if you hired them, then perhaps it's time for that refresher course on planning and executing projects. This might also be a good time to dust off the resume, because you may need it soon.

========

I asked Bob Warfield, HelpStream's CEO and a longtime enterprise expert, to comment on these examples:

In my mind, there are no easy answers to reducing these failures except to be a lot harsher on the initial project scope. Most of the big projects are trying too hard to boil the ocean because it is not politically sound to say "no" to some constituency. It's all too easy to say "yes" when the sales guys and the fancy architectures are telling you, "Yes, this is software, anything is possible." Sure, that may be true, except for shipping that customized software on time or within budget.

My take. Pain chains and the IT Devil's Triangle make clear that failure is typically a partnership in which numerous parties share ownership. Blindly casting blame may feel good or be politically expedient, but does nothing to explain why a project really failed.

It's far better to dissect, as dispassionately as possible, the true causes of failure to accurately understand where things went wrong. Although difficult, that's the best method to prevent failures from occurring in the future.

[Image from iStockPhoto.]