How Many IT Projects Have Built-In Conflicts of Interest

Failure in IT projects is a much written about topic, and an all-too-frequent experience for technology and business professionals.

There are many competing factors: There are budgets to maintain, schedules to manage, personalities to handle, resources to share and shifting priorities to organize. Most of you live and breathe it every day. It's complex, requires strong leadership and a tough constitution. Experienced technology veterans expect some amount of failure in the largest and most complicated projects.

Have you ever wondered about the competing interests that may be at play? You hear about it in some construction and subcontracting projects, in government-funded projects that are stretched out so that hourly billing and cost overruns are maximized. Some use it to take advantage of the delta between things being completed and not. Your company needs and wants the work completed so you are not going to stop the work. But you may pay for it, and pay for it dearly.

For larger software or new system projects, there are often outside vendors and system integrators involved in the implementation or key development pieces of the project. These outside dependencies may have a lot more to do with your success than you'd like, but are often required since they have the kind of experience in integrating that you do not have internally, or cannot take them off the core mission of the project for integration purposes.

One individual shedding light on the subject of conflicting interests is ZDNet's Michael Krigsman in his post "Exploring the Devil's Triangle."

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

This isn't to suggest that all vendors or integrators are trying to run up their fees and costs, but it is something to consider when you add up all the elements in measuring project failure. Remember, once you're nearing project completion and are heavily invested, integrators and vendors know they have you in their bubble of influence.

Where are you going to go at this stage of the game? Your company is invested in the success of the project and the first milestone is its initial completion. You need them.

The best ones are going to consider your budget and needs and work with you to get your project done right. Yet, the bad projects can lead to some very uncomfortable and potentially legal issues that no one wants to see.

Krigsman explores the conflict a little more in depth.

"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 integrators 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."

Has your company dealt with a bad integrator or vendor in a project? Without naming names, how did the company manage and resolve it?