motivated by a deadline?
Traditionally a deadline is defined as a tuple: a certain amount of work to be done by a certain date.
Do people need a specific externally set deadline in order to perform?
A deadline is meant to signal that the work under deadline is important, and somebody wants it to be done in a timely fashion. It also signals that the work can reasonably be done in the allotted time.
However, every so often a deadline is set without any consideration to whether the work requested can or needs to be done by the specified date. When that is the case, the signal the deadline sends is either a mistake, or an outright lie.
Regardless of the truthfulness of the deadline's signal, a deadline is set to provide motivation, stress, and possibly a setup for the later blaming game. That’s the main job of the deadline – provide motivation to those doing the work.
If there was no deadlines in the workplace, would everybody go out and have a beer instead of working? Or would people still do their jobs?
Suppose that the importance of the work and the fact that timeliness is needed is being communicated. Suppose that there is a regular opportunity to demonstrate progress. However, there is no official deadlines*.
For example, a client is coming over every other Wednesday with stories on how much he needs the features you are working on, and asking for a demo of the latest progress. He is also the guy who pays your team's salaries.
But there is no deadline - the team is being asked to do their best, and not worry about when the project will be completed.
Would your team work hard in this situation? Or will it twiddle their thumbs since no particular work is expected by next week?
---------------------------------------
* Of course, you can set all sorts of deadlines for yourself, if you want, but nobody (other than yourself) is going to hold you to them.
- Jane Prusakova's blog
- Login or register to post comments
Comments
I prefer to work backwards
I prefer to work backwards from a target date, and see what can be done. If what is asked can't be done by that date, then something has to give: date moves, tasks are pruned, or overall quality declines. Iterate as necessary until you have agreement.
I think some individual personalities would indeed buy a beer everyday and cram the day before. When there's a team in place, I believe peer pressure tends to stifle such behavior; nobody wants to look like a slacker.
If there's no defined time goal to be met (by an individual or team), the tasks to be completed and quality of those tasks is left to interpretation. For example, one might delve into refining minute details of a task when "good enough" was passed by long ago; in a time-bound environment, the "good enough" point would have been defined prior.
Whether "good enough" is
Whether "good enough" is good enough should be covered in regular progress reports. Once a task is completed in the eyes of the client, it is no longer worked on.
Jane Prusakova
Software Architect & Developer
http://www.linkedin.com/in/prusakov
My experience as been that
My experience as been that motivation based on arbitrary and artificial deadlines tends to lose effectiveness pretty quickly. Deadlines that are based on real needs that have been effectively communicated to the involved parties tend to be more likely to be respected.
Of course, "good" deadlines
Of course, "good" deadlines tend to work a lot better than "bad" ones. The problem is that not enough deadlines are good enough, and the definition of the "real need" is in the eye of the beholder.
Jane Prusakova
Software Architect & Developer
http://www.linkedin.com/in/prusakov
I don't think enough
I don't think enough deadlines are iterated upon with the people who really know what's going on.
For example, I have seen a project schedule developed where every task is assessed by the respective engineers from the very start, including task dependencies. These are then assembled to create bottom-up schedule. Then what happens is the high-level managers look at it, and exclaim "That's way to long. Trim it back". So then we have to compress our schedules, with the pressure that the same task must be completed in less time with the same quality. And then all the engineers scratch their heads and ask why a bottom-up scheduled was employed in the first place.
The question becomes - why
The question becomes - why make up a deadline at all, if we can't get it right anyway?
Jane Prusakova
Software Architect & Developer
http://www.linkedin.com/in/prusakov
A lot of times, that is a
A lot of times, that is a million dollar question. And that is often literally.
I agree Matt, I've seen that
I agree Matt, I've seen that happen a number of times.
Another problem is that requirements are often so vague that engineers/developers are compelled to pad their time estimates in order to have any modicum of safety. And then the PHBs want to slash all those estimates back to what they think is reasonable, eliminating any safety margin, and then wonder why when an obstacle is encountered (usually scope creep caused by the squishy requirements) that the time line gets blown.
Part of the problem is that a lot of managers who claim to be in favor of "Agile" are not willing to give up some of their comforts with typical waterfall methodologies... They still want detailed technical specs and hard time schedules up front... which is completely "fragile".