4

Deadlines are evil. Deadlines are our friends

Deadline. Even if you didn’t know what it meant, the word surely sounds ominous. And then, when you look up the origin of the term, it gets even nastier. The word comes from US Civil War prison camps, where guards would shoot any prisoner that crossed a line about 19 feet from the wall. That is the kind of inspiration  for one of the most common concepts that we have to deal with on our products and projects. Just lovely.

Having recently emerged from an intense period of work to hit a very demanding deadline has gotten me to reflect upon this dirty word and other frequent  issues I hear on this subject. Things like:

  • Why should we work hard to ship within an arbitrary date imposed by someone else?
  • How can this kind of stress be any good for our teams in the long run?
  • Why can’t people see that better results would be reached if we had more time?
  • How are we supposed to follow best practices and methodologies under these conditions/constraints?

The lesson I’ve come to learn over the years is that we need to accept and embrace deadlines as a positive influence on our work. They can make us move forward in a very powerful way, bringing focus and motivation to achieve goals. The good and bad parts are, however,  separated by a very fine line. Deadlines can easily become impossibly heavy burdens that demoralize otherwise great teams.

Thus, we should understand the most important properties of deadlines so that we’re more capable of working with them and to negotiate them with stakeholders.

What is a deadline?

A deadline is an arbitrary moment in time where a given amount of work must be done. That’s it. There are three important parts to this statement, so let’s break it down.

It’s arbitrary

The first important thing to realize is that we’re talking about an arbitrary thing. It’s typically a moment set by an external source to the work being done: a date from a stakeholder, an event we’re servicing, the end of the sprint, the start of the year, etc.

That means that it may (or may not) be possible to adjust this moment if necessary. For instance, if you’re working on something for the Super Bowl, then that date is absolutely fixed; nothing can be changed about it. On the other hand, if you’re working on an internally defined deadline like “this has to be out by August 31st”, then there may be some wiggle room if you need it. Some person (or group of people) came up with  that date; they may be open to changing it.

It’s a moment in time

By “moment” I mean that it can be either a point in time or some fuzzier time period. The classical deadline is set for a given date, like the aforementioned examples. But it can also be “this has to be out by the end of the Fall” or something like that. This kind of deadline definition means that you’ve got some flexibility and, as usual, this can be both a curse and a blessing.

It defines an amount of work to be done

Finally, along with our beloved deadline comes something else: the output that is expected. The thing over which we get shot if we don’t deliver.

This is the key attribute. It’s what sets the difference between positive motivator and death march. The question is simple in principle: is it possible to produce this amount of work until the given date? Can we do this?

Also, in order to produce this output, you have a team/budget. Although these variables may be flexible, we’ll consider them fixed for the purposes of this discussion, as that’s the most common scenario.

Turning deadlines into a positive influence

The key to turning deadlines into a positive influence is to keep them achievable. If you nail this balance, these dates will exert a powerful focusing and motivating influence that keeps everyone’s mind on the goal. Our natural tendency to be distracted and to endlessly perfect what we’re working on gets tamed. We embrace the timing constraints and go for it. When we finally achieve the goal and actually ship, everyone involved feels a major emotional reward.

Those can be the positive effects of working towards (and hitting) a deadline. But as previously mentioned, this depends on controlling the three major aspects described: their arbitrariness and their ties to time and scope.

Failing to do so is the difference from positive influence and going through a death march. The negative charge that comes from an impossible deadline is tremendous; for you and your team.  The date, the scope and everything around the decision making process can easily become demoralizing issues that derail the team.

Given the stakes, and the fact that deadlines are a fact of life, it’s very important to properly account for all of this. To guide you through this thorny topic, here are some questions that can help you think about and negotiate deadlines, keeping them attainable and a positive influence for you and your team.

1. How narrow is the timeframe? 

Are you shooting for a fixed date or is it a wider timeframe? (like “end of the year” or “Q3”.)

If you’re working towards a fixed date, you have to be extremely careful with scope creep, as well as an artful manager of expectations; it’s very likely that some stuff will have to be dropped in order to make the deadline. Having The Date is then very useful, as it’s the strongest case you can make to include or drop something from your workload. Decisions get somewhat simpler: “is this new thing more important than hitting the date?”.

On the other hand, if you’re working towards a softer time limit or time frame, you lose the “date’s coming up” argument and scope might naturally increase. It’s a very easy trap to fall into, as there’s no tangible target (other than the implicit final day of the time period.) The only thing this sort of deadline buys you is some time at the beginning, in order to explore, spec out, and set the scope of what needs to be shipped. But after a while, you should really set dates for having the scope perfectly clear and for having a harder deadline.

2. How arbitrary is the deadline?

An implicit argument in the previous point is that dates can be moved. And in most cases, they can. Specially when something that’s really important suddenly pops up and there’s no time to include it.

