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 to force the pace of a project. I do this by imposing tighter deadlines, even down to the hour, for completion of tasks. A higher level of control, however, implies a higher level of attention. If I do this, I know it has implications for my workload as well. On a tighter schedule I need to pay closer attention to individual tasks to ensure their completion.

Rule #5 : Schedule for the unexpected.
Project management is the art of handling the unknown. Often, unforseen events and circumstances can interrupt the flow of your project. It is important to prepare for delays and be able to cope with them should they arise. Scheduling is particularly important in this respect since, if you do not anticipate a particular course of events, you may not have the resources to deal with it. If experience tells you that a certain type of task almost always overruns, then anticipate it, pad it with some contingency, and make sure you have the adequate resources to handle it.

The Myth of Completion
A commonly held myth about tasks is that "tasks can be partially complete," that is, a task can be 10 or 20 percent done. The purpose of such estimates is to estimate scheduling dates remaining in the lifecycle. But as most have experienced, "percent done" has little relationship with amount of time to estimate in the schedule. Another hazard is vague goals. If a goal is vague or imprecise, such as "write instructional documentation," then technically it is complete after the first written instruction. Be sure goals are spelled out.

On the other hand, if the task is well defined and has a measurable deliverable, then the goal is not achieved until it is delivered. For example: "complete a users guide and a technical manual." This task definition is much more useful because it has a clear measure of success. The only time the task is complete is when the documents are written, have been reviewed, edited, and are ready for publication. You are finished when there are no more changes to be made and you are ready to move on.

A danger in believing that tasks can be partially completed is that it gives you a false sense of security. Because half of a task can be a hard thing to define, people will tell you they have completed 50 percent of the task when they are 50 percent of the way through the time allocated to it. It might be the case that 90 percent of the task remains.

The people who behave as though time were elastic particularly entertain a misconception: that you can cram any amount of work into a particular length of time. Unfortunately, it is just these kind of people who you may find on your project team. These are the people who will tell you one of two things. After working ten days on a twenty-day task they announce that they have done only 10 percent. They insist they can make up the time. This is despite the fact that they fought tooth-and-nail in the first place to get twenty days allocated to the task. In this case their estimate is inaccurate. They won't hit their deadline and neither will you.

The second case is that team members report consistent and rapid progress all the way through the first eleven months of a one-year project. But then their progress slows down. On successive weeks they go from 95 to 96 percent complete. They will almost certainly overrun and claim three weeks later that the last 1 percent is almost done!
 

The old adage that "the first half takes 90 percent of the time and the second half takes the remaining 90 percent" is all too often true. This is not to say that tracking tasks in this way can't be useful. It can give you a good indication of progress and it can be a valuable feedback mechanism for your team. However, you need to view such progress reports with a critical eye.

A better approach is to divide tasks into smaller steps and to simply report on their completion. If a particular task misses its completion date, it automatically triggers an adjustment to the schedule. There should be no ambiguity or confusion.

Conclusion
Scheduling is a fundamental but neglected part of project management. Schedules are often inaccurate or out of date. In that case, they are not a useful tool for the project manager or the project team. Usually, they, and the client, have their attention fixed on the holy grail of delivery. Too often, the intermediate steps become neglected, jeopardizing delivery. By adhering to simple fundamental principles, and by constructing a schedule that is useful, the project manager can turn a schedule from an annoying burden into a useful tool.