These Deadlines Are Too Agressive
This is one of the most common things I hear from engineers, especially as they inch closer to a major deadline. Let’s face it, getting a project done within a deadline is not easy. If you have had to run to a shuttle before it leaves or a cafe before it closes, you should already be familiar with this inconvenient fact. Even the most meticulous planning can come up short, particularly for bigger projects. But sometimes, these hiccups can be mitigated or perhaps even completely avoided if engineers follow some basic rules in how they plan and execute on projects.
First of all, engineers should always do the sizing exercise themselves because they, more than anyone else, should have the most intimate knowledge of the work and the level of effort required. It also stands to reason that they come up with the numbers that they will eventually be held accountable for. Needless to say, if engineers are asked to operate with estimates they themselves did not come up with, they should carefully validate these estimates before committing to the work. This very much applies even to estimates provided by their own managers and close peers.
Secondly, engineers should always add some buffer to their estimates on account of the unexpected. This is never an exact science but with more experience, engineers should become more calibrated at sizing up risk and quantifying it. Some junior engineers unfortunately go to the other extreme and corner themselves into overly aggressive deadlines with little wiggle room, in an effort to impress their peers. The reality is, it is far safer and probably even more impressive to give more realistic deadlines and then, overdeliver.
Lastly, deadlines slip and it’s not the end of the world. Just be sure to let others know. I always tell my team that it’s not the missed deadline that concerns me the most, but how quickly it gets flagged. Raising visibility early ensures that stakeholders who are depending on you are made aware well ahead of time and can account for these changes in their plans. And hopefully, others have also accounted for the expected in unexpected in their plans so they may not have to do much of an adjustment anyway.
Visit my articles page or follow me for my musings on a wide range of other topics.
(Retired) MSG/E8 and (Retired) DA Civilian, Senior RPA Budget Analyst, USACAPOC G8
4 年Great messages Bef!
? Staff Software Engineer & Emoji Expert at LinkedIn ??????
4 年Ooooh so many thoughts on this topic—get ready for some threads ??
Hands-On Software Architect (Java, JavaScript, Cloud)
4 年"We'll fix this one with the docs."
Product Engineer at Y Combinator
5 年These deadlines...were created through a process that incentivizes making people happy at the beginning of a project over making estimates that are correct at the end of a project and which lacks a feedback loop to adjust for systemic bias...and are therefore too aggressive
Software engineers are poor negotiators and rarely take the required margins for errors or "slack" in the estimations.? That is why coming up with one estimation is rarely good. 3 estimations should be made always 1) Best case scenario 2)Worst case scenario 3) Realistic The more complicated the actual problem the more the probability to reach the worst case scenario (so be sure to specify this).