Is imposing “impossible deadlines” a Management Technique?

Question

I am a developer aiming to become a manager. I want to know if the following is a valid management technique (within reasonable parameters, to be determined), I want to know how to deal with it and to use it or not.

A group of developers is given a task that has a hard deadline of one week. Everyone knows that is impossible to achieve, concerns are raised, people speak up, but the deadline stands.

One week later, of course, the task is not finished. The deadline is moved another week further, and so on...

Could this actually be a management technique to create a sense of urgency to actually get the task done in the least possible amount of time, having management knowing full well all along that the imposed deadlines are impossible to meet?

Answer 1

There is a difference between "impossible" and "aggressive".

Setting "impossible" goals, ones where there is almost zero chance of success, is a fantastic way to demotivate your team in the long run because teams are being set up for failure. I've been in companies where the team will provide an honest estimation that a project will take X months to complete and management divides that by some factor as your goal because they've already made a promise or projects are always "late". This becomes a self-fulfilling prophecy because there is too little time to get the project done. Very frustrating to be in that kind of environment.

Setting "aggressive" goals, ones where there is some chance of success even if unlikely, is a reasonable approach to get the team to perform better than they would otherwise. I've been in companies that do this and it has worked well, the main downside is that you have to find a reasonable definition of what "aggressive" looks like so that you can push the team to excel without burning them out.

Answer 2

The only way to get the milestones accomplished on time is when the team sets either deadline or scope.
If someone else does it (a PM), and the team did not participate in negotiation, they will simply think that the deadline is not their responsibility. You can force them to accept it, but they will be set up for failure and they will certainly fail. At least to prove you: "we've been telling you that!"
And maybe the most important criteria to tell a good PM from a bad one is their ability to negotiate on very this matter.

Look at the Iron Triangle. The more balanced it is, the higher the quality of your product. You can stretch any axis, but not all. Leave one for the team, and they will do their best to keep their promise.

Actually, there are two typical cases as the team usually don't rule the resources:

1. "We need this scope done" - then your team tells you when they can accomplish this. If their deadline is not satisfactory, re-define the budget.
2. "We have a presentation on this date" - then you have to agree with your team what will be done by that date.

In other case, you should think on increased budget, e.g. hiring additional people, buying tools, etc.

Answer 3

Of course it's a management technique. And at the risk of down-votes, it's used all the time. It's a function of Parkinson's Law, also known as the Student Syndrome - work expands to fill the time available.

If a team is given two weeks to finish a task that could be done in week, it will take the full two weeks. And before anyone attacks, there are any number of reasons for this, not all of which point to failure on the part of the team.

Management hedges against this. They have a task that HAS to be done it two weeks. They say 'one week', knowing they have a buffer of one week.

The Critical Chain Method is based almost entirely on this principle. It takes estimates, cuts them in half, gives the team the shortened time, and then banks the remaining time as 'buffers".

This doesn't mean it's a good technique, but it's also not a bad one. Sometimes it needs to be used. Those teams that are 'self-organizing' and always working at optimum speed and efficiency are rare.

Answer 4

I feel sorry for anyone tasked with maintaining or altering any software created in such a manner.

Is it possible to create software like this? Sure. You leave out the following things:

• Unit Tests

• Code Reviews

• Refactoring

• Architecture Enforcement

A team that skips these steps, and gets very good at skipping them can deliver new software at amazing rates. Right up until technical debt smacks them in the face. It will happen sooner or later.

And here's the worst thing about skipping these: as a PM, you'll have no idea that the product is un-maintainable until it is too late. You won't be able to tell that what was created is a hack, because most developers are quite good at making a hack work. Kind of.

When the technical debt starts to pile up, everyone will start screaming legacy code this, and legacy code that (when they were the ones who wrote it in the first place), and the tempo will fall off completely. Your good developers will go somewhere else, you'll blame them for making a bad product, and pretty much everyone involved will be unhappy.

So no, I don't think it is a legitimate managing technique. Unless of course your aim is to churn out an unmaintainable product, make a profit, and then go out of business. Getting the task done in the least amount of time possible is almost always a horrible metric of project success.

Edit If there actually is a hard deadline, then be honest with your team and tell them what that deadline is. Treat them like professionals, and expect them to be honest with you about whether or not the deadline is feasible. Either party being dishonest in this process will result in a downward spiral of lies and suspicion.

Answer 5

Asking the Wrong Question

Is imposing “impossible deadlines” a Management Technique?

Yes, it's part of the management framework henceforth known as Epic Failure™. It's right up there with flogging a dead horse, deliberately planning a death-march, and telling people to "work harder, not smarter."

