CIO and Senior Vice President of Operations Edward Nesta, had no idea that a language barrier could cause so much trouble until his company, The Leading Hotels of the World (LHW), nearly got hauled into a Japanese court over a contract dispute with an outsourcer.
LHW, a New York City-based marketing and reservations service for exclusive hotels across the globe, hired a Tokyo computer-support company to hook up the local-area network in its Tokyo office with its wide-area network. Midproject, the Japanese-speaking vendor misinterpreted a series of casual English-language e-mails from Nesta's IT personnel in New York as a go-ahead to perform extra services. Suddenly Nesta got hit with a US $50,000 bill for services he never asked for. Naturally, he refused to pay. Naturally, the vendor threatened to sue - in Japan. "Considering we didn't have a lawyer over there, it would have cost four or five times the amount in question just to deal with the case," says Nesta. "We would have had to find local counsel and develop some understanding of their system."
Nesta resolved the dispute without a lawsuit by expanding the outsourcer's labour-support role, which meant more money for the vendor in the long run. But he dodged a bullet, because IT-related litigation - whether it's your company doing the suing or getting sued - is the ultimate failure for the CIO. Be it a vendor, a partner or a competitor who's really at fault, the other executives will be coming to you for answers. And as the company spends hundreds of thousands of dollars - if not millions - litigating the case, everyone will blame you for putting the company in this situation in the first place. In the end, it can cost you time better spent on important projects, hard-earned influence in the boardroom and even your job.
"It's just not good for your career," says Robert Collins, CIO and vice president of information services at Cognos, a business intelligence company in Ottawa. "It all comes down to the fact that you didn't set out to achieve what you started. It's a credibility issue, and you've hurt the business."
In Nesta's case, even the threat of litigation created a huge headache that he'd love to forget. When the situation broke, he had to back-burner everything else for a week so that he could deal with anxious senior execs and pool together enough data and documentation to refute the outsourcer's claims. So now he forces himself to remember the situation as a guidepost. Whenever his staff deals with vendors in other countries, he makes sure their e-mails are succinct and leave no room for misinterpretation. He also relies more on his onsite staffers, who understand the local language, to act as go-betweens. And when the project carries significant costs, he deals with the vendor directly.
CIOs should take particular note. Colleen Young, who researches IT litigation for the Gartner Group in Stamford, Conn., describes the typical IT department as "a black hole for litigation." This doesn't just mean contract disputes with vendors. You could also have invasion-of-privacy, trade-secret misappropriation, software-pirating and patent-infringement claims on your hands. As a CIO, you have to detect potentially litigious situations and defuse them before they blow up. Here are a few potential horror shows to look out for and some steps to take that could save your job.
Creep Show
Any smart CIO will take steps to avoid the phenomenon of scope creep. This monster surfaces when people in your IS department begin to request services from the vendor that weren't specified in the contract. Gradually the project begins to take on a life of its own until you inevitably wind up in court for one of two reasons. First, additional demands on vendors create delays in the original project, and your CEO will decide she's left with no choice but to sue over the time lag. Or worse, the vendor might sue, demanding payment for all the extras. Either way, you lose. To avoid scope-creep problems, experts recommend the following tactics:
Have a project manager track requests and vendor progress.
You should appoint someone from the IS department who determines at the time of the request whether or not it falls within the contract. "By documenting what's being asked of them, you're forced to address the issue," says Franklin Blackstone, a technology law partner at Mintz, Levin, Cohn, Ferris, Glovsky & Popeo in Reston, Va. "Circulating an e-mail through the IS department ordering people not to make individual requests helps, too."
Organise project-status meetings.
You should hold these meetings once a week to hash out what's being done and whether it goes beyond the contract, says Blackstone.
Maintain a site on your intranet.
For major projects, you should keep a centralised spot on your intranet where you and your vendor can catalogue potential out-of-scope activities and perform regular reviews to avoid conflicts, says Stuart Kliman, director of Vantage Partners, a consultancy specialising in relationship management in Cambridge, Mass. "This helps you keep track of things so that at the end of the month you won't be surprised when a bill comes due," says Kliman, a former practising attorney.
Establish clear, written project parameters within the contract.
Of course nothing prevents scope creep or other contract disputes as much as well-articulated project parameters written in the contract itself, says Bruce F. Webster, a director at PricewaterhouseCoopers (PWC) in Washington, D.C., and author of a recent PWC study on IT systems-failure litigation. Webster adds that you can only achieve this via a multidisciplinary approach. You need a lawyer on the contract team who understands the pitfalls of an IT project, but you also need a trusted IT project manager on the team who can serve as a reality check on the mechanics. "A lawyer isn't necessarily going to understand all the things that can go wrong," says Webster. "And often you, as a CIO, won't have the same down-in-the-trenches, 'been there, done that' level of expertise with the technologies and challenges of project development [as a good IT manager]."
Deliverance
Webster's survey catalogues 25 years of IT systems-failure litigation, and he says a large chunk of what he's seen revolves around a vendor's failure to deliver a working system on time - or to deliver a working system at all. Either the schedule keeps slipping or the vendor installs a bug-ridden system. Eventually the user refuses to pay, the vendor threatens to sue, the user threatens to countersue and everyone ends up in court, spending more in legal fees than the contract was worth in the first place.
As with scope creep, it all comes back to what was in the contract. In some cases, the CIO has placed unrealistic expectations on the vendor. "I've seen cases where the CIO says, 'Look, they want this system in place in four months. I know you can't do that, you know you can't do that, but let's go ahead anyway - I'll deal with the problems later,'" says Webster. "Nine months go by, and the CFO says, 'We're cancelling the contract.' And the vendor can argue that you knew all along it would take longer, which doesn't help your company's position or your own."
Again, the key here is taking a multidisciplinary approach and formulating realistic contractual terms, says Donald J. Kunz, a technology lawyer with Honigman, Miller, Schwartz & Cohn in Detroit. But beyond that, Kunz suggests having a testing procedure written into the contract to determine whether an acceptable product has been delivered and building in financial incentives for early delivery and financial penalties for delays.
On particularly large projects, you should consider having a third-party expert to act as a "building inspector" to determine whether the system is meeting its goals on time, says Nicolas Barzoukas, a partner at Howrey, Simon, Arnold & White in Houston. This guards against litigation over whether or not delivery has occurred in the first place. Typically, you'd use a consultant who charges by the hour. Other delivery cases involve vendors that exaggerate their systems' capabilities and deliver results far short of expectations. Blackstone tells of a case where he represented a manufacturer that contracted with a software vendor to install manufacturing application software. The vendor delivered a bug-ridden system that, despite continuous maintenance, was never fully functional. Eventually Blackstone's client got fed up and sued the vendor.
Blackstone secured a pretty good settlement for his client, but the CIO lost his job. Why? He didn't take the one crucial step that could have prevented him from falling victim to sales puffery: investigating the vendor. As it turned out, the vendor, a highly respected database software developer, was a neophyte in the manufacturing application market, and very few companies had used its manufacturing software before Blackstone's client entered into the contract. "The CFO [who fired the CIO] figured he should have been in a position to have analysed whether these products were ready or not," says Blackstone. "Sometimes it's tough for a CIO to do all the work, but he could have assigned a point person to do all the due diligence."
Blackstone adds that while most CIOs do at least a rudimentary background check, few go far enough. In addition to checking customer references, and company finances and history, you need to meet with members of the vendor's development team, present them with a sophisticated RFP and hash out every conceivable need.
Possession
Litigation-averse CIOs should also be on the lookout for stolen or illegally copied software. For example, an employee might bring in a disk or download a game or an executable file from his e-mail. Chances are, he has no license. Next thing you know, he's shouting to his buddy in the next cube, "Hey, I've got a copy of such-and-such on my PC - I'm gonna send it over. It's free!"
Well, it's not free, and your company inevitably pays. It can be as easy as a disgruntled ex-employee calling up the "software police" - either the Business Software Alliance (BSA) or the Software Publishers Association (SPA) - and saying, "By the way, these guys have unlicensed copies of Quake all over their computers. Just so you know." All of a sudden, the software cops are at your door, accompanied by a subpoena and a couple of Justice Department agents demanding to audit all your PCs forthwith. "Now talk about a freakin' headache," says Blackstone. "That's not the kind of phone call you need to get from your receptionist."
The next step for the BSA or SPA is suing you in federal court on behalf of their member software companies. As for settling with them before they bring suit: "Good luck," says Blackstone. "They really trumpet these suits; they do it with great fanfare. They want to put this to a stop."
The best way to avoid this situation is through vigilant internal auditing of your systems. There are tools available to help you. "We use Microsoft SMS," says Cognos's Collins. "And from our central server, we can inventory everything. We keep track of what's on everybody's PCs and look for what's not supposed to be there. Since we're also a vendor, it's important to us to be purer than pure."
Trade secrets are another big issue, particularly if you employ in-house software developers. They may be embedding or reusing software routines that they've developed for another employer. If they haven't taken explicit steps to retain ownership, they'll very likely find themselves in court, with you sitting right there alongside them at the defendants' table. "I can't think of a single company I've talked to that has any formal process in place to prevent this type of occurrence," says Gartner's Young, noting that hundreds of trade-secret suits are brought each year.
The good news is that an effective management process is not difficult to design. The first step is to incorporate a policy into your employment agreements that in essence says that if it wasn't invented here, either lose it or prove the right to use it. And if you employ reusable pieces of code, you should maintain them in a library of reusable objects. "You need a management process around that library to ensure that anything that goes in has appropriate ownership," says Young.
Similarly, if you outsource your software development, you must be sure your vendor has the right to use any technology it's employing on your behalf. An angry third-party patent holder isn't going to sue just the vendor - he's coming after you, too. So you must vigorously manage the project, even if the vendor's doing the work. Collins suggests appointing someone from your team, perhaps your IS director, to closely monitor how the software is being built.
Unfortunately, it's impossible to cross-reference every patent in the world with each line of code your vendor writes. Since you can't catch everything, you need to negotiate an IT indemnity clause into your vendor contract, saddling the vendor with full responsibility for any third-party IP claims.
Hands Off
Many people think of sexual-harassment issues as human resources turf. Don't buy into that. It's your problem, too, particularly when an outsourcer's employees are working on a job in your IS department. Blackstone says he's seen too many cases in which a vendor's employee made improper sexual advances toward a user's employee or vice versa. If the problem goes unchecked, the consequences are obvious: enormous monetary payments to the victim (sexual-harassment cases have gone well into the six figures), horrible publicity for your company and a perception that you have no control over your department.
Even worse, you might find yourself individually named as a defendant in the suit. Blackstone says this happened to a CIO in a case he defended. A female employee accused the CIO of doing nothing when she came to him to complain of a vendor employee's lewd conduct toward her. In this case, the plaintiff dropped her claim against the CIO when he agreed to have a letter of reprimand placed in his personnel file.
Though it's impossible to prevent every incident of harassment ahead of time, there are precautionary steps CIOs can take to manage the situation. First, you should distribute a formal antiharassment policy to your employees and to vendor employees who will be visiting your facility. Additionally, you should have a contractual clause giving you the authority to remove any problem vendor employee. "This gives weight when you come to the vendor and say, 'We need to talk,'" says Blackstone.
The Towering Inferno
Your litigation watch shouldn't be focused on just the acts of hackers, vendors, competitors and employees. You need to look out for acts of God, too. We all remember the mad scramble to become Y2K-compliant in order to avoid liability for data loss last year. The same concept applies in case of fires, hurricanes, earthquakes and other disasters. Gary R. Baxter, vice president and CIO of Maine Employers Mutual Insurance Co., says this issue is of real concern to him. "If we lose data on injured workers, it would be a true disaster with potential legal implications," he says. "They'd be left without funds."
In order to prepare for this, Baxter runs a disaster-recovery preparedness test twice a year. "We physically take our entire set of data and application programs, go to another site, load it up and run our business," he says. "Unless you do that, you don't know if your plan is workable. If it's not workable, that's unthinkable."
And if there's one glaring weakness in the IT industry, he says, perhaps speaking not just about disasters, but about litigation as a whole, "it would be lack of preparedness for the big event."
Are you concerned about the long arm of the law? Senior Writer Eric Berkman wants to know. E-mail him at eberkman@cio.com.