Schedule Mistakes - Full
Schedule Mistakes - Full
Schedule Mistakes - Full
White Paper
1-888-762-3683
www.PMCentersUSA.com
This white paper is provided free of charge by PMCentersUSA for use solely by our key
clients. No portions of this work may be distributed or used in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping or information
storage or retrieval systems - without the written permission of PM Centers USA, LLC.
PM Centers USA, LLC is a charter Registered Educational Provider (R.E.P.) for the Project
Management Institute (PMI). PM Centers USA, LLC is also an Endorsed Education Provider
(EEP) for the International Institute of Business Analysis (IIBA).
PM Centers USA, LLC
634 Alpha Drive
Pittsburgh, PA 15238
(888)-762-3683
www.pmcentersusa.com
Authors Biography
October, 2014
Page 1 of 9
7.
8.
9.
10.
Prefab Walls
Build Trusses
Landscaping
Foundations
Install Walls
Install Roofing
10
10
SS+6
A
Clear Land
4
H
Clean-up
4
October, 2014
Page 2 of 9
October, 2014
Page 3 of 9
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 AInterface Module Coding,
with 10 days duration and Task BUnit Tests, with 7 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 startto-start relationship and a 5 day delay for Task B. Obviously different resources would be assigned
to each task and the schedule logic dictates 5 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 2
weeks due to sickness. The schedule logic doesnt recognize this situation; all it knows is that 7
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 5 day lag for Task B. If this relationship is
used, the schedule logic recognizes that Task B cannot be completed until 5 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
doesnt have to guess why its there.
#4 - Lack of Schedule Contingency
Task
P
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 Figure2 below.
Schedule
Contingency
11 days
Project
Complete
Task
Q
October, 2014
Page 4 of 9
#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 has a hanger, which is an unintended break in the project network diagram.
Figure 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 doesnt 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 doesnt tie into any other schedule tasks.
Project
Start
Project
Complete
F
H
Figure 4 Sample Task Listing Showing Two Hangers Can You Find Them?
October, 2014
Page 5 of 9
# 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 4th for Task R. The calculated completion dates for the preceding tasks wont change, and
lets assume the calculated completion date for Task R, before you added the constraint, was
August 11th. However, the scheduling software will follow your constraint command and show a
Task R completion date of August 4th which results in 5 days of negative slack. This is equivalent
to adding a new task just before Task R labeled Miracle Occurs with a minus 5 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. Figure 5 below shows the task type relationships for one commonly used software
package.
and you change the
If the task
type is:
Fixed Duration
Fixed Units
Fixed Work
Duration
Units
Work
Work
Work
Units
Work
Duration
Duration
Units
Duration
Duration
then
schedule
software
recalculates
Page 6 of 9
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,
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 Figure 6 below, the Planning and Execution Phase Summary tasks are linked with a finish-tostart relationship. In this example, execution phase task E-1 really doesnt 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.
Planning Phase Summary Task
Approvals
10 days
P- 4
E-1
Figure 6 Example of How Linking Summary Tasks can Impact Schedule Logic
#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. Figure3 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.
October, 2014
Page 7 of 9
#10 - Not Using the Project Summary Task, Header, Footer and Legend
Have you ever viewed a schedule that doesnt 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 dont 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:
October, 2014
Page 8 of 9
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. Its also important
to know the relationship between duration, work and availability; and when to use each task type
(Fixed Work, Fixed Units and 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. Its 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 shown in
Figure 1:
1.
2.
3.
4.
October, 2014
Page 9 of 9
1-888-762-3683
www.PMCentersUSA.com