GIBSON~GRUENERT
L.L.P.
ATTORNEYS
& COUNSELORS AT LAW
TEXAS
- LAFAYETTE
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 dependant 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.
G.
Conclusion
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.
Copyright 2002
Gibson~Gruenert L.L.P.
Page updated
03/10/2008
|