Insiders Tips On Software Development Pricing

What professionals know about pricing a custom software development project that most buyers don’t (and end up learning the hard way).

Having both won and lost our fair share of software project proposals, it appears that most buying decisions for large scale software projects typically come down to a choice based on three common factors. These are, broadly speaking, the quoted price and the perceived capacity to deliver and the more intangible ‘vendor likability’.

In this post, I’d like to suggest some of the challenges facing buyers of custom software and a few insightful questions that can be asked of any potential vendor.

Buying Custom Software Isn’t Like Buying A House

My observation is that many inexperienced purchasers of custom software think of the purchase as similar to buying a house. They expect to provide an initial brief, seek quotes (for price comparison) then select the more reasonably priced estimates and seek to evaluate a vendors demonstrable skill (capacity to deliver).

This process is certainly logical. However, it makes some assumptions that quickly come undone. To explain, let me show how a purchasing custom developed software project is radically different to buying a house in two important ways:

Complete house designs are cheap, often free – Custom software design takes time.

A house design can be readily copied for free (e.g. from a magazine or display property) or created (e.g. by an architect or drafts person) for a small fraction of the final cost of the house.
By comparison, the analysis required for a complete software design can represent a huge amount of the project budget (30% plus is common). When creating a custom software development solution, you as the purchaser by definition have a complex and unique problem to solve (or you’d use ‘off the shelf’ software or simple tools like spreadsheets). Given this unique and complex problem to be solved, there must be time for a developer to understand your needs (called requirements gathering) and create a plan to solve it (system design).

No body would accept the scenario where a builder charged $100,000 dollars to design a $300,000 house, but in software development, it’s common for a developer to only fully understand your needs and have created a plan for development 30% of the way through the process. Indeed it is only inexperienced developers who are fail to invest the required time to truly understand the problem at hand, with the outcome being the creation of a product ill suited to the buyers needs.

So the approach commonly taken is for custom software vendors to provide indicative ball park estimates (read educated guesses) and then firm up pricing (often with major variations) after considerable time has passed. Here at Alliance, we’ve take the approach of prototyping to create a full mock solution to enable customer feedback.

Houses, once built don’t change – Custom Software always changes

When you buy a house, you don’t expect to be adding an extension every year, year after year. After all, a house is essentially the ’shell’ that we live in, and the things we like to change (think of clothes, books, food in the cupboard etc) aren’t part of the ‘house’ itself. The precise opposite is true of custom software. If you think about it, custom software is created to automate a set of business processes. As soon as those processes improve (which they should consistently do), the custom software will likely require some updates to change with it.

The vast majority of the buyers of custom software make the assumption that once their initial set of requirements are serviced, that’s it, they’re done. After developing and subsequently managing the creation of numerous complex software projects, it’s clear that this almost never happens. Indeed yesterday, I sat in a meeting with a client arranging a number of changes to a reasonably new system. This client is educated, intelligent and right up till our first ‘go live’ was conviced they’d communicated all their needs. In their case, they realised that certain business rules, whilst nice in theory, needed to be broken from time to time. I can’t think of a single complex project where requests for changes haven’t come in regularly.

Often changes are because the people using a system discover that whilst an automated process (enabled by their custom software) is far better than the old manual process, the process they initial requested isn’t perfect and needs some adjustment. Or the marketplace changes, or other systems like the accounting package change, or most commonly, staff begin to see the potential for improvement and want more of it.

Whatever the reason, the only time that we’ve not had ongoing requests for changes to custom systems is because the client either ran out of money or changed their business focus.

So here are some tips to the prospective buyer of a custom software system:

1. Don’t spend all your money up front – you’ll want changes over time. So spend only a maximum of 50% of your total budget on the first phase of development. Indeed, you should aim to deploy the smallest version of a usable system possible. Then, after you’ve made your new system live, you can use the experience of using it to see what additions are most important (they almost certainly won’t be what you initially expected).
2. Own the IP in your system designs – Your developer doesn’t know what your system will cost until they’ve done the design. The initial estimates are just a rough guess. If, after the design process, when a fixed price is given, you get the nasty shock of an unexpectedly high price, then owning IP rights to the design documents (e.g. prototypes, requirements documents, design specifications) will enable you to ’shop’ the project elsewhere.
3. Confirm maintenance / update pricing where possible. It’s common for large software development companies to quote low, even below cost, on new work knowing that customers will find it very difficult to leave them. They then price gouge on the inevitable changes that come through. Clarify and agree in writing on the costs of work in the future. At a minimum agree on an hourly rate.
4. Beware the quick fixed price – Any vendor who attempts to give you a solid, fixed price on a complex project with only a basic investigation is guessing. This kind of guesswork is the common precursor to ‘professional blackmail’, where a vendor says, ‘yes, I know we have an agreement, but your project took longer than we expected so you need to pay more or we can’t afford to complete’. After you’ve spent your initial time and money, it can be difficult to say no (especially where vendors use fine print in contracts expecting this day to come).

Have a custom website project you’re consider? Contact us today.

This entry was posted on Tuesday, October 13th, 2009 at 4:39 pm and is filed under Strategy. 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.