This is the accessible text file for GAO report number GAO-12-120G 
entitled 'GAO Schedule Assessment Guide: Best Practices for project 
schedules' which was released on May 30, 2012. 

This text file was formatted by the U.S. Government Accountability 
Office (GAO) to be accessible to users with visual impairments, as part 
of a longer term project to improve GAO products' accessibility. Every 
attempt has been made to maintain the structural and data integrity of 
the original printed product. Accessibility features, such as text 
descriptions of tables, consecutively numbered footnotes placed at the 
end of the file, and the text of agency comment letters, are provided 
but may not exactly duplicate the presentation or format of the printed 
version. The portable document format (PDF) file is an exact electronic 
replica of the printed version. We welcome your feedback. Please E-mail 
your comments regarding the contents or accessibility features of this 
document to Webmaster@gao.gov. 

This is a work of the U.S. government and is not subject to copyright 
protection in the United States. It may be reproduced and distributed 
in its entirety without further permission from GAO. Because this work 
may contain copyrighted images or other material, permission from the 
copyright holder may be necessary if you wish to reproduce this 
material separately. 

United States Government Accountability Office:
GAO: 
Applied Research and Methods: 

May 2012: 

GAO Schedule Assessment Guide: 
Best Practices for project schedules: 

“From May 30, 2012 - April 30, 2013, GAO is seeking input and feedback 
on this Exposure Draft from all interested parties. See page 2 for 
more information.” 

GAO-12-120G: 

Contents: 

Preface: 

Introduction and Concepts:
Ten Best Practices:
The Integrated Master Schedule:
The Critical Path Method:
Planning, Scheduling, and the Scheduler: 

Best Practice 1: Capturing All Activities:
Capturing All Effort:
Constructing an IMS:
Work Breakdown Structure:
Activity Names:
Activity Codes:
Best Practices Checklist: Capturing All Activities: 

Best Practice 2: Sequencing All Activities:
Predecessor and Successor Logic:
Incomplete and Dangling Logic:
Summary Logic:
Date Constraints:
Using Date Constraints:
Lags and Leads:
Using Lags:
Using Leads:
Path Convergence:
Best Practices Checklist: Sequencing All Activities: 

Best Practice 3: 
Assigning Resources to All Activities:
Resources, Effort, and Duration:
Rolling Wave Planning:
Loading Activities with Resources:
Resource Leveling:
Best Practices Checklist: Assigning Resources to All Activities: 

Best Practice 4: 
Establishing the Duration of All Activities:
Durations:
Estimating Durations:
Calendars:
Best Practices Checklist: Establishing the Duration of All Activities: 

Best Practice 5: 
Verifying That the Schedule Can Be Traced Horizontally and Vertically:
Horizontal Traceability:
Vertical Traceability:
Best Practices Checklist: Verifying That the Schedule Can Be Traced 
Horizontally and Vertically: 

Best Practice 6: 
Confirming That the Critical Path Is Valid:
The Critical Path:
The Critical Path and the Longest Path:
Common Barriers to a Valid Critical Path:
Resource Leveling:
Critical Path Management:
Best Practices Checklist: Confirming That the Critical Path Is Valid: 

Best Practice 7: 
Ensuring Reasonable Total Float:
Definitions of Total Float and Free Float:
Calculating Float:
Common Barriers to Valid Float:
Reasonableness of Float:
Float Management:
Best Practices Checklist: Ensuring Reasonable Total Float: 

Best Practice 8: 
Conducting a Schedule Risk Analysis:
The Definition of Schedule Risk Analysis:
The Purpose of a Schedule Risk Analysis:
Schedule Risk Analysis with Three-Point Duration Estimates:
Schedule Risk Analysis with Risk Drivers:
Schedule Contingency:
Prioritizing Risks:
Probabilistic Branching:
Correlation:
Updating and Documenting a Schedule Risk Analysis:
Best Practices Checklist: Conducting a Schedule Risk Analysis: 

Best Practice 9: 
Updating the Schedule Using Actual Progress and Logic:
Statusing Progress:
Progress Records:
Adding Activities:
Out-of-Sequence Logic:
Verifying Status Updates and Schedule Integrity:
Schedule Narrative:
Reporting and Communication:
Best Practices Checklist: Updating the Schedule Using Actual Progress 
and Logic: 

Best Practice 10: 
Maintaining a Baseline Schedule:
Baseline and Current Schedules:
Baseline Document:
The Change Process:
Baseline Analysis:
Trend Analysis:
Strategies for Recovery and Acceleration:
Best Practices Checklist: Maintaining a Baseline Schedule: 

Four Characteristics of a Reliable Schedule: 

Appendix I: An Auditor's Key Questions and Documents: 

Appendix II: The Forward and Backward Pass: 

Appendix III: Standard Quantitative Measurements for Assessing Schedule 
Health: 

Appendix IV: Recommended Elements of a Data Collection Instrument: 

Appendix V: Case Study Backgrounds: 

Appendix VI: Experts Who Helped Develop This Guide: 

Appendix VII: GAO Contacts and Staff Acknowledgments: 

References: 

Tables: 

Table 1. Strategies for Schedule Recovery and Acceleration: 

Table 2. The Four Characteristics of a Reliable Schedule: 

Table 3. Expected Durations and Estimated Resources: 

Table 4. Standard Data Measures for Schedule Best Practices: 

Table 5: Case Studies Drawn from GAO Reports Illustrating this Guide: 

Figures: 

Figure 1: A Milestone's Dates: 

Figure 2: Detail Activities: 

Figure 3: Summary Activities: 

Figure 4: The WBS and Scheduling: 

Figure 5: Redundant Activity Names: 

Figure 6: Unique Activity Names: 

Figure 7: Finish-to-Start Relationship: 

Figure 8: A Start-to-Start Relationship: 

Figure 9: A Finish-to-Finish Relationship: 

Figure 10: Early and Late Dates: 

Figure 11: Start-Date Dangling Logic: 

Figure 12: Finish-Date Dangling Logic: 

Figure 13: A Linked Summary Activity: 

Figure 14: A Lag: 

Figure 15: A Negative Lag (or Lead): 

Figure 16: Using a Lag to Force an Activity's Start Date: 

Figure 17: The Effect of a Lag on Successor Activities: 

Figure 18: Eliminating Leads with Finish-to-Start Links: 

Figure 19: Logic Failure Associated with a Lead: 

Figure 20: Enumerating Lags: 

Figure 21: A Profile of Expected Construction Labor Costs by Month: 

Figure 22: A Smoothed Profile of Expected Construction Labor Costs by 
Month: 

Figure 23: Resource Overallocated in a Correctly Sequenced Network: 

Figure 24: Resource Leveling in a Correctly Sequenced Network: 

Figure 25: The Critical Path and Total Float: 

Figure 26: The Critical Path and the Longest Path: 

Figure 27: Critical Path Activities Not on the Longest Path: 

Figure 28: The Longest Path and the Lowest-Float Path: 

Figure 29: The Critical Path and Lags: 

Figure 30: The Critical Path and Level of Effort Activities: 

Figure 31: Total Float and Free Float: 

Figure 32: Network Diagram of a Simple Schedule: 

Figure 33: A Project Schedule: 

Figure 34: Estimated Durations for Remaining WBS Areas in the Schedule: 

Figure 35: The Cumulative Distribution of Project Schedule, Including 
Risk: 

Figure 36: Identified Risks on a Spacecraft Schedule: 

Figure 37: A Risk Register for a Spacecraft Schedule: 

Figure 38: Spacecraft Schedule Results from a Monte Carlo Simulation: 

Figure 39: A Schedule Showing a Critical Path: 

Figure 40: The Results of a Monte Carlo Simulation for a Schedule 
Showing a Critical Path: 

Figure 41: A Sensitivity Index for Spacecraft Schedule: 

Figure 42: Probabilistic Branching in a Schedule: 

Figure 43: Probability Distribution Results for Probabilistic 
Branching: 

Figure 44: The Original Plan for Interior Finishing: 

Figure 45: Retained Logic: 

Figure 46: Progress Override: 

Figure 47: Baseline, Actual, and Forecasted Dates: 

Figure 48: Baselined Activities: 

Figure 49: Updated Status Compared with Baseline: 

Figure 50: Updated Status and Proposed Plan Compared with Baseline: 

Figure 51: Start-Up and Testing Network: 

Figure 52: Early Start and Early Finish Calculations: 

Figure 53: Successive Early Start and Early Finish Calculations: 

Figure 54: Complete Early Start and Early Finish Calculations: 

Figure 55: Late Start and Late Finish Calculations: 

Figure 56: Early and Late Dates of the Start-Up and Testing Network: 

Figure 57: Total Float in the Start-Up and Testing Network: 

Abbreviations: 

BEI: baseline execution index: 

BOE: basis of estimate: 

CFM: Office of Construction and Facilities Management: 

CLIN: contract line item number: 

CPM: critical path method: 

DEAMS: Defense Enterprise Accounting and Management System: 

DHS: U.S. Department of Homeland Security: 

DOE: U.S. Department of Energy: 

DRRS: Defense Readiness Reporting System: 

ERP: enterprise resource planning: 

EVM: earned value management: 

FAA: Federal Aviation Administration: 

FNET: finish no earlier than: 

FNLT: finish no later than: 

FTE: full-time equivalent: 

GCSS-Army: Army Global Combat Support System: 

GFEBS: General Fund Enterprise Business System: 

G/R: giver/receiver: 

IMS: integrated master schedule: 

IPT: Integrated Product Team: 

LCCE: life-cycle cost estimate: 

LOE: level of effort: 

MFO: must finish on: 

MSO: must start on: 

PMB: performance measurement baseline: 

PMO: Program Management Office: 

SNET: start no earlier than: 

SNLT: start no later than: 

SOO: statement of objectives: 

SOW: statement of work: 

TSA: Transportation Security Administration: 

TPO: Transformation Program Office: 

USCIS: U.S. Citizenship and Immigration Services: 

WBS: work breakdown structure: 

[End of section] 

Preface: 

The U.S. Government Accountability Office is responsible for, among
other things, assisting the Congress in its oversight of the federal
government, including agencies’ stewardship of public funds. To use
public funds effectively, the government must meet the demands of
today’s changing world by employing effective management practices and
processes, including the measurement of government program
performance. In addition, legislators, government officials, and the 
public want to know whether government programs are achieving their 
goals and what their costs are. 

Toward these objectives, In March 2009, we published the GAO Cost
Estimating and Assessment Guide as a consistent methodology based on
best practices that can be used across the federal government to
develop, manage, and evaluate capital program cost estimates. The
methodology outlined in the Cost Estimating and Assessment Guide is a
compilation of best practices that federal cost estimating organizations
and industry use to develop and maintain reliable cost estimates
throughout the life of an acquisition program. 

This schedule guide is a companion to the Cost Guide. A consistent
methodology for developing, managing, and evaluating capital program
cost estimates includes the concept of scheduling the necessary work to
a timeline, as discussed in the Cost Guide. Simply put, schedule
variances are usually followed by cost variances. Because some program
costs such as labor, supervision, rented equipment, and facilities cost
more if the program takes longer, a reliable schedule can contribute 
to an understanding of the cost impact if the program does not finish 
on time. In addition, management tends to respond to schedule delays 
by adding more resources or authorizing overtime. Further, a schedule 
risk analysis allows for program management to account for the cost 
effects of schedule slippage when developing the life-cycle cost 
estimate. A cost estimate cannot be considered credible if it does not 
account for the cost effects of schedule slippage. 

Thus, a well-planned schedule is a fundamental management tool that
can help government programs use public funds effectively by specifying
when work will be performed in the future and measuring program
performance against an approved plan. Moreover, as a model of time, an
integrated and reliable schedule can show when major events are
expected as well as the completion dates for all activities leading up 
to them, which can help determine if the program’s parameters are 
realistic and achievable. A program’s success depends in part on the 
quality of its schedule. A well-formulated schedule can help analyze 
how change affects the program. A schedule that contains many 
concurrent activities, unrealistic activity durations or logic, or a 
significant number of constrained start or finish dates is a common 
indicator of poor program performance. Accordingly, a schedule will 
serve as a warning that a program may need an overtarget budget or 
schedule. 

Developing the scheduling concepts introduced in the Cost Estimating
and Assessment Guide, the GAO Schedule Assessment Guide presents
them as ten best practices associated with developing and maintaining a
reliable, high-quality schedule. A companion to the Cost Guide, the GAO
Schedule Assessment Guide serves also to present guiding principles for
our auditors in evaluating the economy, efficiency, and effectiveness of
government programs. 

We intend to update the Schedule Assessment Guide to keep it current. 
Comments and suggestions from experienced users, as well as 
recommendations from experts in the scheduling, cost estimating, and 
program acquisition disciplines, are always welcome. Please click on 
this link [hyperlink, https://tell.gao.gov/costguidecomment} to 
provide us with comments on the Guide. 

If you have any questions concerning this Guide, you may contact me at 
(202) 512-6412 or personst@gao.gov. Contact points for our Offices of 
Congressional Relations and Public Affairs may be found on the last 
page of this Guide. Major contributors to this project are listed on 
page 201. 

Signed by: 

Timothy M. Persons, Ph.D. 
Director, Center for Science, Technology, and Engineering Applied 
Research and Methods: 

[End of section] 

Introduction and Concepts: 

The success of a program depends in part on having an integrated and 
reliable master schedule that defines when and how long work will occur 
and how each activity is related to the others. A schedule is necessary 
for government acquisition programs for many reasons. The program 
schedule provides not only a road map for systematic project execution 
but also the means by which to gauge progress, identify and resolve 
potential problems, and promote accountability at all levels of the 
program. A schedule provides a time sequence for the duration of a 
program's activities and helps everyone understand both the dates for 
major milestones and the activities that drive the schedule. A program 
schedule is also a vehicle for developing a time-phased budget 
baseline. Moreover, it is an essential basis for managing tradeoffs 
between cost, schedule, and scope. Among other things, scheduling 
allows program management to decide between possible sequences of 
activities, determine the flexibility of the schedule according to 
available resources, predict the consequences of managerial action or 
inaction on events, and allocate contingency plans to mitigate risk. 
Following changes in a program, the schedule is used to forecast the 
effects of delayed, deleted, and added effort, as well as possible 
avenues for time and cost recovery. In this respect, schedules can be 
used to verify and validate proposed adjustments to the planned time to 
complete. 

The GAO Schedule Assessment Guide is intended to expand on the 
scheduling concepts introduced in the Cost Estimating and Assessment 
Guide by providing ten best practices to help managers and auditors 
ensure that the program schedule is reliable. The reliability of the 
schedule determines the credibility of the program's forecasted dates 
for decision making. 

Ten Best Practices: 

The ten best practices associated with a high-quality and reliable 
schedule and their concepts are as follows: 

Capturing all activities. The schedule should reflect all activities as 
defined in the project's work breakdown structure (WBS), which defines 
in detail the work necessary to accomplish a project's objectives, 
including activities both the owner and contractors are to perform. 

Sequencing all activities. The schedule should be planned so that 
critical project dates can be met. To do this, activities need to be 
logically sequenced--that is, listed in the order in which they are to 
be carried out. In particular, activities that must be completed before 
other activities can begin (predecessor activities), as well as 
activities that cannot begin until other activities are completed 
(successor activities), should be identified. Date constraints and lags 
should be minimized and justified. This helps ensure that the 
interdependence of activities that collectively lead to the completion 
of events or milestones can be established and used to guide work and 
measure progress. 

Assigning resources to all activities. The schedule should reflect the 
resources (labor, materials, overhead) needed to do the work, whether 
they will be available when needed, and any funding or time 
constraints. 

Establishing the duration of all activities. The schedule should 
realistically reflect how long each activity will take. When the 
duration of each activity is determined, the same rationale, historical 
data, and assumptions used for cost estimating should be used. 
Durations should be reasonably short and meaningful and allow for 
discrete progress measurement. Schedules that contain planning and 
summary planning packages as activities will normally reflect longer 
durations until broken into work packages or specific activities. 

Verifying that the schedule can be traced horizontally and vertically. 
The detailed schedule should be horizontally traceable, meaning that it 
should link products and outcomes associated with other sequenced 
activities. These links are commonly referred to as "hand-offs" and 
serve to verify that activities are arranged in the right order for 
achieving aggregated products or outcomes. The integrated master 
schedule (IMS) should also be vertically traceable--that is, varying 
levels of activities and supporting subactivities can be traced. Such 
mapping or alignment of levels enables different groups to work to the 
same master schedule. 

Confirming that the critical path is valid. The schedule should 
identify the program critical path--the path of longest duration 
through the sequence of activities. Establishing a valid critical path 
is necessary for examining the effects of any activity's slipping along 
this path. The program critical path determines the program's earliest 
completion date and focuses the team's energy and management's 
attention on the activities that will lead to the project's success. 

Ensuring reasonable total float. The schedule should identify 
reasonable float (or slack)--the amount of time by which a predecessor 
activity can slip before the delay affects the program's estimated 
finish date--so that the schedule's flexibility can be determined. 
Large total float on an activity or path indicates that the activity or 
path can be delayed without jeopardizing the finish date. The length of 
delay that can be accommodated without the finish date's slipping 
depends on a variety of factors, including the number of date 
constraints within the schedule and the amount of uncertainty in the 
duration estimates, but the activity's total float provides a 
reasonable estimate of this value. As a general rule, activities along 
the critical path have the least float. 

Conducting a schedule risk analysis. A schedule risk analysis uses a 
good critical path method (CPM) schedule and data about project 
schedule risks and opportunities as well as statistical simulation to 
predict the level of confidence in meeting a program's completion date, 
determine the time contingency needed for a level of confidence, and 
identify high-priority risks and opportunities. As a result, the 
baseline schedule should include a buffer or reserve of extra time. 

Updating the schedule using actual progress and logic. Progress updates 
and logic provide a realistic forecast of start and completion dates 
for program activities. Maintaining the integrity of the schedule logic 
at regular intervals is necessary to reflect the true status of the 
program. To ensure that the schedule is properly updated, people 
responsible for the updating should be trained in critical path method 
scheduling. 

Maintaining a baseline schedule. A baseline schedule is the basis for 
managing the project scope, the time period for accomplishing it, and 
the required resources. The baseline schedule is designated the target 
schedule, subject to a configuration management control process, 
against which project performance can be measured, monitored, and 
reported. The schedule should be continually monitored so as to reveal 
when forecasted completion dates differ from planned dates and whether 
schedule variances will affect downstream work. A corresponding 
baseline document explains the overall approach to the project, defines 
custom fields in the schedule file, details ground rules and 
assumptions used in developing the schedule, and justifies constraints, 
lags, long activity durations, and any other unique features of the 
schedule. 

The ten best practices represent the key concepts of a reliable 
schedule in no particular order; they are not a series of steps for 
developing the schedule. 

The federal audit community is the primary audience for this guide. 
Agencies that do not have a formal policy for creating or maintaining 
integrated master schedules will also benefit from the guide because it 
will inform them of GAO's criteria for assessing a schedule's 
credibility. Besides GAO, auditing agencies include Inspectors General 
and audit services such as the Naval Audit Service and the Army Audit 
Agency. Following the text discussion of the best practices, an 
appendix lists key questions and documentation that members of the 
federal audit community who assess program schedules will find useful. 
The remainder of this section introduces the concepts and activities 
entailed in the integrated master schedule; the critical path method; 
and planning, scheduling, and the scheduler. 

The Integrated Master Schedule: 

As a document that integrates the planned work, the resources necessary 
to accomplish that work, and the associated budget, the IMS should be 
the focal point of program management. In this guide, an IMS 
constitutes a program schedule that includes the entire required scope 
of effort, including the effort necessary from all government, 
contractor, and other key parties for a program's successful execution 
from start to finish.[Footnote 1] 

An IMS connects all the scheduled work of the government and the 
contractor in a network, or collection of logically linked sequences of 
activities. The sequences clearly show how related portions of work 
depend on one another, including the relationships between the 
government and contractors. Although the IMS includes all government, 
contractor, and external effort, the government program management 
office is ultimately responsible for its development and maintenance. 
In this respect, the government program management office must ensure 
that the schedule is as logical and realistic as possible. The IMS must 
be a complete and dynamic network. That is, the IMS should consist of 
logically related activities whose forecasted dates are automatically 
recalculated when activities change. If the schedule is not dynamic, 
planned activities will not react logically to changes, and the 
schedule will not be able to identify the consequences of changes or 
possible managerial action to respond to them. 

In general, schedules can refer to programs and projects. In this 
guide, a "program" encompasses an entire acquisition program from 
beginning to end, including all government and contractor effort. An 
IMS may be made up of several or several hundred individual schedules 
that represent portions of effort within a program. These individual 
schedules are "projects" within the larger program. For example, a 
program IMS may consist of individual project schedules for the prime 
contractor, the government program management office, and a government 
testing laboratory. 

As discussed in Best Practice 1, the IMS includes summary, 
intermediate, and all detailed schedules. At the highest level, the 
summary schedule provides a strategic view of the activities and 
milestones necessary to start and complete a project. The intermediate 
schedule includes all information displayed in the summary schedule, as 
well as key program activities and milestones that show the important 
steps in achieving high-level milestones. At the lowest level, the 
detailed schedule lays out the logically sequenced day-to-day effort to 
reach program milestones. Ideally, one schedule serves as the summary, 
intermediate, and detailed schedule by simply rolling up lower levels 
of effort into summary activities or higher-level work breakdown 
structure (WBS) elements. 

The program or project team should develop the schedules and, in doing 
so, include the program manager, schedulers, and subject matter experts 
or managers responsible for specific areas of work. Managers 
responsible for resources should approve the areas of a schedule they 
are committed to support. If the schedule is not planned in sufficient 
detail or collaboratively by team members and stakeholders, then 
opportunities for process improvement (for example, identifying 
redundant activities), what-if analysis, and risk mitigation will be 
missed. Moreover, activity owners responsible for managing the day-to-
day effort and the most experienced team members who perform the work 
are the best source of resource estimates. Activity owners must be able 
to explain the logic behind their resource estimates; if resources are 
without justification, the schedule will falsely convey accuracy. 

The Critical Path Method: 

The critical path method is used to derive the critical activities--
that is, activities that cannot be delayed without delaying the end 
date of the program. The amount of time an activity can slip before the 
program's end date is affected is known as "total float." 

Critical activities have the least amount of float and, therefore, any 
delay in them generally causes the same amount of delay in the 
program's end date. Activities with little total float are called 
"near-critical" activities, because they can quickly become critical if 
their small amount of total float is used up in a delay. Management 
must closely monitor critical and near-critical activities by using 
sound schedule practices. 

Unless the IMS represents the entire scope of effort and the effort is 
correctly sequenced through network logic, the scheduling software will 
report an incorrect or invalid critical path. That is, the critical 
path will not represent the activities affecting the program finish 
date. With no accurate critical path, management cannot focus on the 
activities that will be detrimental to the project's key milestones and 
finish date if they slip. 

Planning, Scheduling, and the Scheduler: 

Project planning is a process within program management. An integral 
stage of management, it results primarily in an overall program 
execution strategy. The overall strategy is documented in the project 
plan, which defines, among other things: 

* project scope; 

* project objectives and requirements; 

* stakeholders; 

* organizational and work breakdown structures; 

* design, procurement, and implementation; and: 

* risk and opportunity management plans. 

Project planning is the basis for controlling and managing project 
performance, including managing the relationship between cost and time. 

Scheduling is a distinct process that follows the planning process. 
The schedule is essentially a model of the project plan. It calculates 
the dates on which activities are to be carried out according to the 
project plan. As a model of time, the schedule incorporates key 
variables such as nonworking calendar periods, contingency, resource 
constraints, and preferred sequences of work activities to determine 
the duration and the start and finish dates of activities and key 
deliverables. 

Planning and scheduling are continual processes throughout the life 
of a project. Planning may be done in stages throughout the project as 
stakeholders learn more details. This approach to planning, known as 
rolling wave planning, is discussed in Best Practice 3. Scheduling 
involves the management and control of the schedule over the project's 
life cycle. However, in no case should planning be concurrent with 
scheduling. In other words, work and strategies for executing the work 
must be planned first before activities can be scheduled. 

By creating and maintaining the schedule, a scheduler interprets and 
documents the project plan developed by those responsible for managing 
and for executing the work. The scheduler is responsible for creating, 
editing, reviewing, and updating the schedule and ensuring that project 
and control account managers follow a formal schedule maintenance 
process. Interpreting the project's sequence of work entails 
responsibility for alerting program management to threats to the 
critical path, the degradation of float, and the derivation and use of 
schedule contingency (these concepts are discussed in Best Practices 6, 
7, and 8). The scheduler must also modify the schedule in accordance 
with approved change requests, including rolling wave planning details, 
changes in scope, and changes in resource constraints. Maintaining a 
reliable schedule allows the scheduler to identify the effects of 
delayed activities or unplanned events on the planned sequence of 
activities, as well as possible mitigation strategies to prevent 
significant delays in planned work. The scheduler must track and report 
actual work performance against the plan, including the production of 
variances, forecasts, and what-if analyses. 

The remainder of this text consists of detailed definitions and 
descriptions of the ten best practices. 

[End of section] 

Best Practice 1: Capturing All Activities: 

[Side bar: Best Practice 1: The schedule should reflect all activities 
as defined in the project's work breakdown structure (WBS), which 
defines in detail the work necessary to accomplish a project's 
objectives, including activities both the owner and contractors are to 
perform. End of side bar] 

A schedule represents an agreement for executing a program. It should 
reflect all activities (steps, events, required work, and outcomes) to 
accomplish the deliverables described in the program's WBS. An IMS 
should be based on critical path method scheduling that contains all 
the work represented in logically linked activities representing the 
execution plan. At its summary level, the IMS gives a strategic view of 
summary activities and milestones necessary to start and complete a 
project. At its most detailed, the schedule clearly reflects the WBS 
and defines the activities necessary to produce and deliver each 
product. The amount of detail should be sufficient to identify the 
longest path of activities through the entire program. 

Capturing All Effort: 

The IMS should reflect all effort necessary to successfully complete 
the program, regardless of who performs it. Failing to include all work 
for all deliverables, regardless of whether they are the government's 
responsibility or the contractor's, can lead to project members' 
difficulty understanding the plan completely and the project's 
progressing toward a successful conclusion. If activities are missing 
from the schedule, then other best practices will not be met. Unless 
all necessary activities are accounted for, no one can be certain 
whether all activities are scheduled in the correct order, resources 
are properly allocated, missing activities will appear on the critical 
path, or a schedule risk analysis will account for all risk. Because 
the schedule is used for coordination, the absence of necessary 
elements will hinder coordination, increasing the likelihood of 
disruption and delay. A comprehensive IMS should reflect all a 
program's activities and recognize that uncertainties and unknown 
factors in schedule estimates can stem from, among other things, data 
limitations. A schedule incorporates levels of detail that depend on 
the information available at any point in time through a process known 
as rolling wave planning. Rolling wave planning is described in Best 
Practice 3. 

A program IMS is not simply the prime contractor's schedule; it is a 
comprehensive plan of all government, contractor, subcontractor, and 
key vendor work that must be performed. Along with complete contract 
life cycle effort, the schedule must account for related government 
effort such as design reviews, milestone decisions, government-
furnished equipment, and testing. It is also important to include the 
government effort that leads to final acceptance of the product or 
service--for example, certain activities that only the government can 
perform, such as reviewing and accepting of deliveries, obtaining 
permits, and performing program reviews. Schedulers should be aware of 
how long these government activities take because they often have a 
clear effect on schedules; for instance, a program phase cannot begin 
until the government review is complete. In addition, if risk 
mitigation plans have been determined and agreed on then mitigation 
activities--particularly activities with scope and assigned resources--
should also be captured in the schedule.[Footnote 2] 

It is the responsibility of the government program management office to 
integrate all government and contractor work into one comprehensive 
program plan that can be used to reliably forecast key program dates. 
Moreover, all who are affected should clearly agree on what final 
actions constitute the completion of the project. For instance, if the 
scope includes financial closeout, contract disputes, and final payment 
activities, these should be completed before the finish milestone. 

Case Study 1: Attempts in Varying Degrees to Capture All Effort, from 
DOD Business Transformation, [hyperlink, 
http://www.gao.gov/products/GAO-11-53]: 

Four DOD enterprise resource planning system schedules differed in the 
extent to which they captured all activities, as well as in their 
integration of government and contractor activities. For example, the 
Defense Enterprise Accounting and Management System Program Management 
Office (PMO) did not have a schedule that integrated government and 
contractor activities. The PMO maintained internal schedules that 
reflected government-only activities, but these activities were not 
linked to contractor activities. While the Army's Global Combat Support 
System schedule identified contractor activities, it contained only key 
government milestones for the program. Other government activities, 
such as testing events and milestones beyond December 2010, were not 
captured in the schedule. Instead, they were displayed in isolated, 
high-level illustrated documents. The Expeditionary Combat Support 
System program schedule contained detailed activities associated with 
government effort and contractor effort. However, the government 
activities were not fully linked to contractor activities, so that 
updates to government activities did not directly affect scheduled 
contractor activities. Finally, while the General Fund Enterprise 
Business System schedule captured government and contractor activities, 
dependencies between key milestones in deployment, software release, 
and maintenance were not linked, precluding a comprehensive view of the 
entire program. 

GAO, DOD Business Transformation: Improved Management Oversight of 
Business System Modernization Efforts Needed, [hyperlink, 
http://www.gao.gov/products/GAO-11-53] (Washington, D.C.: October 7, 
2010). 

Milestone, Detail, and Summary Activities: 

Planned effort and events are represented in a schedule by a 
combination of milestones, detail activities, and summary activities. 
Milestones are points in time that have no duration but that denote the 
achievement or realization of key events and accomplishments such as 
program events or contract start dates. Because milestones lack 
duration, they do not consume resources. Two important milestones that 
every schedule should include are the project start and the finish. No 
work should begin before the start milestone, and all project scope 
must be completed before the finish milestone. 

Figure 1: A Milestone's Dates: 

[Refer to PDF for image: illustration] 

Activity name: Budget and design complete; 
Duration (in days): 0; 
Start: 1-9-13; 
Finish: 1-9-13. 

Source: GAO.  

[End of figure] 

A best practice is to create the schedule from primarily detail 
activities and to include milestones only to reflect major events or 
deliverables.[Footnote 3] A milestone should have clear conditions for 
completion. Examples of milestones include the start and finish of the 
design stage, start and finish of subcontractor work, and key hand-off 
dates between parties. The presence of too many milestones in the 
schedule may mask the activities necessary to achieve key milestones 
and may prevent the proper recording of actual progress. That is, when 
too many milestones are introduced into a schedule, the activity 
sequences that are most likely to delay milestone achievement become 
increasingly difficult to identify. If work is represented by 
milestones, actual progress recorded in the schedule cannot be used to 
forecast the dates of key events. 

Detail activities (also known as "normal" or "work" activities) are at 
the lowest level of the WBS and represent actual discrete work that is 
planned to be performed in the project. They are measurable portions of 
effort. Often they result in a discrete product or component, logically 
linked to other preceding and succeeding activities in order to form 
logical sequences and parallel paths of work that must be accomplished 
to complete the project. Logically related paths of detail activities 
are linked to milestones to show the progression of work that it is 
planned to carry out. Detail activities have an estimated duration--
that is, a planned estimate of the time it will take to complete the 
work--and are assigned resources. The status of detail activities is 
examined periodically to record actual progress. Figure 2 shows an 
example of a sequence of activities necessary to complete framing in a 
house construction project. 

Figure 2: Detail Activities: 

[Refer to PDF for image: illustration of Gantt chart] 
        
Activity name: Rough grade property; 
Duration: 1 day; 
Start: 3-19-13; 
Finish: 3-20-13. 

Activity name: Frame first floor walls; 
Duration: 4 days; 
Start: 3-19-13; 
Finish: 3-25-13. 
        
Activity name: Install roof trusses; 
Duration: 2 days; 
Start: 3-25-13; 
Finish: 3-27-13. 

Activity name: Install roof decking; 
Duration: 2 days; 
Start: 3-27-13; 
Finish: 3-29-13. 

Activity name: Rough-in framing inspection; 
Duration: 1 day; 
Start: 3-29-13; 
Finish: 4-1-13. 

Activity name: Form and pour driveway; 
Duration: 2 days; 
Start: 3-29-13; 
Finish: 4-2-13. 

Activity name: Finish excavate and pour garage; 
Duration: 1 day; 
Start: 4-2-13; 
Finish: 4-3-13. 

Activity name: Framing complete; 
Duration: 0 days; 
Start: 4-3-13; 
Finish: 4-3-13. 

Chart indicates: 
* Normal task; 
* Milestones. 

Source: GAO. 

[End of figure] 

Certain scheduling software packages include summary activities as an 
option. Summary activities are grouping elements that are useful for 
showing the time that activities of lower levels of detail require. 
Summary activities derive their start and end dates from lower-level 
activities. Because the work is done at the level of detailed 
activities, summary activities should never be linked to or from other 
activities. Figure 3 shows a summary activity, rolling up the time and 
effort required during the budget and design phase of a house 
construction project. 

Figure 3: Summary Activities: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Budget and design; 
Duration: 6 days; 
Start: 1-2-13; 
Finish: 1-9-13. 

Activity name: Create budget; 
Duration: 1 days; 
Start: 1-2-13; 
Finish: 1-2-13. 

Activity name: Choose and hire architect; 
Duration: 1 days; 
Start: 1-3-13; 
Finish: 1-3-13. 

Activity name: Finalize design; 
Duration: 1 days; 
Start: 1-4-13; 
Finish: 1-4-13. 

Activity name: Apply for mortgage pre-approval; 
Duration: 1 days; 
Start: 1-7-13; 
Finish: 1-7-13. 

Activity name: Secure construction loan; 
Duration: 1 days; 
Start: 1-8-13; 
Finish: 1-8-13. 

Activity name: Secure construction insurance; 
Duration: 1 days; 
Start: 1-9-13; 
Finish: 1-9-13. 

Activity name: Budget and design complete; 
Duration: 0 days; 
Start: 1-9-13; 
Finish: 1-9-13. 

Chart indicates: 
* Normal task; 
* Milestones. 

Source: GAO. 

[End of figure] 

Level of Effort Activities: 

In addition to detailed work activities and milestone events, other 
activities in schedules represent effort that has no measurable output 
and cannot be associated with a physical product or defined 
deliverable. These level of effort (LOE) activities are typically 
related to management and other oversight that continues until the 
detailed activities they support have been completed. Progress on LOE 
activities is based on the passage of time, not the accomplishment of 
some discrete effort. In schedules they should be seen as contributing 
to the comprehensive plan of all work that is to be performed. 

LOE is represented by summary activities in certain scheduling software 
packages, and some schedulers represent LOE effort with detailed 
activities of estimated long duration. When represented as summary or 
long-duration detailed activities in a fully networked schedule, LOE 
activities may inadvertently define the length of a project or program 
and become critical. LOE activities should never be on the critical 
path because they do not represent discrete effort. The main way to 
circumvent issues associated with including LOE in a schedule is to 
represent the effort as an activity that has been designed specifically 
for that purpose--that is, one that derives its duration from detailed 
activities. These types of activities, used specifically to represent 
LOE, are known as "hammock" activities, and they are included in 
certain scheduling software packages. 

Constructing an IMS: 

The overall size of the IMS depends on many factors, including the 
complexity of the program and the technical, organizational, and 
external risk involved. In addition, the intended use of the schedule 
in part dictates its size. That is, a schedule with many short-duration 
activities may make the schedule unusable for other purposes such as 
strategic management or risk analysis. The schedule should not be too 
detailed to interfere with its use. However, the more complex a program 
is, the more complex the IMS must be. 

Generally speaking, the level of detail in the schedule should reflect 
the level of information available on the portion of the work that is 
planned to be accomplished. Both the government and the contractor must 
define the effort required to complete the program in a way that fully 
details the entire scope and planned flow of the work. In this manner, 
the IMS will be defined to the level necessary for executing daily work 
and periodically controlling the project. Schedules that are defined at 
too high a level may disguise risk that is inherent in lower-level 
activities. In contrast, too much detail in a schedule will make it 
difficult to manage progress and may convolute the calculation of 
critical paths. 

The IMS ideally takes the form of a single schedule file that includes 
all activities. However, it may also be a set of separate schedules, 
perhaps representing the work of separate contractors and government 
offices, networked together through external links. Regardless of how 
this is achieved, the IMS schedules must be consistent horizontally and 
vertically. Horizontal and vertical integration form the basis of Best 
Practice 5. 

The IMS includes the summary, intermediate, and all detailed schedules. 
At the highest level, a summary schedule should provide a strategic 
view of summary activities and milestones necessary to start and 
complete a project. Decision makers use summary schedules to view 
overall progress toward key milestones. Summary schedules are roll-ups 
of lower-level intermediate and detail schedules. The dates of these 
milestones are automatically calculated through the established network 
logic between planned activities. 

An intermediate schedule includes all information displayed in the 
summary schedule, as well as key program activities and milestones that 
show important steps toward high-level milestones. Intermediate 
schedules may or may not include detailed work activities. For 
instance, an intermediate schedule may show the interim milestone 
accomplishments necessary before a major milestone decision or 
summarized activities related to a specific trade or resource group. A 
properly defined IMS can facilitate tracking key program milestones 
such as major program decision points or deliverables. The important 
program milestones can be summarized along with the specific required 
activities leading up to the milestone event. 

A detailed schedule, the lowest level of schedule, lays out the 
logically sequenced day-to-day effort to achieve program milestones. 
While each successively lower level of schedule shows more detailed 
date, logic, resource, and progress information, summary, intermediate, 
and detailed schedules should be integrated in a way such that higher-
level schedule data respond dynamically and realistically to progress 
(or lack of progress) at the lower levels. Delays in lower-level 
schedules should be immediately relayed to intermediate and summary 
schedules. A summary schedule presented to senior management should not 
display on-time progress and on-time finish dates if the same 
milestones in lower-level schedules are delayed. 

Ideally, the same schedule serves as the summary, intermediate, and 
detailed schedule by simply rolling up lower levels of effort into 
summary activities or higher-level WBS elements. When fully integrated, 
the IMS shows the effect of delayed or accelerated government 
activities on contractor activities, as well as the opposite. Not every 
team member needs to digest all the information in the entire schedule. 
For example, decision makers need strategic overviews, whereas 
specialist contractors need to see the detail of their particular 
responsibility. Both sets of information should be available from the 
same data in the same schedule. 

In some instances, the government program management office and its 
contractors might use different scheduling software. However, given the 
same schedule data, different software products will produce different 
results because of variations in algorithms and functionality. 
Attempting to manually resolve incompatible schedules in different 
software can become time-consuming and expensive. If the use of 
different software cannot be avoided, the parties should define a 
process to preserve integrity between the different schedule formats 
and to verify and validate the converted data whenever the schedules 
are updated. 

The IMS must include planning for all activities that have to be 
accomplished for the entire duration of the program. A schedule of 
planned effort for one block, increment, or contract for a multiyear 
multiphased program is not a plan sufficient to reliably forecast the 
finish date for the program. Without such a view, a sound basis does 
not exist for knowing with any degree of confidence when and how the 
project will be completed. A comprehensive IMS reflects all activities 
for a program and recognizes that there can be uncertainties and 
unknown factors in schedule estimates because of limited data, 
technical difficulty, inadequate resources, or other factors in the 
organizational environment. Uncertainties regarding future activities 
are incorporated into an IMS in part by the rolling wave process 
(discussed in Best Practice 3) and through schedule risk analysis (Best 
Practice 8). Management should verify that all subcontractor schedules 
are correctly integrated in the IMS at the level of detail appropriate 
to their risk level. Case study 2 highlights the lack of accountability 
associated with the absence of an IMS. 

Case Study 2: Establishing an IMS, from Military Readiness, GAO-09-
518]: 

From its inception in 2002 until November 2008, the Defense Readiness 
Reporting System (DRRS) Implementation Office did not have an 
integrated master schedule. It had long been allowed to proceed, 
therefore, without a basis for executing the program and measuring its 
progress. In fact, the only identifiable milestone for the program 
before November 2008 was the date that DRRS was to achieve full 
operational capability, which was originally estimated for fiscal year 
2007. Later, this slipped to fiscal year 2008 and fiscal year 2011 and, 
at the time of assessment, had become fiscal year 2014--a 7-year delay. 

GAO, Military Readiness: DOD Needs to Strengthen Management and 
Oversight of the Defense Readiness Reporting System, [hyperlink, 
http://www.gao.gov/products/GAO-09-518] (Washington, D.C.: September 
25, 2009). 

Work Breakdown Structure: 

A work breakdown structure is the cornerstone of every program because 
it defines in detail the work necessary to accomplish a program's 
objectives. For example, a typical WBS reflects the requirements to be 
accomplished to develop a program, and it provides a basis for 
identifying resources and activities necessary to produce deliverables. 
A WBS is also a valuable communication tool between systems 
engineering, program management, and other functional organizations 
because it provides a clear picture of what has to be accomplished by 
decomposing the project scope into finite deliverables. Accordingly, it 
is an essential element for identifying activities in a program's IMS. 

A well-structured WBS helps promote accountability by identifying work 
products that are independent of one another. It also provides the 
framework for developing a schedule plan that can easily track 
technical accomplishments--in terms of resources spent in relation to 
the plan as well as completion of activities--allowing quick 
identification of cost and schedule variances. 

A WBS deconstructs a program's end product into successively greater 
levels of detail until the work is subdivided to a level suitable for 
management control. By breaking work down into smaller elements, 
management can more easily plan and schedule the program's activities 
and assign responsibility for the work. It is also essential for 
establishing a reliable schedule baseline. Establishing a product-
oriented WBS such as the one in figure 4 is a best practice because it 
allows a program to track cost and schedule by defined deliverables, 
such as a hardware or software component. This allows program managers 
to identify more precisely which components are causing cost or 
schedule overruns and to more effectively mitigate overruns by 
manipulating their root cause. 

Figure 4: The WBS and Scheduling: 

[Refer to PDF for image: illustration] 

PLANNING: 

0.0 Program Home; 

1.0 Project House; 

1.1 Phase Start-Up; 

1.2 Phase Construction; 

1.2.1 Task Foundation Work; 

1.2.2 Task House Construction. 

Scheduling: 

1.2.2.1 Sub-Task Framing; 

1.2.2.1.1 Work Package Set steel columns; 

1.2.2.1.2 Work Package Install first floor joists. 

Source: Adapted from 2010 Paul D. Giammalvo. 

[End of figure] 

The WBS is the basis of the project schedule and defines what is 
required as a deliverable. Scheduling activities addresses how the 
program is going to produce and deliver what the WBS describes. When 
properly planned, the schedule reflects the WBS and therefore defines 
the activities necessary to produce and deliver the lowest-level 
deliverable. As such, the schedule is a set of instructions on how the 
program intends to execute the project. Every activity within the 
schedule must be traceable to an appropriate WBS element, and every WBS 
element must have at least one associated activity that is necessary to 
complete that element clearly identified within the schedule. Aligning 
the schedule to the program WBS will ensure that the total scope of 
work is accounted for within the schedule. 

In the schedule, the WBS elements are linked to one another through the 
activities' logical relationships and lead to the end product or final 
delivery. The WBS progressively deconstructs the deliverables of the 
entire effort through lower-level WBS elements and control accounts. 

The hierarchical nature of the WBS ensures that the entire statement of 
work accounts for the detailed technical activities and, when 
completed, facilitates communication between the customer and supplier 
on cost, schedule, resource requirements, technical information, and 
the progress of the work. 

It is important that the WBS is comprehensive enough to represent the 
entire program to a level of detail sufficient to manage the size, 
complexity, and risk associated with the program. There should be only 
one WBS for each program, and it should match the WBS used for the cost 
estimate and schedule so that actual costs can be fed back into the 
estimate with a correlation between the cost estimate and schedule. A 
well-developed WBS is essential to the success of all acquisition 
programs.[Footnote 4] 

In addition, the WBS must have an associated WBS dictionary that 
clearly defines the scope of each individual WBS element and, 
therefore, the scope of related schedule activities. Activities that 
are not assigned to WBS elements or are assigned to undefined WBS 
elements reflect unassigned or undefined project scope. In this manner, 
the WBS dictionary helps clarify the boundaries between different WBS 
elements. 

Activity Names: 

A consistent convention for naming work activities should be 
established early in a program and carried through its completion. 
Names for all activities, including summary, milestone, and detailed 
activities, should be unique and as descriptive as necessary to 
facilitate communication between all team members. Descriptive activity 
names will ensure that decision makers, managers, control account 
managers, task workers, and auditors know what scope of work is 
required for each activity. 

Because activities are instructions for someone to carry out, activity 
names should be phrased in the present tense with verb-noun 
combinations, such as "review basis of estimate," "test level 4 
equipment," or "install and test workstations, room 714." Milestone 
descriptive names should be related to an event or a deliverable, such 
as "Milestone B decision" or "level 4 test results report delivered." 
In all cases, descriptive names should be unambiguous and should 
identify their associated product without the need to review high-level 
summary activity or preceding activity names. In the example in figure 
5, it is not clear which products the detailed inspection activities 
are associated without including their respective summary activities 
and preceding activities in the filtered view. 

Figure 5: Redundant Activity Names: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: House construction; 
Start: 3-11-13. 

Activity name: Framing; 
Start: 3-11-13. 

Activity name: Install roof decking; 
Start: 3-27-13. 

Activity name: Inspection; 
Start: 3-29-13. 

Activity name: Interior rough-in; 
Start: 4-3-13. 

Activity name: Dry-in roof; 
Start: 4-9-13. 

Activity name: Inspection; 
Start: 4-11-13. 

Activity name: Interior finishes; 
Start: 4-9-13. 

Activity name: Install drywall on walls and ceilings; 
Start: 4-25-13. 

Activity name: Inspection; 
Start: 5-1-13. 

Source: GAO.  

[End of figure] 

Repetitive naming of activities that are not associated with specific 
products or phases makes communication difficult between teams, 
particularly between team members responsible for updating and 
integrating multiple schedules. However, in figure 6, activity names 
include their respective products, which are also identified for 
clarity in their summary activity. 

Figure 6: Unique Activity Names: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: House construction; 
Start: 3-11-13. 

Activity name: Framing; 
Start: 3-11-13. 

Activity name: Install roof decking; 
Start: 3-27-13. 

Activity name: Rough-in framing inspection; 
Start: 3-29-13. 

Activity name: Interior rough-in; 
Start: 4-3-13. 

Activity name: Dry-in roof; 
Start: 4-9-13. 

Activity name: Roofing inspection; 
Start: 4-11-13. 

Activity name: Interior finishes; 
Start: 4-9-13. 

Activity name: Install drywall on walls and ceilings; 
Start: 4-25-13. 

Activity name: Drywall screw inspection; 
Start: 5-1-13. 

Source: GAO.  

[End of figure] 

Individual activities in figure 6 are easier to identify, especially 
when filters and other analyses are performed on the schedule data and 
the activities are taken out of the summary-indented activity context. 
For example, filtering the schedule data to display only critical path 
activities will not be helpful if activity names are redundant or 
incompletely identify the work being executed. Communicating to 
management that "inspection" is a critical path activity is not very 
useful unless management knows which inspection is meant. Communicating 
that "drywall screw inspection" is a critical path activity conveys 
much more usable information and obviates the need to note its summary 
or predecessor activity. Unique activity names are essential if a 
schedule is to produce reliable information at the summary, 
intermediate, and detailed level. 

Finally, abbreviations specific to programs and agencies should be 
minimal and, if used, should be defined in either the WBS dictionary or 
the schedule baseline document.[Footnote 5] 

Activity Codes: 

In addition to having descriptive names, activities within the schedule 
must be consistent with key documents and other information through 
activity or task codes. Activities should be consistent with such 
information as the related statement of work (SOW) or statement of 
objectives (SOO) paragraph, WBS element, contractor, location, phase, 
contract line item number (CLIN), work package number, and control 
account, as applicable. Every contractor's detailed activities should 
be associated with an SOW or SOO paragraph at some agreed-on level of 
detail.[Footnote 6] Consistent coding can help ensure the vertical 
integration of the summary and detailed work schedules. Activity names 
should not directly contain code information. That is, information such 
as CLIN, SOW, or SOO paragraph numbers should be stored in custom 
fields rather than appended to activity names. 

Each activity should be associated with a unique alpha-numeric code 
that allows it to be immediately identified, particularly in a complex 
schedule with many embedded subprojects. Ideally, this unique code 
preserves the hierarchical relationship between the activity and its 
parent elements. For example, the activity "Software Unit 1A test" 
could be mapped to the code "ADZT125" to represent the Alpha project 
(A), development phase (D), Zeta prime contractor (Z), testing activity 
(T), and activity ID number (125). Other commonly used codes that are 
mapped to schedule activities, either in separate columns or embedded 
in a unique identifier, identify the responsible owner of the activity 
and the related integrated product team (IPT). Codes such as phase, 
department, area, system, and step also greatly facilitate the 
filtering and organization of schedule data for reporting, metric 
analysis, and auditing purposes. LOE activities should be identified as 
such in the schedule, and government and contractor efforts should be 
clearly delineated. Any custom text fields or coding scheme within the 
schedule should be defined in the schedule baseline document. Case 
study 3 shows how activities in a detailed schedule can be quickly 
sorted, filtered, or categorized using codes. 

Case Study 3: Successfully Coding Detailed Work, from VA Construction, 
GAO-10-189: 

The Department of Veterans Affairs (VA) required by contract that the 
schedule for the expansion of the medical centers in Cleveland, Ohio, 
include approximately 2,500 activities in order to sufficiently detail 
the level of work required. The actual schedule contained 2,725 
activities, approximately 75 detail activities per milestone. Each 
activity was mapped to an activity identification number, building 
area, and work trade, which allowed the scheduler to quickly filter the 
schedule by type of work or subcontractor. Additionally, the VA Office 
of Construction and Facilities Management reviewed the schedule for 
completeness to ensure that all necessary activities and milestones 
were included. 

GAO, VA Construction: VA Is Working to Improve Initial Project Cost 
Estimates, but Should Analyze Cost and Schedule Risks, [hyperlink, 
http://www.gao.gov/products/GAO-10-189] (Washington, D.C.: December 
14, 2009). 

Best Practices Checklist: Capturing All Activities: 

* The WBS is the basis of the project schedule. Its elements are linked 
to one another with logical relationships and lead to the end product 
or final delivery. The schedule clearly reflects the WBS and defines 
the activities necessary to produce and deliver each product. 

* The schedule reflects all effort (steps, events, work required, and 
outcomes) to accomplish the deliverables described in the program's 
work breakdown structure. 

* The IMS includes planning for all activities that have to be 
accomplished for the entire duration of the program, including all 
blocks, increments, phases, and so on. 

* The IMS includes the summary and intermediate and all detailed 
schedules. The same schedule serves as the summary, intermediate, and 
detailed schedule by simply rolling up lower levels of effort into 
summary activities or higher-level WBS elements. 

* The detailed schedule includes all activities the government, its 
contractors, and others must perform to complete the work, including 
government furnished equipment or information, deliverables, or 
services from other projects. 

* The schedule contains primarily detail activities and includes 
milestones only to reflect major events or deliverables. 

* If the government program management office and its contractor use 
different scheduling software packages, a process is defined to 
preserve integrity between the different schedule formats, and the 
converted data are verified and validated when the schedules are 
updated. 

* Effort that has no measurable output and cannot be associated with a 
physical product or defined deliverable is represented by level of 
effort (LOE) activities. 

* Activity names are descriptive and clear enough to identify their 
associated product without the need to review high-level summary or 
predecessor activity names. 

* Activities within the schedule are easily traced to key documents and 
other information through activity or task codes. 

[End of Best Practice 1] 

Best Practice 2: Sequencing All Activities: 

[Side bar: Best Practice 2: The schedule should be planned so that 
critical project dates can be met. To do this, activities need to be 
logically sequenced—that is, listed in the order in which they are to 
be carried out. In particular, activities that must be completed 
before other activities can begin (predecessor activities), as well as 
activities that cannot begin until other activities are completed 
(successor activities), should be identified. Date constraints and 
lags should be minimized and justified to help ensure that the 
interdependence of activities that collectively lead to the completion 
of events or milestones can be established and used to guide work and 
measure progress. End of side bar] 

Once established, a schedule network can forecast reliably--in light 
of the best information available at that point in time--the start and 
finish dates of future activities and key events based on the status of 
completed and in-progress activities. Dates are forecast with some 
realism by planning work effort in sequences of activities that 
logically relate portions of effort to one another. The schedule 
network is a model of all ongoing and future effort related to the 
program; it establishes not only the order of activities that must be 
accomplished but also the earliest and latest dates on which those 
activities can be started and finished to complete the project on time. 
By establishing the network logic, the schedule can also the effect on 
the project's planned finish date of, among other things, misallocated 
resources, delayed activities, external events, scope changes, and 
unrealistic deadlines. 

The ability of a schedule to forecast the start and finish dates of 
activities and key events reliably is directly related to the 
complexity and completeness of the schedule network. The reliability of 
the schedule is in turn related to the management's ability to use the 
schedule to direct the assignment of resources and perform the correct 
sequence of activities. Activities are related through different types 
of sequential and parallel predecessor and successor logic. 

The more complex a program is, the more complex the schedule must be. 
However, it is essential that the schedule to be as straightforward as 
possible so that management has a clear indication of the path forward 
and the necessary resources needed to accomplish activities on time. 
Convoluted logic techniques such as date constraints, lags, and misused 
logic links should be eliminated and, if used, employed judiciously and 
justified in the schedule documentation. 

Once all dependencies are in place, the schedule should be presented 
for the review and approval of management and the persons responsible 
for performing the work. Major handoffs between groups should be 
discussed and agreed on to ensure that the schedule correctly models 
what is expected to happen. This will help everyone see the big picture 
needed to complete the entire project scope. 

Predecessor and Successor Logic: 

Activities that are logically related within a schedule network are 
referred to as predecessors and successors. A predecessor activity must 
start or finish before its successor. The purpose of a logical 
relationship, or dependency, is to depict the sequence in which 
activities occur. Such relationships state when activities are planned 
to start and finish in relation to the start and finish of other 
activities. A logic relationship therefore models the effect of an on-
time, delayed, or accelerated activity on subsequent activities. 
Relationships between activities can be internal--that is, within a 
particular schedule--or external--that is, between schedules. 

Logical relationships between activities identify whether they are to 
be accomplished in sequence or in parallel. A sequence of activities is 
a serial path along which one activity is completed after another. 
Activities can also be accomplished in parallel, or concurrently. A 
logic relationship linking a predecessor and successor activity can 
take one of three forms: finish-to-start, start-to-start, and finish-
to-finish.[Footnote 7] 

A finish-to-start (F-S) relationship is the most straightforward 
logical link between a predecessor and successor. In it, a successor 
activity cannot start until the predecessor activity finishes, creating 
a simple sequence of planned effort. This logical relationship is the 
default in most scheduling programs. In figure 7, the installation of 
roof decking cannot begin until the installation of roof trusses 
finishes. Note that the installation of the roof decking does not 
necessarily need to start once the installation of the roof trusses 
finishes, but it cannot start until the trusses are installed. The 
"install roof decking" activity may have other predecessors that push 
its start date further into the future. 

Figure 7: Finish-to-Start Relationship: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install roof trusses; 
Start: 3-25-13; 
Finish: 3-27-13. 

Activity name: Install roof decking; 
Start: 3-27-13; 
Finish: 3-29-13. 

Source: GAO. 

[End of figure] 

A start-to-start (S-S) relationship dictates that a successor activity 
cannot start until the predecessor activity starts. In the example in 
figure 8, the application of wall finishes cannot start until the 
application of drywall texture starts. The S-S relationship does not 
dictate that wall finishing must start at the same time that drywall 
texturing starts, but it does indicate that it cannot start until 
drywall texturing starts. The "apply wall finishes" activity may have 
other predecessors that push its start date further into the future. 

Figure 8: A Start-to-Start Relationship: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Apply drywall texture; 
Start: 5-12-13; 
Finish: 5-17-13. 

Activity name: Apply wall finishes (stain and paint); 
Start: 5-12-13; 
Finish: 5-17-13. 

Source: GAO. 

[End of figure] 

A finish-to-finish (F-F) relationship dictates that a successor 
activity cannot finish until the predecessor activity finishes. In 
figure 9, final landscaping cannot finish until forming and pouring the 
patio has finished. Again, the F-F relationship does not dictate that 
landscaping must finish at the same time as pouring the patio finishes, 
but it cannot finish until the pouring of the patio finishes. The final 
landscaping activity may have other predecessors that determine its 
finish date, or it may finish later than the patio pouring activity. 

Figure 9: A Finish-to-Finish Relationship: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Form and pour patio; 
Start: 4-23-13; 
Finish: 4-24-13. 

Activity name: Plant trees and shrubs and install final landscaping; 
Start: 4-19-23; 
Finish: 4-24-13. 

Source: GAO. 

[End of figure] 

The majority of relationships within a detailed schedule should be 
finish-to-start. Finish-to-start relationships are intuitive because 
most work is accomplished serially. Moreover, F-S relationships are 
easy to trace within a schedule network and clearly indicate to 
management which activities must finish before others begin and which 
activities may not begin until others have been completed. F-S 
relationships are most easily implemented where work is broken down to 
small elements. 

Start-to-start and finish-to-finish relationships, in contrast, imply 
parallel or concurrent work. S-S and F-F relationships represent a 
valid technique for modeling the overlapping of activities. As such, 
they may be more predominant in schedules that have not yet evolved to 
a detailed level. However, an overabundance of these relationships in 
detail schedules may suggest an overly optimistic or unrealistic 
schedule or shortcuts that have been taken in modeling activities and 
logic. Particularly in a detailed schedule, their overuse may impair 
the usefulness of the schedule by, for example, complicating the 
identification of the critical path. S-S and F-F relationships are also 
prone to producing unintentional "dangling" relationship logic, an 
error that is described later in this best practice. 

Once the logic has been established to create a network, the scheduling 
software will calculate a set of start and finish times for each 
activity, given the relationship logic and the estimated duration of 
each activity. Ideally, there should be only one date input into the 
scheduling software--the project start date--and all other dates are 
calculated by the network logic. Network logic calculates activity 
dates that define both when an activity may start and finish and also 
when an activity must start and finish in order to meet a specified 
program completion date. These are known as early and late dates, 
respectively. 

Each activity has an early start and an early finish date. 

* Early start defines the earliest time when an activity may start. 

* Early finish defines the earliest time when an activity may finish. 

The early start and early finish dates for each activity are 
calculated by the "forward pass" method. The forward pass determines 
the early start and early finish times for each activity by adding 
durations successively through the network, starting at day one. The 
forward pass will derive the total time required for the entire project 
by calculating the longest continuous path through the network--that 
is, the sequence of activities that determines the length of the 
project, typically known as the critical path. Managing the critical 
path is the foundation of Best Practice 6. 

Each activity also has a late start and a late finish date. 

* Late start defines the latest time when an activity must start in 
order for the project to be completed on time. 

* Late finish defines the latest time when an activity must finish in 
order for the project to be completed on time. 

The late start and late finish for each activity are calculated by 
the "backward pass" method--the opposite of the forward pass. Whereas 
the forward pass determines early finishes by adding durations to early 
starts, the backward pass determines late starts by subtracting 
durations from late finishes. 

The difference between an activity's early and late dates is known as 
total float or slack. Total float is an essential output of critical 
path method scheduling, and its proper management is the foundation of 
Best Practice 7. 

In figure 10, the excavation and installation of the underground 
sewer lines may begin as early as February 19 (early start) and finish 
as early as February 20 (early finish). However, in order for the house 
construction project to be completed on time, the excavation and 
installation must begin by February 21; if they do, the project will 
finish on February 22. The activity therefore has 2 days of total 
float: the difference between its early start date of February 19 and 
its late start date of February 21.[Footnote 8] The red box in figure 
10 represents the late start and late finish dates, and the black box 
represents the early start and early finish dates. 

Figure 10: Early and Late Dates: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Excavate and install for underground sewer; 
Early start: 2-19-13; 
Late start: 2-21-13; 
Early finish: 2-20-13; 
Late finish: 2-22-13. 

Source: GAO. 

Appendix II gives a detailed example of how to calculate early and late 
dates using the forward and backward passes. 

Incomplete and Dangling Logic: 

Because a logic relationship dictates the effect of an on-time, 
delayed, or accelerated activity on subsequent activities, any missing 
or incorrect logic relationship is potentially damaging to the entire 
network. Complete network logic between all activities is essential if 
the schedule is to correctly forecast the start and end dates of 
activities within the plan. 

As a general rule, every activity within the schedule should have at 
least one predecessor and at least one successor. The two natural 
exceptions to this rule are the project start milestone, which will 
have no predecessor, and the project finish milestone, which will have 
no successor. In some cases, other activities within the schedule may 
not have predecessor or successor links. For example, a milestone may 
represent handing off some interim product to an external partner by 
the program office and therefore has no successor relationship within 
the schedule. However, any activity that is missing predecessor or 
successor logic must be clearly justified in the schedule 
documentation. 

Even if an activity has predecessor and successor logic relationships, 
incorrect or incomplete logic can arise. Networks should be assessed 
for circular logic--that is, logic that forces two activities to be 
dependent on each other. Circular logic creates an endless loop of 
work: an activity cannot have its successor also be its predecessor. In 
addition, the network should be clear of redundant logic. Redundant 
logic represents unnecessary logic links between activities. For 
example, if a sequence of activities A, B, and C exists with a series 
of finish-to-start logic, there is no need for an additional F-S logic 
link between A and C. 

Activities with S-S or F-F relationships should be checked for two 
types of "dangling" logic. Dangling or "hanging" logic is scheduling 
logic that is not properly tied to an activity's start or end date. 
Each activity's start date--other than the start and finish milestones-
-must be driven by a predecessor activity, and each activity's finish 
date must drive a successor activity's start or finish. Dangling logic, 
a form of incomplete logic, can interfere with the valid forecasting of 
scheduled activities. 

The first type of dangling logic occurs when an activity has a 
predecessor and a successor but its start date is not properly tied to 
logic. In other words, no preceding activity within the schedule is 
determining the start date of the activity, with either its start (S-S) 
or finish (F-S). Figure 11 shows a sequence of activities--form and 
pour sidewalks, form and pour patio, install final landscaping--and a 
completion milestone. 

Figure 11: Start-Date Dangling Logic: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Form and pour sidewalks. 

Activity name: Form and pour patio. 

Activity name: Plant trees and shrubs and install final landscaping 
Exterior finishes complete. 

Source: GAO. 

[End of figure] 

"Form and pour patio" has an F-S relationship to its predecessor 
activity, "form and pour sidewalks," and an F-F relationship with its 
successor, "plant trees, shrubs, and install final landscaping." "Plant 
trees, shrubs, and install final landscaping" in turn has an F-S 
relationship with the "exterior finishes complete" milestone. Notice 
that the finish date of "plant trees, shrubs, and install final 
landscaping" is determined by the predecessor relationship to the 
finish of "form and pour sidewalks"; that is, final landscaping cannot 
finish until the patio is formed and poured. The problem here is that 
the start date of "final landscaping" is not determined by any 
relationship; it is simply determined by the estimated time it will 
take to accomplish final landscaping and its finish date. Moreover, if 
"form and pour patio" finishes but "final landscaping" runs longer than 
planned, the only resolution--according to the original plan--is for 
"final landscaping" to start earlier. This is a logical solution but 
practically impossible, because it may have already started before it 
is determined that it takes longer than planned. To correct the 
dangling logical error, "final landscaping" must have at least one F-S 
or S-S predecessor link alongside the F-F predecessor relationship to 
determine its start date. This requirement might make the scheduler 
find a different predecessor or break "form and pour patio" into two 
activities. 

The second type of dangling logic is similar to the first but involves 
an activity's finish date. Figure 12 shows a sequence of activities: 
finish drywall, apply drywall texture, apply wall finishes, and install 
trim. "Apply drywall texture" has an F-S predecessor link to "finish 
drywall" and an S-S successor relationship to "apply wall finishes." 

Figure 12: Finish-Date Dangling Logic: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Finish drywall (tape and mud). 

Activity name: Apply drywall texture. 

Activity name: Apply wall finishes (stain and paint). 

Activity name: Install interior door, window, and baseboard trim. 

Source: GAO. 

[End of figure] 

In this example, "apply drywall texture" starts once "finish Drywall" 
completes. Once "apply drywall texture" starts, "apply wall finishes" 
can start. Note, however, that while "apply drywall texture" has a 
successor, its finish date is not related to any subsequent activity. 
In other words, "apply drywall texture" can continue indefinitely with 
no adverse affect on subsequent activities, until it affects the 
owner's occupation date--to which it is implicitly linked by an F-S 
relationship by the scheduling software. To correct the dangling 
logical error, "apply drywall texture" must have at least one F-S or F-
F successor link alongside the S-S successor relationship in order for 
its finish date to affect downstream activities. 

Finally, note that dangling logic is far more dangerous for detail 
activities than milestones. Milestones have the same start and finish 
dates, so from a practical standpoint, delaying or accelerating a 
milestone within the schedule would still affect successor activities, 
even with start or finish date dangling logic. In point of fact, there 
is little reason to sequence milestones with any logic other than F-S, 
because milestones simply indicate a point in time. Regardless, all 
dangling logic should be corrected to ensure that the logic in the 
schedule is as straightforward and intuitive as possible. 

To summarize dangling logic checks: 

* Any activity with an F-F predecessor link must also have at least one 
F-S or S-S predecessor link. If nothing is driving the start date of 
the activity, then why not start the activity earlier? 

* Any activity with an S-S successor link must also have at least one 
F-S or F-F successor link. If the finish date of the activity is not 
driving the start of another activity, then why finish the activity? 

Complete schedule logic that addresses the logical relationships 
between predecessor and successor activities is important. The analyst 
needs to be confident that the schedule will automatically calculate 
the correct dates when the activity durations change. 

Summary Logic: 

Summary activities should not have logic relationships because their 
start and finish dates are derived from lower-level activities. 
Therefore, there is no need for logic relationships on a summary 
activity in a properly networked schedule. 

Summary logic hinders vertical traceability. For example, if the start 
or finish dates of summary activities are not derived by the planned or 
actual dates of lower-level activities, then the dates of summary 
activities may be misrepresented in higher-level versions of the 
schedule.[Footnote 9] In addition, tracing logic through summary links 
does not impart to management the sequence in which lower-level 
activities should be carried out. Figure 13 gives an example of a 
linked summary activity. The summary activity "interior rough-in" 
defines the start date of "HVAC interior rough-in," "plumbing interior 
rough-in," and "install exterior vapor barriers," rather than the 
activities' start dates defining the summary start date. Moreover, 
because the summary logic masks actual work effort relationships, it 
may not be clear to management that "HVAC interior rough-in," "plumbing 
interior rough-in," and "install exterior vapor barriers" all depend on 
"framing complete" occurring. 

Figure 13: A Linked Summary Activity: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Framing complete. 

Activity name: Interior rough-in. 

Activity name: HVAC interior rough-in and through-roof penetration. 

Activity name: Plumbing interior rough-in and through-roof penetration. 

Activity name: Dry-in roof. 

Activity name: Roofing inspection. 

Activity name: Install exterior vapor barriers. 

Activity name: Install exterior doors and windows. 

Activity name: Install exterior siding and brick finishes. 

Source: GAO. 

[End of figure] 

Case study 4 provides an example of how using summary links may 
initially make scheduling activities easier but eventually convolutes 
the network logic. 

Case Study 4: Summary Logic, from DOD Business Transformation, 
GAO-11-53: 

GAO's analysis of the General Fund Enterprise Business System schedule 
found that 50 summary activities (12 percent of remaining summary 
activities) had predecessor links. Program Management Office schedulers 
used these summary links rather than linking predecessors to their 
numerous lower-level activities. Because many of the lower-level 
activities began on the same date, this made updating the schedule 
simpler: an updated start date for the summary activity forced that 
same date on all the unlinked lower-level activities. 

Despite updating's being made easier, the technique is not considered a 
best practice. First, summary activities do not represent work and are 
used simply as grouping elements. They should take their start and 
finish dates from lower-level activities; they should not dictate the 
start or finish of lower-level activities. Second, linking summary 
activities obfuscates the logic of the schedule. That is, tracing logic 
through summary links does not impart to management the sequence in 
which lower-level activities should be carried out. 

GAO, DOD Business Transformation: Improved Management Oversight of 
Business System Modernization Efforts Needed, [hyperlink, 
http://www.gao.gov/products/GAO-11-53] (Washington, D.C.: October 7, 
2010). 

Date Constraints: 

Ideally, relationship logic, the duration of activities, and resource 
availability determine the planned early and late start dates of all 
activities within the schedule network. However, in some cases it may 
be necessary to override the calculated start or finish dates of 
activities by imposing calendar restrictions on when an activity can 
begin or end. Such restrictions are referred to as date constraints. 
Constraints can be placed on an activity's start or finish date and can 
limit the movement of an activity into the past or future or both. 
Because constraints override network logic and restrict how planned 
dates respond to actual accomplished effort or resource availability, 
they should be used only when necessary and only if they are justified 
in the schedule documentation. Generally, constraints are used to 
demonstrate an external event's effect on the schedule. For example, 
constraints may be used to show the expected availability of a 
production line. 

"Not earlier than" constraints affect the forward pass of the schedule 
and thus may delay a project by pushing some activities' start dates 
later than permitted by their predecessors. These types of constraints 
are also known as "past-limiting" in that they prevent activities from 
starting or finishing earlier than planned but allow them to slip into 
the future if predecessor activities are delayed. 

* Start no earlier than (SNET): schedules an activity to start on or 
after a certain date even if its predecessors start or finish earlier. 
That is, it prevents an activity from beginning before a certain date. 
SNET constraints are also called start on or after constraints. 

* Finish no earlier than (FNET): schedules an activity to finish on or 
after a certain date. That is, it prevents an activity from finishing 
before a certain date. FNET constraints are also called finish on or 
after constraints. 

"Not later than" constraints affect the backward pass of the schedule 
and thus may unrealistically accelerate the project. These types of 
constraints are also known as "future-limiting" in that they prevent 
activities from starting or finishing later than planned but allow them 
to be accomplished earlier if possible. 

* Start no later than (SNLT): schedules an activity to start on or 
before a certain date. That is, it prevents the activity from starting 
any later than a certain date. SNLT constraints are also called start 
on or before constraints. 

* Finish no later than (FNLT): schedules an activity to finish on or 
before a certain date. That is, it prevents an activity from finishing 
after a certain date. FNLT constraints are also called finish on or 
before constraints. 

"Must" or "mandatory" constraints affect both the forward pass and 
the backward pass of the schedule, forcing activities to occur on dates 
regardless of network logic. These types of constraints prevent 
activities from starting or finishing on any day other than the date 
assigned. 

* Must start on (MSO): schedules an activity to start on a certain 
date. That is, it prevents the activity from starting any earlier or 
later than a certain date, thereby overwriting network logic. MSO 
constraints are also called mandatory start constraints. 

* Must finish on (MFO): schedules an activity to finish on a certain 
date. That is, it prevents the activity from finishing any earlier or 
later than a certain date, thereby overwriting network logic. MFO 
constraints are also called mandatory finish constraints. 

Date constraints are often categorized as either soft (also referred 
to as moderate or one-sided) or hard (also referred to as inflexible), 
depending on how the constraint restricts the ability of the activity 
to accelerate or slip according to the established network logic. 
[Footnote 10] Soft constraints include SNET and FNET constraints. 
These are called soft because while they restrict the ability of the 
activity to start or finish early, depending on network logic, they 
allow the activity to start or finish later than planned. In this 
respect, these constraints allow delays to permeate the schedule and, 
given available float, possibly affect the project's end date. 

Hard constraints include the SNLT, FNLT, MSO, and MFO constraints. 
SNLT and FNLT constraints prevent activities from starting or finishing 
later than planned, essentially restricting the ability of any 
predecessor delays to affect their start and finish dates. While these 
types of constraints allow activities to start and finish earlier than 
planned, the acceleration of activities is not usually as big a concern 
to program management as the delay of activities. 

Mandatory start and finish constraints are the most rigid because 
they do not allow the activity to either take advantage of time savings 
by predecessor activities or slip in response to delayed predecessors 
or longer-than-scheduled durations. By setting the early and late dates 
of an activity equal to each other, a mandatory start or finish 
constraint immediately eliminates all float associated with the 
activity and renders them static in time; successors might start on the 
next day, even though unconstrained logic would not permit it. 

Using Date Constraints: 

As noted previously, date constraints are generally used to demonstrate 
an external event's effect on the schedule. However, because they 
prevent activities from responding dynamically to network logic, 
including actual progress and availability of resources, they can 
affect float calculations and the identification or continuity of the 
critical path and can mask actual progress or delays in the schedule. 
Date constraints should be minimized because they restrict the movement 
of activities and can cause false dates in a schedule. They can also 
imply a false level of criticality because of their effects on float. 
Moreover, constraints affect the analysis of risk in the schedule. Hard 
constraints can sometimes be impossible to meet, given the network 
characteristics, and can thereby result in schedules that are logically 
impossible to carry out. 

SNET constraints are valuable when an activity cannot start any earlier 
than a fixed date and has no other logical dependencies. They are often 
used to represent the availability of cash flow or reliance on some 
external product. For example, a production line may not be available 
until an outside entity finishes producing its product. In that case, 
an SNET constraint would legitimately prevent scheduled activities from 
unrealistically starting before they should. 

SNET constraints are also used to signal the receipt of some item, such 
as a hardware subcomponent or a government-furnished test article. 
However, often these conditions of supply by an outside vendor or 
contractor are better represented as actual activities in the schedule. 
For example, the receipt of a subcontractor hardware component is often 
modeled as a milestone with an SNET constraint. It may be more 
appropriate to model this as one activity or a sequence of activities 
representing the whole procurement process, starting with the ordering 
of the product and ending with actual receipt. These types of 
representative activities--referred to as "reference" tasks or 
"schedule visibility" tasks--are not part of the project scope and have 
no assigned resources, yet they have the potential to affect project 
activities. For example, the time to produce the product should be 
represented by a fabrication activity. By modeling vendor or contractor 
production as an activity, the program office can track the high-level 
progress of the contractor and apply risk to the external production 
activity. Representing supplier, government, or subcontractor 
deliverables as date-constrained milestones rather than summary 
activities may understate the risk in the procurement process. 

SNET constraints are also often used to delay activities in response to 
available resources, such as labor or funding. However, this model 
should not be used for several reasons. First, it prevents the 
constrained activity from dynamically taking advantage of possible time 
savings being produced by predecessor activities. Second, logical 
dependencies should not be used to allocate resources because, 
typically, resource-constrained activities that are resolved with date 
constraints are forced to occur sequentially. This may temporarily 
solve a specific resource overallocation, but the sequential logic will 
remain even if additional resources are assigned to the activities. 
Finally, perhaps the main disadvantage of applying SNET constraints to 
represent the availability of resources is that it requires constant 
manual upkeep of the schedule. Updating constraint dates on associated 
activities manually may be manageable in a relatively small schedule 
with a small number of resources. However, large schedules with 
hundreds of SNET constraints representing tens or hundreds of resources 
will quickly become unmanageable, and the likelihood of errors will 
increase. If decision makers are not aware that an unnecessary SNET 
constraint on a low-level detail activity is preventing the activity 
from starting earlier, additional opportunities for time savings will 
be lost. 

As described in Best Practice 3, resources should be assigned to 
activities so that their availability can drive the dates of planned 
activities according to resource calendars. For example, suspensions to 
work because of weather events are most appropriately indicated by a 
nonworking period in the working calendar rather than date constraints. 
Updating resource calendars is easier to manage than manually updating 
hundreds of individual constraints (see case study 5). 

Case Study 5: Managing Resources with Constraints, from DOD Business 
Transformation, GAO-11-53: 

GAO's analysis of the Army's Global Combat Support System found that 
dependencies within the schedule were generally sound, but 60 percent 
of the activities (or 1,360) had Start No Earlier Than (SNET) 
constraints. SNET constraints are considered "soft" date constraints 
because they allow an activity to slip into the future if their 
predecessor activity is delayed, but the activity cannot begin earlier 
than its constraint date. 

Program officials stated that SNET constraints were used to manually 
allocate resources and coordinate data tests, which relied on 
coordination with outside partners. Officials further stated that 
individual control account managers monitor these constraints. GAO 
found that 87 percent of the constraints were actively affecting the 
start date of their activities. That is, without the constraint, the 
activity might have been able to start sooner. 

Constraining over half of all activities to start on or after specific 
dates defeats the purpose of a dynamic scheduling tool and greatly 
reduces the program's ability to take advantage of possible time 
savings. 

GAO, DOD Business Transformation: Improved Management Oversight of 
Business System Modernization Efforts Needed, [hyperlink, 
http://www.gao.gov/products/GAO-11-53] (Washington, D.C.: October 7, 
2010). 

More information on resources and calendars is given in Best Practices 
3 and 4. 

Finally, SNET and FNET date constraints that are not actively 
constraining an activity's start or finish date should be removed from 
the schedule. In these cases, the constraints are meaningless. 

The hard MSO and MFO constraints prevent activities from moving either 
forward or back in the plan in response to the status of predecessor 
activities. This includes preventing the constrained activities from 
taking advantage of time savings from predecessor activities. In other 
words, even if the constrained activity could start earlier, it will 
not do so according to network logic because the early and late dates 
are set equal. 

Placing a hard constraint on an activity fixes the date and immediately 
causes the activity to become critical. It is therefore possible to use 
hard constraints as a temporary working tool during schedule 
development to calculate total available float up to key milestones. 
The temporary use of hard constraints is also valuable for assessing 
the realism of available resources to achieve the planned activity 
date. For example, a hard constraint placed on an intermediate delivery 
milestone may show the need for an immediate "bow wave" of resources, 
shortening the predecessor durations because it is forcing the 
milestone to be achieved on an unrealistic date. 

Hard constraints are useful for calculating the amount of float 
available in the schedule and, therefore, the realism of the required 
project finish date and available resources during schedule 
development. However, they may be abused if they force activities to 
occur on specific dates that are determined off-line without much 
regard for the realism of the assumptions necessary to achieve them. It 
is important to note that just because an activity is constrained in a 
schedule, the activity is not necessarily constrained in reality. A 
customer-mandated date, including contractual obligations, does not 
constitute a legitimate reason to constrain an activity. A schedule is 
intended to be a dynamic, pro-active planning and risk mitigation tool 
that models the project and can be used to track progress toward 
important project milestones. Schedules with constrained dates can 
portray an artificial or unrealistic view of the project and begin to 
look more like calendars than schedules. Such unrealistic views are 
especially dangerous when they are translated to higher-level summary 
schedules for decision makers' use. 

Senior management may not be aware that key milestone dates in the 
summary schedules are artificially fixed dates that are actually behind 
schedule in working-level detailed schedules. Working versions of 
schedules may include hard constraints to assess available float and 
available resources, but the baseline schedule and official status 
updates should not contain hard constraints. If a hard constraint 
cannot be avoided, it must be used judiciously and be fully justified 
by referring to some controlling event outside the schedule in the 
schedule's baseline documentation. 

In summary, 

* SNET and FNET constraints delay activity starts and finishes even if 
predecessor durations allow them to occur earlier. These constraints 
allow activities to slip if their predecessors cause them to slip--in 
this case, they become meaningless and should be deleted. However, 
their use must be justified because, in general, program management's 
not wanting to start or finish an activity as soon as possible may be 
questionable. 

* Because SNLT and FNLT constraints prevent activities from slipping, 
their use is discouraged. They should never appear in the schedule 
baseline. If they are not properly justified in working schedules, they 
must be immediately questioned. 

* Because MSO and MFO constraints prevent activities not only from 
slipping but also from accelerating, their use is discouraged. They 
should never appear in the schedule baseline. If not properly justified 
in working schedules, they must be immediately questioned. 

Many activities with date constraints are typically substitutes for 
logic and can mean that the schedule was not well planned and may not 
be feasible. In addition, constraints can cause misleading risk 
analysis results because they override network logic. 

Lags and Leads: 

A lag in a schedule denotes the passage of time between two activities. 
Lags simply delay the successor activity--no effort or resources are 
associated with this passage of time. A common example of the use of a 
lag is the passage of time to allow concrete to cure, as in figure 14. 
The forms on the basement walls cannot be stripped until the concrete 
cures. While other work may be occurring in parallel in other parts of 
the house, this particular sequence of activities is delayed in order 
that the concrete can cure. 

Figure 14: A Lag: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Pour basement walls; 
Start: 3-4-13; 
Finish: 3-5-13. 

Activity name: Strip form for basement walls; 
Start: 3-7-13; 
Finish: 3-8-13. 

Source: GAO. 

[End of figure] 

Without the lag, work associated with stripping the forms may start as 
soon as the basement walls are poured. The lag delays the start of the 
successor activity to allow time for the concrete to cure. 

A negative lag, known as a lead, is used to accelerate a successor 
activity. In figure 15, installing the rebar in the basement walls is 
accelerated to begin one day before the forming of the walls is 
finished. 

Figure 15: A Negative Lag (or Lead): 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Form basement walls; 
Start: 2-26-13; 
Finish: 2-28-13. 

Activity name: Install rebar in basement walls; 
Start: 2-27-13; 
Finish: 2-27-13. 

Source: GAO. 

[End of figure] 

Without the lead, installing of rebar would start as soon as the 
basement walls have been formed. The lead accelerates the start of the 
rebar installation activity and allows the forming of the walls and the 
installation of the rebar to overlap 2 days before formation of the 
walls is completed. If this is possible, the project might finish ahead 
of schedule. 

Using Lags: 

Like constraints, lags have a specific use in scheduling but may be 
abused. Because lags denote the passage of time and leads denote the 
acceleration of a successor relationship, they are often misused to 
force successor activities to begin on specific dates. For example, if 
the general contractor has mandated the installation of floor joists 
and decking must start on March 20, yet its predecessor activity 
finishes on March 12, a 6-working day lag will force the installation 
activity to occur at a date later than necessary (see figure 16). 

Figure 16: Using a Lag to Force an Activity's Start Date: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Set steel columns and beams; 
Start: 3-11-13; 
Finish: 3-11-13. 

Activity name: Install first floor joists and decking; 
Start: 3-20-13; 
Finish: 3-22-13. 

Source: GAO. 

[End of figure] 

The lag in the example lessens the ability of the project schedule to 
dynamically respond to changes in the status of predecessor activities. 
A lag is static; that is, the lag will always be 6 days long unless the 
scheduler manually changes it. As shown in figure 17, if the 
predecessor activity slips 1 day, the 6-day lag forces the mandated 
event to occur 1 working day later than March 20. For the event to 
occur on March 20, the lag must be changed to 5 days. 

Figure 17: The Effect of a Lag on Successor Activities: 

[Refer to PDF for image: illustration of Gantt chart] 
   
Activity name: Set steel columns and beams; 
Duration (in days): 1; 
Start: 3-11-13; 
Finish: 3-11-13. 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Start: 3-20-13; 
Finish: 3-21-13. 

Activity name: Set steel columns and beams; 
Duration (in days): 2; 
Start: 3-11-13; 
Finish: 3-12-13. 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Start: 3-21-13; 
Finish: 3-22-13. 

Source: GAO. 

[End of figure] 

Constant manual updating defeats the purpose of a dynamic schedule and 
is particularly prone to error when the schedule contains many lags. If 
for some compelling reason outside the schedule joists and decking 
installation cannot start before March 20, the better approach would be 
to put the SNET constraint there. Hence, that date will be maintained 
unless its predecessor is delayed past March 20, and then the activity 
will by logic be pushed to a later date. 

Lags, like date constraints, must be used judiciously. They represent a 
real need to delay or quicken time between two activities. They must be 
justified by compelling reasons outside the schedule in the schedule 
documentation. In particular, F-S relationships with lags are generally 
not necessary. In these cases, every effort should be made to break 
activities into smaller tasks and to identify realistic predecessors 
and successors so that logic interface points are clearly available for 
needed dependency assignments. If used improperly, lags can distort 
float calculations in the schedule and corrupt the calculation of the 
critical path. Lags are useful in summary and intermediate schedules 
because portions of long-term effort are likely to be unknown, or one 
may wish to reduce the number of activities displayed in high-level 
reports. Lags are usually used in places where detail is not 
sufficiently broken down to identify the needed interface points for 
making proper relationships, as in early summary-level schedules. 

But lags must not be used in the place of effort in detailed schedules 
because lags take no resources. Likewise, lags should not be used to 
represent procurement activities or other types of work performed by 
parties external to the schedule. Because lags are static and simply 
denote the passage of time, they cannot be updated with progress, are 
not easily monitored, and do not respond to the availability of 
resources. 

Lags are also often used as buffers between two activities for risk; 
however, this practice should be discouraged because the lags persist 
even as the actual intended buffer is used up. 

Using Leads: 

Leads in particular are often unnecessary. As negative lags, leads 
imply the unusual measurement of negative time and exact foresight 
about future events. In the example in figure 15, management must 
assume some prescient knowledge to start installing rebar 1 day before 
wall forming finishes. Any delay in forming the walls within the last 
day may cause immediate problems for the plan. A 2-day look ahead might 
seem trivial, but leads of weeks or even months are common in some 
schedules, causing a credibility problem when people are forced to see 
that far into the future on a risky project. In effect, a lead 
indicates that a future event will dictate the timing of an event in 
the past--a situation that is neither logical nor possible. 

The concept of a lead is better represented by a positive lag on an S-
S relationship, or even more straightforward, F-S relationships with no 
lags using smaller-duration activities. For example, instead of a lead, 
the wall-forming activity should be broken down into smaller activities 
to identify the proper F-S activities. For example, the wall-forming 
activity might be broken into two sequential subactivities: "form east 
and west basement walls" and "form north and south walls." "Install 
rebar in basement walls" could then be linked with a finish-to-start 
relationship to "form east and west walls," as shown in figure 18. 

Figure 18: Eliminating Leads with Finish-to-Start Links: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Form east and west basement walls; 
Start: 2-26-13; 
Finish: 2-27-13. 

Activity name: Form north and south basement walls; 
Start: 2-27-13; 
Finish: 2-28-13. 

Activity name: Install rebar in basement walls; 
Start: 2-27-13; 
Finish: 2-28-13. 

Source: GAO. 

[End of figure] 

The network now clearly shows that once the east and west walls have 
been formed, rebar installation can begin. It also clearly identifies 
that rebar installation can go on while the last two walls are being 
formed. Any delay in forming the last two walls will still delay rebar 
installation, but the sequence of events and delay's effects are now 
obvious to anyone not intimately familiar with the project. 

Finally, using leads improperly can cause logic failures when a lead is 
longer than the successor activity. An example is given in figure 19. 

Figure 19: Logic Failure Associated with a Lead: 

[Refer to PDF for image: illustration of Gantt chart] 
 
Activity name: Form basement walls; 
Start: 2-26-13; 
Finish: 2-28-13. 

Activity name: Install rebar in basement walls; 
Start: 2-27-13; 
Finish: 2-27-13. 

Source: GAO. 

[End of figure] 

The finish-to-start link in figure 19 between "form basement walls" and 
"install rebar in basement walls" dictates that forming walls must 
finish before installing rebar can begin. Suppose the relationship also 
has a 2-day lead that states that the installation of rebar should 
begin 2 days before forming the basement walls is finished. However, 
installing rebar takes only 1 day, which means the installation of 
rebar in the basement walls will actually finish before the basement 
walls are formed. This causes a conflict in logic between the lead and 
the finish-to-start relationship. Moreover, because the lead causes 
rebar installation to finish a day earlier than the forming of basement 
walls, an artificial day of float may be introduced into the sequence 
of activities. 

Note that the number of activities affected by a lag or lead is 
different from the total number of lags or leads in the schedule. The 
total is useful for determining the extent to which updating the 
schedule will be affected by the use of lags and leads. As stated 
above, a major disadvantage of lags and leads is that they are static; 
if they are prevalent in the schedule, the update process requires 
significant manual effort and becomes time consuming and prone to 
error. 

The total number of predecessor relationships with a lag or lead 
provides a scheduler with a sense of how cumbersome the update process 
will be. If the schedule is not well maintained, its utility as a 
dynamic management tool will be greatly reduced and activity dates may 
be artificially delayed by a static lag or lead. For this reason, it is 
also worthwhile to understand the number of activities that will 
actually be affected by such a situation. For example, if an activity 
has two predecessors, each with a lag, only one predecessor will drive 
the outcome of the activity. Thus, while two activities, i and j, have 
lags in this scenario, only one activity's schedule date, k, would be 
affected as an out-of-date lag. This situation is illustrated in figure 
20, where "L" denotes a lagged successor. 

Figure 20: Enumerating Lags: 

[Refer to PDF for image: illustration] 

I connects to K through path L; 
J connects to K through path L. 

Source: GAO. 

[End of figure] 

Path Convergence: 

Several parallel activities joining with a single successor activity is 
known as path convergence. Path convergence can represent an 
unrealistic plan because it implies the need to accomplish a large 
number of activities on time before a major event can occur as planned. 
The convergence of many parallel activities into a single successor--
also known as a "merge point"--causes problems in managing the 
schedule.[Footnote 11] 

These points should be a key program management concern because risk at 
the merge point is multiplicative. That is, because each predecessor 
activity has a probability of finishing by a particular date, as the 
number of predecessor activities increases, the probability that the 
successor activity will start on time quickly diminishes to zero. Path 
convergence is the basis of "merge bias," which we discuss in detail in 
Best Practice 8. 

Because of this risk effect, activities with a great many predecessors 
should be examined to see if they are needed and if alternative logic 
can be used to link some predecessors to other activities. Often paths 
converge because major milestones are used to "tie off" many 
predecessor activities, some of which may be only marginally related to 
the actual milestone. In this case, predecessor activities should be 
examined for available float. If many of the predecessors leading to 
the merge point have large amounts of float available, then convergence 
may not be an immediate issue. However, if several predecessor 
activities are determining the date of the successor event, then the 
workflow plan should be reexamined for the realism of performing many 
activities in parallel with the available resources. 

The appropriate number of converging activities varies by project. A 
reasonable number of parallel activities for a large project will not 
be the same as for a small project. Because most work is performed 
serially, the majority of the schedule activities should have F-S 
relationships, resulting in a waterfall approach to the work. An 
excessive number of parallel relationships can indicate an overly 
aggressive or unrealistic schedule. 

Best Practices Checklist: Sequencing All Activities: 

* The schedule contains complete network logic between all activities 
so that it can correctly forecast the start and end dates of activities 
within the plan. 

* The majority of relationships within the detailed schedule are 
finish-to-start. 

* Except for the start and finish milestones, every activity within the 
schedule has at least one predecessor and at least one successor. 

* Any activity that is missing predecessor or successor logic--besides 
the start and finish milestones--is clearly justified in the schedule 
documentation. 

* The schedule contains no dangling logic. That is, 

- Each activity (except the start milestone) has an F-S or S-S 
predecessor that drives its start date. 

- Each activity (except the finish milestone and deliverables that 
leave the project without subsequent effect on the project) has an F-S 
or F-F successor that it drives. 

* The schedule does not contain start-to-finish logic relationships. 

* Summary activities do not have logic relationships because the logic 
is specified for activities that are at the lowest level of detail in 
the schedule. 

* Instead of SNET constraints, conditions of supply by an outside 
vendor or contractor are represented as actual activities in the 
schedule. 

* Date constraints are thoroughly justified in the schedule 
documentation. Unavoidable hard constraints are used judiciously and 
are fully justified in reference to some controlling event outside the 
schedule. 

* Lags are used in the schedule only to denote the passage of time 
between two activities. 

* Instead of lags and leads, every effort is made to break activities 
into smaller tasks to identify realistic predecessors and successors so 
that logic interfaces are clearly available for needed dependency 
assignments. 

* If included in the schedule, lags and leads are used judiciously and 
are justified by compelling reasons outside the schedule in the 
schedule documentation. 

* The schedule is assessed for path convergence. That is, activities 
with many predecessors have been examined to see whether they are 
needed and whether alternative logic can be used to link some 
predecessors to other activities. 

[End of Best Practice 2] 

Best Practice 3: Assigning Resources to All Activities: 

[Side bar: Best Practice 3: The schedule should reflect the resources 
(labor, materials, overhead) needed to do the work, whether they will 
be available when needed, and any refunding or time constraints. End 
of side bar] 

A resource is anything required to perform work. Because resource 
requirements directly relate to an activity's duration, assigning 
resources to activities ensures that they will be used to determine 
realistic and rational activity durations. Because labor, material, 
equipment, burdened rates, and funding requirements are examined to 
determine the feasibility of the schedule, resources provide a 
benchmark of the project's total and reporting-period costs. 

The process of assigning labor, materials, equipment, and other 
resources to specific activities within the schedule is known as 
loading resources. A resource-loaded schedule therefore implies that 
all required labor and significant materials, equipment, and other 
costs are assigned to the appropriate activities within the schedule. 
The schedule should realistically reflect the resources that are needed 
to do the work and--compared to total available resources--should 
determine whether all required resources will be available when they 
are needed. Loading resources is the first step in allocating the 
expected available resources to a schedule at the time an activity is 
planned to be performed. To determine whether resources are adequate, 
they must be examined by time period. To represent the total and 
reporting-period costs of the project, all resources (including 
subcontracts and LOE management resources) must be included. A schedule 
that has not been reviewed for resource issues is not credible. 

Resources, Effort, and Duration: 

The amount of available resources, whether labor or nonlabor, affects 
estimates of work and its duration, as well as resources that will be 
available for subsequent activities. Labor is, of course, a human 
resource; nonlabor resources can be subcontracts, consumable material, 
machines, and other purchased equipment. Labor and equipment are 
measured in units of time such as hours and days; material resources 
are measured in cubic feet, tons, pallets, or the like. Resources can 
depend on time--generally labor but also equipment or space rented per 
period--meaning that they increase in cost as time runs longer. 
Alternatively, they can be time-independent in the sense that they cost 
the same regardless of time--for example, material costs. Some 
activities use both labor and nonlabor resources. 

Labor Resources: 

In general, the amount of work, in person-days, required to complete an 
activity is equal to the duration of the activity multiplied by the 
number of labor resource units assigned. Stated another way, the 
duration of an activity is directly related to how much work is 
necessary to complete the activity divided by the number of people 
available to perform the work. However, this does not necessarily mean 
that doubling the available resources will halve the activity's 
duration. 

If the amount of work is known, along with an estimate of the number of 
people available to perform that work, then its duration can be 
estimated, along with efficiency levels, risk, and other external 
factors. That is, when the amount of work is fixed, the number of labor 
resources directly affects its duration. For example, if an activity is 
estimated to require 16 hours of work (2 person-days) and only one 
full-time equivalent (FTE) employee is available to perform the 
activity within an 8-hour day, then the duration of the activity will 
be 2 days. If two FTEs are available to perform the activity, then the 
duration will be 1 day; if one FTE is available for only 50 percent of 
the time, the duration will be 4 days. Productivity or efficiency 
factors can be applied to specific resources to account for standard 
output rates, personal experience, or historical productivity. For 
example, a specific set of individuals in a resource group may have 
more experience performing an activity than other individuals in the 
same group. Productivity will vary depending on the type of work--for 
example, trees planted per day or drawings produced per week. Workflow 
will also affect productivity: a steady flow of work tends to increase 
efficiency, while a discontinuous flow will introduce inefficiencies. 

The duration of other types of activities known as fixed-duration 
activities is not affected by the number of people assigned to perform 
the work. For example, the number of days required for testing a 
satellite in a vacuum chamber will be the same regardless of how many 
engineers are assigned to monitor the testing. Likewise, the duration 
of a management offsite meeting does not depend on the number of people 
who attend. In the case of fixed-duration activities, labor resource 
information is nonetheless vital because the number of people directly 
affects the work required for the activity and, therefore, the cost. 
For example, five engineers assigned to a 2-day fixed-duration software 
coding activity will incur 10 person-days of work at whatever labor 
rate each engineer earns. 

Nonlabor Resources: 

Significant material and equipment resources should also be captured 
within the schedule. Material resources are consumables and other 
supplies that are used to complete the project. Equipment resources may 
be items such as machines that are installed during the project, which 
become part of the completed project at turnover. Other equipment 
resources facilitate project execution but are neither consumed nor 
turned over in the final product delivery--for example, a rented crane. 

Like labor resources, nonlabor resources can be fixed or variable. 
Fixed nonlabor resources do not vary with an activity's duration; that 
is, the same amount of resource is consumed regardless of the 
activity's duration. For example, 100 square feet of wood flooring 
might be needed for a floor, regardless of whether the floor 
construction takes 2 or 3 days to complete. Variable nonlabor resources 
may include equipment used during the project such as cranes or testing 
machines that are not consumed but provide services that vary with the 
duration of an activity. For example, the longer a testing activity 
runs, the longer the test equipment is in use. 

Rolling Wave Planning: 

As discussed in Best Practice 1, a comprehensive IMS should reflect all 
activities of a program and recognize that uncertainties and unknown 
factors in schedule estimates can stem from, among other things, 
limited data. As such, a schedule incorporates different levels of 
detail depending on the information available at any point in time. 
That is, near-term effort will be planned in greater detail than long-
term effort. Detailed activities within a low-level schedule represent 
work packages, or detailed tasks, that are typically 4 to 6 weeks long. 
These detail activities reflect near-term, well-defined effort, 
typically within 6 months to a year of the current date. Effort beyond 
the near term that is less well defined is represented within the 
schedule as planning packages. 

Although some schedulers insist on scheduling detailed activities for 
the entire project, it is often difficult to forecast detailed work 
clearly beyond 9 to 12 months. Planning packages summarizing work in 
the distant future can be used as long as they are defined and 
estimated as well as possible. Planning packages are planned at higher 
levels such that a single activity may represent several months of 
effort, generic work to be accomplished by a trade or resource group, 
or even a future contract or phase. 

As time passes and future elements of the program become better 
defined, planning packages are broken down into detailed work packages. 
This incremental conversion of work from planning packages to work 
packages is commonly known as "rolling wave" planning. Rolling wave 
planning continues for the life of the program until all work has been 
planned in detail. Rolling wave planning with portions of effort that 
align to significant program increments, blocks, or updates is known as 
"block planning." A best practice is to plan the rolling wave to a 
design review, test, or other major milestone rather than to an 
arbitrary period such as 6 months. Moreover, detail should be included 
in the schedule whenever possible. That is, if portions of far-term 
effort are well defined, they should be included in the IMS as soon as 
possible. However, care should be taken not to detail ill-defined far-
term effort so soon as to require constant revision as time progresses. 

While planning packages represent far-term effort that is not yet 
planned in detail, each planning package must still be traceable to WBS 
elements within the IMS. Moreover, planning packages should be 
logically linked within the schedule to create a complete picture of 
the program from start to finish and to allow the monitoring of a 
program's critical path. As durations and resource assignments are 
refined over time, so too is the detailed sequence of activities. 

Loading Activities with Resources: 

Loading resources into a schedule helps management compute total labor 
and equipment hours, calculate total project and per-period cost, 
resolve resource conflicts, and establish the reasonableness of the 
plan. A schedule without resources implies an unlimited number and 
availability of resources. Fully loading the schedule with resources, 
including materials, equipment, direct labor, overhead, and level of 
effort activities, provides the basis for the performance measurement 
baseline (PMB), which can be used to monitor the project using earned 
value management (EVM).[Footnote 12] Milestones should never be 
assigned resources because they have no duration. Assigning resources 
to milestones is an unfortunate common practice that greatly distorts 
resource hours worked. 

Resource assignments and duration estimates will vary in detail 
depending on the level of detail of activities in the schedule. Work 
scheduled for the near term should account for specific resource 
availability and productivity. When a schedule is fully resource 
loaded, budgets for direct labor, overhead, and material are assigned 
to both work and planning packages so that total costs to complete the 
program are identified at the outset. 

In addition, the level of detail for resource loading should be based 
on the information available to management as well as the purpose of 
the schedule. Detail schedules used for day-to-day management should 
include detail resource information, while summary schedules with 
higher-level resource information may be more appropriate for analyses 
such as an integrated cost-schedule risk analysis. Non-LOE resources 
should not be assigned to summary activities because summary durations 
depend on the activities contained within them. However, lower-level 
resource information can be rolled up to the summary levels for 
reporting purposes. 

Activity owners responsible for managing the day-to-day effort and the 
most experienced team members who will be performing the work are the 
best source of resource estimates. Activity owners must be able to 
explain the logic behind their resource estimates; if there is no 
justification for allocating and assigning resources, the schedule will 
convey a false accuracy. Estimated resources within the schedule should 
also reconcile with the life cycle cost estimate (LCCE). The 
assumptions for resources and related activity cost should be the same 
as those that are used in estimating activity duration. The basis of 
estimate (BOE) is the connection between cost and time and should be 
kept up to date as assumptions change. If durations, resources, or 
productivity rates change, the cost is also likely to change, and they 
need to be coordinated. Both the schedule and the LCCE should be 
thoroughly documented to include underlying resource assumptions for 
the entire estimated scope of work. 

In terms of labor resources, a schedule can be loaded at different 
levels of detail, each level having its advantages and disadvantages. 
In some cases, a program may rely on a centralized resource pool, 
previously approved by management, that must be used as the detailed 
work schedules are populated. Assigning labor resources to activities 
at the name level ("Bob Smith Jr.") is specific and allows management 
to track the effort of individual people and to make sure they are not 
overallocated. This is particularly useful for tracking the assignments 
and responsibilities of subject matter experts whose absence or 
overallocation could delay an activity. However, assigning individual 
names to activities requires constant updating and shuffling of 
assignments for vacations, sick leave, and the like and reduces 
flexibility in resource leveling. Individual name assignments may also 
require specific labor rates, although planners may simply enter the 
average rate for each employee to avoid this issue. 

Assigning resources at the organizational level such as "agency test 
department" or "production facility staff" is quicker than assigning 
individual names to activities. However, organizations include multiple 
skill sets, which complicates allocating and assigning specific skill 
sets to activities. Assigning resources by skill set ("software 
engineer level 3") may be more time consuming than organization-level 
assignments but is a compromise option for resource loading to avoid 
both too much and too little detail. Skill sets obscure specific labor 
rates, parse individuals skills, and allow for management's easy 
rearrangement of individual personnel within skill sets. 

Resource information can be stored within the schedule files or it can 
be stored externally in separate software. If resource information is 
stored and maintained outside the schedule, a clear process must exist 
for integrating information between the schedule and the resource 
management software. Specifically, managing resources outside the 
schedule requires a documented process by which resource assignments 
are fed back into the schedule so that it reflects the resolution of 
resource issues conducted separately. A best practice is to store the 
resource information in the schedule; otherwise, resource leveling will 
be difficult. Case study 6 provides an example of a fully resource-
loaded schedule and its alignment to the program budget baseline. 

Case Study 6: Assigning Resources to Activities, from Nuclear 
Nonproliferation, GAO-10-378: 

GAO assessed the extent to which the project schedule for the 
Department of Energy's Savannah River Waste Solidification Building 
used best practices. In addition to fully reflecting both government 
and contractor activities, the sequencing of 95 percent of the 
remaining 2,066 activities, and the establishment of a credible 
critical path driven by the logic of the schedule, the project's 
schedule included assigned labor and material resources that accounted 
for 98 percent of the project's $344 million cost baseline. 

GAO, Nuclear Nonproliferation: DOE Needs to Address Uncertainties with 
and Strengthen Independent Safety Oversight of Its Plutonium 
Disposition Program, [hyperlink, 
http://www.gao.gov/products/GAO-10-378 (Washington, D.C.: March 26, 
2010). 

Once the schedule is resource loaded, total resources in the schedule 
should be crosschecked with the program budget and contractual cost 
constraints. Crosschecking can be performed at the summary level by 
rolling up lower levels of the schedule to key high-level milestones. 
The cumulative resources and budget can be visualized graphically as a 
series of peaks and troughs of resource and funding availability. 
Resource peaks should be examined for feasibility regarding the 
available budget, availability of resources, and timeliness. For 
example, scheduled activities may call for 70 software engineers, but 
actual facility or administrative constraints may prevent the staffing 
of more than 40 software engineers simultaneously. Peaks in the 
resource profile may also occur at incorrect times. For instance, 
resources should peak before major decision points in the program. 

If the cumulative overlay of resources against major milestones shows 
resource peaks just beyond major milestone points, resources may have 
to be reallocated. In addition, managers and planners should assess 
whether "bow waves" exist in the high-level resource allocation 
profile. Bow waves represent the need for large amounts of resources 
near the end of work streams to finish deferred or delayed work in 
order to complete the project on time. Often the number of resources 
and funding required at the peak of a bow wave are unrealistic. 

The benefits of using a schedule to reallocate resources can be shown 
with the example of house construction in figure 21. 

Figure 21: A Profile of Expected Construction Labor Costs by Month: 

[Refer to PDF for image: vertical bar graph: some vaules are approximated] 

Labor Cost: 
January: $5,200; 
February: $27,000; 
March: $36,730; 
April: $60,400: 
Carpenters and Bricklayers: $26,000; 
Other Labor: $22,000; 
Concrete: $6,000; 
Landscape: $7,000; 
May: $24,050; 
June: $25,510. 

Source: GAO. 

[End of figure] 

The expected labor costs peak severely in April, corresponding with a 
surge in carpentry and bricklaying work, as well as final grading, 
landscaping, and pouring concrete for the patio and sidewalks once the 
exterior house work is complete. The labor budgets then drop 
substantially for May and June, creating potential cash flow issues for 
the owners or the general contractor. However, final grading and 
landscaping need be completed only by the time of the owner's 
walk-through, not scheduled until early July. Those activities have 
over 40 days of total float available; that is, delaying the final 
landscaping and patio and sidewalk pouring activities can be delayed 
until May without delaying the owner's acceptance. This shifts nearly 
$10,000 in labor costs from April to May, easing the budget concerns in 
April and allowing work and cash flow to ramp down smoothly into June 
(see figure 22). 

Figure 22: A Smoothed Profile of Expected Construction Labor Costs by 
Month: 

[Refer to PDF for image: vertical bar graph: some values are approximated] 

Labor Cost: 

January: 
Smoothed profile: $5,200; 
Original profile: $5,200. 

February: 
Smoothed profile: $27,000; 
Original profile: $32,200. 

March: 
Smoothed profile: $36,730; 
Original profile: $68,930. 

April: 
Original profile: $60,400: 
Carpenters and Bricklayers: $26,000; 
Other Labor: $22,000; 
Concrete: $6,000; 
Landscape: $7,000; 
Smoothed profile: $129,330. 

May: 
Smoothed profile: $24,050 (including Landscaping ($7,000) and Concrete ($6,000); 
Original profile: $15,380. 

June: 
Smoothed profile: $25,510; 
Original profile: $17,890. 

Source: GAO. 

[End of figure] 

Resource assignments should also be carefully reviewed for realism in 
light of assumptions made by the scheduling software. Depending on how 
resources are assigned and durations are estimated, the scheduling 
software may ignore resource overallocations by allowing assignments to 
continue beyond resource availability. For example, if only 3 
carpenters are available to perform cabinetry work but 4 are assigned 
to the activity, the software may allow 4 carpenters and simply mark 
the activity as overallocated. In reality, a fourth carpenter is not 
available and the duration of the activity would have to be extended. 

While resource loading the entire schedule may be a difficult exercise, 
it encourages management to assess the amount of resources available 
and encourages the discussion of difficult questions early in program 
planning. If the resource-loaded schedule alerts decision makers that 
the available resources will not suffice to execute the work on time as 
planned, management can begin negotiating for additional resources 
early in the program. Finally, linking available resources to activity 
durations may expose infeasible durations to scrutiny or show 
opportunities to reduce durations with the application of more 
resources. See Best Practice 4 for more information on establishing 
durations for activities. 

Resource Leveling: 

Resource leveling adjusts the scheduled start of activities or the work 
assignments of resources to account for their availability. It is used 
primarily by the organization that has control of the resources to 
smooth spikes and troughs in resource demands created by the sequencing 
of activities in the schedule network. Frequent peaks and troughs in 
resource requirements represent their inefficient use because frequent 
mobilization and demobilization of resources is disruptive. For 
example, a schedule that requires 30 software engineers one week, none 
the next week, and 25 the next is disruptive and inefficient. A 
resource plan that is more manageable should be sought. 

Leveling can be as simple as reassigning work from overallocated 
resources to underallocated resources or delaying the start date of 
activities until the resources required to perform the effort are 
available. Leveling may also develop into a complex trade-off between 
the required duration of the plan and the availability of myriad 
resources. Resource leveling can be performed automatically with 
scheduling software or manually by management and planners or both. 
Whatever the method, the goal of resource leveling is to finish the 
project on time or early, if possible, within a level of resources 
realistically expected to be available throughout the entire plan. 
Leveling resources allows management to identify "critical resources"-
-that is, resources that will delay the project finish date if they are 
not available for specific activities. Resource leveling is ideally 
integrated into scheduling and updating to ensure that the best 
possible tradeoffs are made between resources and time and to ensure 
that the schedule remains credible throughout its lifespan. 

Typically, the activities that are delayed by resource leveling will be 
those with the most free float available and the least amount of 
assigned resources.[Footnote 13] Resource leveling by shifting 
activities with free float minimizes the effect of the delayed 
activities on the project as a whole and minimizes the number of 
resources that must be reassigned work. Given the amount of float 
available in the schedule and the original assignment of resources, 
resource leveling can have little to no effect on a schedule, or it can 
severely delay the forecasted end date of the project. Resource 
leveling should be used only to reallocate resources to reduce spikes 
and troughs by absorbing available float. In other words, resource 
leveling should never delay a completion date. If the outcome of 
resource leveling is a delayed completion date, then resources are an 
inevitable constraint, and an alternative approach to the project plan 
is needed. If resources are assigned to activities realistically 
according to the sequence of planned activities and no resources are 
overallocated, then the resource-leveled scheduled will be the same as 
the original CPM schedule. 

An example of resource leveling is given in figures 23 and 24. Figure 
23 shows the sequence of events for selecting subcontractors for house 
construction, as scheduled according only to predecessor-successor 
logic. Once the owners select a general contractor, they can then 
confer with the general contractor to select the subcontractors: 
surveyor, excavator, concrete supplier, plumber, electrician, and the 
like. Once an individual subcontractor is selected, the owners and 
general contractor can then select and approve the necessary material. 
For instance, after selecting a plumber, the owners and general 
contractor can select the plumbing fixtures. From a network 
perspective, the selection of subcontractors can all happen at the same 
time once the general contractor is selected by the owner, and once 
each subcontractor is selected, the respective materials can be 
selected. 

Figure 23: Resource Overallocated in a Correctly Sequenced Network: 

[Refer to PDF for image: illustration of Gantt chart] 

Task name: Choose and hire concrete contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve concrete equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire plumber; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve plumbing equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire electrician; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve electrical equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose an HVAC contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve HVAC equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire roofer; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve roofing equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire insulating contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve insulating equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire drywall and painting contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve drywall and painting equipment and 
materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire ceramic tile contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Select and approve tile equipment and materials; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire surveyor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Choose and hire excavator; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Subcontractors selected and equipment and materials 
approved; 
Start: 1-14-13; 
Finish: 1-14-13. 
   
Thursday (1/10): 
Owners (2): 8 hours; 
General contractors (1): 0. 

Friday (1/11): 
Owners (2): 80 hours; 
General contractors (1): 20 hours. 

Monday (1/14): 
Owners (2): 96 hours
General contractors (1): 40 hours. 

Total hours: 
Owners (2): 184 hours
General contractors (1): 60 hours. 

Source: GAO. 

[End of figure] 

However, once resources are assigned to the activities, it quickly 
becomes apparent that the plan is not feasible. The table below figure 
23 gives the total hours necessary for two owners and one general 
contractor (GC). 

The resource leveling of these activities is straightforward, because 
the owners and the general contractor have time available to select 
subcontractors while they wait for approval of the general construction 
permit. In fact, the "subcontractors selected and equipment and 
materials approved" milestone has nearly 18 days of free float. This 
allows management to spread the selection of subcontractors over the 
next several weeks without affecting activities succeeding the 
subcontractor selection milestone. Figure 24 shows the results of 
manual resource leveling for these activities. 

Figure 24: Resource Leveling in a Correctly Sequenced Network: 

[Refer to PDF for image: illustration of Gantt chart] 

Task name: Choose and hire general contractor; 
Start: 1-11-13; 
Finish: 1-11-13. 

Task name: Choose and hire concrete contractor; 
Start: 1-15-13; 
Finish: 1-15-13. 

Task name: Select and approve concrete equipment and materials; 
Start: 1-16-13; 
Finish: 1-16-13. 

Task name: Choose and hire plumber; 
Start: 1-17-13; 
Finish: 1-17-13. 

Task name: Select and approve plumbing equipment and materials; 
Start: 1-18-13; 
Finish: 1-18-13. 

Task name: Choose and hire electrician; 
Start: 1-22-13; 
Finish: 1-22-13. 

Task name: Select and approve electrical equipment and materials; 
Start: 1-23-13; 
Finish: 1-23-13. 

Task name: Choose an HVAC contractor; 
Start: 1-24-13; 
Finish: 1-24-13. 

Task name: Select and approve HVAC equipment and materials; 
Start: 1-25-13; 
Finish: 1-25-13. 

Task name: Choose and hire roofer; 
Start: 1-28-13; 
Finish: 1-28-13. 

Task name: Select and approve roofing equipment and materials; 
Start: 1-29-13; 
Finish: 1-29-13. 

Task name: Choose and hire insulating contractor; 
Start: 1-30-13; 
Finish: 1-30-13. 

Task name: Select and approve insulating equipment and materials; 
Start: 1-31-13; 
Finish: 1-31-13. 

Task name: Choose and hire drywall and painting contractor; 
Start: 2-1-13; 
Finish: 2-1-13. 

Task name: Select and approve drywall and painting equipment and 
materials; 
Start: 2-4-13; 
Finish: 2-4-13. 

Task name: Choose and hire ceramic tile contractor; 
Start: 2-5-13; 
Finish: 2-5-13. 

Task name: Select and approve tile equipment and materials; 
Start: 2-6-13; 
Finish: 2-64-13. 

Task name: Choose and hire surveyor; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Choose and hire excavator; 
Start: 1-14-13; 
Finish: 1-14-13. 

Task name: Subcontractors selected and equipment and materials 
approved; 
Start: 2-6-13; 
Finish: 2-6-13. 
   
Week of 1/6: 
Owners (2): 8 hours; 
General contractors (1): 0. 

Week of 1/13: 
Owners (2): 56 hours; 
General contractors (1): 18 hours. 

Week of 1/20: 
Owners (2): 40 hours
General contractors (1): 16 hours. 

Week of 1/27: 
Owners (2): 40 hours
General contractors (1): 12 hours. 

Week of 2/3: 
Owners (2): 40 hours
General contractors (1): 14 hours. 

Total hours: 
Owners (2): 184 hours
General contractors (1): 60 hours. 

Source: GAO. 

[End of figure] 

The activities are now spread over 5 weeks, leaving the owners and 
general contractor busy but not overallocated. This effort profile also 
frees the general contractor to work with other clients. Finally, the 
leveling of the subcontractor selection activities is done within the 
available free float, which does not affect either activities beyond 
the subcontractor selection milestone or the original critical path. 

Because changes to the schedule from limited resource availability can 
alter float and critical path calculations, it is important that 
changes to resolve the resource conflicts be thoroughly documented and 
that everyone understands them.[Footnote 14] Output from automatic 
resource-leveling routines should always be carefully examined by 
planners and management and tempered or adjusted where necessary. 
Automatic leveling may produce inefficient output, such as delaying 
activities if resources are partially available and, thus, prevent 
activities from being partially accomplished while the project waits 
for the full complement of resources to become available. 

It is important to note that decisions made from incorrect data 
assumptions will themselves be incorrect. This is especially true if a 
CPM schedule is being overridden by resource-leveling decisions based 
on summary-level or incorrect resource assumptions. Resource leveling 
should occur only on detailed schedules that include detailed resource 
estimates supported by historical data and sound estimating 
methodologies. Without specific resource assignments, effects and costs 
cannot be accurately estimated and tracked. If a schedule is resource 
leveled, it is important to check the date of the last leveling against 
the date of the last changes to resources and resource availability. 
This will ensure that actual resource assignments have been aligned 
with the proposed leveling in the model. 

Resource leveling should never be applied to summary schedules or when 
resources are specified at such a summary level that the concept of 
availability cannot be applied. Incorrect resource assumptions (usually 
in the form of unwarranted optimism) will lend unreasonable credence to 
a resource-leveled schedule, and the resulting leveled schedule will 
convey a false sense of precision and confidence to senior decision 
makers. 

Best Practices Checklist: Assigning Resources to All Activities: 

* The amount of available resources, whether labor or nonlabor, affects 
estimates of work and its duration, as well as the availability of 
resources for subsequent activities. 

* The schedule should realistically reflect the resources that are 
needed to do the work and--compared to total available resources--
should determine whether all required resources will be available when 
they are needed. 

* Resources are either labor or nonlabor, where labor refers to humans 
and nonlabor can refer to subcontracts, consumable material, machines, 
and other purchased equipment. Resources are identified as fixed or 
variable. 

* Significant material and equipment resources are captured within the 
schedule along with other equipment resources that facilitate the 
project. 

* Budgets for direct labor, overhead, and material are assigned to both 
work and planning packages so that total costs to complete the program 
are identified at the outset. 

* If EVM is used to monitor the program, the fully loaded schedule, 
including materials, equipment, direct labor, overhead, and LOE 
activities, is the basis for the PMB. 

* Activity owners are able to explain the logic behind their resource 
estimates. 

* The same assumptions that formed resource estimates for the LCCE are 
applied to the estimated resources loaded into the schedule and are 
documented in the BOE. Underlying resource assumptions for the entire 
estimated scope of work are documented in the schedule baseline 
document at an appropriate level of detail. 

* Resource information is stored in the schedule in the form of 
assignments. If resource management is performed outside the schedule, 
a documented process feeds resource assignments back into the schedule 
so that it reflects the resolution of resource issues conducted 
separately. 

* Once the schedule is resource loaded, total resources in the schedule 
are crosschecked with the program budget and contractual cost 
constraints. 

* Resource peaks are examined for the feasibility of the available 
budget, the availability of resources, and the timeliness of the peaks. 

* If the cumulative overlay of resources against major milestones shows 
resource peaks just beyond major milestone points, resources may have 
to be reallocated. 

* Managers and planners have assessed whether bow waves exist in the 
high-level resource allocation profile. 

* Resource leveling has been performed--that is, the scheduled time of 
activities or the assignment of resources has been adjusted to account 
for the availability of resources. 

* In general, activities that are delayed through resource leveling 
have the greatest free float available and the least amount of 
resources assigned. 

* If critical resources delay the entire project, changes to resolve 
the resource conflicts are thoroughly documented in the schedule 
narrative and understood by all. 

* Planners and managers carefully examine and temper or adjust where 
necessary. 

* Resource leveling occurs only on detail schedules that include 
detailed resource estimates supported by historical data and sound 
estimating methodologies. 

[End of Best Practice 3] 

Best Practice 4: Establishing the Duration of All Activities: 

Durations: 

[Side bar: Best Practice 4: The schedule should realistically reflect 
how long each activity will take. When the duration of each activity 
is determined, the same rationale, historical data, and assumptions 
used for cost estimating should be used. Durations should be 
reasonably short and meaningful and allow for discrete progress 
measurement. Schedules that contain planning and summary planning 
packages as activities will normally reflect longer durations until 
broken into work packages or specific activities. End of side bar] 

Duration is the estimated length of time required to complete an 
activity--the time between its start and finish. Durations are 
expressed in business units, such as working days, and are subject to 
the project calendar. For example, for a standard 40-hour 5-day work 
week, the duration of an activity that starts on Thursday and ends on 
Tuesday will be 4 working days, even though it spans 6 calendar days. 
If the activity is assigned to a 7-day workweek calendar, then the 
activity will start Thursday and end Sunday. Multiple calendars can be 
created to accommodate activities with different work schedules. 

The definition of duration is different from the definition of work 
(work is also referred to as effort in some scheduling software). For 
example, if a painting activity is scheduled for 2 8-hour days and two 
full-time painters are assigned to the job, the duration of the 
painting activity is 2 days, but the effort associated with painting is 
32 hours (that is, two 8-hour employees for 2 days). Duration is 
directly related to the assigned resources and estimated amount of 
required work. Best Practice 3 discusses in detail how duration, 
resource units, and effort can change in relation to one another. 

In general, estimated detail activity durations should be shorter than 
2 working months, or approximately 44 working days, for near-term 
effort. Durations should be as short as possible to facilitate the 
objective measurement of accomplished effort. It may be difficult for 
management to gauge progress on detail activity durations that are too 
long. The shorter the duration of the detail activity, up to a point, 
the more precise the measurement of accomplished effort will be. 

Planners should break long durations into shorter activities if logical 
breaks can be identified in the work being performed. If it is not 
practical to divide the work into smaller activities or insert 
intermediate milestones, justification for long durations should be 
given in the schedule baseline document. One rule of thumb is to break 
long activities into enough detail that finish-to-start logic 
relationships can be identified. Moreover, shorter durations are needed 
for areas of work associated with high cost or high risk. 

However, durations that are too short and durations that are too long 
should be balanced. Very short durations, such as 1 day or less, may 
imply that the schedule is too detailed and require more frequent 
schedule duration and logic updates than necessary. Moreover, for a 
large number of 1-and 2-day duration activities, planners should 
recognize that people are rarely, if ever, 100 percent productive 
during an 8-hour day. An actual "pure" productive workday is 
approximately 60 to 80 percent of an 8-hour workday, because time may 
be taken up with staff meetings, phone calls, e-mails, and water cooler 
talks. Also, a long chain of 1-day activities may be assigned to one 
employee who is assumed to never get sick or take vacation. It is 
important that activity durations remain realistic. Durations should 
not be broken up simply to meet an artificial guideline. If the work 
required for the activity is estimated to span 48 or 50 days, or if 
network logic dictates a duration longer than 44 days for some other 
reason, then the activity duration should reflect this reality. 

Certain activities within schedules will naturally span more than 44 
working days. For summary-level schedules, often created before 
detailed engineering is complete, durations might be longer than 44 
days and lags might be more common. Within detailed schedules, LOE 
activities such as management and other oversight activities depend on 
the duration of the underlying discrete effort, so they span complete 
phases or even the entire project. LOE activities should be clearly 
marked in the schedule and should never appear on a critical path. 

In addition, planning packages representing undefined future work can 
be several months long. However, the duration of the planning packages 
must be estimated and they should still be integrated into network 
logic. 

Finally, all activity durations in the schedule should be defined by 
the same time unit (hours, days, weeks) to facilitate calculating and 
monitoring the critical path. Days are the preferred time unit. 

Estimating Durations: 

Activity durations should be realistic to ensure that forecasted 
project delivery dates and critical paths are reliable. Activity 
durations are often mistakenly determined solely by the time available 
to complete the project. However, activity durations should be based on 
the effort required to complete the activity, the resources available, 
and resource efficiency or productivity. This ensures that the dates in 
the schedule are determined by the project plan logic and durations 
rather than wishful thinking or estimates that are constructed to meet 
a particular finish date objective. 

If the estimated durations and supporting schedule network logic do not 
support the target deliverable date, then the project manager and the 
teams must discuss how to realistically compress the schedule, perhaps 
by adding more resources, adjusting scope, or setting a later finish 
date.[Footnote 15] 

Activity durations should be estimated under normal conditions, not 
under optimal or "success-oriented" conditions or padded durations. 
"Normal conditions" for estimated durations imply that duration 
estimates do not contain padding or buffer for risk. Rather, risk 
buffers should be introduced as separate schedule contingency 
activities to facilitate proper monitoring by management, as discussed 
in Best Practice 8. Durations also should not be unrealistically short 
or arbitrarily reduced by management to meet a project challenge. 

Activity owners should be responsible for estimating durations for 
their activities. Activity owners may have experience from similar 
activities on past projects that can help them estimate the duration 
estimate of the current activity. If the scheduler creates estimates, 
it is important that the underlying assumptions are acceptable to the 
activity owners. 

All assumptions related to activity duration estimates should be 
documented at an appropriate level of detail, such as recording the 
methodology used to create the estimate (for example, parametric 
analysis of historical data or analogy to similar effort) and all 
supporting historical or analogous data. Documenting the basis for 
duration facilitates the communication of expectations between activity 
owners and decision makers and helps in estimating future analogous 
activity durations. Greater activity detail might be necessary when 
additional risk penetration and analysis will help management 
understand and address the implications of risk and uncertainty. 

Finally, activity duration estimates for a WBS element in the schedule 
should clearly map to and correspond with the basis of the cost 
estimate for the same WBS element. For example, assumptions for the 
number of FTE workers underlying the cost estimate for a WBS element 
should also underlie the duration estimates for the WBS element in the 
schedule. 

As discussed in Best Practices 1 and 3, a comprehensive IMS reflects 
all activities of a program yet incorporates different levels of 
detail, depending on the information available at any point in time. 
Detailed activities reflect near-term, well-defined effort while less 
well-defined effort beyond the near term is represented within the 
schedule as planning packages. Resource assignments and duration 
estimates will vary in detail concordant with the level of detail of 
activities in the schedule. The durations of detail activities within a 
low-level schedule represent work packages that are typically 4 to 6 
weeks long. These duration estimates should be related to the amount of 
work required, specific resource availability, and resource 
productivity. Long-term planning packages naturally have less-accurate 
resource availability and productivity information from which to 
estimate durations because they can be several months or years long. 
Estimates for the durations of planning packages are most likely to be 
based on analogies to historical projects, planners' experience, or 
standard productivity rates. 

Calendars: 

Calendars in schedules specify valid working times for resources and 
activities. Typically, resources are assigned to calendars to define 
their availability. The availability of a resource in turn affects the 
dates and elapsed duration of the activity to which it is assigned. 
Activities should be directly tied to task calendars, which will define 
the valid times the activity can be worked. Calendars are defined by 
the number of workdays per workweek as well as the number of hours 
available each workday. Special nonworkdays, known as exceptions, are 
defined in resource and activity calendars. Holidays and plant shutdown 
periods are examples of exceptions at the activity calendar level. 

As we learned in Best Practice 2, the proper use of resource and task 
calendars usually precludes the need for soft constraints in schedules. 
For example, an SNET constraint may be used to prevent a testing 
activity from beginning too soon while the testing facility is in use 
for an unrelated project. Instead of an SNET constraint, however, the 
test facility should be defined as a resource within the schedule and 
assigned to a calendar whose exceptions represent days other projects 
are using the facility. If the testing facility becomes available 
sooner or later than originally planned, the scheduler need only update 
the exceptions within the testing facility resource calendar. Task 
calendars may also be employed to represent a suspension of effort. For 
example, if severe weather requires a suspension of concrete pouring, 
the activity can be assigned to a specific calendar that prevents the 
work from being performed on certain days. 

Another use for a resource calendar might be to exclude seasonal days 
from work. Outdoor construction probably cannot be conducted when the 
ground is frozen or the rain is intense. Such an activity could start 
before the rain or the freeze but would then have to continue after the 
end of the exception. A calendar that excludes November through 
February for bad weather could be assigned to all outdoor construction 
activities. Such dates are well known from many years of experience. 
Defining resource calendars in this way allows for properly scheduling 
activities automatically according to network logic. It also renders 
the SNET constraint unnecessary and eliminates the need for manual 
updates of the actual activity start date should the testing facility 
become available at a time other than planned. The automatic updating 
of the schedule will give greater confidence in float calculations and 
the derived critical paths. Resource calendars must also be adjusted 
for planned overtime--to allow a resource to work in an otherwise 
nonworking period. 

Project managers must ensure that calendars are properly defined 
because schedules will incorrectly represent the forecasted start, 
finish, and durations of planned work if resources are assigned an 
incorrect calendar. A common mistake is to allow all activities within 
a schedule to simply adhere to the default calendar within the 
scheduling software. However, a default calendar rarely has appropriate 
national holidays defined as exceptions and will not define specific 
blackout periods or related exceptions. Similarly, the general project 
calendar that would have excluded holidays still may not represent the 
work practices of all resources. For instance, a testing facility may 
work 24 hours a day while some personnel work 4 10-hour days a week. 

Additionally, if management has planned that work will be performed 7 
days a week within the schedule, it is crucial that the people assigned 
to the planned activities are aware of the schedule. Planning effort 
can prevent unexpected delays in the project and the unnecessary use of 
schedule contingency. Establishing realistic calendars will provide for 
greater accuracy of dates and may reveal opportunities to advance the 
work. 

Case study 7 shows how incorrect calendars can affect planned dates. 

Case Study 7: The Effect of Incorrect Calendars, from Transportation 
Worker Identification Credential, GAO-10-43: 

The pilot schedule for the Department of Homeland Security's 
Transportation Worker Identification Credential program included 
duration estimates for all activities, but GAO could not be certain of 
their reliability. Nearly 86 percent (259 of 302) of the activities 
identified in the schedule were assigned to a 7-day calendar that did 
not account for holidays. 

While pilot sites may normally operate on a 7-day schedule, resources 
for conducting pilot activities such as installing readers and 
associated infrastructure such as cables and computers or analyzing the 
results of pilot data may not be available on weekends. By using a 7-
day calendar, the schedule inaccurately indicated that approximately 28 
percent more workdays were available each year than actually were 
available. 

Best practices in project management include obtaining stakeholders' 
agreement with project plans, such as the schedule. Because the 
schedule was not shared with the individual pilot sites, responsible 
pilot officials had no opportunity to comment on whether the 7-day 
schedule matched available resources. Therefore, pilot participants may 
not have the resources, such as employees who can work on weekends, to 
meet pilot goals. 

If an activity is defined as taking 60 days, or approximately 2 months 
using a 7-day calendar, the reality may be that participants work a 5-
day workweek with the result that the activity takes approximately 3 
months to complete--1 month longer than scheduled. 

GAO, DHS Transportation Worker Identification Credential: Progress Made 
in Enrolling Workers and Activating Credentials but Evaluation Plan 
Needed to Help Inform the Implementation of Card Readers, [hyperlink, 
http://www.gao.gov/products/GAO-10-43] (Washington, D.C.: November 18, 
2009). 

A best practice when considering the duration of activities around the 
U.S. holiday season (Thanksgiving through New Years' Day) is to 
recognize that productivity is generally low then and that many workers 
take extended holidays during this time.[Footnote 16] 

Best Practices Checklist: Establishing the Duration of All Activities: 

* Activity durations are directly related to the assigned resources and 
estimated work required. 

* In general, estimated detailed activity durations are shorter than 2 
working months, or approximately 44 working days. 

* Durations are as short as possible, to a point, to facilitate the 
objective measurement of accomplished effort. 

* Long durations should be broken into shorter activities if logical 
breaks can be identified in the work being performed. If it is not 
practical to divide the work into smaller activities or insert 
intermediate milestones, justification for long durations is provided 
in the schedule baseline document. 

* Very short durations, such as 1 day or less, may imply a schedule 
that is too detailed and will require more-frequent updates to schedule 
duration and logic than is otherwise necessary. 

* LOE activities are clearly marked in the schedule and do not appear 
on a critical path. They are scheduled as hammock or summary 
activities, so that their durations are derived from other discrete 
activities. 

* All activity durations within the schedule are defined by the same 
time unit (hours, days, weeks). Days are preferred. 

* Planning packages representing undefined future work should be 
integrated into network logic. 

* Activity durations are estimated under normal conditions, not optimal 
or "success-oriented" conditions or padded durations. That is, "normal 
conditions" for estimated durations implies that duration estimates do 
not contain padding or buffer for risk. They should also not be 
unrealistically short or arbitrarily reduced by management to meet a 
project challenge. 

* All assumptions related to activity duration estimates are documented 
at an appropriate level of detail, such as the methodology used to 
create the estimate (for example, parametric analysis of historic data 
or opinion of a subject matter expert) and all supporting historic or 
analogous data. Activity duration estimates for a WBS element in a 
schedule should clearly map to and correspond with the basis of the 
cost estimate for the same WBS element. 

* Activity duration estimates for a WBS element in a schedule should 
clearly map to and correspond with the basis of the cost estimate for 
the same WBS element. 

* Calendars are used to specify valid working times for resources and 
activities. 

[End of Best Practice 4] 

Best Practice 5: Verifying That the Schedule Can Be Traced 
Horizontally and Vertically: 

Horizontal Traceability: 

[Side bar: Best Practice 5: The detailed schedule should be 
horizontally traceable, meaning that it should link products and 
outcomes associated with other sequenced activities. These links are 
commonly referred to as "hand-offs" and serve to verify that 
activities are arranged in the right order for achieving aggregated
products or outcomes. The integrated master schedule (IMS) should also 
be vertically traceable—that is, varying levels of activities and 
supporting subactivities can be traced. Such mapping or alignment of 
levels enables different groups to work to the same master schedule. 
End of side bar] 

Horizontal traceability demonstrates that the overall schedule is 
rational, has been planned in a logical sequence, accounts for the 
interdependence of detailed activities and planning packages, and 
provides a way to evaluate current status. Schedules that are 
horizontally traceable depict logical relationships between different 
program elements and product handoffs. Horizontally traceable schedules 
support the calculation of activity and milestone dates and the 
identification of critical and near-critical paths. 

Horizontal traceability applies to both an individual project schedule 
and the entire IMS, which may consist of multiple files. A horizontally 
traceable IMS includes complete logic from program start to program 
finish and fully integrates the entire scope of work from all parties 
in the program. Horizontal traceability ensures that forecasted dates 
within the schedule will be determined by network logic and progress to 
date rather than by artificial constraints. Any logic errors in the 
summary, intermediate, and detailed schedules will make dates between 
schedules inconsistent and will cause managers and activity owners to 
differ in their expectations. 

Detail activities, milestones, and planning packages in a horizontally 
traceable schedule are linked to one another, preferably through 
straightforward finish-to-start logic at the detailed level, to 
represent the required inputs and outputs in a planned effort. 
Milestones representing key decisions or deliverables should have each 
predecessor activity traced and validated to make certain that they are 
directly related to the accomplishment of the milestone. 

In particular, "giver/receiver" (G/R) milestones, common when multiple 
schedules are linked to form the IMS, must be clearly identified and 
logically linked between schedules. Giver/receiver milestones 
represent dependencies between schedules, such as hand-offs between 
integrated product teams, delivery and acceptance of government-
furnished equipment, and the like. For example, a production schedule 
may include "receiver" milestones from outside suppliers representing 
the delivery of material and "giver" milestones representing the 
delivery of the produced article to the testing team. Likewise, the 
test schedule will include a receiver milestone that represents the 
receipt of the production article. Key G/R milestones should be defined 
in the schedule baseline document. 

A horizontally traceable schedule will dynamically reforecast the date 
of a key milestone through network logic if activities related to 
accomplishing it are delayed longer than scheduled. For example, if the 
duration of a key milestone's predecessor activity is much extended 
relative to available float, the date of the key milestone should slip. 
Activities whose durations are extended to 100 or 200 days but have no 
effect on key milestones should be examined for unrealistic or dangling 
logic. 

Horizontal traceability is directly related to Best Practice 2, 
sequencing all activities (see case study 8). 

Case Study 8: Horizontal Traceability, from Aviation Security, 
GAO-11-740: 

Issues with sequencing logic prevented the Electronic Detection System 
acquisition schedule from being fully traceable horizontally. Extending 
the duration of some key activities had no effect on future milestone 
activities. For example, increasing the duration of the "evaluate 
pricing" activity associated with the first contract award from 40 days 
to 500 days did not effect any of the three contract award dates. 
Similarly, extending the duration of the first contracting activity, 
"request decision to move forward with purchase," from 1 day to 90 days 
had no effect on any of the three contract award dates. 

GAO, Aviation Security: TSA Has Enhanced Its Explosives Detection 
Requirements for Checked Baggage, but Additional Screening Actions Are 
Needed, [hyperlink, http://www.gao.gov/products/GAO-11-740] 
(Washington, D.C.: July 11, 2011). 

Vertical Traceability: 

Vertical traceability demonstrates the consistency of data between 
different levels of a schedule--summary, intermediate, and detailed. 
When schedules are vertically traceable, lower-level schedules are 
clearly consistent with upper-level schedule milestones, allowing for 
total schedule integrity and enabling different teams to work to the 
same schedule expectations. In this way, management can base informed 
decisions on forecasted dates that are reliably predicted in detailed 
schedules through network logic and actual progress to date. 

In addition, vertical traceability allows managers to understand the 
effect on key program and G/R milestones if their lower-level 
activities are delayed. An activity owner should be able to trace 
activities to higher-level milestones within intermediate and summary 
schedules. Even though their activities may be rolled into a higher-
level milestone, responsible owners should be able to identify when and 
how their product affects the program. 

All levels of schedule data, from detailed through summary schedules, 
should be derived from the same IMS. Ideally, the same schedule serves 
as the summary, intermediate, and detailed schedule by simply creating 
a summary view filtered on summary activities or higher-level WBS 
milestones. Summary schedules created by rolling up the dates and 
durations of lower-level elements are inherently vertically integrated. 
Often the project schedule is represented in a completely different 
format, because of the presentation software, and special care is 
needed if representations are to be consistent with the detailed 
schedules. 

If alternative presentation modes are used to represent the project 
schedule, the program management office should be able to demonstrate 
that this process is successful. It is important to note that vertical 
traceability is not simply the ability to collapse WBS elements within 
the same contractor schedule. Vertical traceability implies the ability 
of the contractor schedule to roll up into the overall program 
schedule, which includes government activities, other contractor 
schedules, and interfaces with external parties, even if constructed in 
a separate computer file or different software package. All a program's 
project schedule information, from the suppliers through the 
contractors and government agencies, should be collapsible into one 
overall IMS. The relationship between vertical traceability and common 
WBS is highlighted in case study 9. 

Case Study 9: Vertical Traceability, from Immigration Benefits, 
GAO-12-66: 

GAO assessed the U.S. Citizenship and Immigration Services' (USCIS) 
Office of Information Technology schedule for its Transformation 
Program. Vertical integration was partially demonstrated in the 
schedule. While GAO was able to trace some activities between the 
transformation program and other USCIS high-level schedules, the WBS 
numbers across schedules did not match. For example, the WBS name and 
element number for the System Definition Review activity--a critical 
milestone necessary if detail planning were to continue--was not 
consistent across the Office of Information Technology, solutions 
architect, and USCIS master schedules. Without a standardized WBS, 
identifying activities across different schedules is hampered, if not 
impossible. 

GAO, Immigration Benefits: Consistent Adherence to DHS's Acquisition 
Policy Could Help Improve Transformation Outcomes, [hyperlink, 
http://www.gao.gov/products/GAO-12-66] (Washington, D.C.: November 22, 
2011). 

Finally, vertical integration applies to all schedule data that are 
reported to and by program management. That is, schedule information 
such as forecasted dates, predecessor logic, and critical path 
activities reported to management should be rooted in and traceable to 
the actual program IMS. 

Best Practices Checklist: Verifying That the Schedule Can Be Traced 
Horizontally and Vertically: 

* The schedule is horizontally traceable. That is, the schedule: 

- depicts logical relationships between different program elements and 
product hand-offs and clearly shows when major deliverables and hand-
offs are expected; 

- includes complete logic from program start to program finish and 
fully integrates the entire scope of work from all involved in the 
program; 

- includes milestones representing key decisions or deliverables with 
traced and validated predecessor activities to ensure that they are 
directly related to completing the milestone; 

- clearly identifies and logically links "giver/receiver" milestones 
between schedules that are defined in the schedule baseline document; 

- dynamically reforecasts the date of a key milestone through network 
logic if activities related to accomplishing the milestone are delayed; 

- is affected by activities whose durations are extended by hundreds of 
days; 

- includes giver/receiver milestones that are defined in the schedule 
baseline document: 

* The schedule is vertically traceable. That is, it: 

- demonstrates that data are consistent between summary, intermediate, 
and detailed levels of the schedule, including ates that are frequently 
validated through a documented process; 

- allows activity owners to trace activities to higher-level milestones 
with intermediate and summary schedules; 

- allows lower-level schedules to be rolled up into the overall program 
schedule, which includes government activities, other contractor 
schedules, and interfaces with external parties. 

[End of Best Practice 5] 

Best Practice 6: Confirming That the Critical Path Is Valid: 

The Critical Path: 

[Side bar: Best Practice 6: The schedule should identify the program 
critical path—-the path of longest duration through the sequence of 
activities. Establishing a valid critical path is necessary for 
examining the effects of any activity's slipping along this path. The 
program critical path determines the program's earliest completion 
date and focuses the team's energy and management's attention on the 
activities that will lead to the project's success. End of side bar] 

The critical path is generally defined as the longest continuous 
sequence of activities in a schedule. As such, it defines the program's 
earliest completion date or minimum duration. Activities on this path 
are termed "critical path activities." Typically, the sequence of 
activities with the longest total duration is also the path through the 
network with the lowest total float. As we shall see in Best Practice 
7, total float is the amount of time an activity can slip before its 
delay affects the program end date. When the network is free of date 
constraints, critical activities have zero float, and therefore any 
delay in the critical activity causes the same amount of delay in the 
program finish date. That is, if an activity on the critical path is 
delayed by a week, the program finish date will be delayed by a week 
unless the slip is successfully mitigated. Therefore, the critical path 
is most useful as a tool to help determine which activities deserve 
focus and, potentially, management help. 

In figure 25, the critical path is made up of three detail work 
activities: "install roof decking," "form and pour driveway," and 
"finish excavate and pour garage floor." "Install roof decking" has an 
estimated duration of 2 days, "form and pour driveway" 2 days, and 
"finish excavate and pour garage floor" 1 day. The minimum duration of 
this particular sequence of activities, leading up to the "framing 
complete" milestone, is therefore 5 days. An additional 1-day's 
activity, "rough-in framing inspection," is performed in parallel with 
"form and pour driveway"--that is, the rough-in framing inspection may 
start after the installation of the roof decking finishes, along with 
forming and pouring the driveway. 

Figure 25: The Critical Path and Total Float: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Framing; 
Early start: 3-11-13; 
Late start: 3-11-13; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Early start: 3-27-13; 
Late start: 3-27-13; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Early start: 3-29-13; 
Late start: 4-2-13; 
Total float (in days): 2. 

Activity name: Form and pour driveway; 
Early start: 3-29-13; 
Late start: 3-29-13; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Early start: 4-2-13; 
Late start: 4-2-13; 
Total float (in days): 0. 

Activity name: Framing complete; 
Early start: 4-2-13; 
Late start: 4-2-13; 
Total float (in days): 0. 

Source: GAO. 

[End of figure] 

With the inspection complete and the garage floor poured, the framing 
portion of construction is considered complete. However, because 
"rough-in framing inspection" is 1 day shorter than "form and pour 
driveway" and does not affect the pouring of the garage floor, it does 
not directly affect the start date of the "framing complete" milestone. 
Notice that "rough-in framing inspection" has an early start of March 
29 and a late start of April 2. In other words, rough-in framing 
inspection could start as late as April 2 (2 working days later than 
planned) and, if finished in 1 day, would have no effect on the 
"framing complete" milestone date of April 3. The difference between 
early and late dates for "rough-in framing inspection" yields 2 working 
days of total float. The early and late start dates for "form and pour 
driveway," however, are equal. If the driveway is formed and poured 1 
day late, or if its duration extends by 1 day, then the "framing 
complete" milestone slips by 1 day. "Form and pour driveway" has zero 
float and is on the critical path. 

Scheduling software automatically calculates a critical path through a 
network of activities by defining as critical activities with less than 
a predefined amount of total float. Typically, total float is set to 
zero, and the scheduling software marks critical all activities with 
zero or less-than-zero total float. 

When the network is free of date constraints, activities with low total 
float are "near-critical" because they can quickly become critical if 
their float is used up in a delay. Near-critical paths need only a 
small extension of time to become critical. Management must monitor 
critical and near-critical activities through sound schedule management 
because any delay in them will delay the entire program. Near-critical 
paths are monitored according to a float threshold tailored to the 
project. For example, a brief schedule might consider a 5-day slip to 
be a near-critical threshold. In projects scheduled to take years, a 2 
or 3 month's slip in near-critical paths might make the path critical. 
Because prolonging a schedule by 5 days on a short project is as easily 
possible as prolonging a multiyear project several months, project 
managers should manage all near-critical and critical paths. 

The sequence of activities that make up the critical path changes as 
activities are delayed, finished early, occur out of planned sequence, 
and so on. Activities that were previously critical may become 
noncritical, and activities that were not critical may become critical. 
At any point in time, the critical path may or may not contain 
activities that management believes are particularly important. It is 
crucial that program management understand that an important activity 
is not necessarily "critical." A delay in an activity may be important 
for any number of reasons related to scope and cost without delaying 
the finish milestone date. In contrast, some mundane activities--
training, for example--may be on the critical path and may not be 
particularly risky but can delay the project finish date if they take 
longer to accomplish. Similarly, an activity of long duration should 
not be referred to as a "critical path activity" simply because it will 
take a long time to accomplish. "Critical activity" in scheduling 
parlance has a specific definition that should be adhered to when 
reporting and evaluating schedule data. 

The Critical Path and the Longest Path: 

The critical path is theoretically the sequence of activities that 
represents the longest path from the project's start and finish dates. 
In reality, however, as a schedule becomes more complex, total float 
values may not necessarily represent a true picture of the number of 
days an activity can slip. For example, multiple calendars, out-of-
sequence progress, date constraints, and leveled resources can all 
produce misleading values of total float in complex schedules, leading 
to a misrepresentation of the sequence of activities that actually 
drives the project finish date. 

As we noted in Best Practice 2, date constraints may cause activities 
to become critical, regardless of the total float that may be available 
if not constrained in the network. Specifically, backward-pass date 
constraints on activities other than the finish milestone will 
influence the criticality of activities. Hence, where constraints are 
many, there may be many more activities with zero or negative total 
float than activities that are actually driving the key project 
completion milestone.[Footnote 17] 

Figure 26 gives two sequences of activities necessary to complete 
framing: critical activities (in red) and noncritical activities (in 
black). The critical path is also the sequence of activities that 
represents the longest path to the "framing complete" milestone. 
Summing their duration yields 16 days. That is, the minimum duration 
from the start date of "install first floor joists and decking" to the 
"framing complete" milestone is 16 working days. A second path of 
activities, consisting of "exterior backfill basement walls" and "rough 
grade property," after the installation of the first floor joists and 
decking, has 7 days of available float and is therefore not considered 
critical. 

Figure 26: The Critical Path and the Longest Path: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Duration (in days): 4; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Duration (in days): 3; 
Total float (in days): 7. 

Activity name: Rough grade property; 
Duration (in days): 1; 
Total float (in days): 7. 

Activity name: Form and pour driveway; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Duration (in days): 1; 
Total float (in days): 2. 

Activity name: Framing complete; 
Duration (in days): 0; 
Total float (in days): 0. 

Source: GAO.  

[End of figure] 

If the general contractor were to introduce a backward-pass date 
constraint on "rough grade property" --mandating for example that the 
property be rough graded by March 19--then the date constraint on 
"rough grade property" would consume that path's entire total float, 
redefining it as critical according to the total float criticality 
threshold of zero. 

Figure 27: Critical Path Activities Not on the Longest Path: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Duration (in days): 4; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Duration (in days): 3; 
Total float (in days): 0. 

Activity name: Rough grade property; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Form and pour driveway; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Duration (in days): 1; 
Total float (in days): 2. 

Activity name: Framing complete; 
Duration (in days): 0; 
Total float (in days): 0. 

Source: GAO.  

[End of figure] 

Source: GAO. 

The network now has two more critical activities than the network 
without the date constraint and shows two parallel critical paths in 
terms of total float. However, the longest path--in terms of duration--
remains the same, regardless of the date constraint. While "rough 
grade property" is marked critical in the schedule, it actually has 7 
days of relative float because it can slip 7 days before causing the 
"framing complete" milestone to slip. The longest path is also referred 
to as the driving path because it determines the date of the key 
milestone. A driving path can be identified for any key milestone or 
activity to determine the sequence of activities driving its finish 
date. 

When the critical path is not the longest path, the longest path is 
preferred because it represents the activities that are driving the 
sequence of start dates directly affecting the estimated finish date, 
if we ignored the presence of date constraints. Therefore, rather than 
simply filtering on activities that are marked critical by the 
scheduling software, management should be aware of the activity 
"drivers" that are determining the schedule finish date. 

Moreover, driver activities may or may not have the lowest total float 
values when activities other than the project finish milestone have 
date constraints. Continuing with the framing example in figure 27, 
suppose the general contractor mandates the property be rough graded by 
Friday, March 15. This mandate is reflected in figure 28. 

Figure 28: The Longest Path and the Lowest-Float Path: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Total float (in days): -2. 

Activity name: Install waterproofing on exterior basement walls; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Duration (in days): 4; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Duration (in days): 3; 
Total float (in days): -2. 

Activity name: Rough grade property; 
Duration (in days): 1; 
Total float (in days): -2. 

Activity name: Form and pour driveway; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Duration (in days): 1; 
Total float (in days): 2. 

Activity name: Framing complete; 
Duration (in days): 0; 
Total float (in days): 0. 

Source: GAO.  

[End of figure] 

The lowest total float path is now "exterior backfill basement walls," 
"rough grade property," "form and pour garage floor," and "finish 
excavate and pour garage floor." However, neither "exterior backfill 
basement walls" nor "rough grade property" is determining the finish 
date of the "framing complete" milestone. Most scheduling software 
calculates activity drivers along with the critical activities. 

Common Barriers to a Valid Critical Path: 

As noted above, the critical path ideally represents the longest path, 
as when the schedule network is free of backward-pass constraints and 
activities on this path have the least float in the network. In this 
section, we highlight issues that prevent the critical path from being 
the longest path. When these issues arise, it is imperative that 
management recognize not only critical path activities--that is, 
activities with the lowest float--but also activities that are truly 
driving the finish date of key milestones. 

Calculating a critical path is directly related to the logical 
sequencing of activities. Missing or convoluted logic and artificial 
date constraints prevent the calculation of a valid critical path; they 
can cause activities to appear to be critical but that are not. 
Successfully identifying the critical path relies on a valid, credible 
schedule. That includes capturing all activities (Best Practice 1), 
proper sequencing of activities (Best Practice 2), horizontal 
traceability (Best Practice 5), the reasonableness of float (Best 
Practice 7), accurate status updates (Best Practice 9), and--if there 
are resource limitations--assigning resources (Best Practice 3). 

It is essential that the critical path be evaluated before the schedule 
is baselined and after every status update to ensure that it is valid. 
If the schedule is missing activities, then the critical path will not 
be valid. Moreover, if the critical path is missing dependencies or has 
date constraints, lags, or level-of-effort activities or is not a 
continuous path from the current status date to the finish milestone, 
then it is not valid. 

Continuous through All Activities: 

Unless the IMS represents the entire scope of effort, the scheduling 
software will report an incorrect or invalid critical path. As 
discussed in Best Practices 1 and 4, the IMS must include planning for 
all activities that have to be accomplished for the entire duration of 
the program. A critical path for one block, increment, or contract for 
a multiyear multiphased program is not a sufficient plan that can 
reliably forecast the finish date for the program. A critical path 
should exist for the entire program because detail activities, as well 
as long-term planning packages, must be logically linked within the 
schedule to create a complete picture of the program from start to 
finish. In addition, for projects under way, the longest path or 
critical path should start with at least one in-progress activity with 
an actual start date. 

The critical path should be a continuous sequence of activities from 
the schedule status date to the finish milestone. In general, the 
sequence of activities should have no breaks and there should be no 
large gaps of unaccounted time. The critical path may branch off into 
several sequences of activities, but they must ultimately converge at 
the finish milestone. Sorting the schedule by activity start date, 
filtering by critical activities, and visually assessing the sequence 
of activities in a Gantt chart is an easy way to assess the 
practicality of the calculated critical path. Ideally, the Gantt chart 
will display a continuous waterfall of activities from the status date 
to the program finish date that are logically linked with finish-to-
start relationships. Case study 10 shows why program-wide critical 
paths are important. 

Case Study 10: Noncontinuous Critical Path, from FAA Acquisitions, 
GAO-12-223: 

Officials from FAA's Collaborative Air Traffic Management Technologies 
system said that because of the 6-month spiral development approach, 
the program schedule could not deliver a single critical path for the 
entire program. Instead, the critical paths were by release. To produce 
the critical paths, the prime contractor used a constraint on the key 
deliverable finish milestone for each release. 

At the time of GAO's analysis, officials stated that only work related 
to Release 5 was subject to a critical path analysis because that 
release was the current focus of management. GAO was able to trace a 
continuous critical path for Release 5, beginning with the project 
status date and ending with the Release 5 finish milestone. However, 
the validity of the Release 5 critical path was hampered by seven in-
progress and remaining detail activities within Release 5 that had over 
1,300 working days of total float. We also determined that a small 
number of activities outside Release 5 were under way (for example, 
activities related to other task orders). Because these activities fell 
outside the Release 5 task order, and therefore outside the purview of 
a Release 5 critical path analysis, management may not have been fully 
aware of the effect of any delay in these activities. 

GAO, FAA's Acquisitions: Management Challenges Associated with Program 
Costs and Schedules Could Hinder NextGen, [hyperlink, 
http://www.gao.gov/products/GAO-12-223] (Washington, D.C.: February 
16, 2012). 

Breaks in the critical path should be examined immediately and 
justified or otherwise addressed. Common causes of noncontinuous 
critical paths are that: 

* the start or finish date of an activity is driven by a constraint; 

* a successor activity is driven by an unexplained lag; 

* the start date of an activity is driven by an external predecessor; 

* activities are scheduled according to different calendars, as when a 
predecessor activity ends in a nonworking period for the successor; 
and: 

* resource leveling is causing delays. 

For example, if an activity on the critical path starts some days or 
weeks after its driving predecessor finishes (assuming finish-to-start 
logic) because of a start date constraint or an unexplained lag, then 
the path is considered to be noncontinuous and broken. In each scenario 
above, additional total float may occur in the predecessor activities; 
it would break the sequence of activities with zero total float. The 
program management team must determine whether this additional total 
float is meaningful. If it is not, the threshold for total float 
criticality may have to be raised. 

The Number of Critical Activities: 

In general, assessing the quality of the critical path by 
predetermining the number of activities that should be critical is not 
useful. The number of activities on the critical path will depend on 
the visibility required to manage the program and reduce risk. However, 
if the ratio of critical path activities to the total activity count is 
nearly 100 percent, then the schedule may be overly serial and resource 
limited. Conversely, if only a few activities are on the critical path 
and they all represent LOE, then the critical path is being driven by 
supporting effort and will not identify effort that is driving key 
milestones. 

Logical Sequencing: 

Float calculations are directly related to the logical sequencing of 
events (see Best Practice 7). Because float dictates the criticality of 
activities, the critical path is directly related to the logical 
sequencing of events and float calculations. If the schedule is missing 
dependencies or if activities are not linked correctly, float estimates 
will be miscalculated. Incorrect float estimates will result in an 
invalid critical path, hindering management's ability to reallocate 
resources from noncritical activities to those that must be completed 
on time. Errors or incomplete logic often cause values of total float 
that do not represent the state of the project schedule (we discuss 
this in Best Practice 7). 

Date Constraints: 

We saw in Best Practice 2 that placing a hard constraint on an activity 
fixes the dates and immediately causes the activity to become critical. 
It is therefore possible to use hard constraints as a working tool 
while developing a schedule to calculate total available float up to 
key milestones. The temporary use of hard constraints is also valuable 
for assessing the likelihood that using available resources can achieve 
the planned activity date. However, using hard constraints simply to 
fix activity dates at certain points in time immediately convolutes 
critical path calculations and reduces the credibility of any schedule 
date on activities past the constraint in logic. In this case, the 
critical path is no longer the longest path; instead, each hard 
constraint in the schedule generates its own sequence of critical 
activities, and the purpose of CPM scheduling is defeated. 

Lags: 

The critical path should be free of lags; they obfuscate the 
identification and management of critical activities. As described in 
Best Practice 2, a lag is used in a schedule to denote the passage of 
time between two activities. Lags cannot represent work and cannot be 
assigned resources. Lags simply delay the successor activity, and no 
effort or resources are associated with them. 

Lags are often misused to force successor activities to begin on 
specific dates. Evaluating a critical path that includes lags can 
therefore be difficult because the lag may or may not represent work 
that has to be accomplished by some resource, either internal or 
external to the program. In addition, because lags are not represented 
in a schedule as an activity, they can easily be overlooked as drivers 
of the finish milestone date. A lag that indicates a waiting period, 
such as for document review or materials delivery, should be replaced 
with an activity that can be actively monitored, statused, and perhaps 
mitigated if necessary. 

In figure 29, "rough-in framing inspection" now has a 2-day lag on its 
finish-to-start relationship to the milestone "framing complete," 
representing 2 days of paperwork that the general contractor's company 
must perform. The total duration of "rough-in framing inspection," 
including its lag, is 3 days. The activity becomes critical because the 
2-day lag consumes its 2 days of total float. A report to the general 
contractor listing the current critical activities in the project would 
list "rough-in framing inspection" as critical but would more than 
likely fail to mention that its successor lag is causing it to be on 
the critical path, not the inspection activity itself. Any management 
initiatives by the general contractor to reduce the criticality of the 
inspection activity would fail, because it would be misdirected. The 
planned effort that is causing the criticality is concealed by the lag. 

Figure 29: The Critical Path and Lags: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Duration (in days): 4; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Duration (in days): 3; 
Total float (in days): 7. 

Activity name: Rough grade property; 
Duration (in days): 1; 
Total float (in days): 7. 

Activity name: Form and pour driveway; 
Duration (in days): 2; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Duration (in days): 1; 
Total float (in days): 0. 

Activity name: Framing complete; 
Duration (in days): 0; 
Total float (in days): 0. 

Source: GAO.  

[End of figure] 

Source: GAO. 

Level of Effort and Other Long-Durations Activities: 

We learned in Best Practice 1 that some schedulers represent LOE work 
by activities that have estimated durations rather than by hammock 
activities, the preferred practice. Their long durations mean that 
these activities may inadvertently define the length of a project and, 
thus, become critical if they are linked to successors through logic. A 
critical path cannot include LOE activities because, by their very 
nature, they do not represent discrete effort. The duration of LOE 
activities is determined by the overall duration of the discrete work 
they support. Therefore, an LOE activity cannot drive any successor and 
become critical. The logic should be placed on the detailed activities 
that the LOE resources support. 

In the house construction framing example in figure 30, we see an 
overarching general contractor project management activity planned 
through April 3 to ensure that all framing activities are managed 
properly and all documentation is created and filed appropriately. 
However, the LOE project management activity now determines the minimum 
duration of the framing sequence of activities, rather than the 
sequence of actual work that has to be accomplished to achieve the 
completion of framing. It is impossible to reduce the duration of 
framing: adding resources to a level of effort activity simply 
increases the work. Using this schedule, management has no indication 
of which activities can slip and which will respond positively to 
additional resources and reduce the risk of finishing late. 

Figure 30: The Critical Path and Level of Effort Activities: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Manage framing; 
Duration (in days): 17; 
Total float (in days): 0. 

Activity name: Install first floor joists and decking; 
Duration (in days): 2; 
Total float (in days): 1. 

Activity name: Install waterproofing on exterior basement walls; 
Duration (in days): 1; 
Total float (in days): 1. 

Activity name: Finish excavate and pour basement floor; 
Duration (in days): 2; 
Total float (in days): 1. 

Activity name: Frame first floor walls; 
Duration (in days): 4; 
Total float (in days): 1. 

Activity name: Install roof trusses; 
Duration (in days): 2; 
Total float (in days): 1. 

Activity name: Install roof decking; 
Duration (in days): 2; 
Total float (in days): 1. 

Activity name: Exterior backfill basement walls; 
Duration (in days): 3; 
Total float (in days): 8. 

Activity name: Rough grade property; 
Duration (in days): 1; 
Total float (in days): 8. 

Activity name: Form and pour driveway; 
Duration (in days): 2; 
Total float (in days): 1. 

Activity name: Finish excavate and pour garage floor; 
Duration (in days): 1; 
Total float (in days): 1. 

Activity name: Rough-in framing inspection; 
Duration (in days): 1; 
Total float (in days): 3. 

Activity name: Framing complete; 
Duration (in days): 0; 
Total float (in days): 0. 

Source: GAO.  

[End of figure] 

Long-duration non-LOE activities in the detail planning period should 
be reevaluated to determine if they can be broken down into more 
manageable pieces, particularly if they appear on the critical path. If 
work is broken into smaller pieces, some portions of it might be able 
to start earlier or in parallel with other portions or might be 
reassigned to other available resources, saving time and possibly 
moving the activity off the critical path. In particular, summary 
activities should never be on the critical path. As described in Best 
Practice 2, linking summary activities obfuscates the logic of the 
schedule. Tracing logic through summary links does not impart to 
management the sequence in which lower-level activities should be 
carried out. If a summary activity becomes critical, there is no way to 
determine which subactivities are critical and which are not. 

Predetermined Critical Activities: 

Finally, because all activities can become critical under some 
circumstances, intermediate and summary level schedules should derive 
their critical paths from detailed schedules while recognizing that 
this will not be as informative as the full critical path. For example, 
separate summary schedules should not be created by selectively 
choosing which lower-level milestones and detail activities management 
has determined are important to monitor. Activities may be important in 
terms of cost or scope, but there is little guarantee that hand-picked 
activities determine the finish milestone date as the project 
progresses. By only reporting on or monitoring the progress of favorite 
activities, management risks losing sight of previously unimportant 
activities that may now be driving the project's finish date (see case 
study 11). 

Case Study 11: Predetermined Critical Activities, from Immigration 
Benefits, GAO-12-66: 

The U.S. Citizenship and Immigration Services (USCIS) Transformation 
Program schedule consisted of 18 individual project schedules. To 
provide an alternative to an IMS and to ease reporting to the 
Acquisition Review Board and other senior officials, the Transformation 
Program Office (TPO) developed a high-level tracking tool summarizing 
dates and activities for the first release of the program based on 
individual schedules such as the Office of Information Technology and 
solutions architect schedule, which TPO did not directly manage. TPO 
used this tool to ensure the coordination and alignment of activities 
by collaborating with staff responsible for managing of individual 
schedules. 

However, this tracking tool was not an IMS because it did not integrate 
all activities necessary to meet the milestones for Release A. Rather, 
it was a selection of key activities drawn from the individual 
schedules that USCIS components and the solutions architect maintained. 
Moreover, the Transformation Program Manager expressed concern in a May 
2011 program management review that the information reported in the 
high-level tracking tool was not being reported in the individual 
schedules. In addition, this tracking tool was not an IMS because it 
did not show activities over the life of the program. That is, it had 
no dates or activities for the four other releases' set of work 
activities or how long they would take and how they were related to one 
another. 

As a result, program officials would have difficulty predicting, with 
any degree of confidence, how long completing all five releases of the 
Transformation Program would take. Program officials would also have 
difficulty managing and measuring progress in executing the work needed 
to deliver the program, thus increasing the risk of cost, schedule, and 
performance shortfalls. Last, USCIS would be hindered in accurately 
communicating the status of Transformation Program efforts to 
employees, the Congress, and the public. 

In addition, neither of the two underlying schedules that GAO assessed 
had a valid critical path. The USCIS Office of Information Technology 
schedule had missing or dangling logic on over 61 percent of its 
remaining activities. The solutions architect's schedule was missing 
logic on 40 percent of its remaining activities and contained excessive 
constraints, lags, and dangling logic. 

GAO, Immigration Benefits: Consistent Adherence to DHS's Acquisition 
Policy Could Help Improve Transformation Program Outcomes, [hyperlink, 
http://www.gao.gov/products/GAO-12-66] (Washington, D.C.: November 22, 
2011). 

Resource Leveling: 

The critical path method of scheduling assumes unlimited resources to 
accomplish the project. This is true even when the schedule is resource 
loaded because the critical path does not take into account resource 
overallocation. That is, a worker can be assigned to any number of 
parallel activities, regardless of workload. As discussed in Best 
Practice 3, resource leveling adjusts the scheduled times of activities 
or work assignments of resources to account for the availability of 
resources and to improve schedule accuracy and credibility. Resource 
leveling can be relatively simple as in reassigning work from 
overallocated resources to underallocated resources or delaying 
activities until resources are available. 

Leveling resources allows management to identify critical resources--
those that will delay the project finish date if they are unavailable 
for specific activities. If resource allocation is an issue that must 
be addressed in the schedule, the project end date will be determined 
not solely through network logic but also by considering resource 
availability. The sequence of activities that drive the project finish 
date, based on both network logic and resource availability, is called 
the resource critical path or the resource constrained critical path or 
critical chain. Although the resource critical path is complex and not 
easily derived by even the most common schedule software, it represents 
the most realistic model of activities and resources that determine the 
minimum possible duration of the project. Once critical resources are 
determined, management can attempt to facilitate their work by, for 
example, hiring additional help, providing an uninterrupted work 
environment, or negotiating vacation time so that critical work is not 
delayed. If management focuses solely on critical activities without 
taking into account critical resources, it risks ignoring or 
overworking the program's most valuable assets or jeopardizing the 
project's timely completion. 

Critical Path Management: 

Without clear insight into a critical path, management cannot determine 
which slipped activities will be detrimental to key project milestones 
and the program finish date. More complex schedules will require 
additional analysis by tracing critical resources. Float within the 
schedule can be used to mitigate critical activities by reallocating 
resources from activities that can safely slip to activities that must 
be completed on time. Until the schedule can produce a credible 
critical path and a credible longest path, management will not be able 
to provide reliable timeline estimates or identify problems or changes 
or their effects. In addition, management will not be able to reliably 
plan and schedule the detailed work activities. 

As stated earlier, the critical path and longest path must be 
reevaluated after each status update because the sequence of activities 
that make up the paths will change as activities are delayed, finish 
early, occur out of planned sequence, or the like. Additionally, 
activity duration updates and changes to logic may alter the paths. 
After each status update, the critical path and the longest path should 
be compared to the previous period's paths, and responsible resources 
should be alerted if previously noncritical and nondriving activities 
are now critical or driving. Likewise, resources that had been assigned 
to previously critical activities may now need to be reassigned to 
other critical activities. The critical and longest paths should make 
intuitive sense to subject matter experts. That is, the sequence, 
logic, and duration of critical activities should appear to be rational 
and consistent with reviewers' experience. 

Depending on the overall duration of the project, management may 
benefit by monitoring near-critical activities as well. For example, in 
addition to monitoring critical path activities, management may wish to 
monitor activities with 5 days or less total float. Monitoring near-
critical activities alerts management of potential critical activities 
and facilitates proper resource allocation before activities become 
critical.[Footnote 18] 

Conducting a schedule risk analysis (Best Practice 8) may reveal that, 
with risks considered, the path most likely to delay the project is not 
the critical path or the longest path in the static CPM schedule. The 
risk analysis may identify a different path or paths that are "risk 
critical." Risk mitigation should focus on those risk-critical paths 
for best effect. 

Best Practices Checklist: Confirming That the Critical Path Is Valid: 

* The schedule's critical path is valid. That is, the critical path or 
longest path in the presence of late-date constraints: 

- does not include LOE activities, summary activities, or other 
unusually long activities; 

- is a continuous path from the status date to the major completion 
milestones; 

- does not include constraints so that other activities are unimportant 
in driving the milestone date; 

- is not driven in any way by lags or leads; 

- is derived in summary schedules by vertical integration of lower-
level detailed schedules, not preselected activities that management 
has presupposed are important. 

* If backward-pass date constraints are present on activities other 
than the finish milestone, both the critical path and the longest path 
have been identified. With a number of constraints, activities with 
zero or negative total float may outnumber activities that are actually 
driving the key project completion milestone. 

* The critical path, or longest path in the presence of late-date 
constraints, is used as a tool for managing the program. That is, 
management: 

- has vetted and justified the current critical path as calculated by 
the software; 

- uses the critical path to focus on activities that will be 
detrimental to the key project milestones and deliveries if they slip; 

- examines and mitigates risk in activities on the critical path that 
can potentially delay key program deliveries and milestones; 

- has reviewed and analyzed near-critical paths because these 
activities are likely to overtake the existing critical path and drive 
the schedule; 

- recognizes not only activities with the lowest float but also 
activities that are truly driving the finish date of key milestones; 

- evaluates the critical path before the schedule is baselined and 
after every status update to ensure that it is valid. 

[End of Best Practice 6] 

Best Practice 7: Ensuring Reasonable Total Float: 

[Side bar: Best Practice 7: The schedule should identify reasonable 
float (or slack)—-the amount of time by which a predecessor activity 
can slip before the delay affects the program's estimated finish date-—
so that the schedule's flexibility can be determined. Large total 
float on an activity or path indicates that the activity or path can 
be delayed without jeopardizing the finish date. The length of delay 
that can be accommodated without the finish date's slipping depends on 
a variety of factors, including the number of date constraints within 
the schedule and the amount of uncertainty in the duration estimates, 
but the activity's total float provides a reasonable estimate of this 
value. As a general rule, activities along the critical path have the 
least float. End of side bar] 

Management should be aware of schedule float. Activities with the 
lowest float values constitute the highest risk to schedule completion 
or interim milestones. In general, if zero-float activities or 
milestones are not finished when scheduled, they will delay the project 
by time equal to their delayed finish--unless successor activities on 
the critical path can be completed in less time than originally 
planned. An activity's delay causes total float to decrease, thus 
increasing the risk of not completing the project as scheduled. 

* Incomplete, missing, or incorrect logic; unrealistic activity 
durations; or unstatused work will distort the value of total float so 
that it does not accurately represent the schedule's flexibility. In 
addition, total float may not be a completely accurate measure of 
flexibility if the schedule has late-date constraints or deadlines such 
that low or even negative float values for activities do not drive the 
finish milestone. Thus, it is imperative that project managers for both 
the acquirer and the contractor proactively manage float as activities 
are completed. Doing so will ensure that the project schedule 
accurately depicts the project's flexibility and will enable management 
to make appropriate decisions on reallocating resources or resequencing 
work before the project gets into trouble. 

Definitions of Total Float and Free Float: 

Float, or slack, is the amount of time an activity can be delayed 
before the dates of its successor activities or the program's finish 
milestone are affected.[Footnote 19] The two types of float most 
commonly monitored are total float and free float.[Footnote 20] 

Total Float: 

Total float, the amount of time an activity can be delayed or extended 
before delay affects the program's finish date, can be positive, 
negative, or zero. If positive, it indicates the amount of time that an 
activity can be delayed without delaying the program's finish date. 
[Footnote 21] Negative total float indicates the amount of time 
that must be recovered so as not to delay the program finish date 
beyond the constrained date. Negative total float arises when an 
activity's completion date is constrained--that is, when the constraint 
date is earlier than the calculated late finish of an activity. In 
essence, the constraint states that an activity must finish before the 
date the activity may finish as calculated by network logic. Negative 
float can also occur when activities are performed in a sequence that 
differs from the logic dictated in the network. Out-of-sequence logic 
is discussed in detail in Best Practice 9. Zero total float means that 
any amount of activity delay will delay the program finish date by an 
equal amount. An activity with negative or zero total float is 
considered critical. 

Free Float: 

Free float is the portion of an activity's total float that is 
available before the activity's delay affects its immediate successor. 
Depending on the sequence of events in the network, an activity with 
total float may or may not have free float. For example, an activity 
may be able to slip 2 days without affecting the finish date (2 days of 
total float), but its delay will cause a 2-day slip in the start date 
of its immediate successor activity (zero free float). 

Total float and free float are therefore indicators of a schedule's 
flexibility. Some activities in the schedule network will be able to 
slip without affecting their immediate successor, and some may affect 
their immediate successor but not the program finish date. This 
knowledge allows management to reassign resources from activities that 
can slip to activities that cannot slip. Knowing the amount of time an 
activity can or cannot be delayed is essential to successful resource 
allocation and to completing the program on time. 

Nonworking periods are not float. Nonworking periods are defined 
through resource calendars and dictate the availability of resources to 
work, not the flexibility of an activity's start or finish dates. In 
addition, float should not be treated as schedule contingency. Because 
float is shared along a sequence of activities, it is available for use 
by any activity along that sequence. As described in Best Practice 8, 
schedule contingency should be applied to specific activities according 
to prioritized risks. 

Calculating Float: 

Activities on the same network path share total float. Figure 31 shows 
a portion of the house construction project's critical path through 
framing. The critical path (in red) spans activities from "set steel 
columns and beams" through the "framing complete" milestone. Three 
activities have total float available: "exterior backfill basement 
walls," "rough grade property," and "rough-in framing inspection." 

Figure 31: Total Float and Free Float: 

[Refer to PDF for image: illustration of Gantt chart] 
    
Activity name: Install first floor joists and decking; 
Early start: 3-12-13; 
Late start: 3-12-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Early start: 3-14-13; 
Late start: 3-14-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Early start: 3-15-13; 
Late start: 3-15-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Early start: 3-19-13; 
Late start: 3-19-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Early start: 3-25-13; 
Late start: 3-25-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Early start: 3-27-13; 
Late start: 3-27-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Early start: 3-14-13; 
Late start: 3-25-13; 
Free float (in days): 0; 
Total float (in days): 7. 

Activity name: Rough grade property; 
Early start: 3-19-13; 
Late start: 3-28-13; 
Free float (in days): 7; 
Total float (in days): 7. 

Activity name: Form and pour driveway; 
Early start: 3-29-13; 
Late start: 3-29-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Early start: 4-2-13; 
Late start: 4-2-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Early start: 3-29-13; 
Late start: 4-2-13; 
Free float (in days): 2; 
Total float (in days): 2. 

Activity name: Framing complete; 
Early start: 4-2-13; 
Late start: 4-3-13; 
Free float (in days): 0; 
Total float (in days): 0. 

Source: GAO. 

[End of figure] 

While both "exterior backfill basement walls" and "rough grade 
property" have 7 days of total float available, only "rough grade 
property" has 7 days of free float available. Any delay backfilling 
basement walls will delay the rough grading of the property by an equal 
amount. However, rough grading the property may be delayed up to 7 days 
without affecting any successor activity. 

Note that leveling overallocated resources on the "rough grade 
property" activity is much easier than on "exterior backfill basement 
walls" because of the former activity's available free float. Delaying 
rough grading by 2 days affects the resources assigned to that 
activity, but it has no effect on any subsequent activity in the 
network. But delaying the backfill activity affects also the grading 
activity and resource assignments for both activities. As shown here, 
however, leveling resources will always consume float along a path of 
activities. 

Common Barriers to Valid Float: 

Unreasonable amounts of total float usually result from missing or 
incomplete logic rather than acceptable periods of potential delay. 
Therefore, any activities that appear to have a great amount of float 
should first be examined for missing or incomplete logic. Because total 
float is calculated from activities' early and late dates, it is 
directly related to the logical sequencing of events--just like the 
validity of the resulting critical path. Missing activities, missing or 
convoluted logic, and date constraints prevent the valid calculation of 
total float, potentially making an activity appear as though it can 
slip when it actually cannot. The reasonableness of total float depends 
on capturing all activities (Best Practice 1) and properly sequencing 
activities (Best Practice 2). It also depends on realistic resource 
assignments (Best Practice 3) and accurate status updates (Best 
Practice 9). Case study 12 shows how unreasonable float values can 
arise from improperly sequenced activities. 

Case Study 12: Unreasonable Float from the Sequencing of Activities, 
from FAA Acquisitions, GAO-12-223: 

GAO's analysis of FAA's Collaborative Air Traffic Management 
Technologies system IMS found unreasonable amounts of total float 
throughout the schedule. For example, 325 (68 percent) of the 481 
remaining activities had float values greater than 1,000 days. These 
unreasonable float values were caused mostly by activities being tied 
to the project finish milestone, which was constrained to start no 
earlier than July 1, 2016. Interim milestones that were scheduled to 
finish earlier than July 1, 2016--such as those marking the end of task 
orders--were tied to the project finish milestone as predecessors and 
were therefore showing enormous amounts of float that did not reflect 
actual flexibility in the schedule. The majority of high-float 
activities were level of effort activities, many of which were extended 
to the end of these interim milestones and thus associated with 
unreasonable amounts of float as well. Several activities had more than 
1,000 days of float, including "test and deploy" which showed a total 
float value of 1,280 days. This excessive float meant that delays in 
the activities would have no effect on the finish date of the Release 5 
end milestone. 

GAO, FAA's Acquisitions: Management Challenges Associated with Program 
Costs and Schedules Could Hinder NextGen, [hyperlink, 
http://www.gao.gov/products/GAO-12-223] (Washington, D.C.: 
February 16, 2012). 

Scheduling software automatically calculates total and free float for 
activities, which are then used to identify critical activities. 
However, these values of float must be examined for reasonableness. 
Unreasonable amounts of float might be negative, positive, or zero 
float. That is, a network that displays large negative values of total 
float, such as -300 days for some activities, most likely indicates 
either missing logic or an unrealistic sequencing of activities. For 
example, dangling logic can create unrealistic amounts of free float. 
Because float is shared along activity paths, finding and addressing 
incomplete logic that causes large float values may solve the float 
problem for many activities on the path. Likewise, a complex schedule 
the majority of whose remaining activities are critical is not a 
realistic plan and should be assessed for reasonable logic, the 
practicality of resource assignments, or the reasonableness of the 
project's duration. 

Reasonableness of Float: 

Given that float is directly related to the logical sequencing of 
activities and indicates schedule flexibility, management and auditors 
will question what constitutes a reasonable amount of float for a 
particular schedule. Float differs among activities, given their 
logical sequence in the network and the overall program duration. 
Therefore, management should not adhere to a target float value (for 
example, maximum 2 working periods) or specific float measure (for 
example, 10 percent of project duration). Large amounts of float may be 
justified, given the activity's place in the flow of work. For example, 
landscaping or paving in a construction project may slip many more 
months than pipefitting. Likewise, nonessential activities in a 2-year 
program may have far more float available than the same activities in a 
6-month project.[Footnote 22] Case study 13 shows unreasonable float in 
a schedule. 

Case Study 13: Reasonable Float, from Nuclear Waste, GAO-10-816: 

GAO initially assessed DOE's Savannah River Salt Waste Processing 
Facility's construction schedule in March 2010, finding that the 
schedule had 272 activities with more than 500 working days of float. 
In addition, two construction activities involving the fabrication of 
piping--usually critical in construction projects--had more than 1,000 
working days of float because neither activity was linked to a 
successor. After discussion with DOE and contractor officials, DOE made 
changes to the schedule for the May 2010 assessment. But the problem 
became worse, when 433 activities proved to have more than 500 days of 
float--an increase of 59 percent between March and May. In fact, 22 of 
these activities had more than 1,250 days of float, which was not 
reasonable. The department was therefore unable to realistically 
determine how much an activity could slip before the end date would be 
affected. In this case, apparently activities could slip by up to 3 
years and not affect the overall end date. 

GAO, Nuclear Waste: Actions Needed to Address Persistent Concerns with 
Efforts to Close Underground Radioactive Waste Tanks at DOE's Savannah 
River Site, [hyperlink, http://www.gao.gov/products/GAO-10-816] 
(Washington, D.C.: September 14, 2010). 

In general, total float should be as accurate as possible and should be 
evaluated relative to the program's projected finish date. Remaining 
activities in the schedule should be sorted by total float, and those 
values should be assessed for reasonableness. Management should 
determine whether it makes sense logically that any activity with a 
relatively high amount of float can actually slip that far without 
affecting the project's finish date. For instance, management should 
ask, is it reasonable that an activity with 55 days of total float can 
actually slip 55 working days before the program's finish date is 
affected? Is the manager of that particular activity aware of this 
float? A float value of 55 days may make sense for a program that has 4 
years of future planning packages, but a 55-day delay would probably be 
considered implausible in a 6-month project. Total float values that 
appear to be excessive should be documented to show that the project 
team, having already performed an analysis, has agreed that the logic 
and float for this activity is consistent with the plan. If too little 
float is built into the schedule, no recovery from inevitable delay may 
prevent the program's completion date from slipping. 

All activities with negative float should be questioned. Negative float 
stems from constraining one or more activities or milestones in the 
network. The constraint should be examined and justified, and the 
resulting negative float should be evaluated for reasonableness. 
Management should be aware of activities that are behind schedule with 
respect to the constrained activity. If the delay is deemed 
significant, management should develop a plan to examine options for 
recovering from the schedule slip. 

Float Management: 

Total and free float calculations are fundamental products of CPM 
scheduling. Network logic, float, durations, and criticality of 
activities are interrelated. That is, the logical sequence of 
activities and resource assignments within a network dictate the amount 
of available float, and the amount of available float defines the 
criticality of an activity to a constrained milestone or to the final 
milestone, whether constrained or not. Therefore, management cannot 
correctly monitor the critical path without also monitoring float. 
Incorrect float estimates may result in an invalid critical path and an 
inaccurate assessment of project completion dates. In addition, 
inaccurate values for total float result in a false depiction of the 
project's true status, which could lead to decisions that jeopardize 
the project. 

Management must understand the amount of time an activity can or cannot 
be delayed if it is to successfully allocate resources and manage the 
resequencing of work. Accurate values of total float can be used to 
identify activities that could be permitted to slip and resources to 
reallocate to activities that require more resources if the project is 
to be completed on time. This knowledge helps in reallocating resources 
optimally and in identifying the activity sequences that should be 
managed most closely. However, management must also balance the use of 
float with the fact that total float is shared along a path of 
activities. Allowing an activity to consume total float prevents 
successive activities from being able to slip and expends the 
schedule's flexibility rather than conserving it for future risks. 

Free float is particularly important in resource leveling because 
leveling generally targets activities with free float first. That is, 
delaying an activity within its available free float will not affect 
its successor activity or the project's completion date. Delaying an 
activity that has total float but no free float does not affect the 
project's completion date but does disturb successor activity dates 
that rely on the start or finish of the delayed activity. This, in 
turn, may disrupt resource availability for assignments along the 
entire path of successor activities. 

Once critical path float has been exhausted, the program is on a day-
for-day schedule slip. Float on the critical path should be 
commensurate with program risk, urgency, technological maturity, 
complexity and funding profile. Periodic reports should routinely 
report the amount of float consumed in a period and remaining on the 
critical and near-critical paths. A portent of things to come can be 
seen in the consumption of free float. As a program schedule becomes 
less flexible, the probability of having to consume near-critical path 
and critical path float is increased. 

Best Practices Checklist: Ensuring Reasonable Total Float: 

* The total float values calculated by the scheduling software are 
reasonable and accurately reflect true schedule flexibility. 

* The project really has the amount of schedule flexibility indicated 
by the levels of float. 

* Remaining activities in the schedule are sorted by total float and 
assessed for reasonableness. Any activities that appear to have a great 
deal of float are examined for missing or incomplete logic. 

* Total float values that appear to be excessive are documented to show 
that the project team has performed the assessment and agreed that the 
logic and float are consistent with the plan. 

* Total float is calculated to the main deliveries and milestones as 
well as to the project completion. 

* Total and free float inform management as to which activities can be 
reassigned resources in order to mitigate slips in other activities. 

* Management balances the use of float with the fact that total float 
is shared along a path of activities. 

* Periodic reports routinely show the amount of float consumed in a 
period and remaining on the critical and near-critical paths. 

* Date constraints causing negative float have been justified. If delay 
is significant, plans to recover the implied schedule slip have been 
evaluated and implemented, if so decided. 

[End of Best Practice 7] 

Best Practice 8: Conducting a Schedule Risk Analysis: 

Best Practice 8: A schedule risk analysis uses a good critical path 
method (CPM) schedule and data about project schedule risks and 
opportunities as well as statistical simulation to predict the level 
of confidence in meeting a program's completion date, determine the 
time contingency needed for a level of confidence, and identify high-
priority risks and opportunities. As a result, he baseline schedule 
should include a buffer or reserve of extra time. End of side bar] 

The results of risk analysis are best viewed as inputs to project 
management rather than as forecasts of how the project will be 
completed. The results indicate when the project is likely to finish 
without the project team's taking additional risk mitigation steps. The 
high-priority risks can be identified and used to guide further risk 
mitigation actions. A schedule risk analysis may prove that a given 
schedule has more risk than is acceptable. In this case, a review of 
the activities, dependencies, and network might help derive a less 
risky sequence of work. However, the initial estimates of efforts and 
durations should not be changed without sufficient justification. 

The Definition of Schedule Risk Analysis: 

A schedule risk analysis uses statistical techniques to predict a level 
of confidence in meeting a program's completion date. This analysis 
focuses on key risks and how they affect the schedule's activities. 
[Footnote 23] The analysis does not focus solely on the critical path 
because, with risk considered, any activity may potentially affect the 
program's completion date. A schedule risk analysis requires the 
collection of program risk data such as: 

* risks that may jeopardize (threats) or enhance (opportunities) 
schedule success, usually found in the risk register prepared before 
the risk analysis is conducted;[Footnote 24] 

* probability distributions of risk impact if it occurs, usually 
specified by a three-point estimate of activity durations (optimistic, 
most likely, and pessimistic) or multiplicative factors if the risk is 
to be applied to several activities; 

- the probability of a risk occurring; 

- the probability that a branch of activities might occur (for example, 
a test failure could lead to several recovery activities); and: 

- correlations between uncertain activity durations, whether specified 
directly or calculated. 

Risk data should be derived from quantitative risk assessment and 
should not be based on arbitrary percentages or factors. A risk 
assessment is a part of the program's overall risk management process 
in which risks are identified and analyzed and the program's risk 
exposure is determined. As risks are identified, risk-handling plans 
are developed and incorporated into the program's cost estimate and 
schedule as necessary.[Footnote 25] 

* Schedule risk analysis relies on statistical simulation to randomly 
vary the following: 

* activity durations according to their probability distributions; 

* risks and opportunities according to their probability of occurring 
and the distribution of their impact on affected activities if they 
were to occur; and: 

* the existence of a risk or probabilistic branch. 

The objective of the simulation is to develop a probability 
distribution of possible completion dates that reflect the program plan 
(represented by the schedule) and its quantified risks and 
opportunities. From the cumulative probability distribution, the 
organization can match a date to its degree of risk tolerance. For 
instance, an organization might want to adopt a program completion date 
that provides a 70 percent probability that it will finish on or before 
that date, leaving a 30 percent probability that it will overrun, given 
the schedule and the risks as they are known and calibrated. The 
organization can thus adopt a plan consistent with its preferred level 
of confidence in the overall integrated schedule. This analysis can 
give valuable insight into what-if drills and can quantify the effect 
of program changes (see case study 14). 

Case Study 14: Conducting a Schedule Risk Analysis, from Transportation 
Worker Identification Credential, GAO-10-43: 

Transportation Worker Identification Credential (TWIC) program 
officials did not perform a schedule risk analysis (SRA) for the pilot 
program IMS because they did not believe it necessary. For the TWIC 
pilot, an SRA could have enabled the program to model "what if" 
scenarios as to when and whether locations such as Long Beach would 
complete their preliminary work and the effects that schedule changes, 
if any, might have had on meeting the pilot reporting goal. Also, 
because the schedule was not shared with pilot participants, no SRA 
helped facilitate detailed discussions between the TWIC program office 
at TSA and the individual pilot locations regarding task durations and 
expected progress. This would have been especially relevant for the 
TWIC pilot given that the schedule did not clearly articulate all the 
activities that had to be completed to carry out the pilot, or changes 
that may have resulted from the availability of funding. For example, 
according to TSA officials and one pilot participant, such changes 
included delays in the approval by the Federal Emergency Management 
Agency of pilot participants' award contracts to allow the grantees to 
expend grant funds. In programs that lack a schedule risk analysis, it 
is not possible to reliably determine a level of confidence for meeting 
the completion date. 

GAO, DOD Transportation Worker Identification Credential: Progress Made 
in Enrolling Workers and Activating Credentials but Evaluation Plan 
Needed to Help Inform the Implementation of Card Readers, [hyperlink, 
http://www.gao.gov/products/GAO-10-43] (Washington, D.C.: November 18, 
2009). 

When a schedule risk analysis is developed, probability distributions 
for each activity's duration have to be established. Further, risk and 
opportunities in all activities must be evaluated and included in the 
analysis. The risk analysis should not be focused solely on the 
deterministic critical path. Because the durations of activities are 
uncertain, the true critical path is uncertain. Any off-critical path 
activity might become critical if a risk were to occur. Typically, 
three-point estimates--that is, best, most likely, and worst case 
estimates--are used to develop the probability distributions for the 
durations of activities. Alternatively, the risk driver approach 
specifies the probability that a risk will occur, its impact in 
multiplicative terms on the durations of activities that it affects if 
it occurs, and the identity of those activities. After the risk 
information is developed, the statistical simulation is run and the 
resulting cumulative distribution curve, the S curve, displays the 
probability associated with the range of program completion dates. 

If the analysis is to be credible, the program must have a good 
schedule network that clearly identifies the work that is to be done 
and the relationships between detailed activities. The schedule should 
be based on a minimum number of justified date constraints. The risk 
analysis should also identify the activities during the simulation that 
most often ended up on the critical path, so that near risk-critical 
path activities can also be identified and closely monitored. It is 
important to represent all work in the schedule, because any activity 
can become critical under some circumstances. Complete schedule logic 
that addresses the logical relationships between predecessor and 
successor activities is also important. The analyst needs to be 
confident that the schedule will automatically calculate the correct 
dates and critical paths when the activity durations change, as they do 
thousands of times during a simulation. If time or resources are 
insufficient to simulate the full program, or if the level of detail is 
unclear because of rolling wave planning, the simulation can be 
performed on a summary version of the schedule. 

The Purpose of a Schedule Risk Analysis: 

One of the most important reasons for performing a schedule risk 
analysis is that the overall program schedule duration may well be 
greater than the sum of the path durations for lower-level activities. 
This is so partly because of schedule uncertainty and schedule 
structure. 

Schedule uncertainty can cause activities to shorten (an opportunity) 
or lengthen (a threat). For instance, if a conservative assumption 
about labor productivity was used in calculating the duration of an 
activity and during the simulation a better labor productivity is 
possible, then the activity will shorten, at least for that iteration. 
However, most program schedule risk phenomena exhibit more probability 
of overrunning than underrunning. 

A schedule's structure has many parallel paths connected at a merge or 
join point that can cause the schedule to lengthen. Merge points 
include program reviews (preliminary design review, critical design 
review, and the like) or the beginning of an integration and test 
phase. The timing of these merge points is determined by the latest 
merging path. Thus, if a required element is delayed, the merge event 
will also be delayed. Because any merging path can be risky, any 
merging path can determine the timing of the merge event. This added 
risk at merge points is called the "merge bias." Figure 32 gives an 
example of the schedule structure that illustrates the network or pure-
logic diagram of a simple schedule with a merge point at integration 
and test. 

Figure 32: Network Diagram of a Simple Schedule: 

[Refer to PDF for image: illustration] 

Start: 
Milestone date: 4-29-06; ID-1. 

Unit 1: 
Start 4-29-06; ID-2; Duration: 165 days; Comp 0%: 
Design Unit 1: 
Start 4-20-08; ID-3; Finish 6-23-08; Duration: 165 days; Res: 
Build Unit 1: 
Start 6-24-08; ID-4; Finish 11-10-08; Duration: 100 days; Res: 
Test Unit 1: 
Start 11-11-08; ID-5; Finish 12-15-08; Duration: 25 days; Res:  

Unit 2: 
Start 4-29-06; ID-6; Finish 12-15-08; Duration: 165 days; Comp 0%;  
Design Unit 2: 
Start 4-29-08; ID-7; Finish 6-23-08; Duration: 40 days; Res: 
Build Unit 2: 
Start 6-24-08; ID-8; Finish 11-10-08; Duration: 100 days; Res: 
Test Unit 2: 
Start 11-18-08; ID-9; Finish 11-10-08; Duration: 25 days; Res: 
               
Integration and Test:                
Start 4-29-06; ID-10; Finish 4-20-09; Duration: 40 days; Comp 0%. 

Integrate 1 & 2:  
Start: 12-16-08; ID 11; Finish: 12-23-09; Duration: 50 days; Res:  

Test integrated System:
Start: 2-24-09; ID 12; Finish: 4-20-09; Duration: 40 days; Res:  

Finish: 
Milestone date: Mon. 4-20-09; ID 13.  

Source: Copyright 2007 Hulett and Associates, LLC. 

[End of figure] 

Because each activity has an uncertain duration, it stands to reason 
that the entire duration of the overall program schedule will also be 
uncertain. Therefore, unless a statistical simulation is run, 
calculating the completion date based on schedule logic and the most 
likely duration distributions will tend to underestimate the overall 
program critical path duration. 

Schedule underestimation is more pronounced when the schedule durations 
or logic have optimistic bias--for instance, when the customer or 
management has specified an unreasonably short duration or early 
completion date and when there are several points where parallel paths 
merge. Case study 15 highlights the potential impacts of converging 
activities on scheduled activities. 

Case Study 15: Converging Paths and Schedule Risk Analysis, from Coast 
Guard, GAO-11-743: 

The Coast Guard program office and Northrop Grumman officials said that 
schedule risk analysis (SRA) was not required for the National Security 
Cutter 3 (NSC 3) production contract and therefore was not performed. 

In the December 2010 program management review, only one risk was 
identified: "test or installation phase failure." Given that the 
schedule in February 2011 had 3,920 remaining activities, one 
identified risk seemed improbable. For example, Northrop Grumman 
officials said that the critical end milestone they were most concerned 
about was "preliminary delivery of NSC." However, this milestone was 
not on the risk list. The critical milestone had 5 days of negative 
float and 57 converging predecessors. That is, the task was already 5 
days behind schedule on the status date, and--compounding the risk--had 
multiple converging activity paths, which decreased the probability of 
meeting the planned milestone date. The chance that the milestone will 
be accomplished on time decreases with every additional path leading up 
to the milestone. The more parallel paths existing in the schedule, the 
greater is the schedule risk. A Monte Carlo SRA simulation could have 
helped identify the compound effect of parallel paths and could have 
quantified how much contingency reserve or buffer was needed in the 
schedule to mitigate the risk. 

Agency officials and Northrop Grumman said that a schedule risk 
analysis would be performed as part of the NSC 4 schedule. 

GAO, Coast Guard: Action Needed As Approved Deepwater Program Remains 
Unachievable, [hyperlink, http://www.gao.gov/products/GAO-11-743] 
(Washington, D.C.: July 28, 2011). 

Schedule Risk Analysis with Three-Point Duration Estimates: 

Because activity durations are uncertain, the probability distribution 
of the program's total duration must be determined statistically, by 
combining the individual probability distributions of all paths 
according to their risks and the logical structure of the schedule. 
Schedule activity duration uncertainty can be represented several ways, 
as illustrated by figure 33. 

Figure 33: A Project Schedule: 

[Refer to PDF for image: illustration of Gantt chart] 

ID: 0; 
Task name: Three path project GAO; 
Duration: 750 days; 
Start: 1/9/08; 
Finish: 1/27/10. 

ID: 1; 
Task name: Start; 
Duration: 0 days; 
Start: 1/9/08; 
Finish: 1/9/08. 

ID: 2; 
Task name: Software; 
Duration: 470 days; 
Start: 1/9/08; 
Finish: 4/22/09. 

ID: 3; 
Task name: Software design; 
Duration: 100 days; 
Start: 1/9/08; 
Finish: 4/17/08. 

ID: 4; 
Task name: Software coding; 
Duration: 250 days; 
Start: 4/18/08; 
Finish: 12/23/08. 

ID: 5; 
Task name: Software testing; 
Duration: 120 days; 
Start: 12/24/08; 
Finish: 4/22/09. 

ID: 6; 
Task name: Hardware; 
Duration: 500 days; 
Start: 1/9/08; 
Finish: 5/22/09. 

ID: 7; 
Task name: Hardware design; 
Duration: 100 days; 
Start: 1/9/08; 
Finish: 4/17/08. 

ID: 8; 
Task name: Hardware fabrication; 
Duration: 300 days; 
Start: 4/18/08; 
Finish: 2/11/09. 

ID: 9; 
Task name: Hardware test; 
Duration: 100 days; 
Start: 2/12/09; 
Finish: 5/22/09. 

ID: 10; 
Task name: Integration 11/W and SAN; 
Duration: 250 days; 
Start: 5/23/09; 
Finish: 1/27/10. 

ID: 11; 
Task name: Integration; 
Duration: 150 days; 
Start: 5/23/09; 
Finish: 10/19/09. 

ID: 12; 
Task name: Integrated test; 
Duration: 100 days; 
Start: 10/20/09; 
Finish: 1/27/10. 

ID: 13; 
Task name: Finish; 
Duration: 0 days; 
Start: 1/27/10; 
Finish: 1/27/10. 

Source: Copyright 2006 Huett and Associates, L.L.C. 

[End of figure] 

In this example, the project begins on January 9, 2008, and is 
expected to be completed about 2 years later, on January 27, 2010. 
Three major efforts involve software, hardware, and integration. 
According to the schedule logic and durations, hardware fabrication, 
testing, and the integration of hardware and software drive the 
critical path. 

The first way to capture schedule activity duration uncertainty is to 
collect various estimates from individuals and, perhaps, from a review 
of actual program performance. Estimates derived from interviews 
should be formulated by a consensus of knowledgeable technical experts 
and coordinated with the same people who manage the program's risk 
mitigation watch list. Figure 34 shows a traditional approach with a 
three-point estimate applied directly to the activity durations. 

Figure 34: Estimated Durations for Remaining WBS Areas in the Schedule: 

[Refer to PDF for image: table] 

ID: 0; 
Task name: Three path GAO project; 
Rept ID: 2; 
Mn Rdur: 0 days; 
ML Rdur: 0 days; 
Max Rdur: 0 days; 
Rept ID: 0. 

ID: 1; 
Task name: Start; 
Rept ID: 0; 
Mn Rdur: 0 days; 
ML Rdur: 0 days; 
Max Rdur: 0 days; 
Rept ID: 0. 

ID: 2; 
Task name: Software; 
Rept ID: 0; 
Mn Rdur: 0 days; 
ML Rdur: 0 days; 
Max Rdur: 0 days; 
Rept ID: 0. 

ID: 3; 
Task name: Software design; 
Rept ID: 0; 
Mn Rdur: 85 days; 
ML Rdur: 100 days; 
Max Rdur: 150 days; 
Rept ID: 2. 

ID: 4; 
Task name: Software coding; 
Rept ID: 0; 
Mn Rdur: 212.5 days; 
ML Rdur: 250 days; 
Max Rdur: 375 days; 
Rept ID: 2. 

ID: 5; 
Task name: Software testing; 
Rept ID: 0; 
Mn Rdur: 90 days; 
ML Rdur: 120 days; 
Max Rdur: 240 days; 
Rept ID: 2. 

ID: 6; 
Task name: Hardware; 
Rept ID: 0; 
Mn Rdur: 0 days; 
ML Rdur: 0 days; 
Max Rdur: 0 days; 
Rept ID: 0. 

ID: 7; 
Task name: Hardware design; 
Rept ID: 0; 
Mn Rdur: 85 days; 
ML Rdur: 100 days; 
Max Rdur: 130 days; 
Rept ID: 2. 

ID: 8; 
Task name: Hardware fabrication; 
Rept ID: 0; 
Mn Rdur: 255 days; 
ML Rdur: 300 days; 
Max Rdur: 390 days; 
Rept ID: 2. 

ID: 9; 
Task name: Hardware test; 
Rept ID: 0; 
Mn Rdur: 75 days; 
ML Rdur: 100 days; 
Max Rdur: 200 days; 
Rept ID: 2. 

ID: 10; 
Task name: Integration H/W and S/W; 
Rept ID: 0; 
Mn Rdur: 0 days; 
ML Rdur: 0 days; 
Max Rdur: 0 days; 
Rept ID: 0. 

ID: 11; 
Task name: Integration; 
Rept ID: 0; 
Mn Rdur: 120 days; 
ML Rdur: 150 days; 
Max Rdur: 210 days; 
Rept ID: 2. 

ID: 12; 
Task name: Integrated test; 
Rept ID: 0; 
Mn Rdur: 75 days; 
ML Rdur: 100 days; 
Max Rdur: 200 days; 
Rept ID: 2. 

ID: 13; 
Task name: Finish; 
Rept ID: 0; 
Mn Rdur: 0 days; 
ML Rdur: x days; 
Max Rdur: 0 days; 
Rept ID: 0. 

Source: Copyright 2007 Hulett and Associates, LLC. 

Note: 
Rept ID = report identification; 
Rdur = remaining duration, 
Mn = minimum, ML = most likely, Max = maximum; 
H/W = hardware; 
S/W = software. 

[End of figure] 

The example shows three-point estimates of remaining durations. In an 
actual program schedule risk analysis, these would be developed from 
in-depth interviews of people who are knowledgeable in each of the WBS 
areas of the program. To model the risks in the simulation, the risks 
are represented here as triangular distributions specified by the 
three-point estimates of the activity durations. Other distributions 
besides the triangular are traditionally available as well.[Footnote 
26] 

Once the distributions have been established, a statistical simulation 
(typically a Monte Carlo simulation) uses random numbers to select 
specific durations from each activity probability distribution and 
calculates a new critical path and dates, including major milestone and 
program completion. The Monte Carlo simulation continues this random 
selection thousands of times, creating a new program duration estimate 
and critical path each time. The resulting frequency distribution 
displays the range of program completion dates along with the 
probabilities that activities will occur on these dates, as seen in 
figure 35. 

Figure 35: The Cumulative Distribution of Project Schedule, Including 
Risk: 

[Refer to PDF for image: combined vertical bar and line graph] 

Date: 12/7/2007, 5:35:45 PM 
Samples: 5000; 
Unique ID: 0; 
Name: Three Path Project GAO. 

Completion Std Deviation: 51.79 days;
95% Confidence Interval: 1.44 days; 
Each bar represents 20 days. 

Graph plots frequency vs. completion date, mapping cumulative 
probability. 
      
Completion Probability Table: 

Probability: 0.05; 
Date: 2/19/10.   

Probability: 0.10; 
Date: 3/6/10. 

Probability: 0.15; 
Date: 3/18/10. 

Probability: 0.20; 
Date: 3/29/10. 

Probability: 0.25; 
Date: 4/5/10. 

Probability: 0.30; 
Date: 4/12/10. 

Probability: 0.35; 
Date: 4/19/10. 

Probability: 0.40; 
Date: 4/25/10. 

Probability: 0.45; 
Date: 5/2/10. 

Probability: 0.50; 
Date: 5/9/10. 

Probability: 0.55; 
Date: 5/15/10. 

Probability: 0.60; 
Date: 5/22/10. 

Probability: 0.65; 
Date: 5/29/10. 

Probability: 0.70; 
Date: 6/6/10. 

Probability: 0.75; 
Date: 6/15/10. 

Probability: 0.80; 
Date: 6/24/10. 

Probability: 0.85; 
Date: 7/5/10.   

Probability: 0.90; 
Date: 7/20/10. 

Probability: 0.95; 
Date: 8/8/10. 

Probability: 1.00; 
Date: 11/12/10.        

Source: Copyright 2007 Hulett and Associates, LLC. 

[End of figure] 

The figure shows that the most likely completion date is 
about May 11, 2010, not January 27, 2010, which is the date the 
deterministic schedule computed. The cumulative distribution also shows 
that, in this case study, the schedule completion date of January 27, 
2010, is less than 5 percent likely to occur, given the schedule and 
the risk ranges used for the durations. 

Schedule Risk Analysis with Risk Drivers: 

A second way to determine schedule activity duration uncertainty 
involves analyzing the probability that risks from the risk register 
may occur and what their effect on schedule activities will be if they 
do occur. With this approach, a probability distribution of the risk 
impact--expressed as a multiplicative factor--on the duration of 
activities in the schedule is estimated and the risks are assigned to 
specific activities in the schedule. In this way, activity duration 
risk is estimated indirectly by the root cause risks and their 
assignment to activities. A risk can be assigned to multiple activities 
and the durations of some activities can be influenced by multiple 
risks. This risk driver approach focuses on risks and their 
contribution to time contingency as well as on risk mitigation. The 
spacecraft schedule example in figure 36 shows how this approach can be 
used. 

Figure 36: Identified Risks on a Spacecraft Schedule: 

[Refer to PDF for image: illustration of Gantt chart] 

ID: SUMMA; 
Description: Project summary; 
Rem duration: 1,900; 
Start: 03/Mar/08; 
Finish: 12/Jun/15; 

ID: 00001; 
Description: Spacecraft project milestones; 
Rem duration: 1,900; 
Start: 03/Mar/08; 
Finish: 12/Jun/15. 

ID: 0002; 
Description: Requirements definition spacecraft; 
Rem duration: 100; 
Start: 03/Mar/08; 
Finish: 18/Jul/08. 

ID: 00003; 
Description: PDR spacecraft; 
Rem duration: 0; 
Start: 
Finish: 11/Sep/09. 

ID: 00004; 
Description: CDR spacecraft; 
Rem duration: 0; 
Start: 
Finish: 03/Jun/11. 

ID: 00005; 
Description: Ship to launch site; 
Rem duration: 0; 
Start: 
Finish: 12/Jun/15. 

ID: 00006; 
Description: First stage; 
Rem duration: 1,450; 
Start: 21/Jul/08; 
Finish: 07/Feb/14. 

ID: 00007; 
Description: FS preliminary design; 
Rem duration: 300; 
Start: 21/Jul/08; 
Finish: 11/Sep/09. 

ID: 00008; 
Description: FS PDR; 
Rem duration: 0; 
Start: 
Finish: 11/Sep/09. 

ID: 00009; 
Description: FS final design; 
Rem duration: 450; 
Start: 14/Sep/09; 
Finish: 03/Jun/11. 

ID: 00010; 
Description: FS CDR; 
Rem duration: 0; 
Start: 
Finish: 03/Jun/11. 

ID: 00011; 
Description: FS fabrication; 
Rem duration: 600; 
Start: 06/Jun/11; 
Finish: 20/Sep/13. 

ID: 00012; 
Description: Test FS engine; 
Rem duration: 100; 
Start: 23/Sep/13; 
Finish: 07/Feb/14. 

ID: 00020; 
Description: Upper stage; 
Rem duration: 1,450; 
Start: 21/Jul/08; 
Finish: 07/Feb/14. 

ID: 00021; 
Description: US preliminary design; 
Rem duration: 300; 
Start: 21/Jul/08; 
Finish: 11/Sep/09. 

ID: 00022; 
Description: US PDR; 
Rem duration: 0; 
Start: 
Finish: 11/Sep/09. 

ID: 00023; 
Description: US Final design; 
Rem duration: 450; 
Start: 14/Sep/09; 
Finish: 03/Jun/11. 

ID: 00024; 
Description: US CDR; 
Rem duration: 0; 
Start: 03/Jun/11; 
Finish: 03/Jun/11. 

ID: 00025; 
Description: US fabrication; 
Rem duration: 600; 
Start: 06/Jun/11; 
Finish: 20/Sep/13. 

ID: 00026; 
Description: US test; 
Rem duration: 100; 
Start: 23/Sep/13; 
Finish: 07/Feb/14. 

ID: 00027; 
Description: Integration; 
Rem duration: 350; 
Start: 11/Feb/14; 
Finish: 12/Jun/15. 

ID: 00028; 
Description: Integration; 
Rem duration: 250; 
Start: 10/Feb/14; 
Finish: 23/Jan/15. 

ID: 00029; 
Description: Integration testing; 
Rem duration: 100; 
Start: 26/Jan/15; 
Finish: 12/Jun/15. 

Source, Copyright 2007 Hulett and Associates, LLC.   

[End of figure] 

In this example of a spacecraft schedule, the work begins on 
March 3, 2008, and is expected to finish more than 7 years later, on 
June 12, 2015. Because of the long time and the risk associated with 
developing the spacecraft technology, the risk driver method can be 
used to examine how various risks from the risk register may affect 
this schedule. 

Figure 37: A Risk Register for a Spacecraft Schedule: 

[Refer to PDF for image: table] 

Description: 1; Requirements have not been decided; 
Optimistic: 95.00%; 
Most likely: 105.00%; 
Pessimistic: 120.00%; 
Likelihood: 30.00%. 

Description: 2; Several alternative designs considered; 
Optimistic: 95.00%; 
Most likely: 100.00%; 
Pessimistic: 115.00%; 
Likelihood: 60.00%. 

Description: 3; New designs not yet proven; 
Optimistic: 96.00%; 
Most likely: 103.00%; 
Pessimistic: 112.00%; 
Likelihood: 40.00%. 

Description: 4; Fabrication requires new materials; 
Optimistic: 96.00%; 
Most likely: 105.00%; 
Pessimistic: 115.00%; 
Likelihood: 50.00%. 

Description: 5; Lost know-how since last full spacecraft; 
Optimistic: 95.00%; 
Most likely: 100.00%; 
Pessimistic: 105.00%; 
Likelihood: 30.00%. 

Description: 6; Funding from congress is problematic; 
Optimistic: 90.00%; 
Most likely: 105.00%; 
Pessimistic: 115.00%; 
Likelihood: 70.00%. 

Description: 7; Schedule for testing is aggressive; 
Optimistic: 100.00%; 
Most likely: 120.00%; 
Pessimistic: 130.00%; 
Likelihood: 100.00%. 

Source: Copyright 2007 Hulett and Associates, LLC.     

[End of figure] 

In Figure 37, we can quickly determine that the biggest risk 
in the spacecraft schedule has to do with testing, because the schedule 
is very aggressive and some tests are always on the critical path. 
Moreover, a lack of requirements, funding delays, alternative designs, 
and the fact that some of the designs are unproven are also highly 
likely to affect the schedule. With the risk driver method, these risks 
are shown as factors that will be used to multiply the durations of the 
activities they are assigned to, if they occur in the iteration. Once 
the risks are assigned to the activities, a simulation is run. The 
results may be similar to those in figure 38. 

Figure 38: Spacecraft Schedule Results from a Monte Carlo Simulation: 

[Refer to PDF for image: combined vertical bar and line graph] 

Hits plotted vs. distribution (start of interval) in terms of 
cumulative frequency. 

Source: Copyright 2007 Hulett and Associates, LLC.    

[End of figure] 

In this example, the schedule date of June 12, 2015, is 
estimated to be 9 percent likely, based on the current plan. If the 
organization chooses the 80th percentile, the date would be March 3, 
2016, representing a 9-month time contingency. Notice that the risks 
have caused a 14-month spread, a respectable range of uncertainty, 
between the 5 percent and 95 percent confidence dates. A schedule risk 
analysis can provide valuable information to senior decision makers, as 
shown in case study 16. 

Case Study 16: Schedule Risk Analysis, from VA Construction, 
GAO-10-189: 

GAO performed a schedule risk analysis (SRA) on the construction 
schedule for Phase IV of the Department of Veterans Affairs' (VA) new 
Medical Center Complex in Las Vegas, Nevada. 

The project executive identified 22 different risks in an exercise 
preliminary to this analysis. Using these risks as a basis for 
discussion, GAO interviewed 14 experts familiar with the project, 
including VA resident engineers, general contractor officials, and 
architect and engineer consultants. In these interviews, GAO identified 
11 additional risks. During data analysis, some risks were consolidated 
with others and some were eliminated because of too few data. Finally, 
20 risks were incorporated into the Monte Carlo simulation. They 
included 18 risk drivers, 1 schedule duration risk, and 1 overall 
system commissioning activity that was not included in the baseline 
schedule. 

The schedule duration risk was applied to each activity duration to 
represent the inherent inaccuracy of scheduling. Of the 6,098 
activities in the schedule, GAO assigned risk drivers to 3,193. Some 
activities had one or two risks assigned, but some had as many as 
seven. 

Beyond applying 20 risks to the schedule, GAO was interested in 
identifying the marginal effect of each risk. Therefore, GAO identified 
the risks that had the greatest effect on the schedule, because they 
should have been targeted first for mitigation. Marginal effect 
translates directly to potential calendar days saved if the risk is 
mitigated. 

GAO's analysis of the medical center construction schedule concluded 
that VA should realistically expect VA acceptance between March 1, 
2012, and May 17, 2012, the 50th and 80th percentiles. It was 
determined that the must-finish date of August 29, 2011 was very 
unlikely. The analysis showed that the probability of achieving VA 
acceptance by October 20, 2011, was less than 1 percent, given the 
current schedule without risk mitigation. 

VA's actual acceptance was December 19, 2011, approximately 4 months 
later than what had originally been expected. Delays stemmed from 
issues with steel fabrication and erection, as well as changes to 
equipment requirements. At the time of GAO's original analysis, 
December 19, 2011 fell within the 10th to 15th percentile. 

GAO, VA Construction: VA is Working to Improve Initial Project Cost 
Estimates, but Should Analyze Cost and Schedule Risks, [hyperlink, 
http://www.gao.gov/products/GAO-10-189] (Washington, D.C.: December 
14, 2009). 

Schedule Contingency: 

A baseline schedule should include a buffer or a reserve of extra time, 
referred to as schedule contingency, to account risk[Footnote 27] The 
contingency represents a gap in time between the finish date of the 
last activity (the planned date) and the finish milestone (the 
committed date). When schedule contingency is depicted this way, a 
delay in the finish date of the predecessor activity results in a 
reduction of the contingency activity's duration. This reduction 
translates into the consumption of schedule contingency. 

Schedule contingency should be calculated by performing a schedule risk 
analysis and comparing the schedule date with that of the simulation 
result at a desired level of certainty. For example, an organization 
may want to adopt an 80 percent chance that its project will finish on 
time. The amount of contingency necessary would be the difference in 
time between the 80th percentile date and the date associated with the 
percentile of the deterministic finish date. 

For some projects, the 80th percentile is considered a conservative 
promise date. Other organizations may focus on another probability, 
such as the 65th or 55th percentile. However, these percentiles are not 
as certain as the 80th percentile and may expose the project to 
overruns if they are adopted. Factors such as project type, contract 
type, and technological maturity will affect each organization's 
determination of its tolerance level for schedule risk. 

Schedule contingency or reserve is held by the project manager but can 
be allocated to contractors, subcontractors, partners, and others as 
necessary for their scope of work. When margin needs to be allocated, a 
formal change process should be followed. Subjecting schedule 
contingency to the program's change control process ensures that 
variances can be tracked and monitored and that the use of contingency 
is transparent and traceable. 

Schedule contingency may appear as a single activity just prior to the 
finish milestone or it may be dispersed throughout the schedule as 
multiple activities prior to key milestones. For example, it might be 
appropriate to plan a contingency activity before the start of a key 
integration activity that depends on several external inputs to ensure 
readiness to start. In addition, dispersing contingency to specific key 
milestones may prevent its being consumed prematurely or superfluously. 
However, in general, apportioning contingency in advance to specific 
activities is not recommended because the risks that will actually 
occur and the magnitude of their effects are not known in advance. 
Contingency should be allocated according to the prioritized risk list. 
Moreover, contingency that is dispersed throughout the schedule is less 
visible and may be harder to track and monitor. Contingency reserved to 
specific activities may also encourage team members to work toward late 
dates rather than the expected early dates. By aggregating contingency, 
everyone on the project will be working to protect the schedule 
contingency as a whole, not simply their own portion. Regardless of 
whether contingency is captured at the end of the schedule or just 
before key milestones, representing it as activities will help ensure 
that the schedule is not hiding potential problems. 

Note that contingency is not the same as float. As described in Best 
Practice 7, float is the amount of time by which an activity can be 
delayed before it affects the dates of its successor activities or the 
program finish milestone. Float is directly related to network logic 
and is calculated from early and late dates of activities. Schedule 
contingency, in contrast, is determined by a schedule risk analysis 
that compares the schedule date with that of the simulation result at a 
desired level of certainty. Moreover, schedule contingency should not 
be represented as a lag between two activities. Lags are not 
specifically named in schedules and the associated contingency may 
become lost within the network logic. 

Prioritizing Risks: 

Regardless of the method used to examine schedule activity duration 
uncertainty, it is important to identify the risks that contribute most 
to the program schedule risk. Figure 39 shows one approach to 
identifying activities that need close examination for effective risk 
mitigation because they may ultimately determine the duration of the 
project. It compares a schedule with a well-managed critical path (unit 
2) and two other paths that have risk but positive total float. The 
noncritical path efforts (units 1 and 3) therefore did not attract the 
program manager's risk management attention. 

Figure 39: A Schedule Showing a Critical Path: 

[Refer to PDF for image: illustration of Gantt chart] 

Task name: Risk criticality project; 
Rept ID: 2; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Task name: Start; 
Rept ID: 0; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Task name: Units; 
Rept ID: 0; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Task name: Design unit 1; 
Rept ID: 0; 
Mn Rdur: 18 days; 
Mn Rdur: 28 days; 
Max Rdur: 43 days; 
Curve: 2. 

Task name: Build unit 1; 
Rept ID: 0; 
Mn Rdur: 35 days; 
Mn Rdur: 40 days; 
Max Rdur: 50 days; 
Curve: 2. 

Task name: Test unit 1; 
Rept ID: 0; 
Mn Rdur: 20 days; 
Mn Rdur: 25 days; 
Max Rdur: 50 days; 
Curve: 2. 

Task name: Unit 2; 
Rept ID: 0; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Task name: Design unit 2; 
Rept ID: 0; 
Mn Rdur: 25 days; 
Mn Rdur: 30 days; 
Max Rdur: 38 days; 
Curve: 2. 

Task name: Build unit 2; 
Rept ID: 0; 
Mn Rdur: 37 days; 
Mn Rdur: 40 days; 
Max Rdur: 45 days; 
Curve: 2. 

Task name: Test unit 2; 
Rept ID: 0; 
Mn Rdur: 22 days; 
Mn Rdur: 25 days; 
Max Rdur: 35 days; 
Curve: 2. 

Task name: Unit 3; 
Rept ID: 0; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Task name: Design unit 3; 
Rept ID: 0; 
Mn Rdur: 20 days; 
Mn Rdur: 30 days; 
Max Rdur: 45 days; 
Curve: 2. 

Task name: Build unit 3; 
Rept ID: 0; 
Mn Rdur: 32 days; 
Mn Rdur: 37 days; 
Max Rdur: 47 days; 
Curve: 2. 

Task name: Test unit 3; 
Rept ID: 0; 
Mn Rdur: 20 days; 
Mn Rdur: 25 days; 
Max Rdur: 50 days; 
Curve: 2. 

Task name: Finish; 
Rept ID: 0; 
Mn Rdur: 0 days; 
Mn Rdur: 0 days; 
Max Rdur: 0 days; 
Curve: 0. 

Source: Copyright 2007 Hulett and Associates, LLC. 

Note: Rept ID = report identification; Rdur = remaining duration, Mn = 
minimum, ML = most likely, Max = maximum; H/W = hardware; S/W = 
software. 

[End of figure] 

The measure of merit, the risk criticality, shows that the risky 
noncritical paths are more likely to delay the project than the 
original critical path. Figure 40 shows the results of each unit's 
probability of landing on the critical path, based on the Monte Carlo 
simulation. 

Figure 40: The Results of a Monte Carlo Simulation for a Schedule 
Showing a Critical Path: 

[Refer to PDF for image: illustration of Gantt chart] 

ID: 0; 
Task name: Risk criticality project; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 0; 
Risk Critical: No. 

ID: 1; 
Task name: Start; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 100; 
Risk Critical: No. 

ID: 2; 
Task name: Unit 1; 
Total slack: 2 days; 
Critical: No; 
% Critical: 44; 
Risk Critical: Yes. 

ID: 3; 
Task name: Design unit 1; 
Total slack: 2 days; 
Critical: No; 
% Critical: 44; 
Risk Critical: Yes. 

ID: 4; 
Task name: Build unit 1; 
Total slack: 2 days; 
Critical: No; 
% Critical: 44; 
Risk Critical: Yes. 

ID: 5; 
Task name: Test unit 1; 
Total slack: 2 days; 
Critical: No; 
% Critical: 44; 
Risk Critical: Yes. 

ID: 6; 
Task name: Unit 2; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 17; 
Risk Critical: No. 

ID: 7; 
Task name: Design unit 2; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 17; 
Risk Critical: No. 

ID: 8; 
Task name: Build unit 2; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 17; 
Risk Critical: No. 

ID: 9; 
Task name: Test unit 2; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 17; 
Risk Critical: No. 

ID: 10; 
Task name: Unit 3; 
Total slack: 3 days; 
Critical: No; 
% Critical: 39; 
Risk Critical: Yes. 

ID: 11; 
Task name: Design unit 3; 
Total slack: 3 days; 
Critical: No; 
% Critical: 39; 
Risk Critical: Yes. 

ID: 12; 
Task name: Build unit 3; 
Total slack: 3 days; 
Critical: No; 
% Critical: 39; 
Risk Critical: Yes. 

ID: 13; 
Task name: Test unit 3; 
Total slack: 3 days; 
Critical: No; 
% Critical: 39; 
Risk Critical: Yes. 

ID: 14; 
Task name: Finish; 
Total slack: 0 days; 
Critical: Yes; 
% Critical: 100; 
Risk Critical: No. 

Source: Copyright 2007 Hulett and Associates, LLC. 

[End of figure] 

After running the simulation, which takes into account the minimum, 
most likely, and maximum durations, we can see that although unit 2 is 
on the schedule's deterministic critical path, unit 1 is 44 percent 
likely to delay the project and unit 3 is 39 percent likely to do the 
same. In other words, the critical path method "critical path" is the 
least likely path to delay the project, perhaps because the project 
manager was successful in mitigating the risks on the CPM critical 
path. 

Other measures of risk importance can be reviewed. For instance, 
sensitivity measures reflecting the correlation of the activities or 
the risks with the final schedule duration can be produced by most 
schedule risk software. Figure 41 is a standard schedule sensitivity 
index for the spacecraft project discussed earlier. 

Figure 41: A Sensitivity Index for Spacecraft Schedule: 

[Refer to PDF for image: horizontal bar graph] 

Risk Criticality Project: 

00005 - Test Unit 1: 
Duration Sensitivity: 47%. 
   
00013 - Test Unit 3: 
Duration Sensitivity: 42%. 
   
00003 - Design Unit 1: 
Duration Sensitivity: 34%. 
   
00011 - Design Unit 3: 
Duration Sensitivity: 29%. 
   
00004 - Build Unit 1: 
Duration Sensitivity: 21%. 
   
00012 - Build Unit 3: 
Duration Sensitivity: 18%. 
   
00007 - Design Unit 2: 
Duration Sensitivity: 10%. 
   
00009 - Test Unit 2: 
Duration Sensitivity: 8%. 
   
00008 - Build Unit 2: 
Duration Sensitivity: 17%. 

Source: Copyright 2007 Hulett and Associates, LLC. 

[End of figure] 

In this example, the durations of the testing and design 
activities of units 1 and 3 show the highest correlation with the 
overall schedule duration more than the design, testing, and building 
of unit 2, even though unit 2 represents the critical path in the 
deterministic schedule. Therefore, without taking into account the risk 
associated with each unit's duration, the program manager would not 
know that keeping a strong eye on units 1 and 3 would be imperative for 
keeping the program on schedule. 

Probabilistic Branching: 

In addition to standard schedule risk and sensitivity analysis, typical 
events in government programs require adding some new activities to the 
schedule. This is called "probabilistic branching." One common event is 
the completion of a test of an integrated product (for example, a 
software program or satellite). The schedule often assumes that tests 
are successful, whereas experience indicates that tests may fail and 
that their failure will require the activities of root cause analysis, 
plan for recovery, execution of recovery, and retest. This is a branch 
that happens only with some probability. An example is shown in figure 
42. 

Figure 42: Probabilistic Branching in a Schedule: 

[Refer to PDF for image: illustration of Gantt chart] 

ID: 1; 
Task name: Project; 
Duration: 95 days; 
Start: 6/1; 
Finish: 9/3; 

ID: 2; 
Task name: Start; 
Duration: 0 days; 
Start: 6/1; 
Finish: 6/1; 

ID: 3; 
Task name: Design Unit; 
Duration: 30 days; 
Start: 6/1; 
Finish: 6/30; 
Predecessor: 2. 

ID: 4; 
Task name: Build Unit; 
Duration: 40 days; 
Start: 7/1; 
Finish: 8/9; 
Predecessor: 3. 

ID: 5; 
Task name: Test Unit; 
Duration: 25 days; 
Start: 8/10; 
Finish: 9/3; 
Predecessor: 4. 

ID: 6; 
Task name: FIXIT; 
Duration: 0 days; 
Start: 9/3; 
Finish: 9/3; 
Predecessor: 5. 

ID: 7; 
Task name: Retest; 
Duration: 0 days; 
Start: 9/3; 
Finish: 9/3; 
Predecessor: 6. 

ID: 8; 
Task name: Finish; 
Duration: 0 days; 
Start: 9/3; 
Finish: 9/3; 
Predecessor: 7,5. 

Source: Copyright 2007 Hulett and Associates, LLC.  

[End of figure] 

If the test unit activity fails, FIXIT and retest occur; 
otherwise, their duration is 0 days. This is a discontinuous event that 
leads to the two new activities. If the test is estimated to fail with 
some probability, such as 30 percent, the resulting probability 
distribution of dates for the entire project can be depicted as in 
figure 43. 

Figure 43: Probability Distribution Results for Probabilistic 
Branching: 

[Refer to PDF for image: combined vertical bar and line graph] 

Date: 1/9/2006; 8:03:50 PM; 
Samples: 3000; 
Unique ID: 0; 
Name: Probabilistic Branch.  

Completion Std Deviation: 27.45 d; 
95% Confidence Interval: 0.98 d; 
Each bar represents 10 d. 

Completion Probability Table: 
      
Prob: 0.05; 
Date: 9/1. 

Prob: 0.10; 
Date: 9/4. 

Prob: 0.15; 
Date: 9/6. 

Prob: 0.20; 
Date: 9/8. 

Prob: 0.25; 
Date: 9/10. 

Prob: 0.30; 
Date: 9/11. 

Prob: 0.35; 
Date: 9/13. 

Prob: 0.40; 
Date: 9/14. 

Prob: 0.45; 
Date: 9/16. 

Prob: 0.50; 
Date: 9/18. 

Prob: 0.55; 
Date: 9/20. 

Prob: 0.60; 
Date: 9/23. 

Prob: 0.65; 
Date: 9/26. 

Prob: 0.70; 
Date: 10/4. 

Prob: 0.75; 
Date: 10/28. 

Prob: 0.80; 
Date: 11/3. 

Prob: 0.85; 
Date: 11/9. 

Prob: 0.90; 
Date: 11/13 

Prob: 0.95; 
Date: 11/20. 

Prob: 1.00; 
Date: 12/16. 

Source: Copyright 2007 Hulett and Associates, LLC. 

[End of figure] 

Notice the bimodal distribution with the test success iterations on 
the left of figure 43 and the test failure iterations on the right. If 
the organization demanded an 80th percentile schedule, this would be 
November 3, although if it is satisfied by anything under the 70th 
percentile, the possibility of failure would not be important. 
[Footnote 28] 

Correlation: 

Other capabilities are possible once the schedule is viewed as a 
probabilistic statement of how the program might unfold. One that is 
notable is the correlation between activity durations. Positive 
correlation is when two activity durations are both influenced by the 
same external force and can be expected to vary in the same direction 
within their own probability distributions in any consistent scenario. 
While durations might vary in opposite directions if they are 
negatively correlated, this is less common than positive correlation in 
program management. Correlation might be positive and fairly strong if, 
for instance, the same assumption about the maturity of a technology is 
made to estimate the duration of design, fabrication, and testing 
activities. If the technology maturity is not known with certainty, it 
would be consistent to assume that design, fabrication, and testing 
activities would all be longer or shorter together. Without specifying 
correlation between these activity durations in simulation, some 
iterations or scenarios would have some activities that are thought to 
be correlated go long and others short in their respective ranges 
during an iteration. This would be inconsistent with the idea that they 
all react to the maturity of the same technology. 

Specifying correlations between design, fabrication, and testing 
ensures that each iteration represents a scenario in which their 
durations are consistently long or short in their ranges, together. 
Because schedules tend to add durations (given their logical 
structure), if the durations are long together or short together there 
is a chance for very long or very short projects. .Correlation affects 
the low and high values in the simulation results. That means that the 
high values are even higher with correlation and the low values are 
even lower, because correlated durations tend to reinforce each other 
down the schedule paths. If the organization wants to focus on the 80th 
percentile, correlation matters, whereas it does not matter as much 
around the mean duration from the simulation. 

Updating and Documenting a Schedule Risk Analysis: 

A schedule risk analysis should be performed on the schedule 
periodically as the schedule is updated to reflect actual progress on 
activity durations and sequences. As the project progresses, risks will 
retire or change in potential severity and new risks may appear. The 
length of time between SRA updates will vary according to project 
length, complexity, risk, and availability of management resources. A 
contractor should perform an SRA during the formulation of the 
performance measurement baseline to provide the basis for contractor 
schedule reserve at the desired confidence level. Preferably, an SRA 
would also be performed at key decision points throughout the project. 
An SRA might occur more regularly, for instance, to support annual 
budget request submissions so that adequate contingency can be included 
in the budget baseline. 

SRAs should also be performed as needed, as when schedule challenges 
begin to emerge with a contractor and schedule contingency is consumed 
at a higher than expected rate or consumed by the materialization of 
risks not included in the risk register. An updated SRA is particularly 
important in order to support the internal independent assessment 
process if the project is rebaselined or if significant changes are 
made to the risk register. Keeping the project schedule current is 
discussed in Best Practice 9 and rebaselining is discussed in Best 
Practice 10.[Footnote 29] 

Each update to the SRA should be fully documented, to include the risk 
data, sources of risk data, and techniques used to validate the risk 
data. In addition, the methodologies used to perform the simulation 
should be detailed, and outputs such as a prioritized risk list, the 
likelihood of the project completion date, which activities most often 
ended up on the critical path, and the derivation of contingency 
sufficient for risk mitigation should be documented. 

Best Practices Checklist: Conducting a Schedule Risk Analysis: 

* A schedule risk analysis was conducted to determine: 

- the likelihood that the project completion date will occur: 

- how much schedule risk contingency is needed to provide an acceptable 
level of certainty for completion by a specific date: 

- risks most likely to delay the project: 

- how much contingency reserve each risk requires and: 

- the paths or activities that are most likely to delay the project. 

* The schedule was assessed against best practices before the 
simulation was conducted. That is, the schedule network clearly 
identifies the work that is to be done and the relationships between 
detailed activities and is based on a minimum number of justified date 
constraints. 

* Data fields exist within the schedule for risk analysis such as low, 
most likely, and high durations. 

* The SRA accounts for correlation in the uncertainty of activity 
durations. 

* Risks are prioritized by probability and magnitude of impact. 

* The risk register was used in identifying the risk factors 
potentially driving the schedule before the SRA was conducted. 

* The SRA data and methodology are available and documented. 

* The SRA identifies the activities in the simulation that most often 
ended up on the critical path, so that near-critical path activities 
can be closely monitored. 

* The risk inputs have been validated. The ranges are reasonable and 
based on information gathered from knowledgeable sources, and there is 
no evidence of bias in the risk data. 

* The baseline schedule includes schedule contingency to account for 
the occurrence of risks. Schedule contingency is calculated by 
performing an SRA and comparing the schedule date with that of the 
simulation result at a desired level of certainty. 

* Schedule contingency is held by the project manager and allocated to 
contractors, subcontractors, partners, and others as necessary for 
their scope of work. 

* Contingency is allocated according to the prioritized risk list 
because the risks that will actually occur and the magnitudes of their 
effects are not known in advance. 

* The program documents the derivation and amount of contingency set 
aside by management for risk mitigation and unforeseen problems. An 
assessment of schedule risk is performed to determine whether the 
contingency is sufficient. 

* An SRA is performed on the schedule periodically as the schedule is 
updated to reflect actual progress on activity durations and sequences. 
A contractor performs an SRA during the formulation of the performance 
measurement baseline to provide the basis for contractor schedule 
reserve at the desired confidence level. 

[End of Best Practice 8] 

Best Practice 9: Updating the Schedule Using Actual Progress and 
Logic: 

[Side bar: Best Practice 9: Progress updates an logic provide a 
realistic forecast of start and completion dates for program 
activities. Maintaining the integrity of the schedule logic at regular 
intervals is necessary to reflect the true status of the program. To 
ensure that the schedule is properly updated, people responsible for 
the updating should be trained in critical path method scheduling. End 
of side bar] 

"Statusing" is the process of updating a plan with actual dates, 
logic, and progress and adjusting forecasts of the remaining effort. 
Statusing the schedule is fundamental to efficient resource management 
and requires an established process to provide continual and realistic 
updates to the schedule. Updates should be regular and fully supported 
by team members and program management. 

The benefits of updating the schedule on a regular basis include: 

* Knowledge of whether activities are complete, in progress, or late 
and the effect of variances on remaining effort; 

* continually refined duration estimates for remaining activities using 
actual progress, duration, and resource use; 

* the current status of total float and critical path activities; and: 

* the creation of trend reports and analyses to highlight actual and 
potential problems. 

The time between status updates depends on the project's duration, 
complexity, and risk. Updating the schedule too often will misuse team 
members' time and will provide little value to management, but updating 
too infrequently makes it difficult to respond to actual events. The 
schedule may be updated less frequently in the beginning of a project, 
then more frequently as it progresses and as more resources begin 
working on activities. 

The schedule should reflect actual progress as well as actual start 
and finish dates. Once an update has been made, management should 
assess its accuracy to verify that all finished work is in the past and 
all unfinished work is scheduled for the future. 

To ensure the schedule is properly updated, responsibility for 
changing or statusing the schedule should be assigned to someone who 
has the proper training and experience in CPM scheduling. Certain 
scheduling software packages may appear to be easy to use at first, but 
a schedule constructed by an inexperienced user may hide or ignore 
fundamental network logic errors and erroneous statusing assumptions. 

Statusing the schedule should not be confused with revising the 
schedule. Statusing involves updating the schedule with actual facts 
and comparing those facts against a plan, such as events on certain 
dates and the progress of work with a certain number of resources. 
After the schedule is statused, management may wish to revise the plan 
for remaining work by, for example, changing the sequence of activities 
or adding or deleting activities. That is, statusing the schedule 
involves updating the schedule with actual data, while revising the 
schedule focuses on adjusting future work. The concepts of altering the 
plan based on knowledge gained or actual performance are referred to as 
either replanning or rebaselining, depending on the project's approach 
to change control. These concepts are discussed further in Best 
Practice 10. 

Statusing Progress: 

Statusing progress generally takes the form of updating to either 
durations or work and includes updating the status of remaining work 
and network logic. A status date (or data date) denotes the date of the 
latest update to the schedule and thus defines the demarcation between 
actual work performed and remaining work. All work prior to the status 
date represents completed effort; all work beyond it represents 
remaining effort. Simply put, all dates before the status date are in 
the past and all dates beyond the status date are in the future. No 
dates in the past should be estimated; no dates in the future are 
actual dates. 

Unless a status date is provided, the schedule cannot be used to 
reliably convey past and remaining effort. The status date is an input 
into the calculations used to update and schedule remaining work. 
Neither the date on which someone is viewing the schedule nor the 
latest save date should be used as a substitute for a valid status date 
(see case study 17). 

Case Study 17: Invalid Status Dates, from DOD Business Transformation, 
GAO-11-53: 

Our analysis of the Air Force Defense Enterprise Accounting and 
Management System IMS found that the contractor schedule did not have a 
status date (or data date), and that the government program management 
office did not expect one. A status date denotes the date of the latest 
update to the schedule and, thus, defines the point in time at which 
completed work and remaining work are calculated. Officials stated that 
the status date is reflected by the month given in the schedule file 
name. Despite the invalidity of using the file name for a status date, 
we found 31 activities that had actual starts in future months relative 
to the month in the file name. That is, according to the schedule, 
these activities had actually started in the future. For example, the 
schedule file name is November 2009, yet we found actual start dates 
for activities in December 2009, February 2010, and April 2010. 

GAO, DOD Business Transformation: Improved Management Oversight of 
Business System Modernization Efforts Needed, [hyperlink, 
http://www.gao.gov/products/GAO-11-53] (Washington, D.C.: October 7, 
2010). 

Updating Duration or Work: 

Updating duration is the most common method of recording progress 
because it is the easiest to do. To update activity duration, an actual 
duration is entered into the plan to record the amount of time 
(typically working days) elapsed since the last update. If the activity 
began after the last statusing, an actual start date is entered as 
well. Next, an updated estimate of time remaining on the activity is 
entered. The scheduling software calculates percentage complete for the 
activity based on actual duration and planned remaining duration. 

While duration updates are widely used, team members can easily 
misconstrue them. Because the update applies to the activity duration, 
it specifically denotes the passage of time from the start date, not 
actual work accomplished on the activity. For instance, an activity 
could have used up 80 percent of its scheduled time yet have 
accomplished only 10 percent of the work. For this reason, it is 
important that realistic forecasts of remaining duration be updated at 
the same time as the actual duration is recorded. 

Accordingly, updating an activity's duration by entering percentage 
complete is not recommended, because scheduling software will adjust 
the remaining duration in order to yield the entered percentage 
complete. Estimating a percentage of work or time complete is an 
inexact science, whereas activity managers and schedulers are 
accustomed to estimating remaining duration. For instance, task 
managers may confuse inputs and outputs, assuming that if they have 
worked 7 days on a 10-day activity, they must be 70 percent finished. 
In addition, asking activity managers for information on actual 
duration and remaining duration is a more natural question than 
requesting a subjective measure of time passed. For example, a response 
of 80 percent complete on a 5-day activity may indicate that it is 
almost finished, even if the team has left all the difficult work for 
the last day. 

The subjectivity of percentage complete estimates becomes more apparent 
the longer the activity's duration. While 25 percent complete may be a 
viable estimate for a 4-day activity, it is an entirely ambiguous 
progress measure for a 50-day activity. Finally, percentage complete is 
based on the expected duration of an activity, which is variable. The 
exception is in updating LOE activities that represent support 
activities that are not associated with any discrete product. Level of 
effort activities are typically described as percentage complete by the 
total duration of the activities they support. However, LOE activities 
are best linked to the physical percentage complete of the work they 
support. For example, quality control responsibilities associated with 
pipefitting or pouring concrete should be hammocked with their 
respective activities, and the LOE efforts should be based on the 
work's physical percentage complete, not the elapsed time. 

Updating durations generally implies that work performed by a single 
resource or multiple assigned resources is completed at the same pace 
and, in terms of percentage complete, is equal to the time spanning the 
start date and the status date. That is, if the activity is 50 percent 
complete, then all assigned resources are generally assumed to have 
completed 50 percent of their work. This is a simplifying assumption 
that may work well for some program plans. 

Other program managers may wish to update work by resources to track 
actual effort by resource unit or group. Tracking actual work progress 
requires more time and is more complex than updating durations, but it 
provides more accurate historical data and higher-quality forecasts of 
remaining effort. Similar to updating durations, updating work progress 
requires entering actual work performed as well as forecasts for 
remaining work. The scheduling software then calculates percentage work 
complete. 

Regardless of whether a schedule's progress is marked by duration or 
work, data should be relevant and should adhere to the definitions set 
forth in the governing process. Team members and management should have 
consistent, documented definitions of what constitutes an activity's 
start, its finish, and its meaningful progress. For example, the actual 
start date of an activity could be the preparatory research or it could 
mean only the start of significant work that directly affects the 
associated product. Likewise, the actual finish date could be the point 
at which no further work whatsoever is charged to that particular 
activity or it could simply mean the point at which the activity's 
successor can begin. In general, opening an activity without the 
resources to do the work just to record some progress is a poor 
practice. 

Updating the Status of Remaining Work: 

Time preceding the status date represents history. All unfinished work 
and activities that have not started should be rescheduled to occur on 
or after the status date. If unfinished work remains in the past, the 
schedule no longer represents a realistic plan for completing the 
project, and team members will lose confidence in the model. Case study 
18 shows an example of activities within a schedule that were not 
properly updated. 

Case Study 18: Updating a Schedule Using Progress and Logic, from 
Aviation Security, GAO-11-740: 

Officials from the Transportation Security Administration's Electronic 
Baggage Screening Program stated that they had conducted weekly 
meetings on the schedule and had updated the status accordingly. From 
these weekly meetings, officials generated weekly reports that 
identified key areas of concern with regard to schedule shifts and 
their potential effects on milestones. However, our analysis showed 
that 30 activities (6 percent of the remaining activities) should have 
started and finished according to the schedule status date but did not 
have actual start or actual finish dates. 

In addition, the schedule's critical path began in a data collection 
activity that was not logically linked to any predecessor activities, 
had a constrained start date, and was marked as 100 percent complete on 
June 18, 2010--2 months into the future, according to the schedule 
status date of April 16, 2010. 

The schedule also contained 43 activities (9 percent of the remaining 
activities) with actual start and actual finish dates in the future 
relative to the schedule status date. 

The schedule should be continually monitored to determine when 
forecasted completion dates differ from the planned dates, which can be 
used to determine whether schedule variances will affect downstream 
work. 

GAO, Aviation Security: TSA Has Enhanced Its Explosives Detection 
Requirements for Checked Baggage, but Additional Screening Actions Are 
Needed, [hyperlink, http://www.gao.gov/products/GAO-11-740] 
Washington, D.C.: July 11, 2011). 

Progress Records: 

Schedules should be statused by reference to progress records for the 
current time period. Progress records are the sources from which 
schedulers update the schedule. They are a documentation trail between 
actual experience on the activity and the progress recorded in the 
schedule, including actual start and finish dates, the number of 
resources required, and the amount of work performed to accomplish the 
activity. Progress records can take many forms according to individual 
agency or contract requirements. Typically, the document that keeps the 
activity owner aware of information related to current and upcoming 
activities is the same form that is filled out with actual data by the 
owner and returned to the scheduler for updating the schedule (commonly 
known as a "turnaround" document). This document contains pertinent 
activity information such as its name, unique ID, original and 
remaining durations, planned and actual start and finish dates, and 
float. For the purposes of updating the schedule for the current 
progress period, the progress record should include, at a minimum, 

* the actual start date if started, or the planned start date if not 
started; 

* the actual finish date if finished, or the planned finish date if not 
finished; 

* actual duration or actual work performed; 

* an estimate of the remaining duration or remaining work; and: 

* an estimate of percentage complete for LOE activities. 

It is important to collect the correct type of data during statusing. 
Individuals directly managing or performing the work should report 
progress. If activities are updated by duration, team members should 
not provide work updates; likewise, if activities are updated by work, 
team members should not provide duration updates. 

Progress records are particularly useful for reviewing remaining 
duration estimates during attempts to accelerate the schedule (this 
concept is discussed in Best Practice 10). Upon completion of the 
project, progress records will provide the historical data necessary 
for resource, work, and productivity assumptions for future analogous 
projects. If sufficient attention is paid to recording the way work is 
actually performed, the resulting archived data will lead to improved 
accuracy and quality control of similar future projects. 

Adding Activities: 

Activities may be added to represent unplanned work, reflect the actual 
order of completion of planned work, or refine existing long-duration 
activities. As with all existing activities, new activities should be 
given a unique description and be mapped to the appropriate activity 
codes. New activities should be reviewed for completeness of 
predecessor and successor logic, resource assignments, and the impacts 
on the critical path and float calculations. Inserting additional 
activities may be subject to the program's schedule change control 
process. 

Out-of-Sequence Logic: 

Rescheduling activities may require adjusting network logic to explain 
why an activity did not start as planned, particularly if any of its 
successors have started or been completed. An activity's starting 
before its predecessor activity has completed is out-of-sequence 
progress. Out-of-sequence progress is common and should be expected, 
because some activity managers know they can safely start their 
activities, sometimes challenging their predecessor activity teams to 
speed up. When out-of-sequence progress occurs, managers and schedulers 
may choose to retain or override the existing network logic. 

Retained Logic: 

In the case of retained logic, work on the activity that began out of 
sequence is stopped until its predecessor is completed. As much as 
possible of the original network logic is preserved because the 
remainder of the out-of-sequence activity is delayed until the 
predecessor finishes, to obey its original sequence logic. 

Progress Override: 

In progress override, work on the activity that began out of sequence 
is permitted to continue, regardless of original predecessor logic. 
Actual progress in the field supersedes the plan logic, and work on the 
out-of-sequence activity continues. The predecessor and successor 
activities may now be executed in parallel, or the original logic on 
the activities is altered to model their new, more realistic, 
dependencies. Figure 44 below shows the original plan for conducting 
the interior finishes of the house construction project. 

Figure 44: The Original Plan for Interior Finishing: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install tile in bathroom and kitchen; 
Start: 5-16-13; 
Finish: 5-20-13. 

Activity name: Install interior doors; 
Start: 5-21-13; 
Finish: 5-22-13. 

Activity name: Install interior door, window, and baseboard trim; 
Start: 5-23-13; 
Finish: 5-31-13. 

Activity name: Install carpeting and wood flooring; 
Start: 6-3-13; 
Finish: 6-10-13. 

Source: GAO. 

[End of figure] 

For this example we will assume that the status date is May 23 and that 
"install tile in bathroom and kitchen" has completed on time. No 
progress was made on "install interior doors" so its start date is 
rescheduled for May 24. However, its successor activity "install 
interior door, window, and baseboard trim" did start on May 22 and two 
carpenters accomplished 32 hours of work. This is illustrated in figure 
45 by the status date (green vertical dashed line) and white activity 
bars that represent actual accomplished effort. If the schedule is 
statused according to retained logic, the remaining work for "install 
interior door, window, and baseboard trim" is deferred until the 
interior doors are installed. In figure 45, 2 days of actual duration 
is recorded for the "install interior door, window, and baseboard trim" 
activity, but the remaining duration is rescheduled to begin after 
"install interior doors" finishes. This start-stop-resume approach may 
not be an efficient way to install interior trim but it may be viewed 
as important given the reliance of the trimming activity on the 
installation of interior doors. 

Figure 45: Retained Logic: 

[Refer to PDF for image: illustration of Gantt chart] 

Activity name: Install tile in bathroom and kitchen; 
Start: 5-16-13; 
Finish: 5-20-13; 
Actual start: 5-16-13; 
Actual finish: 5-20-13; 
Duration (in days): 3; 
Actual duration (in days): 3. 

Activity name: Install interior doors; 
Start: 5-24-13; 
Finish: 5-28-13; 
Actual start: NA; 
Actual finish: NA; 
Duration (in days): 2; 
Actual duration (in days): 0. 

Activity name: Install interior door, window, and baseboard trim; 
Start: 5-22-13; 
Finish: 6-3-13; 
Actual start: 5-22-13; 
Actual finish: NA; 
Duration (in days): 6; 
Actual duration (in days): 2. 

Activity name: Install carpeting and wood boring; 
Start: 6-4-13; 
Finish: 6-11-13; 
Actual start: NA; 
Actual finish: NA; 
Duration (in days): 6; 
Actual duration (in days): 0. 

[End of figure] 

Source: GAO. 

If the schedule is statused according to progress override, the work 
for "install interior door, window, and baseboard trim" continues, 
regardless of the original plan's logic. This concept is illustrated in 
figure 46. Two days of actual duration is recorded for the trimming 
activity, and the remaining duration is scheduled to occur in parallel 
with "install interior doors." While the progress override accelerates 
the overall construction schedule by 2 working days, the time savings 
may not be feasible for at least three reasons. First, it assumes that 
"install interior door, window, and baseboard trim" does not depend on 
"install interior doors" finishing as the original plan dictated. 
Second, it assumes that resources are available to work on both the 
interior door installation and the interior trim installation. But both 
activities rely on two carpenters; the concurrent activities now 
require four carpenters on May 24 and May 28. Finally, the installation 
of carpeting and wood flooring, originally scheduled to begin on June 
4, is now scheduled to start on May 31. It may be unrealistic to assume 
that the flooring material and the floor installers will be available 2 
days earlier than expected with less than a week's notice. 

Figure 46: Progress Override: 

[Refer to PDF for image: illustration of Gantt chart] 
    
Activity name: Install tile in bathroom and kitchen; 
Start: 5-16-13; 
Finish: 5-20-13; 
Actual start: 5-16-13; 
Actual finish: 5-20-13; 
Duration (in days): 3; 
Actual duration (in days): 3. 

Activity name: Install interior doors; 
Start: 5-24-13; 
Finish: 5-28-13; 
Actual start: NA; 
Actual finish: NA; 
Duration (in days): 2; 
Actual duration (in days): 0. 

Activity name: Install interior door, window, and baseboard trim; 
Start: 6-30-13; 
Finish: 5-22-13; 
Actual start: 5-22-13; 
Actual finish: NA; 
Duration (in days): 6; 
Actual duration (in days): 2. 

Activity name: Install carpeting and wood flooring; 
Start: 5-31-13; 
Finish: 6-7-13; 
Actual start: NA; 
Actual finish: NA; 
Duration (in days): 6; 
Actual duration (in days): 0. 

[End of figure] 

Source: GAO. 

In general, regardless of how management wishes to proceed with the 
work related to the out-of-sequence activity, the logic relationship 
between activities in the schedule should be repaired to show the order 
in which the activities were actually carried out. If the original 
logic is allowed to remain, it will produce an inaccurate schedule. For 
example, the F-S logic between the "install interior doors" and 
"install door, window, and baseboard trim" activities should be 
deleted. The successor logic of "install interior doors" should be 
reviewed and linked to a new correct successor, perhaps "install 
carpeting and wood floors." 

Retained logic and progress override are options in scheduling software 
that must be properly set before updating the status of the schedule. 
Each approach represents a different philosophy on how to manage 
unexpected developments in the project, and they can have vastly 
different effects on forecasted dates. It is recommended that the 
scheduler and activity leads examine each instance of out-of-sequence 
progress to determine the correct response case by case. While out-of-
sequence activities are common, they should nonetheless be reported, 
and an analysis of the effect on key milestone dates is recommended 
before out of sequence activities are formally addressed. Out-of-
sequence activities may represent risk or potential rework, because 
knowledge or products from the predecessor activity were not complete 
and available to the successor activity. 

Verifying Status Updates and Schedule Integrity: 

Once the schedule has been statused, management should review the 
inputs to verify the updates and assess the effect on the plan. The 
schedule should be reviewed to ensure the following: 

* All activities completed prior to the status date represent finished 
work and therefore should have actual start and finish dates. They 
should be statused as 100 percent complete with actual durations or 
actual work values. 

* In-progress activities should have an actual start date and all work 
scheduled before the status date is expressed as actual duration or 
actual effort. All remaining work should be scheduled beyond the status 
date. 

* Activities planned beyond the status date represent future activities 
and therefore should not have actual start or actual finish dates. They 
also should not have actual duration or work values. 

* Out-of-sequence activities are addressed purposefully and case by 
case through either retained logic or progress override. 

* Schedule recalculations from changes in estimated work, assigned 
resources, or duration are verified to ensure meaningful and accurate 
calculations. 

* Resource assignments are assessed for the coming period, and 
assignments for delayed or out-of-sequence activities are reevaluated 
for potential overallocations. In addition, resource calendars should 
be updated to reflect current availability. 

* Date constraints are revisited and removed if possible. In 
particular, soft constraints should be removed if they can no longer 
affect an activity's start or finish date. 

* At least one in-progress activity is critical. If not, it is most 
likely that date constraints or external dependencies are separating 
subsequent from the in-progress activities. Such breaks in the critical 
or longest path represent weak or incomplete logic, causing a lack of 
credibility in the identity of the path and the schedule dates. 

Schedule integrity should also be assessed in the schedule update 
process. Verifying the integrity of the schedule after each update will 
ensure that the schedule remains reliable after activities are added, 
removed, broken down into smaller activities, or sequenced differently 
from the last period. Common schedule health measures are listed in 
Appendix III. 

It is unlikely in a major program that all activities will be fully 
identified. As a program changes and completes phases, some activities 
are overtaken by events and others are generated from lessons learned. 
Changes made to a schedule, whether minor or major, may need to undergo 
formal change control according to contract requirements or internal 
process controls. 

The current schedule, once management approves it, should be assigned 
a version number and archived. This ensures that all status updates can 
be traced and guarantees that all stakeholders are using the same 
version of the current schedule. 

Schedule Narrative: 

Regardless of whether a change triggers schedule change control, all 
changes made to the schedule during statusing should be documented, and 
salient changes should be justified along with their likely effect on 
future planned activities. A schedule narrative should accompany the 
updated schedule to provide decision makers and auditors a log of 
changes and their effect, if any, on the schedule timeframe. The scope 
of the schedule narrative will vary with project and contract 
complexity, but should contain at a minimum, 

* the status of key milestone dates, including the program finish date; 

* the status of key hand-offs or giver/receiver dates; 

* explanations for any changes in key dates; 

* changes in network logic, including lags, date constraints, and 
relationship logic, and their effect on the schedule; 

* a description of the critical paths, near-critical paths, and longest 
paths along with a comparison to the previous period's paths; and: 

* a description of any significant scheduling software options that 
have changed between update periods, such as the criticality threshold 
for total float and progress override versus retained logic and whether 
or not resource assignments progress with duration. 

Significant variances between planned and actual performance, as well 
as actual and planned logic, should be documented and understood. 
Assessing the updated critical path is particularly crucial. It should 
be compared to the critical path from the baseline and the last 
period's current schedule and assessed for reasonableness. Total float 
should be examined and compared to the last period's current schedule 
to identify trends. For activities that are behind schedule, the 
remaining duration should be evaluated and the delay's effect on 
succeeding activities in the network should be understood. If a delay 
is significant, management should develop a plan to examine the options 
to recover from the schedule slip. In addition, near-critical paths 
should be assessed and compared against previous near-critical paths. A 
decrease in total float values on a near-critical path indicates 
activities that are slipping; the path may soon be critical, because 
float will not be available for successive activities on that path. 

Reporting and Communication: 

As noted earlier, a schedule is a fundamental program management tool 
that specifies when work will be performed in the future and how well 
the program is performing against an approved plan. It is therefore 
particularly important that all stakeholders be able to view 
information stored in the schedule related to their specific roles and 
needs in order to successfully manage and execute the plan. 
Stakeholders include, among others, project team members, control 
account managers, government customers, resource managers, 
subcontractors, project sponsors, finance specialists, and decision 
makers. Each stakeholder requires a different level and type of 
information that will depend on whether the stakeholder is internal to 
the project or external. Reports can encompass actual data (status), 
actual versus planned data (progress), and predictive data (forecasts). 
A well-constructed, comprehensive schedule is a database that contains 
actual, planned, and forecast activity and resource and cost 
information. It will be able to report reliable data quickly at all 
levels of detail. 

The regularity of schedule reporting and the level of detail that is 
reported will naturally vary by stakeholder and project complexity. At 
the level of senior decision maker, high-level summary trend charts and 
key milestone schedules reporting monthly or quarterly progress will be 
most useful. These reports typically include progress and forecast 
information on contractual and deliverable milestones and major project 
phases, as well as summary critical path and contingency information. 
High-level trend information is also useful, such as key milestone 
completions, contingency burn rate, and resource availability. In 
addition, the level of detail will depend on the complexity and risk of 
certain WBS items. For example, a series of complex activities on the 
critical path may be reported to program management in more detail than 
less complex, noncritical activities. 

Best Practices Checklist: Updating the Schedule Using Actual Progress 
and Logic: 

* Schedule progress is recorded periodically and the schedule has been 
updated recently. Schedule status is updated with actual and remaining 
progress. 

* Schedule status is based on progress records for the current time 
period; they include pertinent activity information such as name, 
unique ID, original and remaining durations, planned and actual start 
and finish dates, and float. 

* The status date (or data date) denoting the date of the latest update 
to the schedule is recorded. 

* At least one in-progress activity is critical. 

* No activities precede the status date without actual start or finish 
dates and actual effort up to the status date. No activities beyond the 
status date have actual start or finish dates or actual effort. 

* Activities that are behind schedule by the status date have a 
remaining duration estimate and the delay's effect has been assessed. 

- If the delay is significant, plans to recover the implied schedule 
slip have been evaluated and implemented, if so decided. 

- Resources are reviewed and may be reassigned, depending on schedule 
progress. 

- When possible, LOE activities are linked to the physical percentage 
complete of the work they support. 

* When possible, actual work progress is tracked rather than simply 
updating durations. 

* Responsibility for changing or statusing the schedule is assigned to 
someone who has the proper training and experience in CPM scheduling. 

* Changes that were made to the schedule during the update have been 
documented. 

* New activities are reviewed for completeness of predecessor and 
successor logic, resource assignments, and effects on the critical path 
and float calculations. 

* Activities that have started or completed out of sequence have been 
addressed using either retained logic or progress override to reflect 
the order in which the activities were actually carried out. 

* Management reviews schedule updates and verifies and assesses effects 
on the plan. Significant variances between planned and actual 
performance, as well as actual and planned logic, are documented and 
understood. 

* The schedule structure is examined after each update to ensure that 
logic is not missing or broken, all date constraints are necessary, and 
no artifacts impede the ability of the schedule to dynamically forecast 
dates. 

* The current schedule, once management approves it, is assigned a 
version number and archived. 

* A schedule narrative accompanies each status update and includes: 

- the status of key milestone dates, including the program finish date; 

- the status of key hand-offs or giver/receiver dates; 

- explanations for any changes in key dates; 

- changes in network logic, including lags, date constraints, and 
relationship logic and their effect on the schedule; 

- a description of the critical paths, near-critical paths, and longest 
paths along with a comparison to the previous period's paths; and: 

- any significant scheduling software options that have changed between 
update periods, such as the criticality threshold for total float; 
progress override versus retained logic; or whether resource 
assignments progress with duration. 

[End of Best Practice 9] 

Best Practice 10: Maintaining a Baseline Schedule: 

[Side bar: Best Practice 10: A baseline schedule is the basis for 
managing the project scope, the time period for accomplishing it, and 
the required resources. The baseline schedule is designated the target 
schedule, subject to a configuration management control process, 
against which project performance can be measured, monitored, and 
reported. The schedule should be continually monitored so as to reveal 
when forecasted completion dates differ from planned dates and whether 
schedule variances will affect downstream work. A corresponding 
baseline document explains the overall approach to the project, 
defines custom fields in the schedule file, details ground rules and 
assumptions used in developing the schedule, and justifies 
constraints, lags, long activity durations, and any other unique 
features of the schedule. End of side bar] 

Baseline and Current Schedules: 

Establishing a baseline schedule is a strong support to effective 
management. A baseline schedule represents the original configuration 
of the program plan and signifies the consensus of all stakeholders 
regarding the required sequence of events, resource assignments, and 
acceptable dates for key deliverables. It is consistent with both the 
project plan and the project budget plan and defines clearly the 
responsibilities of project performers. The baseline schedule includes 
not only original forecasts for activity start and finish dates but 
also the original estimates for work, resource assignments, critical 
paths, and total float. 

The baseline schedule is not the same as the current schedule. The 
current schedule is updated from actual performance data, as described 
in Best Practice 9. Therefore, it provides the latest depiction of 
performance and accomplishments, along with the latest forecast of 
remaining dates and network logic. The baseline schedule represents the 
program's commitments to all stakeholders, while the current schedule 
represents the actual plan to date. 

The current schedule is compared to the baseline schedule to track 
variances from the plan. Deviations from the baseline inform management 
that the current plan is not following the original plan as agreed on 
by all stakeholders. Deviations imply that the current approach to 
executing the project needs to be altered to align the program to the 
original plan or that the plan from this point forward should be 
altered. 

Comparing the current status of the schedule to the baseline schedule 
can help managers identify the root cause of the deviation, thereby 
allowing them to target specific areas such as resource assignments, 
network logic, and other factors for immediate mitigation. Without a 
formally established baseline schedule to measure performance against, 
management lacks the ability to identify and mitigate the effects of 
unfavorable performance. 

The final version of the current schedule--the "as-built" schedule--
represents the plan as executed to completion. Particular care should 
be taken to archive this final version. Once the project has been 
completed, the as-built schedule becomes a database of the actual 
sequence of events, activity durations, required resources, and 
resource productivity. These can be compared to the original plan for 
an assessment of lessons learned, and the data become a valuable basis 
of estimate input for schedule estimates of future analogous projects. 

As-built schedules are also useful for creating and validating 
fragmentary networks, or "fragnets." A fragnet is a subordinate network 
that represents a sequence of activities typically related to 
repetitive effort. Subordinate networks can be inserted into larger 
networks as a related group of activities. For example, a related group 
of activities may occur for each systems test, regardless of the actual 
product. In this case, a fragnet related to systems test, representing 
a well-known sequence of events and expected duration, may be inserted 
into various product schedules. 

The baseline should be set promptly after a program begins. A schedule 
baseline is typically in place between 3 and 6 months of contract 
award, although the timing will depend on contract size and type, 
requirements, and risk [Footnote 30] Projects should operate against an 
interim baseline until the schedule baseline is in place. The level of 
detail in the baseline schedule also depends on contract type, industry 
type, risk, and agency guidelines. For example, management may choose 
to baseline the entire detailed IMS or only intermediate-level summary 
activities leading to key milestones. The greater the baselined detail, 
the greater will be the understanding of performance, variances, 
forecasts, and assessed effects of potential changes--yet this must be 
balanced with the time necessary to formally approve, change, and track 
at that level. 

In addition, baseline creation and approval may take place in concert 
with the project's rolling wave process. That is, as periods of summary 
and intermediate-level planning packages are planned in greater detail, 
the baseline is updated to reflect that detail. The intent is that once 
formally approved and archived, the baseline schedule reflects the 
agency's commitment to allocating resources and becomes the basis 
against which actual performance and accomplishments can be measured, 
monitored, and reported. The parties should agree that the baseline 
refers to the maintenance of a schedule for meeting contractual 
deliverable and project control milestones. It typically does not 
constitute a strict adherence to estimates of activity durations, 
resources assignments, or logic. 

Baseline Document: 

The accuracy of the IMS as a model for the project depends on a mutual 
understanding among all stakeholders of the schedule's structure, use, 
and underlying assumptions. Thorough documentation is essential for 
validating and defending a baseline schedule. A well-documented 
schedule can present a convincing argument for a schedule's validity 
and can help answer decision makers' and oversight groups' probing 
questions. A well-documented schedule is essential if an effective 
independent review is to ensure that it is valid and credible. 

A schedule baseline document is a single document that defines the 
organization of the IMS, describes the logic of the network, describes 
the basic approach to managing resources, and provides a basis for all 
parameters used to calculate dates. As noted in Best Practice 1, the 
government program management office is responsible for integrating all 
government and contractor work into one comprehensive program plan. The 
schedule baseline document is therefore created and approved by the 
government program management office once the schedule baseline is 
approved. While the baseline document will not be updated as often as 
the schedule narrative described in Best Practice 9, it should be 
considered a living document in that it reflects updates to the 
baseline schedule. Both the baseline schedule and baseline document 
should be referenced and updated as the project progresses in 
accordance with the established change process. At a minimum, the 
baseline document should include the following. 

* A project overview or a general description of the project, including 
general scope and key estimated life cycle dates, and descriptions of 
each stakeholder, including the project owner, prime and 
subcontractors, and key stakeholder agencies. 

* A general description of the overall execution strategy, including 
the type of work to be performed, and contracting and procurement 
strategies. 

* A description of the overall structure of the IMS, including the 
scope and purpose of subprojects, those responsible for each 
subproject, the relationship between subprojects, a WBS dictionary, the 
status delivery dates for each subproject, and a list of key hand-off 
products and their estimated dates. In addition, it refers to relevant 
contract data requirements lists (CDRLs) and data item descriptions 
(DIDs) associated with schedules. 

* A description of the settings for key options for the relevant 
software, such as criticality threshold, progress override versus 
retained logic, and the calculation of critical paths and whether work 
progresses with duration updates. 

* A definition and justification in the baseline document of all ground 
rules and assumptions used to develop the baseline, including items 
specifically excluded from the schedule. If rolling wave planning is 
used, key dates or milestones for detail and planning periods are 
defined. 

* A justification of each use of a lag and date constraint that is 
clearly associated with the activities that are affected. Missing 
successor or predecessor logic is also justified. 

* The documentation of each project, activity, and resource calendar, 
along with a rationale for workday exceptions (holidays, plant 
shutdowns, and the like), working times, and planned shifts. 

* An explanation or rationale for the basic approach to estimating key 
activity durations and justification of the estimating relationship 
between duration, effort, and assigned resource units, to an 
appropriate level of detail. 

* Definitions of all acronyms and abbreviations. 

* A table of the purposes of custom fields. Any LOE activities in the 
IMS are clearly marked. 

* A description of resources used in the plan and the basic approach 
for updating resource assignments, along with schedule updates and 
average and peak resource demand projections. The document defines all 
resource groups used within the schedule and justifies planned 
overallocations to an appropriate level of detail. In addition, key 
material and equipment resources are described in the context of their 
related activities. 

* A description of critical paths, longest paths, and total float. A 
discussion of the critical paths, including justification for the 
criticality threshold, rationale for single or multiple critical paths, 
and justification for any gaps in a noncontinuous critical path. If the 
schedule has late-date constraints, a description of the longest path 
is included. In addition, abnormally large amounts of total float are 
justified. 

* A description of the critical risks as prioritized in a quantitative 
schedule risk analysis, along with a discussion of the appropriate 
schedule contingency. 

* A detailed description of the updating and schedule change management 
processes. Any additional documentation that governs them is 
referenced. 

Thorough documentation helps with analyzing changes in the program 
schedule and identifying the reasons for variances between estimates 
and actual results. In this respect, baseline documentation contributes 
to the collection of cost, schedule, and technical data that can be 
used to support future estimates. 

The Change Process: 

The baseline and current schedules should be subjected to a change 
control process. A control process governs when and how technical and 
programmatic changes are applied to the baseline, as well as the 
content of the current IMS. A proper change control process helps 
ensure that the baseline and current schedule are accurate and 
reliable. Without a documented, consistently applied schedule change 
control process, project staff might continually revise the schedule to 
match performance, hindering management's insight into the true 
performance of the project. Undocumented or unapproved changes hamper 
performance measurement and may result in inaccurate variance 
reporting, inconsistent stakeholder versions of the plan, and 
unreliable schedule data. Moreover, if changes are not controlled and 
fully documented, performance cannot be accurately measured against the 
original plan. 

The extent to which the IMS is subject to a change control process is 
decided by program management and depends on the project size, scope, 
risk, and complexity. Less complex projects may subject only key 
milestones or high-level WBS activities to the change control process, 
so that changes to supporting detailed activities do not require change 
approval. For more complex and tightly controlled schedules, lower-
level detail activities as well as network dependencies may also be 
subject to change approval. 

The current schedule, once management approves it, should be assigned a 
version number and archived. This ensures that all status updates can 
be traced and guarantees that all stakeholders are using the same 
version of the current schedule. 

Changes to the baseline schedule should be limited to revisions for new 
or reduced scope or for formal replanning. At times, however, 
management may conclude that the remaining schedule target for 
completing a program is significantly insufficient and that the current 
baseline is no longer valid for realistic performance measurement. The 
purpose of a schedule rebaselining is to restore management's control 
of the remaining effort by providing a meaningful basis for performance 
management. 

Working to an unrealistic baseline could make an unfavorable schedule 
condition worse. For example, if variances become too big, they may 
obscure management's ability to discover newer problems that could 
still be mitigated. To quickly identify new variances, a schedule 
rebaseline normally eliminates historical variances. A rebaselined 
schedule should be rare. If a program is recurrently rebaselined, it 
may be that the scope is not well understood or simply that program 
management lacks effective discipline and is unable to develop 
realistic estimates. Case study 19 highlights a complex, highly 
detailed schedule that was successfully updated periodically according 
to a defined process. 

Case Study 19: Baseline Schedule, from 2010 Census, GAO-10-59: 

For the 2010 Decennial Census schedule, the U.S. Census Bureau had 
implemented processes around its master schedule that complied with a 
number of scheduling process criteria that are important to maintaining 
a schedule that is a useful management tool. The Bureau ensured a 
complete scope of the schedule with input from stakeholders throughout 
the agency, with reviews of previous schedules, that built on a number 
of census tests during the decade. As a result, the schedule was the 
primary source for senior managers to determine weekly what census 
activity was ahead of or behind schedule, and it provided a resource 
for determining any effect on the overall project of delays in major 
activities. 

The Bureau had documented and implemented a formal process for keeping 
the data in the schedule current. Staff within each Bureau division 
were responsible for ensuring that schedule activities had their status 
updated weekly. Staff updated the actual start and finish dates, the 
percentage of each activity completed so far, and estimates of the time 
remaining to complete each activity in progress. The Bureau was 
recording status information on an average of more than 1,300 
activities in the schedule ongoing during any given week, generating 
historical data that could provide valuable input to future schedule 
estimates. 

In addition, the Bureau implemented a formal change control process 
that preserved a baseline of the schedule so that progress could be 
meaningfully measured. The Bureau's criteria for justifying changes 
were clearly documented and required approval by a team of senior 
managers and acknowledgment of the effect by each team affected within 
the Bureau. Since the master schedule was baselined in May 2008, about 
300 changes had been approved. Even corrections to the schedule for 
known errors, such as incorrect links between activities, had to be 
approved through the change control process, helping to ensure the 
integrity of the schedule. 

GAO, 2010 Census: Census Bureau Has Made Progress on Schedule and 
Operational Control Tools, but Needs to Prioritize Remaining System 
Requirements, [hyperlink, http://www.gao.gov/products/GAO-10-59] 
(Washington, D.C.: November 13, 2009). 

Baseline Analysis: 

Schedules deviate from the baseline as a program is executed. Changes 
in resource availability, late or early key deliveries, unexpected 
additional work activities, and risks can contribute to deviation. 
Although they are often perceived as something bad, negative variances 
provide valuable insight into program risk and its causes. Positive 
variances can indicate problems as well. For example, early starts may 
cause issues with out-of-sequence logic and can disrupt the scheduling 
of future resources. Understanding the types of activities that have 
started earlier or later than planned is vital as well. For instance, 
positive variances may not be desirable if only relatively easily 
accomplished activities are completed early while critical activities 
continue to be delayed. Variances empower management to decide how best 
to handle risks. Schedule deviations from the baseline plan give 
management at all levels information about where corrective action is 
needed to bring the program back on track or to update completion 
dates. 

A schedule variance does not necessarily mean program delay; it means 
that work was not completed as planned. Negative schedule variances 
should be investigated to see if the effort is on the critical path. If 
it is, then the whole program will be delayed. In addition, activities 
that vary significantly from their baseline may create a new critical 
path or near-critical path. 

A schedule Gantt chart can be used to show baseline dates, forecasted 
dates, and actual progress to date for each activity, as shown in 
figure 47. In the figure, the gray activity bar shows the activity 
baseline dates. The black bar above the baseline dates represents 
forecasted dates, and the white bar represents actual effort to date, 
including the actual start date. The status date is represented by the 
vertical dashed green line. The difference between the baseline start 
date and the actual start date is the start variance; the difference 
between the baseline finish and forecasted finish is the (forecasted) 
finish variance. 

Figure 47: Baseline, Actual, and Forecasted Dates: 

[Refer to PDF for image: illustration of Gannt chart] 

Activity name: Install first floor joists and decking; 
Start: 3-12-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Start: 3-14-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Start: 3-15-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Start: 3-19-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Start: 3-25-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Start: 3-27-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Start: 3-14-13; 
Actual start: NA; 
Total float (in days): 7. 

Activity name: Rough grade property; 
Start: 3-19-13; 
Actual start: NA; 
Total float (in days): 7. 

Activity name: Form and pour driveway; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 2. 

Activity name: Framing complete; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

[End of figure] 

Source: GAO. 

Carefully monitoring the schedule allows for quickly determining when 
forecasted completion dates differ from the planned dates. In this 
respect, progress to date can be evaluated on whether it has met or not 
met planned targets. Activities may be resequenced or resources 
realigned. It is also important to determine whether schedule variances 
are affecting successive work activities. For example, a schedule 
variance may compress remaining activities' durations or cause 
"stacking" of activities toward the end of the program, to the point at 
which it is no longer realistic to predict success. 

Consider again the activities in the framing phase of the house 
construction project, given in figure 48. Red activities are forecasted 
to be critical and black activities will have 2 to 7 days of total 
float on their paths. The gray bars below the red and black activity 
bars represent the baseline start and finish dates. The original plan 
is for the installation of the first floor joists and decking to begin 
on March 12 and to complete framing by April 2. Before any progress is 
made on the project, baseline dates and forecast dates are the same. 

Figure 48: Baselined Activities: 

[Refer to PDF for image: illustration of Gannt chart] 

Activity name: Install first floor joists and decking; 
Start: 3-12-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Start: 3-14-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Start: 3-15-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Start: 3-19-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Start: 3-25-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Start: 3-27-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Start: 3-14-13; 
Actual start: NA; 
Total float (in days): 7. 

Activity name: Rough grade property; 
Start: 3-19-13; 
Actual start: NA; 
Total float (in days): 7. 

Activity name: Form and pour driveway; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 2. 

Activity name: Framing complete; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

Source: GAO. 

[End of figure] 

Figure 49 gives the current schedule for the same plan, now statused 
through March 25. The blue dashed vertical line represents the current 
status date, and the white horizontal bar on activities represents 
progress to date on each activity. 

Figure 49: Updated Status Compared with Baseline: 

[Refer to PDF for image: illustration of Gannt chart] 

Activity name: Install first floor joists and decking; 
Start: 3-12-13; 
Actual start: 3-12-13; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Start: 3-14-13; 
Actual start: 3-14-13; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Start: 3-15-13; 
Actual start: 3-15-13; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Start: 3-19-13; 
Actual start: 3-19-13; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Start: 3-25-13; 
Actual start: 3-25-13; 
Total float (in days): 1. 

Activity name: Install roof decking; 
Start: 3-27-13; 
Actual start: NA; 
Total float (in days): 1. 

Activity name: Exterior backfill basement walls; 
Start: 3-25-13; 
Actual start: 3-25-13; 
Total float (in days): 0. 

Activity name: Rough grade property; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Form and pour driveway; 
Start: 4-1-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Start: 4-3-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 3. 

Activity name: Framing complete; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

Source: GAO. 

[End of figure] 

As seen in the current schedule, not only did the "exterior backfill 
basement walls" start 7 days late but also its effort is expected to 
take 8 hours longer than originally planned. The 7-day late start and 
the extra effort consume the available 7 days of total float on the 
path, and the activities "exterior backfill basement walls" and "rough 
grade property" are now critical. The activities "install roof trusses" 
and "install roof decking" are no longer critical, because the delay in 
the backfill work created a day of total float for those activities. 
The start variance of "exterior backfill basement walls" is 7 days and 
the finish variance is expected to be 8 days. The effect of the 
backfill delay can clearly be seen in the variances of "rough grade 
property," "form and pour driveway," "finish excavate and pour garage 
floor," and the finish milestone "framing complete." Visually, the 
activity bars are far removed from their original baselined positions 
in the timeline. 

In this situation, the general contractor has several possible 
solutions to get the construction schedule back on track: 

* Adjust the working calendar. Forming and pouring the driveway could 
take place over the weekend. Alternatively, the excavators could work 
overtime to finish backfilling by the morning of March 28. Both options 
assume that resources are available for overtime work on short notice 
and that the project can afford the additional labor rate associated 
with overtime. 

* Increase resources. Adding an additional worker to the backfill 
activity would reduce the activity's duration by 1 day. Again, this 
assumes that additional resources are available on short notice. The 
additional labor cost is unavoidable because of the additional work 
required, but this option leaves the labor cost at the normal rate. 

* Perform activities concurrently. The general contractor could 
convince the excavator to begin grading the property a day earlier, 
when the backfilling is under way. However, because both activities 
require three excavators, as well as the same unique piece of 
equipment, resources will more than likely not be available. 

* Do nothing and allow the framing to complete a day late. This assumes 
that the negative float of 1 day will be addressed at some point beyond 
framing, perhaps by adding resources during interior rough-in. However, 
this option affects many subsequent resource assignments such as 
plumbers, electricians, HVAC specialists, carpenters, and bricklayers. 
Each assignment would have to be rescheduled if the delay is carried 
beyond framing. 

Figure 50 shows the impact of the general contractor's plan to get 
the program back on track by adding an additional resource to the 
backfill activity. This reduces the backfill activity by 1 day and 
places the "form and pour driveway" and "finish excavate and pour 
garage floor" activities back on their originally planned dates. The 
"framing complete" milestone is once again scheduled for April 2. 

Figure 50: Updated Status and Proposed Plan Compared with Baseline: 

[Refer to PDF for image: illustration of Gannt chart] 
   
Activity name: Install first floor joists and decking; 
Start: 3-12-13; 
Actual start: 3-12-13; 
Total float (in days): 0. 

Activity name: Install waterproofing on exterior basement walls; 
Start: 3-14-13; 
Actual start: 3-14-13; 
Total float (in days): 0. 

Activity name: Finish excavate and pour basement floor; 
Start: 3-15-13; 
Actual start: 3-15-13; 
Total float (in days): 0. 

Activity name: Frame first floor walls; 
Start: 3-19-13; 
Actual start: 3-19-13; 
Total float (in days): 0. 

Activity name: Install roof trusses; 
Start: 3-25-13; 
Actual start: 3-25-13; 
Total float (in days): 0. 

Activity name: Install roof decking; 
Start: 3-27-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Exterior backfill basement walls; 
Start: 3-25-13; 
Actual start: 3-25-13; 
Total float (in days): 0. 

Activity name: Rough grade property; 
Start: 3-28-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Form and pour driveway; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Finish excavate and pour garage floor; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

Activity name: Rough-in framing inspection; 
Start: 3-29-13; 
Actual start: NA; 
Total float (in days): 2. 

Activity name: Framing complete; 
Start: 4-2-13; 
Actual start: NA; 
Total float (in days): 0. 

[End of figure] 

Source: GAO. 

The threshold for reporting variances will vary by project size, 
complexity, and risk. All stakeholders should agree on the threshold 
and it should be formally defined in a governing document. In 
particular, guidance should take into account the threshold for the 
number of days the activity is delayed as well as the available float. 
If a variance exceeds the threshold, it should be reported to 
management along with a detailed description that includes the cause 
and recommended corrective actions. Note that because level of effort 
activities support work activities, they will never show a variance. 

Various schedule measures should be analyzed to identify and better 
understand the effect of schedule variances. Some examples of measures 
for comparing the current schedule to the baseline include the number 
of activities that: 

* have started early, on time, and late; 

* have finished early, on time, and late; 

* should but have not started; 

* should but have not finished; 

* should not but have started; 

* should not but have finished. 

Trend Analysis: 

Trend analysis involves collecting schedule measure data during each 
status period and plotting them over time. Sustained variances in one 
direction should be documented to assess whether the project is heading 
toward a problem and to determine whether action is necessary. Trend 
analysis provides valuable information about how a program is 
performing. Knowing what has caused problems in the past can help 
determine whether they will continue. Typical schedule measure data 
that can help managers know what is happening in their programs are: 

* comparisons of the cumulative number of completed activities to the 
cumulative number of baselined activities planned to be completed; 

* comparisons of the cumulative number of activities forecasted to be 
completed to the number of activities planned to be completed; 

* available resources over time, highlighting overallocations; 

* total float and schedule contingency tracked by status period; 

* comparisons of actual, forecasted, and baselined completed 
activities. 

The last plot is useful for identifying a potential bow wave of 
activities that will have to be completed at a higher rate than the 
rate at which activities have been previously completed. For example, 
if on average 15 detail activities have been accomplished per 2-week 
period yet forecasts imply that 30 detail activities need to be 
completed every 2 weeks to finish on time, the schedule is most likely 
unrealistic. 

A measure known as the baseline execution index (BEI) is commonly 
used in baseline analyses. It is the ratio of the number of detail 
activities that were completed to the number of detail activities that 
should have been completed by the status date. A BEI of 1 indicates 
that the project is performing according to plan. A BEI less than 1 
indicates that, in general, fewer activities are being completed than 
planned; a BEI greater than 1 indicates that, in general, more 
activities are being completed than planned. 

The BEI is an objective measure of overall performance because it 
compares actual completions to planned completions. However, it is a 
summary measure--that is, it does not provide insight into why 
activities are not being completed according to plan or take into 
account the importance of their not being completed according to plan. 
For example, delayed activities that are on the critical path or on 
near-critical paths are given weight equal to delayed activities that 
have free float available. 

To provide additional insight, the BEI can be calculated against any 
group of activities--WBS level, resource group, or activity duration. 
Finally, note that the BEI will always equal 1 at the end of a project 
if, eventually, all activities are completed. 

Strategies for Recovery and Acceleration: 

Table 1 summarizes common techniques schedulers and management teams 
use to recover schedule variances and, in general, accelerate the 
schedule. Schedule recovery is an effort by management to recover from 
the impact of interrupting events on the planned schedule. Acceleration 
refers to the technique of reducing the duration of the overall 
schedule. The focus for schedule recovery or acceleration should be on 
critical activities and, in particular, on long-duration critical 
activities. Because critical activities drive key milestone dates, the 
overall project duration will be reduced only by reducing the critical 
paths. 

Table 1: Strategies for Schedule Recovery and Acceleration: 

Technique: Crashing; 
Description: Add resources to time-dependent activities to complete 
work faster; 
Side effects: Requires additional resources and will thus increase 
costs. May also reduce quality if activities are executed faster and 
with less experienced labor. 

Technique: Fast tracking; 
Description: Involves reducing the sequential dependencies between 
activities to partial dependencies. That is, F-S logic is reduced to S-
S logic or leads are introduced to force parallel work; 
Side effects: Resources may become overallocated. Quality may also be 
reduced and risk introduced if activities ideally executed in sequence 
are now executed in parallel. 

Technique: Split long activities; 
Description: Long activities may be split into shorter activities that 
can be worked in parallel; 
Side effects: Resources may become overallocated. 

Technique: Review constraint and lag assumptions; 
Description: Reassess assumptions related to forcing activities to 
begin on certain dates; 
Side effects: If the original date constraint or lag is justified, the 
removal of the constraint or lag may not be realistic. 

Technique: Review duration estimates; 
Description: Duration estimates should be revisited using progress 
records as actual effort is recorded on the project; 
Side effects: [Empty]. 

Technique: Add overtime and reduce vacations; 
Description: Review nonworking periods and assign overtime work; 
Side effects: Costs will increase over standard labor rates. As 
overtime increases, morale will decrease, eventually affecting the 
quality of the product negatively. 

Technique: Reduce scope; 
Description: Decreasing scope reduces both duration and costs; 
Side effects: Scope is the primary reason for performing the work. May 
not be able to delete some requirements. 

Technique: Schedule contingencies; 
Description: Allocate contingency to absorb delay in accordance with 
identified risk mitigation plans; 
Side effects: Using contingency too early in a project will reduce the 
likelihood of the program's completing on time, particularly if the 
reason for a delay was not a risk that was previously identified and 
quantified. 

Source: GAO. 

[End of table] 

Regardless of what combination of methods is used for acceleration or 
recovery of variances, the schedule should be archived before the 
change. After the schedule is modified, the techniques used should be 
documented and the critical path recalculated and assessed for 
reasonableness. 

Best Practices Checklist: Maintaining a Baseline Schedule: 

* A baseline schedule: 

- is set promptly after the program begins; 

- is the basis for measuring performance; 

- represents the original configuration of the program plan and 
signifies the consensus of all stakeholders regarding the required 
sequence of events, resource assignments, and acceptable dates for key 
deliverables; 

- is compared to the current schedule to track variances from the plan. 

* There are plans to archive the as-built version of the schedule 
which: 

- represents the plan as executed to completion; 

- can be compared to the original plan for an assessment of lessons 
learned; 

- becomes a valuable basis of estimate input for schedule estimates of 
future analogous projects; 

- becomes the basis for creating and validating fragnets where 
possible. 

* A baseline schedule document is a single document that: 

- defines the organization of the IMS; 

- describes the logic of the network; 

- describes the basic approach to managing resources; 

- provides a basis for all parameters used to calculate dates; 

- describes the general approach to the project; 

- defines how to use the schedule file; 

- describes the schedule's unique features; 

- describes the schedule change management process; 

- contains a dictionary of acronyms and custom fields; 

- gives an overview of the assumptions and ground rules, including 
justification for: 

-- calendars, 

-- lags, 

-- date constraints, 

-- long activity durations, and: 

- calendars and working times; 

- describes the use and assignments of resources within the schedule at 
an appropriate level of detail; 

- describes the critical risks prioritized in a schedule risk analysis 
as well as schedule contingency; 

- discusses the derivation of the critical paths, longest path, and 
total float for the program; 

- is considered a living document that reflects updates to the baseline 
schedule. 

* Changes to the baseline schedule are reviewed and approved according 
to the change control process. 

* Schedule variances that exceed predetermined thresholds are reported 
to management, along with the cause and any corrective actions. 

* Negative schedule variances should be investigated to see if the 
associated effort is on the critical path. 

* Schedule measures, such as the number of activities that have started 
or finished early, on time, or later than planned, are analyzed for the 
effect of any variances. 

* Trend analysis is conducted periodically to examine measures such as 
decreasing float and schedule contingency erosion. 

* The focus of any schedule recovery or acceleration techniques is on 
critical activities. 

End of Best Practice 10] 

Four Characteristics of a Reliable Schedule: 

Our research has identified four characteristics of a high-quality, 
reliable schedule: they are comprehensive, well-constructed, credible, 
and controlled. 

A comprehensive schedule includes all activities for both the 
government and its contractors necessary to accomplish a project's 
objectives as defined in the project's WBS. The schedule includes the 
labor, materials, and overhead needed to do the work and depicts when 
those resources are needed and when they will be available. It 
realistically reflects how long each activity will take and allows for 
discrete progress measurement. 

A schedule is well-constructed if all its activities are logically 
sequenced with the most straightforward logic possible. Unusual or 
complicated logic techniques are used judiciously and justified in the 
schedule documentation. The schedule's critical path represents a true 
model of the activities that drive the project's earliest completion 
date and total float accurately depicts schedule flexibility. 

A schedule that is credible is horizontally traceable--that is, it 
reflects the order of events necessary to achieve aggregated products 
or outcomes. It is also vertically traceable: activities in varying 
levels of the schedule map to one another and key dates presented to 
management in periodic briefings are in sync with the schedule. Data 
about risks and opportunities are used to predict a level of confidence 
in meeting the project's completion date. The level of necessary 
schedule contingency and high-priority risks and opportunities are 
identified by conducting a robust schedule risk analysis. 

Finally, a schedule is controlled if it is updated periodically by 
trained schedulers using actual progress and logic to realistically 
forecast dates for program activities. It is compared against a 
designated baseline schedule to measure, monitor, and report the 
project's progress. The baseline schedule is accompanied by a baseline 
document that explains the overall approach to the project, defines 
ground rules and assumptions, and describes the unique features of the 
schedule. The baseline schedule and current schedule are subject to a 
configuration management control process. 

Table 2 shows how the 10 scheduling best practices can be mapped to 
the four characteristics of a high-quality, reliable schedule. 

Table 2: The Four Characteristics of a Reliable Schedule: 

Schedule characteristic: Comprehensive, reflecting: 
* all activities as defined in the project's WBS; 
* the labor, materials, and overhead needed to do the work and whether 
those resources will be available when needed; 
* how long each activity will take, allowing for discrete progress 
measurement with specific start and finish dates; 
Schedule best practice: 
1. Capturing all activities; 
3. Assigning Resources to all activities; 
4. Establishing the durations of all activities. 

Schedule characteristic: Well constructed, with: 
* all activities logically sequenced with predecessor and successor 
logic; 
* limited amounts of unusual or complicated logic techniques that are 
justified in the schedule documentation; 
* a critical path that determines which activities drive the project's 
earliest completion date; 
* total float that accurately determines the schedule's flexibility; 
Schedule best practice: 
2. Sequencing all activities; 
6. Confirming that the critical path is valid; 
7. Ensuring reasonable total float. 

Schedule characteristic: Credible, reflecting: 
* the order of events necessary to achieve aggregated products or 
outcomes; 
* varying levels of activities, supporting activities, and subtasks; 
* key dates that can be used to present status updates to management; 
* a level of confidence in meeting a project's completion date based 
on data about risks and opportunities for the project; 
* necessary schedule contingency and high priority risks based on 
conducting a robust schedule risk analysis; 
Schedule best practice: 
5. Verifying that the schedule is traceable horizontally and 
vertically; 
8. Conducting a schedule risk analysis. 

Schedule characteristic: Controlled, being: 
* updated periodically by schedulers trained in critical path method 
scheduling; 
* statused using actual progress and logic to realistically forecast 
dates for program activities; 
* compared against a documented baseline schedule to determine 
variances from the plan; 
* accompanied by a corresponding baseline document that explains the 
overall approach to the project, defines assumptions, and describes 
unique features of the schedule; 
* subject to a configuration management control process; 
Schedule best practice: 
9. Updating the schedule with actual progress and logic; 
10. Maintaining a baseline schedule. 

Source: GAO. 

[End of table] 

[End of Four Characteristics of a Reliable Schedule] 

Appendix I: An Auditor's Key Questions and Documents: 

Best Practice 1: Capturing All Activities: 

Key Questions: 

1. Is there an IMS for managing the entire program (not just a block, 
increment, or prime contractor)? Is the schedule defined at an 
appropriate level to ensure effective management? 

2. Is the IMS maintained in scheduling software and linked to external 
detailed subproject schedules? Do the government program management 
office and contractors have different scheduling software systems? If 
so, how is integrity preserved and verified when converting the 
schedule? 

3. Does the IMS include government, contractor, and applicable 
subcontractor effort? 

4. Does the schedule reflect the program WBS and does the WBS enable 
the tracking of key deliverables? Does every activity trace to an 
appropriate WBS element, and do the activities define how the 
deliverables will be produced? Is there a WBS dictionary? 

5. Are key milestones identified and are they consistent with the 
contract dates and other key dates established by management in the 
baseline schedule? 

6. Are clear start and finish milestones present in the schedule? Are 
there too many milestones in relation to detail activities? 

7. Are all activities mapped to the contract statement of work (SOW) or 
statement of objectives (SOO) to ensure that all effort is accounted 
for in the schedule? Are activities within the schedule easily 
traceable to key documents and other information through activity or 
task codes? 

8. Are activity names unique and descriptive? Are activities phrased in 
verb-noun combinations (for example, "develop documentation")? Are 
milestones named with verb-noun or noun-verb combinations (for example, 
"start project" or "project finished")? 

9. Are level-of-effort activities clearly marked? Are LOE activity 
durations determined by the activities they support? 

10. Does the schedule include risk mitigation activities? 

Key Documentation: 

1. Work breakdown structure (WBS), statement of work or objectives (SOW 
or SOO) and mission requirements: 

2. SOW or SOO crosswalk to the schedule WBS: 

3. Contractor WBS to program WBS crosswalk: 

4. Schedule custom fields and activity codes dictionary and LOE field 
identification: 

5. Activity codes used to organize and filter the activities into 
categories as necessary to confirm a complete scope of work: 

6. Engineering plans used to define activities, such as systems 
engineering plan, software development plan, risk management plan, and 
master test plan. 

7. Systems engineering life cycle, system development life cycle, or 
other required life cycle documentation: 

8. Enterprise architecture documentation for software programs: 

Likely Effects If Criteria Are Not Fully Met: 

1. If activities are missing from the schedule, then other best 
practices will not be met. If all necessary activities are not 
accounted for, it is uncertain whether all activities are scheduled in 
the correct order, resources are properly allocated, missing activities 
will appear on the critical path, or a schedule risk analysis can 
account for all risk. 

2. Failing to include all work for all deliverables, regardless of 
whether the deliverables are the responsibility of the government or 
contractor, can lead to project members' difficulties because of an 
incomplete understanding of the plan and its progress toward a 
successful conclusion. 

3. If the project schedule does not fully and accurately reflect the 
project, it will not be an appropriate basis for analyzing or measuring 
technical work accomplished and may result in unreliable completion 
dates, time extension requests, and delays. 

4. If government work is not captured in the IMS, the program manager 
will be less able to plan all the work and minimize the risk of 
government-caused delays. 

5. Because the schedule is used for coordination, missing elements will 
hinder coordination efforts, increasing the likelihood of disruption 
and delays. 

6. If the schedule is not sufficiently detail planned, then 
opportunities for process improvement (for example, identifying 
redundant activities), what-if analysis, and risk mitigation will be 
missed. 

7. LOE activities can interfere with the critical path unless they are 
clearly marked and represented as summary or hammock activities 
designed for the purpose. 

8. Too many milestones in the schedule can mask the activities 
necessary to achieve key milestones and can prevent the proper 
recording of actual progress. 

9. Schedules that are defined at too high a level may disguise risk 
that is inherent in lower-level activities. Conversely, schedules that 
have too much detail make it difficult to manage progress. 

10. Unless the schedule is aligned to the program WBS, management 
cannot ensure that the total scope of work is accounted for within the 
schedule. 

11. Repetitive naming of activities makes communication difficult 
between teams, particularly between team members who are responsible 
for updating and integrating multiple schedules. 

Best Practice 2: Sequencing All Activities: 

Key Questions: 

1. Have the activities and logical relationships been determined by 
those executing the project? 

2. Are the majority of the relationships within the detailed schedules 
finish-to-start? 

3. Are there any dangling predecessors or successors? 

a. Does each activity (except the start milestone) have an F-S or S-S 
predecessor that drives its start date? 

b. Does each activity (except the finish milestone and deliverables 
that leave the project without subsequent impact on the project) have 
an F-S or F-F successor that it drives? 

4. Do summary activities have predecessor or successor links? 

5. Do activities have start-to-finish links? 

6. How much convergence (that is, several parallel activities 
converging at one major event) is there in the schedule? 

7. Does the schedule contain date constraints other than "as soon as 
possible?" Is each one justified in the schedule documentation? 

8. Is the work of suppliers, government offices or agencies, or 
subcontractors represented in the schedule as an activity so that risk 
can be applied rather than representing the "promise date" as a date-
constrained milestone? 

9. Are lags or leads specified between the activities? Can these be 
more accurately characterized by improving logic or adding activity 
detail? 

Key Documentation: 

1. Justification for using hard and soft date constraints instead of 
activities' duration and logic: 

2. Justification for lags and leads instead of activities' duration and 
logic: 

3. Justification for any activity that has no F-S or S-S predecessor or 
no F-S or F-F successor: 

Likely Effects If Criteria Are Not Fully Met: 

1. The logical sequencing of events is directly related to float 
calculations and the critical path. If the schedule is missing 
dependencies or if activities are linked incorrectly, float estimates 
will be miscalculated. Incorrect float estimates may result in an 
invalid critical path and, thus, will not be reliable indicators of 
where resources can be shifted to support delayed critical activities. 

2. That all interdependencies between activities are identified is 
necessary for the schedule to properly calculate dates and predict 
changes in the future. Without the right linkages, activities that slip 
early in the schedule do not transmit delays to activities that should 
depend on them. When this happens, the schedule will not provide a 
sufficient basis for understanding the program as a whole, and users of 
the schedule will lack confidence in the dates and the critical path. 
Finally, when activities are not correctly linked, the program cannot 
use the IMS to identify disconnects or hidden opportunities and cannot 
otherwise promote efficiency and accuracy or control the program by 
comparing actual to planned progress. 

3. Logical sequencing promotes a more realistic workflow. If missing, 
project team members can misunderstand one another, especially 
regarding receivables and deliverables. 

4. The presence of "dangling activities" reduces the credibility of the 
calculated activity start and finish dates and the identity of the 
critical paths. The slip or elongation of an activity that has no 
logical successor will not reflect its effect on the scheduled start 
dates of successor activities. 

a. If an activity--other than the start milestone--does not have an F-S 
or S-S predecessor that drives its start date, the activity will start 
earlier if its duration is projected to be longer than originally 
believed. An earlier start may be illogical. 

b. If an activity--other than the finish milestone or deliverable that 
leaves the project--does not drive a successor by an F-S or F-F link, 
the implications of its running late or long are not passed on to any 
successor activity. 

5. The ability of a schedule to forecast start and finish dates of 
activities and key events is directly related to the complexity and 
completeness of the schedule network. Unless complete network logic is 
established, the schedule cannot predict impacts on the project's 
planned finish date from, among other things, misallocated resources, 
delayed activities, external events, and unrealistic deadlines. 

6. Because a logic relationship dictates the effect of an on-time, 
delayed, or accelerated activity on following activities, any missing 
logic relationship is potentially damaging to the entire network. 

7. Path convergence issues can represent an unrealistic plan by 
implying that a large number of activities must be finished at the same 
time before a major event can occur as planned. An excess number of 
parallel relationships can indicate an overly aggressive or unrealistic 
schedule. 

8. Hard date constraints that restrict activities to starting or 
finishing on a specific date must be justified by referring to some 
controlling event outside the schedule. Date constraints prevent 
activities from responding dynamically to network logic, including 
actual progress and availability of resources. They can seriously 
affect float calculations and the identification or continuity of the 
critical path and can mask actual progress or delays in the schedule. 

9. Hard and soft constraints interfere with the results of a schedule 
risk analysis because they prevent activity dates within the schedule 
from dynamically responding to changes in predecessor dates. 

10. A customer-mandated date is not a legitimate reason to constrain an 
activity. A schedule is intended to be a dynamic, pro-active planning 
and risk mitigation tool that models the project and can be used to 
track actual progress toward important project milestones. Schedules 
with constrained dates can portray an artificial or unrealistic view of 
the project plan. 

11. Constraints should be used only when necessary and only if their 
justification is documented because they override network logic and 
restrict how planned dates respond to actual accomplished effort or 
resource availability. A large number of activities with constraints is 
typically a substitute for logic and can mean that the schedule is not 
well planned and may not be feasible. 

12. SNLT and FNLT constraints prevent activities from starting or 
finishing later than planned, essentially restricting the ability of 
any predecessor delays to affect their start and finish dates. 

13. Applying constraints to represent the availability of resources 
requires constant manual upkeep of the schedule. 

14. Mandatory start and finish constraints are the most rigid of all 
constraints because they do not allow the activity either to take 
advantage of time savings by predecessor activities or to slip in 
response to delayed predecessors or longer-than-scheduled durations. 

15. The time to produce an external product should be represented by a 
reference or schedule visibility activity rather than a constrained 
milestone representing receipt of the product. By modeling vendor or 
contractor production as an activity, the program office can track the 
contractor's high-level progress and apply risk to the external 
production activity. 

16. Lags must be justified because they may represent work or a delay 
that may be variable while the lag is static. Lags should not be used 
to represent activities because they cannot be easily monitored or 
included in the risk assessment and do not take resources. Activities 
represented by lags are not, in fact, risk free. 

17. Constantly updating lags manually defeats the purpose of a dynamic 
schedule and makes it particularly prone to error. 

18. The use of a lag with F-S logic is generally not good practice 
because it is generally not necessary. In such cases, every effort 
should be made to break activities into smaller tasks and to identify 
realistic predecessors and successors so that logic interface points 
are clearly available for needed dependency assignments. 

19. Leads are generally not valid. As negative lags, leads imply the 
unusual measurement of negative time and exact foresight about future 
events. 

20. Lags are also often used as buffers for risk between two 
activities, but this practice should be discouraged because the lags 
persist even as the actual intended buffer is used up. 

Best Practice 3: Assigning Resources to All Activities: 

Key Questions: 

1. What resources are specified and assigned to the activities? At what 
level of detail are resources specified (for example, labor categories, 
organizations, or individual names)? 

2. Are significant material and equipment resources captured in the 
schedule? 

3. Do the resources have logical resource calendars? 

4. How were resource estimates developed for each activity? 

5. Has analysis been performed to ensure that resources are sufficient 
and available in each work period when needed? 

a. Are there potential difficulties in obtaining scarce resources to 
accomplish the work? 

b. Are there work periods for which more resources are required than 
are available? What is the plan for resolving resource deficiencies? 

6. Has resource leveling been performed? 

7. To what extent are the resource estimates in the schedule 
consistent with those in the project cost estimate? 

Key Documentation: 

1. Basis of estimates for resource assumptions should align with 
resource estimates within the cost estimates. 

2. A resource allocation planning document should define resource 
profiles and tables for unique resources derived from the schedule. 

3. Resource output from scheduling software across all project 
schedules should be reported. This highlights the problem of assigning 
resources to several schedules in parallel. It also catches any issues 
with the resource leveling assumptions that the software is using and 
the use of "placeholder" resource names. 

Likely Effects If Criteria Are Not Fully Met: 

1. Information on resource needs and availability in each work period 
assists the program office in forecasting the likelihood that 
activities will be completed as scheduled. If the current schedule does 
not allow insight into current or projected allocation of resources, 
then the risk of the program's slipping is significantly increased. 
Overallocated resources result in inefficiency (for example, staff are 
less productive because of extended overtime) or project delay from 
unavailable resources. 

2. Resources must be considered when creating a schedule because their 
availability directly affects an activity's duration. 

3. A schedule without resources implies an unlimited number of 
resources and their unlimited availability. 

4. If there is no justification for allocating and assigning 
resources, the schedule will convey a false level of accuracy. 

5. Bow waves in forecasts of resource assignments represent the need 
for large amounts of resources near the end of work streams to finish 
deferred or delayed work on time. Often the number of resources and 
funding required at the peak of the bow wave are unrealistic. 

6. If resource leveling causes enormous delays in the project finish 
date--for example, by many months or years--then the original resource 
assumptions, network logic, or activity durations must be examined for 
pragmatism. 

7. Automatic resource leveling can lead to inefficient output by 
delaying activities if only partial resources are available and 
preventing activities from being partially accomplished while waiting 
for the full complement of resources to become available. 

8. Incorrect resource assumptions (usually in the form of unwarranted 
optimism) will lend unreasonable credence to a resource-leveled 
schedule, and the resulting leveled schedule will convey a false sense 
of precision and confidence to senior decision makers. 

9. A schedule that has not reviewed and resolved resource utilization 
issues is not credible. 

10. If the baseline schedule does not identify the planned resources, 
it cannot be used to make important management decisions, such as 
reallocating resources from activities with significant float to 
critical activities that are behind schedule. 

11. If the schedule does not have resource assignments, management's 
ability to monitor crew productivity, allocate idle resources, monitor 
resource-constrained activities, and level resources across activities 
is severely limited. 

Best Practice 4: Establishing Durations for All Activities: 

Key Questions: 

1. Were durations determined from work to be done and realistic 
assumptions about available resources, productivity, normal 
interferences and distractions, and reliance on others? 

2. For a detailed schedule, are durations short enough to be 
consistent with the needs of effective planning and project execution? 
Are durations no more than two reporting periods for effective 
statusing and progress reporting of near-term work? Are activity 
durations too short? 

3. Are activities long in duration because of LOE or rolling wave 
planning? 

4. Were durations estimated by the person responsible for the 
activities or reviewed with experts who have experience with similar 
types of work? 

5. Was the project duration determined by some target or mandated 
date? 

6. Are durations based on appropriate calendars? Do any specific 
conditions necessitate special calendars, and are they addressed (for 
example, religious holidays, nonwork periods for climate, shift work, 
unavailability of resources)? Are activity durations assigned 
inconsistent time units? 

Key Documentation: 

1. How durations of work activities were estimated is documented at 
the appropriate level of detail. For instance, the basis of estimate 
includes the assumptions made to justify the durations assumed for the 
cost. These should be consistent with the durations at the same level 
of detail. 

2. Documentation justifies nonstandard working calendars. 

3. Documentation justifies excessively long durations, including the 
identification of LOE activities and how they were scheduled. 

Likely Effects If Criteria Are Not Fully Met: 

1. If activities are too long, the schedule may not have enough detail 
for effective progress measurement and reporting. 

2. If activities are too short, the schedule may be too detailed. This 
may lead to excessive work in maintaining the logic, updating the 
status of activities, and managing the many short-duration activities. 

3. When durations are not based on the effort required to complete an 
activity, the resources available, resource efficiency, and other 
factors such as previous experience on similar activities, then there 
is little confidence in meeting the target deliverable date. 

4. Schedules determined by imposed target completion dates rather than 
work and logic are often infeasible. 

5. Durations estimated under optimal or "success-oriented" conditions 
will produce unrealistic project delivery dates and unreliable critical 
paths and could mask program or project risks. 

6. Proper use of resource and task calendars will usually preclude the 
need for soft constraints in schedules. But improperly defined task or 
resource calendars will incorrectly represent the forecasted start, 
finish, and durations of planned activities. 

7. The default calendar in a schedule software package rarely has 
appropriate national holidays defined as exceptions and will not have 
specific blackout periods or other project-specific exceptions defined. 

8. Schedules will incorrectly represent the forecasted start, finish, 
and durations of planned work if resources are assigned to incorrect 
calendars. Ensuring realistic calendars will provide for more accurate 
dates and may reveal opportunities to advance the work. 

Best Practice 5: Verifying That the Schedule Is Traceable Horizontally 
and Vertically: 

Key Questions: 

1. Is all logic in place and has the technical content of the 
schedule been validated? 

2. Are major hand-offs and deliverables easily identified in the 
schedule? How are major hand-offs and deliverables negotiated and 
monitored? 

3. Does the schedule have fields that record the responsible givers 
and receivers? 

4. Are the key dates consistent between lower-level detailed working 
schedules and higher-level summary schedules? Do all lower-level 
activities roll up into higher WBS levels? 

5. Do major milestones map between the schedule and management-level 
briefing charts? 

Key Documentation: 

1. All representations of the schedule are given as of a specific 
time. These may include different levels of the same schedule used in 
presentations as well as schedule representation using different 
platforms (scheduling or presentation packages) for different 
audiences. 

2. The integration between summary, intermediate, and detailed 
schedules is demonstrated. 

Likely Effects If Criteria Are Not Fully Met: 

1. If the schedule is not horizontally traceable, there may be little 
confidence in the calculated dates or critical paths. Schedules that 
are not horizontally integrated may not depict relationships between 
different program elements and product handoffs. Any logic errors 
between summary, intermediate, and detailed schedules will cause 
inconsistent dates between schedules and will cause different 
expectations between management and activity owners. 

2. Unless the schedule is horizontally traceable, activities whose 
durations are greatly extended will have no effect on key milestones. 

3. Schedules that are not horizontally integrated may not depict 
relationships between different program elements and product hand-offs. 
When this happens, hand-offs of project subcomponents cannot be fully 
traced to the end product, leading to less effective project 
management. 

4. Vertical traceability provides assurance that the representation 
of the schedule to different audiences is consistent and accurate. 
Without vertical traceability, there may be little confidence that all 
consumers of the schedule are getting the same correct schedule 
information. 

5. Unless the schedule is vertically traceable, lower-level schedules 
will not be consistent with upper-level schedule milestones, affecting 
the integrity of the entire schedule and the ability of different teams 
to work to the same schedule expectations. 

6. Without horizontal and vertical traceability, there is no valid 
critical path or computation of float. 

Best Practice 6: Confirming That the Critical Path is Valid: 

Key Questions: 

1. Is the critical path, or longest path in the presence of late-date 
constraints, calculated by the scheduling software valid? 

a. Are any activities in the schedule missing logic or constrained 
without justification? Are these issues resulting in an unreliable 
critical path? 

b. Is the critical path a continuous path from the status date to the 
major completion milestones? 

c. Does the critical path start with a constraint so that other 
activities are unimportant in driving the milestone date? If so, is 
there justification for that constraint? 

d. Does the critical path include LOE activities? Is the critical path 
driven by activities of unusually long duration? 

e. Is the critical path driven in any way by lags or leads? 

2. Does management use the critical path to focus on activities that 
will have detrimental effects on key project milestones and deliveries 
if they slip? 

3. Does the scheduling software identify activities that drive the 
dates of key deliveries and milestones? 

4. If there are several important milestones, are the critical paths 
to them clearly identified, continuous, and free of constraints, LOE 
activities, leads, and lags? 

Key Documentation: 

1. Important program deliverables or milestones for which critical 
paths should be established are identified. 

2. Printouts of the logic diagram indicate the longest paths to the 
important milestones, as well as critical paths based on total float to 
all major milestones. 

3. Near-critical paths are identified. 

Likely Effects If Criteria Are Not Fully Met: 

1. Successfully identifying the critical path relies on capturing all 
activities (Best Practice 1), properly sequencing activities (Best 
Practice 2), horizontal traceability (Best Practice 5), the 
reasonableness of float (Best Practice 7), accurate status updates 
(Best Practice 9), and--if there are resource limitations--assigning 
resources (Best Practice 3). Unless the schedule is fully horizontally 
traceable, the effects of slipped activities on successor activities 
cannot be determined. If the schedule is missing dependencies or if 
activities are not linked correctly, float estimates will be 
miscalculated. Incorrect float estimates will result in an invalid 
critical path and will hinder management's ability to allocate 
resources from noncritical activities to those that must be completed 
on time. 

2. Until the schedule can produce a true critical path, the program 
office will not be able to provide reliable timeline estimates or 
identify when problems or changes may occur and their effect on 
downstream work. 

3. LOE activities should not drive the schedule. LOE and repetitive 
activities support effort, and their durations are determined by detail 
activities. For example, a project's length is not determined by 
biweekly meetings or program management. If the schedule has discrete 
durations and driving logic for LOE activities, it will potentially 
confuse the identification of, and deflect program attention away from, 
the critical path. If LOE is critical, management has no indication of 
which activities can slip and which will respond positively to 
additional resources to reduce the risk of finishing late. 

4. Without a valid critical path, management cannot focus on 
activities that will have detrimental effects on the key project 
milestones and deliveries if they slip. 

5. Risk in activities on critical paths should be examined and 
mitigated because it has the potential to delay key program deliveries 
and milestones. 

6. The review and analysis of near-critical paths is important 
because their activities are likely to overtake the existing critical 
path and drive the schedule. 

Best Practice 7: Ensuring Reasonable Total Float: 

Key Questions: 

1. Are the total float values the scheduling software calculates 
reasonable and do they accurately reflect true schedule flexibility? 

2. Are excessive values of total float being driven by activities 
that are missing logic? 

3. Is total float calculated to the main deliveries and milestones as 
well as to the project's completion? 

4. Is total float monitored? Does management have a plan to mitigate 
negative total float? 

5. Does management rely on free float to level resources or reassign 
resources to assist critical activities? 

Key Documentation: 

The project team can use a list of activities sorted by their total 
float values to determine whether the total float values correctly 
reflect flexibility in the project schedule. 

Likely Effects If Criteria Are Not Fully Met: 

1. If the schedule is missing activities or dependencies or links 
activities incorrectly, float estimates will not be accurate. Incorrect 
float estimates may result in an invalid critical path and an 
inaccurate assessment of project completion dates. In addition, 
inaccurate values of total float falsely depict true project status, 
which could lead to decisions that may jeopardize the project. For 
example, if activities are not linked correctly to successors, total 
float will be greater than it should be. 

2. Because the critical path is directly related to the logical 
sequencing of events and float calculations, if the schedule is missing 
dependencies or if activities are incorrectly linked, float estimates 
will be miscalculated, resulting in an invalid critical path. 

3. Without accurate values of total float, it cannot be used to 
identify activities that could be permitted to slip and thus release 
and reallocate resources to activities that require more resources to 
be completed on time. 

4. Negative float indicates that not enough time has been scheduled 
for the activity and is usually caused by activities taking longer or 
starting later than planned, making target dates infeasible. The 
project may have to take some corrective action or the negative float 
may act as a lien against or threat to the project end date. 

5. Too little float built into the schedule may indicate insufficient 
time to recover from delay without slipping the program's completion 
date. 

Best Practice 8: Conducting a Schedule Risk Analysis: 

Key Questions: 

1. Was an SRA performed to determine the confidence level in 
achieving the program schedule and other key dates? 

a. Was the schedule checked to ensure that it meets best practices 
before the simulation was conducted? 

b. Are there data fields within the schedule for risk analysis such as 
low, most likely, and high durations? 

c. Were uncertainties in activity durations statistically correlated to 
one another? 

d. How much schedule contingency was selected and what is the 
probability of meeting the completion date? 

e. Did the SRA identify activities during the simulation that most 
often ended up on the critical path, so that near-critical path 
activities can be closely monitored? 

2. Was a risk register used as an input to schedule development? 

a. Was the risk register used in identifying the risk factors 
potentially driving the schedule before the SRA was conducted? 

b. Once the SRA was conducted, were risks prioritized by probability 
and magnitude of impact? 

3. Are the SRA data, assumptions, and methodology available and 
documented? 

4. Have the risk inputs been validated? Are the ranges reasonable and 
based on information gathered from knowledgeable sources? Is there 
evidence of bias in the risk data? 

5. How is the use of schedule contingency controlled and authorized? 

Key Documentation: 

1. A risk register with prioritized risks should be available. 

2. SRA documentation should include assumptions, methodology, data, 
data normalization techniques, and findings. 

3. If applicable, people should be listed who were interviewed or 
included in risk interviews, including their organization, position, or 
expertise. 

4. The schedule risk analysis file is available. 

Likely Effects If Criteria Are Not Fully Met: 

1. If a schedule risk analysis is not conducted, the following cannot 
be determined: 

a. the likelihood of the project's completion date: 

b. how much schedule risk contingency is needed to provide an 
acceptable level of certainty for completion by a specific date: 

c. risks most likely to delay the project: 

d. how much contingency reserve each risk requires and: 

e. the paths or activities that are most likely to delay the project. 

2. Because activity durations are uncertain, the identity of the true 
critical path is also unknown unless a schedule risk analysis has been 
performed. An SRA can identify the paths that are most likely to become 
critical as the project progresses so that risk mitigation can lessen 
the effect of any delays. 

3. Unless a statistical simulation is run, calculating the completion 
date from schedule logic and the most likely duration distributions 
will tend to underestimate the program's overall critical path 
duration. 

4. If the schedule risk analysis is to be credible, the program must 
have a quality schedule that reflects reliable logic and clearly 
identifies the critical path. If the schedule does not follow best 
practices, confidence in the SRA results will be lacking. Without this 
analysis, the program office cannot sufficiently understand the level 
of confidence in meeting the program's completion date and identifying 
reserves for contingencies. 

5. If the program does not have sufficient schedule reserve, then 
risk mitigation actions and schedule issues from unforeseen events may 
not be managed without a schedule delay. 

6. If the task durations are not correlated to one another, the 
uncertainty on the critical path duration will be underestimated. 

Best Practice 9: Updating the Schedule Using Logic and Progress: 

Key Questions: 

1. Is the schedule progress recorded periodically? Has the 
schedule been updated recently as planned? Is the status date recorded? 
Is at least one in-progress activity critical? 

2. Do any activities have start or finish dates in the past without 
actual start or finish dates? Are there any activities with actual 
start or finish dates in the future? 

3. Is responsibility for changing or statusing the schedule assigned 
to someone who has the proper training and experience in CPM 
scheduling? 

4. Is there a list of logic changes that were made to the schedule 
during the update? Are there any comments in the schedule activities to 
document logic changes? 

5. Were any activities started or completed out of sequence? If so, 
was the logic retained, or did the scheduler use progress override? 

6. A schedule narrative accompanies each status update and includes: 

a. the status of key milestone dates, including the program finish 
date; 

b. the status of key hand-offs or giver/receiver dates; 

c. explanations for any changes in key dates; 

d. changes in network logic, including lags, date constraints, and 
relationship logic and their effect on the schedule timeframe; 

e. a description of the critical paths, near-critical paths, and 
longest paths along with a comparison to the previous period's paths; 
and: 

f. any significant scheduling software options that changed between 
update periods, such as the criticality threshold for total float, 
progress override versus retained logic, or whether or not resource 
assignments are progressed along with duration. 

7. Is the schedule structure examined after each update to ensure 
that no logic is missing, constraints are necessary, and no activities 
impede the ability of the schedule to dynamically forecast dates? 

Key Documentation: 

1. The schedule shows actual and planned dates, remaining duration 
for in-process activities, and the status date. 

2. Copies of project management review (PMR) briefings to verify 
whether schedule status is discussed and consistent with the schedule. 

Likely Effects If Criteria Are Not Fully Met: 

1. If the schedule is not continually monitored to determine when 
forecasted completion dates differ from planned dates, then it cannot 
be used to determine whether schedule variances will affect downstream 
work. 

2. Maintaining the integrity of the schedule logic is not only 
necessary to reflect true status but is also required before conducting 
a schedule risk analysis. If the schedule has not been updated, then it 
is impossible to tell what activities have been completed, are in 
progress, are late, and are planned to start on time. 

3. A schedule that has not been updated will not reflect what is 
actually occurring on the project and hence may have inaccurate 
completion dates and critical paths. When this is the case, management 
cannot use the schedule to monitor progress and make decisions 
regarding risk mitigation, resource allocations, and so on. 

4. Unless a status date is provided, the schedule cannot be used to 
reliably convey effort spent and remaining. 

5. A schedule with progress remaining out of sequence may have the 
wrong logic in place and, hence, inaccurate critical paths and 
completion dates. 

6. If unfinished work remains in the past, the schedule no longer 
represents a realistic plan to complete the project, and team members 
will lose confidence in the model. 

7. At least one in-progress activity is critical. If not, it is most 
likely that date constraints or external dependencies are separating 
subsequent from in-progress activities. Such breaks in the critical or 
longest path represent weak or incomplete logic, causing a lack of 
credibility in the identity of the path and the schedule dates. 

8. Without a documented, consistently applied schedule change control 
process, project staff might continually revise the schedule to match 
performance, hindering the project manager's insight into the true 
performance of the project. Good documentation helps with analyzing 
changes in the program schedule and identifying the reasons for 
variances between estimates and actual results, thereby contributing to 
the collection of cost, schedule, and technical data that can be used 
to support future estimates. 

9. Unless the schedule is kept updated, trend reports and analysis 
that highlight problems will not be useful in mitigating future 
delays. 

10. Unless progress records are archived, historical data necessary 
for resource, work, and productivity assumptions for future analogous 
projects will not be available. If sufficient attention is paid to 
recording the way work is actually performed, the resulting archived 
data will help improve the accuracy and quality control of future 
similar projects. 

Best Practice 10: Maintaining a Baseline Schedule: 

Key Questions: 

1. Is the baseline schedule the basis for measuring performance? 

2. Does a baseline schedule document exist? Does the document: 

a. describe the general approach to the project, define how to use the 
electronic schedule file, and describe the schedule's unique features? 

b. describe the schedule change management process? 

c. contain a dictionary of abbreviations, acronyms and custom fields? 

d. provide an overview of the assumptions and ground rules, including 
justification for calendars and any lags, constraints, or long activity 
durations? 

e. describe the use of resources within the schedule? 

f. describe the critical risks prioritized in a schedule risk analysis 
as well as schedule contingency? 

g. discuss the derivation of the critical paths and longest path and 
justify excessive total float? 

3. Are changes to the baseline schedule reviewed and approved 
according to the schedule change control process? 

4. Is trend analysis performed, such as monitoring start and finish 
dates, available float, and available schedule contingency? 

5. Is there a large bow wave of work to the right of the status date 
that is unrealistic? 

Key Documentation: 

1. The designated baseline schedule is available. 

2. The schedule change control process is described. 

3. The current schedule change control log is available. 

4. The baseline schedule is documented. 

Likely Effects If Criteria Are Not Fully Met: 

1. Without a formally established baseline schedule to measure 
performance against, management cannot identify or mitigate the effect 
of unfavorable performance. 

2. Good documentation helps with analyzing changes in the program 
schedule and identifying the reasons for variances between estimates 
and actual results thereby contributing to the collection of cost, 
schedule, and technical data that can be used to support future 
estimates. 

3. Thorough documentation is essential for validating and defending a 
baseline schedule. A well-documented schedule can convincingly argue 
for a schedule's validity and can help answer decision makers' and 
oversight groups' probing questions. A well-documented schedule is 
essential if an effective independent review is to ensure that it is 
valid and credible. 

4. If changes are not controlled and fully documented, performance 
cannot be accurately measured against the original plan. Undocumented 
or unapproved changes will hamper performance measurement and may 
result in inaccurate variance reporting, inconsistent stakeholder 
versions of the plan, and unreliable schedule data. 

5. Without a schedule change control process, traceability for all 
status updates will be unreliable, and there will be no guarantee that 
stakeholders are using the same version of the schedule. 

6. Unless schedule variances are monitored, management will not be 
able to reliably determine whether forecasted completion dates differ 
from the planned dates. 

7. Without trend analysis, management will lack valuable information 
about how a program is performing. Knowing what has caused problems in 
the past can help determine whether they will continue in the future. 

[End of Appendix I] 

Appendix II: The Forward and Backward Pass: 

Early and late activities dates are determined by the logical 
sequence of effort that planners lay out. Network logic will calculate 
activity dates that define both when an activity may start and finish 
and when an activity must start and finish in order to meet a specified 
program completion date. 

Suppose house construction and exterior finishing have been 
completed, and a certificate of occupancy (CO) has been issued. Several 
activities remain before the owner can occupy the house; specifically, 
utility systems must be started up and tested. Workers must: 

* set the electricity meter, 

* start up and test the electrical system, 

* set the gas meter, 

* start up and test the furnace and air conditioner, 

* set the water meter, and: 

* start up and test the plumbing fixtures. 

Once these activities are completed, then the start-up and testing 
phase will be completed and the owner can occupy the house. 

These activities must happen in a specified order: 

* The electrical, gas, and water meters cannot be set until the CO is 
issued. 

* The electrical system cannot be tested until the meter is set. 

* The furnace and air conditioner cannot be tested until the gas and 
electrical meters are set. 

* The plumbing fixtures cannot be tested until the gas and water meters 
are set. 

* The start-up and test phase is complete when the electrical system, 
furnace, air conditioner, and plumbing fixtures are tested. 

Table 3 shows the expected durations of each activity, given the 
estimated resources. 

Table 3: Expected Durations and Estimated Resources: 

Activity: Set electrical meter; 
Resource name: Electrician; 
Resource 
units: 2; 
Work hours: 16; 
Duration in days: 1. 

Activity: Set electrical meter; 
Resource name: Electrical 
service technician; 
Resource units: 1; 
Work hours: 8. 

Activity: Start up and test electrical system; 
Resource name: 
Electrician; 
Resource units: 1; 
Work hours: 16; 
Duration in days: 2. 

Activity: Set gas meter; 
Resource name: Gas service technician; 

Resource units: 2; 
Work hours: 16; 
Duration in days: 1. 

Activity: Start up and test furnace and air conditioner; 
Resource name: 
HVAC technician; 
Resource units: 1; 
Work hours: 8; 
Duration in days: 1. 

Activity: Set water meter; 
Resource name: Water service technician; 
Resource units: 2; 
Work hours: 16; 
Duration in days: 1. 

Activity: Start up and test plumbing fixtures; 
Resource name: Plumber; 
Resource units: 2; 
Work hours: 32; 
Duration in days: 2. 

Source: GAO. 

[End of table] 

Assuming the CO is attained on Monday, June 24, the electrical, gas, 
and water meters can be set the next day. Then, assuming that all 
succeeding activities are related by finish-to-start relationships, the 
start-up and testing network will appear as in figure 51. 

Figure 51: Start-Up and Testing Network: 

[Refer to PDF for image: illustration] 
                    
June 24, Monday: 
CO attained. 

June 25, Tuesday: 
Set electrical meter; 
Set gas meter; 
Set water meter. 

June 26, Wednesday: 
Startup up and test electrical system (through June 27); 
Start up and test furnace and AC; 
Start up and test plumbing features (through June 27). 

June 27, Thursday: 
Start up test complete. 

June 28, Friday: 
             
Source: GAO. 

[End of figure] 

The activities in figure 51 are planned according to forward 
scheduling; that is, activities begin as soon as possible according to 
their predecessor and successor relationships. For example, once the 
electrical meter is set, start-up and testing of the electrical system 
can begin. Calculating the earliest dates when activities can start and 
finish--given their predecessor and successor logic and durations--is 
known as the forward pass. In the forward pass, durations are added 
successively through the network. 

If CO is issued at the end of the business day on Monday, June 24, then 
the work associated with setting the electrical, gas, and water meters 
can begin on Tuesday, June 25. This is the early start (ES) for these 
activities and is noted in a box in the upper left corner of the text 
box representing each activity in figure 52. To calculate the early 
finish (EF) of each activity, the duration is added to the ES. One day 
must be subtracted to account for the full day of work available 
between the early start and early finish. That is, 

EF = ES + duration - 1. 

The EF is noted in the upper right corner of the activity's text box. 
The durations are noted in between the ES and EF boxes. In these simple 
cases of 1-day activities, the early start and early finish dates are 
the same day. The numbers above the date boxes represent the cumulative 
duration of the project as work progresses along those dates. 

Figure 52: Early Start and Early Finish Calculations: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25: 
1 day: Select electrical meter; 
EF: 6-25. 

ES: 6-25: 
1 day: Set gas meter; 
EF: 6-25. 

ES: 6-25: 
1 day: Select water meter; 
EF: 6-25. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

Early starts of successor activities are calculated according to the 
logic of the network. For a single finish-to-start relationship, the 
early start of the successor activity is simply the predecessor's early 
finish plus 1 day. The "start up and test electrical system" can begin 
the day after "set electrical meter" finishes, as shown in figure 53. 
The EF for "start up and test electrical system" is its ES (June 26) 
plus its 2 days of duration (June 28) and minus 1 day (June 27). 

Figure 53: Successive Early Start and Early Finish Calculations: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25: 
1 day: Select electrical meter; 
EF: 6-25. 

ES: 6-26: 
2 days: Start up and test electrical meter; 
EF: 6-27. 

ES: 6-25: 
1 day: Set gas meter; 
EF: 6-25. 

ES: 6-25: 
1 day: Select water meter; 
EF: 6-25. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

When an activity has two or more predecessor activities, the ES is 
calculated using the latest EF of its predecessor activities. That is, 
an activity cannot begin until the latest predecessor finishes. In 
figure 54, "start up and test furnace and AC" cannot begin until both 
the electrical meter and the gas meter are set. Setting the meters 
takes a day for each one, but they happen concurrently so they both 
finish on June 25. Therefore, setting the furnace and AC meters can 
start as early as June 26. Likewise, plumbing fixtures testing cannot 
be tested until the gas meter and the water meter are set. But because 
these are both 1 day long and occur on the same day, testing plumbing 
fixtures can begin as early as June 26. 

Figure 54: Complete Early Start and Early Finish Calculations: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25: 
1 day: Select electrical meter; 
EF: 6-25. 

ES: 6-26: 
2 days: Start up and test electrical meter; 
EF: 6-27. 

ES: 6-25: 
1 day: Set gas meter; 
EF: 6-25. 

ES: 6-26: 
1 day: Start up and test furnace/AC; 
EF: 6-27. 

ES: 6-25: 
1 day: Select water meter; 
EF: 6-25. 

ES: 6-26: 
2 days: Start up and test plumbing fixtures; 
EF: 6-27. 

Start up and test complete: 6/27. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

Note that testing plumbing fixtures is expected to take 2 days as well. 
Its EF is calculated as its ES (June 26) plus 2 days of duration (June 
28) minus 1 day (June 27). Finally, the ES of the "start up and test 
complete" milestone is calculated using the latest EF of its 3 
predecessors. Both "start up and test plumbing fixtures" and "start up 
and test electrical system" have EF dates of June 27. Therefore, the 
earliest when "start up and test complete" could possibly occur is June 
27 (milestones have no duration and therefore occur immediately after 
their latest predecessor). 

As can be concluded by these calculations, the ES and EF dates are the 
earliest dates that an activity may start or finish. We are also 
interested in the latest dates that an activity must start or finish. 
That is, what are the latest dates when activities must start and 
finish in order to finish a project by a given completion date? These 
dates are calculated by the backward pass. Once the forward pass has 
been calculated, the backward pass will determine the latest possible 
start and finish dates for activities. 

The backward pass essentially calculates how long activities can wait 
to start or finish and still have the project complete on time. The 
backward pass begins with the EF of the project. In the house 
construction set-up and test example, the three testing activities will 
each have a late finish (LF) of June 27. This is equal to the latest EF 
of the testing activities and, likewise, the date of the completion 
milestone. In figure 55 the LF is noted in the bottom right corner of 
each activity. To calculate an activity's late start (LS), the duration 
is subtracted from its LF, and 1 day is added to account for the full 
day of work between the two dates: 

LS = LF - duration + 1. 

The LS is noted in the bottom left corner of the activity's text box in 
figure 55. 

Figure 55: Late Start and Late Finish Calculations: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25; (LS: 6/25); 
1 day: Select electrical meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26; (LS: 6/26); 
2 days: Start up and test electrical meter; 
EF: 6-27; (LS: 6/27). 

ES: 6-25; (LS: 6/25); 
1 day: Set gas meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/27); 
1 day: Start up and test furnace/AC; 
EF: 6-27; (LS: 6/27). 

ES: 6-25: (LS: 6/25); 
1 day: Select water meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/26); 
2 days: Start up and test plumbing fixtures; 
EF: 6-27; (LS: 6/27). 

Start up and test complete: 6/27. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

When an activity has two or more successor activities, its LF is 
derived from the earliest LS of its successors. Stated another way, an 
activity does not need to finish until its successor must start; in the 
case of multiple successors, the earliest successor start date drives 
the activity's LF. In the following example, "set gas meter" has two 
successors: "start up and test furnace and AC" and "start up and test 
plumbing fixtures." The late start for testing plumbing fixtures is 
June 26, and the late start for testing the furnace and AC is June 27. 
The LF for "set gas meter" will use the earliest LS of its successors, 
which in this case is June 26 for "start up and test plumbing 
fixtures." 

The successors for "set electrical meter," test electrical system, and 
test furnace also have different LS dates (June 26 and 27, 
respectively). Its LF will therefore be June 25, 1 day before the 
earliest LS date. The complete forward pass and backward pass 
calculations are shown in figure 56. 

Figure 56: Early and Late Dates of the Start-Up and Testing Network: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25; (LS: 6/25); 
1 day: Select electrical meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26; (LS: 6/26); 
2 days: Start up and test electrical meter; 
EF: 6-27; (LS: 6/27). 

ES: 6-25; (LS: 6/25); 
1 day: Set gas meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/27); 
1 day: Start up and test furnace/AC; 
EF: 6-27; (LS: 6/27). 

ES: 6-25: (LS: 6/25); 
1 day: Select water meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/26); 
2 days: Start up and test plumbing fixtures; 
EF: 6-27; (LS: 6/27). 

Start up and test complete: 6/27. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

Total Float: 

Now that early and late dates have been derived, the schedule can be 
assessed for flexibility. The difference between the time an activity 
may start or finish (the early dates) and the time an activity must 
start or finish in order for the project to be completed on time (late 
dates) is known as total float (TF). Total float is calculated as the 
difference between an activity's early start and late start: 

TF = LS - ES. 

Total float is noted in figure 57 as "TF." Activities that have no 
total float are highlighted in red. 

Figure 57: Total Float in the Start-Up and Testing Network: 

[Refer to PDF for image: illustration] 

CO attained 6-24: 

ES: 6-25; (LS: 6/25); 
TF: 0 days; 
1 day: Select electrical meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26; (LS: 6/26); 
TF: 0 days; 
2 days: Start up and test electrical meter; 
EF: 6-27; (LS: 6/27). 

ES: 6-25; (LS: 6/25); 
TF: 0 days; 
1 day: Set gas meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/27); 
TF: 1 day; 
1 day: Start up and test furnace/AC; 
EF: 6-27; (LS: 6/27). 

ES: 6-25: (LS: 6/25); 
TF: 0 days; 
1 day: Select water meter; 
EF: 6-25; (LS: 6/25). 

ES: 6-26: (LS: 6/26); 
TF: 0 days; 
2 days: Start up and test plumbing fixtures; 
EF: 6-27; (LS: 6/27). 

Start up and test complete: 6/27. 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

[End of figure] 

All activities but one in figure 57 have zero total float. A total 
float value of 0 indicates that an activity has no flexibility between 
the date when it may start and the date when it must start or between 
the dates when it may finish and must finish. Any delay in its start or 
finish dates will transfer directly to the end milestone. 

Three paths through the set-up and testing network have no total float 
and thus no flexibility: 

1. "CO attained"... "set electrical meter"... "start up and test 
electrical system"... "start up and test complete"; 

2. "CO attained"... "set gas meter"... "start up and test plumbing 
fixtures"... "start up and test complete"; 

3. "CO attained"... "set water meter"... "start up and test plumbing 
fixtures"... "start up and test complete." 

Any delay along the activities on these paths is transferred directly, 
day for day, to the finish date of the "start up and test complete" 
milestone, unless mitigating steps are taken. 

Two paths through the set-up and testing network have total float 
available and thus have flexibility: 

1. "CO attained"... "set electrical meter"... "start up and test 
furnace and AC"... "start up and test complete"; 

2. "CO attained"... "set gas meter"... "start up and test furnace and 
AC"... "start up and test complete." 

Practically speaking, only one activity in the network can slip a day. 
None of the meter-setting activities can slip because they are all on 
the critical path: a slip in any one of the three will cause either the 
electrical system or the plumbing fixtures test to slip a day, causing 
the finish milestone to slip a day. Only the furnace and AC test 
activity can safely slip 1 day without pushing the completion milestone 
out. To introduce more flexibility into the schedule, the general 
contractor may want to assign an extra electrician to the electrical 
system testing. An extra resource will reduce the duration by 1 day and 
would therefore introduce an extra day of total float for that 
activity. Because total float is shared along a path, the test's 
predecessor, "set electrical meter," would also gain a day of total 
float. 

[End of Appendix II] 

Appendix III: Standard Quantitative Measurements for Assessing Schedule 
Health: 

An assessment of schedule best practices encompasses both qualitative 
and quantitative information. Qualitative information is provided by 
programmatic questions as such as those detailed in appendix I. These 
questions are related to the general policies in place and procedures 
undertaken to create and maintain the schedule. The quantitative 
assessment involves a detailed data analysis of the schedule data to 
determine the overall health of the network. While the specific 
questions addressed by the data analysis are also covered in appendix 
I, the quantitative assessment often involves specific filters and 
detailed data metric definitions. These filters and definitions are in 
table 4 for each best practice. 

Table 4: Standard Data Measures for Schedule Best Practices: 

Best practice: 1. Capturing all activities; 

Measure: Measures in Best Practice 1 provide basic information on the 
scope of the schedule, such as number and types of activities and the 
level of detail. 

Measure: Total number of activities, including total summary, hammock, 
milestone, and detail activities; 
Notes: Summary activities may or may not be present in the scheduling 
software. 

Measure: Total number of remaining activities, including total 
summary, hammock, milestone, and detail activities; 
Notes: A remaining activity is any activity that is not complete. 
"Remaining" may be defined as (1) an activity with an actual start or 
no actual start and no actual finish or (2) any activity that is not 
100 percent complete. Issues may arise with either definition. For 
instance, an activity may be noted as 100 percent complete and not 
have an actual finish date, or it may have an actual start and finish 
date but be less than 100 percent complete. Summary activities may or 
may not be present in the scheduling software. 

Measure: If applicable, number of activities marked as 
both a milestone and summary activity; 
Notes: An activity cannot be both a summary and a milestone. 

Measure: Number of activities with no descriptive name; 
Notes: May or may not be valid activities. 

Measure: Ratio of detail activities to milestones; 
Notes: Provides a rough indicator of the level 
of planning detail in the schedule. While there is no specific 
threshold, 1 or 2 detailed activities per milestone is probably a very 
low level of detail, while 10 is probably highly detailed. 

Measure: Number of activities not mapped to program or contractor work 
breakdown structure; 
Notes: [Empty]. 

Measure: Number of activities not mapped to a SOW or SOO paragraph or 
similar information; 
Notes: Depending on the nature of the effort, an activity may not be 
mapped to the statement of work. 

Measure: Number of activities with duplicate names; 
Notes: Activity names should be unique and descriptive. 

Best practice: 2. Sequencing all activities: 

Measure: Best Practice 2 includes more advanced measurements to assess 
the reliability of the network logic. Thresholds for metrics are not 
provided because, in theory, any missing or inappropriate logic may 
disrupt the entire network. The assessment of this best practice 
relies in part on the assessment of Best Practices 5, 6, and 7. If 
major deficiencies are identified in Best Practice 2, then a valid 
critical path, total float, and horizontal traceability are simply not 
possible. For minor deficiencies, an assessment of the schedule's 
critical path, total float, and response to tests of horizontal 
traceability are essential to understand the implications of 
constraints and incorrect or missing logic. Finally, all activities in 
a schedule, regardless of detail or planning period, are subject to 
this best practice. 

Measure: Number of remaining detail activities and milestones missing 
predecessor links; 
Notes: Does not include the start milestone; missing links to external 
activities (activities outside the scope of the current schedule file) 
may be excluded when a schedule is evaluated outside the IMS network. 

Measure: Number of remaining detail activities and 
milestones missing successor links; 
Notes: Does not include the finish milestone; missing links to 
external activities (activities outside the scope of the current 
schedule file) may be excluded when a schedule is evaluated outside 
the IMS network. 

Measure: Number of remaining detail activities and milestones missing 
both predecessor and successor links; 
Notes: [Empty]. 

Measure: Dangling activities: number of remaining detail activities 
and milestones with no predecessor on start date; 
Notes: Milestone activities may be excluded because their start and 
finish dates are the same; missing links to external activities 
(activities outside the scope of the current schedule file) may be 
excluded when a schedule is evaluated outside the IMS network. 

Measure: Dangling activities: number of remaining detail activities 
and milestones with no successor off finish date; 
Notes: Milestone activities may be excluded because their start and 
finish dates are the same; missing links to external activities 
(activities outside the scope of the current schedule file) may be 
excluded when a schedule is evaluated outside the IMS network. 

Measure: Number of remaining detail activities and milestones with 
start-to-finish links; 
Notes: Count either successor or predecessor links but do not count 
both. An S-F link is between two activities but represents only one 
link. 

Measure: Number of remaining summary activities with logic links; 
Notes: May also be measured as "logic links to and from remaining 
summary activities," although this will be a different number. 

Measure: Remaining detail activities and milestones with a great many 
predecessors; 
Notes: Assesses the schedule for path convergence. A relatively high 
number of predecessors may indicate a high-risk area. Note that not all 
predecessors are driving; only those predecessors that have 0 or low
float have the ability to delay the successor when they are delayed. 

Measure: Remaining detail activities and milestones with soft date 
constraints; 
Notes: [Empty]. 

Measure: Remaining detail activities and milestones with hard date 
constraints; 
Notes: [Empty]. 

Measure: Remaining detail activities and milestones with active SNET 
date constraints; 
Notes: If an activity's scheduled start date is the same as the SNET 
date, then the SNET constraint is more than likely preventing the 
activity from starting early. This is considered an active constraint. 
If an SNET constraint is earlier than the activity's start date, then 
the activity is not affected by the constraint date. 

Measure: Remaining detail activities and milestones with active FNET 
date constraints; 
Notes: If an activity's scheduled finish date is the same as the FNET 
date, then the FNET constraint is more than likely preventing the 
activity from finishing early. This is considered an active 
constraint. If an FNET constraint is earlier than the activity's 
finish date, then the activity is not affected by the constraint date. 

Measure: Remaining detail activities and milestones with lags; 
Notes: Count either successor or predecessor lags but do not count 
both. A lag is between two activities but represents only one lag. 
This is a different number than the number of lags. 

Measure: Number of lags on remaining detail activities and milestones; 
Notes: Count either successor or predecessor lags but do not count 
both. A lag is between two activities but represents only one lag. 
This is a different number than the number of activities with lags. 

Measure: Remaining detail activities and milestones with leads; 
Notes: Count either successor or predecessor leads but do not count 
both. A lead is between two activities but represents only one lead. 
This is a different number than the number of leads. 

Measure: Number of leads on remaining detail activities and milestones; 
Notes: Count either successor or predecessor leads but do not count 
both. A lead is between two activities but represents only one lead. 
This is a different number than the number of activities with leads. 

Measure: Remaining detail activities and milestones with an F-S 
predecessor lead greater than remaining duration; 
Notes: [Empty]. 

Best practice: 3. Assigning resources to all activities: 

Measure: Best Practice 3 is more programmatic than quantitative, 
although metrics and trends may be investigated for fully resource 
loaded schedules. If possible, resource assignments over time may be 
evaluated to identify potential unrealistic bow waves. In general, the 
measures assess the number of activities within the detail planning 
period that are assigned resources and the reasonableness of work 
hours. Overallocated resources and unrealistic resource units should 
be a cause for concern. Care should be taken to assess only the 
appropriate detailed activities. 

Measure: Total number of resources; 
Notes: [Empty]. 

Measure: Overallocated resources; 
Notes: [Empty]. 

Measure: Maximum units available per resource; 
Notes: Individuals should be available between 0 and 
100 percent of full time, and resource groups should have a realistic 
number of individuals available to perform the work. 

Measure: Remaining detail activities with assignments; 
Notes: Exclude non-applicable activities such as planning packages, 
LOE activities, and reference activities. 

Measure: Remaining detail activities without assignments; 
Notes: Exclude non-applicable activities such as planning packages, 
LOE activities, and reference activities. 

Best practice: 4. Establishing the durations of all activities; 

Measure: Measures for Best Practice 4 are generally straightforward, 
providing an overall assessment of the detail available to management, 
as well as the appropriateness of the schedule calendars. Care should 
be taken to assess only the appropriate detailed activities. 

Measure: Remaining detail activities with dissimilar time units; 
Notes: All durations should be in the same unit, preferably days. 

Measure: Best practice: Remaining detail activities with durations less 
than 44 days; 
Notes: Exclude nonapplicable activities such as planning packages and 
LOE and reference activities. The analyst should take into account 
baseline durations if available. That is, if the baseline duration is 
35 days but the actual plus remaining duration is 60, the original 
baseline meets the intent of the best practice. 

Measure: Remaining detail activities with durations greater than 44 
days; 
Notes: Exclude nonapplicable activities such as planning packages and 
LOE and reference activities. The analyst should take into account 
baseline durations if available. That is, if the baseline duration is 
35 days but the actual plus remaining duration is 60, the original 
baseline meets the intent of the best practice. 

Measure: Average duration of remaining detail activities; 
Notes: Exclude nonapplicable activities such as planning packages and 
LOE and reference activities. The analyst should take into account 
baseline durations if available. That is, if the baseline duration is 
35 days but the actual plus remaining duration is 60, the original 
baseline meets the intent of the best practice. 

Measure: Median duration of remaining detail activities; 
Notes: Exclude nonapplicable activities such as planning packages and 
LOE and reference activities. The analyst should take into account 
baseline durations if available. That is, if the baseline duration is 
35 days but the actual plus remaining duration is 60, the original 
baseline meets the intent of the best practice. 

Measure: Holidays and other exceptions by task calendar; 
Notes: Exclude nonapplicable activities such as planning packages and 
LOE and reference activities. The analyst should take into account 
baseline durations if available. That is, if the baseline duration is 
35 days but the actual plus remaining duration is 60, the original 
baseline meets the intent of the best practice. 

Measure: Remaining detail activities or milestones starting or 
finishing on a weekend or holiday; 
Notes: May be legitimate but stem from incorrect calendar assignments 
or specifications. Milestones on weekends or holidays are particularly 
suspicious. 

Best practice: 5. Verifying that the schedule can be traced 
horizontally and vertically; 
Measure: Best Practice 5 has no standard measurements. Vertical 
traceability is assessed by determining whether lower-level tasks fall 
within the same timeframe as higher-level tasks and whether detailed 
schedule dates fall within the same timeframe as summary schedule 
dates. An essential check of vertical traceability is determining 
whether forecasted milestone dates in detailed schedules match those 
quoted in management briefings. Horizontal traceability depends on 
Best Practice 2, although not entirely as noted in that best practice. 
It is assessed by increasing activities' durations by improbable 
amounts (500 or 1,000 days) and observing how the schedule reacts. In 
the absence of constraints and assuming logic has been properly 
identified, key milestones should move and the critical path should 
change. 

Measure: Assessment of how critical and noncritical planned dates 
dynamically react to dramatic increases in predecessor activity 
durations; 
Notes: Horizontal traceability implies that the network responds 
dynamically to delayed activities. Severely delayed activities should 
become critical and previously critical paths should become 
noncritical. Delays of this magnitude should cause the finish date to 
slip relative to the activity delay. 

Best practice: 6. Confirming that the critical path is valid; 
Measure: Best Practice 6 has no standard measurements for assessing 
the critical path. Beginning at the program finish milestone, the 
sequence of driving activities is traced back to the status date. This 
sequence of activities should be straightforward, continuous, and the 
same as the critical path--defined by zero total float--in the absence 
of date constraints. Date constraints will convolute the critical path 
and cause activities to be critical that may not necessarily be 
driving the finish milestone. Critical paths to interim key milestones 
may also be assessed as applicable. 

Measure: Assessment of the driving paths to key milestones and 
comparison of those paths to activities marked as critical in the 
schedule; 
Notes: Ideally the driving path and critical path are the same to
the key milestone. The path should be continuous from the status date 
to the key milestone and should be free of lags. 

Best practice: 7. Ensuring reasonable total float; 
Measure: Best Practice 7 includes basic measurements of total float to 
assess overall program flexibility as reported by the schedule. It is 
closely related to assessments of Best Practices 2, 5, and 6, because 
a properly sequenced network will produce reasonable estimates of 
float and a valid critical path. It has no thresholds or tripwire 
metrics; as discussed in Best Practice 7, reasonableness is assessed 
in combination with program length and activity type. In addition, 
because one logic error can cause an entire sequence of activities to 
report unreasonable amounts of float, the breadth of deficiencies 
reported in Best Practice 2 should be taken into account here. 
Negative float should always be questioned. 

Measure: Remaining detail activities and milestones with dissimilar 
total float time units; 
Notes: All float should be in the same units, preferably days. 

Measure: Remaining detail activities and milestones with 
relatively high total float; 
Notes: High float is relative to the scope, length, and complexity of 
the schedule. Float should be reasonable and realistically reflect the 
flexibility of the schedule. 

Measure: Remaining detail activities with negative total float; 
Notes: Negative total float indicates the activity's constraint date 
is earlier than its calculated late finish. Negative float occurs when 
activities are performed out of sequence. 

Measure: Average total float value of remaining detail activities and 
milestones; 
Notes: [Empty]. 

Measure: Median total float value of remaining detail activities and 
milestones; 
Notes: [Empty]. 

Best practice: 8. Conducting a schedule risk analysis; 
Measure: Many quantitative measurements are related to Best Practice 
8, and a proper schedule risk analysis typically deserves a much more 
complex quantitative assessment than that given here. GAO's assessment 
of Best Practice 8 is more programmatic, and these questions are 
provided in appendix I. The metrics for Best Practice 8 are limited to 
determining the existence of risk data within the schedule risk file. 

Measure: Fields within the schedule used for SRA; 
Notes: Fields that store low, most likely, and high durations. 

Measure: Correlation measures within the schedule; 
Notes: [Empty]. 

Measure: Contingency activities; 
Notes: [Empty]. 

Best practice: 9. Updating the schedule using actual progress and 
logic; 
Measure: Best Practice 9 is assessed by determining the validity 
of the dates reported in the schedule. The assessment of this best 
practice is dependent entirely on the status date reported in the 
schedule. 

Measure: Number of in-progress activities; 
Notes: Any activity that is not complete. "Remaining" may be defined 
as either (1) an activity with an actual start or no actual start and 
no actual finish or (2) any activity that is not 100 percent complete. 
Issues may arise with either definition. For instance, an activity may 
be noted as 100 percent complete and not have an actual finish date, 
or it may have an actual start and finish date but be less than 100 
percent complete. 

Measure: Number of remaining detail activities and milestones that 
have a start date in the past but no actual start date; 
Notes: Planned start dates should not occur in the past. "Past" is 
defined by the status date. 

Measure: Number of remaining detail activities and milestones that 
have a finish date in the past but no actual finish date; 
Notes: Planned finish dates should not occur in the past. "Past" is 
defined by the status date. 

Measure: Number of remaining detail activities and milestones that 
have an actual start date in the future; 
Notes: Actual start dates should not occur in the future. "Future" is 
defined by the status date. 

Measure: Number of remaining detail activities and milestones that 
have an actual finish date in the future; 
Notes: Actual finish dates should not occur in the future. "Future" is 
defined by the status date. 

Measure: Number of detail activities performed out of sequence; 
Notes: [Empty]. 

Best practice: 10. Maintaining a baseline schedule; 
Measure: Many data measures can be used to assess Best Practice 10, 
some are provided here. All baseline measures ultimately depend on the 
existence of a controlled baseline and a properly statused current 
schedule. Baseline measures are typically calculated by reporting 
period: for example, number of activities forecasted to start early 
over the next 60 days or activities that have actually finished late 
over the last 6 months. They may also be useful when applied to 
specific products within the WBS, resource groups, or criticality: for 
example, the number of late activities during product integration, the 
average start variance of activities executed in one production plant, 
or the baseline execution index of activities with less than 10 days 
of total float. 

Measure: Number of remaining detail activities and milestones that are 
forecasted to start or finish before their baseline dates; 
Notes: Represents activities and milestones forecasted to begin or end 
early. 

Measure: Number of remaining detail activities and milestones that are 
forecasted to start or finish on their baseline dates; 
Notes: Represents activities and milestones forecasted to begin or end 
on time. 

Measure: Number of remaining detail activities and milestones that are 
forecasted to start or finish after their baseline dates; 
Notes: Represents activities and milestones forecasted to begin or end 
late. 

Measure: Number of remaining detail activities that actually started 
before their baseline start date; 
Notes: Represents activities and milestones that actually started 
early. 

Measure: Number of remaining detail activities that actually started 
on their baseline start date; 
Notes: Represents activities and milestones that actually started on 
time. 

Measure: Number of remaining detail activities that actually started 
after their baseline start date; 
Notes: Represents activities and milestones that actually started late. 

Measure: Number of remaining detail activities and milestones that 
actually finished before their baseline finish date; 
Notes: Represents activities and milestones that actually finished 
early. 

Measure: Number of remaining detail activities and milestones that 
actually finished on their baseline finish date; 
Notes: Represents activities and milestones that actually finished on 
time. 

Measure: Number of remaining detail activities and milestones that 
actually finished after their baseline finish date; 
Notes: Represents activities and milestones that have actually 
finished late. 

Measure: Average and median start variance; 
Notes: Start variance may be the difference between actual start and 
baseline start or forecasted start and baseline start. 

Measure: Average and median finish variance; 
Notes: Finish variance may be the difference between actual finish and 
baseline finish or forecasted finish and baseline finish. 

Measure: Baseline execution index; 
Notes: The ratio of actual completed detail activities to detail 
activities that were planned to finish. A BEI of 1 indicates that the 
project is performing according to plan. A BEI less than 1 indicates 
that, in general, fewer activities are being completed than planned; a 
BEI greater than 1 indicates that, in general, more activities are 
being completed than planned. 

Source: GAO. 

[End of table] 

[End of Appendix III] 

Appendix IV: Recommended Elements of a Data Collection Instrument: 

* The baseline IMS and the latest updated IMS, including all applicable 
embedded project schedules. Their format should be that of a software 
schedule file such as Microsoft Project or Primavera P6. PDF and 
PowerPoint files are not valid schedule file formats and are not 
acceptable. Note the software used to create and maintain the schedule. 

* A schedule dictionary or similar documentation that defines custom 
fields, especially those that contain information on level of effort 
activities; contractor versus government effort; and statement of work, 
statement of objective, work package, integrated master plan, or 
control account mappings. 

* Integrated master pan (IMP), if applicable. 

* Work breakdown structure (WBS) and dictionary. 

* A statement of work (SOW) or statement of objectives (SOO) and 
mission requirements. 

* A cross-walk between the WBS or SOW and the schedule activities. 

* An identification of the main deliverables, including a designation 
of the paths that the project considers critical. 

* The schedule baseline and narrative documentation. 

* A basis of estimate or other documentation for estimating activity 
durations and assigned resources. 

* Relevant scheduling guidance, such as contract line item numbers, 
data item descriptions, and agency directives that govern the creation, 
maintenance, structure, and status of the schedule. 

* Schedule risk analysis documentation, including the analytical 
approach, assumptions, and results. 

* A risk management plan and a copy of the current risk watch list. 

[End of Appendix IV] 

Appendix V: Case Study Backgrounds: 

We drew the material in the guide's 19 case studies from the 11 GAO 
reports described in this appendix. Table 5 shows the relationship 
between reports, case studies, and the chapters in which they are 
cited. The table is arranged by the order in which we issued the 
reports, earliest first. Following the table, paragraphs describe the 
reports and are ordered by the numbers of the case studies in the 
guide. 

Table 5: Case Studies Drawn from GAO Reports Illustrating this Guide: 

Case study: 2; 
GAO report: GAO-09-518: Military Readiness; 
Best practices cited: 1. 

Case study: 19; 
GAO report: GAO-10-59: 2010 Census; 
Best practices cited: 10. 

Case study: 7, 14; 
GAO report: GAO-10-43: Transportation Worker 
Identification Credential; 
Best practices cited: 4, 8. 

Case study: 3, 16; 
GAO report: GAO-10-189: VA Construction; 
Best practices cited: 1, 8. 

Case study: 6; 
GAO report: GAO-10-378: Nuclear Nonproliferation; 
Best practices cited: 3. 

Case study: 13; 
GAO report: GAO-10-816: Nuclear Waste; 
Best practices cited: 7. 

Case study: 1, 4, 5, 17; 
GAO report: GAO-11-53: DOD Business Transformation; 
Best practices cited: 1, 2, 9. 

Case study: 8, 18; 
GAO report: GAO-11-740: Aviation Security; 
Best practices cited: 5, 9. 

Case study: 15; 
GAO report: GAO-11-743: Coast Guard; 
Best practices cited: 8. 

Case study: 9, 11; 
GAO report: GAO-12-66: Immigration Benefits; 
Best practices cited: 5, 6. 

Case study: 10, 12; 
GAO report: GAO-12-223: FAA Acquisitions; 
Best practices cited: 6, 7. 

[End of table] 

Case Studies 1, 4, 5, and 17: From DOD Business Transformation, 
[hyperlink, http://www.gao.gov/products/GAO-11-53], October 7, 2010: 

The Department of Defense (DOD) invests billions of dollars annually to 
modernize its business systems. Consequently, the DOD business systems 
modernization program has been on our high-risk list since 1995. In its 
modernization, DOD is implementing nine enterprise resource planning 
(ERP) efforts that perform business-related tasks such as general 
ledger accounting and supply chain management. These efforts are 
essential to transforming DOD's business operations. 

We were asked to determine whether selected ERPs followed schedule and 
cost best practices. We found that none of the four programs we 
assessed had developed a fully integrated master schedule as an 
effective management tool. Such a tool is crucial to estimating the 
overall schedule and cost of a program. Without it, DOD is unable to 
say, with any degree of confidence, whether the estimated completion 
dates are realistic. 

Case Study 2: From Military Readiness, [hyperlink, 
http://www.gao.gov/products/GAO-09-518], September 25, 2009: 

DOD reports data about the operational readiness of its forces. In 
1999, the Congress directed DOD to create a comprehensive readiness 
system with timely, objective, and accurate data. In response, DOD 
started to develop the Defense Readiness Reporting System (DRRS). After 
7 years, DOD had incrementally fielded some capabilities and reported 
obligating, through fiscal year 2008, about $96.5 million. We were 
asked to review the program, including the extent to which the DOD had 
(1) effectively managed and overseen DRRS acquisition and deployment 
and (2) implemented features of the DRRS consistent with legislative 
requirements and DOD guidance. 

First, we compared DRRS acquisition disciplines with DOD's related 
guidance and, second, we reviewed the DRRS's current and intended 
capabilities relative to legislative requirements and DOD's guidance. 
We found that DOD had not effectively managed and overseen DRRS 
acquisition and deployment. In large part, this ineffectiveness was 
caused by the absence of rigorous and disciplined acquisition 
management controls and an effective governance and accountability 
structure. Moreover, the DRRS had not been guided by a reliable 
schedule of work to be performed and key activities to take place. Such 
management weaknesses can, in part, be attributed to long-standing 
limitations in office staffing and system oversight and accountability. 

Case Studies 3 and 16: From VA Construction, [hyperlink, 
http://www.gao.gov/products/GAO-10-189], December 14, 2009: 

The Department of Veterans Affairs (VA) operates one of the largest 
health care systems in the country. As of August 2009, VA's Veterans 
Health Administration (VHA) had 32 major ongoing construction projects, 
with an estimated total cost of about $6.1 billion and average cost per 
project of about $191 million. Some of these projects were initiated as 
part of VA's Capital Asset Realignment for Enhanced Services (CARES) 
process, which was a comprehensive assessment of VHA's capital asset 
requirements. In response to a congressional request, we (1) described 
how costs and schedules of current VHA major construction projects had 
changed, (2) determined the reasons for changes in costs and schedules, 
and (3) described the actions VA had taken to address cost increases 
and schedule delays. 

We reviewed construction documents, visited three construction sites, 
and interviewed VA and general contractor officials. We found that 
while about half of the 32 major ongoing construction projects were 
within their budget, since they were first submitted to the Congress, 
18 had been subject to cost increases; 11 to schedule delays; and 5 to 
a cost increase of over 100 percent. For example, the cost of a new 
medical center in Las Vegas rose from an initial estimate of $286 
million to over $600 million, an increase of about 110 percent. In 
addition, 13 projects had been subject to cost increases of between 1 
and 100 percent, 11 to schedule delays, 4 of which were longer than 24 
months. There were several reasons for project cost increases and 
schedule delays, including VA's preparing initial cost estimates that 
were not thorough; significant changes to project scope after the 
initial estimate was submitted; and unforeseen events, such as an 
increase in the cost of construction materials. 

Case Study 6: From Nuclear Proliferation, [hyperlink, 
http://www.gao.gov/products/GAO-10-378], March 26, 2010: 

The end of the Cold War left the United States with a surplus of 
weapons-grade plutonium that posed proliferation and safety risks. Much 
of this material was to be found in a key nuclear weapon component 
known as a pit. The Department of Energy (DOE) planned to dispose of at 
least 34 metric tons of plutonium by fabricating it into mixed oxide 
(MOX) fuel for domestic nuclear reactors. To do so, DOE's National 
Nuclear Security Administration (NNSA) was constructing two facilities-
-a MOX Fuel Fabrication Facility (MFFF) and a Waste Solidification 
Building (WSB)--at the Savannah River Site in South Carolina. We were 
asked to assess the (1) cost and schedule status of the MFFF and WSB 
construction projects, (2) status of NNSA's plans for pit disassembly 
and conversion, (3) status of NNSA's plans to obtain customers for MOX 
fuel from the MFFF, and (4) actions that the Nuclear Regulatory 
Commission (NRC) and DOE had taken to provide independent nuclear 
safety oversight. 

To develop our analysis, we reviewed NNSA documents and project data, 
toured DOE facilities, and interviewed officials from DOE, NRC, and 
nuclear utilities. We found that the MFFF project was subject to 
schedule delays stemming, in part, from the delivery of reinforcing 
bars that did not meet nuclear quality standards. 

Case Studies 7 and 14: From Transportation Worker Identification 
Credential, [hyperlink, http://www.gao.gov/products/GAO-10-43], 
December 10, 2009: 

The Transportation Worker Identification Credential (TWIC) program, 
managed by the Department of Homeland Security's (DHS) Transportation 
Security Administration (TSA) and the U.S. Coast Guard, required 
maritime workers who accessed secure areas of transportation facilities 
to obtain a biometric identification card to gain access. A TWIC 
regulation set a national compliance deadline of April 15, 2009. In 
part to inform the development of a second TWIC regulation, TSA was 
conducting a pilot program to test the use of TWICs with biometric card 
readers. We were asked to evaluate (1) TSA's and the Coast Guard's 
progress and related challenges in implementing TWIC and (2) the 
management challenges, if any, that TSA, the Coast Guard, and DHS faced 
in executing the TWIC pilot test. 

We reviewed TWIC enrollment and implementation documents and conducted 
site visits or interviewed officials at the seven pilot program sites. 
We found that TSA had made progress in incorporating management best 
practices to execute the TWIC pilot test, aimed at informing the 
Congress. But TSA faced two management challenges to ensure the 
successful execution of the test and the development of the second TWIC 
regulation. First, TSA faced problems in using the TWIC pilot schedule 
to both guide the pilot and accurately identify the pilot's completion 
date. Although TSA had improved its scheduling practices in executing 
the pilot, weaknesses remained, such as not capturing all pilot 
activities in the schedule. This could adversely affect the schedule's 
usefulness as both a management tool and a means of communication among 
pilot participants. Second, shortfalls in planning for the TWIC pilot 
hindered TSA and the Coast Guard's efforts to ensure that the pilot (1) 
represented deployment conditions and (2) would yield the information 
needed--such as the operational effects of deploying biometric card 
readers and their costs--to accurately inform the Congress and develop 
the second regulation. This was partly because TSA and the Coast Guard 
had not developed an evaluation plan that fully identified the scope of 
the pilot or specified how information from the pilot would be 
analyzed. The current evaluation plan described data collection methods 
but did not identify the evaluation criteria and methodology for 
analyzing the pilot data once they were collected. A well-developed, 
sound evaluation plan would help TSA and the Coast Guard determine how 
the data were to be analyzed to measure the pilot's performance. 

Case Studies 8 and 18: From Aviation Security, [hyperlink, 
http://www.gao.gov/products/GAO-11-740], July 12, 2011: 

Explosives represent a continuing threat to aviation security. To 
detect explosives, TSA used the Electronic Baggage Screening Program 
(EBSP) for checked baggage. To identify and resolve threats in checked 
baggage, the program includes the use of the explosives detection 
system (EDS) in conjunction with explosives trace detection (ETD) 
machines. 

We analyzed EDS requirements, compared the EDS acquisition schedule 
against our best practices, and interviewed DHS officials. We found 
that TSA had faced challenges in procuring the first 260 EDSs to meet 
2010 requirements. For example, the danger associated with some 
explosives challenged TSA and DHS in developing simulants and 
collecting data on the explosives' physical and chemical properties. 
Vendors and agencies needed these data to develop detection software 
and test EDSs before acquisition. In addition, TSA's decision to pursue 
EDS procurement during data collection complicated both efforts and 
resulted in a delay of over 7 months for the 2011 EDS procurement. TSA 
could have helped avoid additional schedule delays by completing data 
collection for each phase of the 2010 requirements before pursuing EDS 
procurement that met those requirements. Although TSA had established a 
schedule for the 2011 EDS procurement, (1) the schedule did not fully 
comply with our best practices and (2) TSA had not developed a plan to 
upgrade its EDS fleet to meet the 2010 requirements. 

Case Studies 9 and 11: From Immigration Benefits, [hyperlink, 
http://www.gao.gov/products/GAO-12-66], November 22, 2011: 

Each year, using a paper-based process, DHS's U.S. Citizenship and 
Immigration Services (USCIS) handles millions of applications for 
immigration benefits. In 2005, USCIS embarked on a major multiyear 
transformation program meant to transform its current process to a 
system that would incorporate electronic application filing, 
adjudication, and case management. In 2007, we reported that USCIS 
planned, in the early stages of the program, to partially or fully meet 
best practices. In 2008, USCIS contracted with a solutions architect to 
help develop the new program. 

We reviewed DHS's acquisition management policies and guidance; 
analyzed transformation program planning and implementation documents, 
such as operational requirements; compared schedule and cost 
information with our guidance for best practices; and interviewed USCIS 
officials. We found that USCIS was continuing to manage the program 
without specific acquisition management controls, such as reliable 
schedules, that would have detailed work to be performed by both the 
government and its contractor over the expected life of the program. As 
a result, USCIS did not have reasonable assurance that it could meet 
its future milestones. In particular, although USCIS had established 
schedules for the first release of the transformation program, our 
analysis showed that these schedules were unreliable because they did 
not meet best practices for schedule estimating. 

Case Studies 10 and 12: From FAA Acquisitions, [hyperlink, 
http://www.gao.gov/products/GAO-12-223], February 16, 2012: 

The Federal Aviation Administration (FAA), partnering with other 
federal agencies and the aviation industry, is implementing the Next 
Generation Air Transportation System (NextGen), a new satellite-based 
air traffic management system that will replace the current radar-based 
system and is expected to enhance the safety and capacity of the air 
transport system by 2025. In a review of 30 major ATC acquisition 
programs, all contributing to the transition to NextGen, GAO found that 
costs for 11 of the 30 programs had increased from their initial 
estimates by a total of $4.2 billion and that 15 programs had 
experienced delays. The 11 acquisitions accounted for over 60 percent 
of FAA's total acquisition costs ($11 billion of $17.7 billion) for the 
30 programs. The 15 acquisitions, 10 of which also had cost increases, 
ranged from 2 months to more than 14 years and averaged 48 months. 

To determine the extent to which select ATC programs adhered to best 
practices for determining acquisition costs and schedules, we conducted 
an in-depth review of 4 of the 30 acquisitions programs: the Automatic 
Dependent Surveillance-Broadcast (ADS-B) system, the Collaborative Air 
Traffic Management Technologies (CATMT) system, the System Wide 
Information Management (SWIM) system, and the Wide Area Augmentation 
System (WAAS). In addition to interviews, we collected documentation, 
and we analyzed and summarized the views and information we collected. 
We also performed a schedule risk analysis of the WAAS program to 
determine the likelihood of the project's finishing on schedule. 

FAA was not consistently following the characteristics of high-quality 
cost estimates and scheduling best practices for the four programs GAO 
analyzed. Regarding scheduling practices, most programs did not 
substantially or fully meet the majority of the 9 best practices GAO 
previously identified, including developing a fully integrated master 
schedule of all program activities and performing a schedule risk 
analysis. For example, without a schedule risk analysis, FAA is unable 
to predict, with any degree of confidence, whether the estimated 
completion dates are realistic. FAA is implementing new processes and 
organizational changes to better manage acquisitions. However, by not 
consistently following the characteristics of high-quality cost 
estimate and scheduling best practices, FAA cannot provide reasonable 
assurance to the Congress and other stakeholders that NextGen and other 
ATC programs will avoid additional cost increases or schedule delays. 

Case Study 13: From Nuclear Waste, [hyperlink, 
http://www.gao.gov/products/GAO-10-816], September 14, 2010: 

At DOE's Savannah River Site in South Carolina, decades of nuclear 
materials production had left 37 million gallons of radioactive liquid 
waste in 49 underground storage tanks. In December 2008, DOE entered 
into a contract with Savannah River Remediation, LLC (SRR), to close, 
by 2017, 22 of the highest-risk tanks at a cost of $3.2 billion., 

We visited the Savannah River Site and reviewed tank closure documents. 
We also analyzed the construction schedule of the Salt Waste Processing 
Facility (SWPF). This facility was vital to successful tank closure 
because the SWPF was to treat a large portion of the waste removed from 
the tanks. We found that the SWPF construction schedule did not fully 
meet the best scheduling practices we identified. For example, the 
schedule had problems with excess float between activities, indicating 
that these activities may not have been sequenced logically. To 
mitigate the effects of construction delays, DOE was exploring ways to 
deploy new technologies to treat radioactive waste. However, additional 
research and development on these new technologies was required. 
Therefore, it would be several years before they could be deployed. 

Case Study 15: From Coast Guard, [hyperlink, 
http://www.gao.gov/products/GAO-11-743], July 28, 2011: 

The Deepwater Program--the largest acquisition program in the Coast 
Guard's history--began in 1996 as an effort to recapitalize the Coast 
Guard's operational fleet including ships, aircraft, and other 
supporting capabilities. In 2007, the Coast Guard took over the lead 
systems integrator role from the Integrated Coast Guard Systems, 
establishing a $24.2 billion overall program baseline. 

We reviewed key Coast Guard documents and applied criteria from the GAO 
Cost Guide. We found that the estimated total acquisition cost of the 
Deepwater Program, based on approved program baselines as of May 2011, 
could have been as much as approximately $29.3 billion, or about $5 
billion more than the $24.2 billion baseline approved by DHS in 2007. 
However, we also found that two factors precluded a solid understanding 
of the program's true cost and schedule: (1) the Coast Guard had not 
yet developed revised baselines for all assets, including the Offshore 
Patrol Cutter--the largest cost driver in the program--and (2) the 
Coast Guard's most recent capital investment plan indicated further 
cost and schedule changes not yet reflected in the asset baselines. We 
also found that the reliability of the cost estimates and schedules for 
selected assets were undermined because the Coast Guard did not follow 
key best practices for developing these estimates. 

Case Study 19: From 2010 Census, [hyperlink, 
http://www.gao.gov/products/GAO-10-59], November 13, 2009: 

To carry out the decennial census, the U.S. Census Bureau conducts a 
sequence of thousands of activities and numerous operations. As 
requested, we examined its use of (1) scheduling tools to maintain and 
monitor progress and (2) two control systems key to field data 
collection--one to manage the work flow for paper-based operations, 
including nonresponse follow-up, and the other to manage quality 
control for two major field operations. We applied schedule analysis 
tools; reviewed the Bureau's evaluations, planning documents, and other 
documents on work flow management; and interviewed Bureau officials. 

We found that as the Bureau carries out the census, its master schedule 
provides a useful tool to gauge progress, identify and address 
potential problems, and promote accountability. We also found that the 
Bureau's use of its master schedule generally follows leading 
scheduling practices, which allow such high-level oversight. However, 
the errors we found in the Bureau's master schedule were hindering its 
ability to identify the effects of activity delays and to plan for the 
unexpected. 

[End of Appendix V] 

Appendix VI: Experts Who Helped Develop This Guide: 

The two lists in this appendix name the experts in the scheduling 
community, along with their organizations, who helped us develop this 
guide. This first list names significant contributors to the Schedule 
Guide. They attended and participated in numerous expert meetings, 
provided text or graphics, and submitted comments. 

Organizations: 

ABBA Consulting; 
Expert: Wayne Abba. 

Acumen; 
Expert: Brad Arterbury. 

AECOM & PMI Scheduling President; 
Expert: Pradip Mehta. 

Air Force; 
Expert: Jennifer Bowles.
Expert: John Cargill.
Expert: Fred Meyer.
Expert: Donna Rosenbaum. 

Arcadis; 
Expert: John Livengood. 

ARES Software; 
Expert: Eden Gold. 

Bechtel Jacobs; 
Expert: Darryl Walker. 

Belstar, Inc (Former AACE President); 
Expert: Osmund Belcher. 

Booz Allen Hamilton; 
Expert: Javed Hasnat.
Expert: Greg Hogan.
Expert: Seth Huckabee. 

Chartered Institute of Building; 
Expert: Saleem Sakram. 

Construction Consulting Services, LLC; 
Expert: Stephen Lee. 

CPIC Solutions Corp; 
Expert: William Mathis. 

David Consulting Group; 
Expert: Michael Harris. 

DEAMS; 
Expert: Harold Parker. 

Defense Acquisition University; 
Expert: Robert Pratt. 

Defense Contract Management Agency; 
Expert: Erik Berg.
Expert: Donna Holden. 

Delta Group; 
Expert: Joseph Perron. 

Department of Energy; 
Expert: Brian Kong.
Expert: Reuben Sanchez. 

Department of Homeland Security; 
Expert: Christine Ketcham.
Expert: Lawrence Mugg.
Expert: Robert Uzel. 

Department of Justice; 
Expert: Lionel Cares.
Expert: Teresa Palmer. 

Department of the Treasury; 
Expert: Kimberly Smith. 

ESPM Inc; 
Expert: Joe Halligan. 

EVMWIG; 
Expert: Jimmy Black.
Expert: Camilla Canty.
Expert: Jon Fleming.
Expert: Kristen Kehrer.
Expert: Jerald Kerby.
Expert: Lin Kroeger.
Expert: Debbie Schumann. 

Federal Acquisition Certification Academy; 
Expert: Ben Sellers. 

Federal Aviation Administration; 
Expert: Fred Sapp. 

General Services Administration; 
Expert: Bill Hunt. 

HNTB Corporation; 
Expert: Mike Debiak. 

Hulett & Associates, LLC; 
Expert: David Hulett. 

ICS-Global;
Expert: Murray Wolf. 

Independent Consultant; 
Expert: Anthony Corridore.
Expert: Joyce Glenn. 

INDUS Corporation; 
Expert: Jay Goldberg. 

KM Systems Group; 
Expert: Joe Houser.
Expert: Kimberly Hunter. 

L-3 Stratis; 
Expert: Eric Christoph. 

Legis Consultancy; 
Expert: Patrick Ray. 

Lockheed Martin; 
Expert: Scott Gring. 

Longview-FedConsulting JV; 
Expert: Charles Cobb.
Expert: Sandra Marin. 

Ludwig Consulting Services, LLC; 
Expert: Joyce Ludwig. 

Management Concepts; 
Expert: John Driessnack. 

Management Technologies; 
Expert: Raymond Stratton. 

MBP; 
Expert: Jill Hubbard.
Expert: Niyi Ladipo. 

MCR Federal LLC; 
Expert: Neil Albert.
Expert: Susan Barton.
Expert: Raymond Covert.
Expert: Brian Evans. 

Missile Defense Agency; 
Expert: David Anderson.
Expert: Ken Twining. 

MITRE; 
Expert: Stephen Bonk.
Expert: Clarke Thomason.
Expert: Nathan Welch. 

Organization: NASA; 
Expert: Tom Coonce.
Expert: Zachory Dolch.
Expert: Carol Grunsfeld.
Expert: Ken Poole. 

Organization: National Science Foundation; 
Expert: Patrick Haggerty. 

Organization: NAVAIR; 
Expert: John Scaparro. 

Organization: Naval Center (NCAA); 
Expert: Duncan Thomas. 

Organization: Northrop Grumman; 
Expert: Raymond Bollas.
Expert: Anthony Claridge.
Expert: Gay Infanti. 

Organization: Oracle;
Expert: Chris Sala.
Expert: Kristy Tan. 

Organization: Parsons Brinckerhoff; 
Expert: Marie Gunnerson. 

Organization: Price Waterhouse Coopers; 
Expert: Jennifer; Mun. 

Organization: ProChain Solutions, Inc.; 
Expert: Rob Newbold. 

Organization: Project & Cost Management Consulting Services; 
Expert: Christopher Gruber. 

Organization: Project Management Consultant; 
Expert: Shashi Khanna. 

Organization: Project Time & Cost; 
Expert: Michael Nosbisch.
Expert: Chris Watson. 

Organization: PT Mitratata Citragraha; 
Expert: Paul Giammalvo. 

Organization: R. J. Kohl & Assoc.; 
Expert: Ronald Kohl. 

Organization: Raytheon; 
Expert: Joshua Anderson.
Expert: Warren Kline.
Expert: Joseph Kusick. 

Organization: ServQ; 
Expert: Andrew Crossley. 

Organization: SRA; 
Expert: Shobha Mahabir. 

Organization: Technomics; 
Expert: Scott DeNegre. 

Organization: Tecolote Research, Inc.;
Expert: Mike Dalessandro.
Expert: Darren Elliott.
Expert: Anthony Harvey.
Expert: Greg Higdon.
Expert: James Johnson.
Expert: Linda: Milam.
Expert: Alf Smith. 

Organization: The Earned Value Group; 
Expert: Glenn Counts. 

Organization: Valued Technology; 
Expert: Keith Corner. 

Organization: VARiQ; 
Expert: Christopher Ditta. 

Organization: Walter Majerowicz Consulting; 
Expert: Walter Majerowicz. 

This second list names those who generously donated their time 
to review this guide in its various stages and who provided feedback. 

Organization: Accenture;
Expert: Tom Maraglino.
Expert: Nick Mark.
Expert: Mark Nickolas.
Expert: Patrick South.
Expert: Phil Wood. 

Organization: Acumen; 
Expert: Jackie O'Connor.
Expert: Dan Patterson. 

Organization: Air Force; 
Expert: Shannon House.
Expert: Dolores LaGuarde.
Expert: Dennis Rackard. 

Organization: Army; 
Expert: Jay Billings.
Expert: Sean Vessey. 

Organization: AzTech International, LLC; 
Expert: Luis Contreras.
Expert: Timothy Fritz.
Expert: James Ivie.
Expert: Zachary Lindemann.
Expert: Dave Rutter.
Expert: Blaine Schwartz.
Expert: Joy Sichveland. 

Organization: Barrios Technology; 
Expert: Patrick McGarrity. 

Organization: Battelle;
Expert: Bill Altman.
Expert: Chuck Chapin. 

Organization: BIA; 
Expert: Vivian Deliz. 

Organization: Boeing; 
Expert: Kirk Kotthoff.
Expert: Barbara Park. 

Organization: Booz Allen Hamilton; 
Expert: Tim Boatwright.
Expert: Tiffenie Shircliffe.
Expert: Calvin Speight. 

Organization: Centers for Disease Control and Prevention; 
Expert: Kimberly Crenshaw. 

Organization: Chevo Consulting; 
Expert: Cyndy Iwan.
Expert: Michelle Powell. 

Organization: Cobec Consulting Inc.; 
Expert: Dan French. 

Organization: Commerce Trade Administration; 
Expert: Peggy White-Fouts. 

Organization: Consultant - Boeing, Retired; 
Expert: John Pakiz. 

Organization: D&G; 
Expert: Chris Alberts. 

Organization: David Consulting Group; 
Expert: David Herron. 

Organization: Defense Acquisition University; 
Expert: Mark Husband. 

Organization: Defense Contract Management Agency; 
Expert: Marvin Charles. 

Organization: Deloitte Consulting LLP; 
Expert: Robyn Wiley. 

Organization: Delta Group; 
Expert: Christopher Melling. 

Organization: Department of Education; 
Expert: Tauqir Jilani. 

Organization: Department of Energy; 
Expert: Fredericka Baker.
Expert: Richard Couture.
Expert: Ronald Lile.
Expert: Robert McCoy.
Expert: Victoria: Pratt.
Expert: Autar Rampertaap.
Expert: Karen Urschel. 

Organization: Department of Homeland Security; 
Expert: Jose Christian.
Expert: Michael Divecchio.
Expert: Katie Geier.
Expert: James Mararac.
Expert: Steve Nakazawa.
Expert: Lauren Riner.
Expert: William R. Taylor.
Expert: Mark Terry.
Expert: Michael Zaboski. 

Organization: Department of Justice; 
Expert: Anthony Burley.
Expert: Bellorh Byrom.
Expert: Tapan Das.
Expert: Bryce Mitchell. 

Organization: Department of Transportation; 
Expert: Traci Stith. 

Organization: Federal Aviation Administration; 
Expert: Sharon 
Boddie.
Expert: William Russell. 

Organization: Galorath Incorporated; 
Expert: Daniel Galorath.
Expert: Bob Hunt. 

Organization: General Services Administration; 
Expert: Arnold 
Hill.
Expert: Patrick Plunket.
Expert: Gene Ransom.
Expert: John Ray. 

Organization: George Washington University; 
Expert: Homayoun Khamooshi. 

Organization: Health and Human Services; 
Expert: Gerald Brozyna.
Expert: Rita Warren. 

Organization: Huntington Ingalls Inc.; 
Expert: Doug Baggett.
Expert: Dan Burke.
Expert: Bruce Lemmert. 

Organization: Idaho National Laboratory (INL); 
Expert: Rick Staten. 

Organization: Independent Consultant; 
Expert: Sheila DeBardi.
Expert: Gerard Jones. 

Organization: Internal Revenue Service; 
Expert: Donald 
Moushegian. 

Organization: ITG; 
Expert: Judy Rexin. 

Organization: ITT Exelis; 
Expert: Brenda Malmberg.
Expert: Bill Mendolsohn. 

Organization: KP-IT SCAL; 
Expert: Kathy Cook. 

Organization: KPMG; 
Expert: Mark Hogenmiller. 

Organization: Legis Consultancy, Inc.; 
Expert: Dave Smart. 

Organization: Lockheed Martin; 
Expert: Marcy Barlett.
Expert: James Fieber. 

Organization: Management & Aviation 
Expert: Sven Antvik.
Expert: Andrew Lovorn.
Expert: David Treacy. 

Organization: MDS; 
Expert: Mark Ives. 

Organization: MITRE; 
Expert: Raj Agrawal.
Expert: Charlie Dobbs.
Expert: Eric Fisher.
Expert: Daniel Harper.
Expert: Ron Hess.
Expert: Richard Riether.
Expert: Victoria Smith. 

Organization: Monte Ingram & Associates, LLC; 
Expert: Monte Ingram. 

Organization: NASA; 
Expert: Heidemarie Borchardt.
Expert: Barbara Carroon.
Expert: Claude Freaner.
Expert: David Hall.
Expert: Jerry Holsomback.
Expert: Zach Hunt.
Expert: James Johnson.
Expert: Fred Kuo.
Expert: Patrick Maggarity.
Expert: Nakia Marks.
Expert: Arlene Moore.
Expert: Johnnetta Punch.
Expert: Yvonne Simonsen.
Expert: Mike Soots.
Expert: Steve Sterk.
Expert: Steve Wilson. 

Organization: National Oceanic and Atmospheric Administration/Weather 
Service; 
Expert: Alpha Bailey. 

Organization: National Science Foundation; 
Expert: Jack Matthewman. 

Organization: Naval Air Systems Command; 
Expert: Jeffrey Upton. 

Organization: Naval Center (NCAA); 
Expert: Tim Lawless. 

Organization: Naval Sea Systems Command; 
Expert: Hershel Young. 

Organization: Navy Postgraduate School - Boeing;
Expert: Daniel; 
Expert: Dassow.
Expert: Maria Sims. 

Organization: Northrop Grumman; 
Expert: Jim Chappell.
Expert: Josh Dornan.
Expert: Stanton Smith. 

Organization: Oak Ridge National Lab; 
Expert: Bill Toth. 

Organization: Office of Management and Budget; 
Expert: Jim Wade. 

Organization: Office of the Secretary of Defense; 
Expert: Joseph Beauregard. 

Organization: PARCA; 
Expert: David Nelson. 

Organization: Pentagon; 
Expert: Robert Loop. 

Organization: Performance Results Corporation; 
Expert: Greg 
Dowd. 

Organization: Pratt & Whitney Rocketdyne; 
Expert: Gregory 
Manley.
Expert: Fernando Vivero. 

Organization: PRICE Systems LLC; 
Expert: Zach Jasnoff. 

Organization: Principle of Davis Langdon; 
Expert: Peter Morris. 

Organization: Project & Program Management Solutions; 
Expert: Matthew Morris. 

Organization: QS Requin Corp; 
Expert: Alexia Nalewaik. 

Organization: Raytheon; 
Expert: Jeff Poulson. 

Organization: Robbins Gioia; 
Expert: Boris Blechman. 

Organization: Ron Winter Consulting; 
Expert: Ron Winter. 

Organization: SAIC; 
Expert: Ralph Justus.
Expert: Laura Mraz. 

Organization: SETA Contractor;
Expert: John Roland. 

Organization: SM&A; 
Expert: Mark Infanti. 

Organization: Systems Made Simple; 
Expert: Ron Lattomus. 

Organization: Technomics; 
Expert: Peter Braxton.
Expert: Colleen Craig.
Expert: Richard Lee.
Expert: Brian Octeau. 

Organization: Tecolote Research, Inc.; 
Expert: Darren Elliott.
Expert: Michael Harrison.
Expert: Bill Rote. 

Organization: The Rehancement Group, Inc.; 
Expert: Peter 
Chrzanowski. 

Organization: Trade; 
Expert: Peggy Fouts. 

Organization: United States Capitol Police; 
Expert: Ken Sragg. 

[End of Appendix VI] 

Appendix VII: GAO Contacts and Staff Acknowledgments: 

GAO Contact: 

Timothy M. Persons, Ph.D., Chief Scientist, at (202) 512-6412 or 
personst@gao.gov: 

Other Leadership Provided for This Project: 

Karen Richey, Assistant Director, Applied Research and Methods (ARM), 
and: Jason T. Lee, Analyst-in-Charge and Senior Cost Analyst, also in 
ARM. 

Key Contributors: 

Pille Anvelt, Visual Communications Analyst Avrum Ashery, Visual 
Communications Analyst Mathew Bader, Information Technology Analyst Amy 
Bowser, Senior Attorney Carol R. Cha, Acting Director, Information 
Technology Issues Kimani Darasaw, Analyst Tisha Derricotte, Senior Cost 
Analyst Jennifer Echard, Senior Cost Analyst Kaelin Patrick Kuhn, 
Senior Analyst Constantine (Dino) Papanastasiou, Information 
Technology Analyst Penny Pickett, Ph.D., Senior Communications Analyst 
Matt Snyder, Information Technology Analyst Stacey Steele, Senior Cost 
Analyst: 

[End of Appendix VII] 

References: 

AFMC (Air Force Materiel Command). Integrated Master Plan and Schedule 
Guide, AFMC Pamphlet 63-5. Wright-Patterson AFB, Ohio: 2005. 

Ambriz, Rodolfo. Dynamic Scheduling with Microsoft® Project 2007. Fort 
Lauderdale, Fla. International Institute for Learning, 2008. 

Anderson, Mark I. Recovery Schedules. Rockville, Md.: Warner 
Construction Consultants, 2006. 

Antvik, Sven, and Håkan Sjöholm. Project Management and Methods 
(Projekt-ledning och metoder). Västerås, Sweden: Projektkonsult Håkan 
Sjöholm AB, 2007. 

Bolinger, Paul. Schedule Analysis of the Integrated Master Schedule. 
Orange, Calif.: Humphreys & Associates, May 2008. 

Book, Stephen A. "Schedule Risk Analysis: Why It Is Important and How 
to Do It." Presentation to the International Society of Parametric 
Analysts and the Society of Cost Estimating and Analysis, Denver, 
Colo.: MCR, June 14-17, 2005. 

CIOB (Chartered Institute of Building). Guide to Good Practice in the 
Management of Time in Complex Projects. Oxford: Wiley-Blackwell, 2011. 

Cooper, Sue L. "Basic Schedule Analysis." Presentation to the 
International Society of Parametric Analysts and the Society of Cost 
Estimating and Analysis, Denver, Colo.: Boeing, June14-17, 2005. 

DAU (Defense Acquisition University). ACC Practice Center--Risk 
Management. Fort Belvoir, Va.: Dec. 2011. 

DCMA (Defense Contract Management Agency). Integrated Master Plan/
Integrated Master Schedule Basic Analysis. Washington, D.C.: Nov. 21, 
2009. 

DOD (Department of Defense). Department of Defense Standard Practice: 
Work Breakdown Structures for Defense Materiel Items, MIL-STD-881C. 
Washington, D.C.: Oct. 3, 2011. 

DOD. Integrated Master Plan and Integrated Master Schedule. Washington, 
D.C.: Oct. 21, 2005. 

DOD. Integrated Master Schedule Data Item Description, DI-MGMT-81650. 
Washington, D.C.: Mar. 30, 2005. 

Douglas, Edward E. III. Documenting the Schedule Basis, AACE 
International Recommended Practice 38R-06. Morgantown, West Va.: 2009. 

DSMC (Defense Systems Management College). Schedule Guide for Program 
Managers. Fort Belvoir, Va.: Oct. 2001. 

FAA (Federal Aviation Authority). Acquisition Management Policy. 
Washington, D.C.: Jan. 2012. 

GAO (Government Accountability Office). 2010 Census: Census Bureau Has 
Made Progress on Schedule and Operational Control Tools, but Needs to 
Prioritize Remaining System Requirements, [hyperlink, 
http://www.gao.gov/products/GAO-10-59]. Washington, D.C.: Nov 13, 2009. 

GAO. Air Traffic Control Modernization: Management Challenges 
Associated with Program Costs and Schedules Could Hinder NextGen 
Implementation, [hyperlink, http://www.gao.gov/products/GAO-12-223]. 
Washington, D.C.: Feb. 16, 2012. 

GAO. Aviation Security: TSA Has Enhanced Its Explosives Detection 
Requirements for Checked Baggage, but Additional Screening Actions Are 
Needed, [hyperlink, http://www.gao.gov/products/GAO-11-740]. 
Washington, D.C.: July 11, 2011. 

GAO. Coast Guard: Action Needed as Approved Deepwater Program Remains 
Unachievable, [hyperlink, http://www.gao.gov/products/GAO-11-743]. 
Washington, D.C.: July 28, 2011. 

GAO. Cost Estimating and Assessment Guide, [hyperlink, 
http://www.gao.gov/products/GAO-09-3SP]. Washington, D.C.: Mar. 2009. 

GAO. DOD Business Transformation: Improved Management Oversight of 
Business System Modernization Efforts Needed, [hyperlink, 
http://www.gao.gov/products/GAO-11-53]. Washington, D.C.: Oct. 7, 2010. 

GAO. Immigration Benefits: Consistent Adherence to DHS's Acquisition 
Policy Could Help Improve Transformation Program Outcomes, [hyperlink, 
http://www.gao.gov/products/GAO-12-66]. Washington, D.C.: Nov 22, 2011. 

GAO. Military Readiness: DOD Needs to Strengthen Management and 
Oversight of the Defense Readiness Reporting System, [hyperlink, 
http://www.gao.gov/products/GAO-09-518]. Washington, D.C.: Sept. 25, 
2009. 

GAO. Nuclear Nonproliferation: DOE Needs to Address Uncertainties with 
and Strengthen Independent Safety Oversight of Its Plutonium 
Disposition Program, [hyperlink, 
http://www.gao.gov/products/GAO-10-378]. Washington, D.C.: Mar. 26, 
2010. 

GAO. Nuclear Waste: Actions Needed to Address Persistent Concerns with 
Efforts to Close Underground Radioactive Waste Tanks at DOE's Savannah 
River Site, [hyperlink, http://www.gao.gov/products/GAO-10-816]. 
Washington, D.C.: Sept. 14, 2010. 

GAO. Transportation Worker Identification Credential: Progress Made in 
Enrolling Workers and Activating Credentials but Evaluation Plan Needed 
to Help Inform the Implementation of Card Readers, [hyperlink, 
http://www.gao.gov/products/GAO-10-43]. Washington, D.C.: Nov. 18, 
2009. 

GAO. VA Construction: VA Is Working to Improve Initial Project Cost 
Estimates, but Should Analyze Cost and Schedule Risks, [hyperlink, 
http://www.gao.gov/products/GAO-10-189]. Washington, D.C.: Dec. 14, 
2009. 

Hillson, David. Use a Risk Breakdown Structure (RBS) to Understand Your 
Risks, proceedings of the Project Management Institute Annual Seminars 
& Symposium. San Antonio, Texas: Oct. 3-10, 2002. 

Hulett, David T. Advanced Quantitative Schedule Risk Analysis. Los 
Angeles, Calif.: Hulett and Associates, 2007. 

Hulett, David T. Practical Schedule Risk Analysis. Farnham, Surrey, 
U.K.: Gower, 2009. 

Hulett, David T. Advanced Project Scheduling and Risk Analysis. Los 
Angeles, Calif.: Hulett and Associates, 2009. 

International Institute for Learning, Inc. Project Orange Belt® 2007. 
New Yor: 2007. 

NASA (National Aeronautics and Space Administration). Scheduling 
Management Handbook, SP-2010-3403. Washington, D.C.: Jan. 2010. 

NAVAIR (Naval Air Systems Command). EVM Analysis Toolkit. Washington, 
D.C.: Apr. 14, 2009. 

NAVAIR Integrated Master Schedule Guidebook. Washington, D.C.: Feb. 
2010. 

NDIA (National Defense Industrial Association). Planning and Scheduling 
Excellence Guide, v1.1b. Arlington, Va.: Apr. 6, 2011. 

O'Brien, James J., and Fredric L. Plotnick. CPM in Construction 
Management, 6th ed. New York: McGraw-Hill, 2005. 

VA (Veterans Affairs). Master Construction Specifications--
Architectural and Engineering CPM Schedules, 01 32 16.01. Washington, 
D.C.: n.d. 

VA. Master Construction Specifications--Network Analysis Schedules, 01 
32 16.13. Washington, D.C.: n.d. 

VA. Master Construction Specifications--Project Schedules (Small 
Projects - Design/Bid/Build), 01 32 16.15. Washington, D.C.: n.d. 

VA. Master Construction Specifications--Project Schedules (Design-
Build Only), 01 32 16.16. Washington, D.C.: n.d. 

VA. Master Construction Specifications--Project Schedules (Design/
Build), 01 32 16.17. Washington, D.C.: n.d. 

USACE (U.S. Army Corps of Engineers). Cost and Schedule Risk Analysis 
Guidance (Draft). Washington, D.C.: May 17, 2009. 

Uyttewaal, Eric. Dynamic Scheduling with Microsoft® Project 2003. Boca 
Raton, Fla.: International Institute for Learning: 2005. 

Uyttewaal, Eric. A Proposed Standard for Critical Path 2.0. Oct. 20, 
2011. 

[End of References section] 

Footnotes: 

[1] We recognize that different organizations may use the term 
"integrated master schedule" differently; for example, an IMS is often 
used to refer solely to the prime contractor schedule. Our use of 
"integrated" implies the schedule's incorporation of all activities--
those of the contractor and government--necessary to complete the 
program. 

[2] More information on formal risk assessment is available in Best 
Practice 8, as well as in the GAO Cost Estimating and Assessment Guide, 
[hyperlink, http://www.gao.gov/products/GAO-09-3SP]. 

[3] For example, Federal Aviation Administration (FAA) service 
organizations employ standard program milestones when planning, 
executing, and reporting progress on investment programs. The standard 
program milestones are documented along with a description, completion 
criteria, WBS reference or crosswalk, and the decision authority. 

[4] See the GAO Cost Estimating and Assessment Guide (GAP-09-3SP) for 
numerous examples of standard work breakdown structures for, among 
others, surface, sea, and air transportation systems; military systems; 
communications systems; and systems for construction and utilities. 

[5] A schedule baseline document and its recommended content are 
detailed in Best Practice 10. 

[6] In addition, a Department of Defense (DOD) program IMS should be 
vertically traceable to events, accomplishments, and criteria within 
the integrated master plan (IMP). The IMS includes the detailed 
activities necessary to support the criteria. 

[7] A theoretical, fourth combination of logical links exists between 
predecessor and successor. The start-to-finish (S-F) link has the 
bizarre effect of directing a successor activity not to finish until 
its predecessor activity starts, in effect reversing the expected flow 
of sequence logic. Its use is widely discouraged because it is 
counterintuitive and it overcomplicates schedule network logic. 
Examples of activity sequences used to justify the existence of an S-F 
relationship can usually be rewritten in simple F-S logic by either 
subdividing activities or finding more appropriate F-S predecessors 
within the network. 

[8] Unless otherwise stated in this guide, "start" and "finish" refer 
to an activity's early start and early finish dates. 

[9] Vertical traceability is discussed in detail in Best Practice 5. 

[10] Our definitions of hard and soft constraints assume that a 
schedule is formulated under forward scheduling. That is, the project 
start date is firm and all activities are scheduled to occur as soon as 
possible to determine the project finish date. Under backward 
scheduling, the project end date is considered firm and all activities 
are scheduled as late as possible to determine the project start date. 
Whether the plan is forward or backward scheduled affects how 
restrictive certain constraints are. For example, under backward 
scheduling, a finish no earlier than constraint is considered a "hard" 
constraint. 

[11] Parallel lines do not converge in mathematics. However, in 
scheduling parlance, paths and activities are parallel if they occur in 
the same work periods. The paths converge when their activities have 
the same successor. 

[12] For more information on the relationship between cost, schedule, 
and EVM, see GAO Cost Estimating and Assessment Guide, [hyperlink, 
http://www.gao.gov/products/GAO-09-3SP], chs. 18 and 19. 

[13] Free float is the amount of time by which an activity can be 
delayed without affecting any successor (see Best Practice 7). 

[14] Logic specifically inserted to solve resource leveling issues once 
the plan is baselined is known as "preferential logic" or "soft logic." 
Preferential logic dictates a desired sequence of activities that is 
not entirely necessary. That is, the logic is not related to the work 
itself but reflects management's plan for realistically executing the 
work. Conversely, "engineering logic," or "hard logic," dictates an 
order of activities that must occur regardless of preference. For 
example, concrete curing must always occur after pouring concrete. 
Inserting preferential logic to address resource leveling may be 
subject to the program's schedule change control process. 

[15] Usually biased estimating has the purpose of achieving an earlier 
project finish date, often to satisfy management or the customer. That 
is, the direction of the estimating bias is typically not symmetrical. 

[16] Schedule risk analysis can handle this phenomenon with 
probabilistic calendars, where any day has less than a 100 percent 
chance of being a working day, with that percentage reflecting the 
historical experience of people taking time off during a holiday 
season. 

[17] Negative float and its causes are discussed in detail in Best 
Practice 7. 

[18] Unfortunately, no easy method of calculating the "near longest 
path" in complex schedules would alert management and schedulers to 
activities near the path of longest duration. 

[19] Specifically, float is calculated from an activity's early start 
date and is the amount of time the activity can be delayed before 
delaying the early start of its successor or the project finish date. 

[20] A schedule network may also mathematically calculate independent 
float and interfering float. Independent float is the amount of time 
the activity can be delayed without delaying successor activities or 
restricting the scheduling of preceding activities. Interfering float 
is the difference between an activity's total float and free float. 

[21] Typically, total float is calculated by the scheduling software to 
the last activity in the schedule file, but other activities or interim 
milestones may be monitored for total float, using constraints on key 
interim milestones. With these constraints, using total float to 
identify the critical path to the finish milestone is a flawed method. 

[22] Total float is also tied to the overall confidence level of a 
schedule, assuming that a schedule risk analysis has been performed. 
The more optimistic a schedule may be (less confidence in meeting the 
completion date), the lower the available float is; the more 
pessimistic a schedule (more confidence in meeting the completion 
date), the higher the available float. 

[23] For more information on the difference between uncertainty and 
risk, see Chapter 14 in the GAO Cost Estimating and Assessment Guide, 
[hyperlink, http://www.gao.gov/products/GAO-09-3SP]. 

[24] A risk register formally documents a project's identified risks, 
including likelihoods, consequences, mitigation plans, and current 
status. 

[25] For more information on formal risk assessments and their relation 
to cost, schedule, and EVM, see [hyperlink, 
http://www.gao.gov/products/GAO-09-3SP]. 

[26] For more information on developing probability distributions to 
model uncertainty, see chapter 14 in the GAO Cost Estimating and 
Assessment Guide, [hyperlink, http://www.gao.gov/products/GAO-09-3SP]. 

[27] For our purposes in this guide, contingency represents time 
reserve held at or above the government program management office for 
"unknown unknowns" that are outside a contractor's control. In this 
context, schedule contingency is added to a schedule to allow for 
items, conditions, or events for which the state, occurrence, or effect 
is uncertain and for which experience implies likely delays. Schedule 
reserve, in contrast, is for "known unknowns" that are tied to the 
contract's scope and managed at the contractor level. We recognize that 
other organizations may define the terms schedule contingency, schedule 
reserve, schedule buffer, and schedule margin differently. 

[28] Probabilistic branching is used to model the random choice between 
two alternatives. An advanced technique known as "conditional 
processing" is also available in an SRA. With conditional processing, 
an action is determined by some scheduled event rather than randomness. 
That is, it is modeled as an "If…then…else" statement rather than a 
probabilitiy of occurrence. For example, if a design activity takes 2 
weeks, then execute Plan A, otherwise (else) execute Plan B. 

[29] If activities representing schedule contingency are not removed 
before conducting an update to the SRA, they will adversely affect the 
results. 

[30] Establishing and maintaining a schedule baseline is highly 
significant when EVM is a requirement. In this case, the entire 
schedule must be baselined because the IMS is the source of time-
phasing for all control accounts and work packages that make up the 
project's performance measurement baseline. This requirement will apply 
to contracted effort and may apply to the government effort as well, 
depending on the agency. For contracted efforts, the baselines for cost 
and schedules are required to support the integrated baseline review 
(IBR). In reality, to successfully prepare for the IBR, baselines must 
be set (either formally or informally) much earlier than the IBR 
deadline to ensure credibility. 

[End of Footnotes] 

[End of section] 

GAO’s Mission: 

The Government Accountability Office, the audit, evaluation, and 
investigative arm of Congress, exists to support Congress in meeting 
its constitutional responsibilities and to help improve the 
performance and accountability of the federal government for the 
American people. GAO examines the use of public funds; evaluates 
federal programs and policies; and provides analyses, recommendations, 
and other assistance to help Congress make informed oversight, policy, 
and funding decisions. GAO’s commitment to good government is 
reflected in its core values of accountability, integrity, and 
reliability. 

Obtaining Copies of GAO Reports and Testimony: 

The fastest and easiest way to obtain copies of GAO documents at no 
cost is through GAO’s website [hyperlink, http://www.gao.gov]. Each 
weekday afternoon, GAO posts on its website newly released reports, 
testimony, and correspondence. To have GAO e-mail you a list of newly 
posted products, go to [hyperlink, http://www.gao.gov] and select “E-
mail Updates.” 

Order by Phone: 

The price of each GAO publication reflects GAO’s actual cost of 
production and distribution and depends on the number of pages in the 
publication and whether the publication is printed in color or black 
and white. Pricing and ordering information is posted on GAO’s 
website, [hyperlink, http://www.gao.gov/ordering.htm]. 

Place orders by calling (202) 512-6000, toll free (866) 801-7077, or 
TDD (202) 512-2537. 

Orders may be paid for using American Express, Discover Card, 
MasterCard, Visa, check, or money order. Call for additional 
information. 

Connect with GAO: 

Connect with GAO on facebook, flickr, twitter, and YouTube.
Subscribe to our RSS Feeds or E mail Updates. Listen to our Podcasts.
Visit GAO on the web at [hyperlink, http://www.gao.gov]. 

To Report Fraud, Waste, and Abuse in Federal Programs: 

Contact: 
Website: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]; 
E-mail: fraudnet@gao.gov; 
Automated answering system: (800) 424-5454 or (202) 512-7470. 

Congressional Relations: 

Katherine Siggerud, Managing Director, siggerudk@gao.gov, (202) 512-4400
U.S. Government Accountability Office, 441 G Street NW, Room 7125
Washington, DC 20548. 

Public Affairs: 
Chuck Young, Managing Director, youngc1@gao.gov, (202) 512-4800
U.S. Government Accountability Office, 441 G Street NW, Room 7149 
Washington, DC 20548.