That doesn't mean it isn't practiced as a management technique. Many, many companies do exactly what you've described. However, you're asking the wrong question. The right question isn't whether it's a management technique or not, but it's whether it's an effective one.

How People Address Impossible Deadlines

When faced with impossible deadlines, some common things may happen. For example:

1. People ignore ridiculous and arbitrary deadlines, and continue doing whatever they normally do.
2. People try to meet unrealistic deadlines, burn out, and move on to other projects and/or companies.
3. People speak up, get singled out as "not a team player," and shrink the collective IQ or skill set of the team when they get drummed off the project.

This isn't an exhaustive list; I'm sure you can think of others. The end result, though, is typically a failed project. The mere use of this management technique is often a "project smell" that a project is currently failing, or is just about to fail, so it's a useful signpost that intervention is urgently needed.

My Personal Response to Ridiculous Deadlines

When faced with the Epic Failure™ management technique, I have actually said the following to various people in my professional life:

I've given you my very best professional estimate. If you prefer to apply a different metric, just subtract your deadline from my projected delivery date; that will tell you approximately how late the project will be.

A few people have appreciated the refreshing honesty over the years, but most Epic Failure™ practitioners do not. There are certainly consequences to being so outspoken, but one of the positive consequences is that I haven't been on a single involuntary death march in the past twenty years. Your mileage will certainly vary.

Answer 6

I am a developer who is studying project management as well.

It is a technique, but it is not an effective one if you want a top quality team.

Estimates need to come from the developers who are actually writing the code. It is the team lead's job to make sure that the estimates are reasonable to the skill of the developer, complexity of the task and quality of results that are expected.

Keeping everybody perpetually under the gun will result in an unhappy team and very likely will result in the loss of your most important people.

If I am asked how long something will take, then I will provide an estimate that is as accurate as I can make it. If my boss then tells me that I have half the time I estimated then I have 3 options:

• Work extra long hours with no extra pay and push myself closer to burnout. Studies have shown this to be ineffective in the long run.
• Cut quality. There are lots of ways to do this, leave bugs in the code so that you will be allocated time later to fix them. Don't unit test, don't comment, etc.
• Take longer than the time that I have been allocated and think a bit less of my project manager or boss, because they clearly don't respect me as a developer.

I can't see how any of those options would come from a good management technique.

Answer 7

Overall, management by task deadlines is not a good idea. It leads, among other things, to student syndrome.

A better approach is Goldratt's critical chain method.

In critical chain, tasks are estimated at 'aggressive but possible' durations, however, there is NO EXPECTATION that such estimates will be met. In other words, there is a clear separation between estimations and commitments.

What is committed is the project end date. In order to protect it from unavoidable overruns of aggressive estimates, a project buffer is added to the end of the project. Buffer consumption is then monitored against project completion to assess whether the project is in green, yellow or red zone. This information is a basis for active project management.

For an excellent introduction, see the novel 'Critical Chain'.

Answer 8

This is a recipe for high turnover, since the team will implicitly know:

