Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

The danger of drop-dead dates and iterative cycles

This problem is pretty typical of drop-dead dates, but it's even more blazingly obvious when pushing new software on a regular basis.

Drop-dead dates are a huge invitation to Parkinson's Law – they always become delivery dates.

This may seem obvious, but when running interative cycles/FDD, the problem is magnified. 

Regardless of the people who are delivering, drop-dead dates will ultimately become the defacto ship date for dependent features – especially from dependencies that are external to your group. When one group is responsible for multiple upstream features, this may be a good idea on a per-release basis but always be aware of the precedent being set. 

Whenever you establish new drop-dead dates, ignore past performance of the external groups.  Their schedule should always be considered fluid, especially when they are asked to service anyone but you.

A great rule of thumb is to never establish them beyond a feature-by-feature basis regardless of how mundane the external feature is.  Go to painstaking lengths whenever establishing a drop-dead date to explain the circustances around it.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

One Response to The danger of drop-dead dates and iterative cycles

  1. Steve, I’m not much familiar with the english terminology, so, care to explain the laiman (i.e. me) what exactly a drop-dead date is? (the name alone sounds like it should strike fear into a developer’s heart :))

Leave a Reply