The Risks of Custom Software Quotes

When con­sid­er­ing a soft­ware de­vel­op­ment pro­ject, it is im­por­tant to un­der­stand the risks in­volved with em­bark­ing on that jour­ney. One in­her­ent risk that peo­ple of­ten over­look is the risk as­so­ci­ated with ob­tain­ing a quote too early in the plan­ning process. Understandably, peo­ple are ea­ger to find out the ticket price to build their soft­ware, how­ever this comes with a host of other com­pli­ca­tions. In this ar­ti­cle we will ex­plore two com­mon is­sues.

1. Lack of in­for­ma­tion

When ob­tain­ing a quote for soft­ware de­vel­op­ment, the more in­for­ma­tion given to the de­vel­oper, the more ac­cu­rate the quote can be due to known work needed for suc­cess­ful pro­ject de­liv­ery. When peo­ple re­quest a quote too early, this puts de­vel­op­ers in an awk­ward po­si­tion with a large num­ber of un­knowns in what is ac­tu­ally re­quired for this pro­ject. This in turn can leave way for an un­pleas­ant de­vel­op­ment ex­pe­ri­ence.

A great ex­am­ple for lack of in­for­ma­tion caus­ing frus­tra­tion in soft­ware pro­jects is the QLD health pay­roll up­grade. The pro­ject started in 2006, and looked like a sim­ple pro­ject, with a bud­get al­lo­ca­tion of $6 mil­lion AUD. Fast for­ward 5 years and the pro­ject was $25 mil­lion AUD over bud­get and still lack­ing core sys­tem func­tion­al­ity, all due to lack of proper plan­ning and in­for­ma­tion gath­er­ing.

a. Cone of un­cer­tainty

The cone of un­cer­tainty is shown be­low. This is a vi­sual rep­re­sen­ta­tion of risk and ex­em­pli­fies the im­por­tance of know­ing as many re­quire­ments of a de­vel­op­ment pro­ject be­fore ob­tain­ing a quote. Moving from left to right you can see the move­ment away from a place of high cer­tainty and lower risk into a place of less cer­tainty and higher risk. It ac­counts for the lack of cer­tainty in the fu­ture. This is why it is im­por­tant to know as much as pos­si­ble be­fore de­vel­op­ment, and why we must com­plete a scop­ing process.


b. Scope

The scope is our process of be­gin­ning work on your pro­ject. Once the scope is known, so too is the likely time and cost to com­plete the de­sired func­tions. In this phase we ex­plore the prob­lem and un­cover a so­lu­tion that your soft­ware is pro­vid­ing its users. We move through 4 se­quences (discovery, in­spi­ra­tion, ideation and re­al­i­sa­tion). The process typ­i­cally is any­where from 2-4 weeks de­pend­ing on re­quire­ments.

Under/Over Quoting

Another risk as­so­ci­ated with ask­ing for a quote with­out em­bark­ing on a scop­ing process is that the de­vel­oper will be at a higher level of risk due to un­cer­tainty of work re­quired be­fore en­ter­ing scope. This in turn causes both un­der/​over quot­ing on time and money re­quired for a suc­cess­ful pro­ject de­liv­ery and will al­most al­ways end in dis­ap­point­ment. Projects started with­out go­ing through a scop­ing phase can cause dis­ap­point­ment through ei­ther the soft­ware be­ing of a sub­par stan­dard, or from the de­vel­oper hold­ing your soft­ware ran­som whilst you pay the ex­tra funds needed to com­plete the pro­ject. On this point, al­ways triple check who owns the IP. If you’re pay­ing for de­vel­op­ment ser­vices, our stance is that the IP should re­side with you as the cus­tomer.

We mit­i­gate these risks through our Way of Working, which is our in-house ver­sion of the Agile method­ol­ogy. It al­lows for con­tin­u­ous im­prove­ment and flex­i­bil­ity in a pro­jec­t’s life­time.

Through the Way of Working there are three op­tions for em­bark­ing on a pro­ject.

  1. Fixed time, vari­able scope

This is our pre­ferred op­tion, as it of­fers the high­est level of cer­tainty in pric­ing whilst en­abling flex­i­bil­ity for new or un­fore­seen scope ideas.

  1. Fixed Scope, vari­able time

This op­tion en­sures all scope re­quire­ments are de­liv­ered and al­lows for flex­i­bil­ity in the amount of time for de­liv­ery.

  1. Fixed time, fixed scope

This is the least rec­om­mended and riski­est op­tion as it has the po­ten­tial to blow bud­gets out of pro­por­tion due to dev re­quire­ments and it lim­its the op­por­tu­nity for scope fea­ture adap­ta­tion thus lim­it­ing the pro­ject.


In sum­mary, due to the na­ture of soft­ware de­vel­op­ment any pro­ject has some el­e­ment of risk as­so­ci­ated with it. Our aim is to min­imise that risk through a strate­gic and sci­en­tific de­vel­op­ment method­ol­ogy, in our case, the Way of Working. If you would like more in­for­ma­tion about our way of work­ing you can down­load the full doc­u­ment here.


Josh Beatty

Account de­vel­oper and hair gel hoarder

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call