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.

User Acceptance Testing

A formal process for demonstrating project completeness

Ever had a project where you thought you were done, but the client had other ideas? The project schedule may say all tasks are done, the QA tester may have successfully run through the System Test Plan, and the programmers may have cleared all known bugs. So why wont the client settle their account and let you get on with your next project? Easy, they don't know the project's finished, and why should they unless you can demonstrate without a doubt that you have delivered on everything you promised.

This is where User Acceptance Testing, or UAT comes to the rescue (also known as System Acceptance). It's not quite the finale of a project, but its getting close. You could say the Sign-off Agreement or Project Post-mortem is the real project end point. In essence, System Acceptance helps give closure to a project, without it, you may have a tough time convincing a client to sign the Sign-off Agreement (where the client formally indicates they are happy with the work you have done).

The actual structure of the document I use for System Acceptance is quite simple, filling it in is the tricky part.



The idea behind the System Acceptance process is to first make a list of every screen contained in the system, then you arrange a time to go sit with the client and systematically go through all the screens with them. For each screen, you ask the client two questions; 1) does the page appear error free?, and 2) does it perform all functions according to the spec? If the screen passes these criteria, its initialled by both you and the client. If you're thinking "oh god, doesn't that get really tedious after about twenty screens?", you are absolutely right. But as painful as it is, it will produce the desired effect; a tangible sense of closure within the client's mind. I recommend you forewarn the client of the less joyful aspects of the process, explaining that there will likely be multiple sessions lasting a few hours each, and that the process may seem inane at times, but you ask that they bare with you.

Now for some inconvenient truths. Will you complete the acceptance process in the first session you book with your client? probably not. As a rough guide, allow ten minutes per screen, a twenty page web application could take over three and a half hours. However, what tends to happen is the client really starts thinking about their software once they realize its almost over, its their last chance to make changes before they become indisputable feature additions. The result is that you may get side-tracked. The other issue is that a UAT session isn't meant to be a critique of interface cosmetics or functionality, but it can easily turn into such a discussion.



If the time consuming and tedious nature of UAT weren't daunting enough, there is another looming danger; bugs. Chances are good the client will discover bugs during the acceptance session. If you've been wondering what the 'Comments/Notes' column was for, now you know; to write down bug details. What will probably happen is a good portion of the screens will pass, and some wont. You will have to make arrangements for another session with the client after you've had time to get the bugs fixed. Eventually you'll have all screens signed off, then you are ready to present the client with the Sign-off Agreement.