Minggu, 25 November 2012
Chapter 6
Project Time Management
Project Time Management includes the processes
required to ensure timely completion of the project. Figure 6-1 provides an overview of the following major processes
in developing the project time schedule:
6.1 Activity Definition—identifying the specific activities that must be performed to produce the
various project deliverables.
6.2 Activity Sequencing—identifying and documenting interactivity dependencies.
6.3 Activity Duration Estimating—estimating the number of work periods that will be
needed to complete individual activities.
6.4 Schedule Development—analyzing activity sequences, activity durations, and resource
requirements to create the project schedule.
6.5 Schedule Control—controlling changes to the project schedule.
These processes interact with each other and with the
processes in the other knowledge areas as well. Each process may involve effort
from one or more individuals or groups of individuals, based on the needs of
the project. Each process generally occurs at least once in every project
phase.
Although the processes are presented here as discrete
elements with welldefined interfaces, in practice they may overlap and interact
in ways not detailed here. Process interactions are discussed in detail in Chapter
3.
On some projects, especially smaller ones, activity
sequencing, activity duration estimating, and schedule development are so
tightly linked that they are viewed as a single process (e.g., they may be
performed by a single individual over a relatively short period of time). They
are presented here as distinct processes because the tools and techniques for
each are different.
6.1 ACTIVITY DEFINITION
Activity definition involves identifying and
documenting the specific activities that must be performed to produce the
deliverables and subdeliverables identified in the Work Breakdown Structure
(WBS). Implicit in this process is the need to define the activities such that
the project objectives will be met.
6.1.1 Inputs to Activity Definition
.1 Work breakdown structure. The WBS is the primary input to activity definition (see Section 5.3.3.1
for a more detailed discussion of the WBS).
2 Scope statement. The project justification and the project objectives contained in the scope
statement must be considered explicitly during activity definition (see Section
5.2.3.1 for a more detailed discussion of the scope statement).
.3 Historical information. Historical information (what activities were actually required on previous,
similar projects) should be considered in defining project activities.
.4 Constraints. Constraints are
factors that will limit the project management team’s options; an example would
be the use of desired maximum activity durations.
.5 Assumptions. See Section
4.1.1.5.
.6 Expert judgment. Expert judgment
is discussed in Sections 5.1.2.2 and 6.3.2.1.
6.1.2 Tools and Techniques for Activity Definition
.1 Decomposition. Within the
context of the process of Activity Definition, decomposition involves
subdividing project work packages into smaller, more manageable components to
provide better management control. The technique of decomposition is described
in more detail in Section 5.3.2.2. The major difference between decomposition
here and in Scope Definition is that the final outputs here are described as
activities rather than as deliverables. The WBS and the activity list are
usually developed sequentially, with the WBS being the basis for development of
the final activity list. In some application areas, the WBS and the part of the
project scope. As with the WBS, the activity list should include
descriptions of each activity to ensure that the
project team members will understand how the work is to be done.
.2 Supporting detail. Supporting detail for the activity list should be documented and organized
as needed to facilitate its use by other project management processes.
Supporting detail should always include documentation of all identified
assumptions and constraints. The amount of additional detail varies by
application area.
.3 Work breakdown structure updates. In using the WBS to identify which activities are needed, the project team
may identify missing deliverables, or may determine that the deliverable
descriptions need to be clarified or corrected. Any such updates must be
reflected in the WBS and related documentation, such as cost estimates. These
updates are often called refinements and are most likely when the project involves new or unproven technology.
6.2 ACTIVITY SEQUENCING
Activity sequencing involves identifying and
documenting interactivity logical relationships. Activities must be sequenced
accurately to support later development of a realistic and achievable schedule.
Sequencing can be performed with the aid of a computer (e.g., by using project
management software) or with manual techniques. Manual techniques are often
more effective on smaller projects and in the early phases of larger ones when
little detail is available. Manual and automated techniques may also be used in
combination.
6.2.1 Inputs to Activity Sequencing
.1 Activity list. The activity list
is described in Section 6.1.3.1.
.2 Product description. The product description is discussed in Section 5.1.1.1. Product
characteristics often affect activity sequencing (e.g., the physical layout of
a plant to be constructed, subsystem interfaces on a software project). While
these effects are often apparent in the activity list, the product description
should generally be reviewed to ensure accuracy.
.3 Mandatory dependencies. Mandatory dependencies are those that are inherent in the nature of the
work being done. They often involve physical limitations. (On a construction
project, it is impossible to erect the superstructure until after the
foundation has been built; on an electronics project, a prototype must be built
before it can be tested.) Mandatory dependencies are also called hard logic.
.4 Discretionary dependencies. Discretionary dependencies are those that are defined by the project
management team. They should be used with care (and fully documented), since
they may limit later scheduling options. Discretionary dependencies are usually
defined based on knowledge of:
_ “Best practices” within a particular
application area.
_ Some unusual aspect of the project
where a specific sequence is desired, even though there are other acceptable
sequences.
Discretionary dependencies may also be called preferred logic, preferential
logic, or soft logic.
.5 External dependencies. External dependencies are those that involve a relationship between project
activities and nonproject activities. For example, the testing activity in a
software project may be dependent on delivery of hardware from an external
source, or environmental hearings may need to be held before site preparation
can begin on a construction project.
.6 Milestones. Milestone
events need to be part of the activity sequencing to assure that the
requirements for meeting the milestone(s) are met.
6.2.2 Tools and Techniques for Activity Sequencing
.1 Precedence diagramming method (PDM). This is a method of constructing a project network diagram that uses boxes
or rectangles (nodes) to represent the activities and connects them with arrows
that show the dependencies (see also Section 6.2.3.1). Figure 6-2 shows a simple network logic diagram drawn using PDM.
This technique is also called activity-on-node
(AON) and is the method used by most project
management software packages. PDM can be done manually or on a computer.
It includes four types of dependencies or precedence
relationships:
_ Finish-to-start—the initiation of
the work of the successor depends upon the completion of the work of the
predecessor.
_ Finish-to-finish—the completion of
the work of the successor depends upon the completion of the work of the
predecessor.
_ Start-to-start—the initiation of the
work of the successor depends upon the initiation of the work of the
predecessor.
_ Start-to-finish—the completion of
the successor is dependent upon the initiation of the predecessor.
In PDM, finish-to-start is the most commonly used type
of logical relationship. Start-to-finish relationships are rarely used, and
then typically only by professional scheduling engineers. Using start-to-start,
finish-to-finish, or start-to-finish relationships with project management
software can produce unexpected results, since these types of relationships
have not been consistently implemented.
.2 Arrow diagramming method (ADM). This method of constructing a project network diagram uses arrows to
represent the activities and connects them at nodes to show their dependencies
(see also Section 6.2.3.1). Figure 6-3 shows a simple network logic diagram drawn using ADM. This technique is
also called activityon- arrow (AOA) and, although less prevalent than PDM, is still
the technique of choice in some application areas. ADM uses only finish-to-start
dependencies and may require the use of dummy activities to define all logical
relationships correctly. ADM can be done manually or on a computer.
.3 Conditional diagramming methods. Diagramming techniques such as Graphical Evaluation and Review Technique
(GERT) and System Dynamics models allow for nonsequential activities such as
loops (e.g., a test that must be repeated more than once) or conditional
branches (e.g., a design update that is only needed if the inspection detects
errors). Neither PDM nor ADM allows loops or conditional branches.
.4 Network templates. Standardized networks can be used to expedite the preparation of project
network diagrams. They can include an entire project or only a portion of it.
Portions of a network are often referred to as subnets or fragnets. Subnets are especially useful when a project includes several identical
or nearly identical features, such as floors on a high-rise office building,
clinical trials on a pharmaceutical research project, program modules on a
software project, or the start-up phase of a development project.
6.2.3 Outputs from Activity Sequencing
.1 Project network diagrams. Project network diagrams are schematic displays of the project’s activities
and the logical relationships (dependencies) among them. Figures 6-2 and 6-3 illustrate two different approaches to drawing a
project network diagram. A project network diagram may be produced manually or
on a computer. It may include full project details, or have one or more summary
activities (hammocks). The diagram should be accompanied by a summary narrative
that describes the basic sequencing approach. Any unusual sequences should be
fully described. A project network diagram is often referred to as a PERT
chart. Historically PERT (Program Evaluation and Review Technique) was a
specific type of network diagram (see also Section 6.4.2.1).
.2 Activity list updates. In much the same manner that the activity definition process may generate
updates to the WBS, preparation of project network diagrams may reveal
instances where an activity must be divided or otherwise redefined to diagram
the correct logical relationships.
6.3 ACTIVITY DURATION ESTIMATING
Activity duration estimating is the process of taking
information on project scope and resources and then developing durations for
input to schedules. The inputs for the estimates of duration typically
originate from the person or group on the project team who is most familiar
with the nature of a specific activity. The estimate is often progressively
elaborated, and the process considers the quality and availability of the input
data. Thus, the estimate can be assumed to be progressively more accurate and
of known quality. The person or group on the project team who is most familiar
with the nature of a specific activity should make, or at least approve, the
estimate.
Estimating the number of work periods required to
complete an activity will often require consideration of elapsed time as well.
For example, if “concrete curing” will require four days of elapsed time, it
may require from two to four work periods, based on a) which day of the week it
begins, and b) whether or not weekend days are treated as work periods. Most
computerized scheduling software will handle this problem by using alternative
work-period calendars.
Overall project duration may also be estimated using
the tools and techniques presented here, but it is more properly calculated as
the output of schedule development (described in Section 6.4). The project team
can consider the project duration a probability distribution (using
probabilistic techniques) or as a singlepoint estimate (using deterministic
techniques).
6.3.1 Inputs to Activity Duration Estimating
.1 Activity list. The activity list
is described in Section 6.1.3.1.
.2 Constraints. Constraints are
described in Section 6.1.1.4.
.3 Assumptions. Assumptions are
described in Section 4.1.1.5. An example would be reporting periods for the
duration of the project that could dictate maximum durations, i.e., two
reporting periods.
.4 Resource requirements. Resource requirements are described in Section 7.1.3.1. The duration of
most activities will be significantly influenced by the resources assigned to
them. For example, two people working together may be able to complete a design
activity in half the time it takes either of them individually, while a person
working half time on an activity will generally take at least twice as much
time as the same person working full time. However, as additional resources are
added, projects can experience communication overload, which reduces
productivity and causes production to improve proportionally less than the
increase in resource.
.5 Resource capabilities. The duration of most activities will be significantly influenced by the
capabilities of the human and material resources assigned to them. For example,
if both are assigned full time, a senior staff member can generally be expected
to complete a given activity in less time than a junior staff member.
.6 Historical information. Historical information on the likely durations of many categories of
activities is often available from one or more of the following sources:
_ Project files—one or more of the
organizations involved in the project may maintain records of previous project
results that are detailed enough to aid in developing duration estimates. In
some application areas, individual team members may maintain such records.
_ Commercial duration estimating
databases—historical information is often available commercially. These databases
tend to be especially useful when activity durations are not driven by the
actual work content (e.g., how long it takes concrete to cure; how long a
government agency usually takes to respond to certain types of requests).
_ Project team knowledge—the individual
members of the project team may remember previous actuals or estimates. While
such recollections may be useful, they are generally far less reliable than
documented results.
.7 Identified risks. The project team considers information on identified risks (see Section
11.2) when producing estimates of activity durations, since risks (either
threats or opportunities) can have a significant influence on duration. The
project team considers the extent to which the effect of risks is included in
the baseline duration estimate for each activity, including risks with high
probabilities or impact.
6.3.2 Tools and Techniques for Activity Duration
Estimating
.1 Expert judgment. Expert judgment
is described in Section 5.1.2.2. Durations are often difficult to estimate
because of the number of factors that can influence them (e.g., resource
levels, resource productivity). Expert judgment guided by historical
information should be used whenever possible. If such expertise is not
available, the estimates are inherently uncertain and risky (see Chapter 11,
Project Risk Management).
.2 Analogous estimating. Analogous estimating, also called top-down
estimating, means using the actual duration of a previous,
similar activity as the basis for estimating the duration of a future activity.
It is frequently used to estimate project duration when there is a limited
amount of detailed information about the project (e.g., in the early phases).
Analogous estimating is a form of expert judgment (described in Section 6.3.2.1).
Analogous estimating is most reliable when a) the
previous activities are similar in fact and not just in appearance, and b) the
individuals preparing the estimates have the needed expertise.
.3 Quantitatively based durations. The quantities to be performed for each specific work category (i.e.,
number of drawing, meters of cable, tons of steel, etc.) defined by the
engineering/design effort, when multiplied by the productivity unit rate (i.e.,
hours per drawing, meters of cable per hour, etc.), can be used to estimate
activity durations.
.4 Reserve time (contingency). Project teams may choose to incorporate an additional time frame, called
time reserve, contingency, or buffer, that can be added to the activity duration or elsewhere in the schedule
as recognition of schedule risk. This reserve time can be a percentage of the
estimated duration, or a fixed number of work periods. The reserve time can
later be reduced or eliminated, as more precise information about the project
becomes available. Such reserve time should be documented along with other data
and assumptions.
6.3.3 Outputs from Activity Duration Estimating
.1 Activity duration estimates. Activity duration estimates are quantitative assessments of the likely
number of work periods that will be required to complete an activity. Activity
duration estimates should always include some indication of the range of
possible results. For example:
_ 2 weeks ± 2 days to indicate that
the activity will take at least eight days and no more than twelve (assuming a
five-day workweek).
_ 15 percent probability of exceeding
three weeks to indicate a high probability— 85 percent—that the activity will
take three weeks or less. Chapter 11 on Project Risk Management includes a more
detailed discussion of estimating uncertainty.
.2 Basis of estimates. Assumptions made in developing the estimates must be documented.
.3 Activity list updates. Activity list updates are described in Section 6.2.3.2.
6.4 SCHEDULE DEVELOPMENT
Schedule development means determining start and finish
dates for project activities. If the start and finish dates are not realistic,
then the project is unlikely to be finished as scheduled. The schedule
development process must often be iterated (along with the processes that
provide inputs, especially duration estimating and cost estimating) prior to
determination of the project schedule.
6.4.1 Inputs to Schedule Development
.1 Project network diagrams. Project network diagrams are described in Section 6.2.3.1.
.2 Activity duration estimates. Activity duration estimates are described in Section 6.3.3.1.
.3 Resource requirements. Resource requirements are described in Section 6.3.1.4.
.4 Resource pool description. Knowledge of what resources will be available at what times and in what
patterns is necessary for schedule development. For example, shared or critical
resources can be especially difficult to schedule since their availability may
be highly variable. The amount of detail and the level of specificity in the
resource pool description will vary. For example, one need only know that two
consultants will be available in a particular time frame for preliminary
schedule development of a consulting project. The final schedule for the same
project, however, identifies which specific consultants will be available.
.5 Calendars. Project and
resource calendars identify periods when work is allowed. Project calendars affect all resources (e.g., some
projects will work only during normal business hours, while others will work a
full three shifts). A five-day workweek is an example of calendar usage. Resource calendars affect a specific resource or
category of resources (e.g., a project team member may be on vacation or in a
training program; a labor contract may limit certain workers to certain days of
the week).
.6 Constraints. Constraints are
factors that will limit the project management team’s options. There are two
major categories of time constraints considered during schedule development:
_ Imposed dates—imposed dates on
activity starts or finishes can be used to restrict the start or finish to
occur either no earlier than a specified date or no later than a specified
date. While all four date constraints are typically available in project
management software, the “Start No Earlier Than” and the “Finish No Later Than”
constraints are the most commonly used. Typical uses of date constraints
include such situations as a market window on a technology project, weather
restrictions on outdoor activities, government-mandated compliance with environmental
remediation, delivery of material from parties not represented in the project
schedule, etc.
_ Key events or major
milestones—completion of certain deliverables by a specified date may be requested by the project sponsor, the project customer, or other
stakeholders. Once scheduled, these dates become expected and often may be
moved only with great difficulty. Milestones may also be used to indicate
interfaces with work outside of the project. Such work is typically not in the
project database, and milestones with constraint dates can provide the
appropriate schedule interface.
.7 Assumptions. See Section
4.1.1.5.
.8 Leads and lags. Any of the
dependencies may require specification of a lead or a lag to accurately define
the relationship. An example of a lag: there might be a desire to schedule a
two-week delay (lag) between ordering a piece of equipment and installing or
using it. An example of a lead, in a finish-to-start dependency with a ten-day
lead: the successor activity starts ten days before the predecessor has
completed.
.9 Risk management plan. The risk management plan is discussed in 11.1.3.
.10 Activity attributes. Attributes of the activities—including responsibility (i.e., who will
perform the work), geographic area or building (where the work has to be
performed), and activity type (i.e., summary or detailed)—are very important
for further selection and sorting of the planned activities in a convenient way
for the users. WBS classification is also an important attribute that allows
useful activity ordering and sorting.
6.4.2 Tools and Techniques for Schedule Development
.1 Mathematical analysis. Mathematical analysis involves calculating theoretical early and late start
and finish dates for all project activities without regard for any resource
pool limitations. The resulting dates are not the schedule, but rather indicate
the time periods within which the activity could be scheduled given resource limits and other known constraints. The most
widely known mathematical analysis techniques are:
_ Critical Path Method
(CPM)—calculates a single, deterministic early and late start and finish date
for each activity based on specified, sequential network logic and a single
duration estimate. The focus of CPM is calculating float to determine which activities have the least
scheduling flexibility. The underlying CPM algorithms are often used in other
types of mathematical analysis.
_ Graphical Evaluation and Review
Technique (GERT)—allows for probabilistic treatment of both network logic and
activity duration estimates (i.e., some activities may not be performed at all,
some may be performed only in part, and others may be performed more than
once).
_ Program Evaluation and Review
Technique (PERT)—uses a weighted average duration estimate to calculate
activity durations. Although there are surface differences, PERT differs from
CPM primarily in that it uses the distribution’s mean (expected value) instead
of the most likely estimate originally used in CPM (see Figure 6-4). PERT itself is seldom used today.
.2 Duration compression. Duration compression is a special case of mathematical analysis that looks
for ways to shorten the project schedule without changing the project scope
(e.g., to meet imposed dates or other schedule objectives). Duration compression
includes techniques such as:
_ Crashing—in which cost and schedule
tradeoffs are analyzed to determine how, if at all, to obtain the greatest
amount of compression for the least incremental cost. Crashing does not always
produce a viable alternative and often results in increased cost.
_ Fast tracking—doing activities in
parallel that would normally be done in sequence (e.g., starting to write code
on a software project before the design is complete, or starting to build the
foundation for a petroleum processing plant before the 25 percent engineering
point is reached). Fast tracking often results in rework and usually increases
risk.
.3 Simulation. Simulation
involves calculating multiple project durations with different sets of activity
assumptions. The most common technique is Monte Carlo Analysis, in which a
distribution of probable results is defined for each activity and used to
calculate a distribution of probable results for the total project (see also
Section 11.4.2.4). In addition, what-if analyses can be made using the logic network to simulate different
scenarios, such as delaying a major component delivery, extending specific
engineering durations, or introducing external factors (such as a strike, or a
change in the permitting process). The outcome of the what-if simulations can
be used to assess the feasibility of the schedule under adverse conditions, and
in preparing contingency/response plans to overcome or mitigate the impact of
unexpected situations.
.4 Resource leveling heuristics. Mathematical analysis often produces a preliminary early-start schedule that requires more resources during certain
time periods than are available, or requires changes in resource levels that
are not manageable. Heuristics, such as, “Allocate scarce resources to critical
path activities first,” can be applied to develop a schedule that reflects such
constraints. Resource leveling often results in a project duration that is
longer than the preliminary schedule. This technique is sometimes called the resource-based method, especially when implemented with
computerized optimization. Resource reallocation from noncritical to critical
activities is a common way to bring the schedule back, or as close as possible,
to its originally intended overall duration. Utilization of extended hours,
weekends, or multiple shifts should also be considered to reduce the durations
of critical activities. Productivity increases based on the use of different
technologies and/or machinery (i.e., automatic welding, electrical pipe
cutters, etc.) are another way to shorten durations that have extended the
preliminary schedule. Fact tracking, if feasible (as described in Section
6.4.2.2), is another way to reduce the overall project duration. Some projects
may have a finite and critical project resource, requiring that this resource
be scheduled in reverse from the project ending date; this is known as reverse resource allocation scheduling. Critical chain is a technique that modifies the
project schedule to account for limited resources.
.5 Project management software. Project management software is widely used to assist with schedule
development. Other software may be capable of interacting directly or
indirectly within themselves, or with other software, to carry out the
requirements of other knowledge areas. These products automate the calculation
of the mathematical analysis and resource leveling,
and thus allow for rapid consideration of many schedule alternatives. They are
also widely used to print or display the outputs of schedule development.
.6 Coding structure. The activities should have a coding structure that will allow sorting
and/or extractions based on different attributes assigned to the activities,
such as responsibility, geographic area or building, project phase, schedule
level, activity type, and WBS classification.
6.4.3 Outputs from Schedule Development
.1 Project schedule. The project schedule includes at least planned start and expected finish
dates for each activity. (Note: The project schedule remains preliminary until
resource assignments have been confirmed. This would usually happen no later
than the completion of Project Plan Development, Section 4.1.)
The project schedule may be presented in summary form
(the master schedule), or in
detail. Although it can be presented in tabular form, it is more often
presented graphically, using one or more of the following formats:
_ Project network diagrams with date
information added (see Figure 6-5). These charts usually show both the project logic and the project’s
critical path activities (see Section 6.2.3.1 for more information on project
network diagrams).
_ Bar charts, also called Gantt charts (see Figure 6-6), show activity start and end dates, as well as expected durations, and
sometimes show dependencies. They are relatively easy to read, and are
frequently used in management presentations.
_ Milestone charts (see Figure 6-7) are similar to bar charts, but only identify the
scheduled start or completion of major deliverables and key external
interfaces.
.2 Supporting detail. Supporting detail for the project schedule includes at least documentation
of all identified assumptions and constraints. The amount of additional detail
varies by application area. For example:
_ On a construction project, it will
most likely include such items as resource histograms, cash-flow projections,
and order and delivery schedules.
_ On an electronics project, it will
most likely include resource histograms only. Information frequently supplied
as supporting detail includes, but is not limited to:
_ Resource requirements by time period,
often in the form of a resource histogram.
_ Alternative schedules (e.g., best
case or worst case, resource leveled or not, with or without imposed dates).
_ Schedule contingency reserves (see
Section 11.4).
.3 Schedule management plan. A schedule management plan defines how changes to the schedule will be
managed. It may be formal or informal, highly detailed or broadly framed, based
on the needs of the project. It is a subsidiary element of the overall project
plan (see Section 4.1).
.4 Resource requirement updates. Resource leveling updates may have a significant effect on preliminary
estimates of resource requirements.
6.5 SCHEDULE CONTROL
Schedule control is concerned with a) influencing the
factors that create schedule changes to ensure that changes are agreed upon, b)
determining that the schedule has changed, and c) managing the actual changes
when and as they occur. Schedule control must be thoroughly integrated with the
other control processes, as described in Section 4.3, Integrated Change
Control.
6.5.1 Inputs to Schedule Control
.1 Project schedule. The project schedule is described in Section 6.4.3.1. The approved project
schedule, called the schedule baseline (which must be
feasible technically and in terms of resources), is a component of the project
plan described in Section 4.1.3.1. It provides the basis for measuring and
reporting schedule performance.
.2 Performance reports. Performance reports, discussed in Section 10.3.3.1, provide information on
schedule performance, such as which planned dates have been met and which have
not. Performance reports may also alert the project team to issues that may
cause problems in the future.
.3 Change requests. Change requests
may occur in many forms—oral or written, direct or indirect, externally or
internally initiated, and legally mandated or optional. Changes may require
extending the schedule or may allow accelerating it (see Section 4.3.1.3).
.4 Schedule management plan. The schedule management plan is described in Section 6.4.3.3.
6.5.2 Tools and Techniques for Schedule Control
.1 Schedule change control system. A schedule change control system defines the procedures by which the
project schedule may be changed. It includes the paperwork, tracking systems,
and approval levels necessary for authorizing changes. Schedule change control
should be integrated with the integrated change control system described in
Section 4.3.
.2 Performance measurement. Performance measurement techniques such as those described in Section
10.3.2 help to assess the magnitude of any variations that do occur. An
important part of schedule control is to decide if the schedule variation
requires corrective action. For example, a major delay on a noncritical
activity may have little effect on the overall project, while a much shorter
delay on a critical or near-critical activity may require immediate action.
.3 Additional planning. Few projects run exactly according to plan. Prospective changes may require
new or revised activity duration estimates, modified activity sequences, or
analysis of alternative schedules.
.4 Project management software. Project management software is described in Section 6.4.2.5. The ability of
project management software to track planned dates versus actual dates and to
forecast the effects of schedule changes, real or potential, makes it a useful
tool for schedule control.
.5 Variance analysis. Performance of the variance analysis during the schedule-monitoring process
is a key element for time control. Comparing target dates with the
actual/forecast start and finish dates provides useful information for the
detection of deviations and for the implementation of corrective solutions in
case of delays. The float variance is also an essential planning component to
evaluate project time-performance. Particular attention has to be given to
critical and subcritical activities (i.e., analyzing the ten subcritical paths,
in order of ascending float).
6.5.3 Outputs from Schedule Control
.1 Schedule updates. A schedule update is any modification to the schedule information that is
used to manage the project. Appropriate stakeholders must be notified as
needed. Schedule updates may or may not require adjustments to other aspects of
the project plan.
Revisions are a special
category of schedule updates. Revisions are changes to the schedule start and
finish dates in the approved project schedule. These changes are generally
incorporated in response to scope changes or changes to estimates. In some
cases, schedule delays may be so severe that rebaselining is needed to provide realistic data to measure performance. However, care
must be taken before rebaselining, as historical data will be lost for the
project schedule. Rebaselining should only be used as a last resort in
controlling the schedule; new target schedules should be the normal mode of
schedule revision.
.2 Corrective action. Corrective action is anything done to bring expected future schedule
performance in line with the project plan. Corrective action in the area of
time management often involves expediting: special actions taken to ensure
completion of an activity on time or with the least possible delay. Corrective
action frequently requires root-cause analysis to identify the cause of the
variation, and schedule recovery can be planned and executed for activities
delineated later in the schedule and need not only address the activity causing
the deviation.
.3 Lessons learned. The causes of
variances, the reasoning behind the corrective action chosen, and other types
of lessons learned from schedule control should be documented, so that they
become part of the historical database for both this project and other projects
of the performing organization.
