For the Deadline Was a Boojum, You See
“There was one who was famed for the number of things
He forgot when he entered the ship:
His umbrella, his watch, all his jewels and rings,
And the clothes he had bought for the trip.”
— Lewis Carroll, Hunting of the Snark
Lewis Carroll billed the Hunting of the Snark as an “agony in eight fits.” While it’s not entirely clear what Carroll meant by this, the sentiment well describes the process of scheduling and hitting deadlines in many organizations. Certainly it’s clear that the Bellman didn’t have a schedule, or he wouldn’t have left his crew’s belongings on the beach.
Some years ago, I worked for a software company where the CEO decided that missing a deadline was a personal failing on his part. No matter what, the software would ship on the day he had announced. Even if the product had bugs, even if it did not work, it shipped on the day the CEO had promised. “Not a single day of delay,” said he.
He preferred to ship a product that did not work and then release a bug-fix rather than delay the software even a day. He never understood why customers grew increasingly irate and would call the company to complain. He was keeping his promise to ship by a certain date, and certainly adherence to the schedule was important.
There are several problems with this belief. The most obvious, of course, is the stubborn belief that the software must go out on a specific date no matter what. Shipping any product that doesn’t work is going to upset your clients. Doing it repeatedly just makes the company look incompetent or indifferent to its customers. It is not meeting their needs to give them something that they cannot use.
Stepping back, though, from that minor problem, we have to ask what the point of the schedule was. There seemed to be little rhyme or reason to why the CEO picked the dates that he did. When pushed, his reaction was that scheduling was important, otherwise things didn’t get done. True, but not necessarily relevant. Fundamentally, a schedule is a tool; like all tools, it must be used properly or there is risk of serious injury. In this case, financial injury.
A schedule is not an arbitrary set of dates put down on paper to make sure that everyone works hard and doesn’t goof off. The goal of a schedule is also not to precisely calculate how long each task will take and account for every minute. It is not a holy writ to be held to beyond the bounds of common sense or product quality, nor is it put in place in order to have something to ignore. Sadly, I can’t count the number of times I’ve seen schedules designed with exactly those somewhat dubious objectives in mind. However, a well-designed schedule needs to satisfy some fairly significant constraints:
- A schedule helps make sure you don’t forget anything. It is both a to-do list and calendar. It helps people know what to work on when so that they don’t have to waste time constantly figuring that out.
- A schedule is a tool for marshalling resources. Building a product requires different resources, be those resources time, people, or equipment. The schedule helps make sure that the right resources are available at the right times so that the project can move steadily forward.
- A schedule is a tool for managing dependencies. In any large project, different pieces will depend on other pieces or on obtaining external resources. Some dependencies are obvious from the beginning, others do not emerge until the project is under way. The schedule helps organize tasks and manage dependencies so that they don’t derail the project.
- The schedule helps you determine what you can do in the time available with the resources you have; alternately, it helps you understand how long it will take to accomplish your goals with the resources you have available.
- The schedule enables you to define reasonable checkpoints, or milestones, that will let you know if you are moving successfully toward your planned target date or if problems are emerging. Missing a milestone is feedback that something is not working as expected!
- A schedule needs to have enough slush in it to handle unexpected problems. You can’t always determine all possible dependencies at the start; some parts of the project may turn out to be significantly more difficult than expected; you may discover that a piece that appeared to make perfect sense just won’t work and needs to be redone. When I speak about this to technology companies, someone always claims that they’ve done a few simple calculations and developed the perfect project schedule. Based on the reactions from the rest of that person’s department, I have my doubts.
- The schedule also needs enough slush to handle external delays. If your schedule is so tight that a severe winter storm closing the roads or having someone come down with the flu or having a vendor be late on a delivery will cause real problems, then you need to rethink the schedule. As that great sage Murphy so wisely said, “If something can go wrong, it will go wrong.” Plan for it.
You’ll also notice that if you design a schedule this way, you’ll tend to be running ahead of schedule, not behind. Falling behind schedule is demoralizing, particularly when the schedule feels arbitrary. Running ahead of schedule energizes the team to work harder. A team that falls behind tends to stay behind, while a team that runs ahead tends to get further ahead. In other words, nothing succeeds like success.
When you view a schedule in this way, it has the potential to be a powerful, flexible tool for getting things done as opposed to causing quality, effort, and enthusiasm to softly and silently vanish away. Isn’t that the whole point?
