Saturday, August 4, 2007

Scheduling Pitfalls

This post started as a reply to a question from my uber-boss about scheduling, but rapidly got too detailed and wordy for a poor little blackberry. So, here it is in a more palatable medium.

By way of disclaimer, I'll say here that this post uses the terms developer and manager. However, every individual fills both roles regardless of their responsibilities.

Q: What can we do to be better about meeting deadlines?

I think we need more skepticism and a better understanding of the limitations of our scheduling tools.

The most basic scheduling tool is a hard deadline. Its advantages are obvious: an unambiguous goal. Its limitations are similarly obvious. How do we know that the goal is attainable?

An itemized schedule is a much more refined tool. Its primary advantages are to instill confidence in the final deadline, and to keep track of progress throughout the development time, cutting lower priority features as appropriate. Its limitations generally come from letting it get too big or having too much confidence in it (which can be the same thing). The important thing to remember is that every item on the schedule is its own little hard deadline. So we have to be just as skeptical of those items as we would be a hard deadline. Does the worker truly understand the task? Does the task represent a need that must be filled? Will the task still represent a need when we get around to working on it? Both of these questions are much harder to answer the further out (in time and development) the task is.

One of the most uncomfortable tools is no deadline at all: it's done when it's done. This offers no comfort to you the manager; in a way its just giving up on the scheduling process altogether. However, for critical pieces it might be the way to go. The only advantage is that you almost never think you're done until you're actually done.

So why mention all of these tools? Well, as a manager or developer, you have to understand that you're always using at least one of them. That is, you're always bringing along some set of disadvantages which might endanger your project if you don't pay attention to them.

For example, suppose you're developing a design. Which tool would you use? Well, you won't benefit from an itemized schedule, because that implies understanding almost everything you're going to do. And of course, if you understood it all, you wouldn't need to design. How about a hard deadline? In that case, you'll probably get your design doc, but if the goal turned out to be unattainable what you have is a bad design on time. Of course, no deadline at all and you might find your developer spending most of his time (your money) reading digg.

The best solution is a hybrid approach. Each step or draft might have a hard deadline, but the number of steps or drafts is not predetermined in any way (no ultimate deadline at all). Add into this plenty of skepticism and you might just get a good design eventually without too much time wasted.

As another example (and I think this one is very important), consider the process of developing an itemized schedule. If you set a hard deadline for this process, and don't throw in plenty of skepticism or allow for multiple iterations, you'll end up with an itemized schedule with all of its own inherent limitations compounded by the limitations of the hard deadline. That is, you'll have a complete, itemized list that works somewhat well for about 2 weeks, but after that is only a drain on resources as people try to adapt the changing project and only-now-understood tasks to fit into the schedule provided.

However, keep in mind that if you confine yourself to small projects, the limitations above are not so serious. Here's where some more skepticism comes in: don't pretend to be able to schedule far beyond the next month or so. If a project is bigger than that, divide it up using the same hybrid approach as above. Use an itemized schedule for the short term and then evaluate your progress. Either rework the previous sub-project or schedule and work on the next sub-project.

I'll leave it off here. Keep in mind that this advice is as much for me as it is for anyone else.

This post was scheduled using an ad-hoc hybrid of hard and soft deadlines.