It’s that time of the year we have to hand in our budgets. Making a budget for software development is hard because of all the uncertainties. What are we going to make? How long will that take? What if it does not go as planned.

The cost of software is not determined by how fast developers make software. The cost of software is determined by how quick you identify wrong assumptions and deal with them. They come in two forms:

1. Technical assumptions: When developers plan how long it will take to implement a certain functionality they have to make a lot of assumptions. The reality shows that when these assumptions do not hold up, more time is needed to adjust the plan and implementation. This results in projects going over budget.
2. Functional assumptions: Often we assume a certain functionality will be used once implemented. Reality is that often we need a lot more work for software to actually be used. This is why marketing and training business is so booming. Nadella has also identified this and is now measuring his developers not only on the amount of features they develop, but the amount of features they develop that are being used by the end user.

Before we go into how we can solve the problems of assumptions a quick calculation. Let’s say we have 5 developers working on a new product. It will take 3 development cycles of 2 weeks with one week in between to do all developments. Let’s assume we pay R500 p/h, this project will cost 8 weeks * 5 people * R500 p/h = R800.000,-

The general misconception is that If a developer runs in to a planning problem the impact is huge because let’s be honest, generally it takes twice as long as the developer says it will take, so let’s say R1,6 mil.

But what if you now have spent R1,6 mil and you software needs extra budget for marketing and training, because it’s not being used after release (you functional assumptions turn out to be wrong). On top of that training and marketing cost are not a once, all new customers need to keep being trained. Sound like a whole lot of work that could have easily be prevented.

To put some numbers to this let’s say we have to hire 4 people to do training. Let’s say they earn about R25k p/m, so another R100k recurring cost per month. All this just because you released software with a bad UX (User Experience). Depending on the product you will also lose revenue because it takes longer for a user to adopt the product and some users might not even buy it. Word of mount will also be less effective because of this.

I hear you think, what if I would not have released the software and just fixed the UX. OK, good option let’s see what that does to the budget. So we define another 1 or 2 sprints, let’s say 1 because we have awesome developers, that will be another 1 week prep and 2 weeks dev. So 3 weeks * 5 developers * R500,- p/h = R300.000. This sounds great, but wait how are we sure if this is what the user wants? We did not release anything we were still basing ourselves on assumptions that we did not test. Well let’s say we have an awesome team and it’s indeed better but not perfect. We release the software after the 4th dev cycle, get user feedback and do another dev cycle to fine tune. We end up at a total cost of R800k + R300k + R300k = R1,4mil. On top of that we do not have as much recurring cost for training and marketing as we would have in the first scenario. This is already much cheaper and more effective but there is a better way.

Do You Prototype Your Ideas and Test Them with Your End User?

So how can we prevent all these mishaps? Well if we look at the above sample it’s easy to see that, if we would have made software with a good User Experience in the first place it would solve many problems. It is crucial to test your assumption in the UX as early as possible. Designing, making and most importantly testing a prototype with all stakeholders including users is crucial. This will first of all make the impact of technical assumptions a lot lower and secondly the rework less likely. It even lowers the amount of technical assumptions because developers have a better understanding of what the end product and end user looks like. All together it is reducing the risk of project failure.

Satya Nadella has identified this concept quite clearly, if you measure your developers on developing functionality that is being used you will not only reduce the cost of ownership but also development because they will understand the user better and make software that is useful to them. If you want more detailed info on how to make a prototype and test it in one week feel free to contact me.