Why the fine “art” of scheduling?
If it were a science then every project would be delivered on time!
This sadly is not the case. Overruns are so common that most people have no faith in project deadlines. 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 a good schedule by following some simple rules.
Principles of Scheduling
Rule #1 – Never give off-the-cuff or unconsidered responses (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.
More times than I can remember I have sat and watched an inexperienced project manager in a meeting with clients or senior management blurt out a date or like “four weeks from today”. Not one of them to my knowledge ever delivered, it was just a response to pressure, a desire to please.
If management pushes you, give a realistic answer if you have one or ask for more time to formulate a proper estimate – remember it’s your project and you will only be undermining your own success by giving an ‘off the cuff’ response.
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 spread contingency throughout your project time line 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 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.
Contingency really refers to the Vth commandment, or “promise low / deliver high”. It is better to be pessimistic in your estimations and then surprise people with a better than expected performance than it is to cut your estimation to the bone and blow your schedule at the first hiccough. The old adage “think of a number and then double it” has some validity when it comes to project scheduling.
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 require daily updates from your team then it makes sense to break into day-by-day chunks. Then 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 prioritising 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.
Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.