Setting Deadlines

I came across a post from Bas de Baar about customers setting deadlines. Bas points Parkinson’s Law (work will fill all available time) and Student’s Syndrome (job can be done better when given more time) as the main fears which stand behind overly short schedules forced by customers.

I do agree with Bas with his distance to these so-called laws. I do agree that motivated, enjoyed team can deliver software earlier than planned, although from my experience I could probably count these situations on a single hand. However, I really don’t think the main reasons of having customers expecting software delivery by tomorrow lay in that area.

Fixed Deadlines

There are projects where deadlines are written in stone. The ERP system implementation which has to end by the end of the year, because migrating accounting data during the fiscal year is the worst nightmare project manager can dream of. Solutions for the biggest companies (like mobile operators) where dates of marketing campaigns are set quarters before they’ll be kicked off. Features whose development is forced by the change in the law. Components which integrate with external solutions being implemented two moths from now. In that case the customer will probably make fair buffer for themselves from the very last date, will give you your deadline and choice: their way or highway. And it has nothing to do with Parkinson’s Law.

Soft Deadlines

Another case is when there’s no such thing as fixed deadline. Vendor can deliver the solution on the date mutually agreed by both sides. Yes, one side will tend to shorten the deadline, another will tend to lengthen it and everything is a part of the bigger thing – closing the deal (with competitors right behind your back). If you often follow that scenario ask yourself: how many times deadlines were proposed by your side and weren’t kept? The typical situation is we boldly commit we can do it in three months or by Friday or before the 1st or whatever and then, magically, we can’t keep those dates, because we were too optimistic or have too little knowledge about the project or maybe… just maybe… it was the customer who forced tight deadlines. Ah yeees, you’re right, that was the case. Like always. That darn customer wanted it all by yesterday.
I think we have two different issues here:

• Ability to deal with fixed deadlines on both sides of the table. One of the main problems here is small pressure on signing the deal before date planned for that milestone.

• Ability to plan and schedule work on vendor’s side. A lot was written on the subject but I’m yet to see project plan which will go as planned.

And Parkinson’s Law? Maybe it is somewhere there in the back of the heads of customers, but its impact is really overestimated.