Good or bad you certainly don’t want to miss them. To quote Fred Brooks “How does a project get to be a year late? One day at a time.” or as I have heard it put in other ways, project death by a thousand cuts.
The word ‘deadline’ has quite grim beginnings at least according to Merriam-Webster where the origin dates back to the U.S. Civil War and was used to describe “a line drawn within or around a prison that a prisoner passes at the risk of being shot.”. At least I can say that the projects I have worked on have never had that sort of consequence but that does not mean missing them was not a major issue. It is a bit easier to use a more modern definition
On reading through Merriam-Webster’s examples of the use of the word however there are some other interesting points that I’m sure project team members can relate to where Wimmiam Williston Heartsill diarised in 1963 that the drawing of the deadline by prison guards “is done for no other purpose under the sun but to interfere with our only enjoyment and to grind us to the lowest depth of subjugation”. While we may not face the hardship as Mr. Heartsill and his fellow P.O.Ws, it does give cause for some reflection on what using deadlines has on an individual or team.
Given this background, it’s no wonder the concept of a deadline can make some people break out into a cold sweat and it can therefore be misconstrued as a negative management instrument. However it would be a mistake to avoid deadlines given the positive impact they can have and how a project should aspire to not just avoid missing them but to exploit them to achieve greater levels of productivity and success.
So what is the right definition of a deadline in a project?
Did you know that the word “run” has 645 definitions (as of 2011 so maybe more by now). If you look up Dictionary.com ‘deadline’ has three. Two of them more related to the original meaning I referred to earlier but it is the first definition (split into two sentences) that are most applicable to projects:
- “The time by which something must be finished or submitted; or
- The latest time for finishing something”.
The fact these are two sentences within a single definition suggests they can be interchangeable, however with projects that should not be the case. So for a start, make sure that in your project you are clear what you actually mean when you use the word ‘deadline’.
To help bring this to life a bit, in some project methodologies such as a traditional or waterfall projects, both definitions are readily used albeit in quite different contexts. The first definition (definition 1) is used for dependencies, such as ‘Finish-Start’ dependencies which rely on the one task being finished on time, by a date, in order to hit the start date of the subsequent task. However that same project may use the second definition (definition 2) when using a critical-path method or when describing the project end date.
In Agile, while the concept of dependent tasks exists, as Ron Jeffries (one of the authors of the Agile manifesto says deadlines are a management responsibility, “not a development responsibility”. Therefore, the second definition is perhaps more appropriate where a time limit is set top down for the project or product manager to meet goals by.
So it’s simple enough. Set a deadline and as long as you are clear to your project team on what you really mean, you’ll never miss one right?
Not quite. It’s a good start but it’s important to look at more than just the time dimension of a deadline given it is just as important to understand how effort is managed within your time limit.
Obey Parkinson’s Law
Parkinson's law, according to wikipedia, is the adage that "work expands so as to fill the time available for its completion" and it is a very real thing.
No doubt you have seen it in many of your projects, or even in other parts of your life such as the last minute work on assignments despite being given notification at the start of a semester of the submission deadline. Where it will almost always be seen in a professional setting are meetings - how many times have you seen a meeting that is set for 60 minutes go for less than 60 minutes? Probably not enough.
It can be misconstrued though as a warning against procrastination however that won’t help you meet deadlines although it might make you stress more about time. Think instead of the actual time it might take to complete the task rather than the elapsed time. In other words “if you wait until the last minute, it only takes a minute to do”. So instead of thinking of Parkinson’s law as avoiding leaving work until the last minute, make the deadline one minute. Note what Timothy Ferriss wrote in The 4-Hour Workweek “The end product of the shorter deadline is almost inevitably of equal or higher quality due to greater focus”.
Avoid missing deadlines by applying Parkinson’s law to reduce the time limits to complete tasks and achieve goals. Analyse your schedule and the effort you are assigning and be critical of any duration which has ‘contingency’ given chances are it will just be eaten up as the work expands.
Ultimately establishing and meeting deadlines on a consistent basis will depend on a number of variables within your project sticking to the script and let’s face it that does not always happen. However there are some key things you can do that will give you every chance of success and ensure you never miss a deadline again.
Break down tasks and goals to avoid them being too large
I’ve always been a fan of the Work Breakdown Structure where a large task or objective is continuously broken down into much smaller pieces until they are manageable. It will only be possible for a team to meet deadlines if the work is set at a level that can be managed. If the team can manage work at an hourly, daily or even weekly level, it will allow for time limits and deadlines to be set which align to actual productivity. Without breaking down the work, your team will be eating the elephant well beyond the deadline. Big task, small bites and short deadlines will allow you to achieve our goal with less risk and greater reward.
A clear definition of ‘done’ not ‘perfection’
Once you have your tasks broken down to the right level, set clear definitions of done for them. If your task completion targets are too vague, the project team will not know where to stop, or each project team member will have different views which will drive excessive iterations (beauty is in the eye of the beholder after all). Set and agree the clear success criteria and definition of done which is specific and well understood.
Not everything is equal
It will be important that you don’t place a limit on your work backlog in order to ensure their new ideas can always be reviewed as potential opportunities (this should be true of waterfall and agile projects although with the right level of control over scope creep). In a project, with so many concurrent activities underway at any time, the project team must know how to prioritise. This will ensure that the work completed within a time limit, reflects the most important tasks required to achieve the goal. Not only do deadlines get managed but the work completed should also be of the highest value.
Always complete retrospectives to determine what worked well and what the actual effort was to complete your tasks. Reset your deadlines for the next phase or iteration of your project based on what has historically worked. Establish an ongoing cadence of improvement and push your deadlines harder and drive performance further in the team. For the things you assess as not having worked that well? Stop doing them!
Create pressure and thrive
Most of us will work very hard on managing stakeholder expectations and the conservative approach to managing deadlines in the project will be to under-promise and over-deliver. This is always a flawed approach and will never allow the team to truly push boundaries and see what they are truly capable of.
In his book Mastery, Robert Greene writes about Thomas Edison who created pressure and external expectation by releasing information to the media about a new idea before it was ready. This effectively set a deadline outside of his control, created a pressure situation which could push him to greater things and also established a consequence for failure.
While your stakeholders may not want to see every detail of a large and complex project. Try publishing your team’s deadlines and follow the ‘press release' approach to let external expectations push your team beyond a conservative limit.
Never miss a deadline again
So that’s it right? Easy. It’s a nice goal to have so if you’ve read this article with a healthy dose of scepticism, like I said, take the bigger objective and break it down into smaller ones and start there. Of course, don’t forget to set yourself a deadline to achieve it!