There are three inescapable tropes in stories about software projects: the client or boss who brings the deadline forward, the team on a death march to fulfill an unrealistic deadline, and the delayed project that doesn’t work when it’s finally delivered.
There is a reason why these three tropes are so common.
When we plan a project, there are three dimensions we can adjust: the project’s scope, cost, and delivery date. Those three dimensions are interdependent; for example, if you want to increase the scope, the cost will also increase, and the delivery date will be later.
Someone often wants to touch one or two of those dimensions without making changes in the other, which is just impossible. A project is like a water balloon: when you press on one side, the opposite side will bulge out. I don’t know what you did when you were kids, but when I played with water balloons, I learned that I couldn’t press on all sides simultaneously because the balloon would burst and I would get soaked from head to toe.
A common situation arises when someone comes and says: “This three-month project of yours, we need to deliver it in two months.” Mind you; this person won’t say it to an experienced project manager because they know it won’t work. They say it to someone like you or me, because we will fall into the trap and start making absurd concessions: “Well, we could write fewer tests, we could work Saturdays, and then if everything works on the first try and everyone manages to deliver on time, we might be able to do it.” And, before you know it, this “we might be able to do it” will have turned into a “we will do it for sure” that they’ll hold you to.
How do you think this story ends? Remember the balloon: When someone pushes on the delivery date, the other sides must give. We will need to provide more resources and reduce the scope. If we have to deliver one month sooner, we must remove one month’s work. If we don’t do it, the delivery date will come and go, and we won’t have delivered a working product.
Boom! The three tropes at once!
It also happens in the other direction: that person asks to add two months’ worth of work without adjusting the deadline. They don’t usually say it so blatantly; instead, they do it a bit at a time with many excuses each time. Unfortunately, this is a trap everyone falls into, but you can improve your chances if you remember the balloon. Ignore the siren song wafting out of this person’s mouth: if we add more work to the project, we must delay the delivery.
So far today, I only talked about adjusting the project’s scope and deadline, but not about adjusting its resources. In theory, we should be able to do more work for a project without changing the delivery date if we get more people working on it, but reality is more complicated than that.
Some time ago, I saw a word problem in a mathematics textbook: if a man can dig a one-meter deep hole in one day, how deep a hole can two men dig in one day? The answer is not two meters: two men can dig a broader hole, but not a deeper one. Many projects are full of tasks like this, where twice the people cannot do the work in half the time.
Remember the balloon next time someone wants to change your project’s scope or deadline. If they want the delivery date moved, you must reduce the scope; if they want to add work, you must deliver later. Don’t give anything without getting something in return, or the balloon will burst in your hands and you’ll get soaked.
The illustration for this Coding Sheet comes from “The Hole Book” by Peter Newell.