'Pain chains' and the IT Devil's Triangle

'Pain chains' and the IT Devil's Triangle

Summary: The Devil's Triangle and "pain chains" bind together enterprise customers, technology vendors, and system integrators in an unholy trinity that leads to failed projects.


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.

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

Topics: IT Employment, CXO, Software

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
  • RE: 'Pain chains' and the IT Devil's Triangle

    Mike, you have been saying this for years. This is like going to every crime scene and blaming the victim, someone close to the victim and a suspect. In insurance they apportion loss and blame across multiple parties. Can't you do that after years of studying the subject.

    If I was hazard a guess it would be SW Vendor 30, SI 60%, buyer 10%. The reason i allocate less to buyer is often it is a life event for most of them - they don't do it every year. If they make bad decisions the vendor and SI should slap them around, or resign the account. SIs claim to have done it thousands of times, and they say that in their proposals. SW vendors obviously know the product cold.so, the onus of blame should go higher to them
    • Apportioning responsibility

      I love the idea of apportioning responsibility based on some formula or allocation.

      Honestly, I've not given thought to quantifying responsibility that way. However, based on your excellent suggestion I will think about it. Please let me know if you have any ideas on that topic.

      Personally, I'm not prepared to make allocation assignments based only on a blind guess. However, intuitively, I would agree a larger burden likely falls on the SI -- if for no other reason than SI compensation increases when problems arise on a project.

      At the same time, however, I would probably disagree on the extent of the customer's role in creating these situations. To what extent I'm not sure, which is why I need to consider your points and think about a framework for allocating responsibility.

      I suspect the framework may need to include a taxonomy of different kinds of failures, since the relative allocations of responsibility would certainly not be the same in every case.

      Thanks for commenting and raising great points.
      • Statistical Approach

        Take a statistically significant sample of IT project failures. Say, [i]n[/i] = 1,000 projects or more.

        Analyze each project with a peer review group of at least ten members.

        Have each member allocate project failure responsibility percentage to customers, vendors, and integrators in the project.

        Average the results for all ten members and all [i]n[/i] projects. The results would be the broad answer.

        You can expand the complexity by including a taxonomy of failure modes.

        However, I consider the result either way meaningful only for understanding how to plan risk management.

        The only meaningful way to analyze project failures for lessons learned to ensure project success is to analyze the business processes and engineering processes from project conception to project delivery - at the very least.
    • You Two Have Two Valid, but Different Points

      I think it?s important to make the following distinction:
      * Each (vendor, implementor, and Client) is a valid source or a driver of failure

      * For whom should we have the most compassion or understanding if we consider whom should know better given their deep knowledge of the technology or extensive expertise with business implementations?

      I think Michael is speaking to the first point, whereas you are speaking to the second point.

      Neither point negates the other.

      Both are valid, and I?ve seen the first point first hand and definitely have felt empathy with the Client a la the second point.

      I've seen clients ignore good advise, make bad decisions, possess unrealistic expectations, and embark on IT-enabled change initiatives with the assumption that they can force elements of their ecosystem (over which they have no control) to change behavior. I've also seen solution providers accept unrealistic (and unreasonable) missions so as not to loose a contract. Just as I have seen vendors press on to sell a poor fit, in order to meet quarterly and yearly revenue goals.

      But I've also felt for the vulnerability of the Client, especially those companies that have little and limited experience in implementations, who often:

      * Have no idea how clueless they are

      * Don't understand the issues, even if vendors, implementation partners, or consultants caution them against some idea and explain why

      * Don't know how bad the ramifications could be

      * Have blind trust in their "hired" experts and those experts aren't telling them the "truth"

  • RE: 'Pain chains' and the IT Devil's Triangle

    The SI partner is going to assign as many people and bill as many hours possible to each project. The SI will bill until you make them stop. The SI partner sells solutions but really all they're looking for is billable hours - as many billable hours as possible. This triangle of forces ensures failure has no clear definition - and regardless if your project fails or not, 2000 billable hours is anything but a failure. The current model is completely backwards, making failure the norm rather than the exception. The current model also brings economic value to the vendors before, and regardless of, the customer's ROI. This makes the transition of partner firms to service providers rather than product vendors incredibly valuable to each business and our economy as a whole.
    • Hiring the wrong SI

      I think you are hiring the wrong SI. Find a good partner like the one that I work for that does 90% of our work fixed bid.
    • This View Neglects

      the factors of failure versus success in determining a company's reputation.

      A company in any business that establishes a consistent track record for failure does not attract repeat or new business.

      The fact that 68% or IT projects qualify as failures is the result of bad business and engineering processes, as I have commented several times in Michael Krigsman's previous blogs.
  • RE: 'Pain chains' and the IT Devil's Triangle

    Allocation of blame varies by project. Hard to
    generalize a formula or ratio. Too many variables
    across SW vendor, SI vendor & customer.

    Best solution is to change the economic incentive for
    the SI from maximizing billable hours. Fixed price is
    the way to do this. Requires project to be scoped
    adequately in order to arrive at fixed price. This
    aligns all 3 parties (SW vendor, SI vendor & customer)
    interests. This forces SI vendor to assign qualified
    individuals to project and not use it as a vehicle to
    train staff or avoid staff on bench.

    If SI vendor can't provide a fixed price, either
    1) the project has to be scoped more thoroughly, or
    2) SI vendor isn't confident in their and/or customers
    • Firm Fixed Price Requires

      a thoroughly specified product before the price can be determined. The customer must therefore pay for requirements specification, decomposition, and allocation before a cost is assigned for the remaining design, development, integration, and system test work.

      The developers and integrator must also play hardball in firmly specifying cost and schedule increase for every requirements change. But requirements changes frequently result from increased understanding on everyone's part as development progresses.

      The bottom line is that "firm fixed price" is really not logical in sound engineering practice. There must always be allowance for cost increase or the customer will not get a system that meets the customers' needs.
      • Agreed

        When it comes to enterprise software implementations, "fixed fee" isn't going to fly. A iterative process is required because tools (applications) and perception change one another.

        Fixed fee projects would certainly be possible in SMB accounts but common practice is to add 25 to 50% or more to any fixed bid to account for the increased risk to the SI.

        If you have a good relationship with a SI partner then certainly keep it going. When it comes to enterprise IT teams - the teams are in constant flux. A tough project 3 years ago often means little.

        I don't think anyone is truly to blame. It is the system that is broken - most players do the best with what they have to work with. There is a great deal of economic benefit to be had in improvement.
        • I'd like to discuss part of your reply

          Clearly we agree nearly completely. But I may have a slightly different perspective on one small comment you make:

          "[i]I don't think anyone is truly to blame. It is the system that is broken - most players do the best with what they have to work with. There is a great deal of economic benefit to be had in improvement[/i]."

          There is indeed tremendous economic benefit in improvement. A report from the Department of Commerce National Institute of Science and Technology back in 2002 concluded that software errors cost the US nearly $60 billion a year:


          Such a social cost is utterly staggering and begs the question of why it is tolerated.

          I am disinclined to accept the notion that "it is just the system." It should be the responsibility of every systems and software professional to understand the various processes, methods, and practices of their profession, grasp their strengths and weaknesses, and seek every opportunity for improvement.

          A project manager I once worked for presented an orientation for all new staff working for him. The very first slide of that presentation decalred in big bold letters:

          [b]The only one who can make a difference is [u]you[/u].[/b]
      • Fix Price Does Not Guarantee Satisfaction...

        Fix price does not guarantee satisfaction with a deliverable. All it does is fix your costs [i]as long as you don't change your mind[/i] as to what you want or need.

        If what a client thinks it wants today, will be what it wants 12 months from now, 24 months from now, or 36 months from now, then we're assuming:

        * That the client fully understands what it is that they're asking for and how that functionality will fit into the typical work flow of daily tasks

        * That the business or operating conditions that warrant the application or functionality today will still prevail at the time the application is complete and in use

        * That the priorities of the business and user will be unchanged for several years

        I think most anybody would say that these conditions haven't existed in decades.
        • I Agree Completely

          Re: "[i]I think most anybody would say that these conditions haven't existed in decades[/i]."

          At least, those who comprehend engineering.

          All human exchange brings new understanding - of ourselves, of each other, and of goals initially set. The art of engineering is to enter into a shared effort that produces a product that meets the needs of some set of people within bounds of cost and schedule acceptable to the program's customers.

          All of this within a social context in rapid flux.

          I see two extremes in basic philosophy for approaching the social problem of engineering:

          One mindset declares, "We don't have time to nail down exactly what we need to do! We're on a tight deadline here!" This is the approach used by many companies in diligent pursuit of failure.

          The opposite extreme asserts that thoroughly understanding the goals of the program and the system requirements are essential prerequisites for meeting deadlines within budget. This is the practice used by companies like Praxis High Integrity Systems to great effect.
    • Fixed-fee can work, but ...

      ... it shifts all of the work for crafting the solution up front.

      Many customers are not aware enough of their own organizations to make all of the correct decisions up front. Because of fixed-fee billing structure, the SI may be forced to push the implementation of the system [b]as designed[/b] rather than [b]as needed[/b].

      An integrator is more like a sherpa guide and less like a ski lift. An integrator can give you guidance, assess your fitness, make recommendations, draw you a map, and help you over the rocky terrain. But in the end, you still have to get to the top of the mountain yourself.
  • RE: 'Pain chains' and the IT Devil's Triangle

    A good example of this is this weeks win by BSkyB against
    EDS (Now HP). The original project was about ?48m for the
    implementation of a CRM System, the damages to be awarded
    are in the region of ?200m. Full story below:


    I agree with Bob re Scope, however - this takes time and
    you also need to work with the right people with the right
    attitude. Should you decide to spend weeks/months in
    scope, you delay your benefits case so its a tough call.
    if you can break down the size of the problem to bite size
    chunks, or use a agile delivery.. The key for me is to
    take action. Doing noting is not an option.
  • one potential solution

    Really good post, Michael.

    As you point out, different incentives of each party are at the heart of much of the conflict on large IT projects.

    Epicor in November introduced a new program called Shared Benefits, designed to align incentives of all involved.

    I did a podcast with its VP of services, Craig Stephens:


    I'll be very interested to see if other vendors enter into similar agreements with the clients to minimize project risk and the chance of failure.