Planning for the Future: Why Estimate?
In our everyday lives we are constantly estimating time and cost.
- How long will it take me to get to work?
- How much will this new line of shoes cost?
- How many more miles can I go until the gas tank is empty?
We estimate to help us make decisions and plan for the future. The same can be said for software development.
Before starting a custom software development project, typically the first step is to understand if your business’s needs can be met by the amount of resources your business can spend. This leads to the first question of, “How much will this application cost me? And does the value of the custom application exceed the cost?” Both the client/stakeholder and the software team/agency have to understand if this is a realistic project to pursue.
For example, mobile apps we see are often in the 50K – 350K+ range, a web app could be anywhere from the 150K – 750K+ range, and an enterprise web application/system could be in the 250K – 2M+ range. This all depends on the factors related to the product you are developing and what you are including in that initial app, product or system.
Understanding the factors that influence the approach to software estimates can be just as important as the actual estimates themselves.
Why Should You Understand The Factors That Influence Estimation?
- It will help build a trusting partnership
- It will give a closer view of reality
- It will allow the project leadership to make good decisions about how to control the project and guide the estimation targets
How Do You Develop an Understanding of These Factors?
- Understanding the factors of uncertainty
- Understand the various approaches to tackling software development
Understanding the estimation process sets the stage for a successful project and partnership. For example, the strategy you take in order to phase the development of the software and get users testing the software can be part of the estimation process, which often results in product strategy discussions.
Ultimately, the estimation effort can help you know what to look for and what to avoid. You’ll better understand the product development work ahead and put more certainty into your development roadmap and cost.
Opportunities for Early Alignment
Most software apps or systems are products, which are nearly always a series of projects or phases. This makes project iterations inevitable. There’s a reason why most early software is called “beta.” Understanding what goes into each phase is important as you think about building your product. You need a strategy when planning what you build first, as discussed in our white paper, The Strategy of Starting with Less.
Knowing that what we’re building will evolve over time is probably the biggest opportunity for alignment as we think about estimation.
Here Are Eight Core Components That Could Go Into the Estimation Effort:
- Team / People Involved
- Deliverables Committed
- Identification of Uncertainty
- Identification of Risk Factors
- What’s in Scope
- What’s Out of Scope
- Development Approach
Let’s look at timelines, team, and development approach to understand how each can change estimates:
Timelines that are too compressed may require more people than necessary to be effective as a team. This may lead to poor decisions about building for quality and testing along the way. On the other hand, timelines that are too slow could lead to spending more time than necessary. If there isn’t a definitive end state to launching (often in phases), it could create unnecessary work per Pareto’s law.
A diverse team of experts, mid-level and even junior team members can be effective for the type of work in the project. Expertise is needed for architecture, code structure & efficiency. Generally, work structure is layered and having differing skillsets and perspectives can help with execution. However, having too much imbalance may lead to lack of direction if the team is too junior or lack of execution if the team is too senior. The same goes for team skill set: you need your back-end developers to balance out your front-end developers.
Taking a waterfall-oriented approach may lead to shorter timelines but less ideal product market fit. On the other hand, agile approaches may seem to take longer as you work through feedback iterations but will ultimately be quicker to achieving product market fit.
The variables with each of these components can create clarity and mutual understanding on the project early on. Each component can shift and affect the estimates.
The point is that openly discussing these attributes allows you to prepare for them and have confidence in the end estimation. We recommend viewing them as opportunities for alignment rather than obstacles. With everyone working towards the end goal of an accurate estimation, there is less undue stress and more clarity going forward.