Phoney Deadlines are Deadly for Achieving Results

Ever had deadlines that must be met causing short-term decisions to be made? Ever worked over time with your team to meet an important deadline after which the delivered product wasn’t used for a couple of weeks?
I believe we all know these examples where deadlines are imposed on the team for questionable reasons.
Yet, deadlines are part of reality and we have to deal with them. Certainly, there is business value in meeting them but they also have costs.

The Never Ending Story of Shifting Deadlines…..

Some time ago I was involved in a project for delivering personalised advertisements on mobile phones. At that time this was quite revolutionary and we didn’t know how the market would react. Therefore, a team of skilled engineers and marketeers was assembled and we set out to deliver a prototype in a couple of months and test it in real life, i.e. with real phones and in the mobile network. This was a success and we got the assignment to make it into a commercial product version 1.0.
At this time there was no paying customer for the product yet and we built it targeted at multiple potential customers.
For the investment to make sense the deadline for delivering version 1.0 was set to 8 months.
The prototype worked fine but how to achieve a robust product when the product is scaled to millions of subscribers and thousands of advertisements per second? What architecture to use? Should we build upon the prototype or throw it away and start all over with the acquired knowledge?
A new architecture required us to use new technology which would require training and time to get acquainted with it. Time we did not have as the deadline was only 8 months away. We double checked that the deadline can be moved to a later date. Of course, this wash’t possible as it would invalidate the business case. We decided to not throw away the prototype but enhance it further.
As the deadline was approached it became clear that we were not going to deliver a product 1.0. Causes were multiple: the prototype’s architecture did not quite fit the 1.0 needs, scope changed along the way as marketing got new insights from the changing market, the team grew in size, and the integration to other network components took time as well.
So, the deadline was extended with another 6 months.
The deadline got shifted 2 more times.
This felt really bad. It felt we let down both the company and the product owner by not delivering on time. We had the best people part on the team and already had a working proto type. How come we weren’t able to deliver? What happened? What could we do to prevent this from happening a third time?
Then the new product was going to be announced at a large Telecom conference. This is what the product (and the team) needed; we still got a deadline but this time there was a clear goal associated with the deadline, namely a demo version for attracting first customers! Moreover, there was a small time window for delivering the product; missing the deadline would mean an important opportunity was lost with severe impact to the business case. This time we made the deadline.
The conference was a success and we got our first customers; of course new deadlines followed and this time with clear goals related to the needs of specific customers.

The Effect Deadlines Have

Looking back, which always is easy, we could have finished the product much earlier if the initial deadline was set to a much later date. Certainly, there was value in being able to deliver a product very fast, i.e. having short-term deadlines. On the other hand there were also costs associated with these short-term deadlines including:

• struggling with new technologies caused by not taking time to do the necessary trainings and take time to gain experience,
• working with an architecture that does not quite fit causing more workarounds,
• relatively simple tasks becoming more complex over time.

In this case the short-term deadline put pressure on the team to deliver in short time causing the team to take short-cuts along the way causing delays and refactoring at a later time. Over time less results will be delivered.
What makes this pattern hard to fix is that the action of imposing deadline will deliver short-term results and seems a good idea to get results from the team.
This pattern is known as ‘Shifting the Burden’ and is depicted below. In the previous example the root cause is not trusting the team to get the job done. The distrust is addressed by imposing a deadline as a way to ‘force’ the team to deliver.

The balancing (B) loop on top is the short-term solution to the problem getting results from the team. The ‘fear’ of the lacking focus and therefore results leads to imposing a deadline and thereby increasing the focus (and results) of the team. The problem symptom will reduce but will reappear causing an ‘addiction’ to the loop of imposing deadlines.
The fundamental solution of trusting the team, prioritising and giving them goals is often overlooked. Also this fundamental solution is less evident and costs energy and effort from the organisation to implement. The short-term solution has unwanted side effects that in the long run – slashed arrow – have negative impact on the team results.
In the example above the fundamental solution consisted of setting and prioritising towards the goal of a successful demo at the conference. This worked because it was a short-term and realistic goal. Furthermore the urgency was evident to the team: there was not going to be a second chance in case this deadline was missed.
Another example
In practise I also encounter the situation in which deadlines are imposed is a team that seems to lack focus. The underlying problem is the lack of a (business) vision and goals. The symptom as experienced by the organisation is the lack of concrete results. In fact the team does work hard but does so by working on multiple goals at the same time. Here, clear goals and prioritising the work to be done first will help.

Also in this example, the action of imposing deadline to ‘solve’ the problem has the unintended side effect of not addressing the underlying problem. This will make the problem of the team not delivering result reappear.

Goals & Deadlines

In the examples of the previous section the deadlines I call phoney deadlines. When in practise a deadline is imposed it usually also implies a fixed scope and fixed date.
Deadlines
Deadlines should be business case related and induce large costs if not met. For the deadlines in the above examples this is not the case.
Examples of deadlines that have associated large costs if not met, are:

• associated with small market window of introducing a product (or set of features); the cost of missing the small time window is very high,
• associated with implementation dates of laws; again missing these deadline severely harms the business,
• hardware that becomes end of life,
• support contracts the end.

Goals
In the story above the ‘real’ deadline actually was 2 years instead of the 8 months. In this case the deadline probably was used as a management tool, with all good intentions, to get the team focussed on producing results. Whereas in fact it caused short-cuts to be made by the team in order to meet the deadline.
Getting focus in teams is done by giving the team a goal: a series of subgoals leading to the end-goal [Bur13]. Establish a vision and derive a series of (sub)goals to realise the vision. Relate these goals to the business case. Story mapping is one of the tools available to define series of goals [Lit].

Conclusion

Avoid setting deadlines as a means to get results from a team. On the short-term this will give results but on the long run it negatively impacts the results that the organisation wants to achieve.
Reserve deadlines for events that have a very high Cost of Delay when missed, i.e. the cost of missing the deadline is very large.
Instead, set a vision (both for the organisation and product) that is consistent with the fundamental solution. In addition, derive a series of goals and prioritise to help team focus on achieving results. To derive a series of goals several techniques can be used like Story mapping and Goal-Impact Mapping.

References