« New Hashrocket Client Video: Todd Siegel | Main | BizConf 2010 Announcement - Save the Date »

November 22, 2009

(MSA Series #4) Warranties

BUY THE ANNOTATED MSA+SOW DOCUMENT TEMPLATE BUNDLE!

The documents discussed in this blog posts are now available from me for only $99. Click here to learn more.

 

This is the fourth entry in a long-running series of blog posts about the Hashrocket Master Services Agreement (MSA). Parts onetwo and three are also available. When the series is finished, you might be able to piece together a valid MSA document from the examples presented here. However, keep in mind that I am not a lawyer, and that the context of your business may be different than mine. Also, remember that laws vary wildly from country to country and what is presented here might be useless outside of the USA.

Section 5, Warranties

This section of the MSA establishes what warranty, if any, you are guaranteeing on the work performed under the scope of your contract with your client.

The first clause is a bit of legalese stating that each party is authorized to enter the agreement:

5.1 Warranty of Authority; No Conflict
Each party warrants that it is authorized to enter into this Agreement and to perform its obligations hereunder, and that its performance hereunder shall not conflict with, limit or be contrary to any other agreement. 

The second clause of section 5 establishes a warranty on the nature of the work provided, that it will be performed in a professional manner and by qualified personnel.

5.2.1 Professional Manner Hashrocket warrants that all services will be performed in a professional manner using qualified professional personnel. 

Of course, the words professional and qualified are subjective, which means they could be the basis of dispute later on, if problems were to arise. I've been involved in arbitration hearings as an expert witness, testifying on whether work performed lived up to generally-accepted best practices and industry standards. Some of the big factors that affect whether I consider a Rails project to be professional have to do with the quality of testing on the project, and adherence to the Rails conventions and best-practices.
This paragraph edited on 9/23, because the original wording made it sound like I was casting judgment based on my book The Rails Way.

The following paragraphs are of terrific importance in terms of protecting the vendor from unreasonable liability, which is why they are printed in prominent all-caps:

THE WARRANTIES SET FORTH IN THIS AGREEMENT ARE EXCLUSIVE AND ARE IN LIEU OF ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. EXCEPT WHEN OTHERWISE STATED IN WRITING THE MATERIALS PRODUCED UNDER THE TERMS OF THIS AGREEMENT ARE PROVIDED TO CLIENT "AS IS," THAT IS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE AND/OR SERVICES PROVIDED UNDER THIS AGREEMENT RESTS SOLELY WITH THE CLIENT.  SHOULD THE SOFTWARE OR PROGRAM PROVE DEFECTIVE, CLIENT SOLELY ASSUMES THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION, INCLUDING WITHOUT LIMITATION ANY "DEBUGGING."

Significant in this paragraph is the stipulation that work is provided as is, that is, the client cannot force you to continue working on the project if you don't want to do so, or for free. The fact that you are not providing a warranty decidedly does not mean that you are planning to give your client junk. In fact, unless you have a great reputation and client testimonials to back it up, you're probably going to have trouble getting clients to agree to this clause.

There's more to this clause, specifically the stipulation that the client is solely responsible for the "risk as to the quality and performance of the software." The only effective (and moral) way that I know to put that risk on your client is to establish small feedback loops via a well thought-out acceptance process. At Hashrocket, we use the features of Pivotal Tracker to facilitate constant, ongoing acceptance of story functionality and tracking of defects. Delivery of new features and bugfixes happens on a daily basis and so does client acceptance.

The following graph, generated by Pivotal Tracker as part of its Project Points Breakdown report, visually shows progress of a project along the stages of our workflow. The overall height of the bars gives an indication of scope. As the black bars (unstarted work) shrinks, you can see the project headed towards completion.

Picture 4
The vertical axis denotes the number of story points in the project. Note how narrow the bands of green (Delivered) are during the progress of this project. The graph tracks the state of stories on a daily basis. Green bars represent functionality that has been delivered to the staging server for the client to test, but not accepted yet. Occasionally the circumstances cause the client to fall behind for a day or two, but gentle pressure and assistance brings them back in line.

I won't try to explain the legalese of the second all-caps paragraph, simply because I don't necessarily understand it fully myself. This text is in there under the strong advise of our lawyer.

EXCEPT AS OTHERWISE STATED ABOVE, NEITHER PARTY MAKES ANY WARRANTIES OF ANY KIND OR NATURE, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES RELATED TO INFORMATION OR BUSINESS ADVICE PROVIDED, WARRANTIES RELATED TO OUTCOMES BASED ON INFORMATION OR ADVICE PROVIDED, WARRANTIES OF MERCHANTABILITY OR MERCANTILE QUALITY, WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE OR USE, WARRANTIES OR CONDITIONS ARISING BY STATUTE OR OTHERWISE IN LAW, OR WARRANTIES OF ANY PRODUCTS OR SERVICES PROVIDED BY THIRD PARTY VENDORS.

What I will say is that the wording of this paragraph, and indeed all of the all-caps paragraphs are of supreme importance. There is established case-law about these kinds of warranties, and mucking with the wording is a good way to have the entire clause invalidated.

Finally, the supremely-important liability disclaimer, which helps ensure an angry client doesn't put you out of business.

THE PARTIES AGREE THAT NEITHER PARTY’S LIABILITY FOR DAMAGES FROM ANY CAUSE OF ACTION WHATSOEVER, REGARDLESS OF THE FORM OF ACTION, WILL EXCEED THE FEES PAID OR TO BE PAID BY CLIENT PURSUANT TO AN APPLICABLE STATEMENT OF WORK UNDER THIS AGREEMENT. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR LOST PROFITS OR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL OR SPECIAL DAMAGES OF ANY NATURE WHATSOEVER, INCLUDING, WITHOUT LIMITATION, DAMAGES ARISING FROM LOSS OF USE OF ANY SOFTWARE OR HARDWARE, COSTS OF PROCUREMENT OF SUBSTITUTE PRODUCTS OR SERVICES, LOST DATA, LOST PROFITS OR REVENUE, OR FOR ANY CLAIM OR DEMAND BY ANY THIRD PERSON, ARISING OUT OF OR RELATED TO THE AGREEMENT OR THE PERFORMANCE OR BREACH THEREOF, EVEN IF ADVISED OF THIS POSSIBILITY.

If things go completely wrong and lawsuits are filed, you agree beforehand that the maximum liability incurred will not exceed the amount of money that has changed hands. In other words, if you completely fuck up the project, no matter how hurt the client is the most he can do is to get his money back. Absent this stipulation, you could face lawsuit claims in the millions of dollars to account for all sorts of opportunity costs and damages asserted by the client. Luckily this language is fairly common in service contracts.

5.2.2 No Infringement The parties represent and warrant that their disclosure and delivery of any information, documents, software and other materials, and use thereof, as contemplated by this Agreement, will not knowingly infringe or violate any proprietary right of any third party, including, without limitation, any copyright, known patent or trade secret right.

This clause is entirely for the protection of your client. It binds you to a promise not to deliver intellectual property to them that belongs to someone else. In practice this prevents you from taking code that you've written for Client A and selling it again to Client B, without the express knowledge and permission of Client A. Since it's common for software consultancies to produce non-domain-specific code with potential for profitable reuse across clients, a different clause in the MSA establishes a method of differentiating intellectual property produced under billable time, and how the rights to such vary.

5.3 Noninterference with Business
During the term of this Agreement and for all periods thereafter, Hashrocket agrees not to directly or indirectly compete or interfere with Client’s Business in any manner.  Additionally, and without limiting the foregoing, during the term of this Agreement and for a period of two years thereafter, Hashrocket agrees not to, directly or indirectly solicit or induce or attempt to persuade any employee, independent contractor, vendor, supplier, outsourced third-party, director or other participant of Client to terminate an employment, contractual or other relationship with Client, or to enter into a relationship with Hashrocket or into any business organization in which Hashrocket may be directly or indirectly involved.  The term “enter into a relationship” shall include, but not be limited to, acting as a paid or unpaid director, officer, agent, employee of, or consultant to, or acting or participating as owner, partner, manager, member, or shareholder.  During and for a period of two years immediately following termination of this Agreement, Hashrocket further agrees not to (a) directly or indirectly contact any person or entity disclosed by Client for the purpose of taking advantage of a business opportunity, (b) otherwise circumvent a relationship with the Client  or establish a relationship with a party with whom Client already has a relationship or foreseeable relationship with whom Hashrocket has never had a relationship, or (c) seek to establish any rights, including but not limited to intellectual property rights, anywhere in the world in conflict with Client’s pre-existing, herein established, or hereafter established intellectual or other property or proprietary rights.

Interestingly, as I was reading this clause for inclusion in the article, it struck me that its limitations are not mutual. (I'll be fixing that soon.)

All this final paragraph of the section does is to limit you as the vendor from screwing your client in various ways, such as poaching their business model or employees, behavior that would harm your reputation and future business anyway. It's smart to make your clients feel comfortable that you won't engage in nasty behavior as described above. You should keep aware of this clause, particularly as it applies to hiring people that work (or used to work) with your clients.

The next article in the series will cover Fees, Invoices and Payments.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fdca91188330120a6c634fc970b

Listed below are links to weblogs that reference (MSA Series #4) Warranties:

Sponsored By

Flattr

or visit my my homepage

My Companies

My Latest Books

My Book Series