<div>We recently rescued a failing fixed bid project and successfully switched it to a day rate.  It was one of the first projects we estimated for as a company so we were perhaps too keen to get it. We don't offer fixed bid now - but we had already made the mistake and weren't about to let our customer down.</div>

<div><br></div><div>The app ticked most of the boxes from the original spec. But requirements change, and it had become clear the app wasn't going to be useful to them as it was. We weren't happy to leave them with a useless app and offered them an additional free 40 hours to make it useful.  We saw this as our problem as much as it was theirs. </div>

<div><br></div><div>The next trick was how we invoiced.  Instead of working the next 40 hours for nothing, we deducted 40 hours from the original estimate and sent the remainder of the big invoice. We told them that from now on we'll simply charge at an hourly rate and invoice at the end of each month.</div>

<div><br></div><div>This got our first invoice paid (albeit a bit less than it was). I now expect the project to carry on past the additional 40 hours to perfect and maintain their app., they'll just be in the swing of paying us each month.</div>

<div><br></div><div>The project went good very quickly.  Charging on an hourly rate improves the behaviour of the client. Communication is far better - we're discussing the right things at the right time. It's the right choice for agile. Although we didn't make as much as we estimated for the initial stage, we now have a good, happy long term client.  </div>

<div><br></div><div>The great thing is that the cost to us of deducting the 40 hours in effect switched them on to our long term project rate for the first stage (i.e. we had some contingency built in to the estimate).</div>

<div><br></div><div>With any client problem, always try and start with the attitude that you are partners, and that the problem is shared.  Think about what you want to achieve rather than who is right or wrong.</div><div>

<br></div><div>This little story may not help in RobL's case now, but maybe it's useful to someone.</div><div><br></div><div>--<br>Sam Oliver <<a href="mailto:sam@samoliver.com">sam@samoliver.com</a>><br><a href="http://www.thinkpigment.com">www.thinkpigment.com</a><br>

<a href="http://www.twitter.com/samoli">www.twitter.com/samoli</a><br>
<br><br><div class="gmail_quote">On Thu, Oct 29, 2009 at 3:04 PM, Rob Lacey <span dir="ltr"><<a href="mailto:contact@robl.me">contact@robl.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hey guys,<br>
<br>
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.<br>


<br>
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.<br>


<br>
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.<br>


<br>
RobL<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br></div>