Everyone in the software industry, has at some point of the other, been part of a delayed project. The result is often a war room where all the big shots put their heads together to save face. Imagine one such meeting where everyone is focussed on crashing time. Management is willing to compromise margins and the project manager has been given the authority to do anything it takes to deliver the project sooner.

All eyes are on the development team to see what they can do to expedite. Desperate, the project manager thinks he has an offer the Dev manager can’t refuse. He takes pride in offering to add more resources to the project. The Dev manager, however sane otherwise, goes ballistic on hearing this and yells out: ‘9 Women Can’t Make a Baby in a Month’. There is a moment of silence. Then, the noobs giggle, the big shots calm down and the PM walks out of the room.

This is Brooks’s law, and every software engineer gets exposed to this mantra/joke – whichever way you take it – in the very first years on the job. If Pressman was as bold as Fred Brooks, he would’ve added it to his Software engineering bible. This is 100% true and getting things done sooner is definitely good, especially if you have the liberty of resources or when tasks can actually run in parallel. But even when that’s true, you don’t always want to crash time.

In another real-life scenario, a developer said that they had scheduled a recurring hourly meeting over the entire week for knowledge transfer. This was actually blocking development of a crucial component, and we all wanted this to be done sooner. And then one of us desperately asked the developer why they could not dedicate an entire day and get done with it. There was silence in the room. Without the developer uttering a word, the statement was retracted. Everyone has realized that we were talking about a knowledge transfer activity, and not digging a road. The activity demands skills & focus, but most of all, it requires going back and assimilating all that was learned. Doing it all in a day would only overload the person with information, and increasing the chances of dilution or loss. Some PMs – mainly ones who don’t understand the activities involved – use crashing time as the only tool to manage their project. But that isn’t always desirable.

So when is it that you shouldn’t crash time? Activities that are non-repetitive (mechanical) and demand a blend of knowledge, creativity and experience should be given their own time. As product manager myself, I hate black-box activities whose duration is unpredictable. But the best way is to finish the activity iteratively with frequent reviews & early feedback. Something I frequently do with my User experience team. I push them to come out with the first cut at the earliest possible, but they give the date. Anything that’s off-track is quickly trashed. You might not get it right the first time. After all good judgment comes from experience, but experience comes from bad judgment. But don’t be desperate to crash time.