Demystifying Project Estimation
Unraveling the Complexities of Project Estimation with Jordan Cutler
As a former System Engineer, I often found project estimations frustrating and seemingly useless.
However, as I progressed into management and leadership roles, I came to understand that the issue was not with the estimates themselves; it was more about how my managers were handling them.
Estimating a project or the latest feature you aim to deliver holds incredible value, not only for the business your team serves but also for you and your team. In fact, estimations bring clarity and alignment, which are crucial for delivering quickly and with minimal stress.
That's why today, I’d like to delve deeper into this topic and try to demystify project estimations in all their aspects.
To achieve this, I wanted to go beyond my own experience as an Engineering Leader and I invited my friend Jordan Cutler, an expert from the development side, to co-author this article and provide a well-rounded perspective.
So before everything, I'll let him introduce himself.
Hey there! I’m Jordan, Senior Software Engineer and author of the High Growth Engineer newsletter that reached 40k subscribers in less than 1 year. I also teach a course on Maven called Mid-level to Senior Engineer. I love providing actionable advice to help you achieve your goals based on real-world experience.
❓What is an Estimate?
Estimates are informed predictions or assessments about a project, a feature, or a task. Let me reiterate: predictions. Very rarely will an estimate be 100% accurate, and it's crucial that all teams working together (stakeholders included) are aligned on this principle.
But why are estimates so frustrating?
These are just a few reasons:
🤝 Lack of collaboration: often, teams work in silos instead of collaborating to achieve a common objective.
🧠 Lack of knowledge: there's often a lack of mutual understanding in each other's fields.
🌐 More teams involved: it's already challenging to estimate projects when your team is the only one involved; imagine the complexity when external teams join the party.
🎯 Estimations are just guesses: estimating projects is a time-consuming process, and even when all factors are known, they are, at best, educated guesses.
What Affects Estimates Confidence
Estimates' reliability can be influenced by multiple factors. Based on my experience, these are the most frequent:
🏞️ Nature of the project: do you have domain knowledge of the project? Is this an iteration or something completely new? Is the project involving R&D? These are all factors that highly affect estimates.
👩🔬 Experience: the more experience your team has in one field, the more they will be able to do accurate estimates.
⏱️ Invested time: building precise requirements, conducting tech discoveries, brainstorming together, and defining T-Shirt sizes of tasks involved in a project to prioritize them, are all activities that take time. The more time you invest, the more accurate your estimates will become.
I find this last point (Invested Time) particularly important, as it should also determine the confidence level of your estimates.
How much time you should invest in estimating a project depends on the level of confidence you want to achieve within a certain project.
This will be influenced by how critical it is for your stakeholders to have an accurate timeline from the beginning.
⏱️ Should you Estimate Projects?
The reality is that it depends on company culture and other factors. Personally (and this is how I approach it within my teams), I believe estimates are required in the following cases:
🎯 Prioritization: when your stakeholders have to decide where to allocate resources.
🤝 More parties are involved: if you have to coordinate with many functions that are external to your team.
⏳ Time-sensitive Projects: there are projects that require being delivered in a precise amount of time due to other dependencies or external events you can’t control.
If you look at these 3 cases, you’ll notice that they are essentially the norm when it comes to product development teams, leading me to say that you’ll need estimates in approximately 85% of cases.
However, there is one particular scenario where I often try to avoid any estimation: projects that are primarily focused or that involve a lot of R&D.
R&D is inherently unknown, so attempting to estimate it becomes pointless and in some cases counterproductive. What I usually do with projects involving R&D is include them as part of the discovery process, effectively integrating them into the estimation itself.
A Different Point of View ( )
Believe it or not, estimates are in your benefit as an engineer.
 | A guest post by
|