This applies only when the deadline isn’t completely out of your team’s or your organization’s control. That is, if the date was set by someone. If you’re working on something with an actual hard limit (like Christmas or the 4th of July,) well, you should be at constant risk management mode since Day 1. Everything becomes about hitting the date.

Be careful to always try to read if this date is as important as other stakeholders may imply. When you get to the end, and for whatever reason your team realizes that it wasn’t such a hard date anyways, they will lose a bit of trust in the process and the organization. There’s no reason to push harder than what is necessary, and burning out everyone involved.

3. How well defined is the scope?

It’s very common for some deadline to be negotiated without a completely defined scope. And I’m not even talking about having explicit, complete requirements. That’s unrealistic and the whole reason we went to agile software development. It’s wanting to include <insert generic high-level feature here>. It’s not having a clear notion of the required work and the possible tradeoffs involved.

This, of course, depends on the type of stakeholder you’re dealing with, but you should avoid any type of discussion of date commitments until there’s a clearer view of what’s to be done in everyone’s minds.

The fuzzier the scope, the fuzzier the deadline should be.

4. Is the scope achievable in the given timeframe?

This is actually a continuous question. Since the initial setting of the deadline to every sprint planning meeting, the team should be confident that the work is achievable. It may be hard, but it has to be doable.

If no one’s confident that it is possible, then there’s a major red flag. I see a lot of people just pushing forward, somehow expecting that everything will improve by itself or that future work might make it easier than currently expected, and thus compensate for the present delay. This is a big mistake. It’s the first step towards a death march. The only sustainable path in this situation is either to change the scope or the deadline. Other scenarios are just recipes for demoralized and exhausted teams, as well as missed deadlines anyways.

5. How reasonable are the stakeholders imposing the deadline?

Up to this point, we’ve assumed that as long as everyone’s has done their job, when surprises arise, either scope or deadlines are negotiable in your organization. That is, there is a place for reason and for a rational look over these issues.

Sadly, this isn’t always the case and it’s one of the biggest tell-tale signs that you’re working in an unhealthy place. If you know this to be true of where you work, then you must be extra careful when defining the scope and get the longest possible time possible to achieve it. And you should also look for a better place to work.

This kind of inflexible environments are most common in large organizations without digital backgrounds, where there’s no widespread know-how of what it takes to build software and why it is so unpredictable at times.

6. Could the scope be partially achieved and still hit its main goals?

One of the things you should do first as a Product Manager negotiating a deadline, is to understand precisely the underlying goals that the initiative or project is trying to achieve.

If you’re in touch with the business objectives, then you’ll be in a much better place to discuss potential trade-offs whenever the deadline is at risk.

Whenever you and your team realize that some deadline is at risk, in order to maintain the date, some things will have to be dropped. If what’s coming out is core to the organization’s goals, then you should try to come up with some alternative version of the scope that still makes them possible. You’ll be in a much better position to negotiate a positive solution for everyone.

7. Is the team onboard with the timeframe and scope?

This is perhaps the most important issue of them all.

You should never commit to anything without first consulting your team. This is the classic Pig and Chicken situation. If you’re not sensitive to the team’s estimates and confidence about the deadline, then you’ve already lost. Even if the deadline is achievable, you will have lost their respect in the future, as they won’t know what sort of thing you’ll be capable of bringing through the door the next time around.

Every decision concerning timing and scope should have the team’s OK and any possible contingencies you need to negotiate a deadline must be talked with them beforehand.

Enjoyed the article?

Get actionable, useful content and resources on Product Management. Delivered straight to your inbox for free. You will also get in-depth guides to:

  • 20 Product Prioritization techniques (44-page PDF & cheatsheet)
  • The Kano Model (40-page PDF & spreadsheet)
No spam, ever. Unsubscribe at any time. Powered by ConvertKit
  • Deadlines. It was something I struggled to accept. Always were looking through the overly positive lenses, beyond the bounds of reality. “Well, we can finish that in time!”. Well, no. Repetitive occurrences wasn’t enough for me to see it, and then accept it.

    But at a point a man has to accept what is really in front of him. After that point I embraced the better view, that we must work in hours and budget, and learn to cut from the scope. Otherwise not only we didn’t achieve the goal on time, sometimes we didn’t achieve it effectively, and the team suffered a blow to the morale.

    Of course, what I lacked was experience the acquiring of which lead to far better resource management.

    • Daniel Zacarias

      Veso, it’s never easy. Deadlines are just there, and we should embrace them to get to their positive effects. What I’ve come to learn is that we should understand them and carefully control all their different aspects. It’s the only way to avoid their (extremely common) pitfalls.

  • Pingback: Deadlines are evil. Deadlines are our friends -...()

  • Pingback: 17-09-2015 - Links - Magnus Udbjørg()