Chapter 7: Scheduling and Charting

Scheduling and Charting Projects

Gantt Charts

Some projects are easy to follow. If you are building a house, it is easy to see when the foundation goes in, when the walls are completed, and when the electrical wiring is completed. Most projects are not that easy to see - it becomes difficult to schedule and monitor the project. For that reason it is critical to use charts such as Gantt charts and PERT charts to plan and monitor the project.

The Gantt chart is a horizontal bar chart which shows the relationship between project activities and time. Each step of the project is represented by a line placed on the chart which shows the time period when the task will be undertaken. When completed, the chart, as seen in figure 1, shows the sequence of tasks as well as which tasks can be undertaken at the same time.

To create a Gantt chart, first list the set of steps of the project or a part of the project and estimate the time for each task. Draw lines which show the time frame for each of the tasks. Other symbols can be used to show when tasks end or other critical points in the project. Figure 2 shows an example of how the Gantt chart can be expanded to show specific time points, who has responsibility for specific tasks and so forth.

In designing the Gantt chart keep in mind the need to provide different levels of detail for different audiences. For example, upper management may only want to know how the major phases of the project are progressing. They want a summary of time and cost. The members of the project team, on the other hand, need a great deal of information. Gantt charts showing work effort by the team need to be at a much greater level of detail.

A Gantt chart is often used by the project team as the main scheduling and control tool for the project. It is a powerful tool which can help the project manger understand the project better. It can help coordinate and expedite planning, eliminate idle time, troubleshoot conflicts in the schedule. On the other hand, Gantt Charts are not good for showing the interdependencies between tasks, or showing the impact of early or late starts on the project. For those types of analysis a PERT chart is needed.

Creating a Project Network

There are two ways to schedule a project: scheduling by dates, and Critical Path Method (CPM) scheduling. Of the two, we recommend the CPM method. Why? They both have advantages and disadvantages. Scheduling by dates is simple, fast and intuitive. CPM scheduling requires training and some time to learn. And no sane person would attempt it nowadays without a computer and software, adding considerable expense. So why do we go to all this trouble to use CPM scheduling? Because it gives us a far more quantitative and objective way to schedule our projects, and also paves the way for more sophisticated and objective project tracking techniques such as Earned Value. (We will discuss exactly what additional information you get from CPM after we show you how it works). You may already have tried scheduling by dates, perhaps even by using scheduling software. If you have tried it in CPM scheduling software, such as MS Project, Workbench, Project Scheduler, SureTrak, Timeline or others, you may have found yourself at odds with the software because of it. CPM and scheduling by dates don’t mix well. When you try to use the project plan, you find you have problems with understanding how tasks interrelate. Part of the reason it does not work well is because of the planning process people use.

Basically, you simply create a Gantt Chart (maybe you didn’t know that’s what it is called), with a list of tasks down the left edge of the page, and a timeline at the top. You then estimated by best guess method, when you thought each task would start and when it would finish, and created a bar on the Gantt chart to represent this amount of time. Using this method, the relationship between the various tasks is not specified. This means, that later on in the project, when tasks inevitably begin to slip, the effect on other tasks is guesswork. Different people, looking at the same schedule, would predict very different results. And even the most honest of us, under pressure of a major deadline, tend to be overly optimistic. This is why I recently heard the VP of a client firm of mine complain, “Why do I have so many one-hundred day projects until day ninety-nine?” He was tired of being told projects were on schedule until the last moment, and then being told they had in fact slipped by a considerable amount of time. CPM scheduling, if done with even a modicum of integrity, and tracked as the project progresses, helps to avoid this problem. This is because in CPM scheduling, we define tasks based on their dependency relationships with other tasks. Let’s see how this works.

There are several different approaches to this process, but the most common is simply to start creating a list of tasks, or activities. Each task has a list of “attributes”, including a description, an identification number (when using software, this is done automatically), an estimated duration, and so forth. Each task also has attributes called “dependency relationships”. That is, some tasks must be completed before others can start. Before we can paint a wall, we must put it up. Before we put the wall up, we must put up some kind of support structure. And so forth. We must keep this in mind as we create our list of tasks.

