Project managers typically know how to use a scheduling software tool such as Primavera P6 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. Here we present 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. 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
This article 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 we state 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.
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. 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.
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.
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! 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.
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.
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.
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.
Conclusion
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.
Lukas, J. A. (2007). Is your schedule correct? Common scheduling mistakes and how to avoid them. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.