Fixed time/price contracts are always tricky. Once you've said 'it'll take this long' a client has a reasonable expectation that it will. You, of course, have a reasonable expectation that the client won't keep changing their mind or have unspeakable lurking horrors in their legacy code... both of you are kinda, sorta right and kinda sorta at the mercy of murphy's law ;)<br>
<br>A lot of time this stuff is all about managing expectations.<br><br>Tips for the future: - make sure you put in place some kind of official way to make changes to the plan - that you both have to agree upon before it goes ahead. As part of this, make sure your client realises that if the plans change (eg new requirements, adjustments to existing requirements or 'things they forgot to mention') - that you will have to readjust the time/price and usually not in their favour. Also make sure they are aware that a change will often have ripple-on effects, changing the timing of other things you've already estimated.<br>
<br>As to suddenly discovering that there's crazy code to fix instead of neat stuff... that's a toughie. I guess you could say that you can't really estimate how long it'll take to fix it until you've had a good, long look at it. A quick squiz often means you don't really get a feel for some of the lurking horrors in a legacy codebase... <br>
<br>Of course, it's much harder to convince a client that you can't just figure it all out on a quick look... <br><br>The best option, of course, is to shift off the fixed contract. However that may not be possible when you're a beginning contractor, sometimes you just have to do a few bad, fixed-price contracts until you have enough of a reputation to insist on time-based accounting.<br>
<br>My 2c :)<br>Taryn<br><br><br><div class="gmail_quote">2009/10/29 Rob Lacey <span dir="ltr"><<a href="mailto:contact@robl.me">contact@robl.me</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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>