<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
See below:<br><br>> Date: Thu, 7 Aug 2008 18:02:54 +0100<br>> From: sean@practicalweb.co.uk<br>> To: consulting@drupal.org<br>> Subject: Re: [consulting] Contract > Developer liable for bugs?<br>> <br>> Bobby 1290 wrote:<br>> > <br>> > On an hourly basis , the client tests everything when the smallest <br>> > module that is meaningful and ready to test, and SIGNS OFF on it when <br>> > o.k. (end of liability). So here liability is restricted to a modular <br>> > level. In this procedure if there is a problem, it is of a small <br>> > magnitude, and can always be reasoned about.<br>> > <br>> <br>> While I want to limit my liability within reason I am also confident in <br>> my ability to turn out good work - and I'm willing to express that <br>> confidence in order to justify my rate.<br><br>This is not about ability, the topic as i understood it is "how to avoid disasters at the end of a project'<br>And in this way you can catch bugs at the earliest possible, and move 'change' requests to where they belong.<br><br>> <br>> While I expect to be paid for the normal debugging cycle I want to <br>> reassure my clients that they don't have to minutely supervise my work - <br>> and give them some contractual reassurance that if it is a load of <br>> rubbish I'll fix it or they can sue me and my insurance will pay out.<br>> <br><br>No, minute supervision is not need, but whatever their technical level is, <br>they are expected to know when what they ordered is not what they were given.<br> <br>I am no cook, but I know when my food is served too cold or with way too much salt, (and that is subjective, as is everything)<br>If I'm not able to do this, then what I need is a food taster. <br><br>In our case, we would need testers OR a service (contract) where you are technically running/adjusting the show after delivery.<br><br>> I have been on the other side of the negotiating table and found people <br>> putting forward contracts where they still expected to be paid in the <br>> event that their code didn't work. I wouldn't agree to such a contract.<br>> <br>This is not the scope of my comment.<br>As I see it, if a testable module doesn't work, it has to be made working without added expense,<br>extra functionality however, is something different than a bug.<br><br>> <br>> > On a project basis. The scope of the project is predefined. The <br>> > test-cases are predefined. So you can budget and hire 'anyone' to do the <br>> > testing for you. As a last test the client performs the tests ACCORDING <br>> > TO THE ORIGINAL SPECIFICATIONS AND TEST-CASES, if it works, you are at <br>> > the end of your liability, if it doesn't, you knew when you had it tested.<br>> > Every change is a follow up project or follow up hourly billing, no <br>> > exceptions.<br>> > And of course, you'd be wise drill down to the modular level and let the <br>> > client sign off after testing the 'modules'.<br>> <br>> This requires a high level of skill from the client - if your client is <br>> a development agency this is probably OK.<br>> <br>> But if you want to work on a project for a non-technical client I think <br>> it's often appropriate to factor into the project budget a (defined) <br>> warranty period.<br><br>As stated before, a non-technical client should be able to tell if whatever was made is what they asked for or not.<br>If not, Testers can be had from third parties, which can be factored in.<br>A defined warranty period can also be factored in. But I can't see how that works in practice, what are you guaranteeing after everyone has concluded that it works? It sound like an ongoing service to me.<br>And if a client is non-technical as you put it, then factor in a service contract for them.<br>'Factoring in a warranty period' also sounds like they are paying for it, be it bugs or changes.<br><br>> <br>> Fixed price contracts require a lot of specification and a fair bit of <br>> trust.<br>> <br>> If you try and nail down every bit of contract you'll spend all your <br>> time negotiating - which isn't billable.<br>> <br><br>No, there are standard forms and contracts for this, <br>Your National IT association should be able to provide these.<br>But the main point is that you have to go into a negotiation knowing your limits,<br>When you know your limits and stick to them, you won't spend all your time negotiating.<br><br>> If you don't want to take any risk - stop contracting.<br>> <br><br>There is always risk, but we try to mitigate excessive risk.<br>And every contractor is free to operate within the limits he sets for himself.<br>Personally, I will repair bugs at no extra cost, but there must be a verifiable endpoint to all projects, and changes are to be marked and billed as such. <br><br>> -- <br>> <br>> Sean Burlington<br>> <br>> www.practicalweb.co.uk<br>> <br>> _______________________________________________<br>> consulting mailing list<br>> consulting@drupal.org<br>> http://lists.drupal.org/mailman/listinfo/consulting<br><br /><hr />Reveal your inner athlete and share it with friends on Windows Live. <a href='http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAGLM_WLYIA_whichathlete_us' target='_new'>Share now!</a></body>
</html>