The Hidden Cost of Setting Unrealistic Deadlines
If you shoot for the moon, you’ll probably miss and end up with poor results
In this article, I show that not all decisions have the same “structuring” property, and that it has an intricate link with path dependence. This fact has important consequences on process optimization through time — consequences from which we can derive project management advice.
Your experience in getting a kidney stone operation first and anesthesia later is different from having the procedures done in the opposite sequence.
Concrete examples sometimes say more than a thousand words — this one from Nassim Taleb (Antifragile) gets you an immediate sense of what path dependence is.
To make the link between path dependence and process optimization through time, let me take the detour of a parable.
The parable
You live a happy life with your wife Emmy, you have 2 wonderful children and a dog called Marvin. You’re born a millionaire, but you still work hard to protect endangered species and to slow down deforestation. The picture couldn’t be more perfect, except for one snag: your wife is totally unaware of path dependence. It’s Sunday afternoon and the sun is glowing outside.
3 p.m.
Emmy shows up in the living room as if she has just seen the Grudge in the corridor:
— I have totally forgotten to tell you that my mother is coming for a tea time snack at 4 p.m. and I really need to finish that crossword puzzle. I think we have everything needed to make an apple tart. It’s her favorite dessert. Can you handle it?
— Well…Hmmm… Your mother… In an hour…
— I knew you would accept! You’re the best!
After an emergency Google search for the apple tart recipe, it’s clear that you don’t have time for handmade pastry. You preheat the oven, take the industrial ready-to-use pastry out of the fridge, cut the 3 Granny Smiths left on the counter into slices, correctly assemble everything, breathe a sigh of relief and place the dish in the oven.
3:45 p.m.
The tart still needs about half-an-hour to cook. Emmy passes her head through the open kitchen door, and she speaks with an innocent voice, before running back to her crosswords puzzles [remember the snag]:
— My mother will only be here at 4:30 p.m., so you have an extra 30 minutes! Oh, and before I forget: she only swears by handmade pastry — the industrial gives her bloat. You don’t want to see that, do you? Fortunately, Google says that it only takes one and half hour to make an apple tart with handmade pastry. Given that you started at 3 p.m. and that she’ll be there at 4:30 p.m., you’ll spend in total one hour and a half in the kitchen, so you can go for it!
In the real world
If the last sentence contradicts common sense without doubt, injunctions of a (moderately less, I admit) similar shocking nonsense go totally unnoticed in the corporate world.
In the apple tart parable, the structuring consequence of the first decision — the choice of the pastry — is visible. The quasi-irreversibility of assembling the tart won’t raise debates, and almost everyone on Earth would agree that we can’t “uncook” something.
However, in a corporate context, the technicality of some processes muddies the waters, so the structuring property of first decisions and the path dependence consequences are less visible, thus less taken into account.
In every project where the IT component is critical (another way of naming 95% of today’s projects), great chances are that convexity (see the blue curve of the graph of this article) will apply, and that the apple tart parable won’t be so far from reality.
If convexity applies, you’ll drag around poor initial design decisions with you like a ball and chain till the end of the project. And if you do not set enough time for design decisions, you’ll presumably chain yourself to a few millstones — hence the importance of deadline setting.
“Shoot for the moon. Even if you miss, you’ll land among the stars.”-like reasoning, coupled with Parkinson’s law invocations, may incline managers to prefer an “unrealistic deadline + extra time”-strategy to the simpler “realistic deadline”. This is natural and is motivated by prudence, the mould and mother of all virtues.
However, this comes at a cost. As the apple tart parable illustrates, optimization isn’t transitive:
Optimizing from T1 to T2 (T2 being the unrealistic deadline) and only then from T2 to T3 (extra time) does not yield the same results as optimizing from T1 to T3 straight.
Consequences of time optimization intransitivity
In the real world, if T2 is an unrealistic deadline, T2-based retroplanning induces a sense of emergency from day 1. In this state of mind, team members won’t put up with the blank page dread very long and will feel an urge to write/build/do anything, how absurd it may be, not to feel like falling behind. Eaten by action bias.
When “playing extra time” (T2 to T3):
- They’ll have to pay interest on the technical debt taken during “regulation game time” (T1 to T2)
- They’ll pay a possibly important context switching cost to plunge back into early-stage manipulations
- They’ll get their hands dirty by trying to transfer half-cooked apples and compote to the handmade pastry, and even Marvin won’t eat the half-cooked industrial pastry, for Marvin prefers poetry.
- Team members who don’t see the initial contradiction will feel guilty to have built a mediocre design first-hand and not to have met the first deadline.
Mitigation tips
As a manager or a team member, what can I do about it ?
1- Revisit the mitigation tips presented here:
2- Discuss quality along with timing and results
Maybe you can agree on a less ambitious deliverable for which you’ll be able to meet the deadline while keeping your work clean. If you really have no choice but to ship that apple tart within 1 hour, then the industrial-pastry tart will surely taste better than the half-cooked, dosage error-scarred handmade pastry one.
3- Defend your case
If in the parable, the end-to-end recipe time is an unarguable information, in real life, not only will you tend to be overly optimistic (planning fallacy), but people will challenge your completion time estimate, especially if they ignore that Murphy’s law reigns whenever lines of code are involved.
Therefore, you need to be prepared to defend your patch. A priori attempts to forecast the completion time of a complex corporate project won’t reach a consensus among stakeholders. Without tangible quantitative anchors, self-interests will supersede logic and you will not debate on estimates but on visions of the world — to each his own truth.
Getting around this problem is tricky. To leave the barren sphere of subjectivity, you can objectify your view trying to reference-class forecast the completion time based on historical figures (compute the fudge ratio of in-house past projects for instance, as discussed in this article).
Of course, past performance is not indicative of future performance, but the definition of insanity is doing the same thing over and over again, expecting different results. If you never achieved a given task within X months, then you unlikely will today, unless you dramatically change the way you work.
The second way of getting around the problem is to rephrase it. “How long will it take to do that?” is a difficult question to answer. “Is doing that within X months reasonable if we want to keep the work clean?” is a simpler one. Dealing with that lower bound aspect first can be a good starting point for further discussion.
4- Redefine prudence
I said earlier that the “unrealistic deadline + extra time”-strategy couldn’t be totally demonized because it had a prudent dimension. However, this may not be the most efficient form prudence can take.
The wish for a safety time buffer mostly comes from the fear of not shipping. To allay this fear, we must show that setting a realistic deadline first-hand doesn’t imply working in “tunnel mode” and shipping only at the last minute.
That’s where prototypes come on stage. By prototype, I refer to the Pragmatic Programmer definition: “With a prototype, you’re aiming to explore specific aspects of the final system. With a true prototype, you will throw away whatever you lashed together when trying out the concept, and recode it properly using the lessons you’ve learned”.
This means that it’s okay for a prototype not being exhaustive or not having fancy colors, and the disposable nature of it frees you from the fear of shipping your work.
Working with prototypes will therefore ensure:
- Regular shipping
- Learning of user requirements through a feedback loop (because let’s be honest, as Pragmatic Programmer tip #75 says, in day 1 “no one knows exactly what they want”)
- Early crash and therefore early adjustments
A good way to allay the fear of not shipping is also to monitor progress on a regular basis. I’m not an advocate of fancy, one-size-fits-all, fashion-driven, consulting-branded tools, but I think a simple burn-down chart, challenged with past experience, can be useful to monitor scope creep and sound the alarm in time should some delay dawn over the horizon.
To conclude, remember that if you do not hand-make the pastry, your mother-in-law will likely blame you for poor quality. And she doesn’t care about your first T2-based retroplanning constraint, for she’s also unaware of path dependence — it’s a genetic disorder. So you’d better make sure everyone is okay with industrial pastry before settling for this option.
Additionally, take the apple tart example as the antithesis of what you’re looking for when you structure your work. David Thomas and Andrew Hunt (Pragmatic Programmer authors) captured the essence of good design with this simple and yet powerful statement: “Good design is easier to change than bad design”.
Good design requires thinking. Thinking requires time. Time optimization isn’t transitive. Unrealistic deadlines, with the intent of securing your project’s landing, can dig its grave.
Disclaimer: this is a personal and simplified view which aims at identifying overall trends, opening debates and triggering self-reflection. I deliberately made it light style and a bit ironical — take it with a pinch of salt!
