X
Business

Exploring the Devil's Triangle

The Devil's Triangle describes a basic set of dysfunctional relationships that push many projects toward failure. Although I've written about this important topic before, today's post summarizes the issue succinctly.
Written by Michael Krigsman, Contributor
istock000008722906xsmall.jpg

The Devil's Triangle describes a basic set of dysfunctional relationships that push many projects toward failure. Although I've written about many facets of this important topic previously, today's post summarizes the issue succinctly.

Three parties participate in virtually every major software deployment: the customer, system integrator or consultant, and the software vendor. Since each of these groups has its own definition of success, conflicts of interest rather than efficient and coordinated effort afflict many projects.

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.

Devil's Triangle relationships are a short sighted and self-interested way of life for too many participants in the enterprise technology landscape.

Schizophrenic software vendors and split loyalties

Of course, software companies want to sell product licenses to end customers. However, the vendor's loyalties are sometimes unclear, because system integrators influence many software deals. As a result, although the customer buys the license, the system integrator may have a closer relationship with the vendor than does the customer. Although the customer is certainly important, some integrator offer a critical source of deal flow to the vendor, making the integrator a key part of the software company's sales process.

Who wins when a software vendor's loyalties to the customer conflict with its relationship to the system integrator? No doubt, it's an interesting question.

Wacky system integrators: billable time vs. customer success

When a project goes over-budget, the customer pays much of that extra cost to the system integrator in the form of additional services fees. In the best cases, these fees enable the service provider to perform additional, high value work improving business outcomes for the customer despite the higher cost.

System integrators sometimes have a dual incentive to build long-lasting customer relationships while racking up change order fees if the project runs late. Sometimes, this situation creates an negative incentive pushing the integrator away from the goal of completing the project on time. For these unscrupulous consultants, unsuccessful projects represent "annuity consulting" revenue coming at the customer's expense.

I have described this conflict before:

In private moments, many third-party consultants dream of long projects, where billable hours and customer purchase orders flow like water. This kind of annuity consulting is never good for the ERP buyer. Almost by definition, when projects exceed their schedule and budget, the extra dollars go into the consultant's pocket.

Confused buyers: Silos, internal conflicts, and cynicism

Although it's easy and tempting to blame software vendors and integrators for all failures, technology buyers can create their own downfall.

Some customers take unfair advantage of their integrator during the initial bid process by pretending that a poorly planned project is well defined. This causes the integrator to base the bid on incorrect assumptions presented as fact during initial meetings with the customer. Manipulating the integrator in this manner causes downstream problems and disputes when the project inevitably goes off track. Although few customers adopt such a blatantly cynical attitude toward vendors, varying degrees of the same syndrome causes many failures.

Projects can also fail when a customer organization has internal conflicts and disagreements that surface during the implementation process. For example, the accounting department may specify business requirements that are not practical from a technology perspective. At the same time, the IT department may not completely understand the accounting department's business goals. As a result, the customer gives the system integrator conflicting instructions, eventually causing the integrator unplanned and perhaps unnecessary rework. Despite clear fault, some customers in this situation unjustly reject the integrator's request to charge for the extra work. This scenario can set in motion a sequence of events leading to dramatic disputes and major failure.

THE PROJECT FAILURES ANALYSIS

Although it can be difficult and awkward to discuss these negative relationships, to achieve success we must recognize that conflicting goals do exist.

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.

My take. The best software vendors and integrators go far beyond the call of duty to assist their customers. Likewise, smart technology buyers respect the experience of their external consultants and compensate them fairly. Beyond vendor compensation, however, technology buyers should strive to surface hidden expectation mismatches among internal groups -- but that's a subject for another post.

The key to success: help your business partner achieve his or her legitimate and reasonable interests. If all project participants did that, there would be no need for an IT project failures blog.

[This post is based on my presentation, CRM failure: An ounce of prevention, and on a book chapter I wrote for inclusion in The Next Wave of Technologies: Opportunities from Chaos.]

Update: Argentinean IT consultant, Carlos Francavilla, translated this post into Spanish, which you can read here.

Editorial standards