We use two graphic tools to model a project schedule. They are called the “Gantt Chart” and the “PERT Chart”. The Gantt chart was invented by Henry Gantt to plan the World War I Allied war effort. It has a timeline at the top, the list of tasks we created at the left, and a bar for each task on the chart itself. This is the one you probably used if you scheduled by dates. The length of the bars is proportional to the estimated duration for the task - the longer the task duration, the longer the bar. Also, on the Gantt Chart is a vertical line called the “today line”, marking the current date. The today line moves across the chart as the project progresses. A task that falls entirely to the left of the today line should be completed, according to the schedule. A task falling entirely to the right of the today line has not yet started. And a task intersecting the today line is a task in progress, and its percent complete should be proportional to the portion of the line to the left of the today line. The Gantt chart shows us where we stand in time with regard to the list of tasks that comprise our project.

Below is a sample Gantt Chart from MS Project.

The PERT Chart reflects the dependency relationships between the tasks. The Rand Corporation invented PERT scheduling in the 1950’s to do the Polaris Missile Project. PERT scheduling is really a special kind of Critical Path Method Scheduling, involving a rather tedious statistical analysis of the project from the task level on up. The PERT Chart is the method they chose to represent the dependency relationships between the tasks. We seldom do true PERT scheduling, as it is only necessary on high risk, high uncertainty projects, such as research or space programs. The PERT Chart has become the defacto standard in the scheduling business.

The PERT Chart is comprised of a series of boxes, the size and positioning of which has no significance. The boxes represent the tasks, connected by lines we call links, which represent the dependency relationships. Tasks that are connected by a link are said to have a “dependency relationship”. The one that must come first is called the “predecessor”, the one that must follow is called the “successor”. Usually, when we talk about dependency relationships, we refer to tasks directly connected to each other in the PERT. Occasionally, when we want to refer to all tasks linked to a particular task, either directly or through other tasks, we refer to “ all successors” or “ all predecessors” , emphasis on the “all”, to let others know we are making this exception.

In MS Project, the PERT Chart looks like this:

Critical tasks are in bold faced red boxes, non-critical in black boxes, and summary tasks in drop shadowed boxes. We will learn the significance of the term “critical” in scheduling parlance, shortly. This shows the flow of work, the order in which things must be done.

We’ll start with a very small imaginary project of four tasks. Let’s create the first three tasks and look at them first.

We have 3 tasks with ID numbers 1, 2, 3. They have durations of 2, 3 and 1 respectively. These durations could be any unit of time, from milliseconds to millennia. For our purposes, we’ll call them days. The PERT Chart indicates that task 1 must be completed before task 2 can start, and task 2 must be completed before task 3 can start. Therefore, the project takes 6 days overall. We just add the durations.

Now let’s add task 4, which has a duration of 4 days, a predecessor of task 1, and a successor of task 3.

The PERT now tells us that task 1 must finish before tasks 2 or 4 can start, and that both 2 and 4 must finish before 3 can start.

The project duration is now 7 days. the duration of the lower path on the PERT. The duration of a project is determined by the longest path through the project. This project has two paths, path 1-2-3, with a 6 day duration, and path 1-4-3, with a 7 day duration. This longest path, since it determines how long the project takes, is called the “ Critical Path ”. This is the first definition of critical path.

CP = P longest

There are two additional definitions coming up. Each will supersede the previous definitions. Note that there is a difference in how we use the term “critical” in scheduling and in conversational use.

For our theoretical discussion, we will use a different format for the PERT because we need eight fields displayed, and Project can only display five at a time. The key to the fields we will use in our Critical Path Analysis are as follows:

ES FS EF ID Dur LS TS LF ES = Early Start FS = Free Slack EF = Early Finish

ID = ID number Dur = Duration

LS = Late Start TS = Total Slack LF = Late Finish

The Forward Pass

To find out more about our project, we will do a Critical Path Analysis. The first step in this analysis is called the “ Forward Pass ”. It will give us two new attributes for each task, Early Start and Early Finish . These will be the earliest dates we can hope to start and finish each task.

To do the forward pass, we need to make several assumptions. We will only identify two of them here. The first is that the estimated durations we have at the beginning of the project are correct. Of course, if you have any experience with projects, you know that estimated durations often are incorrect. None of us is a perfect fortune teller! So how can this process work if we make an assumption that we know will later turn out false?

This brings us to the very basis of the planning process. The information we write down, such as Gantt Charts, PERT Charts and the many other reporting tools we use in scheduling, are in and of themselves, meaningless! They have no intrinsic value. It is the “act of planning”, not the paper that makes scheduling work. When someone sits down and carefully plans out the entire project, that makes the schedule have value. Remember this only works if the planner puts in realistic values for durations. If the durations are unrealistic, the plan is worthless. The plan will change as circumstances dictate. These models of the project schedule, the Gantt and PERT charts, are dynamic. Each time the durations, or other factors, change, we change the model. The ongoing planning process, not the models, make scheduling worthwhile.

The second assumption is about how we see time in scheduling. During any time period, there is working and non-working time. In scheduling, we assume that the non-working time doesn’t exist. That is, that nothing happens during this time. In each time period, there is a start time and an end time. Between these times is the non-working time, which we now are assuming doesn’t exist.

This means that the end of any working period is the same time, in scheduling terms, as the start of the next working period. If we are using days, then the end of a given work day at 5:00pm is the same time as 8:00am the next working day. The hours or days in between don’t exist. Of course we know that in reality work can be done during these times, but in our theoretical discussion, we will say it can’t. Later, using software, we can schedule overtime to be done in these “in between” times.

We can use either “start of day” dates, or “end of day” dates for our date attributes. We’ll use “end of day” dates. We’ll explain why after we do the forward pass.

Now let’s do our forward pass.

We start with Task 1. Its early start date is end of day 0. (Remember, end of day 0 is the same time as start of day 1). To get the earliest finish date we add the duration to the early start date.

EF = ES + Duration

0 + 2 = 2. The early finish of task 1 is end of day 2.

The early start of the successor, task 2, is the early finish of the predecessor, task 1. That is, end of day 2. We add the duration to get an early finish of 5.

We might be inclined to make 5 the early start of task 3, but we notice 3 has two predecessors, tasks 2 and 4. Both predecessors will have early finish dates, and either could be the early start of task 3. We must wait until we know both possibilities, and then pick the correct one. So we write the 5 above the upper right corner of the task 3 box followed by a comma to remind us that there will be other possible early start dates later.

We must now do all forward passes through all paths to task 3, to get all the possible early start dates. In this tiny project, that means task 4. The early start of task 4 is 2 (from the early finish of its predecessor, task 1). Adding task 4’s duration to the early start, we get an early finish of 6. This gives us the second possibility for the early start of task 3, which is 6.

Now we can choose the correct early start date for 3. It will be the later of the two dates (the larger of the two numbers). This is because task 3 can’t start until both task 2 and task 4 are complete. Task 2 finishes end of day 5, but task 4 doesn’t finish until end of day 6. Task 3 must wait on both. In this case, end of day 6. We can now put the early start date in for task 3 and add the duration to get the early finish date. 6 + 1 = 7.

Note that the early finish of 3, the last task in the project, is the same as the duration we calculated before we started our critical path analysis, 7 days.

The reason we used end of day dates rather than beginning of day dates is that with beginning of day dates, we would have had an early start for task 1 of 1. Its early finish would have been 3 (early start + duration). In fact, all of the date numbers would have been one larger. These would have been the same date, but indicating the beginning of the day rather than the end of the day. The early finish of task 3 would have been 8. Remember, that’s beginning of day 8, the same time, scheduling wise, as the end of day 7. But it confuses people to see an 8 for the final early finish when they know the project is 7 days long. So we use end of day dates.

The next procedure is called the “ Backward Pass ”. It will give us a late start and late finish date for each task. Late Start will go in the bottom left corner of each box. Late Finish will go in the bottom right corner.

We’ll start at the end of the project and work backwards. This means we need a Late Finish date for the final task on the project to start with. This could be any date at all, from 0 to infinity, in theory. (Some projects I’ve been involved in seemed to last to infinity!) For simplicity purposes, we’ll assume the Late Finish date of the final task is the same as the Early Finish. You’ll just have to take my word for it that other dates can be used, and CPM scheduling will account for it. The late start of a task is it’s late finish minus duration.

LS = LF - Duration

7 - 1 = 6. Task 3’s late start is 6.

