This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.
You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.
In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.
Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.
A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.
Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.
Best case estimates
Murphy warned us:
Whatever can go wrong, will go wrong
Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.
Unless you don’t like promotions, who wants to go to the boss with the higher estimate?
Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.
This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.
Feeling up to a challenge
For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.
Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.
Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.
Belief that developers work better under pressure
Authors of the Design Sprint state:
Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.
It is easy to extrapolate this kind of thinking to the entire project.
While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.
You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.
Inevitably, new ideas will come in. Change is a core part of the software development process.
The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.
We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.
Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex