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.