When you finish a project with an unrealistic deadline, your reward is another project with another unrealistic deadline. ^{http://lifehacker.com/dont-always-aim-to-meet-unrealistic-deadlines-1444834485}

It can also have unintended consequences:

Estimates are also not usually updated once the team realizes that a task is behind. The engineer(s) will typically try to speed things up and do more faster, or work longer hours and weekends. In the first case, they can’t suddenly multiply their productivity, and there would be a significant quality loss and risk of missing requirements even if they could. In the later case, this is the fast lane to burnout and reduced overall productivity from lack of downtime, rest, etc. ^{https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/}

And produce an inferior product:

Unrealistic time estimates and the subsequent perceived date commitments can also incentivize the wrong things. They incentivize speed, which often results to reduced quality, increased defects, missed requirements, rework, unhappy customers and CS staff, technical debt, and additional maintenance cost and time. ^{https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/}

There is no good rationale for such a metric:

The problem is that velocity and/or software development estimates rarely involve probabilities and statistics, and yet must. The resulting estimates are therefore nonsense since we try to deterministically produce the value of a stochastic random variable. This would be considered a laughable practice by any statistician. ^{https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/}

And no historical context by which a precedent can be set:

In practice, an engineer (or team) decides on an approximate lead time based on gut feel, experience, educated guess, etc. This process requires almost zero actual time. Once decided, the task is worked on and the actual lead time is recorded once complete, along with some way to categorize the relative size for the task. Over time, a data set is created that allows for statistical analysis and much more realistic estimates (lead times) and due-date performance metrics. ^{https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/}

Which is the opposite of the true goal:

Remember that no one else cares and no one else matters. Most people are so wrapped up with themselves that they won’t notice any "slip" on your part. Let your desire to impress others go, and decouple your performance from your sense of self-worth. ^{http://webstandardssherpa.com/reviews/breaking-the-perfectionism-procrastination-infinite-loop/}

References

• Why Software Development Time Estimation Doesn't Work and Alternative Approaches

• Breaking the Perfectionism–Procrastination Infinite Loop - Web Standards Sherpa

• Don't Always Aim to Meet Unrealistic Deadlines

• Story Point Estimation Mistakes, 5 Common Ones Made | Agile Velocity

Answer 9

This sounds quite severe and I would think the consequences of this kind of approach would not be favorable overall. However, there is a benefit of a challenge like this. The critical chain method is based on this concept to a degree.

Finishing any type of task is not deterministic. In other words, you cannot say that doing a task will take 15 days each and every time you do it. Task completion is probabilistic, where most variables that affect your final result are random, uncontrollable, and unseen. Therefore, a more precise estimate of completing a task would be a range of results with some type of probabilistic distribution on top of it.

Completing on time and within budget are two metrics that we have a tendency of putting too much weight on. So much so that it can be reasonably expected that we would target on the pessismistic side of both targets in order to increase our likelihood of being a "success." The benefit to this would, of course, that you will not overrun your targets except in extreme circumstances. The cost to this is, well, increased costs. And, since you built in the time and budget, due to things like Parkinson's Law and Student Syndrome, it is highly likely your team will use every bit of available time and budget to complete the work that would have otherwise taken less time.

So, there is, in my opinion, some efficacy to "challenge" the team by condensing the time and budget and pushing for better results.

What is better: To target 20 days and come in at 19, a favorable 1 day variance; or target 13 days and come in at 15, a two day unfavorable variance? If you don't have these type of challenges, the latter will never come true.

Answer 10

I work at a company which often has very tight, and very impossible deadlines. One thing I've found is that if you tell people they /must/ produce results in 1 week, they can pull it off but they will cut corners because that's the only way to reach the deadline.

Here is what happens with an impossible deadline: people rush to meet it. People do as much as they can as quickly as possible and cut out all perceived non-important steps. At the end of the week you have results, but they were created with cut corners and last-minute patches. When you then say "actually the hard deadline is /next/ week so you can get it done properly" the entire project has to essentially start from scratch with people trying to patch up the shoddy work they did just to roll it out in time. It doesn't create a sense of urgency so much as create projects with numerous short-cutting errors and a very inefficient edit-and-re-edit process.

In my company, seven people have left in the last three months. Very, very high turnover because nobody can stand working like that.

Answer 11

Within technology, one of our responsibilities is to provide options. If management sets a deadline, it is our responsibility to provide options for how this can be accomplished (variance to minimal viable product, people, etc). Use data to tell the story, not subjective opinions. In my experience, a "business person" (read manager/execitive) will find ways to go around you, through you, behind you, any way to get what they need done. By providing options (backed by data) with costs/cost impacts for alternatives outlined and giving them a thoughtful response, you make it a business decision, not a technology capabilities decision.

I have worked for a CEO who regularly set the bar very high just to see if people would step up. I asked him why he did this and he replied that people generally sell themselves short, tell themselves all the ways it can't be done. By setting the bar high, you will find out what people are capable of given the right environment.

Answer 12

In short, what you want to set is a Timebox, not impossible deadlines. Impossible deadlines are highly demotivating, as developers usually know when a deadline is impossible. If you keep using and pushing impossible deadlines just to scare them, soon it'll become useless.

Setting a timebox is a more formal way to do that. You're telling your team that you are with them, but you don't have all the time/budget available, so at the end of the timebox, what was done is either accepted and pushed into production or simply rejected. Keep in mind that who makes estimations come true are developers, not managers. You want the best that can be done in X weeks, not shrink Y months in X weeks, as this usually leads to catastrophic results.

Answer 13

On paper, it sounds like incompetence on the part of management.

On the other hand, it is part of mainstream culture. Hard Drive talks about how agressive Microsoft was in getting early contracts. Renegades of the Empire suggests this is actually a strategy to keep people perpetually never satisfied.

Many young developers have never failed at anything in their lives, and companies prey on this insecurity. It's not sustainable, but neither are many other bad management practices.

Answer 14

Sounds like a project that is out of control and management that will soon burn-out its personnel from too much of the "boy who cried wolf."