[LRUG] Contact Work and setting limits

[Eleanor McHugh]

On 29 Oct 2009, at 15:04, Rob Lacey wrote:
> Hey guys,
>
> I wanted to ask for a bit of advice about contract work as I know  
> many of you are contractors or have contracted. I am wrapping up a  
> project with a client which has been troublesome to say the least. 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.
>
> The problem being that the client wants a working site, some of the  
> requirements fell outside of the original spec, and delivering a far  
> from finished article at the end of the quoted time was not really  
> an option. I can see from their point of view I quoted a time and  
> price, and delivered the project be it over a longer period of time  
> so they got what they wanted. But from my point of view the work I'm  
> 19 days down which is far from ideal.
>
> 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.

Based on my own nightmare experiences:

1. never estimate the cost of development until you've done a full  
code audit - and if the codebase is large enough that that takes more  
than two days, charge for;

2. never quote fixed price/time-scale on short projects: if you have  
six months of work on your plate there's a chance of staying within  
that timeframe, on a two-week project you're guaranteed to overrun;

3. fixed price means fixed spec, so make sure that every change  
request is documented and costed;

4. keep a backlog and review it regularly;

5. assume that things will go wrong at every stage;

6. the cardinal rule of software estimation: ALWAYS DOUBLE YOUR  
INITIAL ESTIMATE!!!!


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason