GAO Schedule 

Assessment Guide

Best Practices for project schedules

United States Government Accountability Office

GAO Applied Research and Methods

GAO-12-12OG

May 2012

Task name Duration Total float

Install first floor joists and decking

Install water proofing on exterior

basemant walls

 Finish excavate and

 pour basement floor

Frame first floor walls

Install roof trusses

Install roof decking

Exterior backfill basement wells

Rough grade property

Form and pour driveway

Finish excavate and 

pour garage floor

Rough-in framing inspection

Framing complete

2 days

2 days

2 days

1 day

1 day

1 day

1 day

2 days

2 days

4 days

0 days

3 days

0 days ‘65

0 days ‘66

0 days ‘67

0 days ‘68

0 days ‘69

0 days ‘70

7 days ‘66

7 days ‘72

0 days ‘71 ’73

0 days ‘74

2 days ‘71

0 days ‘75 ’76 FS+2 days

March 10, ‘13 March 17, ‘13 March 24, ‘13 March 31, ‘13

M T W T F S S M T W T F S S M T W T F S S M T W T F S

12

6 start

finish

Work package: 

Install first floor joists

1 Install first floor joists and decking

2 Install water proofing on exterior 

 basemant walls

3 Finish excavate and pour 

 basement floor

4 Frame first floor walls 

5 Install roof trusses 

6 Install roof decking

7 Exterior backfill basement wells

8 Rough grade property

9 Form and pour driveway

10 Finish excavate and pour 

 garage floor

11 Rough-in framing inspection

12 Framing complete

Scheduling

Sub-task

work-package

D

U

RATION

2 days

 1 day

3 days

 4 days

 5 days

 20 days

 30 days

 15 days

 25 days

 6 days

7 days

 8 days

 9 days

 10 days

 35 days 40 days 45 days 50 days

Planning

Program

Task

Phase

Project

house

 1 day

2 days

3 days

 4 days

 5 days

 6 days

7 days

 8 days

 9 days

 10 days

“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.”
Page i GAO-12-120G Schedule Assessment 

Preface 1 

Introduction and Concepts 3

Ten Best Practices 3

The Integrated Master Schedule 6

The Critical Path Method 7

Planning, Scheduling, and the Scheduler 8

Best Practice 1 Capturing All Activities 10

Capturing All Effort 10

Constructing an IMS 15

Work Breakdown Structure 17

Activity Names 21

Activity Codes 23

Best Practices Checklist: Capturing All Activities 24

Best Practice 2 Sequencing All Activities 26

Predecessor and Successor Logic 26

Incomplete and Dangling Logic 31

Summary Logic 34

Date Constraints 36

Using Date Constraints 38

Lags and Leads 42

Using Lags 43

Using Leads 45

Path Convergence 47

Best Practices Checklist: Sequencing All Activities 48

Best Practice 3 Assigning Resources to All Activities 50

Resources, Effort, and Duration 50

Rolling Wave Planning 52

Loading Activities with Resources 53

Resource Leveling 58

Best Practices Checklist: Assigning Resources to All Activities 63

Best Practice 4 Establishing the Duration of All Activities 65

Durations 65

Estimating Durations 66

Calendars 68

Contents 
Page ii GAO-12-120G Schedule Assessment 

Best Practices Checklist: Establishing the Duration of All Activities 71

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

Horizontal Traceability 72

Vertical Traceability 73

Best Practices Checklist: Verifying That the Schedule Can Be 

Traced Horizontally and Vertically 75

Best Practice 6 Confirming That the Critical Path Is Valid 76

The Critical Path 76

The Critical Path and the Longest Path 78

Common Barriers to a Valid Critical Path 81

Resource Leveling 89

Critical Path Management 90

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

Best Practice 7 Ensuring Reasonable Total Float 93

Definitions of Total Float and Free Float 93

Calculating Float 95

Common Barriers to Valid Float 96

Reasonableness of Float 97

Float Management 99

Best Practices Checklist: Ensuring Reasonable Total Float 100

Best Practice 8 Conducting a Schedule Risk Analysis 101

The Definition of Schedule Risk Analysis 101

The Purpose of a Schedule Risk Analysis 104

Schedule Risk Analysis with Three-Point Duration Estimates 106

Schedule Risk Analysis with Risk Drivers 109

Schedule Contingency 113

Prioritizing Risks 115

Probabilistic Branching 117

Correlation 119

Updating and Documenting a Schedule Risk Analysis 120

Best Practices Checklist: Conducting a Schedule Risk Analysis 121

Best Practice 9 Updating the Schedule Using Actual Progress and Logic 122

Statusing Progress 123

Progress Records 126
Page iii GAO-12-120G Schedule Assessment 

Adding Activities 127

Out-of-Sequence Logic 127

Verifying Status Updates and Schedule Integrity 131

Schedule Narrative 132

Reporting and Communication 133

Best Practices Checklist: Updating the Schedule Using Actual 

Progress and Logic 134

Best Practice 10 Maintaining a Baseline Schedule 136

Baseline and Current Schedules 136

Baseline Document 138

The Change Process 140

Baseline Analysis 142

Trend Analysis 148

Strategies for Recovery and Acceleration 149

Best Practices Checklist: Maintaining a Baseline Schedule 150

Four Characteristics of a Reliable Schedule 152 

Appendix I An Auditor’s Key Questions and Documents 154 

Appendix II The Forward and Backward Pass 172 

Appendix III Standard Quantitative Measurements for Assessing Schedule Health 184 

Appendix IV Recommended Elements of a Data Collection Instrument 190 

Appendix V Case Study Backgrounds 191 

Appendix VI Experts Who Helped Develop This Guide 199 
Page iv GAO-12-120G Schedule Assessment 

Appendix VII GAO Contacts and Staff Acknowledgments 207 

References 208

Tables 

Table 1. Strategies for Schedule Recovery and Acceleration 149

Table 2. The Four Characteristics of a Reliable Schedule 153

Table 3. Expected Durations and Estimated Resources 173

Table 4. Standard Data Measures for Schedule Best Practices 184

Table 5: Case Studies Drawn from GAO Reports Illustrating This 

Guide 191

Figures 

Figure 1: A Milestone’s Dates 12

Figure 2: Detail Activities 13

Figure 3: Summary Activities 14

Figure 4: The WBS and Scheduling 19

Figure 5: Redundant Activity Names 21

Figure 6: Unique Activity Names 22

Figure 7: Finish-to-Start Relationship 28

Figure 8: A Start-to-Start Relationship 28

Figure 9: A Finish-to-Finish Relationship 29

Figure 10: Early and Late Dates 31

Figure 11: Start-Date Dangling Logic 32

Figure 12: Finish-Date Dangling Logic 33

Figure 13: A Linked Summary Activity 35

Figure 14: A Lag 42

Figure 15: A Negative Lag (or Lead) 43

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

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

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

Figure 19: Logic Failure Associated with a Lead 46

Figure 20: Enumerating Lags 47

Figure 21: A Profile of Expected Construction Labor Costs by 

Month 56

Figure 22: A Smoothed Profile of Expected Construction Labor 

Costs by Month 57
Page v GAO-12-120G Schedule Assessment 

Figure 23: Resource Overallocation in a Correctly Sequenced 

Network 60

Figure 24: Resource Leveling in a Correctly Sequenced Network 61

Figure 25: The Critical Path and Total Float 76

Figure 26: The Critical Path and the Longest Path 79

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

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

Figure 29: The Critical Path and Lags 86

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

Figure 31: Total Float and Free Float 95

Figure 32: Network Diagram of a Simple Schedule 105

Figure 33: A Project Schedule 107

Figure 34: Estimated Durations for Remaining WBS Areas in the 

Schedule 108

Figure 35: The Cumulative Distribution of Project Schedule, 

Including Risk 109

Figure 36: Identified Risks on a Spacecraft Schedule 110

Figure 37: A Risk Register for a Spacecraft Schedule 111

Figure 38: Spacecraft Schedule Results from a Monte Carlo 

Simulation 111

Figure 39: A Schedule Showing a Critical Path 115

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

Showing a Critical Path 116

Figure 41: A Sensitivity Index for Spacecraft Schedule 117

Figure 42: Probabilistic Branching in a Schedule 118

Figure 43: Probability Distribution Results for Probabilistic 

Branching 118

Figure 44: The Original Plan for Interior Finishing 128

Figure 45: Retained Logic 129

Figure 46: Progress Override 130

Figure 47: Baseline, Actual, and Forecasted Dates 143

Figure 48: Baselined Activities 144

Figure 49: Updated Status Compared with Baseline 145

Figure 50: Updated Status and Proposed Plan Compared with 

Baseline 147

Figure 51: Start-Up and Testing Network 174

Figure 52: Early Start and Early Finish Calculations 176

Figure 53: Successive Early Start and Early Finish Calculations 177

Figure 54: Complete Early Start and Early Finish Calculations 178

Figure 55: Late Start and Late Finish Calculations 180

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

Figure 57: Total Float in a Start-Up and Testing Network 182
Page vi GAO-12-120G Schedule Assessment 

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 
Page vii GAO-12-120G Schedule Assessment 

TSA Transportation Security Administration 

TPO Transformation Program Office 

USCIS U.S. Citizenship and Immigration Services 

