How To Estimate An Engineering Project (Or Really Any Project)
There is apparently a cabal of engineers who want you to know that estimating is impossible. Don't believe 'em.
The Multiverse of Timelines
Estimating engineering projects is good and helpful1 and most of all it's not impossible. The first step is understanding that at the start, all projects exist in a multiverse of timelines with a variety of potential outcomes. People get sick or drink too much or just have bad days… or have great days! Or find the right stack overflow answer on the first try or whatever! We’re not code factories that have predictable outputs. Meanwhile, projects have their own uncertainties in scoping, dependencies, etc. Lots of people reading this might scoff and say, “yeah, that’s why estimates are impossible.” But actually, it just means that project outcomes lie on a distribution curve.
The bell curve represents the potential completion dates of a given project. On a standard distribution, the most likely outcome is the middle. Once you start thinking about it this way you can begin to see the patterns in how people attempt to estimate and map them to the curve. The most common pitfall is the sunny outlook.
People assume high energy days, quick problem solving and no new complications. This makes sense: we’re social people and we want to tell other what they want to hear. And what they want to hear is that the project will be done quickly. So we rationalize. The sunny outlook is the most optimistic answer we can give that doesn’t feel like lying. And as you can see on the curve it means we miss the large majority of our estimates.
But actually even the most likely outcome—the peak of the curve—causes us to miss about 50% of our estimates. That’s still not great. Other people are relying on our timelines after all.
Ranges and Error Rates
Once you begin to think in distributions for estimates, the most “honest” way to provide an estimate is as a range, rather than a specific date or amount of time. This requires a negotiation with stakeholders as it’s not the “expected” way to provide an estimate. This should also be paired with an error rate or SLA. How often will you hit your estimates? I promise it’s not 100% of the time, so be transparent about that and attempt to stick to the contract.
So, for example, you agree to hit your estimates 80% of the time, with a 20% error rate. And your estimates themselves are in the unit of "week" rather than "day.” The stakeholder negotiation should be relatively straightforward because it’s the most accurate way to represent the truth. To beef it up a little bit, support it with accountability metrics. At the end of the quarter, half or year, you can promise to deliver a hit rate on your estimates. But teams and organizations are rigid. If you must estimate an exact date, pick the end of your delivery range.
You should now be code complete early on about half your projects. This is your slack. Write more tests, clean up code, give your engineers some time back. You'll see quality go up across the board and stakeholders remain happy.
Dealing with Uncertainty
Most projects don't lie on standard distributions though. Instead they have long tails. You have a dependency you didn’t fully account for or problems that took much longer to solve than expected. For an engineering team, that may be 3rd party software that was harder than expected to integrate. For a non-eng project, maybe it’s designs or research that need to be delivered for the deck.
Typically, this means that usually the front part of the curve climbs steeply to the most likely result, but many outcomes pull the rear portion of the curve out into the distance. A project will probably take two weeks, but it might take three, four or even six. The length of the tail is correlated with uncertainty. The more you can reduce uncertainty, the more you can push your distribution in and narrow your estimate range.
One simple way to reduce uncertainty at the outset is to have each team member draw their own chart and then interrogate each others'. It's a cool framework for knowledge sharing. You’ll find that some people have solutions for some of your uncertainties and you’ll also find that some people have their own uncertainties that you haven’t accounted for.
Getting Started
You don’t need a wholesale organization change to get started estimating this way. On your next project, just do it:
Draw your chart, take careful consideration of uncertainties and adjust the long tail. Maybe even annotate it with the different things impacting the length. You may be able to pull the distribution back in too, with a little bit of research on the biggest uncertainties.
Show your team and see if they like it. Ask them to do the exercise too.
Compare your results. Use this as a basic agenda for a meeting. By the end, try and have a team consensus.
Present a delivery range and see how it’s received!
No matter what, record your estimates and the actual results. Try to calibrate so you're shipping within your margin of error. You can turn this into a game for your team. Don't punish anyone, but reward the best estimators.
You'll see tons of benefits, including better relationships with stakeholders, less stress, more slack for tech debt and tests, a more predictable pipeline, and better prioritization (product will make more knowledgable tradeoffs with reliable estimates). If you get good at this, people will love working with you. Good luck.
Some people disagree that estimating is good and helpful, but that’s a topic for another day.