One of the constant complaints we see and hear about IT is the inability to complete projects, or having projects that fail to meet business goals and expectations. Many support professionals are well acquainted with the world of project management, and, in addition to Maurey Wolk’s focus book on the topic (Project Management Essentials: A Guide for IT Service and Support Professionals), I believe it’s a great idea to get some perspective from one of the best authorities on why projects fail, Michael Krigsman. In this post, Michael describes the factors that can push a project over the brink, and has sage advice for avoiding them. It’s a tour of his “Devil’s Triangle” of project failure. That post is reproduced here with his permission. —Roy Atkinson
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 is helping 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.