Why is scheduling an art? If it were a science, every project would be delivered on time. Overruns have become so common that people have lost faith in schedules and view them as very malleable. In this article, Nick Jenkins explains how to prevent this in your project.
Principles of Scheduling
The art of scheduling is based on experience. The more you have, the more accurate your schedule will be. On the other hand, a project manager with little or no experience can achieve "scheduling success" by following some simple rules.
Rule #1 : Never give on-the-fly commitments.
Essentially, scheduling is one part prediction and one part expectation-management. If you are pressured into picking a date "on-the-fly" at a random meeting you can bet that the date will be wrong and it will come back to haunt you. A well thought out response, when you have had time to evaluate all the factors, is much better.
Rule #2 : Eliminate uncertainty wherever you can.
The more specific you are in your project planning, the more accurate your schedule will be. If you leave out functionality or leave items unspecified in your plan then, at best, you will be able only to approximate them in the schedule. Don't go overboard though. If you are spending all your time adding detail to tasks, but the added detail has no impact on the project delivery date, then you are probably wasting your time.
Rule #3 : Build in plenty of contingency.
No matter how well specified your project is, or how accurate your schedule, circumstances can always occur that can wreck your carefully crafted schedule. People get sick, equipment fails, and external factors intervene, which increase the likelihood that you will miss your target date. Spread contingency throughout the project lifecycle, not just at the end. If you only have one pool of contingency allocated to the end of your project you are leaving yourself with a large slice of uncertainty. By spreading it throughout your project you allow yourself more options and are able to more closely control the project.
Rule #4 : Pick the right level of granularity.
When drawing up your schedule it is important to pick the right level of detail. That way everybody has a clear understanding of what must be achieved, and by when. On the other hand, if your project has large portions of time devoted to similar activities, testing for example, then it may be adequate to simply block-schedule one or two months of testing. You can leave the details up to your team. It all depends on the level of control you want.
In most projects I've dealt with (that have a lifecycle up to a year) my minimum level of granularity is a week. Tasks are scheduled on the basis of the number of weeks they take. Units of less than a week usually are not useful. If a task is scheduled to be completed Wednesday, but due to difficulties it cannot be completed, it is unlikely that it will be finished Thursday, even if a team member predicts it to be so. Unfortunately, this means that subsequent tasks can't take place until the following week. If I schedule day-by-day then I spend all of my time updating the schedule when it changes.
On the other hand, if I schedule week-by-week it is much easier to cope with small variations. If something scheduled for "the week beginning Monday the 21st" is delayed by one, two, or even three days, then subsequent tasks can either be moved comfortably or may not be affected at all, depending on my level of contingency. Week-by-week is also much more comfortable. This is because, for most people, finishing a task by the end of the week seems more natural than finishing it on a Monday or Tuesday.
The only exception to this is where I need