5 common estimation mistakes
Great client relationships are built upon meeting (and hopefully exceeding) expectations, but that can be hard to achieve when your project estimation doesn’t go according to plan.
Estimation is hard, and I’m not the first to say that.
It can take many years and a lot of experience for someone to become a great estimator, but you don’t always have that luxury when starting your own agency or freelance business. You need to provide estimates now, and need to do them as best you can.
I’ve been writing software estimates for nearly 20 years, and below are 5 common mistakes and remedies I’ve integrated to improve my estimation.
1. Bad requirements 📃
“I try to prepare for everything beyond the extent of preparation”
– Taylor Swift
I think this is the primary issue with estimating. Requirements are missed or unclear, and you simply can’t take into account what you don’t know.
As the saying goes “assumptions are the mother of all f*ckups” - meaning the worse your requirements are, the more assumptions you’re making, and the more risk you’re introducing.
To fix this: spend more time working with your client to lock down the requirements. Together, create precise acceptance criteria for each task, and make sure everyone is on the same page about exactly what’s required for each feature.
A Project workshop is a great time for this, and I use User story documentation to capture the requirements, and then use and build upon them throughout the entire project lifecycle.
2. Always thinking best-case 🤞
“The pessimist complains about the wind, the optimist expects it to change, the realist adjusts the sails.”
– William Arthur Ward, Writer
Most people are overly optimistic, and this has a huge impact on estimations. We trust our gut and generally think of just the “happy path” scenario.
But as developers, we are also often asked to estimate completely new concepts or technologies - meaning it’s difficult to consider all the unknowns and hidden risks. This is where it pays to have a healthy dose of pessimism.
To fix this: don’t just estimate based on your gut feeling, but separately estimate the best case (optimistic), worst case (pessimistic), and most likely case scenarios.
When doing a “worse case” I find it handy to think very hard about what could go wrong - as once in a while, these things do go wrong.
I use the PERT 3-point estimation technique, which calculates an expected amount of time or cost based on these three inputs.
3. Forgetting the small things 🤏
“In this bright future, you can't forget your past.”
– Bob Marley
It’s not uncommon to forget about all the small things involved in the project, but these things add up, and can ultimately have a large effect on the estimate.
These are often very project or industry-specific, but an example of un-estimated tasks include.
- Daily communication
- Weekly 20-minute status meetings
- Time spent talking with other stakeholders (designers)
- Responsive UI testing on different devices
- Setting up and configuring your project tools (project management, source control, continuous integration etc)
It might sound silly at first estimating for “daily communication”, and you might not want to publically call it that to your client (call it “Account management”). However, just 15 minutes a day of emails or Slack messages add up to 10 hours over a 2-month project.
To fix this: Have a standard estimate template where you capture all your common line items, then add to the template as you experience new things you want to account for. Over time your estimation template will become a real asset.
4. You are biased 😬
“All of us show bias when it comes to what information we take in. We typically focus on anything that agrees with the outcome we want”
– Noreena Hertz, Academic & economist.
Even if you have collected amazing requirements, and have conducted a thorough best case/worst case estimate, our own opinions are still biased.
All humans are biased. We only know what we know, and we draw on our past experiences when thinking of the future. This can mean missing concepts due to our blind spots, or always thinking some task is a lot simpler than it is.
To fix this: Get another pair of eyes on your estimate, especially really important estimates.
In my agency, I would have 2 developers and myself do independent estimates, and then we would get together and discuss our results. This would often lead to a combined estimate that was more accurate, as different people bring different perspectives, and help smooth out the biases that any one individual brings.
5. Not adding contingencies 📏
“When things go wrong, don't go with them”
– Elvis Presley
Estimation is black art, and no matter how well you do, sometimes it doesn't go according to plan. An API you’re integrating with might not work how you expected, or it might change during development. The client might provide way more feedback than you anticipated, but because they are all little things, you feel rude saying “no”.
To fix this: Build planned contingencies into your estimate. I add a “Technical risk contingency” of between 10% to 20% depending on the level of risk involved. And an “Enhancement contingency” between 10% to 20% depending on how much scope creep I feel this client will introduce. These add a buffer or some wiggle room, but you still need to monitor them so it doesn’t go over the allotted time. And this is especially important if charging a fixed price.
Remember: an estimate is an estimate
Last but not least - don’t make the mistake of thinking an estimate is a contract written in blood between you and your client.
An estimate is just a guide.
Sure, we all want to get things done on time, and deliver on what we said - but software development is equal parts art and science, and that doesn't come with 100% guarantees.
The best you can do is have a plan, communicate early, communicate often, collaborate with your client, and be prepared to make adjustments to the plan as the project evolves.