Cutting Corners

I wrote this guide ten years ago when I was supervising undergraduate programming projects at the University of Toronto. I hope it’s still useful.

Contrary to popular belief, a schedule’s primary purpose is not to tell you what you’re supposed to be doing on any given day. Instead, it is is to tell you when you should start cutting corners. Suppose, for example, that you have ten weeks in order to accomplish some task. Five weeks after you start, you’ve only done the first third of work. You have several options:

Ignore the problem.
This is very popular, but doesn’t actually solve the problem.
Work longer hours.
This is also very popular, but is self-defeating.
Enlarge the team.
This is a good strategy if you’re peeling carrots, but usually doesn’t work on other kinds of projects because it takes more time to bring someone up to speed than it does to do the work yourself.
Move the deadline back.
Product groups and research teams often do this (usually in combination with the previous solution), but it usually isn’t an option for course projects. Instructors have to submit marks at the end of the term, and conference deadlines are fixed as well; sometimes, whatever hasn’t been done by the due date might as well not be done at all.
Cut corners.
The best approach is to update the schedule to reflect the rate at which you’re actually working, then drop features that it tells you can’t be finished in time.

Let’s go back to our example. At the start of the project you believed it would take ten weeks. You’re now at week five, but you’ve done only the first four weeks’ worth of work, so your estimates for how long tasks would take were too optimistic by about 25%. You should therefore go back to your schedule and add 1/4 to each task’s estimate. That inevitably means that some of the things you originally planned to do now spill off the end of your ten-week window. That’s OK; it’s a shame you won’t get to them, but at least you can start taking action now rather than trying to recover from a disaster.

People will thank you for this. “I’m sorry, we’re not going to have the frobnosticator for May 1” is OK in January, since it gives whoever was counting on the frobnosticator time to make other plans. It is not OK on April 30; neither is saying that it’s “done”, but full of bugs.

These calculations are the responsibility of the project manager. Her job is to make sure everyone is doing what they’re supposed to be doing, to shield the team from interruptions (there are always interruptions), and to track the team’s progress. She periodically compares how much has actually been done with how much was supposed to be done and adjusts plans accordingly.

Taking scheduling seriously is one of the things that distinguishes good teams from bad ones. It’s unfortunate that most students only get to do it once or twice in their courses, since you only really see the benefits with practice, but even a couple of rounds of practice can make a big difference.

Unfortunately, most undergraduate students aren’t allowed to adjust either the features they’re supposed to deliver or the deadline they’re supposed to meet. In that situation, the best you can do is figure which features are worth the fewest marks and cut those.

Updated: