Methods to estimate software, a primer

Estimation is probably the most contentious, vital aspect of a software project with as many approaches as there are vendors and very few trusted resources on the subject.

For your clients, an estimate is the first bridge between their internalized need and external reality. Most hope for a detailed estimate, specific tasks and fixed costs: Solving your problem will cost $X and be ready by Y. Their trust will plummet and their anxiety will skyrocket as a function of ambiguity, regardless of project size. Worse, estimates cause so much long-term heartache because they’re the very first time an official expectation gets set.

Unfortunately, most vendors can’t or won’t estimate to a high degree of specificity, preferring the mechanisms outlined below. Sometimes this is warranted, especially when a project simply can’t be conceptualized to the necessary fidelity. More often this reluctance is by design, preferring the minimized accountability of defending ambiguity rather than owning and defining uncertainty.

Estimates generally come in two flavors:

1. Detailed
2. Ballpark

Let’s unpack the methods we’ve seen (and used) to estimate a project both ways, including the identifiers, uncertainty, merits, and risks of each.

To understand the relative value of other methods, let’s define a detailed estimate, which is the most welcome but hardest to deliver well. Generally, a detailed estimate:

• Cites hours and dollars to complete a specific set of tasks
• May include ranges of time (dollars) to complete certain tasks, depending on uncertainty
• Groups discipline specific items into technical and non-technical buckets
• Are ready to be staffed and begin quickly

Critically, detailed estimates help clients understand exactly what is needed to complete a project. Most detailed estimates are obvious:

Identifiers	Specific task- or deliverable-based line items, discipline-specific hour or dollar totals.
Uncertainty	Tied to the expertise of the vendor and clarity of the request. A good detailed estimate will call out areas of uncertainty.
Merits	Uncertainty can be localized to line items rather than spread across a whole project, you get to see that vendor’s thinking and understanding in detail.
Risks	Can become a detailed fiction, overdefining and becoming obsolete during the project despite then usually being part of your contract.

Anything that’s not a detailed estimate can be classified as a ballpark estimate. These take myriad forms.

Budget-based ballpark estimates

Exactly what it seems: a project estimate that fits inside a provided budget amount. This may seem disingenuous, more like an acknowledgement than an estimate.

Budget-based ballparks are often an expression of confidence. Often, a quick “yes” followed by a budget-filling estimate likely means your budget is too high—vendors almost always pad hours to cover uncertainty, internal process slippage, or losses incurred against someone else’s project.

Whether your dollars exactly match your need, or you suspect some vendor padding, additional interrogation will uncover the facts. Requesting a different form of estimate can be warranted, but your vendor may require some other proof of “seriousness”. The markers of a budget-based ballpark:

Identifiers	The estimate miraculously matches the amount of money you have. “Based on $X or Y (date), we will accomplish \__“
Uncertainty	Depends. Highly predictable tech such as WordPress can be budgeted against. Custom development usually can’t.
Merits	You get an estimate that matches your budget.
Risks	The proposed solution only fits because that’s what you can pay.
Pay attention.	Trust your gut. If what you’re hearing seems “hand wavy” or a miraculous outliner, it probably is.

Capacity-based estimates

This model describes fitting tasks within a volume of labor rather than adding up hours to complete. Colloquially, this is a “butts in seats times hours” estimate. Capacity-based estimation has been popular in software for over a decade because it’s:

• Easily done quickly with minimal engineering input
• Predictable to staff and flexible to operate
• Accommodates changes without much effort
• Forces client readiness and constant attention
• Easy to grow

If we’re honest, capacity estimation is more about vendor staffing projection than true software delivery. This method is a fantastic starting point to see if a project is even possible, especially when the delivery date is the most critical factor. Conversely, it’s the worst possible model when budget is paramount. The highs and lows:

Identifiers	Aside from a declaration of “capacity”, look for things like “we sell a team”, burn rate, sprints, or agile.
Uncertainty	Highest. Capacity estimates should be renamed “fuck around and find out.”
Merits	- You have a group of people dedicating time to your project.- Miscellaneous smaller things that got missed in a proposal can be slotted in easily
Risks	- May masquerade as a phased or detailed estimate with line items and everything. If it has details but a wide range, it’s probably capacity-based.- Transfers all responsibility for progress, action, and results fully on the client.- Does not easily support pauses in work.

Phased ballpark estimates

This style of estimate is popular for larger projects, though we’re seeing it declared for smaller and smaller commitments. The premise is that initial phases of a project can be estimated specifically but later work dependent on those early phases is unknown and can’t be scoped.

Usually, those early phases take the form of discovery or strategy workshops. Later phase costs and timing are offered as increasingly broad ranges, if at all. Essentially, a vendor is getting paid to learn and estimate.

Estimates structured like this might have merit if work in later phases is truly unknown and unexpectable, sitting behind a significant decision fork that would fundamentally change the nature of the work. We struggle to find a genuine example of this, but they surely exist.

Ultimately, phases are more about expedience than confidence. In our experience, a simple application of assumptions will allow for later-phase estimation with startling accuracy. If you’re faced with one of these, offer some clarifying assumptions, then request further detail.

