4 ms·

From the article: Projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all.

From the article: Projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all. I'd love to meet that team... In my own experience, development projects that don't have set deadlines (and someone applying "schedule pressure" as the deadline approaches) always go much, much longer than originally estimated. In fact, I'd argue that developers especially are prone to overruns because, with code, there always seems to be something else that can be done to improve it. Even if you complete a discrete number of features and they all test fine, there's always the temptation to go back and refactor.

notauser 18y ago
It depends. A project _of defined scope_ that has no schedule pressure can go pretty fast. If the PMs concentrate on squashing change (or moving it to version N) instead of bugging people to get something out by a date, that can work. This is especially true if there is some cool problem in the next version that the developers want to get to but can't until the current version ships :)
Tamerlin 18y ago
It depends also on how you characterize your deadlines. If you allow slippage when things take longer than expected, or to adapt to changing requirements, you can impose deadlines without laying the hammer down. In the end though, that ends up being more a case of managing scope than of imposing deadlines. Give the developers a well-defined scope, and unless they're putzes, they'll get the job done. Give them a hard deadline, and either they'll slip or they'll do shoddy work. Most projects base everything on deadlines. As a result, most of them deliver shoddy projects, and the company ends up with something that either doesn't work, or it works barely but that requires far more maintenance than the project's scope justifies.
- aasarava 18y ago
  Absolutely agree with you about needing a well defined scope and how that can reduce the chance of an overrun. Likewise, laying the hammer down simply because an arbitrary deadline is on the calendar isn't good project management. But I still argue that a good, reasonable deadline that everyone on the team has a say in setting acts as a commitment -- the team is saying, "yes, we agree to deliver a product in this timeframe." Once you've made that commitment, the deadline then acts as a forcing factor that drives everyone to prioritize the most important tasks.
  - Tamerlin 18y ago
    Agreed -- that's what prevents the endless rounds of re-factoring, and keeps everyone focused on building a product, rather than drifting off on tangents. We're saying the same thing, here. :)

notauser 18y ago

It depends. A project _of defined scope_ that has no schedule pressure can go pretty fast. If the PMs concentrate on squashing change (or moving it to version N) instead of bugging people to get something out by a date, that can work. This is especially true if there is some cool problem in the next version that the developers want to get to but can't until the current version ships :)

Tamerlin 18y ago

It depends also on how you characterize your deadlines. If you allow slippage when things take longer than expected, or to adapt to changing requirements, you can impose deadlines without laying the hammer down. In the end though, that ends up being more a case of managing scope than of imposing deadlines. Give the developers a well-defined scope, and unless they're putzes, they'll get the job done. Give them a hard deadline, and either they'll slip or they'll do shoddy work. Most projects base everything on deadlines. As a result, most of them deliver shoddy projects, and the company ends up with something that either doesn't work, or it works barely but that requires far more maintenance than the project's scope justifies.

aasarava 18y ago
Absolutely agree with you about needing a well defined scope and how that can reduce the chance of an overrun. Likewise, laying the hammer down simply because an arbitrary deadline is on the calendar isn't good project management. But I still argue that a good, reasonable deadline that everyone on the team has a say in setting acts as a commitment -- the team is saying, "yes, we agree to deliver a product in this timeframe." Once you've made that commitment, the deadline then acts as a forcing factor that drives everyone to prioritize the most important tasks.
- Tamerlin 18y ago
  Agreed -- that's what prevents the endless rounds of re-factoring, and keeps everyone focused on building a product, rather than drifting off on tangents. We're saying the same thing, here. :)