Estimating a custom software project is a difficult necessity that usually occurs before the project kickoff (what we like to call the “point of maximum ignorance”). And getting estimates right can have a significant impact on the overall success of a product.
In my time at Atomic Object, I’ve estimated projects using several approaches, including blink estimation, bottom-up ranged estimates, and collaborative team approaches. For better or worse, there’s no silver bullet approach that applies in all cases. But I find that if we attack the estimation problem from several different angles, we’ll arrive at a range that’s more likely to capture the complexity of the project.
Tune Your Approach to the Project
Project “patterns” emerge with experience. At Atomic, we typically see things like:
- A totally new consumer-facing product
- A rewrite of an old, existing system
- A tightly scoped engineering tool or set of tools
- Design-only engagements
- Deployment of an existing application onto a new platform
- A complex, multi-phase, multi-platform project
Each high-level pattern has different requirements, risks, and considerations. You should be tuned into the pattern when estimating. For example:
- Totally new consumer-facing products should include more time to validate user experience and iterate on design. These considerations likely have a larger impact on market success.
- There are significant risks for under-estimation with rewrites. Pressure for feature parity makes it harder to control scope, complexities won’t surface during the pre-project consulting, and additional software may exist to augment the old system being rewritten. Estimators should develop a ranged estimate and set the expectation that the estimate will be revised after an upfront research phase.
- When the project is a smaller engineering tool or design-only engagement, the estimation team should pay close attention to a bottom-up accounting of the work to be done.
- Deploying an existing application onto a new platform (for example, creating a native mobile app alongside an existing web application), brings extra third-party integration risk. It’s easy to make the assumption that since an existing system uses some underlying infrastructure (such as a web API), the new software will be able to integrate with it smoothly. In practice, this is often not the case due to technical debt in the infrastructure or a mismatch in requirements between the legacy system and new software being developed. Seek to learn as much about the integration points as you can during estimation to gauge their risks.
Define a Range; Collaborate on the Budget
The goal of our estimation process is to identify a responsible range where we believe the team can find project success. Once a range has been identified using several estimation techniques, we collaborate with our client’s key stakeholders to identify a budget number. The agreed-upon budget should satisfy business requirements and provide enough value to the client’s organization while falling within the ranged estimate.
Tools for Estimation
When it’s time to estimate, we look at a project from a few different angles, including gut-feel/blink estimation, bottom-up ranged estimates, and comparisons with prior projects.
Gut-feel/blink estimation
We practice a version of blink estimation. The approach is simple. First, bring experienced developers and designers into a room and spend some time discussing project details (30-60 minutes is usually enough). After discussion, everyone in the room estimates how long the project will take, given a certain team makeup (e.g., two developers, one part-time designer). If there is significant disagreement, the team discusses the discrepancies in order to uncover missed details, wrong assumptions, or unseen risks.
Bottom-up range estimates
During pre-project consulting, we catalog a list of high-level feature requirements. The granularity of features depends on the size and complexity of the project. Examples of features included in the bottom-up feature list are:
- Login and API authentication
- New user onboarding and “forgot password” flow
- Integration with a third-party credit card payment provider
- Views and server support for a searchable, filterable list of items available for purchase
Each item is given a ranged estimate with two numbers: “aggressive but possible” and “highly probable.”
The bottom-up approach is time-consuming but invaluable for identifying what will be built and uncovering misunderstandings. Atomic’s CEO, Carl Erickson, wrote a more detailed blog post on this approach that’s worth reading.
Comparisons to prior work
At Atomic, we have the advantage of institutional experience on prior projects. It’s useful to compare new work with similar projects we have done in the past. When comparing past work to a new project, we evaluate the following:
- How many hours, exactly, were spent on the previous project?
- How comparable was the size of the project?
- What details of the other project aren’t present in the current estimated project?
- Differences in tech stack–can we gain efficiency from new technologies?
- Does the vertical introduce extra complexity (medical or financial field, for example)?
The above questions impact the complexity of the project we’re estimating, so we try to capture a multiplier for each item. Multipliers add or reduce scope. Ultimately a new data point is created by applying the multipliers to the actual cost of the old project.
Bringing it Together
A high-quality ranged estimate (low to high) is distilled from the above data points. If there’s a large discrepancy between data points, the estimation team should dig into why the difference exists and, if necessary, adjust the target budget range.
After we have the range, we present the above findings to prospective clients in the form of a spreadsheet. We ask them to review the spreadsheet and ask questions or provide clarifications where necessary. Once we agree upon the scope, we can work with our client to define a fixed budget that falls within the range.