Sign off sheets

[EricDraven]

I am a programmer and recently received a call from a company which purchased an application about two years ago. At the time they had been extremely specific about what it should and shouldnt do. These guidelines were strictly followed and they have now discovered that there is actually a bug in the software based on those guidelines. The upshot of it is that I was swamped for a week where trying to get through my usual work I had to go back to a program written over two years ago (thank you documentation) and remember why everything did what it did!

I moaned about this to a friend who is also a software programmer and he said that he gets his clients to assess the software for a few days and then sign a "Sign Off" sheet. Basically that means that if it goes wrong and they have already signed, then he can say its not his problem and charge them full fees for the upgrades.

Now, we are a small company and need to keep clients happy. My friend on the other hand works for a large company with international clients!

So which approach is the ethically correct one? Do the rules change dependant on the size of the businesses involved and just how many other companies employ these "Sign Off" sheets?

Answers on a postcard please...

Arte Et Labore

 

[dgillz]

I see nothing unethical about a sign off sheet. HOwever hiding behind this can be a bad thing.

For example, if the bug discovered later was clearly in the original contract and not addressed, I say fix it for free (assumming it was a fixed price bid) regardless of the sign off sheet.

The sign off sheet concept for me is more of a way of getting the client to have a certain level of buy in and responsibility for the project.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

dgilsdorf@trianglepartners.com

 

[Kjonnnn]

In a sign off sheet, you probably could distinguish bugs that arise from a programming error vs. and error caused by their application specifications....

 

[CajunCenturion]

I agree with dgillz . I find nothing wrong with sign-off sheets and in fact have used them. But I don't think that it's right to hold the customer responsbile for testing and verifying that everything works according to specs in just a few days, especially in the application is rather complex and integrated. It is just as much our responsibility, and some could argue more, as a vendor to properly test everything as it is the responsibility of the customer.

My preference, as a software vendor, is take the position that we warrant the software will perform according to the agreed upon specs, in writing and signed by both parties of course. If a bug is found, with a bug being defined as the software not performing according to those very same specs, then we fix it for free. Anything else is chargable.

The sign-off in effect says that we have done our job to the best of our ability, and have delivered the product to the customer. But a sign-off does not relieve us of our responsibilities to make good on that which should have been done in the first place.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[guestgulkan]

The 'Sign Off' sheet ( also known as an 'Acceptance document') is quite a useful thing and is very common practice.

When a contract is made - the specification of how the software should be written down.
Also at that time any Acceptance criteria should also be laid down.

When the the software is delivered, it may or may not commissioned (tested and checked to work at the vendors premises, and any found bugs rectified) by the seller.

It should then be subjected to the 'Acceptance Tests' as laid down in the contract, and if all OK then the seller and buyer signs the 'Acceptance' document.
This is an important document - it passes a lot of responsibility from the seller to the buyer - otherwise the seller could end up with open-ended support and liability.

Once the acceptance has been signed, and any problems arise the seller can either charge or not charge for any fixes/upgrades - whichever the seller thinks makes the best business/customer relation sense.

 

[KornGeek]

On custom projects, we clearly state in our proposal that the only warranty is that the software will perform according to the specifications for the first 30 days. This gives them a limited time to report any problems. If the user doesn't install it for weeks (which has happened) this clause makes that their problem not ours.

When problems do arise after this time period, which is bound to happen, we deal with it on a case-by-case basis in determining if to charge, and how much.

The other issue that I've run into is the interpretation of the spec. When the spec says that the program will implement a certain feature, it has been known to happen where the customer will interpret that differently than we did. I generally give the customer the benefit of the doubt. This has cost me labor beyond what we earned on a project in some instances, but that is often better than an angry customer.

I've had customers violate their tech-support agreements and still helped them anyway. They have then provided good recommendations to other potential customers and have come back to bring us more business. The couple of hundred I could have made by sticking to our tightly worded contract would have cost me the thousands we've made by giving good service.

 

[BJCooperIT]

To my way of thinking clients who change their specifications and sign-off sheets are separate issues. Bear in mind that I have a simple perception of how things ought to work:

1. Write specifications of how everything should function
2. Develop system
3. System Test
4. Users sign the sign-off sheets agreeing that the system
functions according to specifications

...time passes...

5. Users change their minds/realize they made a mistake
6. Rewrite specifications
7. Modify system
8. Go to step #3

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
^{When posting code, please use TGML to help readability. Thanks!}

 

[lionelhill]

As a technical user I have no problems with the sign-off concept. If we buy a big expensive piece of analytical equipment, it will almost always be installed as part of the deal, and the engineer who does the installation will expect us to sign a bit of paper saying that the equipment has passed its installation tests (which he will also sign and leave with us). I like this, because it means I know the machine did work, at least once!

But the software that comes with the thing is usually assumed to work according to what the sales rep told us... and that is often a very big assumption. Over the later weeks we get used to the inexplicable crashes in the middle of the night, the fact the something button doesn't work, and the file menu lists files of the wrong type by default, etc. etc.

I know this is different, in that it's not custom-written software, but I'd still have nothing against being given some written specifications that it is supposed to do, and having a few weeks to test it does!