Evaluating the enterprise software buyer's 'Bill of Rights'

Complicated relationships between enterprise software buyers and vendors contribute to late, over-budget, or otherwise painful IT projects. To help customers bring greater transparency to their relationship with software vendors, Forrester Research analyst, Ray Wang, has developed a detailed framework covering the ownership life cycle.

A document called An Enterprise Software Licensee’s Bill Of Rights, V2 describes this framework. Although the bill of rights does an excellent job explicitly highlighting issues that can become points of contention between software buyers and vendors, it does not address customer roles and responsibilities in achieving project success. This gap is significant, as I discuss below.

Software Ownership Life Cycle. The report defines a software ownership life cycle and provides a checklist of issues keyed to different life cycle phases.

The life cycle horizon extends out over a decade, accurately reflecting the long time spans over which some enterprise software contracts extend. One of its most valuable features is raising concerns about intangible considerations that don't come into play until years after a large software contract is signed.

This graphic shows the life cycle:

Bill of Rights checklist. The bill of rights guides customers to raise key points when negotiating with vendors. The next diagram organizes this checklist by life cycle phase. The first step, general rules of engagement, outlines overall expectations of vendor conduct across the entire term of the software business relationship.

THE PROJECT FAILURES ANALYSIS

This bill of rights is a conundrum to me:

• On one hand, it protects buyers from strong arm (and sometimes downright sleazy) vendor tactics that take unfair advantage of customers' dependence on installed systems.
• At the same time, it blankly ignores the customer's role in making software projects successful. Pushing all blame onto vendors can easily backfire and actively create project failure.

Devil's Triangle. I often use the IT Devil's Triangle concept (see here and here) to help explain why some projects go wrong:

Virtually all IT projects involve three parties: customer, technology provider, and integrator. Each of these groups has its own independent set of goals, which leads to a series of interlocking, overlapping, and sometimes mutually exclusive agendas. Customers want low prices and top-quality work; consultants seek high margins and large projects; and technology vendors often bow toward system integrators since consultants are a source of vendor deal flow. Understanding why IT projects fail requires analyzing relationships among these three groups.

Many IT failures result from self-inflicted wounds that customers and vendors perpetrate on each other:

Greed, arrogance, and inexperience are the essential trio driving many IT project failures. Bring this set of factors together, and failure is practically inevitable. All too often, vendors and customers angle to get as much as possible out of each other, ignoring the fact that fairness and mutual respect are the true building blocks upon which successful projects are created.

By bringing transparency to the vendor side of the triangle, the bill of rights helps interrupt the cycle of failure, despite not closing the gap completely.

Customer responsibilities. The bill of rights does protect the customer, which is the stated aim, but only covers half the territory needed to produce successful projects. Although the report does not advocate that customers deny their own responsibilities, I am concerned some may inappropriately use the bill of rights as an excuse to do just that.

I brought these concerns to Ray Wang, author of the report, who agreed that customers share equal responsibility for creating successful projects. Ray commented:

A vendor's bill of rights would also be useful. It should cover things like the customer meeting agreed upon milestones and deliverables, supplying qualified staff, and so on. I don't want to let vendors off the hook, but customers must play an equal role in making the relationship work.

I also asked Ray to comment on vendors' reactions to the bill of rights:

In general, software vendors are supportive because it helps them reduce sales cycle times and avoid customer satisfaction issues in the long run. Not all vendors are thrilled that we have the best practices here, but in the end, everyone benefits from a non-Caveat Emptor environment.

My take. Customers and vendors can both learn from this bill of rights. Relationships are successful when all sides recognize and respect the others' legitimate rights and responsibilities.

Enterprise software relationships governed by mismatched expectations result in failed projects, legal battles, and negative profiles in this blog. The bill of rights can help both parties avoid misaligned expectations and resulting conflict.

However, buyers that use the bill of rights to evade their own responsibilities or screw their vendor are distorting the intent and creating downstream failure for themselves.

Despite the significant caveats, I recommend that customers adopt the bill of rights as an educational tool to help raise awareness of important issues during critical negotiations.