|
|
August 7, 2006
The healthcare executives who are taking a seat across from IT vendors at today’s negotiating table may be more experienced than their predecessors, but they are also dealing with more complex issues with the potential to impact every aspect of the organization, including its IT infrastructure. As such, 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. “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, 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 heeding the advice of those who have successfully (or unsuccessfully) navigated the treacherous waters of contract negotiations, it’s possible to avoid the mistakes of the past 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 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. Scope of Services “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 that clients are addressing all their needs and have a well-developed scope of services that’s approved by all of the project’s stakeholders. More often than not, projects that are considered failures suffered from scope slide, which can impact the timeframe 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.” 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, 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. Interfaces and Compatibility “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 hospitals—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 hospital’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’s portfolio. “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. Source Code Escrow “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 is [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.” Sun Setting 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.” Resources and Responsibilities 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, etc. “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 timeframe 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.” Personnel “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, that they’ll remain on the project until the end, and that 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. Payment Structure and
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 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, Understanding “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 HIT.
“When you start talking about some of the most important deal breakers and foundations of a contract that’s win-win, you don’t want to just throw something at the wall and hope it sticks,” he says. “You’d like to have some kind of foundation that’s based in reality.” To that end, he offers the following dos and don’ts
for negotiating a win-win contract: • Keep all vendor communication consistent, including appointing one primary contact and make certain vendors do not contact any users involved in the selection process. • Establish negotiation “rules of the road” and make sure all parties stick to them. • Set realistic timelines and communicate progress to the selection team. • Contract with external legal counsel (if appropriate). Don’t: • Let the vendor stick to a deadline for pricing discounts. • Assume that all agreed changes to the contract have been included; double-check all changes. • Agree to system modifications unless absolutely necessary for operations. If modifications are needed, they should be prioritized and a “fixed-price” quote obtained from the vendor. Finally, says Duncan, don’t let the vendor of choice know they are the preferred choice. If one vendor becomes the clear leader: • Don’t “tip your hand” and let them know. Keep the other vendor in play as leverage. • Spend the most time negotiating the “deal breakers.” • Be flexible with deal breakers but consistent on demands. — ESR
“The slang term is weasel words. The contractual term is qualifiers,” says Matthew Duncan of First Consulting Group. “You have to objectify the qualifiers. You can’t leave them subjective.” Here are some of the most common: • Solely: Courts have interpreted the word solely to mean just that, says Diane McKenzie of Neal Gerber Eisenberg LLP. If the contested issue is 99.99% the vendor’s fault and 0.01% the client’s fault, the courts will find in the vendor’s favor. “Most people don’t think that,” she says. “They think there’s some threshold, but that’s not the case.” • Estimates: Because they’re really just a guess, using estimates is not helpful because there is no liability associated with them unless they are fraudulently created. • Goals: Like estimates, there’s no liability associated with failure to meet a goal, says McKenzie. “My joke is that they’re great for soccer but otherwise have little value,” she says. “If it’s a vendor’s goal to do something and they don’t do it, they’ve still met the fact that it was their goal.” • Substantially and Materially: Boilerplate contracts make heavy use of these terms, but Duncan advises they be deleted or defined. “If there’s a very clearly defined definition for substantially, then it might be OK to use that term,” he says. “But if you don’t define it, everywhere it’s referenced gives them unlimited wiggle room and it essentially negates all legal obligations of the contract because it can be interpreted any which way.” • May: The word may means it’s a discretionary obligation, while shall is an affirmative obligation, says McKenzie. “It looks kind of silly, but the reality is that ‘may’ at law means it’s discretionary and they can do it or not. So if you’re expecting them to do it, you better have ‘shall’ in there.” • Reasonable Efforts: Clients may say reasonable efforts sounds fair, but there is nothing helpful about the term, says McKenzie. “Reasonable effort is assumed at law,” she says. “If you’re paying for a top-quality vendor, you need an expectation that the vendor will provide at the top level. We’ve developed in our contracts the concept of Tier One effort, which is the level of effort that a top-performing [vendor] is providing.” • Commercially Reasonable Efforts: Like reasonable efforts, using commercially reasonable efforts isn’t helpful unless it clearly defines the industry on which those efforts are based. “Whose industry, the vendor’s industry or the hospital’s industry? Those are very different standards,” says McKenzie. “It should be commercially reasonable efforts for a vendor providing software to a hospital or critical care location, something along those lines.” • Joint Responsibilities: A favorite phrase in IT contracts is joint responsibilities, but McKenzie cautions against its use because it provides too much wiggle room should the project fall apart. “They need to separate everything out. We’re not all coloring the coloring book together. Different people have different parts, different crayons,” she says. — ESR
|
 |