Wednesday, August 11, 2010

How to Buy Custom Software Development



When buying custom software development you have two choices on how the project will be bid; Hourly or by the project. So what are the pros and cons for both choices as a consumer? And which one is the right decision for you?

I'm not going to spend too much time on hourly projects because they are fairly self explanatory. 10 seconds into a phone call with a software vendor and you should have the hourly rate. It's a simple number. However, the problem with hourly projects is that you're at the mercy of the programmer. If your told it's about 100 hours of work then that number really has no legitimacy. After you have paid for 100 hours of labor and you find that the project is only halfway completed, then you have no recourse. This is particularly a problem with overseas companies whose only competitive advantage is low cost. It becomes a price war to be the lowest bidder.

What we are really debating here is risk and who is going to assume it. When a project runs long, someone has to pay for it. In an hourly project, the buyer is assuming that risk. With a fixed price, the programmer is assuming the risk. With software development projects there is inherently huge risk with every project.

The arguments for per project bids.

1. There is a cap on what you're going to spend. Theoretically there will not be any surprises.

2. There is never a "meter running." Your not making an investment decision every time you communicate with your programmer. You won't have to ask questions like, "is this issue worth a $100 phone call?"

3. If the programmer finds additional work within the scope that was unanticipated but must be performed, they can do it without having to come to you for additional funds. In those instances, additional work would otherwise be viewed as an attempt to generate additional billable hours.

4. This is the most uncomplicated way to work together. From the programmers perspective, they can put all of their time into coding your project rather than logging their hours.

The problems with per project bids

1. It takes research time to create an accurate quote. Depending on the size of the project, it can take 100 hours just creating an accurate bid. Someone has to pay for that research.

2. Once you agree on a price, the programmers job becomes getting the project done with the least amount of work in order to maximize returns.

3. Fixed bid projects mean that you're going to pay for the worst case scenario. If a company is going to issue a fixed bid price and assume the risk then they are going to pad the price - after all they don't want to come out at a loss on a project. So with a fixed bid price that means that your always paying for the worst case scenario.

So as a buyer, what is the smart solution for me?

The per project bid guarantees you that you have a ceiling on what your going to spend. You will sign a contract and it will encompass everything that your project is going to include. If the project goes long, that's not your problem. With a fixed bid contract, you can begin to trust your programmer as now they are your advocate in getting this project done as quickly as possible. And you have that contract to fall back on in the event the company you hire starts trying to extort additional dollars from you (assuming that the laws of your country apply to the programmer which is not the case with offshore software development).

One other suggestion is before committing to a programmer, google them. If they have been around for a while there will be some feedback on them - either good or bad. If there is not any feedback then you're still stuck relying on your gut instinct. I can't tell you how many potentially bad situations we have avoided just by Googling companies before we started doing business with them.

electronic cigarette seo

No comments:

Post a Comment