Sign-off Agreements

Getting closure on a project by using a sign-off document

A Sign-off Agreement is simply a document both client and technology supplier sign at the end of a project. In essence, it signifies that a client is happy with the work they have paid for.

You could say the Sign-off Agreement officially marks the end-point of a project, generally trailing behind UAT (also called System Acceptance). Could you close a project without a Sign-off Agreement? Of course, you may be thinking this process is overly bureaucratic, and that may be true for certain situations.

So, what's the point of the Sign-off Agreement? One reason behind it is to give everyone involved in the project a sense of closure. I would say this idea of closure is a good thing, for one it gives the development team a feeling of achievement. Another important aspect is it sets up a boundary relating to version control (i.e. version 1 is done). The concept of versions for web software is somewhat meaningless because of the ease with which updates can be delivered. However artificial, versions can be good for creating dividing lines between a delivered software package, and its next batch of features.

Probably the best answer on whether you should use a Sign-off Agreement on your project is 'maybe'. It comes down to a few key factors; the type of project you have, the kind of client you are working with, and the situation. For instance, if you are dealing with a government body then a certain degree of governance and process is to be expected. As often as possible, do try and use a Sign-off Agreement, but if you are in a situation where you need to concentrate more pressing tasks, then this process is a good candidate for culling.

An important aspect of the Sign-off Agreement is to make a statement about your Software Warranty. This is where you say how long you will be fixing bugs for free, and also what your definition of a bug is. Another way to think of this is as a rudimentary service level agreement (but without any commitments on turn-around time). Failing to discuss the idea of Software Warranty with your client leaves things open to interpretation and can setup the wrong expectations (e.g. a client may just assume you will be fixing bugs forever). How many months should you offer a warranty for? I don't know, that is really up to you. I have seen 3 months, 6 months, but I also know someone who basically fixes bugs for free no matter how long ago the software was delivered.



I like to keep the Sign-off Agreement to one page since I believe people have better things to do with their time then read long documents. I start with my Document Purpose section so someone picking up the sheet of paper can understand what it is about within a few seconds. The format of Sign-off Agreement I use is not designed to be water-tight from a legal perspective, that is not its purpose.

Towards the start of the document, I have a block called Agreement Parties, this just makes it clear who the client is and who the technology supplier is. The statement about the Software Warranty follows soon after.

The bulk of the document is the Terms section. The main point here is to say that your company has fulfilled all its contractual obligations and that the client is happy with what you have produced for them.

Something you may wish to discuss in the document is a maintenance rate for feature additions post-launch (also putting a time limitation on this quoted rate). I will probably be moving away from this style of agreement in favour of more flexible system involving Maintenance Blocks, but this is a discussion for future, after I have had a chance to road test the concept.



The last part of the document is an area for one of your company representatives to sign and date, and an area for the client to do the same (it is called a sign-off agreement after all).

A good tip for using a Sign-off Agreement is to give your client plenty of notice before presenting them with the document. It looks kind of legal, so it may make a client feel as though they are being backed into a corner and are about to relinquish control over their project. It’s important to explain what it is early on, for instance, just before or after UAT.

Reviewed by Patras Surna. Rev. 02.