I received the following email from TechRepublic member Carl Miller:

I recently had an instance where a client was asking about warranty on regular computer work that I had done for them. I’m curious to know what the TechRepublic community opinions on this topic may be.

Do you provide any warranty for your IT consulting work? I don’t. In fact, the only reference my contract makes to the quality of my work is to deny any liability “for any damages arising from the use of the software developed under the terms of this Agreement.” That doesn’t seem as though it would inspire confidence, now does it?

I’m a big believer in Tom Peters’ formula for success: “under promise and over deliver.” I haven’t always been good at following that principle, which is why I’m such a big believer in it. I’ve learned that lesson the hard way, by having to live up to the unrealistic expectations I created. The last thing I want to do is to codify in a legal document a promise that I might not be able to keep.

Another argument against warranties has to do with the type of service we perform. Consultants don’t typically create discrete products from scratch. We usually improve on existing products or practices, so what the client is paying for is our expertise and insight rather than something you can put your hands around. How can you point at any failure and say with certainty that it’s exclusively the fault of the consultant, unless it’s a blatant error?

Even in consulting work products that can be assigned a responsibility, how do you define a failure? Let’s say I developed a utility class for a client; nobody else touched that code, so it’s my responsibility. Within five years, the system constraints have changed (usually relaxed), which means that the client now uses what I created in slightly different ways (usually without realizing it). Maybe now the client’s application is multi-threaded, so a failure to be thread-safe is seen as a bug. But five years ago, the constraints on the system didn’t allow for creating a thread-safe solution. It looks like a bug now, and it is a bug for the client’s system now, but it isn’t my fault even though it’s happening in my code.

Okay, it probably sounds like I want to give all consultants a big free pass. We screw up, and clients should pay anyway because they’re paying for our time — that’s not how a good consultant conducts business. The most important principle for successful consultants is absolutely keeping your customers happy. So when something is really your fault, you have to own up to it and make it right. Even if it isn’t your fault, make it right anyway (within limits), and let the customer know how much time you’re giving them gratis. The goodwill you create can go a long way.

This doesn’t mean that you should promise you will do that in writing. Actions speak much more loudly than words, and the words only serve to give the lawyers a leg to chew on. I recommend under promising and over delivering.

How would you answer Carl’s question? Do you provide any warranties to your clients? If so, has that ever come back to bite you? If not, have you ever been questioned about that policy?

Get weekly consulting tips in your inbox
TechRepublic’s IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!