Estimate padding is a strategy where a time or effort buffer would be added to your honest estimate for how long a task may take. The thinking is that this provides a bit of wiggle room, should anything go wrong over the course of your task. Throughout my career, I have found myself wrestling with padding estimates. This struggle is twofold:
- At a gut level, it feels dishonest.
- Given Parkinson’s Law, I fear that padded estimates will inevitably lead to time wasted. Parkinson’s law states that “work expands so as to fill the time available for its completion.”
My biggest concern is certainly Parkinson’s law. Work expanding to fill the time available for its completion could easily lead to over-engineered solutions or worse–a compromised work-ethic, slowing down & taking dramatically more time to complete tasks.
Under Promising, Over Delivering
A common saying in the industry is to “under promise, over deliver” meaning to provide a more pessimistic estimate to project management & then work to deliver the product before the pessimistic due-date. You may be able to save yourself from the potential harms of Parkinson’s Law by keeping one estimate to yourself, or your development team & then presenting an entirely different estimate to business stakeholders. Saying one thing & believing another certainly seems deceptive to me.
The positive spin on under-promising & over delivering is that when a project is completed ahead of schedule, the business is happy and everybody rejoices. This may be true on the first few projects, but what happens when this is played out over the long term?
Credibility
We become more credible when reality aligns with what we say. That reality could be geopolitical predictions, witness testimony or even gasp project completion dates. If we are constantly missing deadlines, we lose credibility. I am of the mind-set that we also lose credibility if we are constantly beating deadlines as well. I am approaching the mid-point of my career, so I do not have decades of experience to draw from–hopefully I am wrong on this point.
Contingencies
An alternative to blindly padding estimates is to provide contingencies. Bob Zimmerman discusses contingencies at length in this blog post. Bob argues that blindly padding estimates comes from a place of weakness & fear, and instead thought should be given to creating specific contingency tasks. These tasks can vary from project to project, in my opinion the mores specific the better.
For example, if you are developing a new API that client teams will be integrating with, there will almost always be issues that pop up with integration. Sometimes designs change, documents aren’t updated, or some important piece of information gets lost in the game of telephone that is sometimes played between development teams. In this situation, one could add contingency tasks for possible API integration issues that pop up.
This provides a more realistic view of the project. One can communicate with business partners that the existence of the contingency tasks doesn’t necessarily mean that problems will pop up–but if they do, we have planned for it. Best-case scenario, we can close the tasks & not spend any development hours on them. In my opinion, this provides the best of both worlds–You can under-promise and over-deliver from a place of knowledge & strength.
The biggest concern that I have with contingency tasks is that we cannot always predict the types of difficulties we will encounter. For every predicable concern, there may be more unpredictable concerns which pop up & thus never had a contingency task as we were unable to predict it.
Everybody Adapts
The difficulty with all of these strategies is that everybody adapts over the long run.
If we always run a project blindly padding estimates & regularly beat deadlines, project management will eventually catch on. Either they will relay to business partners that the project will likely be completed ahead of schedule or we will begin to lose credibility in our ability to provide accurate estimates.
Alternatively, if we create well-thought-out contingency tasks & then regularly do not encounter them–project management may either cease to see the value in them, or simply not factor them in when relaying estimates to business stakeholders.
Conclusion
Unfortunately, everything seems to always come back to moderation. Pad estimates to account for the unknown, but not so much that it risks your credibility or integrity (re: Parkinson’s law.) Create contingency tasks, but be incredibly thoughtful when doing so; If too many contingencies are never encountered, the value proposition of these tasks will be lost.
Project estimates are hard, with a bit of thought and reflection we all can do better.