WBS work breakdown structure 

This is a work of the U.S. government and is not subject to copyright protection in the 

United States. The published product may be reproduced and distributed in its entirety 

without further permission from GAO. However, 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. 
Page 1 GAO-12-120G Schedule Assessment 

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 

Preface 
Preface 

Page 2 GAO-12-120G Schedule Assessment 

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 https://tell.gao.gov/schedulecommentguide 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 Office of 

Congressional Relations and Office of Public Affairs may be found on the 

last page of this guide. Major contributors to this project are listed on 

page 200. 

Timothy M. Persons, Ph.D. 

Director, Center for Science, Technology, and Engineering 

Applied Research and Methods 
Introduction and Concepts 

Page 3 GAO-12-120G Schedule Assessment 

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. 

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 

Introduction and Concepts 

Ten Best Practices 
Introduction and Concepts 

Page 4 GAO-12-120G Schedule Assessment 

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 
Introduction and Concepts 

Page 5 GAO-12-120G Schedule Assessment 

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 
Introduction and Concepts 

Page 6 GAO-12-120G Schedule Assessment 

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. 

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.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 

 

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 a program. 

The Integrated Master 

Schedule 
Introduction and Concepts 

Page 7 GAO-12-120G Schedule Assessment 

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 highlevel 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 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 

The Critical Path 

Method 
Introduction and Concepts 

Page 8 GAO-12-120G Schedule Assessment 

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. 

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. 

Planning, Scheduling, 

and the Scheduler 
Introduction and Concepts 

Page 9 GAO-12-120G Schedule Assessment 

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. 
Best Practice 1: Capturing All Activities 

Page 10 GAO-12-120G Schedule Assessment 

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. 

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 hamper project members’ 

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 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 

Best Practice 1: Capturing All Activities 

Capturing All Effort 

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.
Best Practice 1: Capturing All Activities 

Page 11 GAO-12-120G Schedule Assessment 

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.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, 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 

 

2

More information on formal risk assessment is available in Best Practice 8, as well as in 

GAO Cost Estimating and Assessment Guide, GAO-09-3SP. 
Best Practice 1: Capturing All Activities 

Page 12 GAO-12-120G Schedule Assessment 

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,

GAO-11-53 (Washington, D.C.: October 7, 2010). 

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 

Source: GAO. 

A best practice is to create the schedule from primarily detail activities 

and to include milestones only to reflect major events or deliverables.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 

 

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. 

Milestone, Detail, and 

Summary Activities 
Best Practice 1: Capturing All Activities 

Page 13 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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. 
Best Practice 1: Capturing All Activities 

Page 14 GAO-12-120G Schedule Assessment 

Figure 3: Summary Activities 

Source: GAO. 

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 

Level of Effort Activities 
Best Practice 1: Capturing All Activities 

Page 15 GAO-12-120G Schedule Assessment 

as “hammock” activities, and they are included in certain scheduling 

software packages. 

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 

Constructing an IMS 
Best Practice 1: Capturing All Activities 

Page 16 GAO-12-120G Schedule Assessment 

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. 
Best Practice 1: Capturing All Activities 

Page 17 GAO-12-120G Schedule Assessment 

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, 

GAO-09-518 (Washington, D.C.: September 25, 2009). 

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 

Work Breakdown 

Structure 
Best Practice 1: Capturing All Activities 

Page 18 GAO-12-120G Schedule Assessment 

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. 
Best Practice 1: Capturing All Activities 

Page 19 GAO-12-120G Schedule Assessment 

Figure 4: The WBS and Scheduling 

Source: Adapted from © 2010 Paul D. Giammalvo. 

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 
Best Practice 1: Capturing All Activities 

Page 20 GAO-12-120G Schedule Assessment 

planned, the schedule reflects the WBS and therefore defines the 

activities necessary to produce and deliver the lowest-level deliverable. 

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.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. 

 

4

See the GAO Cost Estimating and Assessment Guide (GAO-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. 
Best Practice 1: Capturing All Activities 

Page 21 GAO-12-120G Schedule Assessment 

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 with 

without including their respective summary activities and preceding 

activities in the filtered view. 

Figure 5: Redundant Activity Names 

Source: GAO. 

Activity Names 
Best Practice 1: Capturing All Activities 

Page 22 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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 levels. 
Best Practice 1: Capturing All Activities 

Page 23 GAO-12-120G Schedule Assessment 

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.5

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.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 placed 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 

 

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. 

Activity Codes 
Best Practice 1: Capturing All Activities 

Page 24 GAO-12-120G Schedule Assessment 

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,

GAO-10-189 (Washington, D.C.: December 14, 2009). 

 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. 

Best Practices 

Checklist: Capturing 

All Activities 
Best Practice 1: Capturing All Activities 

Page 25 GAO-12-120G Schedule Assessment 

 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. 
Best Practice 2: Sequencing All Activities 

Page 26 GAO-12-120G Schedule Assessment 

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 

predict 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 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. 

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 

Best Practice 2: Sequencing All Activities 

Predecessor and 

Successor Logic 

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.
Best Practice 2: Sequencing All Activities 

Page 27 GAO-12-120G Schedule Assessment 

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 indentify 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.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. 

 

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. 
Best Practice 2: Sequencing All Activities 

Page 28 GAO-12-120G Schedule Assessment 

Figure 7: Finish-to-Start Relationship 

Source: GAO. 

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 

Source: GAO. 

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. 
Best Practice 2: Sequencing All Activities 

Page 29 GAO-12-120G Schedule Assessment 

Figure 9: A Finish-to-Finish Relationship 

Source: GAO. 

The majority of relationships within a detailed schedule should be finishto-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 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. 
Best Practice 2: Sequencing All Activities 

Page 30 GAO-12-120G Schedule Assessment 

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.8

 The 

 

8

Unless otherwise stated in this guide, “start” and “finish” refer to an activity’s early start 

and early finish dates. 
Best Practice 2: Sequencing All Activities 

Page 31 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

Appendix II gives a detailed example of how to calculate early and late 

dates using the forward and backward passes. 

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. 

Incomplete and 

Dangling Logic 
Best Practice 2: Sequencing All Activities 

Page 32 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

“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 and shrubs and install final landscaping.” “Plant trees and 

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 and 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 
Best Practice 2: Sequencing All Activities 

Page 33 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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 
Best Practice 2: Sequencing All Activities 

Page 34 GAO-12-120G Schedule Assessment 

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 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.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. 

 

9

Vertical traceability is discussed in detail in Best Practice 5. 

Summary Logic 
Best Practice 2: Sequencing All Activities 

Page 35 GAO-12-120G Schedule Assessment 

Figure 13: A Linked Summary Activity 

Source: GAO. 

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 
Best Practice 2: Sequencing All Activities 

Page 36 GAO-12-120G Schedule Assessment 

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, 

GAO-11-53 (Washington, D.C.: October 7, 2010). 

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 

Date Constraints 
Best Practice 2: Sequencing All Activities 

Page 37 GAO-12-120G Schedule Assessment 

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.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. 

 

10Our 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. 
Best Practice 2: Sequencing All Activities 

Page 38 GAO-12-120G Schedule Assessment 

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. 

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 

Using Date 

Constraints 
Best Practice 2: Sequencing All Activities 

Page 39 GAO-12-120G Schedule Assessment 

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, resourceconstrained 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 lowlevel 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). 
Best Practice 2: Sequencing All Activities 

Page 40 GAO-12-120G Schedule Assessment 

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, 

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 
Best Practice 2: Sequencing All Activities 

Page 41 GAO-12-120G Schedule Assessment 

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. 
Best Practice 2: Sequencing All Activities 

Page 42 GAO-12-120G Schedule Assessment 

 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. 

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 

Source: GAO. 

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 1 day before the forming of the walls is finished. 

Lags and Leads 
Best Practice 2: Sequencing All Activities 

Page 43 GAO-12-120G Schedule Assessment 

Figure 15: A Negative Lag (or Lead) 

Source: GAO. 

Without the lead, installing 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. 

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 that 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 later than 

necessary (see figure 16). 

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

Source: GAO. 

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 

Using Lags 
Best Practice 2: Sequencing All Activities 

Page 44 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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. 
Best Practice 2: Sequencing All Activities 

Page 45 GAO-12-120G Schedule Assessment 

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. 

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 wallforming 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. 

Using Leads 
Best Practice 2: Sequencing All Activities 

Page 46 GAO-12-120G Schedule Assessment 

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

Source: GAO. 

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 

Source: GAO. 

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. 
Best Practice 2: Sequencing All Activities 

Page 47 GAO-12-120G Schedule Assessment 

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 

 Source: GAO. 

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 

Path Convergence 
Best Practice 2: Sequencing All Activities 

Page 48 GAO-12-120G Schedule Assessment 

many parallel activities into a single successor—also known as a “merge 

point”—causes problems in managing the schedule.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. 

 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-tostart. 

 

11Parallel 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. 

Best Practices 

Checklist: Sequencing 

All Activities 
Best Practice 2: Sequencing All Activities 

Page 49 GAO-12-120G Schedule Assessment 

 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, 

o Each activity (except the start milestone) has an F–S or S–S 

predecessor that drives its start date. 

o 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. 
Best Practice 3: Assigning Resources to All 

Activities 

Page 50 GAO-12-120G Schedule Assessment 

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. An analyst 

must examine resources by time period to determine whether they are 

adequate. 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. 

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. 

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 

Best Practice 3: Assigning Resources to All 

Activities 

Resources, Effort, and 

Duration 

Labor Resources 

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 

funding or time constraints. 
Best Practice 3: Assigning Resources to All 

Activities 

Page 51 GAO-12-120G Schedule Assessment 

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. 

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. 

Nonlabor Resources 
Best Practice 3: Assigning Resources to All 

Activities 

Page 52 GAO-12-120G Schedule Assessment 

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. 

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 nearterm, 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 

Rolling Wave Planning 
Best Practice 3: Assigning Resources to All 

Activities 

Page 53 GAO-12-120G Schedule Assessment 

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 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).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 

 

12For more information on the relationship between cost, schedule, and EVM, see GAO 

Cost Estimating and Assessment Guide, GAO-09-3SP, chs. 18 and 19. 

Loading Activities 

with Resources 
Best Practice 3: Assigning Resources to All 

Activities 

Page 54 GAO-12-120G Schedule Assessment 

include detail resource information, while summary schedules with higherlevel 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”) 
Best Practice 3: Assigning Resources to All 

Activities 

Page 55 GAO-12-120G Schedule Assessment 

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, 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 
Best Practice 3: Assigning Resources to All 

Activities 

Page 56 GAO-12-120G Schedule Assessment 

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 seen in 

the example of house construction in figure 21. 

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

Source: GAO. 

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 
Best Practice 3: Assigning Resources to All 

Activities 

Page 57 GAO-12-120G Schedule Assessment 

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 walkthrough, not 

scheduled until early July. Those activities have over 40 days of total float 

available; that is, 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 fig. 22). 

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

Source: GAO. 

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 
Best Practice 3: Assigning Resources to All 

Activities 

Page 58 GAO-12-120G Schedule Assessment 

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 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 trade-offs are made between resources and time and to 

ensure that the schedule remains credible throughout its lifespan. 

Resource Leveling 
Best Practice 3: Assigning Resources to All 

Activities 

Page 59 GAO-12-120G Schedule Assessment 

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.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. 

 

13Free float is the amount of time by which an activity can be delayed without affecting any 

successor (see Best Practice 7). 
Best Practice 3: Assigning Resources to All 

Activities 

Page 60 GAO-12-120G Schedule Assessment 

Figure 23: Resource Overallocation in a Correctly Sequenced Network 

Source: GAO. 

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. 
Best Practice 3: Assigning Resources to All 

Activities 

Page 61 GAO-12-120G Schedule Assessment 

Figure 24: Resource Leveling in a Correctly Sequenced Network 

Source: GAO. 

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 
Best Practice 3: Assigning Resources to All 

Activities 

Page 62 GAO-12-120G Schedule Assessment 

everyone understands them.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. 

 

14Logic 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. 
Best Practice 3: Assigning Resources to All 

Activities 

Page 63 GAO-12-120G Schedule Assessment 

 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. 

Best Practices 

Checklist: Assigning 

Resources to All 

Activities 
Best Practice 3: Assigning Resources to All 

Activities 

Page 64 GAO-12-120G Schedule Assessment 

 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. 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 65 GAO-12-120G Schedule Assessment 

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 

Best Practice 4: Establishing the Duration of 

All Activities 

Durations 

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.
Best Practice 4: Establishing the Duration of 

All Activities 

Page 66 GAO-12-120G Schedule Assessment 

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. 

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. 

Estimating Durations 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 67 GAO-12-120G Schedule Assessment 

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.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. 

 

15Usually 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. 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 68 GAO-12-120G Schedule Assessment 

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 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. 

Calendars 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 69 GAO-12-120G Schedule Assessment 

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 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 70 GAO-12-120G Schedule Assessment 

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,

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.16

 

16Schedule 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. 
Best Practice 4: Establishing the Duration of 

All Activities 

Page 71 GAO-12-120G Schedule Assessment 

 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. 

Best Practices 

Checklist: 

Establishing the 

Duration of All 

Activities 
Best Practice 5: Verifying That the Schedule 

Can Be Traced Horizontally and Vertically 

Page 72 GAO-12-120G Schedule Assessment 

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 

Best Practice 5: Verifying That the Schedule 

Can Be Traced Horizontally and Vertically 

Horizontal 

Traceability 

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. 
Best Practice 5: Verifying That the Schedule 

Can Be Traced Horizontally and Vertically 

Page 73 GAO-12-120G Schedule Assessment 

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 affect 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, GAO-11-740 (Washington, D.C.: July 11, 2011). 

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. 

Vertical Traceability 
Best Practice 5: Verifying That the Schedule 

Can Be Traced Horizontally and Vertically 

Page 74 GAO-12-120G Schedule Assessment 

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 highlevel 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,

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 
Best Practice 5: Verifying That the Schedule 

Can Be Traced Horizontally and Vertically 

Page 75 GAO-12-120G Schedule Assessment 

forecasted dates, predecessor logic, and critical path activities reported to 

management should be rooted in and traceable to the actual program 

IMS. 

 The schedule is horizontally traceable. That is, the schedule 

o depicts logical relationships between different program elements 

and product hand-offs and clearly shows when major deliverables 

and hand-offs are expected; 

o includes complete logic from program start to program finish and 

fully integrates the entire scope of work from all involved in the 

program; 

o includes milestones representing key decisions or deliverables 

with traced and validated predecessor activities to ensure that 

they are directly related to completing the milestone; 

o clearly identifies and logically links “giver/receiver” milestones 

between schedules that are defined in the schedule baseline 

document; 

o dynamically reforecasts the date of a key milestone through 

network logic if activities related to accomplishing the milestone 

are delayed; 

o is affected by activities whose durations are extended by 

hundreds of days; 

o includes giver/receiver milestones that are defined in the schedule 

baseline document 

 The schedule is vertically traceable. That is, it 

o demonstrates that data are consistent between summary, 

intermediate, and detailed levels of the schedule, including dates 

that are frequently validated through a documented process; 

o allows activity owners to trace activities to higher-level milestones 

with intermediate and summary schedules; 

o 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. 

Best Practices 

Checklist: Verifying 

That the Schedule 

Can Be Traced 

Horizontally and 

Vertically 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 76 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

With the inspection complete and the garage floor poured, the framing 

portion of construction is considered complete. However, because “roughin framing inspection” is 1 day shorter than “form and pour driveway” and 

Best Practice 6: Confirming That the Critical 

Path Is Valid 

The Critical Path 

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.
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 77 GAO-12-120G Schedule Assessment 

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 those activities that have 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 lessthan-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 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 78 GAO-12-120G Schedule Assessment 

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 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.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. 

 

17Negative float and its causes are discussed in detail in Best Practice 7. 

The Critical Path and 

the Longest Path 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 79 GAO-12-120G Schedule Assessment 

Figure 26: The Critical Path and the Longest Path 

Source: GAO. 

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. 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 80 GAO-12-120G Schedule Assessment 

Figure 27: Critical Path Activities Not on the Longest Path 

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 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 81 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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. 

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. 

Common Barriers to a 

Valid Critical Path 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 82 GAO-12-120G Schedule Assessment 

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. 

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. 

Continuous through All 

Activities 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 83 GAO-12-120G Schedule Assessment 

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 inprogress 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, 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 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 84 GAO-12-120G Schedule Assessment 

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. 

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. 

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). 

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. 

The Number of Critical 

Activities 

Logical Sequencing 

Date Constraints 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 85 GAO-12-120G Schedule Assessment 

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. 

Lags 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 86 GAO-12-120G Schedule Assessment 

Figure 29: The Critical Path and Lags 

Source: GAO. 

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 

Level of Effort and Other 

Long-Duration Activities 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 87 GAO-12-120G Schedule Assessment 

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 

Source: GAO. 

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, 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 88 GAO-12-120G Schedule Assessment 

there is no way to determine which subactivities are critical and which are 

not. 

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 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. 

Predetermined Critical 

Activities 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 89 GAO-12-120G Schedule Assessment 

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, GAO-12-66 (Washington, D.C.: November 22, 2011). 

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 

Resource Leveling 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 90 GAO-12-120G Schedule Assessment 

attempt to facilitate its 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. 

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 

Critical Path 

Management 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 91 GAO-12-120G Schedule Assessment 

activities alerts management of potential critical activities and facilitates 

proper resource allocation before activities become critical.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. 

 The schedule’s critical path is valid. That is, the critical path or longest 

path in the presence of late-date constraints 

o does not include LOE activities, summary activities, or other 

unusually long activities; 

o is a continuous path from the status date to the major completion 

milestones; 

o does not include constraints so that other activities are 

unimportant in driving the milestone date; 

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

o is derived in summary schedules by vertical integration of lowerlevel 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 

o has vetted and justified the current critical path as calculated by 

the software; 

o uses the critical path to focus on activities that will be detrimental 

to the key project milestones and deliveries if they slip; 

o examines and mitigates risk in activities on the critical path that 

can potentially delay key program deliveries and milestones; 

 

18Unfortunately, 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. 

Best Practices 

Checklist: Confirming 

That the Critical Path 

Is Valid 
Best Practice 6: Confirming That the Critical 

Path Is Valid 

Page 92 GAO-12-120G Schedule Assessment 

 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. 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 93 GAO-12-120G Schedule Assessment 

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. 

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.19 The two types of float most commonly monitored are total float 

and free float.20

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 

 

19Specifically, 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. 

20A 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. 

Best Practice 7: Ensuring Reasonable Total 

Float 

Definitions of Total 

Float and Free Float 

Total Float 

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. 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 94 GAO-12-120G Schedule Assessment 

delayed without delaying the program’s finish date.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 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 

 

21Typically, 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. 

Free Float 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 95 GAO-12-120G Schedule Assessment 

that sequence. As described in Best Practice 8, schedule contingency 

should be applied to specific activities according to prioritized risks. 

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 

Source: GAO. 

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 

Calculating Float 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 96 GAO-12-120G Schedule Assessment 

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. 

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. 

Common Barriers to 

Valid Float 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 97 GAO-12-120G Schedule Assessment 

GAO, FAA’s Acquisitions: Management Challenges Associated with 

Program Costs and Schedules Could Hinder NextGen, 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. 

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.22 Case study 13 shows 

unreasonable float in a schedule. 

 

22Total 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. 

Reasonableness of 

Float 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 98 GAO-12-120G Schedule Assessment 

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, 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. 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 99 GAO-12-120G Schedule Assessment 

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. 

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-forday schedule slip. Float on the critical path should be commensurate with 

Float Management 
Best Practice 7: Ensuring Reasonable Total 

Float 

Page 100 GAO-12-120G Schedule Assessment 

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. 

 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. 

Best Practices 

Checklist: Ensuring 

Reasonable Total 

Float 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 101 GAO-12-120G Schedule Assessment 

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. 

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.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;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; 

o the probability of a risk’s occurring; 

o the probability that a branch of activities might occur (for example, 

a test failure could lead to several recovery activities); and 

o correlations between uncertain activity durations, whether 

specified directly or calculated. 

 

23For more information on the difference between uncertainty and risk, see Chapter 14 in 

the GAO Cost Estimating and Assessment Guide, GAO-09-3SP. 

24A risk register formally documents a project’s identified risks, including likelihoods, 

consequences, mitigation plans, and current status. 

Best Practice 8: Conducting a Schedule Risk 

Analysis 

The Definition of 

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, 

the baseline schedule should include 

a buffer or reserve of extra time. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 102 GAO-12-120G Schedule Assessment 

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.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 

 

25For more information on formal risk assessments and their relation to cost, schedule, 

and EVM, see GAO-09-3SP. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 103 GAO-12-120G Schedule Assessment 

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,

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 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 104 GAO-12-120G Schedule Assessment 

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. 

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. 

The Purpose of a 

Schedule Risk 

Analysis 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 105 GAO-12-120G Schedule Assessment 

Figure 32: Network Diagram of a Simple Schedule 

Source: Copyright 2007 Hulett and Associates, LLC. 

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 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 106 GAO-12-120G Schedule Assessment 

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, GAO-11-743 (Washington, D.C.: July 28, 

2011). 

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. 

Schedule Risk 

Analysis with ThreePoint Duration 

Estimates 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 107 GAO-12-120G Schedule Assessment 

Figure 33: A Project Schedule 

Note: H/W = hardware; S/W = software. 

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 threepoint estimate applied directly to the activity durations. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 108 GAO-12-120G Schedule Assessment 

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

Note: Rept ID = report identification; Rdur = remaining duration, Mn = minimum, ML = most likely, 

Max = maximum; H/W = hardware; S/W = software. 

The example shows three-point estimates of remaining durations. In an 

actual program schedule risk analysis, these would be developed from indepth 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.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. 

 

26For more information on developing probability distributions to model uncertainty, see 

chapter 14 in the GAO Cost Estimating and Assessment Guide, GAO-09-3SP. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 109 GAO-12-120G Schedule Assessment 

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

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. 

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. 

Schedule Risk 

Analysis with Risk 

Drivers 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 110 GAO-12-120G Schedule Assessment 

Figure 36: Identified Risks on a Spacecraft Schedule 

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. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 111 GAO-12-120G Schedule Assessment 

Figure 37: A Risk Register for a Spacecraft Schedule 

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 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 112 GAO-12-120G Schedule Assessment 

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 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 113 GAO-12-120G Schedule Assessment 

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, 

GAO-10-189 (Washington, D.C.: December 14, 2009). 

A baseline schedule should include a buffer or a reserve of extra time, 

referred to as schedule contingency, to account risk27 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 

 

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. 

Schedule Contingency 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 114 GAO-12-120G Schedule Assessment 

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. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 115 GAO-12-120G Schedule Assessment 

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 

Note: Rept ID = report identification; Rdur = remaining duration, Mn = minimum, ML = most likely, 

Max = maximum; H/W = hardware; S/W = software. 

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. 

Prioritizing Risks 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 116 GAO-12-120G Schedule Assessment 

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

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. 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 117 GAO-12-120G Schedule Assessment 

Figure 41: A Sensitivity Index for Spacecraft Schedule 

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. 

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. 

Probabilistic 

Branching 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 118 GAO-12-120G Schedule Assessment 

Figure 42: Probabilistic Branching in a Schedule 

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 

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 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 119 GAO-12-120G Schedule Assessment 

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.28

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, 

 

28Probabilistic 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 

probability of occurrence. For example, if a design activity takes 2 weeks, then execute 

Plan A, otherwise (else) execute Plan B. 

Correlation 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 120 GAO-12-120G Schedule Assessment 

whereas it does not matter as much around the mean duration from the 

simulation. 

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.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, the activities that most often ended up on the 

critical path, and the derivation of contingency sufficient for risk mitigation 

should be documented. 

 

29If activities representing schedule contingency are not removed before conducting an 

update to the SRA, they will adversely affect the results. 

Updating and 

Documenting a 

Schedule Risk 

Analysis 
Best Practice 8: Conducting a Schedule Risk 

Analysis 

Page 121 GAO-12-120G Schedule Assessment 

 A schedule risk analysis was conducted to determine 

o the likelihood that the project completion date will occur, 

o how much schedule risk contingency is needed to provide an 

acceptable level of certainty for completion by a specific date, 

o risks most likely to delay the project, 

o how much contingency reserve each risk requires, and 

o the paths or activities that are most likely to delay the project. 

 The schedule was assessed against best practices before the 

simulation was conducted. The schedule network clearly identifies 

work to be done and the relationships between detailed activities and 

is based on a minimum number of justified date constraints. 

 The SRA has low, most likely, and high duration data fields. 

 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. 

Best Practices 

Checklist: Conducting 

a Schedule Risk 

Analysis 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 122 GAO-12-120G Schedule Assessment 

“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 that 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 

Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Best Practice 9: 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.
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 123 GAO-12-120G Schedule Assessment 

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 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,

GAO-11-53 (Washington, D.C.: October 7, 2010). 

Statusing Progress 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 124 GAO-12-120G Schedule Assessment 

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, 

Updating Duration of Work 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 125 GAO-12-120G Schedule Assessment 

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. 

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. 

Updating the Status of 

Remaining Work 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 126 GAO-12-120G Schedule Assessment 

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, GAO-11-740 (Washington, D.C.: July 11, 2011). 

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 

Progress Records 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 127 GAO-12-120G Schedule Assessment 

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. 

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. 

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. Outof-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. 

Adding Activities 

Out-of-Sequence 

Logic 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 128 GAO-12-120G Schedule Assessment 

When out-of-sequence progress occurs, managers and schedulers may 

choose to retain or override the existing network 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. 

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-ofsequence 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 shows 

the original plan for conducting the interior finishes of the house 

construction project. 

Figure 44: The Original Plan for Interior Finishing 

Source: GAO. 

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 

Retained Logic 

Progress Override 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 129 GAO-12-120G Schedule Assessment 

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 

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. 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 130 GAO-12-120G Schedule Assessment 

Figure 46: Progress Override 

Source: GAO. 

Note: NA = Not applicable. 

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-ofsequence 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-ofsequence activities may represent risk or potential rework, because 

knowledge or products from the predecessor activity were not complete 

and available to the successor activity. 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 131 GAO-12-120G Schedule Assessment 

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 

Verifying Status 

Updates and Schedule 

Integrity 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 132 GAO-12-120G Schedule Assessment 

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. 

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 

Schedule Narrative 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 133 GAO-12-120G Schedule Assessment 

may soon be critical, because float will not be available for successive 

activities on that path. 

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. 

Reporting and 

Communication 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 134 GAO-12-120G Schedule Assessment 

 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. 

o If the delay is significant, plans to recover the implied schedule 

slip have been evaluated and implemented, if so decided. 

o 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. 

Best Practices 

Checklist: Updating 

the Schedule Using 

Actual Progress and 

Logic 
Best Practice 9: Updating the Schedule Using 

Actual Progress and Logic 

Page 135 GAO-12-120G Schedule Assessment 

 The current schedule, once management approves it, is assigned a 

version number and archived. 

 A schedule narrative accompanies each status update and includes 

o the status of key milestone dates, including the program finish 

date; 

o the status of key hand-offs or giver/receiver dates; 

o explanations for any changes in key dates; 

