[consulting] Contract > Developer liable for bugs?

[Bobby 1290]

See below:

> Date: Thu, 7 Aug 2008 18:02:54 +0100
> From: sean at practicalweb.co.uk
> To: consulting at drupal.org
> Subject: Re: [consulting] Contract > Developer liable for bugs?
> 
> Bobby 1290 wrote:
> > 
> > On an hourly basis , the client tests everything when the smallest 
> > module that is meaningful and ready to test, and SIGNS OFF on it when 
> > o.k. (end of liability). So here liability is restricted to a modular 
> > level. In this procedure if there is a problem, it is of a small 
> > magnitude, and can always be reasoned about.
> > 
> 
> While I want to limit my liability within reason I am also confident in 
> my ability to turn out good work - and I'm willing to express that 
> confidence in order to justify my rate.

This is not about ability, the topic as i understood it is "how to avoid disasters at the end of a project'
And in this way you can catch bugs at the earliest possible, and move 'change' requests to where they belong.

> 
> While I expect to be paid for the normal debugging cycle I want to 
> reassure my clients that they don't have to minutely supervise my work - 
>    and give them some contractual reassurance that if it is a load of 
> rubbish I'll fix it or they can sue me and my insurance will pay out.
> 

No, minute supervision is not need, but whatever their technical  level is, 
they are expected to know when what they ordered is not what they were given.
 
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)
If I'm not able to do this, then what I need is a food taster. 

In our case, we would need testers OR a service (contract) where you are technically running/adjusting the show after delivery.

> I have been on the other side of the negotiating table and found people 
> putting forward contracts where they still expected to be paid in the 
> event that their code didn't work. I wouldn't agree to such a contract.
> 
This is not the scope of my comment.
As I see it, if a testable module doesn't work, it has to be made working without added expense,
extra functionality however, is something different than a bug.

> 
> > On a project basis. The scope of the project is predefined. The 
> > test-cases are predefined. So you can budget and hire 'anyone' to do the 
> > testing for you. As a last test the client performs the tests ACCORDING 
> > TO THE ORIGINAL SPECIFICATIONS AND TEST-CASES, if it works, you are at 
> > the end of your liability, if it doesn't, you knew when you had it tested.
> > Every change is a follow up project or follow up hourly billing, no 
> > exceptions.
> > And of course, you'd be wise drill down to the modular level and let the 
> > client sign off after testing the 'modules'.
> 
> This requires a high level of skill from the client - if your client is 
> a development agency this is probably OK.
> 
> But if you want to work on a project for a non-technical client I think 
> it's often appropriate to factor into the project budget a (defined) 
> warranty period.

As stated before, a non-technical client should be able to tell if whatever was made is what they asked for or not.
If not, Testers can be had from third parties, which can be factored in.
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.
And if a client is non-technical as you put it, then factor in a service contract for them.
'Factoring in a warranty period' also sounds like they are paying for it, be it bugs or changes.

> 
> Fixed price contracts require a lot of specification and a fair bit of 
> trust.
> 
> If you try and nail down every bit of contract you'll spend all your 
> time negotiating - which isn't billable.
> 

No, there are standard forms and contracts for this, 
Your National IT association should be able to provide these.
But the main point is that you have to go into a negotiation knowing your limits,
When you know your limits and stick to them, you won't spend all your time negotiating.

> If you don't want to take any risk - stop contracting.
> 

There is always risk, but we try to mitigate excessive risk.
And every contractor is free to operate within the limits he sets for himself.
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. 

> -- 
> 
> Sean Burlington
> 
> www.practicalweb.co.uk
> 
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting

_________________________________________________________________
Reveal your inner athlete and share it with friends on Windows Live.
http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAGLM_WLYIA_whichathlete_us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20080807/dacd189a/attachment.htm