The Art of Project Scheduling

Why the “art” of project scheduling?

If it were a science then every project would be delivered on time!

This sadly does not seem to be the case. In fact, overruns have become so common that people have lost faith in project deadlines and view them with a great deal of cynicism.

In truth, the art of scheduling is based on experience and the more experience you have, the more accurate your schedule will be. However, you can still produce an accurate schedule by following some simple rules.

PRINCIPLES OF PROJECT SCHEDULING

Rule #1

Never give off-the-cuff or unconsidered responses i.e. don't commit to something you can't deliver).

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 not only be wrong, it will come back to haunt you. A considered response when you have had time to evaluate all the factors is much better. A date picked out of the air is good to no-one, least of all yourself.

Rule #2

Eliminate uncertainty wherever you can.

The more specific you can be in your project planning, the more accurate your schedule will be. If you leave functionality or other items unspecified in your plan, then you will, at best, only be able to approximate them in the schedule. Don't go overboard, though, there is a balance. If you are spending time adding detail to tasks which will have no impact on the project delivery date, then you are probably wasting your time.

Rule #3

Build in plenty of contingency to cope with variation.

No matter how well specified your project and how accurate your schedule, there will be the inevitable random influences that will wreck your carefully crafted schedule. People get sick, equipment fails and external factors join together in a conspiracy to see that you miss your target date. In order to buy yourself some insurance you should build in an adequate amount of contingency, so that you can cope with unexpected delays.

You should also spread contingency throughout your project timeline and not just place it 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 breaking it up and spreading it throughout your project you allow yourself more options and are able to control the project more closely. You can also “buy back” time when you return unused contingency to 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. If you are going to require daily updates from your team then it makes sense to break into day-by-day chunks. That way everybody has the same understanding of what must be achieved 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 better to simply block-schedule one or two months of testing. Maybe 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 my optimum level of granularity is a week. This means that tasks are scheduled on the basis of the number of weeks they take. Week-by-week is much more comfortable for most people since finishing a task by the end of the week seems more natural than finishing it on a Monday or Tuesday.

Day by day scheduling can provoke more overhead than you really need. If a task is scheduled to be completed on Wednesday but due to difficulties it cannot be completed, it is unlikely that it will be finished on the Thursday, even if a team member predicts it to be so. It is more likely it will overrun by a couple of days and finish sometime on Friday, meaning that subsequent tasks can't take place until the next week. If I schedule day-by-day then I spend all of my time updating the schedule and not managing the project. On the other hand if I schedule week-by-week it is much easier to cope with such 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 even be affected at all (depending on my level of contingency).

The only exception to this is where I need to force the pace of a project. I do this by imposing tighter deadlines, to the day or even down to the hour, for completion of tasks. A higher level of control however implies a higher level of attention and if I do this, I know it has implications for my own work-load as well. On a finer grade of schedule I will 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 events and circumstances you could not have foreseen will interrupt the flow of your project. It's your job to take them all in your stride. Schedule for the most likely delays and cope with them should they arise. If experience or instinct tells you that a certain type of task will overrun, then anticipate it, pad it with some contingency and make sure you have adequate resources on hand when it comes up.

A good way to cope with this is to implement a bit of impromptu risk management (see Risk Management). By anticipating likely risks and prioritizing them you will be better able to deal with the unexpected! It also makes a lot of sense to let someone else help assess the risk to your project.

Note: The preceding was taken from Nick Jenkin's A Primer on Project Management. Nick's primer was released on the creative commons license making the above subject to the same licensing terms.