Budget is always the elephant in the room, but it can trample your project if you don’t address it early… and with care. We’ve learnt a lot in ten years of building web and software applications, often for a fixed price, and have a few scars to show for it. Budget is usually the cause.
How much is an app? How long is a piece of string? It’s clichéd, but true. The variables are endless, so it’s important to minimise these, work out the rough length of the string and reduce the risk before you start. Developing software is not an easy process, so to establish a price for a project from scratch is more of an art than a science.
Unlike building a house, there are very few ‘fixed’ costs in software development. This is because an application is usually a new invention; otherwise you’d buy something that already does the job. Inventing something from scratch is difficult to estimate. For example, the concrete for the foundations of a house is largely a fixed cost of materials and a portion of labour, however, the base or core of a piece of software will often fall into a range – 80-100 hours or even 1000-1500 hours. This variation in time presents the risk.
Development cost is significant, but often not the largest part of the project. It’s the things either side of the development that can blow a budget to bits. As you can see by this table, core development may be only 10%. It sounds ridiculous, but when shown this way with testing and marketing factored in, it demonstrates the relative importance of all the other factors that make up a successful application launch.
Note: Below is an example and rough guide only. Every project has unique requirements, needs and marketing methods that influence budget requirements.
Most developers without marketing experience, seriously underestimate the cost of getting the application to market, and without sales your application is dead in the water.
Setting a software development budget is about reducing risk.
The more your developers understand your idea, the easier it is to reduce risk. Unfortunately, for most entrepreneurs’ ideas are scribbled on the back of napkins and rarely fully planned in great detail.
So to establish an estimate, the first stage is writing a project or development scope. This document is a functional and design specification that outlines all the components of your project written by a business/technical analyst with prior experience in software development. Without this document your project is doomed to fail!
Ideally the document should detail 100% of the project, however this is rarely the case. There is always about 10-20% that even the analyst can’t or hasn’t considered. Any price given by a developer before this document is written should be considered mere speculation and a ‘Guesstimate’.
Find out more about planning here – Planning a Successful Web Application
Entrepreneurs will often employ an inexperienced or offshore development team in their quest to reduce costs. This can work in some instances, especially if the scope is extremely well defined, however we have lost count of the number of projects we have rescued from this situation. So, proceed with caution. What may seem like half price, may take twice as long and double the money if things don’t turn out as planned.
Coding quality is also to be considered. If the coding methodology is out of date or sloppy or too many developers have worked on the system, it may render it impossible to fix or extend upon.
This is every entrepreneur’s worst nightmare. Whilst you can’t budget for this, reduce risk by seeking recommendations from experienced people within the industry BEFORE your start. Engage your team based on proven experience and deliverables. Ensure your team use recognised frameworks. This will ensure a consistent coding practice that can be taken elsewhere if needed. Also, make sure you have regular access to the codebase, usually via a version control system.
No matter how well planned, as soon as the application is ready for alpha release and the owners start playing with it, more ideas are going to flow, more reports are going to be required, and the scope will be pushed and pulled. This will quickly blow the budget if not managed correctly.
Changes in scope are a fact of life in the development cycle. Anticipate it and budget for it. We suggest at least 10% of your total budget is dedicated to pre-release changes. It sounds like a lot, but we’ve yet to see an exception.
Testing can be a large part of the overall development process. It is very difficult to place a percentage of budgets on testing, mainly because it is an ongoing process even after the application goes live. Stability is the key. As soon as another feature is added, the testing process needs to start again (see previous point.) Roughly 10% of the overall budget should be allocated to testing, but as the application matures, testing could be much more, say 20-30%. Find out more about testing here.
By far the most underestimated part of getting an application to market is the marketing and sales budget. ‘Build it and they will come’ may have worked for the Romans, but the Romans weren’t trying to sell a new idea on the Internet. They were more like Facebook introducing Timeline.
As you don’t wield the threat of hungry lions or eternal friendlessness, you’ll need to make a lot of noise about your new app to gain traction in the market. Whether you are selling it one-by-one or with a top-down process, it’s still going to cost a lot of money.
Not allocating a marketing budget usually results in the project running out of money and ‘steam’ right on the cusp of world domination, usually with the project needing another cash injection to get to the next stage.
We suggest allocating the same amount on the marketing budget as you do on development. Again, this sounds excessive, but it’s actually very conservative. Facebook wasn’t cashflow positive until its fifth year with 300 million users and a value of $3.7 billion. That’s a lot of startup capital! (reference)
What components of a web application increase the RISK and as a result, the COST? There are 4 main areas:
This is especially the case in cloud-based application development where many levels of users access the same codebase.
Then there are variations on the theme:
Every layer of access almost doubles development time, because every screen and process needs additional rules, which need to be coded and tested. For example, 5 layers of security will take 5 times as long to test. This flows right through the whole project, making every change more complex to implement and test.
All software is built to make a particular task quicker or easier. To enable your software to do the ‘heavy lifting’ it needs logic, so it can make calculations and decisions. The more complex the ‘decision tree’ or calculations, the more time it will take to code and test.
Integration with 3rd party systems introduces the highest level of risk to a project – without fail. There are many unknowns and no developer can truly eliminate this risk in the quoting, scoping or development phase.
If your application plans to connect with others systems allocate a large portion of the budget to integration. Integration may be as small as connecting to a payment gateway or it may mean connecting to an old clunky Windows system that was never made to integrate with anything.
Every application collects a large amount of data. The way in which you extract and present this data is often unknown in the early stages of project planning. Keep it simple in the beginning and build reports as they become necessary.
Thoroughly addressing these four points will help identify risky components and assist in developing a plan and a realistic baseline budget.
Believe it or not, managed correctly, a software development project can stay on budget. It is a team effort, requiring transparency from all stakeholders, both on the client side and development team all working together with a common goal, but it can be done.
Stay focused, be disciplined and creative!Posted by Jason Hawkins on 27 May 2012