o changes in network logic, including lags, date constraints, and 

relationship logic and their effect on the schedule; 

o a description of the critical paths, near-critical paths, and longest 

paths along with a comparison to the previous period’s paths; and 

o 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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 136 GAO-12-120G Schedule Assessment 

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. 

Best Practice 10: Maintaining a Baseline 

Schedule 

Baseline and Current 

Schedules 

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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 137 GAO-12-120G Schedule Assessment 

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.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 

 

30Establishing 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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 138 GAO-12-120G Schedule Assessment 

adherence to estimates of activity durations, resources assignments, or 

logic. 

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. 

Baseline Document 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 139 GAO-12-120G Schedule Assessment 

 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 latedate 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 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 140 GAO-12-120G Schedule Assessment 

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 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. 

The Change Process 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 141 GAO-12-120G Schedule Assessment 

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, 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 142 GAO-12-120G Schedule Assessment 

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, GAO-10-59 (Washington, D.C.: November 13, 

2009). 

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-ofsequence 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 nearcritical 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. 

Baseline Analysis 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 143 GAO-12-120G Schedule Assessment 

Figure 47: Baseline, Actual, and Forecasted Dates 

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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 144 GAO-12-120G Schedule Assessment 

Figure 48: Baselined Activities 

Source: GAO. 

Note: NA = Not applicable. 

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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 145 GAO-12-120G Schedule Assessment 

Figure 49: Updated Status Compared with Baseline 

Source: GAO. 

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 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 146 GAO-12-120G Schedule Assessment 

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 will 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 a 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. 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 147 GAO-12-120G Schedule Assessment 

Figure 50: Updated Status and Proposed Plan Compared with Baseline 

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; 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 148 GAO-12-120G Schedule Assessment 

 should not but have finished. 

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. 

Trend Analysis 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 149 GAO-12-120G Schedule Assessment 

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. 

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 Description Side effects 

Crashing Add resources to time-dependent activities to 

complete work faster 

Requires additional resources and will thus increase 

costs. May also reduce quality if activities are executed 

faster and with less experienced labor 

Fast tracking 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 

Resources may become overallocated. Quality may 

also be reduced and risk introduced if activities ideally 

executed in sequence are now executed in parallel 

Split long activities Long activities may be split into shorter activities 

that can be worked in parallel 

Resources may become overallocated 

Review constraint and 

lag assumptions 

Reassess assumptions related to forcing activities 

to begin on certain dates 

If the original date constraint or lag is justified, the 

removal of the constraint or lag may not be realistic 

Review duration 

estimates 

Duration estimates should be revisited using 

progress records as actual effort is recorded on the 

project 

Add overtime and 

reduce vacations 

Review nonworking periods and assign overtime 

work 

Costs will increase over standard labor rates. As 

overtime increases, morale will decrease, eventually 

affecting the quality of the product negatively 

Reduce scope Decreasing scope reduces both duration and costs Scope is the primary reason for performing the work. 

May not be able to delete some requirements 

Schedule contingencies Allocate contingency to absorb delay in accordance 

with identified risk mitigation plans 

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. 

Strategies for 

Recovery and 

Acceleration 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 150 GAO-12-120G Schedule Assessment 

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. 

 A baseline schedule 

o is set promptly after the program begins; 

o is the basis for measuring performance; 

o 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; 

o is compared to the current schedule to track variances from the 

plan. 

 There are plans to archive the as-built version of the schedule that 

o represent the plan as executed to completion; 

o can be compared to the original plan for an assessment of lessons 

learned; 

o become a valuable basis of estimate input for schedule estimates 

of future analogous projects; 

o become the basis for creating and validating fragnets where 

possible. 

 A baseline schedule document is a single document that 

o defines the organization of the IMS; 

o describes the logic of the network; 

o describes the basic approach to managing resources; 

o provides a basis for all parameters used to calculate dates; 

o describes the general approach to the project; 

o defines how to use the schedule file; 

o describes the schedule’s unique features; 

o describes the schedule change management process; 

o contains a dictionary of acronyms and custom fields; 

o gives an overview of the assumptions and ground rules, including 

justification for 

 calendars, 

 lags, 

 date constraints, 

 long activity durations, and 

 calendars and working times; 

Best Practices 

Checklist: Maintaining 

a Baseline Schedule 
Best Practice 10: Maintaining a Baseline 

Schedule 

Page 151 GAO-12-120G Schedule Assessment 

o describes the use and assignments of resources within the 

schedule at an appropriate level of detail; 

o describes the critical risks prioritized in a schedule risk analysis as 

well as schedule contingency; 

o discusses the derivation of the critical paths, longest path, and 

total float for the program; 

o 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. 
Four Characteristics of a Reliable Schedule 

Page 152 GAO-12-120G Schedule Assessment 

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 highpriority 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. 

Four Characteristics of a Reliable Schedule 
Four Characteristics of a Reliable Schedule 

Page 153 GAO-12-120G Schedule Assessment 

Table 2: The Four Characteristics of a Reliable Schedule 

Schedule characteristic Schedule best practice 

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 

1 Capturing all activities 

3 Assigning Resources to all activities 

4 Establishing the durations of all activities 

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 

2 Sequencing all activities 

6 Confirming that the critical path is valid 

7 Ensuring reasonable total float 

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 

5 Verifying that the schedule is traceable horizontally 

and vertically 

8 Conducting a schedule risk analysis 

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 

9 Updating the schedule with actual progress and 

logic 

10 Maintaining a baseline schedule 

Source: GAO. 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 154 GAO-12-120G Schedule Assessment 

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? 

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 

Appendix I: An Auditor’s Key Questions and 

Documents 

Best Practice 1: 

Capturing All 

Activities 

Key Questions 

Key Documentation 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 155 GAO-12-120G Schedule Assessment 

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 

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. 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 156 GAO-12-120G Schedule Assessment 

11. Repetitive naming of activities makes communication difficult between 

teams, particularly between team members who are responsible for 

updating and integrating multiple schedules. 

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 dateconstrained milestone? 

9. Are lags or leads specified between the activities? Can these be more 

accurately characterized by improving logic or adding activity detail? 

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 

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 

Best Practice 2: 

Sequencing All 

Activities 

Key Questions 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 157 GAO-12-120G Schedule Assessment 

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. 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 158 GAO-12-120G Schedule Assessment 

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. 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 159 GAO-12-120G Schedule Assessment 

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. 

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? 

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 

Best Practice 3: 

Assigning Resources 

to All Activities 

Key Questions 

Key Documentation 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 160 GAO-12-120G Schedule Assessment 

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. 

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. 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 161 GAO-12-120G Schedule Assessment 

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? 

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. 

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 

Best Practice 4: 

Establishing 

Durations for All 

Activities 

Key Questions 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 162 GAO-12-120G Schedule Assessment 

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. 

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 managementlevel briefing charts? 

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 

Best Practice 5: 

Verifying That the 

Schedule Is Traceable 

Horizontally and 

Vertically 

Key Questions 

Key Documentation 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 163 GAO-12-120G Schedule Assessment 

platforms (scheduling or presentation packages) for different 

audiences. 

2. The integration between summary, intermediate, and detailed 

schedules is demonstrated. 

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 handoffs. 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. 

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? 

Likely Effects If Criteria 

Are Not Fully Met 

Best Practice 6: 

Confirming That the 

Critical Path Is Valid 

Key Questions 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 164 GAO-12-120G Schedule Assessment 

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? 

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. 

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, 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 165 GAO-12-120G Schedule Assessment 

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. 

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? 

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. 

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 

Best Practice 7: 

Ensuring Reasonable 

Total Float 

Key Questions 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 166 GAO-12-120G Schedule Assessment 

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. 

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? 

Best Practice 8: 

Conducting a 

Schedule Risk 

Analysis 

Key Questions 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 167 GAO-12-120G Schedule Assessment 

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? 

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. 

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. 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 168 GAO-12-120G Schedule Assessment 

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? 

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. 

Best Practice 9: 

Updating the 

Schedule Using Logic 

and Progress 

Key Questions 

Key Documentation 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 169 GAO-12-120G Schedule Assessment 

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 analyses 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. 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 170 GAO-12-120G Schedule Assessment 

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? 

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. 

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 

Best Practice 10: 

Maintaining a 

Baseline Schedule 

Key Questions 

Key Documentation 

Likely Effects If Criteria 

Are Not Fully Met 
Appendix I: An Auditor’s Key Questions and 

Documents 

Page 171 GAO-12-120G Schedule Assessment 

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. 
Appendix II: The Forward and Backward Pass 

Page 172 GAO-12-120G Schedule Assessment 

Early and late activity 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 electricity, 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 

electricity 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. 

Appendix II: The Forward and Backward 

Pass 
Appendix II: The Forward and Backward Pass 

Page 173 GAO-12-120G Schedule Assessment 

Table 3: Expected Durations and Estimated Resources 

Activity Resource name 

Resource 

units 

Work 

hours

Duration 

in days

Set electricity meter Electrician 2 16 1

 Electrical service 

technician 

1 8

Start up and test 

electrical system 

Electrician 1 16 2

Set gas meter Gas service technician 2 16 1

Start up and test furnace 

and air conditioner 

HVAC technician 1 8 1

Set water meter Water service 

technician 

2 16 1

Start up and test 

plumbing fixtures 

Plumber 2 32 2

Source: GAO. 

Assuming the CO is attained on Monday, June 24, the electricity, gas, 

and water meters can be set the next day. Then, assuming that all 

succeeding activities are related by finish-to-start relationships, the startup and testing network will appear as in figure 51. 
Appendix II: The Forward and Backward Pass 

Page 174 GAO-12-120G Schedule Assessment 

Figure 51: Start-Up and Testing Network 

Source: GAO. 

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 electricity 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 a CO is issued at the end of the business day on Monday, June 24, 

then the work associated with setting the electricity, 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 
Appendix II: The Forward and Backward Pass 

Page 175 GAO-12-120G Schedule Assessment 

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. 
Appendix II: The Forward and Backward Pass 

Page 176 GAO-12-120G Schedule Assessment 

Figure 52: Early Start and Early Finish Calculations 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

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 
Appendix II: The Forward and Backward Pass 

Page 177 GAO-12-120G Schedule Assessment 

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 electricity 

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 

Source: GAO. 

Note: CO = Certificate of Occupancy. 
Appendix II: The Forward and Backward Pass 

Page 178 GAO-12-120G Schedule Assessment 

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 electricity 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 begin 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 

Source: GAO. 

Note: CO = Certificate of Occupancy. 
Appendix II: The Forward and Backward Pass 

Page 179 GAO-12-120G Schedule Assessment 

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 three 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 when an activity may start or finish. We are also interested 

in the latest dates when 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. 
Appendix II: The Forward and Backward Pass 

Page 180 GAO-12-120G Schedule Assessment 

Figure 55: Late Start and Late Finish Calculations 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

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 
Appendix II: The Forward and Backward Pass 

Page 181 GAO-12-120G Schedule Assessment 

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 electricity 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 a Start-Up and Testing Network 

Source: GAO. 

Note: CO = Certificate of Occupancy. 
Appendix II: The Forward and Backward Pass 

Page 182 GAO-12-120G Schedule Assessment 

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 a Start-Up and Testing Network 

Source: GAO. 

Note: CO = Certificate of Occupancy. 

Total Float 
Appendix II: The Forward and Backward Pass 

Page 183 GAO-12-120G Schedule Assessment 

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 electricity 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 electricity 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 electricity meter,” would also gain a day of total float. 
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 184 GAO-12-120G Schedule Assessment 

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 Measure Notes 

1. Capturing all 

activities 

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 

Total number of activities, including total summary, 

hammock, milestone, and detail activities 

Summary activities may or may not be present in the 

scheduling software 

Total number of remaining activities, including total 

summary, hammock, milestone, and detail activities

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 

If applicable, number of activities marked as both a 

milestone and summary activity 

An activity cannot be both a summary and a milestone 

Number of activities with no descriptive name May or may not be valid activities 

Ratio of detail activities to milestones 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 

Number of activities not mapped to program or 

contractor work breakdown structure 

Number of activities not mapped to a SOW or SOO 

paragraph or similar information 

Depending on the nature of the effort, an activity may not be 

mapped to the statement of work 

Number of activities with duplicate names Activity names should be unique and descriptive 

Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 185 GAO-12-120G Schedule Assessment 

Best practice Measure Notes 

2. Sequencing all 

activities 

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 

Number of remaining detail activities and 

milestones missing predecessor links 

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 

Number of remaining detail activities and 

milestones missing successor links 

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 

Number of remaining detail activities and 

milestones missing both predecessor and 

successor links 

Dangling activities: number of remaining detail 

activities and milestones with no predecessor on 

start date 

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 

Dangling activities: number of remaining detail 

activities and milestones with no successor or finish 

date 

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 

Number of remaining detail activities and 

milestones with start-to-finish links 

Count either successor or predecessor links but do not 

count both. An S–F link is between two activities but 

represents only one link 

Number of remaining summary activities with logic 

links 

May also be measured as “logic links to and from remaining 

summary activities,” although this will be a different number 

Remaining detail activities and milestones with a 

great many predecessors 

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 

predecessors that have 0 or low float have the ability to 

delay the successor when they are delayed 

Remaining detail activities and milestones with soft 

date constraints 

Remaining detail activities and milestones with hard 

date constraints 
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 186 GAO-12-120G Schedule Assessment 

Best practice Measure Notes 

Remaining detail activities and milestones with 

active SNET date constraints 

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 

Remaining detail activities and milestones with 

active FNET date constraints 

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 

Remaining detail activities and milestones with lags Count either successor or predecessor lags but not both. A 

lag is between two activities but represents only one lag. 

This is a different number from the number of lags 

Number of lags on remaining detail activities and 

milestones 

Count either successor or predecessor lags but not both. A 

lag is between two activities but represents only one lag. 

This is a different number from the number of activities with 

lags 

Remaining detail activities and milestones with 

leads 

Count either successor or predecessor leads but not both. A 

lead is between two activities but represents only one lead. 

This is a different number from the number of leads 

Number of leads on remaining detail activities and 

milestones 

Count either successor or predecessor leads but not both. A 

lead is between two activities but represents only one lead. 

This is a different number from the number of activities with 

leads 

Remaining detail activities and milestones with an 

F–S predecessor lead greater than remaining 

duration 

3. Assigning 

resources to all 

activities 

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 

Total number of resources 

 Overallocated resources 

Maximum units available per resource 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. 

Remaining detail activities with assignments Exclude nonapplicable activities such as planning 

packages, LOE activities, and reference activities Remaining detail activities without assignments 

4. Establishing 

the durations of 

all activities 

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 

Remaining detail activities with dissimilar time units All durations should be in the same unit, preferably days 
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 187 GAO-12-120G Schedule Assessment 

Best practice Measure Notes 

Remaining detail activities with durations less than 

44 days 

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 

Remaining detail activities with durations greater 

than 44 days 

Average duration of remaining detail activities 

Median duration of remaining detail activities 

Holidays and other exceptions by task calendar 

Remaining detail activities or milestones starting or 

finishing on a weekend or holiday 

May be legitimate but stem from incorrect calendar 

assignments or specifications. Milestones on weekends or 

holidays are particularly suspicious 

5. Verifying that 

the schedule can 

be traced 

horizontally and 

vertically 

Best Practice 5 has no standard measurements. Vertical traceability is assessed by determining whether lowerlevel 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 

Assessment of how critical and noncritical planned 

dates dynamically react to dramatic increases in 

predecessor activity durations 

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 

6. Confirming that 

the critical path is 

valid 

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 

Assessment of the driving paths to key milestones 

and comparison of those paths to activities marked 

as critical in the schedule 

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 

7. Ensuring 

reasonable total 

float 

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 

Remaining detail activities and milestones with 

dissimilar total float time units 

All float should be in the same units, preferably days 

Remaining detail activities and milestones with 

relatively high total float 

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 
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 188 GAO-12-120G Schedule Assessment 

Best practice Measure Notes 

Remaining detail activities with negative total float 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 

Average total float value of remaining detail 

activities and milestones 

Median total float value of remaining detail activities 

and milestones 

8. Conducting a 

schedule risk 

analysis 

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 

Fields within the schedule used for SRA Fields that store low, most likely, and high durations 

Correlation measures within the schedule 

 Contingency activities 

9. Updating the 

schedule using 

actual progress 

and logic 

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 

Number of in-progress activities 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 

Number of remaining detail activities and 

milestones that have a start date in the past but no 

actual start date 

Planned start dates should not occur in the past. “Past” is 

defined by the status date 

Number of remaining detail activities and 

milestones that have a finish date in the past but no 

actual finish date 

Planned finish dates should not occur in the past. “Past” is 

defined by the status date 

Number of remaining detail activities and 

milestones that have an actual start date in the 

future 

Actual start dates should not occur in the future. “Future” is 

defined by the status date 

Number of remaining detail activities and 

milestones that have an actual finish date in the 

future 

Actual finish dates should not occur in the future. “Future” is 

defined by the status date 

Number of detail activities performed out of 

sequence 

10. Maintaining a 

baseline schedule 

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 
Appendix III: Standard Quantitative 

Measurements for Assessing Schedule Health 

Page 189 GAO-12-120G Schedule Assessment 

Best practice Measure Notes 

Number of remaining detail activities and 

milestones that are forecasted to start or finish 

before their baseline dates 

Represents activities and milestones forecasted to begin or 

end early 

Number of remaining detail activities and 

milestones that are forecasted to start or finish on 

their baseline dates 

Represents activities and milestones forecasted to begin or 

end on time 

Number of remaining detail activities and 

milestones that are forecasted to start or finish after 

their baseline dates 

Represents activities and milestones forecasted to begin or 

end late 

Number of remaining detail activities that actually 

started before their baseline start date 

Represents activities and milestones that actually started 

early 

Number of remaining detail activities that actually 

started on their baseline start date 

Represents activities and milestones that actually started on 

time 

Number of remaining detail activities that actually 

started after their baseline start date 

Represents activities and milestones that actually started 

late 

Number of remaining detail activities and 

milestones that actually finished before their 

baseline finish date 

Represents activities and milestones that actually finished 

early 

Number of remaining detail activities and 

milestones that actually finished on their baseline 

finish date 

Represents activities and milestones that actually finished 

on time 

