Underestimating the Size of the Project

Freelance Software Development Mistake # 3

Source: Offshore Software Sucess
Author:Richard

Paul is an old friend of mine from college. He's always looking for an angle to get more than he really has coming.

A few months ago, Paul called me to say he was trying his hand at outsource software development. He was trying to get some free consulting from me, but that's typical.

It turns out, both Paul and the programmer he hired just figured out they underestimated the size of the project by a good bit.

I could tell Paul was excited but worried at the same time. He figured the programmer was over a barrel and would have to deliver. After all, programmers work hard to build a good reputation on the freelance site(s) where they get their work.

Still, Paul was worried, but could not put his finger on the reason. He figured there had to be some sort of down side, but couldn't see it.

Paul was right, this was not good situation for him or the programmer.

Here are some of the possible outcomes from this:

1) The freelance programmer sticks with it and gets the job done. If this happens and you don't reward him with a bonus, you're going to end up with a bad reputation as a buyer.

2) The freelance programmer cuts corners to finish up and move on to another project. This can be OK, as long as everyone agrees on which corners to cut. It can be really bad if the corners cut are randomly picked by the programmer.

3) The buyer and the freelance programmer renegotiate on the project and arrive at a mutually acceptable price/feature balance. You probably only want to do this if you have good experience with the programmer and are pretty far into the project.

4) The freelance programmer may just give up on the project if it seems hopeless. In this case, you just have to start all over.

You need to learn to estimate the size of software projects. It takes time and experience to learn this skill, but it's worth the trouble if you plan to do several projects. Now, you don't have to estimate down to the day, just getting a general sense of how long something might take is good enough.

Any good freelance auction/bid site will help you through this the first couple of times. Just contact the site's support and send them your project description. They can tell you roughly what it should cost.

This is especially true of sites that require you to put your project into small, medium, or large "buckets" based on project cost.

So how did Paul get into the situation above?

He took the lowest bid from an inexperienced programmer.

How did things work out for Paul?

He had mixed results. Paul pushed the programmer to finish the project. He did save a few dollars, even after giving a small bonus to the programmer. But the program did not really meet expecations.

Just goes to show, you get what you pay for.

Overall, Paul would have been better off to pay a bit more for work properly estimated. That way, he would get what he wanted from the programmer, not what he could get out of him.

That's all for now, next time we'll look at Mistake #4, it's a natural trap for anyone excited about their new software project.