Project managers typically know how to use a scheduling software tool such as Primavera or Microsoft Project, either from a training course, mentoring from colleagues, or self-learning. However, despite this knowledge, many people use incorrect techniques in preparing their schedules. This paper is based on the author's observations in reviewing project schedules for numerous clients over the years. Most of these schedules contained errors that greatly reduced the schedule accuracy and value. This paper presents a list of the top 10 mistakes people make when preparing project schedules. Techniques that can be used to avoid these scheduling mistakes, along with a recommended schedule preparation procedure to help ensure that a schedule is accurate and complete, will also be discussed. This paper should interest people who are just learning how to schedule, as well as those who currently prepare schedules and want help in creating more effective ones. If you think you are a skilled scheduler, read this paper to see whether you are making any of the common scheduling errors. You may be surprised!
Top 10 List of Scheduling Mistakes
Before listing the top 10 scheduling mistakes, it's worth clarifying that this paper does not address schedule content (that is, what specific tasks to list for a project) because that is project-dependent and beyond the scope of this document. Also, this paper does not focus on how to use any specific scheduling software package, but rather concentrates on good scheduling techniques that should apply to any scheduling software. Finally, this paper was written specifically for people who lack scheduling experience, so that they can produce quality schedules. The author recognizes that exceptions to some of the guidelines listed may exist. For example, although this paper states that a project manager shouldn't link summary tasks, experienced schedulers can cite some specific situations where this technique is appropriate. However, the point is that proficiency in basic scheduling is needed first. Once proficiency is achieved, then advanced scheduling techniques and the “bending” of some of these guidelines becomes appropriate.
Listed below are the top 10 scheduling mistakes the author has seen in reviewing project schedules for numerous clients over the years. A more detailed description of each item follows.
1. Lack of scheduling knowledge
2. Inappropriate level of detail
3. Incorrect schedule logic
4. Lack of schedule contingency
5. Presence of “hangers”
6. Constraints misuse
7. Confusing duration and work
8. Linking summary tasks
9. Not using start and complete milestones
10. Not using the project summary task, header, footer, and legend
1. Lack of Scheduling Knowledge
Project managers typically have some level of knowledge regarding how to use a scheduling software package, either from a training course, mentoring from colleagues, or self-learning. Most scheduling software training courses do not train attendees on scheduling fundamentals, probably assuming they already possess this knowledge. Unfortunately, too many people preparing schedules do not understand basic scheduling concepts and use incorrect techniques in preparing and maintaining their schedules. The problem is that it is difficult, if not impossible, to prepare a correct schedule if the preparer does not understand the critical path method (CPM), which is the scheduling technique used with most scheduling software. If you don't know how to do a forward and backward pass, determine the critical path and calculate the total and free float, then most likely you won't know whether the schedule you just prepared is correct. For certain, you won't know how to check the schedule to see whether it is correct, and, unfortunately, the odds are that the schedule probably is not correct.
The author teaches a one-day class on scheduling techniques for experienced project managers, and the course begins with a review quiz on scheduling fundamentals. The quiz includes a project network diagram (shown in Exhibit 1), and the students have to determine the schedule dates, critical path and float. The typical test results are that less than 20% of the attendees can correctly do the CPM analysis and answer the quiz questions!
Here is your opportunity to check your CPM knowledge. Conduct a CPM analysis of the network diagram in Exhibit 1 and see whether you can answer these questions:
- The number of days to complete this project is: ___________
- The critical path is: ________________
- Which activities can be postponed without impacting any other project activities: _____________
- Which activities have path (total) float available: _____________
2. Inappropriate Level of Detail
Preparing a schedule with the appropriate level of detail is difficult. The key is that the schedule has to work for the project team. One frequent mistake made when preparing a schedule is creating too many tasks, which can make the schedule unmanageable. A real-life example seen by the author is a $300,000 IT project with more than 400 tasks in the schedule. A suggested rule of thumb is that each task should represent between 20 to 80 hours of work. This is different from the 8/80 rule, but the 8/80 rule tends to drive the project team to create an excessive number of tasks. If a task will require less than 20 hours, consider combining it with another task. If a task requires more than 80 hours, consider decomposing it into two or more separate tasks. The exception to this rule would be a sub-project schedule for a deployment or shutdown, where individual tasks may be less than an hour.
Large schedules can be unmanageable, so one technique is to use a high-level project summary schedule, with a minimum number of tasks. More detailed sub-schedules can then be prepared for each phase or for major deliverables and linked to the project summary schedule.
An additional mistake is not using progressive elaboration to add more detail to the schedule. For example, early in the project when the schedule is first prepared, a single task titled “software package implementation” is probably sufficient, since implementation details are probably still undefined. Later in the project, more tasks should be added to the schedule to fully describe the work needed for implementation.
Another common mistake is the incorrect naming of deliverables, activities, and milestones. A deliverable is defined as any measurable and tangible item produced to complete the project or a part of the project. Deliverables are either project-related (such as the project plan) or product-related (such as software configuration), and should be written as nouns. Examples of deliverables are “Test Plan Module 1” or “SAP Interface Design.” Activities are the things done to create a deliverable, and should be written using an active verb-noun combination, such as “Build Summary Report” or “Conduct Integration Test.” Finally, a milestone is a significant project event, typically the completion of a major deliverable or a major review point in the project. A milestone should be written using a noun-past tense verb combination, such as “Project Plan Approved.”
The task dialog box includes a comment field, and too often this goes unused. Use the comment field to fully describe a deliverable, including acceptance criteria. For example, a deliverable described as “Database Interface Program Design” is vague. To better describe the deliverable, add a comment such as “Database Interface Program Design, consisting of a written, descriptive narrative, a data flow diagram, a process flow diagram, and a written, preliminary unit test plan.”
3. Incorrect Schedule Logic
The Gantt view is not really useful for checking the schedule logic, since it's difficult to follow the task relationships. The network diagram view is also not very useful, since you need to scroll up and down, left and right to see the entire network diagram. A good practice is to plot the entire schedule (many print shops can print this for you) and hang it on the wall. Inevitably, when this is done, the project team finds logic mistakes and multiple opportunities to improve the network logic.
Another common logic mistake is using a start-to-start relationship, when a finish-to-finish is more appropriate. For example, assume you have two deliverables: Task A – Interface Module Coding, with 10 days duration, and Task B – Unit Tests, with seven days duration. Normally you would use a finish-to-start relationship, but to shorten the schedule you put the two tasks in parallel with a start-to-start relationship and a five-day delay for Task B. Obviously, different resources would be assigned to each task and the schedule logic dictates five days after Task A starts, Task B should start. Assume Task A and Task B have both started, but then the person assigned to Task A is out of work for two weeks due to sickness. The schedule logic doesn't recognize this situation; all it knows is that seven days after Task B starts, it should be completed, which is flawed logic. The correct schedule logic would be using a finish-to-finish relationship with a five-day lag for Task B. If this relationship is used, the schedule logic recognizes that Task B cannot be completed until five days after completion of Task A, which will happen once the sick person returns or another resource is assigned to Task A.
A final comment here is to be sure to explain why you are using a lead or lag in the task comment field. Nothing is more frustrating than looking at a schedule with a lead or lag, and not knowing the reason for it. Make sure you document the reason for each lead or lag so a viewer of the schedule doesn't have to guess why it's there.
4.7 Lack of Schedule Contingency
Most people include a contingency when preparing the project budget. They recognize that “things happen,” and extra funds are needed to handle the unknowns that will probably occur over the life of the project. However, how many people preparing a schedule include a schedule contingency? The recommendation is to include a task called “Project Contingency” just before the project complete milestone, as shown in Exhibit 2.
The other reason for having a schedule contingency task is to buffer changes to the completion date. When a schedule is updated, the completion date will probably change based on actual progress. However, project customers can find it frustrating when the project team gives them a new completion date every time the schedule is updated. A better approach is to adjust the project contingency task duration up or down based on actual progress, which will result in the project completion date staying constant. With this approach, the project completion date is only changed when the project team deems it appropriate.
5. Presence of “Hangers”
A basic scheduling rule is that every task should have at least one predecessor and at least one successor. The obvious exception is the project start milestone, which has no predecessor, and the project complete milestone, which has no successor. When a task lacks a predecessor and/or successor, the task is a “hanger,” which is an unintended break in the project network diagram. Exhibit 3 shows task H is a hanger. The problem here is that the forward and backward pass calculations will be incomplete and possibly wrong because each hanger results in a roadblock for CPM calculations. One response from offenders of this rule is that “the completed task doesn't tie into anything else in the schedule.” Given that project stakeholders looking at your schedule probably are not mind readers, tying the task successor to the project complete milestone is a method to clearly communicate that the task doesn't tie into any other schedule tasks.
Checking for hangers is a very simple using the Gantt chart view, which can be set up with columns showing the task numbers for both predecessor and successor tasks. To check for hangers, simply scroll down the task list looking for any tasks that lack at least one predecessor or successor. The exception is summary level tasks should not have a predecessor or successor. (Refer to scheduling mistake 8 for an explanation on why summary tasks should not be linked.) In Exhibit 4, there are two hanger tasks. One task lacks a predecessor and one task lacks a successor. Can you find the two hangers?
6. Constraints Misuse
When working with your project schedule, do not change the start or finish dates for tasks. When you change a start date, you add a “start no earlier than” constraint to the task. When you change a finish date you add a “finish no earlier than” constraint to the task. In both cases, you are overwriting the calculated dates and hence defeat the value of having a project schedule, which determines a finish date based on schedule logic and durations. Let your scheduling software calculate your start and finish dates!
As an example of how constraints impact dates, assume you add a “must finish on” date of August 4 for Task R. The calculated completion dates for the preceding tasks won't change, and let's assume the calculated completion date for Task R, before you added the constraint, was August 11. However, the scheduling software will follow your constraint command and show a Task R completion date of August 4, which results in five days of negative slack. This is equivalent to adding a new task just before Task R labeled “Miracle Occurs” with a negative five days duration. The bottom line is to be judicious in using constraints and be aware of how constraints can impact your schedule logic!
7. Confusing Duration and Work
Duration is defined as the total span of active working time, as defined by the project and/or task calendar, needed to complete the task. Work is defined as the actual number of hours of effort needed to complete the task. Availability (also called “maximum units”) is the maximum capacity for which a resource (or resources) is available to accomplish tasks during the specified time period. Duration, work, and availability are related. You can only specify two, and the scheduling software calculates the third parameter. The relationship between duration, work, and availability is:
Duration = Work/Availability
For example, if a task requires 60 hours of effort and the person is only 50% available, then the duration will be 120 hours (15 working days based on 8 hours per day). Be careful not to over-commit resources. Even if a person is 100% available, the assigned work for a person should not be more than 100%, except for a short duration deliverable, such as a deployment of a new software package.
Scheduling software typically allows you to select which variable (duration, work, or availability) you want to calculate and which other two variables will be input. Note that this calculation cannot be done until you specify at least two variables. The determination of what is calculated is done using the task information dialog box. The options available are fixed duration, fixed work, and fixed units. Exhibit 5 shows the task type relationships for one commonly used software package.
The recommendation is to use fixed duration as the initial task type. Once the section of the schedule you are preparing is developed and you are comfortable with the work effort hours, the resources assigned to each task, and the durations, then change the task type from fixed duration to fixed work. At this point, any changes to resource availability or hours of work effort will probably change the duration. This is exactly what you want in order to realistically reflect the impact of resource availability changes and/or work effort hours on the tasks and project completion dates. Also, note that when you use the fixed-work task type, effort-driven scheduling is automatically in effect. What this means is that as resources are added to a task, the duration decreases, since the work effort required is distributed among the assigned resources to the task.
8. Linking Summary Tasks
By definition, a “summary task” is a roll-up of subtasks linked to the summary. Some people like to link summary tasks, but this can cause problems with your schedule. Linking two summary tasks with a finish-to-start relationship means that all of the predecessor sub-tasks must be completed before any of the successor sub-tasks can be started. The general rule is to only link the lowest level tasks, and do not link summary tasks to other tasks or summary tasks.
In Exhibit 6, the Planning and Execution Phase Summary tasks are linked with a finish-to-start relationship. In this example, execution phase task E-1 really doesn't need to wait until the task “project approval” is complete; the schedule logic shows it can start once planning phase task P-4 is done. However, since the Planning and Execution Phase Summary tasks are also linked, the schedule logic requires that all planning phase tasks must be completed before any execution phase tasks can start.
9. Not Using Start and Complete Milestones
The first task in your schedule should be a project start milestone, and the last task should be a project complete milestone. Exhibit 3 shows the use of the project start and project complete milestones. This provides an easy way to link project tasks to a predecessor or successor when there are no other obvious ties to other project tasks.
10. Not Using the Project Summary Task, Header, Footer, and Legend
Have you ever viewed a schedule that doesn't list the project name or the status date somewhere? You look at the schedule and wonder what revision you are looking at and who did the revision. Scheduling software provides the ability to include header, footer, and legend information, but some people don't use this capability. Your company should define a standard schedule template, which will help ensure pertinent information is on every published schedule. The template should include use of the “project summary task,” which is a summary of all project tasks. A recommended schedule template format is:
- Header: project title and company logo
- Footer: date of the update, page number and total pages, and the name of the person who did the update
- Legend: schedule revision number, file location, and file name
Recommended Scheduling Procedure
When preparing a project schedule, keep in mind the progressive elaboration concept. For example, if you are just starting the project, your schedule should have more detailed information for early project phases, but only high-level information for the later phases. It is more efficient to prepare a schedule using a company-specific template, which may include a standard listing of typical project tasks. Follow these simplified steps in preparing a schedule if using Microsoft Project:
- From the Gantt chart view, input the project start date, project title, and project start and project complete milestones, and set the task type for all project tasks to “Fixed Duration.” Also add the header, footer, and legend information.
- Still working from the Gantt chart, enter the list of tasks needed, task relationships, work (effort) for each task, and a first guess at task duration.
- From the resource sheet, add each resource by name (if known) or workgroup that will be working on the project, and input the availability (maximum units) of each resource; this is the percentage of time each resource can commit to the project.
- From the Gantt chart view, split the screen: the lower half of the screen will be detailed task information for the task selected on the Gantt chart, which is the upper half of the screen. Add resources to the tasks as needed. For each task adjust the work hours assigned to each resource and the duration until you are satisfied that the work hours, resources, and duration reflects a workable plan to complete the task. Check for overload of resources using the resource graph, and adjust task resources and duration as needed.
- Highlight the tasks that you just “resource loaded,” then change the task type to “Fixed Work.” Note that at this point any changes to resource availability or hours of work will probably change the duration.
- From the Gantt chart you can now view your schedule and the critical path. In this view, the schedule should be checked to ensure every task in the schedule has at least one predecessor and one successor, which allows for calculation of the critical path. The exceptions are the summary level tasks, which should not have any predecessor or successors.
Project managers must understand the Critical Path Method, including how to do a forward and backward pass, determine the critical path, and calculate total and free float. This knowledge is important so the schedule logic can be checked to ensure the schedule is correct. It's also important to know the relationship between duration, work, and availability, and when to use each task type (fixed work, fixed units, or fixed duration). Schedules should use both project start and project complete milestones, a contingency task just before the project complete milestone, and make use of the header, footer, and legend. The project manager needs to prepare a schedule with the right level of detail, so the schedule is a manageable and useful tool for the project team. It's also important to avoid the common mistakes that can occur when preparing a schedule, such as hangers, misuse of constraints, and linking summary tasks. Finally, follow the recommended schedule preparation procedure to help ensure your schedule is accurate and complete. Hopefully, this paper will help you create more effective schedules!
By the way, here are the answers to the questions associated with the network diagram in Exhibit 1:
- The number of days to complete this project is 30 days
- The critical path are tasks A-B-D-F-H
- Activities C and G can be postponed without impacting any other project activities
- Activities C, E, and G have path (total) float available.