[LRUG] Contact Work and setting limits

[Sam Oliver]

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.

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.

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.

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.

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.

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

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.

This little story may not help in RobL's case now, but maybe it's useful to
someone.

--
Sam Oliver <sam at samoliver.com>
www.thinkpigment.com
www.twitter.com/samoli


On Thu, Oct 29, 2009 at 3:04 PM, Rob Lacey <contact at robl.me> 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.
>
> RobL
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20091030/24ec6413/attachment-0003.html>