Raul Chedrese

Estimating Large Projects

March 24, 2024
Everyone hates estimating large software projects. It’s fraught with peril. Someone will ask you to estimate a large project and assure you that they won’t hold you to that estimate. Inevitably they are perplexed when the project isn’t done by that time.

People crave estimates. As soon as one is spoken people latch on to it, it spreads like wildfire, and it can never be taken back. People start speaking that estimate to others and all of a sudden the whole leadership team is expecting you to meet that target.

To be fair when I’ve been in management positions I also wanted estimates. At some level estimates are necessary. How can you make decisions about what to work on if you can’t differentiate between a project that will take 1 week and another that will take 1 year?

Recently I’ve had to give estimates on some large projects very early on in their development. I gave some bad ones and some not-so-bad ones. Even when my estimates turned out to be close I felt frustrated because I couldn’t articulate what I did differently to come up with a good estimate. I found myself consumed with the question of how I could reliably come up with useful estimates.

Bad assumptions

Most problems with estimates stem from three bad assumptions we often make about them:
  1. They are a single number
  2. All outcomes are equally likely
  3. They won’t change

Estimates are a single number

The first issue can be solved by giving two numbers instead of one. A best-case scenario and a worst-case. This provides a range and makes it clear that there is uncertainty in the estimate. It also prevents folks from getting a number stuck in their head or the context around the estimate being lost in a game of telephone. If folks do fixate on a single number it is likely to be the worst case scenario.

While this is an improvement it may not make things much easier for people making prioritization decisions. What if the range is really large? It also doesn’t solve the second problem with estimates. Are we more likely to end up closer to the best case or the worst case?

All outcomes are equally likely

The best case is not equally likely as the worst case. In fact, the probabilities tend to be weighted more towards the worst case since many things can derail a project but only a few complex combinations will lead to the best case.

Providing a probability curve gives a better sense of how risky the project is. This doesn’t need to be a perfect curve that is generated based on a mathematical equation. It can be a simple drawing that conveys the high-level project risk. Some of this is going to be gut feel and that’s ok. The most important part is that coming up with this probability curve will force you to think through and identify what the project risks are. What things could go wrong that would significantly extend the timeline? What things would need to be true to hit the best case?

Some folks advocate for giving a third number which is the “most likely” outcome. The problem with this is that it gives folks a single number to fixate on again. It also may imply that it’s more likely than it really is. An outcome could be the most likely but still only a 10% chance. The most likely outcome is also at the top of your probability curve.

Estimates don’t change

You will never know less than you do right now. You should revisit the estimate regularly as the project progresses. As the unknowns you listed are removed you should update the estimate. As the project progresses your probability curve should narrow and your estimate should become more precise.

Even if you do all this things can still go wrong. The final critical step to estimating is to review your estimate after the project is done. If the estimate was inaccurate you need to understand why. If you do this over time your estimates will improve.

Evolving the estimate

Along with the probability curve, a good estimate should include the things you identified that have the most impact on the uncertainty in the estimate. These could be specific features that are risky. It could be unanswered questions like which team will be working on the project. This makes the estimate significantly more useful. It gives you levers to de-risk the project. It also gives you a list of unknowns or questions that should be tackled first. If a specific feature is adding significant uncertainty to the estimate maybe you descope it and squeeze your probability curve to the left.

Good Estimates

  1. Give a range of possible outcomes
  2. Communicates the probability of those outcomes
  3. Contain a list of factors that impact the estimate