Estimating the effort involved in any project can be a challenge, and software projects are no different. Arriving at an accurate estimate and plan is tricky, to get right.
At the start of any project, there is a large amount of uncertainty and numerous assumptions that have to be tackled. These can be refined over time, however, it is an investment, and it is an investment that pays dividends during the course of a project. However, a sensible balance has to be struck so that planning isn’t skimped on in the early stages. In equal measure, planning can reach a point where further investment produces diminishing returns.
Before starting any bespoke software development project, it is important to understand the challenges and limitations associated with estimating such a project.
Unclear Requirements
Almost all projects start with a vision and some semblance of requirements. Being able to estimate requirements accurately requires that there is a sufficient level of detail available to understand exactly how a system should work in every scenario.
In the early stages of a project, requirements often lack:
- Granular detail about how a feature is going to work
- Suitable consideration of the failure or edge cases involved in the functionality or workflow
- Consideration of how a requirement will need to interact with other requirements of the system (and the potential complexity that can evolve from this)
It is also possible to have entirely conflicting requirements within a project. For example, there may be a goal to have a slick and minimalistic user experience for a complicated process. Complicated processes are, by their very definition, complicated – which doesn’t naturally lend itself to providing a slick or minimalistic user experience.
Documenting and distributing requirements amongst a team often leads to a communication challenge which also needs to be tackled carefully because any information exchange is subject to being interpreted incorrectly or ambiguously.
Different documentation techniques can help to reduce ambiguity. For example, a requirements document that just expresses requirements through prose is likely to contain more ambiguity than a document that uses an appropriate combination of natural language, diagrams, flow charts, wireframes, etc.
Producing a requirements document with all of these elements is naturally more time-consuming but ultimately provides a better level of detail, and the process of stepping through producing accompanying diagrams, wireframes, etc, often flushes out further assumptions and details which may otherwise be overlooked and subsequently underestimated.
Changing Requirements
It is rare to work on a project where the requirements do not change and evolve over time. After all, the world doesn’t stand still while a project is delivered. Often projects exist in a changing environment and, as a result, have to change over time, even before an initial version of a system is released.
Equally, as a project evolves, incorrect assumptions or unforeseen challenges rise to the surface and have to be tackled. These challenges may impact on the requirements of the system.
Uncertainty Refines Over Time
Teams are often asked to estimate projects at the start to provide a view of the effort involved in delivering a project.
The challenge with any upfront project estimate is that this estimate will be based on a high degree of uncertainty and assumptions – some of which will be known and some of which will be unknown.
Academic studies have demonstrated that humans have a tendency to underestimate the time, costs and risks of future work whilst overestimating the benefits – this is known as The Planning Fallacy – a phenomenon identified by Daniel Kahneman and Amos Tversky in 1979.
As a team works on a project, uncertainties and assumptions will be flushed out, and the team will learn about the nuances of the project. As a result, the estimation of remaining work often improves over time as a team completes work and gets closer to the end goal of a project.
This means that estimates often increase over time – whilst this may sound undesirable, the reality is that these estimates are more accurate and realistic.
These challenges around uncertainty are one of the motivations that drive most software development teams towards embracing agile software development practices.
Complexity of Software
Building software is a multifaceted problem, and undertaking any software project is a complex exercise in:
- Gathering and refining requirements
- Planning the overall system architecture
- Detailing the design of individual components
- Predicting and capacity planning for the scale and performance needs of the system
- Implementing the system through the appropriate use of programming languages, frameworks and technology stacks
- Ensuring the security of the system and underlying data
- Testing the accuracy and completeness of the system through integration testing, system testing and user acceptance testing (UAT)
- Releasing and deploying the software to production environments
- Documenting the behaviours and operation of the system to satisfy internal and regulatory/compliance needs
- Ensuring a system is in compliance with relevant laws and regulations
- Ensuring any ethical concerns relating to data privacy, security and user rights are suitably addressed
Designing and delivering a software project involves dealing with, including but not limited to, all of the above elements of complexity. As the requirements for a project evolve and become more intricate, predicting the time and resources needed becomes increasingly difficult.
Summary
Estimating software is a complicated process, and many attempts have been made to improve how software projects are estimated and planned by the industry. As a result, there are many different ways to estimate a project.
As the industry has evolved, most teams have moved away from older approaches to estimating projects (such as Waterfall, which requires estimating the project at the start). In favour of more agile software development methods.
Agile methodologies acknowledge the challenges associated with delivering a project and embrace a set of principles designed to minimise the friction and impact of these challenges.
At The Curve, we approach projects using an agile approach which empowers teams to adapt, collaborate, and deliver software iteratively, embracing change as a driving force. This approach thrives on flexibility, customer feedback, and a relentless pursuit of delivering value, ensuring a responsive and successful project delivery that aligns with evolving needs.
Get in Touch
We’re always happy to chat and see if we can be a part of your story. Get in touch with us to tell us what you need help with.