Number of remaining detail activities and 

milestones that actually finished after their baseline 

finish date 

Represents activities and milestones that have actually 

finished late 

Average and median start variance Start variance may be the difference between actual start 

and baseline start or forecasted start and baseline start 

Average and median finish variance Finish variance may be the difference between actual finish 

and baseline finish or forecasted finish and baseline finish 

Baseline execution index 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. 
Appendix IV: Recommended Elements of a 

Data Collection Instrument 

Page 190 GAO-12-120G Schedule Assessment 

 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. 

Appendix IV: Recommended Elements of a 

Data Collection Instrument 
Appendix V: Case Study Backgrounds 

Page 191 GAO-12-120G Schedule Assessment 

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 GAO report Best practices cited

2 GAO-09-518: Military Readiness 1

19 GAO-10-59: 2010 Census 10

7, 14 GAO-10-43: Transportation Worker 

Identification Credential 

4, 8

3, 16 GAO-10-189: VA Construction 1, 8

6 GAO-10-378: Nuclear Nonproliferation 3

13 GAO-10-816: Nuclear Waste 7

1, 4, 5, 17 GAO-11-53: DOD Business Transformation 1, 2, 9

8, 18 GAO-11-740: Aviation Security 5, 9

15 GAO-11-743: Coast Guard 8

9, 11 GAO-12-66: Immigration Benefits 5, 6

10, 12 GAO-12-223: FAA Acquisitions 6, 7

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. 

Appendix V: Case Study Backgrounds 

Case Studies 1, 4, 5, 

and 17: From DOD 

Business 

Transformation,

GAO-11-53, October 7, 

2010 
Appendix V: Case Study Backgrounds 

Page 192 GAO-12-120G Schedule Assessment 

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 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. 

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 

Case Study 2: From 

Military Readiness,

GAO-09-518, 

September 25, 2009 

Case Studies 3 and 16: 

From VA 

Construction,

GAO-10-189, 

December 14, 2009 
Appendix V: Case Study Backgrounds 

Page 193 GAO-12-120G Schedule Assessment 

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 

subjected to cost increases of between 1 and 100 percent and 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. 

The end of the Cold War left the United States with a surplus of weaponsgrade 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. 

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 

Case Study 6: From 

Nuclear 

Proliferation,

GAO-10-378, March 

26, 2010 

Case Studies 7 and 14: 

From Transportation 

Worker Identification 

Credential,

GAO-10-43, December 

10, 2009 
Appendix V: Case Study Backgrounds 

Page 194 GAO-12-120G Schedule Assessment 

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. 

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 

Case Studies 8 and 18: 

From Aviation 

Security, GAO-11-740, 

July 12, 2011 
Appendix V: Case Study Backgrounds 

Page 195 GAO-12-120G Schedule Assessment 

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. 

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 

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 9 and 11: 

From Immigration 

Benefits, GAO-12-66, 

November 22, 2011 
Appendix V: Case Study Backgrounds 

Page 196 GAO-12-120G Schedule Assessment 

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 selected 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 Studies 10 and 

12: From FAA 

Acquisitions,

GAO-12-223, February 

16, 2012 
Appendix V: Case Study Backgrounds 

Page 197 GAO-12-120G Schedule Assessment 

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. 

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 13: From 

Nuclear Waste,

GAO-10-816, 

September 14, 2010 

Case Study 15: From 

Coast Guard,

GAO-11-743, July 28, 

2011 
Appendix V: Case Study Backgrounds 

Page 198 GAO-12-120G Schedule Assessment 

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. 

Case Study 19: From 

2010 Census,

GAO-10-59, November 

13, 2009 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 199 GAO-12-120G Schedule Assessment 

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. 

Organization Expert 

ABBA Consulting Wayne Abba 

Acumen Brad Arterbury 

AECOM & PMI Scheduling President Pradip Mehta 

Air Force 

 

 

 

Jennifer Bowles 

John Cargill 

Fred Meyer 

Donna Rosenbaum 

Arcadis John Livengood 

ARES Software Eden Gold 

Bechtel Jacobs Darryl Walker 

Belstar, Inc (former AACE President) Osmund Belcher 

Booz Allen Hamilton 

 

 

Javed Hasnat 

Greg Hogan 

Seth Huckabee 

Chartered Institute of Building Saleem Sakram 

Construction Consulting Services, LLC Stephen Lee 

CPIC Solutions Corp William Mathis 

David Consulting Group Michael Harris 

DEAMS Harold Parker 

Defense Acquisition University Robert Pratt 

Defense Contract Management Agency 

 

Erik Berg 

Donna Holden 

Delta Group Joseph Perron 

Department of Energy 

 

Brian Kong 

Reuben Sanchez 

Department of Homeland Security 

 

 

Christine Ketcham 

Lawrence Mugg 

Robert Uzel 

Department of Justice 

 

Lionel Cares 

Teresa Palmer 

Department of the Treasury Kimberly Smith 

Appendix VI: Experts Who Helped Develop 

This Guide 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 200 GAO-12-120G Schedule Assessment 

Organization Expert 

ESPM Inc Joe Halligan 

EVMWIG 

 

 

 

 

 

 

Jimmy Black 

Camilla Canty 

Jon Fleming 

Kristen Kehrer 

Jerald Kerby 

Lin Kroeger 

Debbie Schumann 

Federal Acquisition Certification Academy Ben Sellers 

Federal Aviation Administration Fred Sapp 

General Services Administration Bill Hunt 

HNTB Corporation Mike Debiak 

Hulett & Associates, LLC David Hulett 

ICS-Global Murray Wolf 

Independent Consultant 

 

Anthony Corridore 

Joyce Glenn 

INDUS Corporation Jay Goldberg 

KM Systems Group Joe Houser 

 Kimberly Hunter 

L-3 Stratis Eric Christoph 

Legis Consultancy Patrick Ray 

Lockheed Martin Scott Gring 

Longview-FedConsulting JV 

 

Charles Cobb 

Sandra Marin 

Ludwig Consulting Services, LLC Joyce Ludwig 

Management Concepts John Driessnack 

Management Technologies Raymond Stratton 

MBP 

 

Jill Hubbard 

Niyi Ladipo 

MCR Federal LLC 

 

 

 

Neil Albert 

Susan Barton 

Raymond Covert 

Brian Evans 

Missile Defense Agency 

 

David Anderson 

Ken Twining 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 201 GAO-12-120G Schedule Assessment 

Organization Expert 

MITRE Stephen Bonk 

Clarke Thomason 

Nathan Welch 

NASA 

 

 

 

Tom Coonce 

Zachory Dolch 

Carol Grunsfeld 

Ken Poole 

National Science Foundation Patrick Haggerty 

NAVAIR John Scaparro 

Naval Center (NCAA) Duncan Thomas 

Northrop Grumman 

 

 

Raymond Bollas 

Anthony Claridge 

Gay Infanti 

Oracle 

 

Chris Sala 

Kristy Tan 

Parsons Brinckerhoff Marie Gunnerson 

Price Waterhouse Coopers Jennifer Mun 

ProChain Solutions, Inc. Rob Newbold 

Project & Cost Management Consulting Services Christopher Gruber 

Project Management Consultant Shashi Khanna 

Project Time & Cost 

 

Michael Nosbisch 

Chris Watson 

PT Mitratata Citragraha Paul Giammalvo 

R. J. Kohl & Assoc. Ronald Kohl 

Raytheon 

 

 

Joshua Anderson 

Warren Kline 

Joseph Kusick 

ServQ Andrew Crossley 

SRA Shobha Mahabir 

Technomics Scott DeNegre 

Tecolote Research, Inc. 

 

 

 

 

 

 

Mike Dalessandro 

Darren Elliott 

Anthony Harvey 

Greg Higdon 

James Johnson 

Linda Milam 

Alf Smith 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 202 GAO-12-120G Schedule Assessment 

Organization Expert 

The Earned Value Group Glenn Counts 

Valued Technology Keith Corner 

VARiQ Christopher Ditta 

Walter Majerowicz Consulting 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 Expert 

Accenture 

 

 

 

 

Tom Maraglino 

Nick Mark 

Mark Nickolas 

Patrick South 

Phil Wood 

Acumen 

 

Jackie O’Connor 

Dan Patterson 

Air Force 

 

 

Shannon House 

Dolores LaGuarde 

Dennis Rackard 

Army 

 

Jay Billings 

Sean Vessey 

AzTech International, LLC 

 

 

 

 

 

 

Luis Contreras 

Timothy Fritz 

James Ivie 

Zachary Lindemann 

Dave Rutter 

Blaine Schwartz 

Joy Sichveland 

Barrios Technology Patrick McGarrity 

Battelle 

 

Bill Altman 

Chuck Chapin 

BIA Vivian Deliz 

Boeing 

 

Kirk Kotthoff 

Barbara Park 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 203 GAO-12-120G Schedule Assessment 

Organization Expert 

Booz Allen Hamilton 

 

 

Tim Boatwright 

Tiffenie Shircliffe 

Calvin Speight 

Centers for Disease Control and Prevention Kimberly Crenshaw 

Chevo Consulting 

 

Cyndy Iwan 

Michelle Powell 

Cobec Consulting Inc. Dan French 

Commerce Trade Administration Peggy White-Fouts 