Task 2’s late finish, 6, is the late start of task 3, it’s successor. Its late start is 6 - 3 = 3.

Again, we might be inclined to copy the 3, the late start of the successor task, into the late finish of task 1, the predecessor. But we notice that task 1 has two successors, 2 and 4. We need the late start date of both successors before we can select the late finish of task 1. So we put the 3 below the box to remind ourselves that there is more than one possibility for this date.

Now we must follow each path on the project backward to task 1 to get all possible late finish dates. We’ll start at task 4.

Task 4 has a late finish of day 6 (the late start of it’s successor, task 3). It’s late start is 6 - 4 = 2. This is the second possible late finish for task 1.

Now we can pick the correct late finish date for task 1. It will be the earliest possible date, the smaller number, 2. If it finishes day 3, then task 4 wouldn’t start until day 3, wouldn’t finish until day 7 and task 3 wouldn’t start until day 7 and finish day 8. This would be a one day slip in our schedule. So 1 must finish by end of day 2. It’s late start is 2 - 2 = 0.

We have completed our forward and backward passes. Notice that task 2, is different than the others. It is the only task in which the early start and late start and also early finish and late finish are different. On the lower path, the early start and late start are always equal, as are the early finish and late finish. Remember, the lower path is also the longest path. The path along which the early start and late start and the early finish and late finish are always equal is always the critical path. That same path is always the longest path.

Cp = P Es=Ls & Ef = Lf

There are two additional attributes we will discuss in this introduction to scheduling. They are called Total Slack and Free Slack . They are also called “ float ”. In scheduling, the terms slack and float are interchangeable.

Total slack is defined as the amount of time a task can slip without affecting the end date of the project. There are two ways to get total slack. One is by pure logic. Just look at the task and figure it out. The other way to get total slack is to calculate it. We’ll look at our schedule and figure the total slack out logically, then see if you can find the mathematical relationship.

Look at task 1. If it slips by even one day, tasks 2 and 4 start a day later. Task 4 finishes day 7, and task 3 starts day 7 and finishes day 8. That’s one day later than currently scheduled. So if task 1 slips by even one day, the project end date slips the same amount. So task 1 has no total slack. We’ll enter this 0 for Total Slack in the center at the bottom of box 1.

The same logic applies to task 3 and task 4. On task 2, we see that it can slip by one day before the project end date is affected. That is, it can finish a full day late, day 6, and the project can still be done in 7 days. Task 2 has one day of total slack.

See if you can figure out how to calculate Total Slack. It is calculated by subtracting early start from late start or early finish from late finish.

TS = LS - ES or LF - EF

Notice that on the lower path, the total slack is always 0. This is the longest path, and the path where early start equals late start and early finish equals late finish. This leads us to our final definition of Critical Path. The Critical Path is the path along which total slack equals zero.

Cp = P Ts = 0

This definition includes the two previous definitions. That is, the path along which total slack equals zero will be the path along which early start equals late start, which will always be the longest path. This is the definition software uses to calculate and display the critical path.

The final attribute in our introduction to scheduling is free slack . Free slack is defined as the amount of time a task can slip without affecting any other task. It too can be figured out logically or mathematically. Let’s look at it logically first.

We’ll start with task 4. How much time can it slip without affecting task 3? If you said zero, you were right. If task 4 slips at all, task 3 slips with it.

On task 2, the free slack is one. It can slip a full day, from finishing day 5 to day 6, without affecting task 3 at all.

Task 3 has no successor, so how do we get its free slac? We apply another rule, which comes from experience in calculating these numbers. That rule is that free slack is always less than or equal to total slack.

Fs <= Ts

This does not define free slack, but does limit the range in which free slack can occur. When total slack is zero though, then free slack must be zero. So the free slack for task 3 is zero.

On task 1, the free slack is zero. If is slips at all, tasks 2 and 4 slip the same amount.

On a simple PERT like this one, the free slacks and total slacks are the same. This will not be the case on more complex PERTs representing real projects.

Now let’s look at the mathematical way to calculate free slack. To get the free slack of a task, look at its successor’s early start, and subtract the predecessor’s early finish to get the predecessor’s free slack.

FS Pred = ES Suc - EF Pred

