Home

Cover Story

Table of Contents

E-Newsletter

Article Archive

Editorial Calendar

Datebook

Writers' Guidelines

Orgs/Links

Opinion Polls

Reprints

Forum

November 6, 2006

Conducting Negotiations — 8 Things You Need to See in an IT Contract
By Elizabeth S. Roop
Radiology Today
Vol. 7 No. 22 P. 34

The ability to negotiate an IT contract that achieves both client and vendor expectations often lies within the most minute details of the contract itself—details that need to be worked out before anyone signs on the dotted line. And while the healthcare executives who sit across from IT vendors at today’s negotiating table may be more experienced than their predecessors, they are also dealing with more complex issues with the potential to impact every aspect of the organization. The obvious example in radiology is PACS’ growth beyond the imaging department.

“One of the most important factors that, in the long run, either creates a successful project or results in the failure of a project is establishing proper expectations going in,” says Michael McLeod, CPHIMS, president of McLeod CG, Inc. “That means making sure that the expectations the hospital has are well communicated and match the expectations that the vendor has so that the vendor clearly understands what [its] role needs to be, what the end result needs to be, and what the deliverables need to be. Proper management of expectations is absolutely critical.”

It’s a simple concept on the surface. However, reaching a mutually agreed upon, clearly understood definition of deliverables can be tripped up by a word choice, missed warranty, or assumptions that aren’t spelled out in the final document. By learning the lessons of those who have successfully—or unsuccessfully—navigated the treacherous waters of contract negotiations, it’s possible to avoid past mistakes and emerge from the process with a contract that paves the way for a project that manages to achieve all expectations.

“The biggest pitfall, easily, is that these things are very negotiable and there’s a tendency not to ask for enough or to assume that if a vendor says ‘no,’ that’s the end of it,” says Diana J. P. McKenzie of Neal, Gerber & Eisenberg LLP. “The biggest thing to know is what to ask for and the only way to know what to ask for is to deal with people who have done this before, if you haven’t done it yourself, and just keep at it on the important stuff. At a high level, that is the most important thing.”

Although it’s impossible to cover every issue that may arise during negotiations, the following are some of the most common red-flag areas and potential deal breakers.

1. Scope of Services
A poorly defined scope of services can set the stage for failure and an ugly battle between client and vendor when someone seeks relief. The trick is to define the scope as completely as possible and provide wiggle room to accommodate unexpected changes.

“It’s very difficult to define scope and the vendor and customer will always disagree on that later,” says McKenzie. “If you don’t have something that says ‘scope is what’s listed plus anything reasonably related to what’s listed,’ you’re always going to lose the fight that it wasn’t included in scope.”

The best way to accurately define scope of services is for both vendor and client to participate in the process, according to McLeod. Vendors can provide the expertise to ensure clients are addressing all their needs and have a well-developed scope of services.

More often than not, projects that are considered failures suffered from scope slide, which can impact the time frame for project completion and the final cost, McLeod adds.

“Sometimes the requirements flat out change because it takes a long time to get these projects from point A to point B and the organization’s business needs change. But oftentimes it’s just that the homework wasn’t done up front on what needs to be done and how it impacts every other piece of the IT infrastructure,” he says. “Those things are often discovered at points in the project where it’s more difficult to deal with them. For instance, if the requirements of a project change when you get to the testing stage, that’s murder on the project.… It’s important to have that good scope because it helps the vendor and the hospital create a project plan that’s going to be realistic.”

2. Scope of Use
In the world of application development, few things will affect response times, user acceptance, and ongoing costs as greatly as a poorly defined scope of use. While configuration and response time warranties can protect the client if the vendor’s actions result in poor performance, blame lies squarely with the client if they didn’t provide a clear picture of the volume of current and future users, says Matthew Duncan, director of advisory services for First Consulting Group.

“If the hospital doesn’t have an accurate reflection of how many nurses will be using the system at any one time, two years down the road, they’ll find out they’ve surpassed the allowable number of users and they’re being dinged for another $1 million to upgrade their license fee to allow for another 100 users,” he says.

3. Interfaces and Compatibility
As healthcare organizations become more integrated, the application portfolio at any given facility can easily number in the hundreds, some or all of which will be impacted by the application that is the subject of negotiations. Failure to provide comprehensive information on that portfolio and how the various systems will interact with the new application can spell operational and financial disaster.

“Eventually, you’re going to have to deal with the reality of building interfaces, either one-off or what we call point-to-point interfaces, or building design specifications to use an interface engine to link those systems together. No matter how you do it, it requires a lot of people time,” says Duncan. “What both organizations—the vendors and the [facilities]—tend to do is not realize all those interface points until they’re well into the interface process and vendor resources are stretched. That’s the point where they can really up their implementation fees, so it’s in the [facility’s] best interest to really understand their portfolio and what all the pieces are going to be that will interact with the new system, then go to the table with that and negotiate a fixed price.”

Another issue in this category that warrants close scrutiny is that of interoperability—specifically, whether the application in question is compatible with others in the facility.

“A vendor will say [it’s] compatible with another vendor, but [it’s] really not because they maintain a data field with a different number of characters, for example. It really impedes functionality to say those two are compatible,” says McKenzie.

4. Source Code Escrow
Ownership of source code will almost always be retained by the vendor. However, clients need to ensure their ability to access that code is protected through escrow and the escrow deposit is complete.

“Eighty percent of all deposits are incomplete, not because the vendor is trying to be malicious, but because they just forgot something. So you just need to have it verified,” says McKenzie. “What happens is the software vendor forgets to deposit stuff into escrow, so when it comes time to pull it out of escrow, the last thing deposited was three years ago and it’s so out of date that it’s useless.”

