Vendor Management: Making Sure Your Contracts Are Realistic to All Parties Involved
Thu, September 15, 2005
CIO —
A close friend who works for a global marketing company serves on the executive committee that oversees the design and rollout of an enterprise personnel system. The deployment, which will affect scores of the company’s subsidiaries, is running late and over budget. Everyone is frustrated, and the situation is getting worse. Surprise.
My friend and I mull over the corporation’s ulterior motive for the system: to consolidate and centralize all of the company’s HR functions. A couple of cheap but clever technical fixes suggest themselves. The best thing about the fixes—besides the price—is that they’ll be easy to test. My friend presents the ideas to her committee. She expects sighs of relief and a welcoming reception.
Doesn’t happen. To the contrary, the vendor throws a fit. Cheap and clever technical fixes are seen as diabolical and subversive threats. What’s more, the vendor insists that those kinds of technical fixes violate the terms of the contract. Although vendor "consultants" grudgingly acknowledge that they can’t possibly deliver anything near what they’ve promised anywhere close to on time or on budget, the contract ostensibly forbids this non-source-code-touching intervention.
My friend is incredulous; I’m merely disgusted. I’ve seen this before. So what’s happened? The CIO, in cahoots with the CFO, has negotiated a contract that is all about cost savings and service-level agreements (SLAs) and completely disrespectful of what it takes—and what it means—to implement a working system enterprisewide. The CIO has cheated and betrayed his people by committing his company to a contract that treats implementation as essentially irrelevant to how the system ultimately performs. That’s unprofessional and contemptible. It’s also shockingly common.
Surely you aren’t one of those oh-so-Olympian CIOs who view implementation as something that the little people may have to worry about but that is far too tactical to occupy the time and negotiating savvy of a C-level executive? Surely you aren’t a business leader who believes that implementation is simply the "black box" means to the end of accomplishing cost savings and SLAs? After all, we’re not negotiating these multimillion-dollar global contracts for the purpose of promoting happy implementations but for the goal of satisfactory results.
CIO Eyes Wide Shut
The reality is that too many CIOs cut enterprise deals that may look absolutely fabulous to the CEO, CFO and all the other C-creatures, but commit the people who do the real work to a nightmare of unrealistic expectations and milestones. The contract undermines the ability, ingenuity, creativity and initiative of people to do good work. The contract focuses on ultimate results at the expense of the healthy and coherent processes necessary to achieve them.
In short, too many CIOs and CFOs negotiate IT contracts with vendors as if the process of implementation is completely disconnected from the quality of the system that is actually deployed. This is particularly acute in outsourcing deals that trumpet cost reductions and so-called airtight SLAs. These CIOs and their colleagues believe that, so long as the vendor and the system comply with the SLA, everything will be hunky-dory. Who cares if the negotiated contract gets in the way of clever innovations that can slash time from schedules or money from budgets? If you’re a professional, you should.
One financial services company I know builds into its contract the provision that if it is experiencing the risk of a delay, it has the right to force the vendor to bring in a senior partner from one of the systems integrators for two weeks or until the problem is resolved—whichever comes first. For obvious reasons, the systems integrators and their senior partners take great pains to make sure that this option need never be exercised.
By contrast, a pharmaceutical CIO who negotiates hundreds of millions of contracts with outside vendors has put himself in the position where, by contract, his vendors don’t have to perform timely upgrades if their software touches open-source systems.
The vendor rationale? They insist that since open source isn’t formally tested, they’re entitled to wait and see how it works with their software before they help the onsite team do an upgrade. In other words, the presence of open source dilutes the SLA. Needless to say, the pharmaceutical IT employees who actually make the systems run are sick and tired of this arbitrary constraint.
To be fair, the SLA focus is understandable. In the first and final analysis, organizations want measurable and repeatable results. But for mature adults to actually negotiate contracts in which process quality is divorced from quality results is simply delusional. It flies in the face of everything we know about human behavior and systems deployment. Valuing good outcomes over good process guarantees that you’ll get neither.
To my disgust, I’ve observed CIOs who have grown so divorced from the implementation process in their own organizations that they don’t think twice about the implementation implications of the IT contracts they’re negotiating. Implementation? Not their job, man.
Sadly, the CFOs and CEOs typically understand (and appreciate) so little about what software design, testing and deploy-ment mean operationally that they can’t tell (and don’t care) how a contract can undermine what they say they’re trying to do.
Yes, many contracts have milestones, which serve as metrics surrogates for good process and good implementation, and these milestones must be met. But, frankly, they’re cop-outs for lazy CIOs. CIOs who truly care about leadership (and their people) will seek to negotiate contracts that explicitly empower their people (and their vendors) to be more creative and innovative.
CIOs have an affirmative obligation to prevent IT contracts from becoming straitjackets for the people who have to implement the technology.
I’d like to see more CIOs circulating their next-to-final-draft vendor contracts with their implementation and project leaders. The goal would be to solicit useful comments and actionable ideas on what impact the agreement would have on the ability to implement a system that delivers the desired SLAs. This "implementation impact statement" could—and should—be both a powerful tool for savvy negotiators and, just as important, a document that gives the organization real insight into its implementation strengths and weaknesses.
If your organization consistently confronts implementation impediments with its IT vendors, the real source of the problem may not be the quality of your people or your processes but the quality of the contract you negotiate. Involving your implementers in your negotiations may turn out to be the smartest kind of delegating you can do.
