What makes project estimation so difficult?
Proper project estimation can be as much of an art as it is a science. Artistically, it requires that gut reaction when a seemingly simple project carries with it complexity undertones unseen. Scientifically however, it should be interpreted more like statistics than basic arithmetic. I say this because statistics is bound tightly to the principle of uncertainty and uncertainty is a highly valuable concept when understanding and communicating project commitments.
I spent one gratifying summer in my youth studying at Leeds, England - where I primarily drank Frosty Jacks, played rugby and on very rare occasions attended class. One of the courses which I took (and subsequently failed) was quantum mechanics. Surprisingly more application than theory, I was heaved foot-first into a scalding pot of linear-algebraic soup - burned repeatedly by my inability or rather unwillingness to learn. One concept they taught however stuck with me and that was the idea that you can never be fully certain about all properties of a given particle - it’s position for example.
Today I take this concept with me into my day to day job as an engineering manager. Instead of trying to estimate particle positions however, I now instead estimate project completions. When project planning for your team, especially for the projects on the fringe of priority - you should refrain from “committing to completing it” and rather give estimations that it will be completed.
Project | Priority | Q1 Completion |
---|---|---|
Add database sharding abstraction | P1 | MOST LIKELY |
Setup new 2FA prompts | P1 | MOST LIKELY |
New user dispute claim workflow | P1 | LIKELY |
Warranty API expansion | P2 | LIKELY |
Customer service comms analytics | P2 | PROBABLE |
Refactor Core Scheduling | P2 | UNLIKELY |
Split financial planning service | P2 | NO |
With this, there are three important principles I take into quarterly / yearly planning with my stakeholders:
- First is to communicate why you cannot say with 100% certainty whether a project will be completed by the end of the work period.
This can be for a variety of reasons, unexpected scope creep, shifting organizational priorities, changes in staffing, etc.
- Second is to discuss upfront, even for a short bit of time what the backup plan for a failed launch might be.
Having a quick dialog early on in project planning, even five or less minutes prepares your stakeholders for the unlikely (or perhaps more likely) case that the project your team has committed to falls through.
- Third and most important is that these probabilities will move towards 100% and 0% as the quarter nears the end. Continually communicate these updated likelihoods so teams aren’t caught off guard when projects aren’t completed.
Updating your stakeholders when projects get closer (or don’t) from their end will reduce the shock of a project deadline being missed.