[LRUG] Contact Work and setting limits

[Chris Mear]

On 29 Oct 2009, at 15:04, Rob Lacey wrote:

> I initially quoted 13 days to make ammendments to their existing  
> Rails application, and through the process this has stretched to  
> about 32 days work. So I badly misjudged the length of the project,  
> primarily because I hadn't realised how broken their app was and how  
> crazy some of the code was (to me at least), along with requirements  
> creeping in that I should maybe have said no to, and problems post  
> re-launch which may have been there all along but have reared their  
> ugly head only now.

This feels like two separate issues to me -- the issue of the client  
asking for more than you agreed on, and the issue of underestimating  
the time required due to the state of the existing code.

I've always had a clause in my contracts with clients (for fixed-fee  
projects) that goes something like:

"The Work will be restricted to tasks that, in [my company]'s opinion,  
work towards the goals described in the Proposal. If [the client]  
requests work, or if it becomes necessary to cary out work, on areas  
that, in [my company]'s opinion, are substantially outside the scope  
of the Proposal, additional agreement(s) and/or fee(s) may be  
necessary."

This seems pretty weighted in my favour, but I've never had a client  
who had a problem signing it. Part of the deal, of course, is that the  
accompanying 'Proposal' is fairly detailed about what they're getting,  
and what they're not getting.

A clause like this clearly covers cases of requirements creep, but it  
could also be argued that it covers unexpected shitty legacy code  
(i.e. it has become necessary to carry out work fixing up their code,  
which isn't really in core scope of making amendments to  
functionality). For that latter issue, though, it might have been  
better to request access to the existing code before committing to an  
estimate. You could argue (and your client might) that it was your  
responsibility to take this possibility into account in, or do the  
necessary investigation before, your estimate.

> How does anyone deal with the issue of estimation going horribly  
> wrong? And how would you broach this with the client, obviously they  
> thought it would take only the quoted amount that time, so its a  
> tricky one. Is it fair to approach them and come to some compromise  
> over the cost of the project or do you just pick yourself up, forget  
> it and be more mean (and realistic) with your estimates next time.

My inclination in this case (and of course this is dependent on the  
nature of your agreement with them) is that it's perfectly reasonable  
to ask them for money for the additional features requested that were  
not part of the initial estimate. The added time it took due to the  
code being worse than you expected? Well, I'd be inclined to take that  
on the head and treat it as a learning experience.

Bigger picture, you might want to ask yourself how positive your  
working relationship with this client is, and frankly about whether  
you're bothered about retaining them as a possibility for future work.  
This may help inform how much you push or lean one way or the other in  
your negotiations.

Chris