BAB 6 Buku "A Guide to the Project Management Body of Knowledge"
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.
0 Response to "BAB 6 Buku "A Guide to the Project Management Body of Knowledge""
Posting Komentar