Identifiers	Pretty clear when this is happening—look for paid learning.
Uncertainty	Projected high, though it may not be. Vendors often use phased estimates to avoid up-front commitment to specific outcomes or budgets
Merits	Done correctly, this method can legitimately reduce the overall cost of a project through rigorous controls and thoughtful architecture.
Risks	Spiraling costs, under-delivered, strategic drift of objectives-to-outcomes.

“Can we build this in …?”

Although this method rarely makes it to a client explicitly, the behavior is quite common and can result in any of the other forms of estimate outlined here.

Broadly, a team is asked “can a project be built within a specific budget / time / technology? Why or why not?” The answers quickly generate follow-on questions, highlight possible constraining factors, and uncover areas of uncertainty.

This method is distinct from a capacity estimate in that many variables are applied throughout the course of the discussion to challenge biases and reshape the conversation. Competent estimators will withhold actual budget and timeline details from their teams to uncover truth, uncertainty, and risks before providing biasing constraints.

An excellent starting point for estimation, balancing vendor concerns and client needs in a way that quickly generates follow-on discussions and assumptions.

Identifiers	Vendor includes hypotheticals as part of a proposal.
Uncertainty	Low, assuming the aforementioned hypotheticals
Merits	Can be done quickly:- gets to right answers early- uncovers areas of concerns- pressure tests project assumptions
Risks	- Lowest client risk of all the ballparks.- Sometimes hard to know what you’re agreeing to with technical hypotheticals.

Comparison-based ballpark estimates

If you’ve been in the industry long enough as an engineer or vendor, you start to see current estimates in the context of past work. Comparison estimates often start this way. The bad ones never advance beyond “yeah, this looks like that other project. $X.”

There are three core problems with comparisons:

1. Bias. They start from a point of extreme, often unarticulated bias. This is especially true when the reference projects didn’t go well for the implementation team, but the estimation team doesn’t remember (or know) why.
2. Uniformity. They promote sameness prior to investigation. More egregiously, they assume the clients, markets, and desired outcomes are the same because the technology need appears similar.
3. False certainty. They deliver a false sense of confidence. You know what happens when you assume!

From our experience, this method is only valuable as a check against another form of estimate, done independently. Prior work should be referenced with extreme prejudice.

Identifiers	Cited comparisons or estimates delivered with confidence and no supporting detail.
Uncertainty	When the comparison is right, low. When it’s off, staggeringly high.
Merits	Likely informed by experience rather than speculation.
Risks	Can bias a project towards sameness and underestimate the differences

Payer tolerance

As a client, you’ll never see this method but will absolutely receive the output, usually as a budget or phased estimate. It goes something like this:

• We don’t know/assume their budget is (this).
• What’s the highest/lowest it will take to deliver this work?
• What’s the lowest we can cite with confidence? This is usually much more than the lowest cost to actually deliver.
• What’s the highest number we can get away with?

Reasonably, this is a good exercise in understanding business constraints—is it worth this client doing this work at all? Cynically, when done in isolation, tolerance-based estimation ignores the technical problem entirely in an attempt to maximize revenue.

Identifiers	Proposal stretches your budget but is doable, though it’s low on details.
Uncertainty	Hard to say. This is the least accurate method by itself as it ignores the reality of the technical problem at hand, focusing on what its resolution is worth.
Merits	None for the client.
Risks	You’ll feel pressure to accept without interrogation. Trust your gut.

A note on paying for estimates

It’s not uncommon to be asked to pay for an estimate. These are usually framed as “discovery”. We have mixed feelings:

• They theoretically tie you to a vendor, but give you a starting point if you don’t have one.
• They signify a lack of understanding or confidence, both of which can generally be overcome with a little more conversation and slower action.
• They’re not always more informative than some of other methods outlined above that require higher up-front effort.

More often than not, paid estimates done by the implementer (as opposed to a third party) become self-fulfilling prophecies. Projects end up close to an estimated value simply because once agreed, everyone involved focuses on getting to that number hard enough to make it essentially true. It’s on you as the buyer to ensure that the prophecy being sold to you is one you want to come true.

There’s a simple truth about estimation that gets lost in almost every method.

> There is a correct and specific answer to “how long/how much will it take to do this project”.

That answer will be knowable at the end of a project. Everything an estimator does should be in service of discerning that number as early as possible. Every method outlined above is an approach to this.

Finally, the style of estimate provided says a lot about a vendor. Good vendors will deliver a mix, starting with some form of ballpark and working towards a detailed estimate before agreeing to work with you.

The excellent vendors will give you:

1. A real number. “We believe we can do this work for $X dollars in Y time.”
2. Things that will impact their number. “We assume A and B, if those change, we expect the estimate to change by Z.”
3. Confidence. “Their estimate will not only make sense to them, they’ll frame it in a way that makes sense to you.”

If your vendor takes their time to get it right, software estimates stop being an onerous, anxiety-inducing process. Instead, they trigger excitement to begin and a willingness to say “go!”

---

Estimation isn’t hard, but it is a commitment that’s proven hard to make as a vendor and equally hard to consume as a client. If you find yourself in this particular fog, Next Mile can help. We’ve created (and consumed) more estimates than we can count.