On task 4, subtract its early finish, 6, from task 3’s early start, 6 - 6 = 0

On task 2, subtract its early finish, 5, from task 3’s early start, 6 - 5 = 1

On task 1, we have a different circumstance. It has two successors. In this case, we select the earliest early start of all it’s successors and subtract task 1’s early finish. Since both successors to task 1 have early starts of day 2, we subtract 2 from 2. 2 - 2 = 0.

Now we’ll do another project schedule, this time with 9 tasks. Below is the PERT chart.

Can you work through the critical path analysis for this project?

Solution:

What would happen if task 9’s duration changed to 3 days?

We now have two critical paths. When task 9’s duration increased, it used the one day of total slack it had, and it became critical. Note that when task 9 lost its day of total slack, so did task 8. Total slack is a “ shared ” attribute. Along a particular path, tasks often share the total slack, as in the care of tasks 8 and 9, and tasks 3 and 4. The three days of total slack both tasks 3 and 4 have is the same three days. If one task uses some or all of it, the other task loses it. Even if the task using it comes later in the schedule.

What happens if we add a new task to the schedule? Let’s add a new task, task 10, with a duration of 5, a predecessor of 1, and a successor of 4. We’ll use the original duration of task 9, 2 days. To do a critical path analysis of this project, we simply do a forward and backward pass through the new path, making sure that we change any and all affected attributes of the tasks around it.

What happened here is interesting. Notice that task 3 now has 3 days of total slack, while task 4 has only 2. And task 3 now has a day or free slack, which it didn’t have before. Why is this so?

When task 10 is added, it pushed task 4 close to the end date of the project, and closer to its successor, task 5. Since the end date of the project did not change, task 4 lost a day of total slack. Similarly, when task 4 moved closer to task 5, task 4 lost a day of free slack. But now task 5 is not starting as soon as task 3 finishes, its starting as soon as task 10 finishes, giving task 3 one day of free slack it didn’t have before.

Who Cares?

Why do we bother to do this analysis? Why take the time, to either calculate these attributes manually, as we used to do, or learn software that does it for us? Let’s look at what we’ve learned about our project and how that knowledge can be used.

What do we know now about this last project we analyzed that we didn’t know before. There are four things:

Critical Path

Slack

Project Duration

Dates (Early Start, Early Finish, Late Start, Late Finish)

We now know the critical path for this project, those tasks which have no slack. We also know which tasks have slack, and how much. We also know the duration of the project, important knowledge. Finally, we know what are the earliest and latest times we can start and or finish each task on the project and still finish on time.

But there is a lot more to be had here, if we know where to look.

From this point forward, let’s call the duration units in our schedule weeks. Days are a little unrealistic, not much can be changed when we only have 12 days to begin with. Since we only called them days because that is the convention in scheduling theory, we can now change them to weeks. That means that the dates now all refer to “week 5” or “week 9”, not “day 5” or “day 9”. Likewise, task 4 now has three weeks of slack.

Let’s start with the most common problem in most all projects. Time. If our project schedule indicates 12 weeks duration, but we have been told to complete the project in 10 weeks, we have a problem. But we also have a solution now. If the project must be done in less than the currently scheduled time, we must “attack the critical path”. That is, shorten the longest path down to the desired duration.

There are three fundamental ways to shorten the critical path. The first is to shorten the duration of the tasks on the critical path. Shortening the duration of tasks not on the critical path will have no affect on the overall duration of the project. There are many ways of shortening task durations. We can add more resources. Get bigger equipment. Use a different method of doing it that is more efficient time-wise. Any of these and many others would shorten the duration.

The second method of attacking the critical path is to change the dependency relationships between the tasks on the critical path. There are two variations on this method too. One way is to remove tasks from the critical path entirely, tasks that are not truly dependent on other critical tasks. We’ll do this in the software.

The second way to change dependencies is by overlapping tasks. For example, if the successor task doesn’t have to wait until the predecessor is finished, but can start after part of the predecessor is done, we can overlap the two. Again, we’ll see how to implement this in the software.

The third way of shortening the critical path is to change the scope of the project. If we define the project as less than originally scheduled, we can usually do it in less time. This is most commonly done in software development projects, where additional but functionally unnecessary features of the software can be deleted, at least in the release currently being developed.

Another important piece of information we get from this analysis is a priority list of which tasks to closely monitor. Critical tasks are the ones we want to monitor most closely time-wise. They have no slack, no margin for error. The next most closely monitored tasks are those with little slack, such as tasks 8 and 9. Caution: tasks with a lot of slack often get ignored until they become critical or worse, and often slip the entire project for lack of attention!

Let’s look at how this data helps us in assigning resources. We’ll assume we need one resource each, a programmer, on tasks 3 and 6. We have two programmers available, Sue and Tom. Tom’s a good programmer, but Sue is even better. Which resource would you put on each task? If you guessed Sue on task 6 and Tom on task 3, you guessed right. We use our best resource on the critical path, giving us better odds of finishing the critical task on time and staying on schedule.

Now we’ll proceed, with Tom on task 3. Imagine Tom calls us week 5, the week before task 3 starts, and informs us his boss has just temporarily reassigned him to write a program for the vice president, which will take 4 weeks. What is the effect on the schedule, and how do we respond to this?

The effect on the schedule is significant. It will slip the end date one week, and change the critical path to path 1-2-3-4-5. We can tell this by noting task 3’s total slack of 3 weeks. If the task slips four weeks, the effect on the project finish date will be 4 - 3 = 1, a one week slip.

What is our response? While we may have evil thoughts toward Tom, it is not really his fault. In fact, if he took the trouble to tell us, he has done us a favor. One of the major purposes of scheduling is to see the effects of change as early as possible, and Tom’s call has given us early notice of an important change.

We will oppose the change, not the person, but whether or not we are successful or not in preventing this change, the earlier we know about it, the better off we are. We should thank Tom, and oppose the change in the appropriate manner.

Let’s change the last scenario a little. What if Tom calls week 5 and tells us he has been reassigned for 3 weeks, not 4? How do you respond?

Your response should be about the same as in the previous example. At first glance, you might think that a three week slip is acceptable, since task 3 has three weeks of total slack. But look further. If task 3 slips three weeks, it becomes critical. And task 4 becomes critical too. Remember that total slack is often a shared attribute, as in the case of tasks 3 and 4. If one uses the slack, they both lose it. So now we have two more critical tasks. What do you suppose happens to the odds of success on a project as the number of critical tasks increases? It goes down. And it goes down exponentially. So we want to prevent tasks from going critical if possible.

Further, remember why we put Tom on task 3? Because task 3 is not critical and Tom is not our best resource. If task 3 slips by 3 weeks, Tom is now on a critical path, something we used our influence to prevent.

Finally, think about the implications of this slip on the resources assigned to task 4. We will probably have to call them and ask if they can do task 4 week 10 instead of week 7, the originally scheduled date. How likely is it that they are available at that time? They have been planning to do task 4 week 7, and have probably made plans for the following weeks, including week 10. They may not be able to reschedule, especially if there is more than one resource on the task. We may be lucky to get them to do it by week 12!

In an ideal world, the schedule would never change. Unfortunately, I don’t know where that world is! In this one, rescheduling resources is a fact of life, and everyone, including the Project Manager, accepts it and lives with it. We try to minimize it as much as we can, but understand that a schedule is a “living document”, and almost constantly changes on all but the simplest of projects.

Summary

The use of charting techniques in project management is absolutely critical. The tools allow the project manger to provide the kind of planning which is useful in all projects, but critical in large projects. Using GANTT charts and PERT charts allows us to build a basis for:

Making Decisions about Scheduling

Planning the Use of Resources

Planning and Predicting Project Times

Making the Project "Visible"

Controlling the Project

Creating a Basic Structure for Reporting on the Project.

Appendix – Tools

Attached are some worksheets to help with your project planning process. They include:

A Planning Worksheet for Goals and Objectives

A Risk Analysis Sheet

[1] Drucker, Peter, "The Coming of the New Organization," Harvard Business Review, 1988.

[2] Anonymous, "A Plea for Clarity," PM Network, October, 1993, pp 41.

[3] "Reining in Runaway Systems" Information Week , December 16, 1991, p. 20-24.

[4] Based in part on the work of Cash, McFarlan, and McKinney in Corporate Information Systems Management , Irwin, 1983.