The Art of Project Scheduling

Why project scheduling is the art? If it were a science then every project would be delivered on time! 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 "Art":

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 teauate 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 alt 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.

For deeper knowledge on Project Scheduling, you are recommended to read out the book Project Planning, Scheduling, and Control

Related Civil Engineering Articles

• Scope, Budget and Schedule of Construction Projects
  Construction Projects are defined by their scope, budget, and schedule. For example, an Agency is to undertake a project to design and build a new ...
  
• Construction Scheduling Techniques
  The four project scheduling techniques widely used in construction projects are: . Bar Charts and Linked Bar Charts . Network Analysis and Critical ...
  
• Steps to Successful Schedules in Project Management
  If you search internet with "Steps to Successful Schedules", you will find millions of results. There are tons of resources that claim the perfect wa...
  

Top of Form

http://civilengineerblog.com/art-project-scheduling/Bottom of Form