By completing the Rent A Coder requirements wizard, you can greatly increase the chances of on-time delivery. But even that is not enough, because a competent coder can still estimate incorrectly despite this.

To avoid an unpleasant surprise, we highly recommend that you take the delivery date that your coder estimated and calculate a realistic delivery date. That date will be either 5x or 2x longer than the coder estimated. You will not reveal this date to the coder, nor will you enter it into the site as an official date (since that would defeat the purpose). Instead, if the coder misses a milestone deadline and is still doing a good job, you will dole out some of the extra slack time that you have. And if they are not doing a good job, then you can still hold them accountable to the original date, and take the project into arbitration for a refund. This puts you in the driver seat.

Why are competent coders so bad at estimating?

There are a number of reasons. The main ones are:

• Unforeseeable problems:Many of the problems that come up during software development are unforeseeable. If you have ever started a “simple” home improvement project and later found it was much more complicated than you realized…then you know first hand how programming can be…even for the experts.
• Misunderstood/unclear requirements:When the requirements are unclear, the programmer usually underestimates what it takes to build your software. To use an analogy, they may estimate building your software as if it were a comfortable house. Only mid-project do they realize that you were expecting the Taj Mahal!

So, how do I handle this?

With a few simple but innovative management techniques, you can handle this problem so that it doesn’t derail your project:

1. The Realistic Estimate:Take the coder’s estimate and secretly calculate a more realistic estimate by multiplying their estimated time by 5. If the coder has given you the estimate after all of the requirements have been fully documented in a formal document (and/or prototype) and finalized, then you only need to multiply it by 2. (Click here to learn where these numbers come from.) Then, use this realistic estimate in your planning, rather then the coder’s estimate.It’s important that you NEVER share your realistic estimate with the programmer. If they feel they have too time to spare, they will not work as hard on your project and it will defeat the whole purpose of this technique. Do NOT enter the date into the Rent A Coder web site or put it anywhere where the coder might learn about it. Instead keep it like a secret in your “back pocket”.
2. Managing a missed deadline:Managing a missed deadline starts before the coder starts programming. If you wait until the end of your project to start managing them, your options will be much more limited than if you did it earlier in the process. To do this, tell the programmer that before they start programming, they must list out all of the tasks in the project and how long they will take to reach each milestone. Each task length should be 2 days or less. If it comes out to be more, then they should split into smaller sub tasks that are 2 days or less. This has been proven to produce more accurate estimates.Then let them start programming and have them report to you when each task is complete. If they finish every task as planned, then that is great. But if they don’t (which is more likely), then the minute they miss one, tell them to re-estimate it (and the remaining items, as described below). Remember, the slippage won’t cause you a problem, becuase you will have accounted for it in your realistic estimate.
3. How a coder should restimate tasks:It’s important that the coder re-estimate properly.. First, to ensure that they are doing a good job, require them to increase their commitment to your project (see “commitment terms” for more details”). Once they do, then tell them to re-estimate the time for the current task. Software estimation experts have found that if a milestones was missed by an amount (say 20%), then the programmer should add at least 20% to all other milestones as well. Programmers are often tempted to gloss over this, but you should insist on them doing this.
4. Stay in the driver’s seat:It’s important to understand that as long as you DO NOT reveal your secret delivery date to the programmer, you are in the driver’s seat. You can decide to dole them more time from your secret estimate. Or you can decide not to and take them to arbitration for a refund. However if you make the mistake of telling the coder that your realistic deadline is their “real” deadline, then you no longer have that option, and MUST give them ALL of that time. So it is always better to keep it hidden “in your back pocket”.

Where do we get these numbers from?

These numbers are taken from the book “Software Estimation: Demystifying the Black Art” by guru programmer Steve McConnell. McConnell graphed the inaccuracy of estimates on tens of thousands of projects that were done by expert estimators and found some interesting patterns. At the beginning of the project, their estimates were off by as much as 4x. When the formal requirements were complete, it was reduced to 1.5x. However, since most programmers are not experts in estimation, we recommend using 5x and 2x instead.

If you are interested in learning more about this concept, a good synopsis is at: http://www.construx.com/Page.aspx?hid=1648