Week 4: Lesson
TABLE OF CONTENTS
Advanced Schedule Management
Introduction
Last week, we created our project schedule. We followed the processes found in
the PMBOK® Guide's Project Schedule Management Knowledge Area.
Remember that we started with a WBS and ended with a project schedule.
Since time is the indefinite continuous progress of actuality and events in
the past, present, and future regarded as being unabridged, PMI realizes
that one cannot measure time. However, a project manager can indeed
measure the schedule of activities. Therefore, PMI found it appropriate to
rename this knowledge area to Schedule Management in its sixth edition of
the PMBOK® Guide. We are bringing this up because the main textbook
refers to time management as it was published before the latest release of
the PMBOK®
Guide. Please keep this in mind as we explore this topic this week.
This week, we start with that project schedule. We will look at the
techniques that can be applied during project planning or during project
execution to keep the project schedule within stakeholder requirements.
Let's see what new things we can learn this week!
Rolling Wave
Not all projects can be entirely planned during the planning stage of a
project. But from all of the examples we have seen so far, a project gets
planned in its entirety during planning. The truth is, it is possible to plan a
project to just enough detail in the near term to just to be able to begin
working. Later, as the work progresses, successive phases are planned. This
technique is known as rolling-wave planning. This process reduces the time
needed to begin a project.
Rolling-wave planning is a technique in which phases, deliverables, work
packages, and activities that need to begin in the near term are planned in
detail. As these near completion, the planning for the next set of these tasks
begins. This repetitive process continues throughout the project.
Schedule Compression Techniques
In many projects, the calculated end date is not in line with stakeholder
expectations. What are the options for a project manager? How can a
project manager bring a project back into the expectations of the key
stakeholders? There are typically three methods
, available to a project manager to bring a project back into
compliance. They are displayed below.
• Fast tracking: This technique involves doing more work in parallel.
• Crashing: Crashing involves adding more costs or resources to get the
work done faster.
• Scope reduction: If it is not possible to get all of the work done on time,
perhaps doing less work is an option.
As you can see, each has its advantages and disadvantages. A project
manager must weigh each to determine the appropriate course of action.
Fast tracking and crashing will be described in more detail below. Scope
reduction is fairly straightforward.
However, it is never a good first option, because stakeholders rarely like
having less work done than originally planned on their project.
Fast Tracking
Last week, we discussed the four types of predecessors or dependencies.
• Mandatory
• Discretionary
• External
• Internal
Mandatory predecessors cannot be removed from the network diagram
because they are due to the type of work being accomplished. Likewise,
external predecessors typically cannot be removed from the network
diagram because they are outside of the project team’s control.
However, internal, discretionary predecessors could be removed from the
network diagram. They are predecessors placed there by the convenience
of the project team. In fast tracking, the project team looks for these types
of predecessors between activities on or near the critical path. These
predecessors are then removed from the network diagram. This allows
more activities to be performed in parallel. Thus, this method shortens the
critical path of the project. One drawback of the method is that it increases
the risk to the project because more work is occurring at the same time.
Crashing
Crashing involves adding more resources to get the work done faster. It
is a critical trade-off in project management. Let’s explore this a bit
more.
Crashing a Project Schedule
In crashing, there are two types of project times.
, 1. Normal time: This is the schedule that is typically estimated as the most
likely for each task. An estimate for the cost of each task will be made
considering this normal schedule.
2. Crash time: This is the result of expediting the activity by the application of
additional resources. Crashing is usually undertaken on critical-path (the longest
paths) activities to shorten project duration. Note: When crashing, only reduce
the critical path to the point of the next longest path. At that point, you have
created or added a new critical path and now must repeat the process with
multiple critical paths in mind.
Other Definitions
• Time limited: The project must be finished on time, using as few resources as possible.
• Resource limited: The project must be finished as soon as possible, without
exceeding some specific level of resource use or some general resource
constraint.
• System-constrained task: This is fixed time and resource crashing activities, a
process to reduce the schedule duration with added cost.
1. Develop cost slope for each activity; cost slope is "$ per day" or
other cost and time combinations.
2. Look for activity on the critical path with lowest slope (i.e., cost/time unit).
3. Iteratively crash activities on the critical path until the desired
combination of time and cost for the project is achieved.
Crashing a project schedule costs money. It should only be done when
the benefit or cost has been analyzed and it is determined to be of value
to the business.
Example: Crashing a Project Schedule
The Cost Slope: Optimizing Crashing Schedules Given a project with the data below.
Task Predecessor Normal Time Crash Time
A -- 8 6
B -- 6 3
C A 4 3
D B 5 3
E C 7 5
F D 4 4
G E, F 10 8
TABLE OF CONTENTS
Advanced Schedule Management
Introduction
Last week, we created our project schedule. We followed the processes found in
the PMBOK® Guide's Project Schedule Management Knowledge Area.
Remember that we started with a WBS and ended with a project schedule.
Since time is the indefinite continuous progress of actuality and events in
the past, present, and future regarded as being unabridged, PMI realizes
that one cannot measure time. However, a project manager can indeed
measure the schedule of activities. Therefore, PMI found it appropriate to
rename this knowledge area to Schedule Management in its sixth edition of
the PMBOK® Guide. We are bringing this up because the main textbook
refers to time management as it was published before the latest release of
the PMBOK®
Guide. Please keep this in mind as we explore this topic this week.
This week, we start with that project schedule. We will look at the
techniques that can be applied during project planning or during project
execution to keep the project schedule within stakeholder requirements.
Let's see what new things we can learn this week!
Rolling Wave
Not all projects can be entirely planned during the planning stage of a
project. But from all of the examples we have seen so far, a project gets
planned in its entirety during planning. The truth is, it is possible to plan a
project to just enough detail in the near term to just to be able to begin
working. Later, as the work progresses, successive phases are planned. This
technique is known as rolling-wave planning. This process reduces the time
needed to begin a project.
Rolling-wave planning is a technique in which phases, deliverables, work
packages, and activities that need to begin in the near term are planned in
detail. As these near completion, the planning for the next set of these tasks
begins. This repetitive process continues throughout the project.
Schedule Compression Techniques
In many projects, the calculated end date is not in line with stakeholder
expectations. What are the options for a project manager? How can a
project manager bring a project back into the expectations of the key
stakeholders? There are typically three methods
, available to a project manager to bring a project back into
compliance. They are displayed below.
• Fast tracking: This technique involves doing more work in parallel.
• Crashing: Crashing involves adding more costs or resources to get the
work done faster.
• Scope reduction: If it is not possible to get all of the work done on time,
perhaps doing less work is an option.
As you can see, each has its advantages and disadvantages. A project
manager must weigh each to determine the appropriate course of action.
Fast tracking and crashing will be described in more detail below. Scope
reduction is fairly straightforward.
However, it is never a good first option, because stakeholders rarely like
having less work done than originally planned on their project.
Fast Tracking
Last week, we discussed the four types of predecessors or dependencies.
• Mandatory
• Discretionary
• External
• Internal
Mandatory predecessors cannot be removed from the network diagram
because they are due to the type of work being accomplished. Likewise,
external predecessors typically cannot be removed from the network
diagram because they are outside of the project team’s control.
However, internal, discretionary predecessors could be removed from the
network diagram. They are predecessors placed there by the convenience
of the project team. In fast tracking, the project team looks for these types
of predecessors between activities on or near the critical path. These
predecessors are then removed from the network diagram. This allows
more activities to be performed in parallel. Thus, this method shortens the
critical path of the project. One drawback of the method is that it increases
the risk to the project because more work is occurring at the same time.
Crashing
Crashing involves adding more resources to get the work done faster. It
is a critical trade-off in project management. Let’s explore this a bit
more.
Crashing a Project Schedule
In crashing, there are two types of project times.
, 1. Normal time: This is the schedule that is typically estimated as the most
likely for each task. An estimate for the cost of each task will be made
considering this normal schedule.
2. Crash time: This is the result of expediting the activity by the application of
additional resources. Crashing is usually undertaken on critical-path (the longest
paths) activities to shorten project duration. Note: When crashing, only reduce
the critical path to the point of the next longest path. At that point, you have
created or added a new critical path and now must repeat the process with
multiple critical paths in mind.
Other Definitions
• Time limited: The project must be finished on time, using as few resources as possible.
• Resource limited: The project must be finished as soon as possible, without
exceeding some specific level of resource use or some general resource
constraint.
• System-constrained task: This is fixed time and resource crashing activities, a
process to reduce the schedule duration with added cost.
1. Develop cost slope for each activity; cost slope is "$ per day" or
other cost and time combinations.
2. Look for activity on the critical path with lowest slope (i.e., cost/time unit).
3. Iteratively crash activities on the critical path until the desired
combination of time and cost for the project is achieved.
Crashing a project schedule costs money. It should only be done when
the benefit or cost has been analyzed and it is determined to be of value
to the business.
Example: Crashing a Project Schedule
The Cost Slope: Optimizing Crashing Schedules Given a project with the data below.
Task Predecessor Normal Time Crash Time
A -- 8 6
B -- 6 3
C A 4 3
D B 5 3
E C 7 5
F D 4 4
G E, F 10 8
