Please note that this blog is archived and outdated. For the most current information click here!
Leveraging Software Estimations For Scope Discovery
You’ve probably come to this article because you want to know how much is costs to build custom software for your business.
The short answer is that it will cost somewhere between $45,000 and $180,000 for a one milestone build of a software application.
The longer answer involves an understanding of what a milestone is and how the number of requirements will impact the cost of the application.
If there’s one thing you take from this article, let it be this: please do not take a list of requirements to a development agency and ask for a fixed quote.
8 times out of 10 the agency won’t give a quote; the other 2 times won’t lead to a good outcome for anyone involved on the project.
A list of requirements (or a vision for the project) can be interpreted many ways. It is critical to align the stakeholders involved in the software project before setting expectations around time and budget.
WorkingMouse does this through our Way of Working. Specifically, a dedicated stage to align stakeholders, create a well-documented backlog and a clickable prototype so that our developers understand exactly what it is they are building. This allows us to scientifically estimate the requirements and communicate to clients what features impact the cost of their software application.
Before we dive in any deeper it’s important to have an understanding of the different stages that will impact the cost of your application.
The very first stage that can often be devalued by those that don’t have industry experience is scoping. I believe that we must commit to designing and scoping upfront to negate the risks of project failures and inadequate products.
This then leads into the build of the application and finally, the support and maintenance, because no software is ever ‘finished.’
Scoping
As mentioned above, Scoping is how we can more accurately calculate the costs of software development. Using a problem statement that was identified during pre-engagement discussions (we call this the Brief stage), we collectively create the solution that will solve the problem. To find the solution we move in sequence through the discovery, inspiration, ideation and realisation stages (see diagram below).
The length of time for this process can vary but it is generally between 2 and 4 weeks. Importantly, at the end of Scope, we emerge with a number of deliverables including;
- A clickable prototype of your software that can be tested and validated,
- Requirements backlog with implementation steps,
- Your application’s schema,
- Roadmap, and,
- A cost breakdown of each piece of functionality.
What to avoid when looking for costs
The trap that many software development companies fall into is giving a quote before adequately scoping a project. This is incredibly problematic when the project is in the midst of development and it becomes clear that the developer’s interpretation of requirement X is different to the client’s interpretation of requirement X. Now, the complexity of the project has increased and the development company adds an extra 0 to the end of the initial quote.
The other likely pitfall is that a project may initially consist of 20 requirements. But in the midst of development, the client realises that another 10 requirements are actually needed to satisfy the various user groups. We call this scope creep. Without adequate time to plan and align on the direction of the software, it will inevitably suffer from scope creep. Now, you’re back in the same position as above. The scope and complexity have increased and the development company adds an extra 0 to the end of the initial quote.
Estimations
The first step when estimating a project is to capture the requirements. There are many ways for project owners to express the intent of their software. Typically to describe the software, features are verbalised in meetings, documented it via email, diagrams are drawn on a whiteboard, etc. The aim of these strategies is to achieve a shared understanding of what needs to be built. Capturing these requirements accurately is important for minimising the risk of flawed iteration estimates.
Our strategy for capturing these requirements is to understand the user intent through Epics and User Stories.
An epic is a description of a coarse-grained requirement in a story form. It may represent a theme, which can be used to categorise a bunch of related User Stories.
A user story is a description of a fine-grained requirement. Each user story belongs to exactly one epic, where the user story is a subset of the feature defined by the epic. A user story is the unit of delivery for Iterations, so by definition, a user story must be sufficiently small to deliver in a single Iteration.
Once the backlog is complete, our developers estimate based on each of the user stories identified. Our time estimation follows a precise, exponential scale:
- 1 hour (0.13 days*)
- 2 hours (0.26 days*)
- 4 hours (0.52 days*)
- 8 hours (1.05 days*)
You might be wondering, why can’t something be 3 hours or 6 hours of work? Why does it have to increase exponentially? The rationale is that the bigger something is, the less precise we can be on how long it will take. We can say that painting a room will take 2 hours, that tiling floors will take a day but we wouldn’t say that building a house will take 4 months, 2 weeks, 3 days and 1 hour.
This estimations process enables WorkingMouse to more accurately capture realistic estimations of the cost of developing software.
Associated with each estimate is a risk factor that is comprised of complexity and unfamiliarity. Requirements that are complex or unfamiliar are naturally riskier than simple, straightforward requirements. By scientifically capturing risk and accounting for it, the estimates provided carry a greater level of accuracy.
Using these strategies to refine the costing process for building software will greatly help towards achieving a more accurate estimate. Reducing unexpected costs can in turn help maintain a better customer satisfaction level and so is beneficial to both the software developers and customers. More importantly though, implementing a thorough scoping process will lead to a higher chance of creating successful software.
Why is software development expensive?
We’ve touched on the total cost you should expect, but it’s important to understand why the costs are what they are. This will enable you to determine whether an agency Is good value, too expensive or too cheap.
Yes that’s right, the alarm bells should be ringing if an agency is too cheap. To begin, let’s start with the average salary for a software developer in Australia. Indeed AU has put this figure at $122,000. That’s a good start but that number isn’t accurate in and of itself.
Every organisation needs to add on superannuation (10%), overheads (30%), non-billable staff like Sales & HR (35%).
Every agency needs a margin. CSImarket says this figure sits around the 30% mark for a professional services company. On average, a software developer is billable at $7,000 per week (over 46 weeks).
Our final equation of a software developer's salary of team is $130K + super ($19K - $149K cost) + cost of seat ($44.7K - $193K) + margin ($.7K - $237.7K) + opportunity cost ($106K) = Now, we’re looking at a total cost of $343K.
How to make sure you’re getting the right price
Based on the calculations above, we will step through and you’ll learn what a reasonable and unreasonable weekly engagement price is.
We can’t rely on a single developer to build an application themselves. We’ll need a second developer to ensure the knowledge of the system is shared. It will also help facilitate creative problem solving amongst the team.
Next, we’ll need a few other disciplines to ensure we’re creating an amazing product. A scrum master (or project manager) is needed to keep the project on track, a product designer is needed to research and design the best user experience and we’ll want to occasionally consult a customer success consultant to monitor the success of the application.
If one full-time resource is approximately $5.3K per week then 3-4 full-time resources give us a range of $15K - $20K. This is your average range but depending on the seniority of the developers assigned to your project it may be higher. Keep in mind that the average salary for a senior developer is over $140,000.
Offshore software outsourcing can appear a much cheaper alternative because of the lower wages afforded to overseas developers in countries like India. However, offshore outsourcing comes with a variety of long term risks and may involve unexpected costs such as legal fees or additional training costs. It's been noted that figures suggest the final sum-up of offshore development can leave expenditure up to 65% higher than estimated.
Ongoing software costs
As I’ve already mentioned above, software is never finished. The reality is that there are costs involved with supporting software, just like there are costs involved with servicing your car after you’ve bought it.
The general rule of thumb is to budget 10-20% of the cost of development on support.
Ongoing support models can fluctuate significantly from agency to agency. Some agencies may define very stringent service level agreements (an agreed timeframe in which something must be completed) which leads to a higher price, while others don’t. It’s important that you choose a support model that best fits your business and product.
What I have done is I’ve created another article that looks at some costs that are likely to be consistent no matter which agency you proceed with.
Agile Flexibility vs Waterfall
Traditionally, companies created a single plan comprising the desired outcomes and strategies for building the application right at the very start of a project. This is then fleshed out further to include a list of requirements for this plan with an evaluation of how long the project will take and then a cost estimate. This is called waterfall development. The downside to this strategy is that the feedback and learning process isn't available until you've already finished development.
How does the decision between agile and waterfall effect budget?
As you might imagine, less flexibility means a greater domino effect. A good example is the blowout between IBM and the government’s health payroll system. The project was contracted to IBM in 2007 but was plagued by delays and budget blowouts. When the release finally happened, the system failed, resulting in a complete scrapping of the project. However, IBM still wanted the full payment of around $1.2 billion. This failure can be linked to developing without effective scoping and building without testing.
Working in iterations allows you to build to smaller targets. At the end of each target, you can obtain valuable feedback to assess if you are still working towards the right project goals. This provides huge cost savings as you pick up changes that need to be made at a much earlier stage in the build.
This prevents situations like above, where clients are not aware of issues until the final product is released and the final payment is due. For example, if you have a plan to develop a project in 3 sprints and through feedback identified changes to the requirements after the first iteration, then you could save on the final two-thirds of the cost by picking up on the issue earlier. For this reason, the agile methodology can help to deliver successful projects on time and within budget.
Give me the summary
- A custom software application starts between $150,000 and $200,000+ depending on the complexity and size of the app.
- Larger applications will cost more but shouldn’t be completed in a single phase.
- Scoping is critical to aligning on what should be built and accurately estimating how long that will take.
- There are ongoing maintenance costs associated with software.
- Build iteratively to mitigate the risk of a project blowout.
