Time is the lifeblood of a service business and it's one of the most important reasons for bringing a tech services company into an organization. A poor estimate misleads clients about the time taken, causing a poor customer experience. It's also an expensive mistake to make for a service provider, even if the contract is not a fixed-price bid.
As difficult as estimates can be, they are a skill service companies need to master to be profitable and provide an excellent experience to their customers. To help you improve, we'll discuss several biases people often have that make us so bad at providing accurate estimates.
The planning fallacy is the tendency to underestimate the time, costs, and risks of future actions and overestimate the benefits.
Engineers, especially inexperienced engineers, are notorious for being unrealistically optimistic when making estimates. The reason for this is that they are thinking of the problem in terms of the feasibility of the core technical problems that need to be solved. Having determined that, the problem starts feeling doable. And because of that it is likely to feel the problem will be easier to implement than it is. But during implementation, you have to deal with bugs, interface with other parts of the system, implement telemetry, and deal with nuances in third-party APIs. All of this takes time.
Shift focus from time-based estimates to throughput and user story-based estimates. Have people compare units of work with other pieces of work. And then use historical data for converting from throughput, story points, or other quantity of work based metrics into time-based estimates. This ensures your estimates are informed by data rather than gut feelings. Yes, you will need the initial data to get started but that problem will be resolved fairly quickly. As a rough guide, 3x your first instinct is a good place to start.
Confirmation bias leads individuals to favor information or interpretations that confirm their preexisting beliefs or hypotheses.
We are very bad at processing information that we disagree with. This leads to blind spots in our reasoning - and our estimates. This is especially true if the architect is evaluating their own design.
Get more opinions and perspectives when doing estimates. It is critical to get input from people closest to the work because they’ll be implementing it. Getting these diverse perspectives helps everyone better understand the problems involved and reach a better estimate.
Anchoring bias occurs when initial information, such as an early estimate, unduly influences subsequent judgments and decisions.
Early estimates can become psychological anchors, leading to all future numbers being influenced by them, regardless of their accuracy.
When the team meets for estimates they should clarify the problem and understand the desired state but should refrain from discussing the “How” to solve the problem or even if it is hard or easy. Each member present should think through and provide their estimate through a secret ballot. The secret ballot ensures the group as a whole does not get biased by a single data point.
This bias occurs when people overestimate the importance of information that is readily available to them.
Teams might give undue weight to the work they have to do earlier in the project because they are more familiar with it. In estimation conversations, they’ll be able to go into a lot of detail about similar work that needs to be done. But the work they are less familiar with, which is in fact harder work because of more unknowns, doesn’t have as much evidence to inform the amount of work involved. This can result in grossly underestimating the overall scope of the project. The worst part of this bias is that it creates the illusion of everything being okay and only becomes apparent at the later stages of the project causing everyone to be surprised.
When you’re working on a large scope of work, you need to normalize the conversation around a consistent lever when thinking through the entire project. The hierarchy of features, epics, and user stories is a good model to understand this concept. You need to choose what level of abstraction you are on and do all your conversations and estimates at the same level of abstraction.
Authority bias influences team members to align their estimations with the expectations of superiors, often leading to unrealistic or inaccurate timelines and budgets. This bias can result in inadequate resource allocation, increased stress, burnout, and damage to organizational credibility.
There is always a tension between sales and delivery. Sales wants the sale to get done and Delivery knows that they will be held accountable for the promises made by Sales. This creates an undue pressure on the delivery team to lower their estimates.
Train your sales leaders to listen to the input from the delivery team. Use the time to make a real product decision understanding the actual business value desired by the customer and cut out features that are less valuable to the customer. The sales team needs to understand how to use this knowledge to impress the customer with the competence of your team and to sell follow-up work to the customer.
As the saying goes, "Making predictions is difficult. Especially about the future." We need to be inherently wary of our estimates. This article helped you understand some of the biases most damaging to your estimates.
Agile frameworks do a great job in managing these biases and we highly recommend bringing a seasoned agile practitioner on the team as soon as you are able to afford it.
In the meantime use this information as a springboard to understand the underlying principles. You should also check out some sources on agile estimates, such as this presentation by Mountain Goat Software, to help you implement your processes.
To grow your tech services company, you need to have a holistic view of sales, delivery, and finances. We've made it easy through a proven 4-step planning process - now available as a checklist. Please subscribe to receive your free copy.