SUING YOUR IT VENDOR: NOT AS EASY AS HITTING THE DELETE BUTTON
By: Thomas G. Gruenert & Paul D. Gibson
Today’s corporate enterprise is obviously dependent upon sophisticated technology. We make this not-so-profound observation based upon our experiences as lawyers and as businessmen. Abraham Lincoln might have been able to practice law without e-mail, but we can’t. Our dependency on the electronic gadgets on our desks is not a whole lot different from our clients’ situations. Failure of any core component of their IT systems results in profound impacts on their business, and those impacts are not necessarily easy to document, quantify or even understand. When failures in our clients’ IT systems have resulted from faulty hardware, bad installation, software that doesn’t have the functionality that was advertised or contract professionals who don’t have the skills they promised, the clients have asked us to get involved. In the process we have learned that litigation with an IT system vendor involves issues that are certainly challenging and can be much different from those encountered in other kinds of commercial litigation.
A. The Threshold Issue - "Did we do this to ourselves?”
In today’s environment, IT systems are complex, the people who are tasked with operating them come with a wide disparity of qualifications, experience and innate ability, those same people tend to be subjected to work loads and stress that could be characterized as draining, and they work for folks in the executive suite who are not necessarily conversant in the technology. As a result, IT professionals tend to be somewhat younger, somewhat more prone to change jobs and employers and somewhat more likely to make mistakes than management might hope.
At the same time, a client’s IT personnel are faced with a dizzying array of options when they consider changing any part of the IT system. The best IT manager, with all the time in the world to research a product and reflect on a decision (which none of them have) might end up buying something that simply isn’t the right solution for the business problem he or she is trying to address.
So, any lawyer who is asked to get involved with a dispute between a client and one of its IT vendors must first ask himself (and the client) whether the problem is truly the fault of the vendor or whether "we did this to ourselves.” Of course, this analysis is not necessarily that much different from the initial inquiry made by the lawyer in any commercial case. For instance, any lawyer hired to prosecute a breach of contract case would have to look at the facts to determine if the client’s personnel have interpreted and operated under the contract in a way that seems consistent with its terms. Likewise, any lawyer called to the field to investigate a casualty incident at a client’s plant would have to look first at the client’s training, safety and casualty prevention programs before reaching any sort of understanding of where fault really lies. The difference in a technology case simply may be understanding what one is told by the client, and digesting the significance of what one is not told.
It is not unforeseeable that what the lawyer finds upon arriving at the first meeting with the client in an IT case is an in-house lawyer who does not have a technical background, and an IT manager who, consciously perhaps, but more likely sub-consciously, is interested in establishing that the problems in the IT system are not the result of bad decisions in his department. Both may have limited patience with questions about their team’s capabilities. The challenge for the lawyer, at least for a litigator who hasn’t got training as a software developer or an electrical engineer, is first of all to get an understandable explanation of the nature of the problem and its implications for the company. We have had some success asking the IT manager to imagine that he is in the witness stand, that there is a jury listening to him, that the jury is made up entirely of people who are fundamentally technology-challenged, and that he needs to explain to them how the problem was detected, what he thinks is causing it and how it is affecting his business.
Getting beyond the "did we do this to ourselves” phase contemplates a fair bit of due diligence on the part of the lawyer. The trick, of course, is getting the client, who may just be eager to get after the bad guys, to understand the necessity of that due diligence and to assist with it. Here are examples of the kinds of questions that have to be answered:
- What exactly is not working: hardware, software, etc.;
- Where exactly does that piece fit in the IT system;
- When was it acquired, how was it acquired, from whom was it acquired;
- Was it leased, purchased, or acquired under a consulting or some other form of agreement;
- Is there a written contract relating to it;
- Who made the decision to acquire it in the first place, and what kind of sale pitch was he or she given;
- Who supervised its installation/implementation;
- What resources did the company provide to facilitate the installation/implementation;
- What people at the company were involved with installation/implementation;
- Who within the company has managed it after it was up and running;
- Who at the company has been involved in maintenance of the system;
- Who trained the people involved in running and maintaining the product;
- Did the client receive written sales material;
- Did installation/implementation require a change in existing business processes;
- What are the warranties on the item;
- What conversations have been had with the vendor about the current problem.
With regard to any question involving the client’s personnel, one always has to add the follow-up question "are they still here?” The high demand for qualified IT personnel means that the answer frequently is "no.” Which, of course, complicates the due diligence and the case generally.
After working through the initial inquiries and interviewing the IT manager and perhaps the key systems maintenance personnel, the lawyer ought to be able to assess whether there really is a risk that "we did it to ourselves.” Assuming that the lawyer can be satisfied on that issue, the next question is whether a case against the vendor is worth bringing.
B. Evaluating the Case
1. Evaluate the Contract. As in any commercial case, the inquiry regarding whether the case is worth pursuing must start with the written contract between the client and the vendor. (If there is no contract, it is absolutely imperative that the person who made the decision to purchase the IT component is interviewed. If he or she is no longer with the company, they must be found.)
Assuming there is a contract, here are the provisions that must be thoroughly vetted:
- Is there a choice of law provision? If so, will it be enforced in your jurisdiction?
- Is there a liquidated damages provision? If so, will it be enforceable under the law that has been designated as controlling?
- Is there a limitation on consequential and exemplary (punitive) damages? Will it be enforceable under the controlling law?
To our experience it is the rare contract offered by an IT vendor that doesn’t have a liquidated damages provision and an express prohibition of consequential and liquidated damages. While the enforceability of such provisions may vary between jurisdictions, one can generally anticipate that the court will try to give effect to all parts of the parties’ agreement absent exceptional circumstances. At least one jurisdiction that we have become familiar with in the course of past cases, Mississippi, has a statute that specifically validates contractual limitations on consequential damages in software sales contracts.
In the event that the particular contract you are reviewing contains limitations on damages and a choice of law provision that calls for the application of the law of a state that deems such limitations enforceable, there are still some questions you can ask. Most common law jurisdictions will hesitate to enforce contractual limitations on damages where there has been a legitimate disparity in the bargaining power of the parties, where the contract has been imposed by the vendor on a take-it-or-leave-it basis. Thus, if your client is a small business and the vendor is a substantially larger company, you may have an argument against enforcement of limitations on damages. Any meaningful negotiation of the contract by your client, review by counsel, and similar indications of a level bargaining field will, of course, cut against your chance of nullifying the contractual limitations.
Even with a less than desirable contract to work from, one might still make something of the case. Depending on the size and sophistication of your client, you may be able to plead a consumer fraud or unfair trade practices cause of action. Also, whether the problem with the product lies in faulty installation or faulty design, there may be a negligence/products liability claim available against the vendor. If the product simply can’t perform the functionality that was advertised, there may be a fraud claim available. One must be careful to review the case law in the governing jurisdiction regarding pleading tort claims in connection with a breach of contract cause of action. In Texas, for instance, there is jurisprudence to the effect that a negligence claim will not lie in a breach of contract action where the alleged negligence is simply the execution and performance of the contract. So, if you are going to go for the tort cause of action, do your research and make sure you have the facts to support an independent tort claim.
2. Evaluate the Vendor. If you are considering suing the vendor, you must ask yourself two questions. First, has the vendor done something more than sell a product that doesn’t work as well as my client would like? Second, is the vendor worth suing?
By asking whether the vendor did more than just sell a product that the client isn’t happy with, you really are trying to evaluate whether you will end up with a swearing contest at the end of the day, with your client swearing he was told one thing about the product, and the vendor swearing that the client was told something else. The kinds of things that one is looking for here:
- Did the vendor supply sales materials that make specific representations about the product or service?
- Did the vendor supply written training materials?
- Did the vendor’s personnel install/implement the product?
- Did the vendor give your client’s personnel training on the product?
Depending on the size and profile of your client’s project, it is possible that the vendor may not have used it’s "A team” installation personnel. It is also possible that the vendor was training some of its personnel in the course of the implementation program. It certainly is possible that the vendor’s sales representatives might have made statements about the product that simply weren’t accurate.
By asking whether the vendor is worth suing, you are trying to prevent the client from incurring the costs of extended litigation against a vendor that may ultimately be judgment proof. Here are some of the things we look for:
- Is the vendor a public company? If so, review the most recent available annual report and the most recent proxy statement.
- Is the vendor a party to other lawsuits?
- What do the IT trade publications say about the vendor and its products?
- Do any of our client’s people maintain continuing relationships with the vendor? What information can they provide?
Assuming that these inquiries produce sufficient information to satisfy you that there is something more to your case than a swearing contest, and that the vendor is worth suing, you must look next to your client’s involvement in the project.
3. Evaluating your client’s performance. Any substantial IT project involves your client is a variety of ways: the client makes the purchasing decision, participates in the implementation, receives the training and, in the end, operates the system. The client’s involvement in each of these stages of the project can fundamentally impact your case. All of the questions outlined above regarding your due diligence become fundamentally important here. Perhaps the most important question is always going to be "Is that person still here?” If one of the key members of your team is gone, it will fundamentally affect your case if you can’t find them and secure their cooperation.
You can’t evaluate the case if you can’t evaluate the relative strengths and weaknesses of your client’s personnel who dealt with the vendor and managed the client’s side of the implementation. Further, you have to get the client’s frank evaluation of its own personnel. You don’t want to sue the company that sold the enterprise software only to find out that the client’s IT manager who was in charge of the implementation was subsequently referred to counseling with a chemical dependency. Even the best of personnel are not going to be able to do a quality job on the implementation if they are not given sufficient time and support to accomplish it. You have to determine if client’s management made the implementation the highest possible priority for the IT team and gave the team the time and support they needed. If the implementation team couldn’t work on the project until they finished all their other, ordinary job responsibilities, you may have a problem with your case.
You have to determine whether the client did an adequate job of explaining its business processes to the vendor during the implementation. Imagine yourself deposing the vendor’s sales manager and triumphantly informing him that the new accounting software package is incapable of presenting financial data in a format that anyone at the client company has seen before or can understand, only to have him tell you "yeah, we all knew that but they told me that no one really looked at the numbers.” You have to be able to convince the jury that the client explained its business to the vendor before the fact, not after.
Finally, you have to determine whether the client’s personnel who worked on the implementation, as well as the senior people who might testify at trial, are capable of being good witnesses. That means explaining their business to the jury, explaining how they rely on the particular part of the IT system to help them run the business, explaining how the problem is damaging the business and explaining the damages. This explanation has to be delivered without patronizing the jury, in a way that appeals to their common sense and their common experience. Experts may be necessary to explain the technical reason for the problem, or to outline damages, but the initial explanation about what went wrong here has to come from the client. Yes, you say, that can be coached, and to a certain extent we agree. However, even the greatest artist needs a canvas upon which to draw. You’ve got to identify potential witnesses who are articulate, knowledgeable, and willing and capable of withstanding cross examination. We want to be diplomatic about this issue, but we cannot overemphasize it. Engineers and technical specialists traditionally are communication challenged. If the important witnesses for your client are going to have difficulty communicating with the jury and standing up under cross examination, your assessment of the case needs to take that into consideration.
4. Are there potential claims against third parties? Counsel must consider the possibility that the vendor is selling a product manufactured by someone else. This is a strong likelihood in the case of most hardware and much software. Your due diligence should include some investigation of possible claims against the manufacturer.
- Did the vendor deliver sales materials created by the manufacturer?
- Did the vendor assign warranties made available by the manufacturer?
- Did any personnel from the manufacturer participate in the sales meetings or the implementation?
It is also possible that the vendor used a third party contractor to assist in the implementation or the training. If such is the case, counsel must engage in the same due diligence on the contractor that he would devote to the vendor itself or the third party manufacturer.
5. What is the damages model?
Understanding the damages is a challenge in the IT case. The first measure of damages obviously is the amount that your client has paid, or owes, for the purchase and installation of the defective product. Beyond that, however, you are likely to be faced with some difficult questions. The client may suggest that having this defective piece in its IT system has caused any number of problems: customer service may have been damaged, inventory tracking may be crippled, the financial information may not be capable of being presented. The client may say sales have suffered as a result, that important financial transactions have been delayed or lost completely, that profits are down. Your chore here is twofold: figure out if the problem complained of is the result (without substantial contributing factors at your client’s hands) of the problem in the IT system, and think through the implications of the choices you make about damages.
Let’s say for example that new accounting software has been a dismal failure at your client’s company. The CFO states that he had a deal in place to obtain a revolving credit agreement with a group of banks at favorable interest rates, and he lost the transaction due to his inability to give the banks accurate and timely financial forecasts. Instead, he says, he had to go to alternative lending sources with substantially higher interest rates. The cost to the company over the life of the loan will be measured in the hundreds of thousands of dollars. Is the money spent on higher interest rates a legitimate item of damage? Before you decide, remember that, if you pursue this damage theory, you will be making witnesses out of the bankers who didn’t make the loan and the alternative lender who did. Are the bankers likely to say that the only reason they backed off was the inability to produce financials in the format they wanted? Is the CFO really going to be eager to put his current lender in the position of having to respond to discovery and incur legal expense? We’re not passing judgment one way or another on this particular theory of damages, we’re just saying that you’ve got to consider the implications of pursuing it. The same can be said of other damages theories. If you are going to allege that sales are off because client service has been handicapped, are you making witnesses out of your best customers? The final damages model has to take into consideration both the legal issues (remember those contractual limitations on consequential damages) and the practical problems.
C. Choosing the Forum/Preparing the Complaint/Preserving the Evidence
If you believe you have a case, some viable causes of action, and witnesses who can present the facts to a jury, the next issue is getting from the conference room to the courthouse.
1. The Forum. You have to give substantial thought about the right court to proceed in. If you are suing an out of state vendor, you have to determine whether the case will be removable to federal court. Or you may decide to go directly to federal court. Either way, you’ve got to think about rules of pleading in federal court, and the tougher enforcement of sanctions and discovery rules. The "let’s throw in a billion dollar claim now and find some facts to support it later” approach is going to be riskier in federal court.
Even if you have the luxury of proceeding in state court without fear of removal or other expensive jurisdictional proceedings on the front end of the case, you have to decide whether the state judge is going to be patient with a complex, time consuming technical case. Obviously the right decision about which court you want to be in is going to depend on the quality of the local bench, the relative crowding of the dockets, the size of the case and the technical complexity of the proof. The widely held opinion that federal court is the place to be with a complex, legally dense dispute must be weighed against the greater willingness of federal judges to grant summary judgments and to assess sanctions.
The most important part of the forum/jurisdiction analysis is that the client should be part of it. The client is going to have to pay the bill, endure the delay, and live with the judge and the jury, so they should understand the implications of the alternatives.
2. The Complaint. Crafting the complaint requires careful selection of legal theories and causes of action. Everything we said above about reviewing the contract and researching available causes of action applies here. Beyond that, one must decide whether one adopts the "bare minimum” approach in drafting the complaint or something that goes well beyond the basic requirements of notice pleading. We tend to favor a drafting approach that produces a complaint that will not only give the defendants notice of the factual basis for the dispute but also will give the clear message that we have thoroughly researched the problem, that we understand the technical issues, that we understand the legal issues and that we are real serious about the case. This approach, of course, is more expensive to the client at the front end of the case than a "bare minimum” approach. Most clients become comfortable with the expense issue when they understand the reason for the approach. We emphasize that every case is unique, and there is no cookie cutter to use in drafting the complaint.
3. Preserving the Evidence. The client is going to want to put a patch on his IT system with the same sense of urgency that he would have if his roof was leaking on a rainy day. The challenge for the lawyer will be letting him fix his leaky roof while preserving the evidence that the jury is going to need to see.
As in the leaky roof case, the people doing the repair are potentially excellent witnesses. If the software doesn’t work, your client is likely shopping for some that will. The vendor of the replacement product may be a good source of the problem with his competitor’s product and the necessity for the fix.
There are some obvious steps one must take to preserve the evidence:
- Obtain detailed sworn statements from key users of the system who have experienced the problem;
- To the extent that the system has produced faulty reports, flawed graphics or other tangible indications of the underlying problem, obtain the best possible copies and obtain affidavits from the personnel that one would rely on to explain to a jury what they were looking at;
- Obtain copies of internal service requests, work slips, time slips, maintenance reports and other document that relate to the users requests for help from the system maintenance staff and the actions taken in response;
- Get the originals all invoices from outside consultants who have provided labor and services to address the problem;
- Get copies of all proposals or bids that the client has received from vendors hoping to provide the replacement for the defective product, and get names and addresses for the representatives of those vendors who have examined the problem and prepared the proposal to the client; and
- Get contact information for all former employees of the company who were significant users and whose testimony might become necessary, and obtain statements as soon as possible.
Beyond these steps, one needs to think about whether it is possible to preserve a sample of the problem in a way that would allow expert witnesses to review the problem and its implications during trial preparation, that would allow the client’s witnesses to prepare for trial and that would, eventually be shown to the jury. Given that the client may be acting quickly to replace the defective product, this may be a challenge. A logical first step is to sit down with the IT manager, explain the necessity of preserving a working version of the "problem,” and allowing him to work out how to coordinate preserving the evidence. We have worked in cases where it was sufficient to make a copy of a defective software product on a disk. We also have worked on cases where we essentially established a segregated network in a "war room” that included a server, work stations and all the software that was installed on them the day the defendant was done with the installation. The important thing to do is to discuss and address this issue at the very front end of the case.
D. The Necessity of Experts
To our experience, good expert witnesses are of fundamental importance to an IT case. Good expert witnesses are, generally speaking, expensive. This may result in some reluctance on the part of a cost sensitive client. However, the reasons to take on independent expert witnesses are fairly obvious and hard to repute: the clients’ personnel with first-hand knowledge of the problem are likely to be fact witnesses, and so their "independence” will be suspect in the jury’s collective mind; moreover, the client’s personnel are not likely to communicate with a jury as well as a professional would.
There is a veritable ocean of technical experts that flows the whole world round. The trick is helping the client find the right one. We believe that counsel must be particularly careful in vetting conflicts. Any number of first class IT consultancies can provide an articulate witness capable of explaining the most complex of problems in terms a jury could understand. Counsel’s job is to be sure that the consultancy (i) doesn’t have industry clients in the segment that is defending itself before the jury; (ii) hasn’t represented the other side of the technical issue, and (iii) (obviously) hasn’t worked for the defendant your client is suing. This inquiry needs to be made of all of the expert’s personnel. So, counsel must ensure that the engagement agreement for the expert includes specific representations that the expert has examined all clients and all personnel in determining that these conflicts don’t exist.
Cost and commitment are important and impossible to predict in advance. All we can recommend is (i) making the expert commit to making specific personnel available throughout the litigation, (ii) making the ear-marked personnel coordinate their schedules with counsel at the outset of the engagement, and (iii) getting a commitment from the expert to freeze hourly rates and travel reimbursement policies throughout the engagement.
The intricacies of working effectively with experts are topics worthy of a separate article, and we will not pursue them in great detail here. We will note, however, that although the closer one works with and expert, the more it costs (just like with lawyers), a good expert can add value to the decisions about what claims to make, what evidence to present, how to preserve that evidence and what damages model to adopt. Finding an expert who has been involved in similar litigation, and involving him or her from the outset, ought to be a sound investment in the ultimate outcome of the case.
E. Budgeting the Case
All clients want to know how much a lawsuit is going to cost. Clients with prior experience in commercial litigation may demand a budget, and we certainly have never blamed them. We’ve also felt that the preparation of a proposed budget and timeline for a case is a necessary part of our engagement. Where possible, we like to make a client’s approval of the budget part of our engagement agreement.
Preparing a realistic budget, of course, is time consuming and often all but impossible until one knows the adversary’s appetite for the battle. However, counsel can always anticipate certain fundamental parts of the process that are going to be necessary. Reviewing the client’s IT system, interviewing users and taking the preliminary steps to preserve the evidence, for example, is always going to be necessary. Counsel ought to be able to make a ballpark quality guess about how long that particular step will take after the preliminary meeting with the client (if counsel has asked the right questions, anyway). We have never considered it an imposition for a client to ask us to make our best estimate of the time commitment required for a specific task and to ask us to try to live with that commitment.
Budgets for lawyers are as fragile as the client’s operating budgets, of course. Any budget must be presented with the appropriate qualifiers and disclosures. The important point here is to make sure the client understands the qualifiers up front.
F. Discovery Issues
IT litigation is more likely than most types of commercial litigation to require the client to discuss during discovery its most proprietary internal systems. Proof of damages may require disclosure of the most sensitive internal financial information. Any client simply has to make its piece with these possibilities if the case is to be successful. We always start by explaining the scope of discovery to the client. It may not save us a whole lot of impatient "This crap’s not relevant, we’re not producing it” conversations with a grumpy client contact later, but it helps bring those conversations to a peaceful end.
One cannot overestimate the importance of the client dedicating personnel to support discovery efforts. The coordination can be challenging:
- Witnesses may be difficult to locate, given personnel turnover in the industry;
- Witnesses may have to be interviewed or deposed in remote locations, given the requirements and time-critical nature of subsequent implementations being performed by the client;
- Counsel’s responses to written discovery, preparation of discovery to be served on the defendants and preparation for depositions all must be based on a realistic understanding of the client’s business processes. Only the client can assure that counsel gets it right;
- Counsel must coordinate discovery without disrupting the client’s business. An internal representative directing traffic is the best assurance that this gets done
Finally, counsel must remain focused throughout the discovery process on preserving the confidentiality of sensitive business information. Whether this is best done with protective orders, stipulations with opposing counsel or some combination of the two depends on the facts and the adversary. But the simple truth is that what constitutes an invaluable gem of proprietary business information may not be readily apparent to a busy lawyer. There needs to be continuing dialog between the lawyer and the client representative about what is important to the client in terms of confidentiality.
G. Trial Issues
The two fundamental issues in trying an IT case are to present the context correctly and to explain the technical issues in a way the jury will understand.
1. The Context
Someone on the witness stand is going to have to explain to the jury why this failed piece of technology-whatever it is- was so important to your client. We always try to introduce this evidence through one of the witnesses who is employed by the company, because it helps establish some empathy with the jury and because we just think it diminishes the possibility of that empathy if it comes in through the testimony of a hired expert. This initial witness must explain, in a way the jury can understand, the following:
-What components or the client’s IT system are affected?
- What is the purpose of each of these components?
- What did the defendant tell the client about how the product would work within the system?
- Why was the decision to purchase the defendant’s product or service important to the client?
- Was the cost significant to the client? If so, why was he willing to pay it?
- What sacrifices did the client make to pay for the product, to implement it and to get trained on it?
If this part of the testimony is done right, the jury should have the beginning of an understanding of the problem, the damages and the cause, as well as some degree of sympathy for the client. If the client’s technical people are hopelessly bad communicators, counsel ought to be able to present this kind of testimony through one of the managers on the operations side of the business.
2. The Technical Issue: Proving Causation
Proving causation or establishing liability is where the going gets slow in an IT case. One shudders at the prospect of having to put on an expert programmer to demonstrate how a particular program never had a hope of working, put sometimes you just have to warn the jury that the technical stuff is coming and then let them have it. There are ways to minimize the pain for all concerned:
- Emphasize courtroom technology. Demonstrating how something doesn’t work is going to be far more effective than telling the jury how it doesn’t work.
- Bring in a similar product that does work. Show the jury how this product ought to work and let them see what a great world it would be if your client had been given what he paid for.
- Find someone, expert, IT manager, low level user of the system if that’s who can do it, who can explain in lay terms what this product was purchased to do, what the defect in the product is, and what the result has been for your client. If it takes two hours of technical analysis, you probably shouldn’t have filed the case in the first place. A good witness ought to be able to present these points in a half hour of testimony.
- Remember, an IT system is an intricate, dynamic process that can be influenced by any number of variables: power sources, operators, ambient influences, network configuration issues that have nothing to do with how the defendant acted. You have to establish through your witness that you have considered what outside influences and operator errors might have caused the problem, how you have investigated those possibilities and why you believe that those possibilities are to be discounted. You can’t leave one "empty chair” for the defendant to point at.
- Finally, if your client has moved on, replaced the defective product and is operating efficiently by the time of trial, you’ve got to address the possibility that the jury will view this as a "no harm no foul” scenario. We like to give a human face to what our client has gone through. If the jury understands how the problem disrupted the lives of the people who had to fix it, they are going to be less inclined to treat the case as just a squabble over money by two big corporations. Our experience is that jury’s don’t respond well to dry sounding arguments between men in pin-striped suits. They do respond emotionally in defense of people who have been hurt by the sloppy work or fraud of someone else.
IT litigation is challenging in a number of ways. In the end, the real challenge for the lawyer is trying to take a uniquely abstract problem and give it human dimensions. Perhaps as great a challenge is shepherding the client’s management and IT personnel through a process that is going to strike them as expensive, illogical, and time consuming. There is no easy way to meet these challenges. However, in IT litigation, we have found that the challenges are best overcome when the client has bought in to the idea that he is an important part of the team that is going to take the case to trial, not a passive purchaser of legal services.
The same complexity, big dollar damages and intriguing trial issues that make IT litigation a challenge to the lawyers make it an absolute horror show for the clients, who really just want to get about their business. The best thing we can say about preparing for and handling IT litigation is not to forget that: your case is the last, most painful part of a protracted nightmare for the client. If you keep that image in mind in your client interactions, you are approaching the case the right way.