Estimating a software project can seem as useful for predicting the future as gazing into a crystal ball—a crystal ball fogged over with unclear requirements, buzzwords, and hand waving. Giving your client a single number for their project is difficult at best.
This is especially true with fixed-bid contracts. Development shops are often at a disadvantage, guessing at solutions early in the product development cycle, and assuming a disproportionate share of the risk should things go awry.
Now that we’re done whining…
On the other hand, clients who are paying money for a website or other development work want to know how much their website will cost, and how long it will take. This is a reasonable expectation, but certainty is often hard to come by until very late in the development process.
Handing your client a napkin with a number written on it is the worst idea ever. A single-number estimate amounts to a promise, and puts the uncertainty and its corresponding risks entirely on your shoulders.
Instead of a single value estimate, it’s more truthful to supply a range.
Estimate ranges are the new hotness
It would be great to share your estimate with a clear probability, something like, "We’re 80% sure this will take 5 weeks." However, it’s hard to do an estimation that arrives at a strict probability without historical data and clear requirements.
An acceptable alternative to computed probability is to present your estimates as a range of time to completion: "this will take between 4 and 7 weeks."
This kind of estimate implicitly contains a probability: you’re saying there’s a 90-100% likelihood of a successful outcome with a 7-week timeline. You’re also telling the client that there’s a chance it could be completed sooner, but that would be a less likely outcome. In any case, you’ve set a minimum of 4 weeks for completion if everything goes perfectly.
How to talk about estimate ranges
Of course, when you show a client an estimate with large variances between the best and worst-case scenarios, it can be uncomfortable. It exposes the truth behind all software estimation: we’re guessing!
Even experienced estimators get it wrong, and the first time you put a range in front of a client, you might feel that you’re exposing yourself as an imposter. On the contrary, sometimes it’s the most savvy thing you can do.
When you show your client an estimate with wide variances, you can have a conversation about those items that are most uncertain. That can lead to clarified requirements, cuts in scope, or to a shared understanding that another round of planning is needed before an estimate can be made.
Back in the day…
In 2011, Seth Brown wrote about Lullabot’s estimation techniques. In The Art of Estimation, he shared how we break down a project into bite-sized tasks and use the Wideband Delphi method to facilitate discussion about the size and potential uncertainty for each task.
In 2012, Jerad Bitner posted An Update on the Art of Estimation, which described some improvements and adjustments to the process Seth wrote about, and shared a Google Sheet to let our readers try out the Wideband Delphi method for themselves.
Those articles are still very relevant. If you haven’t read them, I highly recommend you do so before proceeding. But we’ve got a new tool that I’d like to share, which takes what we’ve learned since then and brings it up to date.
As before, we’re using Wideband Delphi. You’ll need two (or more) people to estimate and compare the results. As a project manager, you might be one of them, or you may have two developers working with you while you facilitate the conversation.
Estimation requires dealing with uncertainties
Previous discussions about the Wideband Delphi method focused on comparing multiple estimates and arriving at an agreement about possible solutions. Since Seth and Jerad wrote their articles, I’ve done some reading that has extended our thinking and helped us refine that process.
Anyone who’s estimated more than a few projects has heard the old cliche ‘Make your best guess, and then double it’. That speaks to the notion that as developers and business people, we routinely underestimate the complexity of the work we take on. We smooth over uncertainties and make our best guess—but being optimistic in this case is a bad move. It’s better to recognize and even highlight areas where requirements aren’t clear.
How does uncertainty affect an estimate?
Software Estimation by Steve McConnell has a ton of great advice on all facets of this topic. It’s probably the best distillation of software estimation techniques I’ve run across, compiling research from academia and presenting it in a format that’s more accessible to working developers and project managers. In particular, he discusses how uncertainty can affect the accuracy of an estimate.
He describes how the COCOMO II software costing model identified that highly uncertain estimates can vary by a factor of 4. That would imply it’s not enough to simply double your guess. Other aspects of COCOMO II aren’t a great fit for agile projects and modern website development, but that finding was especially useful to me as an estimator
McConnell provides a suggested range of variance for estimation activities, based on the level of uncertainty in a given requirement. I borrowed those general rules about estimation ranges based on uncertainty and worked them into our spreadsheets here at Lullabot.
We now have a low-high range calculation for each estimate a developer makes. We can use that to drive internal discussions, as well as help our clients clarify their requirements before the project is fully underway.
Our New Estimation Tool
Our new Google Spreadsheet incorporates that uncertainty calculation, plus a few more things. It contains:
- a master sheet to lay out the requirements for estimation
- sheets for two developers to do their estimations, which borrows values from the master sheet.
- a comparison sheet that takes those estimates and shows them side by side
- subtotals to do post-estimate work like adding modifiers for project management or activities supporting development.
All of this helps reduce copy/paste work for the project manager, and makes it easy to see where developer estimates have varied, which helps focus the discussion.
Using the tool
Here’s how I recommend using the spreadsheet:
Clone the sheet
You’ll want a copy of the sheet you can actually work on—feel free to save a copy of ours and make your own modifications. There’s some instructions on the first sheet to help you get started.
Plan
You might be working with a list of desired features from a client, or a wireframe that you’re decomposing into components.
Whatever it is you’re estimating, you’ll want to break it into manageable chunks, and enter them on the ‘Master Estimate’ worksheet, along with a unique ID for each item. Those values will magically appear on the developer estimate sheets.
Modify
Adjust the headings for columns E-I to match your process. I’ve included research, design, dev, theming and QA, but you may want to break your estimate up differently.
You can rename the developer sheets if you wish, to the names of the folks who will be estimating the work. Just don’t edit the grey columns, because they contain the formulas that make all this work.
You can also add more developers to the estimation process if you feel it’s needed—that would require some copy-and-paste, and a little twiddling of formulas on the comparison sheet. I’ll leave that up to your ingenuity!
Estimate!
Here’s what to do for each row:
- Review the requirements
- Add a proposed solution
- Indicate the level of uncertainty from the dropdown provided
- Supply estimates (in hours) for any applicable categories
Compare
Using the comparison worksheet, you can identify line items where solutions and estimates differ. Filter on the standard deviation column if needed to spot estimates with a lot of variance, and then discuss them with your team to arrive at an approach everyone is comfortable with.
Deal with that uncertainty!
With that estimate in hand, you can decide whether to have an open meeting with the client and share the full sheet, warts and all, or if you want to clean things up and present a more limited version, with talking points for the main uncertainties.
How your client works with you during that conversation might tell you a lot about whether they’re a good match for your team, and if they’re able to work flexibly with the parts of a project that aren’t clear at the outset.
However you do it, Wideband Delphi lets you check your assumptions internally. Then you can take the resulting range and present it, or work with your client to narrow it first before offering a formal estimate. Either approach beats handing the client a single number and hoping for the best.
P.S. — If you’re interested in more insights on software estimation, check out our Introduction to Project Management series on Drupalize.Me! Our expert team of PMs here at Lullabot discuss a whole range of topics, including specific estimating tips for projects built with Drupal.