What are the “Norms” of IT Contracting?
The world of computers and information technology (“IT”) has developed some unusual norms in warranties and allocating risk. In other industries, they might seem absurd, but not in IT. As long as you understand the significance of the way IT contracts are done, you can come to a fair deal.
As a preliminary matter, let’s clarify that I’m using the broad term “IT” in a broad sense. The same principles will apply whether we’re discussing outsourcing your entire IT department, hiring somebody to design an e-commerce site for your company, subscribing to Cloud or SaaS services, buying hardware, just having some software customized for you, or coming up with the next great social network. Whatever it is, many of the same contracting norms apply.
Warranties
If your new car doesn’t work, you take it to the dealer for repair. Knowing what it’s supposed to do is easy. After all, it’s a car. Everybody knows what a car’s supposed to do.
It’s rarely that easy with IT-related contracts. Certainly, it could be that the computer doesn’t turn on or that all network communication is down. These would be easy cases. As long as you have anything that looks or smells like a warranty in your agreement, you should be covered.
The problem arises because it’s just never that simple. Typical IT problems are more like “the computer is too slow,” “the network is too slow,” “the system crashes too often,” or “the website doesn’t have some of the functionality we expected.” These are the types of problems that can lead to ugly disputes.
There’s no magic after the problem arises. The solution is careful contracting at the front-end.
It’s good for both sides of the deal. I say that as a tech lawyer who represents those who sell tech services as well as large businesses that buy these services. Careful contracting is good for everyone in the deal because it insures that the parties have a true understanding of the other side’s expectations.
There is no doubt that taking the time to carefully contract for IT services slows the date of the contract’s signature. Contracting, like any other process, simply takes time. Still, it can save you if things go less than perfectly.
Using the development of a complex e-commerce website as an example, the norm in the IT industry is a vaguely worded warranty that says that the website will function according to its specifications, or some other vague document or attachment to your contract. The point is that the standard the website must meet is this “other document.”
It’s the norm because it’s easy and provides at least some guidance. It’s also often a poor way to go because it often doesn’t have the objective standards against which you’ll later want to judge your website.
Having said all this, have I ever had contracts where I’ve used some vague specifications as the benchmark for the warranty? Yes, I have.
The reason is actually quite simple — it’s time and money. Quite frequently, the parties don’t want to take the time or spend the money necessary to prepare a more meaningful warranty. We all know what a car should do. There’s no similar common sense benchmark by which to judge IT work. If you don’t specify things in your contract, you may find yourself staring into the face of a bad situation.
IT contracting is often a time consuming and resources draining project. It takes effort to negotiate a deal and develop things like performance standards and acceptance testing procedures.
You can choose to march ahead with a contract that has as much definitive and clear material as a politician’s stump speech. If all goes well, you’ll feel like you made the correct judgment. In fact, you were just lucky. This method is okay for the desperate and those who like to play in the dark.
Who Takes the Loss?
When things go wrong in the world of IT, they can have far reaching consequences. If your office network goes down, you have all the losses that go with the lack of productivity of your employees. If you’re an airline and your reservation system crashes and burns, it’s obvious how disastrous that can be. Who pays for these losses?
In IT, the answer is that the customer usually bears these risks. We can argue about how fair it is. The airline could say something like, “Let me get this straight. I pay you $5 million to update our reservation’s software. It stops functioning, I lose millions of dollars and you think that you shouldn’t be responsible for that loss?”
The standard IT answer to the question is “That’s right!”
The developer’s perspective may not be obvious to many customers, but it does ring of legitimacy in many cases. As the customer, you must build mission critical systems with enough redundancy and over capacity to prevent catastrophic mishaps.
The argument would be that it was the airline in our scenario, which decided that running a parallel reservation’s network or providing for more capacity was too expensive.
Similar arguments are made when other IT disasters happen. If you lose data, the vendor says that you should have had better backups. I could create other examples, but the point remains the same. It’s up to the purchaser of IT services to create enough redundancy to protect against unacceptable losses.
The vendor’s answer to legitimately broken or poorly performing IT products is “response time,” not money. You must largely accept this fundamental norm.
Yes, there are exceptions. I have seen and negotiated contracts with real teeth against vendors, but they are the exceptions.
So, as a buyer of IT goods and services, focus on what you can get. You should always negotiate for better response time guarantees than are first being offered. Follow this up by requesting specific escalation provisions, which helps to insure that if level one support can’t get the job done in a reasonable amount of time, it will move up through the vendor’s chain of command quickly. Good response time and escalation provisions can be worth their weight in gold when you’re in crisis.