For many good reasons deadlines can be seen as bad things. For more context and clarity, I recommend Beyond Deadlines by Jabe Bloom.
So here is what can happen if we take the time to look beyond a deadline and ask about why it is important.
Imagine that we are going to have a birthday party.
And now imagine that we want to develop an application to help us organise and run the party.
We might start by asking for the full application functions to be ready 2 months prior to the party (which, being a birthday, is a date that is fixed).
We may find that the reason we need the application is to help us draw up the list of attendees first and this is why we need it 2 months prior.
However the other things that we need the application to do are not needed by that date and can be delivered a bit later.
Functions are needed at different times
A basic set might look like the above.
- Function to draw up a list of attendees – needed 2 months prior
- Function to create invitations and get them ready to mail – needed 6 weeks prior
- Function to order the ingredients and make the cake – needed 2 days prior
- Function to run the party (check in the guests) – needed on the birthday
By asking why a date is important, we have created a list of functions in order of priority – so that we can make an informed choice about delivery instead of trying to develop and deliver all of the functions at once.
We also have a great conversation about why each function is needed and what it will be used for.
People often set deadlines for good reasons, looking beyond and asking about those reasons is a great starting place.
Thank you to Jabe Bloom (@Cyetain) for inspiring this post with his submission for Lean Kanban Netherlands 2012
What is a deadline? Let us start with it being a demand for delivery of something by a certain date.
I think that demand for delivery by a deadline is really a couple of different things.
- ‘Real’ dates. These are for things that will not move such as the start of an event or a holiday special. These are true deadlines in that the item will have no value if it is delivered after this date. We don’t get these very often.
- Dependencies. These need to be worked with as true dependencies, then when things move around, we can see what else has been impacted. They can be a bit hard to pick up sometimes and we need to ask questions to get enough understanding from the person requesting delivey by a certain date to pick up that it is really a dependency. We have lots of these.
A couple of examples of dependency dates
- Benefit dependencies. Where the business model states that we will start getting benefits from a certain date. Many people will not see these as dependencies and will treat them as deadlines. Identifying the key influential people and having discussions with them to fully understand the dependency is important so that we can all drive to the same goals.
- Downstream activities dependencies. These include training, marketing and so on. Our teams need to include these groups as part of the build. When we find that we are going too fast we need to extend the concept of working on smaller and more valuable items to all involved groups. Then we can start to realise the benefits as soon as possible.
Update 25th September 2012
One of the reasons we may get pressure to meet a deadline is due to a misinterpreted dependency. These can be identified when we call them critical dates, without also mentioning the dependencies that the dates are based upon.
Conversations with key people can help us to discover more about these dependencies. They might be taken aback a little when you first start to ask about the reasons for the critical date, so be careful to explain why you are asking and empathise with the pressures that they are also under.
These concepts are ‘bread and butter’ for seasoned project delivery professionals. The key point is that most of the time we should be managing to dependencies and not to dates.