How to Accurately Estimate Software Development Costs
The overall effect on the software industry for this type of costing is negative. Projects fail due to inadequate scoping, or software is built below par because the software development vendor does not truly understand their craft.
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.” - W. Edwards Deming
I believe that we must commit to more design and scoping up front to negate this problem. A list of requirements or 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. Speciﬁcally, the scoping stage is designed 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 on the requirements and communicate to clients how much it will cost to build their software application.
As mentioned above, Scoping is how we can calculate the costs of software development. Using the problem statement that was identiﬁed with the client in the earlier Brief stage, we identify the solution that is needed to solve that problem. To ﬁnd the solution we move in sequence through the discovery, inspiration, ideation and realisation stages (see diagram below).
This process can vary 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 applications 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 developers interpretation of requirement X is different to the clients 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 has increased and the development company adds an extra 0 to the end of the initial quote.
The ﬁrst step when estimating on 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, they verbalise it in meetings, document it via email, draw diagrams 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 ﬂawed 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 ﬁne-grained requirement. Each user story belongs to exactly one epic, where the user story is a subset of the feature deﬁned by the epic. A user story is the unit of delivery for Iterations, so by definition a user story must be sufﬁciently small to deliver in a single Iteration. For a more in depth look at epics and user stories visit this blog.
Once the backlog is complete, our developers estimate on each of the user stories identiﬁed. 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 ﬂoors 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.
From here the estimate can become more accurate if the developers work with an Agile methodology. Breaking down the pricing into sprints allows for costing to be assessed per iteration rather than a rough overall ﬁgure.
Traditionally, companies work with one big plan which they create by developing a strategy, operation and tactic from the start. They come up with a list of requirements for this plan, evaluate how long the project will take and then provide 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 ﬁnished development.
One example of this is the massive blowout that happened concerning the government contract with IBM to develop a health payroll system. The project was contracted to IBM in 2007 but was plagued by delays and budget blowouts. When the release ﬁnally happened, the system failed, resulting in a complete scrapping of the project. However, IBM was still wanting 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 ﬁnal product is released and the ﬁnal payment is due. For example, if you have a plan to develop a project in 3 sprints and through feedback identiﬁed changes to the requirements after the ﬁrst iteration, then you could save on the ﬁnal 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 budget.
It is relevant to note the cost of developers required for a project. This ﬁgure is then used in combination with the cost of the sprints and multiplied out. However, this is the part of the process that has the greatest impact on the overall project cost. Generally in Australia the average software developer salary is over $83 000 per year. Additionally, software architects and senior developers can earn on average over $120 000 and up to $176 000 per year. These ﬁgures can persuade businesses to turn to offshore software development.
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. In fact one of our previous articles about the ‘20 risks associated with outsourcing offshore’ noted that ﬁgures suggest the ﬁnal sum up of offshore development can leave expenditure up to 65% higher than estimated.
Alternatively, WorkingMouse uses Codebots to help maximise the efﬁciency of our onshore developers. These are software bots that are able to write more than 90% of an applications code, which maximises the efﬁciency of our developers and testers. We believe that this helps reduce the overall cost of projects and delivers more value to clients. It also helps keep work onshore.
Using these strategies to reﬁne 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 beneﬁcial 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.
If you want to read more on outsourcing, check out David’s article on how you can protect your IP when outsourcing in India.