The way to solve that problem is to have the escrow agent contact the vendor every six months or so and tell them what version they have in escrow, which will alert the vendor to upgrade if necessary.

It’s also important to establish release conditions that preferably are not based on bankruptcy provisions. “That’s not great because the bankruptcy trustee can do whatever the bankruptcy trustee wants, despite what your agreement says,” says McKenzie. “What you want to do is grab it right before bankruptcy, so what we tend to do with our documents is put in the source code escrow [release] provision as [language about] failure to support for a certain number of days, failure to return phone calls, failure to market—things that typically happen before someone goes bankrupt.”

5. Sunsetting
Despite a run of acquisitions in the 1980s and 1990s that left thousands of healthcare organizations out in the cold with applications that were no longer supported by the acquiring company, today’s contracts rarely include provisions regarding sunsetting, according to Duncan. The number of new and former PACS companies should make the importance of this obvious.

However, without language requiring the vendor to continue supporting the contract terms in the case of acquisition—or that requires the acquiring company to replace an application that it sunsets at no additional cost—the client can be left unprotected and forced to replace an application they’ve already invested heavily in.

“This has been less of an issue since there’s been a lot of consolidation in the industry over the last decade or so, but it’s certainly still real,” says Duncan. “Every company is for sale, even if they never admit [it]. There have been a number of horror stories on the large scale.”

6. Resources & Responsibilities
Any contract should clearly outline the resources and responsibilities of both parties—who will be available, how often, and what their specific tasks and responsibilities will be, according to McLeod. It’s not uncommon, he says, for a vendor to be doing its part to move the project forward but wind up delayed because the client’s resources are not available to respond to questions, provide necessary information, conduct testing, or other valid questions.

“That’s something that needs to be avoided at all costs,” says McLeod. “One way to do that is to write the contract to clearly spell out what everybody’s responsibilities are going to be, including the client’s. Then build into the contract the understanding that if either party doesn’t provide the resources, the project as stated is not going to be completed in the hours or time frame stated.”

As for responsibilities, McLeod says the integration projects his company undertake typically involve at least three other parties. As such, he is keenly aware of the importance of spelling out up front individual responsibilities and not hiding behind the phrase joint responsibility.

“I do not believe in including joint responsibility in a project scope or contract because I think it’s a cop-out,” he says. “Most organizations are more than willing to provide the resources that they know up front they’ll need to provide. It’s when there’s too much ambiguity in who is responsible for what that people tend to sit around and wait for somebody else to do it.… That’s human nature. Proper expectations dictate that everybody know exactly what it is that they’re required to bring to the table so it goes smoothly and nobody gets burned.”

7. Personnel
When it comes to actually manning the project, clients should seek assurances that the project team will not only have the right mix of skill sets, but that it will also remain relatively consistent throughout the life of the project.

“You need to have a provision in the contract that says they can’t whisk people off; once they’re on your team, they stay on,” says McKenzie. “You have to put some softness around there to allow people to get promoted and so forth, but there’s only a limited amount of patience one can have for these kinds of things.”

Duncan suggests that the client include in the contract a definition of who the key individuals are on the project, they’ll remain on the project until the end, and they have the right to approve certain team members.

“While it’s certainly reasonable to expect that there has to be some sort of pyramid to the staffing mix, you have to have the ability to be satisfied that you’re getting the appropriate experience from key individuals,” he says.

8. Payment structure and fees.
When it comes to payment structure, Duncan says a critical deal breaker for his clients is requiring up-front payment of licensing fees, which are typically the second-largest component of a project behind implementation fees.

Vendors will push hard to get as much of the licensing fee at the time of signing as possible. The problem is, “once you’ve paid that up-front check for the license fees, you lose all leverage. So we always make that the No. 1 priority in negotiations, to structure payment terms around successful delivery of milestones,” says Duncan. “In almost every boilerplate, you’re going to see license fees due up front, but anything more than about 25% is probably not acceptable.”

Another area of concern lies within the language around ongoing software maintenance fees. Typically, vendors reserve the right to raise these fees after a set amount of time has passed and continue to raise them annually.

“They will have seemingly innocuous language in their boilerplate allowing for things like software maintenance fees to be increased on an annual basis; typically they won’t stipulate what the cap is, or it will be something ridiculous like 10%,” Duncan says.

That means a large client who is paying 20% in annual maintenance on a $20 million software license will see their $4 million annual fee increase by as much as $400,000 per year once the ability to increase fees kicks in—and the amount will grow exponentially each year.

“It’s not just on software maintenance fees but pretty much all the operational components in the contract,” adds Duncan. “We always make one of the deal breakers be capping all those fee increases to either consumer price index or 5% annually, whichever is less. That clause protects you if we go back to 1978 and 20% inflation.”

Mutual Trust
When it comes to negotiating win-win IT contracts, it doesn’t matter how many warranties and provisions each party manages to get into the final document if the negotiation process has created a hostile relationship.

“There needs to be some mutual understanding and a mutual trust established so that as you’re going along, if things do change, it’s looked at as a natural part of the process and not a failing of any particular party,” says McLeod. “There needs to be some wiggle room provided to the vendor on the part of the hospital [because] if the hospital didn’t provide a piece of information, there’s only so much the vendor can do. Conversely, if the vendor doesn’t do [its] homework, they need to understand that’s not the hospital’s fault. If [it] didn’t help the hospital develop the scope sufficiently to answer all the questions going into it and it ends up being a much bigger project than what they thought or quoted, that’s not the hospital’s fault.”

— Elizabeth S. Roop is a Tampa, Fla.-based freelance writer specializing in healthcare and health information technology.