Vetted IT negotiations reduce risk of project failure

By Linda Tucci, Senior News Writer 11 Mar 2008 | SearchCIO.com

IT news and analysis for CIOs Digg This!     StumbleUpon     Del.icio.us

More on IT management CIOs must say no to generic IT Risky business: Talking to your company's lawyer

"Technology acquisition is fundamentally flawed," said technology attorney Erik Phelps, a featured speaker at last week's Fusion 2008 CEO-CIO Symposium, where some 250 IT and business executives convened for two days to explore business and IT alignment.

By the time the papers are signed, the air can be so poisoned it's hard to see how the two parties can work together for the next 18 or so months. Yet they must, if the project has any hope of success, Phelps said. And if it does fail, as some 25% of IT projects do (according to various studies) fingers will point in all directions: The vendor overpromised, the integrator didn't know the business, the software was buggy, the customer requirements were incomplete, the project lacked sponsorship, project management was incompetent.

"It is not just the 'bad vendor' who sells the software; often it is the bad customer who isn't going about the procurement process very well," said Phelps, who specializes in IT and Internet-related matters at Madison, Wis.-based Michael Best & Friedrich LLP and served as associate general counsel at clothing retailer Lands' End Inc. before that.

Changing how the deal goes down, he argued, improves the acquisition process and minimizes the project's risk of failure.

The first step in improving the acquisition process is to know the kind of deal you want before you start, Phelps said. Not surprisingly, he recommends that CIOs get their lawyers in the game early.

By the time lawyers are usually called in, it's too late. "You can't chunk up a deal to reduce risk," he said. If terms can't be changed -- and many times they can't for publicly traded vendors required to report material changes -- the deal could collapse. "Time and money are pieces that are hard to recover late in the deal process," Phelps said.

Standardization

CIOs standardize IT processes. The technology acquisition process should be standardized, too, Phelps said. Come up with a "relatively standard" form that captures the information you want to communicate in your requests for information and proposals (RFPs). Standardize your professional services requirements from third parties, for example, and your maintenance development standards.

"There is no vanilla RFP," Phelps said, and terms will vary from acquisition to acquisition. But a well-thought-out standardized document provides a solid base for customizing requests.

Your RFPs should ask meaningful questions, including information you wouldn't hesitate to seek from peers. One question for vendors Phelps said he always includes: Have you ever failed in implementing these products you propose, and, if so, describe the nature of the implementation failures. "You'll get some duck-and-dodge answers, but ask," he said.

Good RFPs shrink the negotiation time. If the vendor doesn't like the way you acquire professional services, for example, tell him to mark it up and send it back, Phelps said. "Your first set of documents is already done."

The integration clause

Many times, vendor proposals will come back with the pricing stuck in an appendix or with boilerplate license agreements and license schedules. CIOs should require a "soup to nuts" response that accurately captures the entire deal, Phelps said. "If there are seat restrictions, process limitations, if there are other license restrictions, you need to know what they are."

Phelps also recommends what he concedes "is a very controversial" requirement: He advises you tell vendors that their RFP answers will be included in the final agreement.

It is not just the 'bad vendor' who sells the software; often it is the bad customer who isn't going about the procurement process very well. Erik Phelps attorney, Michael Best & Friedrich LLP

"I can't tell you how many times I have sat down with CFOs, CIOs, CEOs, and I ask them what they think they are getting from the deal. 'Oh, they did this great demo, they walked through all our use cases, they demonstrated all the functionality, it works just like we want.' And I flip through the miscellaneous sections of the agreement and read them the integration clause: 'This document is the entire agreement of the parties; all other prior proposals, documents, et cetera, et cetera, are excluded in their entirety from the agreement document.'"

"Great demo, great proposal, absolutely meaningless from a legal perspective in holding the vendor's feet to the fire," Phelps said. "Why do you go through the RFP process if the deal has to be renegotiated?"

If you want to be a good customer, don't sugarcoat and don't hide. If your requirements change after the proposal goes out, go back to the vendors and restructure the process, so the proposals you get back are "deals that have a shot at getting done," he said.

And -- very important, in his view -- CIOs should allow vendors to propose changes. "Rely on their expertise," Phelps said, adding that some of the best projects he's seen have been the result of "hybrid" proposals.

Finally, deals don't have to take forever, he argued, offering as evidence a recent $1 million software license deal for a major financial services implementation that he worked on just before his wife was due to deliver. A C-section was scheduled for a date in late December, after which he was out for the year, he informed the vendor. The deal had to get done by that Thursday. No one else was available? the vendor asked. Nope. The decision makers from both sides met and the agreement was signed "before two o'clock," Phelps said. "These deals are not rocket science."

Sound Off! -   Post your comments |  See others' comments (2)

Tags: Contract negotiations and legal issues,  Leadership and strategic planning,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us