The term deadline was first popularized by the publishing industry. It indicated the time at which something needed to be ready for a scheduled print (perhaps a newspaper).
“Make certain that the type does not come outside of the dead-line on the press”.
The consequence of missing the deadline was simple, your work didn’t make it into the final product.
When dealing with deadlines, it’s important to indicate which type of deadline we’re dealing with. From my experience there are two rough buckets of deadlines.
- Very Fixed Deadline: tied to a particular external event or circumstance that isn’t moving (conference, funding requirement, book launch, etc).
- Invented Deadline: an amalgamation of team priorities.
Different deadlines can completely alter your approach towards project execution. Typically, when writing on a project on paper, an Invented Deadline will be your team’s deadline. However, with a Very Fixed Deadline, that should most definitely not be your team’s deadline*. Because project are often late, you’ll need to build in some margin. How much margin?
When you’re planning a project with a Very Fixed Deadline, you must consider a few things:
- What are the consequences for not meeting the Very Fixed Deadline?
- Is there a gradient of acceptable solutions? This can often be a working prototype, screenshots, or a minimized feature scope.
If your consequences are high and there’s a very small gradient of acceptable solutions, you’re going to need a ton of margin to ensure that you get to where you need to be. If the Very Fixed Deadline is either not that important, or there’s a variety of acceptable solutions, then you’ll take significant pressure off the end deadline.
Above all, be proactive and communicative about your deadlines by indicating which type they are and build your project plan around these discoveries.
*Make sure to still communicate you’re dealing with a Very Fixed Deadline. If you ever want to tick off your developers, give them an Invented Deadline, but tell them it’s a Very Fixed Deadline with no wiggle room. I’ve seen teams work through the holidays, only to have a projects sit for a month, which is not a great way to build trust and goodwill.