Business Savvy Software

I’m a big fan of fair valuation and pricing software development is a good example of why.

Its easy for small fixed price software projects to turn into lose-lose situations, usually because they are too cheap. The customer gets what they paid for and the developer starts to lose money fast as the project drags on. The customer expects a perfectly working system for the agreed price and the developer either carries on losing money (but doing a poorer job) or calls it scope creep and delivers an incomplete project.

Software projects are hard to estimate and therefore price, but often this makes no difference to the price of the project. The problem is often that a market valuation of the project is used, instead of a fair valuation.

The market price is what the customer is prepared to pay and what the developers are prepared to deliver for, but it can be well under (or above sometimes) the fair price and can have nothing to do with the project being under-spec’ed or under-estimated.

The fair price of a project means charging a fair and profitable amount for the work to be done/delivered. Estimating the development required for a project is easy compared to estimating the other work to be done, but for delivering a simple software project, a good rule of thumb is that the project will be 3 times the size of the development work.

The market price of a project can be significantly lower than the fair price for a few reasons:

• The fair price makes the project un-viable, so the customer’s cost/benefit dictates the price they are willing to pay
• The customer has limited cash or budget and the developer wants the work
• Competition are prepared to deliver the project for lower than the fair price

Unfortunately, you can’t just quote the fair price, because if this is significantly above the market price, then you’ll lose the project.

One way to bridge the difference between market and fair price is to find a pricing model that fits the project. Software is very rarely a single deliverable, so the pricing shouldn’t be either. Once you know the fair price, you need to communicate this to the customer, so they understand the full scope of the project before they enter it. Then, you need to understand what the market value is (from the customer’s perspective is best) and structure the project so that the cost/benefit stacks up for the customer after every deliverable.

This entry was posted on Sunday, February 17th, 2008 at 8:16 pm and is filed under Business, Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.