Professional Webmaster Business Issues Forum

what rights does the client have if the project turns out to require a LOT more time and money than the developer said it would?

Some of the contracting sites force the developer to pay 10% guarantee upfront to take the work - this is a good idea. When they miss a deadline you have the right to cancel the project. The problem with this is you will never get your project - every developer delivers late.

When contracting out a job directly, without the safety of escrow, the client need to carefully consider how they will handle time, budget and spec trade-offs. It’s all down to the contract terms and payment schedule you define.

An estimate is by definition a rough judgement, but how rough is too rough?

Until the scoping is done there is no way to tell. After scoping the cost agreed is typically fixed and is the maximum that will be paid based on all deadlines met. If you are choosing someone who uses a set product and has done many projects with it then they should be much better at estimating. For bespoke work you may want to multiply by 2 or 3 depending on how well you know them

What responsibility does a developer have to make realistic estimates? Is there such a thing? What are best practices here?

Its best if the client set the timescales and choose a developer that commits to meet it. Normally the budget is fixed, so set milestones for deliverables based on the business goals and massage the spec a little to meet the plan, possibly allowing for a release 2 to finish the low priority requirements, rather than increasing the timelines on release 1. A longer project generally leads to lower quality and higher costs.

What kinds of questions should clients be asking (and possibly getting written into the contract) to protect themselves against being sabotaged by bad cost estimates and missed deadlines?

Definitely ask about there capacity to add resource if things start to slip. Find out their holidays and working hours. Ensure you can communicate frequently and easily. I have the world clocks on my desktop for the time zones I work in and the developers all in skype, this really helps

The best technique is constant communication & a bit of encouragement and praise can help.

Constant delivery (every couple of days) through a very small length project is the no.1 objective.

If you take the pressure off and stop communicating they see this a signal that its not a priorty for you & will work on anoither project. If you give them more than 4 weeks for a project they may decide to do another project first.

This needs the client to invest more time in the spec or have a spec written as a separate project and allow more time for daily project management / communication.

A good technique we use is called critical chain (there is a Goldratt book by the same name). Developers do 3 bad things for project management:
1. Overestimate to build in contingency to manage risk
2. Take all the time given for each task – rarely completing early even though they added contingency
3. Struggle to start and then go nuts near the final deadline

So a fake final deadline with compressed tasks is critical to get them moving at the right pace. Its sounds complex in the book but it’s actually very easy to do critical chain in a spreadsheet –

1. Create your project critical path as normal.
2. Half all the task-time estimates
3. Add on 50% of each task saving as an explicit task buffer
4. Combine all the other 50%'s and make a single project buffer after the last task so the final deadline is now after a very large buffer, but still the same date.
5. Save this as *your* project plan
6. Remove *all* buffers and re-schedule the tasks ASAP from the start date so you have an end date that is now 50% earlier.
7. Publish this to the developer as the real plan

Now when a task overruns you will know if you are in a task buffer (amber) or eating into the project buffer (Red) and can take action accordingly.

In over 5 years in business I have only eaten crow on 1 or 2 projects where what I thought it was going to take was wrong and I ended up with a lot more time into the project. In most cases I either come out just right or even ahead. I figure this is just a risk I have to absorb because in my experience nobody likes an open ended project.

Always charge too much, because if you care about your work it won't be too much anyway and it offers protection, though miscalculations aren't usually an issue once you've got enough notches in the gun (projects in the portfolio). I have over-quoted a couple of projects that went flawlessly start to finish and at the close of the project refunded a percentage of the agreed cost. That's been rare but the long-term payoff in each case far exceeded the give-back.