Consultant – Boeing, Retired John Pakiz 

D&G Chris Alberts 

David Consulting Group David Herron 

Defense Acquisition University Mark Husband 

Defense Contract Management Agency Marvin Charles 

Deloitte Consulting LLP Robyn Wiley 

Delta Group Christopher Melling 

Department of Education Tauqir Jilani 

Department of Energy 

 

 

 

 

 

 

Fredericka Baker 

Richard Couture 

Ronald Lile 

Robert McCoy 

Victoria Pratt 

Autar Rampertaap 

Karen Urschel 

Department of Homeland Security 

 

 

 

 

 

 

 

 

Jose Christian 

Michael Divecchio 

Katie Geier 

James Mararac 

Steve Nakazawa 

Lauren Riner 

William R. Taylor 

Mark Terry 

Michael Zaboski 

Department of Justice 

 

 

 

Anthony Burley 

Bellorh Byrom 

Tapan Das 

Bryce Mitchell 

Department of Transportation Traci Stith 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 204 GAO-12-120G Schedule Assessment 

Organization Expert 

Federal Aviation Administration 

 

Sharon Boddie 

William Russell 

Galorath Incorporated 

 

Daniel Galorath 

Bob Hunt 

General Services Administration 

 

 

 

Arnold Hill 

Patrick Plunket 

Gene Ransom 

John Ray 

George Washington University Homayoun Khamooshi 

Health and Human Services 

 

Gerald Brozyna 

Rita Warren 

Huntington Ingalls Inc. 

 

 

Doug Baggett 

Dan Burke 

Bruce Lemmert 

Idaho National Laboratory (INL) Rick Staten 

Independent Consultant 

 

Sheila DeBardi 

Gerard Jones 

Internal Revenue Service Donald Moushegian 

ITG Judy Rexin 

ITT Exelis 

 

Brenda Malmberg 

Bill Mendolsohn 

KP-IT SCAL Kathy Cook 

KPMG Mark Hogenmiller 

Legis Consultancy, Inc. Dave Smart 

Lockheed Martin 

 

Marcy Barlett 

James Fieber 

Management & Aviation Sven Antvik 

MCR 

 

Andrew Lovorn 

David Treacy 

MDS Mark Ives 

MITRE 

 

 

 

 

 

 

Raj Agrawal 

Charlie Dobbs 

Eric Fisher 

Daniel Harper 

Ron Hess 

Richard Riether 

Victoria Smith 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 205 GAO-12-120G Schedule Assessment 

Organization Expert 

Monte Ingram & Associates, LLC Monte Ingram 

NASA 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Heidemarie Borchardt 

Barbara Carroon 

Claude Freaner 

David Hall 

Jerry Holsomback 

Zach Hunt 

James Johnson 

Fred Kuo 

Patrick Maggarity 

Nakia Marks 

Arlene Moore 

Johnnetta Punch 

Yvonne Simonsen 

Mike Soots 

Steve Sterk 

Steve Wilson 

National Oceanic and Atmospheric 

Administration/Weather Service 

Alpha Bailey 

National Science Foundation Jack Matthewman 

Naval Air Systems Command Jeffrey Upton 

Naval Center (NCAA) Tim Lawless 

Naval Sea Systems Command Hershel Young 

Navy Postgraduate School  Boeing 

 

Daniel Dassow 

Maria Sims 

Northrop Grumman 

 

 

Jim Chappell 

Josh Dornan 

Stanton Smith 

Oak Ridge National Laboratory Bill Toth 

Office of Management and Budget Jim Wade 

Office of the Secretary of Defense Joseph Beauregard 

PARCA David Nelson 

Pentagon Robert Loop 

Performance Results Corporation Greg Dowd 

Pratt & Whitney Rocketdyne 

 

Gregory Manley 

Fernando Vivero 

PRICE Systems LLC Zach Jasnoff 
Appendix VI: Experts Who Helped Develop 

This Guide 

Page 206 GAO-12-120G Schedule Assessment 

Organization Expert 

Principle of Davis Langdon Peter Morris 

Project & Program Management Solutions Matthew Morris 

QS Requin Corp Alexia Nalewaik 

Raytheon Jeff Poulson 

Robbins Gioia Boris Blechman 

Ron Winter Consulting Ron Winter 

SAIC 

 

Ralph Justus 

Laura Mraz 

SETA Contractor John Roland 

SM&A Mark Infanti 

Systems Made Simple Ron Lattomus 

Technomics 

 

 

 

Peter Braxton 

Colleen Craig 

Richard Lee 

Brian Octeau 

Tecolote Research, Inc. 

 

 

Darren Elliott 

Michael Harrison 

Bill Rote 

The Rehancement Group, Inc. Peter Chrzanowski 

Trade Peggy Fouts 

United States Capitol Police Ken Sragg 
Appendix VII: GAO Contacts and Staff 

Acknowledgments 

Page 207 GAO-12-120G Schedule Assessment 

Timothy M. Persons, Ph.D., Chief Scientist, at (202) 512-6412 or 

personst@gao.gov

Karen Richey, Assistant Director, Applied Research and Methods (ARM), 

and 

Jason T. Lee, Analyst-in-Charge and Senior Cost Analyst, also in ARM 

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 

Appendix VII: GAO Contacts and Staff 

Acknowledgments 

GAO Contact 

Other Leadership 

Provided for This 

Project 

Key Contributors 
References 

Page 208 GAO-12-120G Schedule Assessment 

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. 

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. 

Defense Acquisition University. ACC Practice Center—Risk Management.

Fort Belvoir, Va.: Dec. 2011. 

Defense Contract Management Agency. Integrated Master 

Plan/Integrated Master Schedule Basic Analysis. Washington, D.C.: Nov. 

21, 2009. 

Defense Systems Management College. Schedule Guide for Program 

Managers. Fort Belvoir, Va.: Oct. 2001. 

References 
References 

Page 209 GAO-12-120G Schedule Assessment 

DOD (Department of Defense). Department of Defense Standard 

Practice: Work Breakdown Structures for Defense Materiel Items, MILSTD-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-MGMT81650. Washington, D.C.: Mar. 30, 2005. 

Douglas, Edward E. III. Documenting the Schedule Basis, AACE 

International Recommended Practice 38R-06. Morgantown, West Va.: 

2009. 

Federal Aviation Administration. 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, 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, 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, GAO-11-740. Washington, D.C.: July 11, 2011. 

GAO. Coast Guard: Action Needed as Approved Deepwater Program 

Remains Unachievable, GAO-11-743. Washington, D.C.: July 28, 2011. 

GAO. Cost Estimating and Assessment Guide, GAO-09-3SP. 

Washington, D.C.: Mar. 2009. 

GAO. DOD Business Transformation: Improved Management Oversight 

of Business System Modernization Efforts Needed, 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,

GAO-12-66. Washington, D.C.: Nov 22, 2011. 
References 

Page 210 GAO-12-120G Schedule Assessment 

GAO. Military Readiness: DOD Needs to Strengthen Management and 

Oversight of the Defense Readiness Reporting System, 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, 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, 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, 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, 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 Project Scheduling and Risk Analysis. Los 

Angeles, Calif.: Hulett and Associates, 2009. 

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. 

International Institute for Learning, Inc. Project Orange Belt® 2007. New 

York: 2007. 

National Aeronautics and Space Administration. Scheduling Management 

Handbook, SP-2010-3403. Washington, D.C.: Jan. 2010. 

National Defense Industrial Association. Planning and Scheduling 

Excellence Guide, v1.1b. Arlington, Va.: Apr. 6, 2011. 
References 

Page 211 GAO-12-120G Schedule Assessment 

NAVAIR (Naval Air Systems Command). EVM Analysis Toolkit.

Washington, D.C.: Apr. 14, 2009. 

NAVAIR. Integrated Master Schedule Guidebook. Washington, D.C.: Feb. 

2010. 

O’Brien, James J., and Fredric L. Plotnick. CPM in Construction 

Management, 6th ed. New York: McGraw-Hill, 2005. 

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. 

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 

(Design/Build), 01 32 16.17. 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 (Small 

Projects – Design/Bid/Build), 01 32 16.15. Washington, D.C.: n.d. 

 (460618) 
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. 

The fastest and easiest way to obtain copies of GAO documents at no 

cost is through GAO’s website (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 www.gao.gov and select “E-mail Updates.” 

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, 

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 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 www.gao.gov. 

Contact: 

Website: www.gao.gov/fraudnet/fraudnet.htm 

E-mail: fraudnet@gao.gov

Automated answering system: (800) 424-5454 or (202) 512-7470 

Katherine Siggerud, Managing Director, siggerudk@gao.gov, (202) 512-

4400, U.S. Government Accountability Office, 441 G Street NW, Room 

7125, Washington, DC 20548 

Chuck Young, Managing Director, youngc1@gao.gov, (202) 512-4800 

U.S. Government Accountability Office, 441 G Street NW, Room 7149 

Washington, DC 20548 

GAO’s Mission 

Obtaining Copies of 

GAO Reports and 

Testimony 

Order by Phone 

Connect with GAO 

To Report Fraud, 

Waste, and Abuse in 

Federal Programs 

Congressional 

Relations 

Public Affairs 

Please Print on Recycled Paper.