SCHEDULING

GUIDE

FOR

PROGRAM

MANAGERS

October 2001

PUBLISHED BY THE

DEFENSE SYSTEMS MANAGEMENT COLLEGE PRESS

FORT BELVOIR, VA 22060-5565

For sale by the U.S. Government Printing Office

Superintendent of Documents, Mail Stop: SSOP, Washington, DC 20302-9328
ii
iii

FOREWORD

This guide provides an introduction to scheduling intended for use by government

program managers and industry program of project managers and their respective staffs.

It is the third version of a 1986 publication prepared by Mr. David D. Acker, Mr. J. Stanley

Baumgartner, and Mr. Michael B. Patterson. A second version, published in 1994, was

prepared by Mr. William W. Bahnmaier and Mr. Paul T. McMahon.

This version addresses many of the topics contained in their earlier versions, especially

those relating to the different types of scheduling techniques. The major difference

between this and the previous versions is the treatment of scheduling as part of the

acquisition process and the overall program management effort, particularly as it relates

to the planning and control functions of program management. Scheduling is discussed

in the context of the development of integrated master plans and schedules, the risk

management process, and earned value management.

This guide is not intended as a detailed treatment of scheduling techniques. Instead, it is

more of a primer on the subject, addressing the importance of scheduling and the

application of basic scheduling techniques. It is a compilation of information from various

sources, and hopefully will serve as a starting point for those who desire to delve deeper

into the various scheduling techniques.

The proliferation of microcomputers has greatly enhanced the capability of managers at all

levels to develop and analyze schedules. Chapter 9 provides an overview of the types of

automated tools available and information on desirable features of scheduling software

applications.

This document reflects the efforts of many people. Mr. William W. Bahnmaier , Mr. Paul

T. McMahon , Lt Col. David Bachman, USAF, and Mr. John Kelley of the DAU/DSMC

faculty provided invaluable guidance and advice. Mr. Gregory T. Caruth of the DAU/

DSMC Press was very helpful in the composition of the guide. Frances M. Battle, provided

desktop publishing skills. Mr. Van Kinney, Ms. Joni Forman and Mr. Tom Parry of the OSD

Acquisition, Resources and Analysis staff provided comments on the draft and overall

support for the project. Special recognition also goes to the Institute for Defense Analysis

team of Mr. Lou Simpleman, Mr. Jim Lloyd, Mr. George Tolis, Ms. Patti Phillips, Ms. Tina

Higgins, and Ms. Yolanda Prescott, who wrote, edited, and prepared the major portions

of the text.

Norman A. McDaniel

Chair

Program Management and Leadership

Department

William W. Bahnmaier

Editor

Program Management and Leadership

Department
iv
v

CONTENTS

Chapter 1 INTRODUCTION ................................................................................................. 1

1.1 Overview ........................................................................................................................ 2

1.2 Purpose of This Guide .................................................................................................. 2

1.3 Guide Content ................................................................................................................ 2

1.4 Other Sources of Data ................................................................................................... 2

Chapter 2 PROGRAM MANAGEMENT AND THE ACQUISITION PROCESS .......... 3

2.1 Program Management Overview ................................................................................ 3

2.2 The Evolution of Program Management ................................................................... 4

2.3 The Acquisition Process and Scheduling .................................................................. 5

2.4 Risk Management and Scheduling ............................................................................. 6

Chapter 3 PROGRAM MANAGEMENT AND SCHEDULING ....................................... 7

3.1 Program Planning and Scheduling ............................................................................. 7

3.2 Work Breakdown Structure ......................................................................................... 8

3.2.1 Integrated Master Plans/Schedules .............................................................. 10

3.3 Program Controlling and Scheduling ........................................................................ 11

3.3.1 Earned Value Management ............................................................................ 11

3.4 Schedule Preparation .................................................................................................... 13

3.4.1 Activity Definition ........................................................................................... 13

3.4.2 Activity Sequencing ......................................................................................... 14

3.4.3 Activity Duration Estimating ......................................................................... 14

3.4.4 Schedule Development ................................................................................... 15

3.4.5 Schedule Control .............................................................................................. 15

3.5 Schedule Risk ................................................................................................................. 16

3.6 Summary ......................................................................................................................... 17

Chapter 4 SCHEDULE TYPES AND THEIR EVOLUTION ............................................. 19

4.1 Introduction .................................................................................................................... 19

4.2 Schedule Types .............................................................................................................. 19

4.2.1 Gantt and Milestone Charts ............................................................................ 19

4.2.2 Network Schedules .......................................................................................... 21

4.2.3 Production Schedules ...................................................................................... 23

4.3 Summary ......................................................................................................................... 24

Chapter 5 GANTT AND MILESTONE CHARTS ............................................................... 25

5.1 Description ..................................................................................................................... 25

5.2 Constructing Gantt and Milestone Charts ................................................................. 31

5.3 Gantt and Milestone Chart Advantages and Disadvantages .................................. 32

5.3.1 Advantages ....................................................................................................... 32

5.3.2 Disadvantages .................................................................................................. 32

5.4 How and When Gantt and Milestone Charts Are Employed ................................. 32
vi

5.5 Summary ......................................................................................................................... 33

Chapter 6 NETWORK SCHEDULING ................................................................................ 35

6.1 Description ..................................................................................................................... 35

6.1.1 PERT .................................................................................................................. 36

6.1.2 CPM .................................................................................................................... 37

6.1.3 PDM ................................................................................................................... 38

6.2 Network Scheduling Advantages and Disadvantages ............................................ 41

6.2.1 Advantages ....................................................................................................... 41

6.2.2 Disadvantages .................................................................................................. 41

6.3 How and When To Network Schedules Are Employed ......................................... 41

6.3.1 PERT Example .................................................................................................. 42

6.3.2 CPM Example ................................................................................................... 44

6.3.3 PDM Example ................................................................................................... 46

6.4 Network Scheduling When Resources Are Limited ................................................ 49

6.5 Summary ......................................................................................................................... 51

Chapter 7 PRODUCTION SCHEDULING .......................................................................... 53

7.1 Description ..................................................................................................................... 53

7.1.1 Objective Chart ................................................................................................. 54

7.1.2 Production Plan Chart ..................................................................................... 54

7.1.3 Program Status Chart ....................................................................................... 56

7.1.4 Line of Balance ................................................................................................. 56

7.2 How and When To Use the Line of Balance Techniques ........................................ 57

7.2.1 General ............................................................................................................... 57

7.2.2 Analysis ............................................................................................................. 57

7.3 Line of Balance Advantages and Disadvantages ...................................................... 58

7.3.1 Advantages ....................................................................................................... 58

7.3.2 Disadvantages .................................................................................................. 58

7.4 Summary ......................................................................................................................... 58

Chapter 8 TIME MANAGEMENT ....................................................................................... 59

8.1 Time Management and the Program .......................................................................... 59

8.1.1 Time Reserve .................................................................................................... 59

8.1.2 “Now” Schedule ................................................................................................ 59

8.1.3 Value of Time .................................................................................................... 60

8.2 Time Management and the Program Manager ......................................................... 62

8.3 Summary ......................................................................................................................... 63

Chapter 9 AUTOMATED SCHEDULING TOOLS ............................................................ 65

9.1 Automated Planning Aids ........................................................................................... 65

9.2 Functional Characteristics and Features .................................................................... 66

9.3 Evaluating Project Management Software Projects .................................................. 68

9.4 Finding Out More .......................................................................................................... 70
vii

APPENDIX A INTEGRATED MASTER SCHEDULE ..................................................... 71

APPENDIX B TIME ROBBERS ........................................................................................... 77

APPENDIX C GLOSSARY .................................................................................................. 79

APPENDIX D BIBLIOGRAPHY ......................................................................................... 83

FIGURES

3-1 Generic Aircraft System WBS ....................................................................................... 9

3-2 IMP/IMS Sample ........................................................................................................... 10

4-1 Gantt Chart Example ..................................................................................................... 20

4-2 Milestone Chart Example ............................................................................................. 21

4-3 Network Schedule Example ........................................................................................ 22

5-1 Example Gantt Chart Symbols ..................................................................................... 25

5-2 Example Gantt Chart ..................................................................................................... 26

5-3 Example Milestone Chart Symbols ............................................................................. 27

5-4 Example Milestone Chart ............................................................................................. 28

5-5 Example Combination Chart ....................................................................................... 29

5-6 Gantt Chart with Amplifying Information ................................................................. 30

6-1 Beta Distribution with PERT Time Estimates ........................................................... 37

6-2 Example PDM Relationships/Constraints ................................................................ 39

6-3 Example PDM Constraints with Lag Time ................................................................ 40

6-4 Example PDM Activity Node ...................................................................................... 40

6-5 PERT Example ............................................................................................................... 42

6-6 PERT Example with Slack Time .................................................................................. 43

6-7 CPM Example ................................................................................................................ 44

6-8 PDM Example ................................................................................................................ 47

6-9 PDM Example—Example and Late Start and Finish Times ................................... 47

6-10 PDM Example with Lag Time ..................................................................................... 48

6-11 Network Schedule with Constrained Resources ...................................................... 49

6-12 Personnel Loading Chart .............................................................................................. 50

6-13 Revised Personnel Loading Chart .............................................................................. 51

6-14 Revised Network Schedule with Constrained Resources ....................................... 52

7-1 Line of Balance Technique ........................................................................................... 55

8-1 Total Cost Analysis for Selecting “Optimum” Program Duration ........................ 60

9-1 On-Screen Data Entry Using Gantt Chart Feature

 (AEC Software Fast Track Schedule) 68

TABLES

6-1 CPM Example Time Estimates .................................................................................... 46

9-1 Project Management Software Functions and Criteria ............................................ 69
viii
ix
1

INTRODUCTION

1.1 OVERVIEW

In its simplest form, a schedule is a listing

of activities and events organized by time.

In its more complex form, the process examines all program activities and their relationships to each other in terms of realistic constraints of time, funds, and people,

i.e., resources. In program management

practice, the schedule is a powerful planning, control, and communications tool that,

when properly executed, supports time

and cost estimates, opens communications

among personnel involved in program activities, and establishes a commitment to

program activities.

A key aspect of program management planning, scheduling is integral to a program’s

acquisition strategy and to risk management, financial, and technical management

plans. In addition, scheduling is an important element of the other management functions: organizing, staffing, controlling, and

leading. For example, controlling is performed to keep abreast of program execution. To achieve this goal, it is necessary to

know whether the program is behind, on,

or ahead of schedule, and what adjustments are necessary to keep the program

on schedule once it’s back on track.

Why do Program Managers (PMs) schedule? The simple answer is they need a road

map for all program players. In reality,

scheduling can accomplish far more than

providing a list of activities and times.

1

Effective scheduling supports the following key program management activities:

• Provides the basis for effective communications within the government team

and with contractors,

• Identifies a baseline for program status

monitoring, reporting, and program control,

• Facilitates management, and

• Provides the basis for resource analysis

and leveling, exploration of alternatives,

and cost/time tradeoff studies.

On the other hand, poor scheduling can

adversely impact a program in a number

of areas. Haphazard schedules make it

difficult, at best, to determine a realistic

completion date and to efficiently allocate resources to the entire program. This

creates financial problems—escalation of

costs, increased support costs, delayed

return on investment, funding cuts, or

program termination.

Since scheduling is a powerful planning,

control, and communications tool available for program management, PMs must

have a good working knowledge of scheduling practices and applications (such as

Gantt, milestone, and network schedules)

in order to achieve program goals. PMs

will not always have to construct detailed

schedules, but they must be able to understand and analyze schedules created by
others (e.g., contractors) to successfully

manage a program. Since scheduling is an

intrinsic and indispensable element of the

management process, it is treated within

the context of program management.

1.2 PURPOSE OF THIS GUIDE

This guide is an introduction to scheduling. It is meant for people who already

have some experience in program management and those who seek to learn more

about the subject. It is not a detailed

treatment of the subject, but instead, explains how scheduling fits into the overall

program management effort and how to

accomplish schedule planning. It also illustrates different scheduling concepts

and techniques and how they can be applied and analyzed to manage effectively.

Finally, it is intended as a road map to

other useful and more comprehensive

documents and texts on the subjects of

project management, planning, and scheduling that are available in the literature.

1.3 GUIDE CONTENT

In order to provide a suitable context for

the topic of scheduling, Chapter 2 provides an overview of both program management and the acquisition process and

the role scheduling plays in each.

Chapter 3 expands on the role of scheduling in program management and addresses

the following topics: work breakdown

structure, integrated master plans and

schedules, and earned value management.

It concludes with a discussion of schedule

preparation and schedule risk.

Chapter 4 introduces the topic of scheduling techniques with a general discussion of

the various types of schedules and how

and why they evolved. This chapter is a

precursor for Chapters 5, 6, and 7, which

present a more detailed discussion of

the key schedule types. These chapters

focus on Gantt and milestone schedules,

network schedules, and production

schedules.

Chapter 8 introduces the concept of time

management as it relates to the program

and to the PM. Chapter 9 presents the

subject of automated project planning tools

and summarizes some of the desirable features of currently available software products. In addition to an overview describing

the types of automated tools available, this

chapter provides some suggestions on how

to find and evaluate the latest products.

The chapter concludes with a summary of

information sources that will be useful for

further inquiry.

1.4 OTHER SOURCES OF DATA

As previously noted, this guide is intended

as a primer. There is a considerable body of

literature on the subject of scheduling.

Much of it is of an academic nature not

specifically keyed to defense acquisition.

A number of these texts are listed in the

Bibliography Appendix of this guide. Additionally, an enormous amount of relevant information can be secured by searching the web using some of the popular

search engines.

Of particular use to PMs is the Defense

Acquisition Deskbook, available on the

Internet (http://www.deskbook. osd.mil).

The Deskbook includes a database containing mandatory and discretionary policy

documents, Department of Defense and

component discretionary practices, software tools and descriptions, front-line wisdom and advice, and sample formats.

2
2

PROGRAM MANAGEMENT AND

THE ACQUISITION PROCESS

2.1 PROGRAM MANAGEMENT

 OVERVIEW

The Department of Defense (DoD) considers program management to consist of the

tasks and activities that must be done in

order to design, develop, field, and support a weapons system. DoD directives

describe an Acquisition Program as: “A

directed, funded effort that is designed to

provide a new, improved, or continuing

weapons system or automated information system (AIS) capability in response to

a validated operational need.”1

 DoD considers the “program” to include the elements of the acquisition process, such as

the planning, programming, and budgeting process, and the design, development,

and production of the system. Practically

speaking, a DoD program consists of a

combination of organizational resources,

assembled to create a weapons system to

meet a specific operational requirement.

Four key considerations typically involved

in a program are:

• Cost to produce the system,

• Time required to complete the effort,

• Capability/technical performance required to meet needs, and

• Contribution of the system to the overall defense operational and strategic plans.

For purposes of this guidebook, Program

Management consists of the planning, organizing, staffing, controlling, and leading

(POSCL) management functions. Other

functions sometimes included in a program management context are scheduling,

budgeting, monitoring, directing, and

maintaining consensus and support. For

this guidebook, these latter functions are

considered subcategories of the basic five

functions, when appropriate.

• Planning addresses the program mission, objectives, goals, and strategy and

includes all management activities that result in selection of a course of action.

• Organizing considers the resources involved and how are they related. This function addresses the alignment of people,

funds, equipment, facilities, etc., and the

structure of the organization in order to

meet program goals; it identifies:

− Authority—The power to make final

decisions

− Responsibility—The obligation to perform assignments

− Accountability—The state of being

answerable for the completion of an

assignment.

• Staffing addresses the qualifications

and special skills that may be required

3
for persons assigned to each position in

the program and the time phasing of assignments.

• Controllingis the function during which

the manager monitors, measures, evaluates, and corrects program activities to ensure that actual operations conform to

plans.

• Leading is the process whereby one

individual exerts his/her influence over

others in a group. Directing, an element of

leadership, is the process of implementing, through the talents of others, the plans

to meet program objectives. This includes

training, supervising, delegating, motivating, counseling, and coordinating.

In a broad sense, the planning phase includes the tasks associated with defining

the work requirements, specifying the quantity and quality of work, identifying resources, and organizing them to best carry

out the program. Likewise, the management orexecution phase includes the tasks of

monitoring progress, comparing actual to

predicted outcomes, analyzing the impact

of differences between planned and actual

achievements, and adjusting the program

as necessary.

2.2 THE EVOLUTION OF

PROGRAM MANAGEMENT

Formal program management came to the

forefront in the late 1950s. The need to

develop and implement a management

approach to manage large-scale military

systems, both weapons and support systems, stimulated the government and aerospace industry to devise the means to plan

and execute complex programs. As the

cost of weapons systems increased and the

intensity of the Cold War grew, DoD also

felt the need to predict the cost, schedule,

and performance of its new systems. Military organizations (predecessors of current “acquisition” organizations), in conjunction with defense contractors, developed

much of the early theory and practices of

program management as new technologies emerged.

The use of “task teams” or program teams

and other organizational entities led to the

emergence of a program management philosophy for integrating activity in organizations. As the program management discipline evolved, organizations developed

special techniques for planning, organizing, staffing, controlling, and leading programs to integrate those activities from a

focal point in the organizational structure.

Moreover, program management addressed the elements of technical performance, cost, and schedule on a continual

rather than one-time basis in the evolution

of a program and considered them within

the context of an organization’s operational

(short-term) and strategic (long-term)

objectives.

DoD has recently improved management

with the introduction of the concept of

Integrated Product and Process Development (IPPD) and Integrated Product Teams

(IPTs). IPPD integrates all acquisition activities to optimize system development,

production, and deployment. Key to the

success of this concept are the IPTs, composed of qualified and empowered representatives from all appropriate functional

disciplines who work together to identify

and resolve issues. IPTs are the foundation for program management. One of the

tenets of IPPD is the use of event-driven

scheduling, which relates program events

to their accomplishment and accomplishment criteria. Its use reduces risk by

4
ensuring that product and process maturity is incrementally demonstrated prior to

beginning follow-on activities.

2.3 THE ACQUISITION PROCESS

AND SCHEDULING

For the management of programs, the DoD

acquisition process provides a framework

that consists of a series of phases and milestones. The phases are a logical means of

progressively translating broad mission

need statements into well-defined systemspecific requirements and ultimately into

operationally effective, suitable, and survivable systems. Each phase is designed,

among other things, to manage/reduce the

risks, ensure affordability, and deliver the

system to the user as soon as possible.

Milestones are the points in time where

decision makers evaluate the status of the

program and determine if the program

should proceed to the next phase. Prudent

consideration of schedule implications is

important in all phases of a program.

Milestone Decision Authority (MDA) and

Service acquisition officials are encouraged

to tailor programs to eliminate phases or

activities that result in little payoff in terms

of fielding time or cost. To effectively

tailor a program, managers must understand scheduling, resource availability and

allocation, and the risk associated with the

tailoring.

An acquisition strategy defines the business and technical management approach

to meet objectives within schedule and

program constraints. A primary goal is to

minimize the time and cost of satisfying a

valid need, consistent with common sense

and sound business practices. A PM prepares a preliminary acquisition strategy at

Milestone 0 and updates the strategy to

support each milestone decision by describing activities and events planned for

the upcoming phase and relating the accomplishments of that phase to the

program’s overall, long-term objectives.

The acquisition strategy is first formally

approved and published at MSI, Program

Initiation. It provides a master schedule for

research, development, test, production,

fielding, and other activities essential to

program success. This master schedule

also serves as the basis for formulating

functional plans and schedules.

As a program evolves through subsequent

phases, new information becomes available that permits refinement of schedules

and assignment of resources. Understanding of program risk becomes more specific

as the system under development is defined, thereby allowing identification of

risk-handling initiatives and their effect on

schedule. Schedule considerations are an

integral part of any Source Selection process, from preparation of the Request for

Proposal (RFP) through proposal evaluation. After contract award, the schedule

serves as a basis to determine progress and

assess the need for management action.

Government developers should design their

contracts with industry to allow time for

milestone decisions, permit demonstration

of exit criteria in time to support milestone

reviews and to reflect expenditure of money

with the program’s funding profile. A good

acquisition strategy allows fiscal control

without delaying the acquisition decisions

or contracts while adequately considering

risk. In other words, it reflects thoughtful

schedule and resource planning.

As a key element of the planning proess, PMs

must update the schedule as more is learned

about the program and as changes occur.

5
With each new update, program cost, time,

and requirements may change. PMs must

respond by changing the mix and level of

resources and continuously updating the

program plan and the schedule as needed.

2.4 RISK MANAGEMENT AND

 SCHEDULING

DoD defines risk management as “the act

or practice of controlling risk. It includes

risk planning, assessing risk areas, developing risk-handling options, monitoring

risks to determine how risks have changed,

and documenting the overall risk management program.”2

 As part of their responsibility to manage risk, PMs must consider

risk in their planning and scheduling practices. Risk management is concerned with

the identification of uncertainties that

threaten cost, schedule, and performance

objectives, and the development and implementation of actions to best deal with those

uncertainties.

6

ENDNOTES

Risk management and scheduling are

closely tied. Consideration of one requires

a reassessment of the other. For example,

in creating the strategy and plans to handle

program risk, a PM must consider how the approach affects the program schedule. Similarly, any tradeoffs

between cost and performance must take

into account schedule implications. Conversely, any change to the program schedule must consider the impact on the overall

program objectives and on cost and performance. The challenge is to develop a plan

that balances risk, cost, schedule, and performance.

Schedule risk is defined as the likelihood

and consequences of failing to meet the

program schedule, and it is an integral part

of program risk. This topic is covered in

Chapter 3.

1

DoDD 5000.1, Defense Acquisition, March 15, 1996. (Being revised and updated as of 1 January 2000) 2

Ibid.
3

PROGRAM MANAGEMENT AND SCHEDULING

7

As discussed in the previous chapters,

scheduling is one of the most powerful

tools available to the PM, and its effective

application is essential to program success. While it is a key element in performing all program management functions, it

is also critical to the accomplishment of

planning and controlling management

functions. This chapter discusses scheduling in the context of these two functions

and addresses the essential elements and

considerations in schedule planning.

3.1 PROGRAM PLANNING AND

SCHEDULING

Program planning is the process of determining what needs to be accomplished, by

whom, when, and under what resource

constraints. It is arguably the most important of the program management functions.

Without a sound and comprehensive plan,

it is virtually impossible to develop a meaningful budget, effectively organize and staff

the program office, direct the actions of the

program office, or monitor and control the

program. In addition to determining the

“what, where, who, with what, and when”

of a program, planning also helps to identify risk areas and ways to handle the risk,

and establishes the program baselines.

There are a number of products of the

planning process. Among them are:

• Acquisition Strategy—This is the comprehensive, integrated plan the program

will follow. It provides an overall concept

of the program that functional plans will

lay out in greater detail and reflects the

strategy that will be followed to meet program objectives and to handle risk in the

program. The acquisition strategy includes a program structure/schedule

which depicts a visual overview and picture presentation of the acquisition strategy. This schedule is a single diagram

similar to the diagram shown in Figure 3-3,

and defines the relationship among acquisition phases, decision milestones, solicitations, contract awards, systems engineering design reviews, contract deliveries, test

and evaluation activities, production releases, and operational deployment objectives. It includes quantities to be procured

and delivered by fiscal year by phase in

terms of prototypes, engineering

developmemt models, low-rate intitial production and full-rate production. The program structure/schedule is a key decision

review/milestone document; it summarizes the program and is built from many

other more detailed schedules found in

functional plans such as test and evaluation, contracting, etc. It is sometimes referred to as the Master Program Schedule

(MPS). In addition to this top level structure/schedule, the PM may deem it necessary to have more detailed program management Integrated Master Plans (IMP) and

Integrated Master Schedules (IMS) prepared and submitted by the contractor

during the proposal process. See the DSMC

Acquisition Strategy Guide1

 for information

on structuring, developing, and executing

an acquisition strategy.
• Functional Plans—These are the detailed plans that lay out the approach to

be taken in the different functional areas.

Examples include: the Test and Evaluation Master Plan (TEMP) and Command,

Control, Communications, Computers, and

Intelligence (C4I) Support Plan, which are

required; and the Systems Engineering

Master Plan (SEMP), Logistics Support

Plan (LSP), etc., which are optional.

• Work Breakdown Structure (WBS)—

The WBS provides a basic framework for

identifying each element of a project in

increasing levels of detail. In essence, it

describes the way work is performed. The

WBS also provides a coherent method for

reporting progress toward plan goals.

• Integrated Master Plan (IMP)—The

IMP is an event-based plan depicting the

overall structure of the program and the

key processes, activities, and milestones.

It defines accomplishments and criteria for

each event.

• Integrated Master Schedule (IMS)—

The IMS shows the detailed tasks and

timing for events in the IMP and depicts

the logical progression of events throughout the program. These tasks should be

directly traceable to the IMP and the WBS.

• Schedules—A series of schedules are

developed during the planning process,

all of which are derived from the IMS.

These schedules are developed to show

the details required to complete key activities and milestones.

• Budget—The budget reflects the cost

of the integration of the scope, schedule,

and resource plan for accomplishing the

work.

Scheduling is a critical element in the planning process. In addition to being an output of the process as discussed above, it

also contributes to the development of the

other outputs. The early involvement of

people who are knowledgeable and experienced in scheduling techniques can contribute to the effective translation of strategic

concepts and ideas into detailed logic diagrams, depicting the program activities

and relationships among activities. This

can be very useful in developing budget

and detailed functional plans, especially

in identifying the required resources and

leveling them throughout the activities.

The WBS and the IMP/IMS are important

concepts used in the scheduling process

and are described in more detail in the

following sections.

3.2 WORK BREAKDOWN STRUCTURE

During the 1960s, the impetus to develop a

tool to help project managers define a

project in a cohesive way gave rise to the

development of the WBS. WBS use has not

been confined to the DoD and its contractors; rather, it is now used in many commercial enterprises. Several years after the

emergence of the WBS concept, DoD published a WBS standard for DoD acquisition

organizations as well as their contractors to

use: MIL-STD-881B. This standard has been

superseded by a handbook, MIL-HDBK881, dated 2 January 1998. It contains much

of the same information as its predecessor

but is not directive in nature and is for

guidance only.

MIL-HDBK-881defines a WBS as:

• A product-oriented family tree composed of hardware, software, services, data,

and facilities. The family tree results from

8
high cost or high risk. In that case, the WBS

should be taken to a lower level of

definition.

WBS's apply to seven specific categories of

defense materiel systems: aircraft; electronic/automated software; missile, ordnance; ship; space; and surface vehicle.

The WBS should be developed and maintained based on the systems engineering

efforts throughout the system’s life cycle.

Figure 3-1 is an example of a level 3 program

systems engineering efforts during the acquisition of a defense materiel item.

• A WBS displays and defines the product, or products, to be developed and/or

produced. It relates the elements fo work

to be accoomplished to each other and to

the end product.

• A WBS can be expressed down to any

level of interest. However, the top three

levels are as far as any program or contract

needs to go unless the items identified are

9

Figure 3-1. Generic Aircraft System Program WBS

Level 1 Level 2 Level 3

Aircraft System Air Vehicle

Systems Eng/

Program Mgmt

System Test and

Evaluation

Training

Data

Peculiar Support

Equipment

Common Support

Equipment

Operational/Site

Activation

Industrial Facilities

Initial Spares &

Repair Parts

Airframe

Propulsion

A/V Application S/W

A/V System S/W

Navigation/Guidance

Central Computer

Fire Control

Data Display and Controls

Survivability

Reconnaissance

Automatic Flight Control

Central Integrated Checkout

Antisubmarine Warfare

Armament 

Weapons Delivery

Auxiliary Equipment

Development Test and Evaluation

Operational Test and Evaluation

Mock-ups

Test and Evaluation Support

Test Facilities

Equipment

Services

Facilities

Technical Publications

Engineering Data

Management Data

Support Data

Data Depository

Test and Measurement Equipment

Support and Handling Equipment

Test and Measurement Equipment

Support and Handling Equipment

System Assembly, Installation and

Checkout on Site

Contractor Technical Support

Site Construction

Site/Ship/Vehicle Conversion

Construction/Conversion/Expansion

Equipment Acquisition or

Modernization

Maintenance (Industrial Facilities)

Initial Spares and Repair Parts

Prime Mission System
10

WBS for an aircraft system. The WBS approach provides a powerful technique for

scoping a project in a manner that provides

management with insight into project requirements and performancefrom the

very top, or systems level, to the lowest

level of definition of a work product. Planning work using the WBS approach serves

as the basis for both estimating and scheduling resource requirement.

3.2.1 Integrated Master Plans/

Schedules

The IMP is a very effective tool of program

management. It is the contractor's eventbased plan for accomplishing the Statement of Objectives (SOO) and Statement of

Work (SOW). It identifies the key activities, events, milestones, and reviews that

make up the program. A program IMP is

prepared initially by the contractor and

provides the basis for development of subordinate IMPs and other functional plans.

It also identifies those events and activities

that will be included in the IMS.

The IMS is a networked multi-layered

schedule generated by the contractor that

begins with all identified IMP events, accomplishments, and criteria. It shows the

expected start and finish dates of these

events. It contains all contractually required events/ milestones such as reviews,

tests, completion dates, and deliveries

specified in the program WBS.

The IMP is prepared by the contractor

during the proposal process. It is maintained by the government program office

and contractor through a collaborative effort involving all the program “stakeholders.” In some cases, a preliminary IMP

may be developed by the government,

Figure 3-2. IMP/IMS Sample

Detailed Tasks

1. Preliminary Design Complete

2. Duty Cycle Defined

Requirement WBS Elements SOW Task

Integrated Master Plan

Integrated Master Schedule

3.1 Air Vehicle (WBS 1000)

Design, develop, produce

and verify, complete air

vehicles, defined as airframe

propulsion, avionics and

other installed equipment.

Management Plan Events

PDR

Accomplishment Criteria

1. a. Duty Cycle Defined

 b. Preliminary Analysis Complete

1. Preliminary Design

2. Review

19XX 19XY 19XZ

Program Events PDR CDR

1000 Air Vehicle

1100 Airframe

1110 Wing

11n

System Specification

1000 Air Vehicle

1100 Airframe

Wing
with industry input, during pre-solicitation. The IMP defines contract requirements

stated in the RFP and contractors use it to

develop the IMS and detailed functional

schedules. These integrated schedules tie

together all program tasks by showing their

logical relationships and any constraints

controlling the start or finish of each task.

This process results in a hierarchy of related functional and layered schedules

derived from the WBS that can be used for

monitoring and controlling program

progress. An example (suggested format)

of an IMP/IMS for an aircraft development

program is depicted in Figure 3-2. The IMS

should be expanded down to the level of

detail appropriate for the scope and risk of

the program. Programs with high risk

should show more detail in the IMS to

provide the visibility necessary to manage

risk. A more detailed discussion of IMS's is

contained in Appendix A. A Data Item

Decription (DID) has been developed by the

Department of Defense for the IMS; the identification number is DI-MISC-81183A. This

DID is at Tab 1 to Appendix A.

3.3 PROGRAM CONTROLLING

AND SCHEDULING

The controlling function contains all those

activities that a program manager undertakes in attempting to ensure that the actual program conforms to the developed

plan, to include the implementation of necessary action to get the program back on

the plan if possible. To control a program,

the PM needs the means to monitor program progress against the established plan,

or the program baseline. In its simplest

form, the program schedule can serve as a

baseline against which to measure progress.

If there are indications that an activity is

falling behind schedule, this information

can be used by the manager as a basis for

corrective action. However, considering

schedule information alone can be misleading. Successful management requires

the integration of the technical, schedule,

and cost aspects of a program. Thus, some

form of integrated performance measurement is needed for monitoring and controlling a program. The concept of earned value

management provides such a capability.

3.3.1 Earned Value Mangement

Earned Value Management (EVM) is the

use of an integrated management system

that coordinates work scope, schedule, and

cost goals and objectively measures progress toward these goals.2

 The purpose of

EVM is to provide contractor and government PMs with accurate data to monitor program execution. It is also intended

to provide an adequate basis for sound

contractor and government decision making by requiring that the contractor’s internal management control systems produce

data that: (1) indicate work progress; (2)

properly relate cost, schedule, and technical accomplishments; (3) are valid, timely,

and able to be audited; and (4) provide

DoD component managers with information at a practical level of summarization.

The DoD earned value process holds the

contractor responsible for effective implementation of an EVM system. DoD does not

prescribe a specific EVM system for contractors to use; instead, it has established a

set of criteria that the contractors’ systems

must meet to be acceptable. The requirement to use an EVM system that meets the

criteria is dependent on the type and size

of the contract. DoD Regulation 5000.2-R

defines the contracts that must use such an

EVM system as well as the criteria for an

acceptable system. For contracts that do

11
not meet these thresholds, contractor management information is provided to the

government using a Cost/Schedule Status

Report (C/SSR). This report should be

based on an underlying management system that uses an earned value approach for

tracking progress. Such a system does not

have to meet the EVM criteria of DoD

5000.2-R; however, the government should

negotiate with the contractor to ensure that

the system does emphasize earned value

methodology.

Basically, earned value relates resource

planning to schedules and to technical performance requirements. All work (identified in the Program and Contract Work

Breakdown Structures) is planned, budgeted, and scheduled in time-phased

“planned value” increments constituting a

performance measurement baseline. As

work is performed, it is “earned” on the

same basis as it was planned, e.g., in budgeted dollars or labor-hours. Planned value

[budgeted cost of work scheduled (BCWS)]

compared with earned value [budgeted cost

of work performed (BCWP)] measures the

dollar volume of work planned versus the

equivalent dollar value of work accomplished. The difference, if any, is termed

the “schedule” or “accomplishment” variance. Earned value (BCWP) compared

with the actual cost of the work performed

(ACWP) provides an objective measurement of cost performance. Any difference

is called the cost variance.

The three data points—BCWS, BCWP, and

ACWP—are outputs of the EVM system and

are provided to the government on a monthly

basis. They, along with the schedule and cost

variances, provide the basic information

needed to determine program status at a

given time, and to identify the elements that

are driving each of the variances.

Analysis of these data points over time

also identifies trends that may affect or

impact the future performance for the remainder of the contract. This is important;

it enables PMs to isolate causes of recurring variations and to take alternative actions that will improve performance. Quantitative techniques can also be applied to

EVM data to predict program performance

at completion in terms of cost and schedule. The DSMC EVM Textbook3

 provides

detailed information on the application of

EVM techniques.

Success of EVM techniques is dependent on

several things, not the least of which is

effective and accurate contractor scheduling. EVM system criteria do not require

contractors to use specific scheduling techniques. However, they do seek formality,

consistency, and discipline throughout the

scheduling process. The contractor's scheduling system:

• Provides a summary or master schedule and related subordinate schedules

showing vertical traceability from the master to the detailed schedules

• Identifies key milestones and activities

and indicates significant constraints and

relationships

• Provides current status and forecast of

completion dates of scheduled work that

enable comparison of planned and actual

status of program accomplishments

• Establishes a schedule baseline

• Provides horizontal traceability showing interrelationships among various activities.

12
The scheduling baseline usually consists of a hierarchy of vertically integrated schedules, with each lower-level

schedule more fully identifying and expanding the tasks necessary to meet the

program’s objectives. Generally, three sets

of schedules are prepared:

• Master Schedule (MS)—The top-level

schedule that summarizes key program

activities and milestones and depicts the

logical progression of events throughout a

contract. Program Structures/Master Program Schedules developed by the government PM reflect information contained in

the contractor's Master Schedule.

• Intermediate Schedules—The schedule that ties the MS to the detailed schedules. It allows for rollup of detailed schedules to summary levels that are useful for

management.

• Detailed Schedules—The schedules at

the control account or work package level.

Work packages must be distinguishable

from each other and must include definite

start and completion dates. They are prepared by the contractor with government

concurrence.

3.4 SCHEDULE PREPARATION

As stated earlier, scheduling is a critical

element of the planning process. Conversely, planning is critical to the development of effective schedules. Near-term

scheduling can and should be accomplished in sufficient detail to support

management at each level. Far-term, or

rolling-wave, scheduling will be less precise, accounting for the alternative paths

that the program may take. As the program approaches each phase, the schedule for that phase will be fleshed out with

more detailed schedule information. The

schedule for the out-year phases will be

adjusted based on the most current information. However, this should not be taken

as a license to make easy changes in the

schedule. Every effort should be made to

maintain the original schedule.

In all programs, there will always be a

requirement to make tradeoffs between

cost, schedule, and performance. Cost includes all resources—people, money,

equipment and facilities. Performance includes quality and supportability parameters. The best schedule supports the best

tradeoff between these competing demands, taking into account the risks that

are associated with each tradeoff and the

impact on the overall program.

The preparation of program schedules

should be done within a formal structure.

The procedures to be followed should be

specified, to include such things as software applications to be used, the formats

for displays, and the type of symbols to be

used. Also, clear lines of authority and

responsibility should be established. The

remainder of this section discusses the logical steps that should be followed in preparing schedules, to include sources of

information, tools and techniques, and the

outputs of the steps. These steps are based

on those described in the Program Management Institute’s Guide to the Program

Management Body of Knowledge.

4 While they

present a somewhat different approach

than the IMP/IMS method, they have generic applicability over the range of planning methods.

3.4.1 Activity Definition

This step involves the identification and

definition of those activities that must be

13
accomplished to achieve the objectives.

The WBS is a logical source for such

descriptions. If a WBS is not available,

more planning must be done in order to

identify project activities clearly. Other

inputs to the definition step are the program scope, historical information, program constraints and assumptions, and

events required by the Planning, Programming, and Budgeting System (PPBS), the

requirements generation system, and DoD

acquisition management process.

Decomposition and templates are techniques commonly used in activity definition. Decomposition involves the successive breakdown of program elements into

smaller, more manageable components,

which eventually describe the activities to

be scheduled. This technique is essentially the same used in WBS development.

A template is an activity list or WBS element from another similar program that

can serve as a model for the current program and provide a starting point for defining specific activities.

The primary output of this step is the activity list, which should contain a complete

description of each of the activities necessary to complete the program. This list

should be linked to the WBS, which should

be reviewed and revised/clarified as necessary to incorporate changes resulting

from the activity definition process. Supporting details for each activity, such as

constraints and assumptions, should also

be developed and documented.

3.4.2 Activity Sequencing

This step involves the accurate identification of constraints/relationships among activities and establishing the order in which

the activities will be accomplished.

There are several inputs to this step:

• The activity list developed in the activity definition step,

• The product description and characteristics,

• Mandatory constraints/dependencies,

such as the fact that a prototype must be

fabricated before it can be tested,

• Discretionary constraints/dependencies developed by the program management team based on “best practices” or

specific sequences desired by management,

• External dependencies, such as availability of test sites, and

• Other constraints and assumptions.

A number of tools and techniques are useful in developing the logic diagrams that

reflect the desired activity sequencing.

They include various network scheduling

techniques that are discussed in Chapters 4

and 6. In addition, a number of scheduling

software programs develop activity sequencing. Their selection and use are discussed in Chapter 9.

The output of this step is a network diagram that reflects the sequence of activities

based on the inputs described above. This

diagram should be augmented with a

narrative description of the sequencing approach and a detailed discussion of any

unusual or complex sequences. Activity

lists should be reviewed and revised to

reflect any changes necessitated by activity

sequencing.

3.4.3 Activity Duration Estimating

Activity duration estimating is the determi14
nation of the time required to complete the

activities that make up the program. This

is one of the most difficult aspects of schedule development and should be performed

by people who are most familiar with the

activity. Two key inputs to the estimation

process are the resources required and assigned for the activity and the capabilities

of the resources assigned. Historical information from other programs and from commercial databases can also be helpful in

developing accurate estimates.

The following techniques are commonly

used in estimating activity durations:

• Expert judgment guided by historical

information,

• Analogous estimating based on experience of similar programs,

• Parametric estimating based on formulas describing relationships among program parameters and time, and

• Use of simulation to develop distributions of probable duration of each

activity.

The output of this step is an estimate of the

likely amount of time to complete each

activity. These estimates should also include a range of possible values, e.g., 3

weeks ± 1 week, and a clear statement of

the assumptions made in the estimation

process.

3.4.4 Schedule Development

This step involves the development of

realistic start and finish dates for each

activity. An iterative process, schedule

development takes into account activity

sequencing, duration estimates, resource

requirements and availability, calendars

that show when work can be performed,

constraints, assumptions, and risk.

The output of this step is a set of schedules for the program. These include the

master program schedule and the supporting detailed schedules, which should reflect the best balance possible between competing demands of time and resources.

They should also take into account the risk

associated with time, cost, and performance

tradeoffs and the impact on the overall

program.

A number of techniques and tools are useful

in developing schedules, many of which are

contained in various scheduling software

applications. Many of these applications

contain the capability to perform various

types of mathematical analyses to calculate

theoretical start and finish dates for each

activity based on the overall sequencing of

the program activities. Two of the more

commonly known analysis techniques are

critical path method (CPM) and the Program Evaluation and Review Technique

(PERT). They are discussed in greater

detail in Chapter 6.

Other scheduling development techniques

that are commonly used focus on schedule

development in light of resource (time,

people, funds, material) constraints. These

techniques provide the means to manage the

affect of these constraints through the compression of activity duration and the leveling

of resources throughout activities. Schedule

compression and resource leveling are discussed in more detail in Chapter 6.

3.4.5 Schedule Control

The final step in the schedule preparation

15
process is to identify schedule variations and

to manage actual changes to the developed

schedules. A schedule change control system that defines the procedures by which

changes can be made should be established

and integrated into the program’s overall

change control system. The schedule

change control system should address such

things as the methods of schedule performance tracking and the approval process

for authorizing changes. The need for schedule changes can be caused by a number of

factors, to include:

• Failure to achieve planned dates for

specific activities or events,

• Internal program management assessment and replanning, and

• External direction, such as reallocation

of funding.

When evaluating these factors, it is important to determine what, if any, schedule change is necessary. For example, if

an activity that is not on the critical path is

not completed as planned, it may not have

any effect on the overall program schedule. Consequently, it may not require any

significant schedule change.

The schedule change control system

should also include procedures for implementing schedule changes. Such procedures should address the requirement to

keep all program stakeholders, especially

the users, advised of any significant schedule changes. They should also address the

process for adjusting the schedule baseline

and the overall program plan when necessary schedule changes are severe. The

change control system can also serve as a

good database of lessons learned. Consequently, information concerning schedule variations, their evaluation, and the

development of corrective actions should

be documented and made readily available to members of the program’s management team, and to other programs.

3.5 SCHEDULE RISK

In Chapter 2, we discussed the relationship between risk management and program scheduling. In this section, we discuss the risk associated with the program

schedule. Uncertainty exists in every

schedule. It is impossible to predict, with

complete confidence, the length of time

necessary to complete an activity, meet a

milestone, or deliver a system. Little information exists in the early phases of a

program, and planners must rely on personal experience and the estimates of experts. As a program progresses through

the acquisition cycle, more information

becomes available. Schedules developed

in the latter phases of a program are based

on more information and analyses, but

they still lack complete certainty. Uncertainty introduces the element of risk in the

planning process. Schedule risk is the

likelihood of failing to meet schedule plans

and the effect of that failure.

When creating a schedule, or when determining overall program risk, the PM must

assess the risk associated with the schedule. One technique for assessing this schedule risk involves estimate contributions

for each activity’s duration and aggregating these distributions using a Monte Carlo

simulation or other analytical tools. The

resulting program-level schedule is then

analyzed to determine the actual schedule risk and to identify the schedule risk

drivers.

This technique uses a range of times that it

will take to complete each activity instead

16
17

of single-point estimates. This approach

results in a more realistic estimate of schedule risk because it accounts for much of the

uncertainty inherent in the use of singlepoint estimates. Their use invariably leads

to underestimating the time required to

complete the program and, therefore,

schedule overruns, primarily because the

point estimates do not adequately address

the uncertainty inherent in the individual

activities.

This range of values for each activity defines a probability distribution for the duration of the activity. These distributions

are then combined to determine the program-level schedule estimate. This approach enables PMs to estimate early in a

program if there is a significant likelihood

of overrunning the program schedule and

by how much. It also identifies program

activities that are on the “highest risk path.”

This technique can be used in any acquisition phase beginning with the completion of the first statement of work. The

schedule probability distribution function

for each key activity should be developed

as soon as the activity is included in the

master schedule. The distribution functions should be periodically reviewed and

revised, if necessary, at least once per phase.

The technique should be applied by a small

government-industry team consisting of

schedule analysts and technical experts

who understand the significance of previous risk performance assessments. See the

DSMC Risk Management Guidebook5

 or the

Defense Acquisition Deskbook, Section 2.5.2.46

for more details on the application of this

technique.

3.6 SUMMARY

Scheduling is critical to the successful execution of the planning and controlling

functions of program management. In the

planning phase, it contributes to the

development of detailed functional plans

and budgets and to identification and allocation of required resources throughout

program activities. During this phase is

developed a set of integrated multi-layered schedules that tie together all program activities, showing their logical relationships and any constraints. The level of

detail developed for these schedules depends on program scope and risk. This

process provides a hierarchy of functional

and layered schedules that can be useful in

monitoring and controlling program

progress.

Effective program control depends on some

form of integrated cost, schedule, and technical performance management, such as

the earned value management system

(EVMS). Effective scheduling is key to the

success of this technique. EVMS criteria do

not dictate the use of specific scheduling

techniques. However, they do seek formality, consistency, and discipline

throughout the scheduling process.

A five-step process for schedule preparation that is commonly used in program/

project management includes:

• Activity definition,

• Activity sequencing,

• Activity duration estimation,

• Schedule development, and

• Schedule control.

Risk is inherent in all programs, and scheduling is one element of risk. Uncertainty

introduced in estimating the duration of

each activity causes most schedule risk.

PMs must assess the likelihood of failing

to meet schedule plans and the impact of

that failure. Probabilistic techniques have

proven to be very useful in conducting

these assessments.
1 Defense Systems Management College, Acquisition Strategy Guide, Fort Belvoir, VA, January 1998.

2 Defense Systems Management College, Earned Value Management Textbook, Fort Belvoir, VA, April 16, 1998,

3 Ibid.

4 Program Management Institute, A Guide to the Program Management Body of Knowledge, Newtown Square, PA,

1996.

5 Defense Systems Management College, Risk Management Guidebook, Fort Belvoir, VA, May 1999.

6 Information on schedule risk techniques is in the Risk Assessment Techniques of the Front Line Wisdom

& Advice portion of Section 2.5.2.4, Defense Acquisition Deskbook.

ENDNOTES

18

Figure 3-3. Program Schedule/Structure (Example)

PROGRAM STRUCTURE/SCHEDULE (EXAMPLE)

 FY01 FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12 FY13 FY14

Contract

Award

RDT&E

Procurement

O&M

MILCON

Total

C&TD

CAD

Sys Int Sys Demo

System Devel & Demo

A Dec

Rev B

Prototype

Competition

IPR

C FRP IOC

B FRP IOC

B C FRP IOC

SD LRIP PROD Blk II

PROD

Blk III

SD

Blk III

PROD

C

Milestone

Reviews

& Phases

Technical

Reviews

Developmental

& Operational

Testing

Deliveries

OT FOT&E

EDM

EOA

LRIP Production

LRIP Prod & Deployment Operations & Support

Block II

Block III

(eng dev models)

DT&E

IOT&E

Full-Rate

CE

LFT&E

C&TD SI

ASR SRR SFR PDR CDR FCA/

SVR

PCA CDR PCA CDR PCA

Blk II

SD
19

4

SCHEDULE TYPES AND THEIR EVOLUTION

4.1 INTRODUCTION

Previous chapters of this guide stress the

point that scheduling is an intrinsic, indispensable part of program management and

a key output of the planning function of

that process. They also describe the relationship between the program Work Breakdown Structure and scheduling, and introduce the concepts of the Integrated Master

Plan and the Integrated Master Schedule.

Properly prepared and accurate schedules

are invaluable tools in the overall management of programs. They provide a road

map of where the project is going, the

resources required to accomplish the various project tasks, a means to determine

progress, and an effective way to present

status information. This chapter contains

information on the various types of schedules generally in use today, their characteristics, advantages and disadvantages, and

how they have evolved. Subsequent chapters provide more detailed information on

each of the schedule types, along with information on the selection and use of

scheduling software.

4.2 SCHEDULE TYPES

Schedules can be presented in a variety of

ways. Regardless of how they are displayed, schedules essentially convey information concerning one (or a combination) of the following categories:

• Activities or tasks to be accomplished

over a period of time, and

• Events or milestones, that take place at

a point in time, such as a Defense Acquisition Board (DAB) milestone review.

Dependencies or constraints among activities or events.1

Currently, four types of schedules are in

common use and depict the categories of

information described above. They are the

Gantt or bar chart, the milestone schedule/

chart, the network schedule, and the production schedule. The evolution, characteristics, and uses of each of these schedules

are described in the following paragraphs,

and a more detailed treatment of each of

them is contained in subsequent chapters.

4.2.1 Gantt and Milestone Charts

Gantt charts and milestone charts are normally combined to show a program’s

schedule; therefore, they are discussed in

this context. The Gantt chart is used to

provide information concerning activities.

It is commonly referred to as a bar chart,

since it depicts an activity as a horizontal

bar imposed over a time-line, or calendar.

It shows the planned start and finish dates

for the activity and may provide information about task progress, including schedule slips or gains. Figure 4-1 is an example

of a simple Gantt chart that shows the

planned schedule for four activities.

Progress in accomplishing each activity

can be shown on each of the bars, as shown

by the shaded portions of activities 1 and 2.
Activity

Identify User Requirements

Identify Performance Requirements

Identify Interface Requirements

Prepare SW Requirements Spec

Jan Feb Mar Apr May Jun

Legend

Planned

Actual

20

The Gantt chart was the first formal scheduling technique developed. It dates back

to the early 20th century when Henry L.

Gantt first introduced it while working at

the Frankford Arsenal during World War

I. It was developed to provide a more

formal and systematic way to schedule

tasks when time was an imprtant factor.

The Gantt chart has survived in its basic

form to this day and continues to be

widely used as a scheduling tool at all

levels within organizations. Its value

lies in its simplicity and its ability to

convey considerable information in a

clear and concise manner. In the past, the

principal shortcoming of the traditional

Gantt chart was its inability to clearly

depict dependencies or constraints

among activities, making it difficult to

analyze schedules and optimize the allocation of resources to the activities. Some

scheduling software programs now make

it possible to show relationships, thereby

improving its utility. The Gantt chart is

very useful in reporting project status and

in managing individual activities or simple

projects with few tasks.

Subsequent to the development of the Gantt

chart, planners and managers used a similar approach to depict information about

significant project events, focusing on specific points in time. These events represented project milestones—hence the introduction of the milestone chart. The milestone chart shows when an event is scheduled and when it is actually accomplished.

Figure 4-2 is an example of a milestone

chart showing the status of four events;

each of these events represents the completion of the four activities shown in the

example Gantt chart in Figure 4-1.

Like the Gantt chart, the strength of this

milestone chart as a scheduling technique

lies in its relative simplicity and its ability

to concisely display project information,

Figure 4-1. Gantt Chart Example

Now
21

especially at the “big picture” level. However, it does have shortcomings that limit

its effectiveness in day-to-day project management. As shown in Figure 4-2, the milestone chart can depict the events corresponding to the completion of an activity.

However, it does not reflect the progress in

accomplishing the activity. In this case, a

manager relying on this milestone chart

information could be surprised if the

planned completion date is not achieved.

With no warning or indicators of schedule

slippage, the manager loses any flexibility

in attacking the underlying problems causing the slippage. This shortcoming can be

compensated for by the addition of intermediate events or through the use of combined

Gantt and milestone charts. This is discussed

in more detail in the next chapter.

Another weakness of the milestone chart is

the difficulty to clearly visualize the

relationships, dependencies, and constraints among the various project/program activities and events. In spite of these

shortcomings, the milestone chart can be

an effective way of presenting the project

or program status at higher levels of management review.

Perhaps the biggest shortfall of the Gantt

and milestone charts is that neither of

them, nor the combination of both, allow

detailed schedule analysis. However,

every PM must know and understand

Gantt and milestone charts for two simple

reasons: everybody uses them, and normally, one of the first steps in the planning

process is to construct a schedule using a

Gantt chart.

4.2.2 Network Schedules

Network scheduling was developed to

overcome the primary shortcoming of the

Gantt and milestone charts—the inability

to clearly portray the relationships, dependencies, and constraints among the project

activities and events. A network schedule

is a graphical display of a project, including a representation of these relationships.

Figure 4-3 shows an example of a network

schedule for a simple project.

In this example, the lines represent project

activities A through H; the nodes represent the events associated with the beginning and end of the activities. The network shows the following constraints

Figure 4-2. Milestone Chart Example

Event

User Requirements Identified

Performance Requirements Identified

Interface Specs Identified

SW Requirements Spec Completed

Jan Feb Mar Apr May Jun

Legend

Planned

Actual
among the activities: activity A must be

completed before activities B, C, or D can

begin; B must be completed before E can

begin; F cannot begin until D is completed;

G cannot begin until C and E are done, and

H cannot begin until F and G are completed. In addition to showing this type of

sequencing constraints, network schedules

can also show the time and resources

planned for each activity and thus provide

managers with a mechanism to monitor

and control the project. A later chapter

covers network schedules in detail.

The advent of network schedules can be

traced back to the 1920s and the evolution of operations research. Analysts realized the inability to depict dependencies and constraints was a major shortcoming of existing scheduling techniques,

and attempted to solve the problem

through the application of network theory.

The translation of this theory into a usable

scheduling tool was hindered by the inability to process network-related data

in a timely fashion. The development of

the computer provided the means to automate this data processing and, by the

1950s, the concept of network scheduling

was being applied to large, complex programs. The first major network scheduling technique developed was the Program Evaluation and Review Technique,

or PERT, which was used as a management tool for scheduling and controlling

the Navy’s Polaris missile program. PERT

enables managers to visualize the entire

program, see interrelationships and dependencies, and recognize when and

where delays are acceptable. One of the

key features of PERT is the use of probability techniques to develop a set of

time estimates for each program activity,

making it particularly well-suited for programs where it is difficult to make accurate estimates with high confidence. Concurrent with the development of PERT,

the construction industry developed a

network scheduling system based on the

concept of critical path. A project’s critical path is the most time-consuming route

through the network activities that must

be completed in order to finish the project.

This approach, named Critical Path Method

(CPM), was designed to focus on performance time and total program cost. Some

publications refer to CPM as the Arrow

Diagram Method (ADM).

Figure 4-3. Network Schedule Example

22

A

B

C

D

E

F

G H
PERT and CPM scheduling techniques have

many similarities. For example, each shows

the relationships among activities and

events, both include the project’s critical

path, and the structure of each allows analysis of the tasks to be done, resources assigned to do them, and the time associated

with each task. Both techniques use nodes

to represent events (beginning and end of

activities) and lines to represent the activities.

A third network scheduling technique is the

Precedence Diagram Method (PDM), which

was developed subsequent to the PERT/

CPM techniques. Its function is to permit a

more accurate depiction of relationships

among various activities than is possible

using the other two techniques. PERT/

CPM techniques are essentially limited to

“finish-start” relationships (i.e., activity B

cannot start until activity A is completed).

The PDM technique can depict other relationships that permit a more accurate and

realistic portrayal of the program’s activities, such as “start-start” (i.e., activity B cannot start until activity A starts). The technique accomplishes this through the use of

nodes to depict activities and lines to depict

relationships. These three techniques are

discussed in greater detail in Chapter 6.

Network scheduling techniques provide

managers with a powerful tool for scheduling and controlling their programs/projects.

In general, they permit the graphic portrayal of project activities and relationships

among the activities. This provides the

basis for determining the project’s critical

path, predicting shortages, and identifying

possible reallocation of resources to solve

problems. Through the use of readily available software, network schedules are fairly

easy to update and rework, thus providing

managers with current program/project status information and control over activities

and schedules.

In spite of the strengths of network scheduling techniques, there are some limitations.

The value of network schedules is directly

dependent on the validity of the time estimates for each activity. In addition, it is

sometimes difficult to accurately portray

all activities and relationships, especially

for very large, complex programs. Thus,

considerable “up front” work is required

to develop an effective network schedule.

Detailed networks, once developed, tend

to be the focus of management attention

when, in fact, there will undoubtedly be

other factors not on the display that will

require management attention.

4.2.3 Production Schedules

Production scheduling involves the planning, execution, and control of repetitive

activities, such as the manufacture of a

large number of identical items. Efficient

production requires the proper balance of

materials, facilities, and personnel skills.

It also requires a means to monitor the

production process.

The Line of Balance (LOB) technique, while

not truly a scheduling tool, is such a monitoring technique that can provide early

warning of potential problems that can

affect program schedule. It is especially

useful for monitoring repetitive processes

where it is essential to balance inventory

acquisition with the production process

and delivery requirements. The LOB technique consists of four elements: (1) objectives of the program, i.e., contract schedule and actual deliveries; (2) production

plan; (3) current program status or inventory; and (4) a comparison between where

the program is and where it’s supposed to

be, (that is, program inventories versus

the LOB). These elements are discussed

in more detail in Chapter 7.

23
The origin of LOB is not clear, but it is

believed it was developed to help manage

defense-related contracts in the 1940s and

50s. It is still used today in both defense and

commercial industry. While government

PMs or their staffs will probably not need to

directly develop or apply the LOB technique, they should understand it and realize that it can be a valuable tool for contractors to monitor the status of production

contracts and to present status information.

This technique can point out problems before their impact on finished product deliveries shows up, thereby allowing managers

to make corrections. It also allows managers to see, in the middle of a contract, whether

they can meet the contract schedule if they

continue working as they have been. Another advantage of LOB is that it focuses

attention on the production activities where

there are problems, thereby facilitating initiation of corrective action.

There are some limitations with the LOB

technique. First, it is best suited for production and/or assembly-type processes that

are stable. The activities that make up the

production plan must be definable and well

understood. Second, while this technique

pinpoints where a problem exists, it cannot

identify the specific problem.

4.3 SUMMARY

Each scheduling method has strengths and

limitations. Program Mangers must be familiar with all of the techniques and choose

the method that allows them to meet their

goals. The choice of schedule type depends

on a number of factors, such as, the purpose

of the schedule, its intended use, and the

decisions to be made from the information

presented. For example, day-to-day management of a project consisting of a number

of related and complex activities may require a schedule that depicts the tasks, their

planned duration, dependencies, progress,

and resources allocated to each of them. If a

PM must do detailed schedule analysis of

this type of project, then the PM will most

likely use a network schedule. This method

is the only way to use probability distributions for time estimates rather than completing an activity and project in a certain time.

On the other hand, the management of a

single activity may require a schedule that

reflects only the time planned for accomplishing the task and the current status.

Schedules showing only events, such as the

completion dates of planned activities, or

bar charts may be sufficient in those cases

when the audience may not be concerned

with the details of the activities.

As a rule of thumb, Gantt and milestone

charts are useful to present information and

summarize program activities. They are

also usually the starting points for detailed

planning and creating a network schedule.

Network schedules are usually created for

detailed planning and analyses. They are

necessary to determine the feasibility of

meeting program goals, assessing risk, and

conducting sensitivity analyses.

24

1

Quentin W. Fleming, John W. Bronn, and Gary C. Humphries, Project and Production Scheduling, Chicago,

IL, Probus Publishing Co., 1987, p. 45.

ENDNOTES
5

GANTT AND MILESTONE CHARTS

25

Planned activity schedule

Status of activity

Forecasted completion behind schedule

Forecasted completion ahead of schedule

Symbol Meaning

Figure 5-1. Example Gantt Chart Symbols

5.1 DESCRIPTION

As discussed in Chapter 4, the Gantt chart

is one of the oldest planning tools in

existence and is still used today at all

levels of project management. For example, PMs use Gantt charts to report

information concerning program activities at milestone decision briefs, while

engineers may use them to manage the

tasks associated with design activities.

Because PMs often use Gantt and milestone charts to report information to review groups, they are treated jointly in

this chapter.

In its simplest form, a Gantt chart is a

schedule that shows the start/stop dates

of a program’s individual activities. It

uses symbols superimposed on a calendar to provide information about the

original plan, the status of the activity,

and any forecasted changes to the plan.

There is no standard set of Gantt chart symbols. Planners should define them and consistently use them throughout the chart. Figure 5-1 shows an example of the symbols that

could be used in Gantt charts.

The schedule is displayed as a series of

horizontal bars representing the duration of

activities. A manager may show actual

progress against the schedule by shading in

each bar as activity progresses or may use a

colored bar that is parallel to the schedule

bar. Figure 5-2 shows a simple Gantt chart

that illustrates activities involved in developing components of a weapons system.

This type of display can be useful for conveying information about the program to those

involved in its review or those charged with

its day-to-day management.

From this example, we can see that as of late

March, the design, fabrication, and assembly

of the payload are ahead of schedule, [A].
Payload Design

Payload Fabrication

Payload Assembly

Test & Rework

Guidance & Control

Design

Guidance & Control

Fabrication

Guidance & Control

Assembly

Guidance & Control

Test & Rework

System Integration

System Test & Rework

Activity J F M A M J J A S O N D

[A]

[A] [B]

[A] [C]

[D] [E]

[E]

Figure 5-2. Example Gantt Chart

Based on this information, and an analysis

of the activities, the PM has revised the

planned completion date for the payload

fabrication, [B]. In analyzing the current

status, the PM has determined that much of

the work in payload assembly will have to

be done toward the end of the planned

activity period. (In other words, the work is

not uniformly distributed throughout the

period.) Thus, even though this activity is

ahead of schedule now, the PM has decided not to revise the planned completion

date for assembly and test, [C]. This Gantt

chart also shows that development of the

guidance and control subsystem is not going as well as planned. As of late-March,

the fabrication is well behind schedule,

[D]. After reviewing the progress and remaining work, the PM has slipped the

planned completion dates for the fabrication and assembly activities, [E]. They believe that it is too early to revise the planned

completion dates for test and rework, and

the system integration and test activities.

However, the slippage already experienced

should serve as a warning that this entire

development effort may be in trouble and

will require close monitoring.

26

Now
While the Gantt chart focuses on activities

and their duration, the milestone chart focuses on planned significant events scheduled to occur at specific times in the program. Such events could be the initiation

or completion of a particularly important

or critical activity, equipment deliveries,

reviews, or approval dates. Like the Gantt

chart, the milestone chart uses symbols

imposed on a calendar to provide information about planned and actual completion

dates and any revisions to the milestone

schedule. There is no standard set of symbols for milestone charts. Figure 5-3 shows

the symbols prescribed for reporting milestone information within the Air Force

Material Command. Different scheduling

software will often use unique symbols.

The important thing is that the symbols be

clearly defined and consistently applied.

Figure 5-4 shows an example milestone

chart for the program described in the Gantt

chart in Figure 5-2. Note that events displayed correspond to the beginning of

some activities and the completion of all of

them. Other events displayed represent

important occurrences and key decision

points within each of the activities, e.g.,

preliminary and critical design reviews,

“make or buy” decision, etc. In this example, we see that as of late-March payload design has progressed on schedule,

[A], and that planned completion date for

fabrication has been revised ahead of the

original schedule, [B]. As discussed in the

Figure 5-3. Example Milestone Chart Symbols

27

Standard symbols have been adapted for Air Force milestone

schedules. The most common symbols used and their meanings are

shown below.

Basic Symbol Meaning

Schedule Completion

Actual Completion

Previous Scheduled Completion—Still in Future

Previous Scheduled Completion—Date Passed

Representative Uses Meaning

Anticipated Slip—Rescheduled Completion

Actual Slip—Rescheduled Completion

Actual Slip—Actual Completion

Actual Completion Ahead of Schedule

Time Span Action

Continuous Action
28

J FMAMJ J ASOND

Payload Design

Begin Payload Design

Payload Preliminary Design Review (PDR)

Payload Critical Design Review (CDR)

Complete Payload Design

Payload Fabrication

Make or Buy Decision

Tooling Complete

Fabrication Complete

Assemble Payload

Begin Assembly

Delivery of Parts Complete

Assembly Complete

Payload Test & Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete

Guidance & Control Design

Begin G&C Design

G&C PDR

G&C CDR

Complete G&C Design

Fabricate G&C

Make or Buy Decision

Tooling Complete

Fabrication Complete

Assemble G&C

Begin Assembly

Delivery of Parts Complete

Assembly Complete

Test and Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete

Integrate Payload and G&C

Begin Integration

Complete Integration

Test & Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete

[A]

[B]

[C]

[D]

[D]

[D]

Figure 5-4. Example Milestone Chart

Now
Figure 5-5. Example Combination Chart

29

J FMAMJ J ASON D

Payload Design

Payload Preliminary Design Review (PDR)

Payload Critical Design Review (CDR)

Complete Payload Design

Payload Fabrication

Make or Buy Decision

Tooling Complete

Fabrication Complete

Assemble Payload

Delivery of Parts Complete

Assembly Complete

Payload Test & Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete

Guidance & Control Design

G&C PDR

G&C CDR

Complete G&C Design

Fabricate G&C

Make or Buy Decision

Tooling Complete

Fabrication Complete

Assemble G&C

Delivery of Parts Complete

Assembly Complete

Test and Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete

System Integration Payload and G&C

Complete Integration

System Test & Rework

Test Plan Complete

Test Readiness Review

Test & Rework Complete
Figure 5-6. Gantt Chart with Amplifying Information

30

Jun ‘99 Jul ‘99

Activity Name Assign- ment

7 14 21 28 5 12 19 26 Budget C

Requirements

Planning

Review existing

systems

Perform work flow

analysis

Model process

Identify user

requirements

Identify

performance

requirement

Identify interface

requirements

Prepare SW

Requirements Spec

Software

Requirements

Review

Mary

James

Mary,

James

Peter

Chris

James,

Peter

All

All

$10,000

$10,000

$12,000

$15,000

$11,000

$15,000

$12,000

$10

$9,0

$12

$17

$9,5

$0

$0
31

As discussed in the Gantt chart example,

there are problems in the fabrication of the

guidance and control subsystem. One of

the events selected as a milestone was the

completion of the tooling necessary for

fabrication. From the example, we see that

this event experienced an actual slip of

approximately one month, [C]; this, in turn,

has caused the Program Manager to revise

the scheduled completion dates for fabrication, parts delivery, and assembly, [D].

Managers rarely use pure Gantt or milestone charts. Normally they integrate the

information from these charts and display

it in a combination chart. Such a chart can

be useful in displaying the planned and

actual duration of activities using the Gantt

chart symbols and in monitoring the

progress for completing key events in these

activities using the milestone symbols. Figure 5-5 is a combination chart showing the

activities and events described in Figures

5-2 and 5-4.

Whereas the simple Gantt, milestone, or

combination charts may be suitable for

reporting program status, most managers

need additional information to plan, monitor, and control activities. New software

applications increase the utility of these

charts by making it easy to add information, such as budget, cost, resources, etc.

Today’s programs use databases to store

related schedule information and then allow users to filter, sort, and display information in a variety of ways. They also

allow users to tailor the software to their

needs by adding customized information

to the database. Figure 5-6 shows how to

display the relationship of one activity with

another by drawing lines between related

activities. The Budget column, in which the

manager enters the budgeted cost for the

activity, is a standard feature of the particular program used to create this Gantt

chart.1 The Assignment, Cost, and Cost/Budget ratio columns are not standard features

but were added to the database to demonstrate how the charts may be customized to

meet individual needs. Note that the user

may create computation fields, such as the

percentage and totals fields shown in the

figure.

5.2 CONSTRUCTING GANTT AND

MILESTONE CHARTS

Gantt and milestone charts are relatively

easy to construct when compared to the

complexity of network charts. The first

step is to decide the level at which the

project is to be planned, tracked, and reported. This decision should consider such

things as the needs of the entire project

team, and the degree of risk associated

with the various program activities. Most

likely there will be a need to manage and

track at a low level and report at a higher

level. Current scheduling software has the

capability to handle activities at various

program levels allowing insight and management at the lower levels and permitting

roll up of information at higher levels for

reporting purposes. To accomplish this,

charts must be developed in a logical and

consistent manner.

The next step in constructing the charts is

the identification of activities and milestones to be displayed, tracked, and monitored. The WBS should be used as the

primary source for this identification. If a

WBS is not available, or if it does not go

down to the necessary level, additional

planning must be done to clearly define

and identify activities to be managed,

tracked, and reported. Other sources for

identifying activities and events include
32

the Acquisition Strategy, the Acquisition

Program Baseline, the Risk Management

Plan, and the Integrated Management Plan,

and the Integrated Management Plan.

5.3 GANTT AND MILESTONE

CHART ADVANTAGES AND

DISADVANTAGES

Gantt and milestone (or combination) charts

provide a simple, effective means to

present project information, and a way to

monitor and control smaller projects. Using these charts as scheduling tools has

many advantages, but also limitations that

should be understood. These pros and

cons are presented below. Evolving scheduling software includes features that overcome some of the shortcomings to varying

degrees.

5.3.1 Advantages

(1) Simple to prepare and update,

(2) Information portrayed in easily understood format,

(3) Relatively inexpensive to prepare

using software tools,

(4) Relate activities and calendar dates,

(5) Easy to roll up information into

summary form,

(6) Useful first step for preparation of

more complex type schedules

(7) Reliable estimates can be developed

when the work is repetitive and when the

product is easy to measure quantitatively.

5.3.2 Disadvantages

(1) Difficult to use for detailed schedule analysis

(2) Do not show the effects of late or

early activity starts

(3) Do not represent dependencies

among activities as well as other scheduling methods

(4) Do not reflect the uncertainty in the

planned activity duration or event date

(5) Only as reliable as the estimates on

which they are based; looking at the chart

doesn’t indicate which estimates are the

most reliable

(6) Do not allow quick or easy exploration of the consequences of alternative actions.

5.4 HOW AND WHEN GANTT AND

MILESTONE CHARTS ARE

EMPLOYED

Gantt and milestone charts are best used

for displaying the planned activities and

events of a project and the progress in

meeting them. This makes them very useful for presenting schedule and program

status information in a concise simple format at such things as programor activity

reviews.

Because of its simplicity and ease of interpretation, it is a particularly good tool for

communicating to higher management

when information must be presented

quickly and efficiently. These charts may
also be sufficient for management and control of simple projects. However, they

have limited utility for managing more

complex projects, since they do not easily

capture interrelationships among activities and events or reflect the uncertainty

associated with time and resource estimates. Generally, they do not provide the

level of information necessary for the effective monitoring and control of such projects.

5.5 SUMMARY

As scheduling tools, Gantt and milestone

charts provide a simple and effective means

for displaying actual versus planned

progress of a program and for showing

schedule changes that have occurred. The

major drawback of Gannt and milestone

charts is the limited degree fo detail and

dependency information they can portray.

However, recently developed software

scheduling applications now make it possible to show more of the relationships

among project activities and events.

33
1

This figure is an adaptation of sample charts from Fast Track Schedule sample charts.

ENDNOTES

34
35

6.1 DESCRIPTION

Driven by the increase in project complexity, managers developed the need for better

schedule and control methods than those

provided by Gantt and milestone charts.

The shortcomings of these charts gave rise to

network scheduling. Over time, different

applications of network theory were developed to address the needs of managers.

Today, essentially three networking techniques are in use: the Program Evaluation

and Review Technique (PERT); the Critical

Path Method (CPM) [these two techniques

are also known as Arrow Diagram Methods

(ADM)] and the Precedence Diagram

Method (PDM). Each is discussed later in

this chapter.

All of these techniques provide the manager

with powerful tools to plan, analyze, monitor, and control the project and to manage

the resources necessary to accomplish project

tasks. They can help the manager answer

the following questions:

• When is each activity or task of the

program scheduled to begin and end?

• Which activities must be finished on

time to avoid missing the scheduled program completion date?

• Can resources be shifted to critical

parts of the program (those that must be

completed on time) from non-critical parts

(those that can be delayed) without affecting the overall scheduled completion date

for the program?

• Among program tasks, where should

management efforts be concentrated at

any particular time?

Networks are a graphical portrayal of the

activities and events of a project. They show

how each activity relates to others in the

project, the sequence of activities, and the

need to perform some tasks before others.

Figure 4-3 is an example of an ADM network

schedule. Networks also facilitate the determination of the impact of early or late starts

or finishes, provide information about the

allocation of resources, and allow managers

to do “what if” analyses. With this information, managers may view the status of the

plan, analyze progress, and evaluate alternatives.

To apply these networking techniques, the

following conditions must exist:

• All program activities must be clearly

defined, including identifiable start and

completion points.

• A logic diagram showing the sequence

and interrelationships of activities must be

developed.

• The time to complete each activity

must be estimated as accurately as possible.

6

NETWORK SCHEDULING
36

Accomplishing these things may require

considerable effort and the involvement of

people familiar with the overall project and

those responsible for executing various

groups of activities. This up-front effort

provides an understanding of project requirements and early identification of potential problem areas.

6.1.1 PERT

In 1958, the U.S. Navy introduced the concept of network scheduling techniques by

developing PERT as a management control

system for the development of the Polaris

missile program. The focus of PERT was to

give managers the means to plan and control processes and activities so the project

could be completed within the specified time

period. The Polaris program involved 250

prime contractors, more than 9,000 subcontractors, and hundreds of thousands of tasks.

PERT was introduced as an event-oriented,

probabilistic technique to increase a PM’s

control in projects where time was the critical factor and time estimates were difficult

to make with confidence. The events used in

this technique represent the start and finish

of the activities. PERT uses three time estimates for each activity: optimistic, pessimistic, and most likely. From these estimates, an expected time is calculated based

on a beta probability distribution for each

activity. The developers of PERT chose the

beta probability distribution because it could

accommodate nonsymmetrical situations.

They assumed that the probability of an

estimate being too optimistic would not be

equal to the probability that the same estimate would be too pessimistic. That is, if

estimated times could be compared against

actual completion times in a number of cases,

the variation would look like the curve in

Figure 6-1.

The expected time, t is the weighted average, or mean time, for an activity based on

the beta distribution and is determined from

the following formula:

Using the expected times and other statistical properties of the beta distribution for

each activity, it is possible to determine an

expected time for completion of the project

and the likelihood (probability) that this expected completion time will be met. It is also

possible to determine the critical path for the

project—the most time-consuming path

through the network activities and events to

project completion. Any delay on this path

will delay the completion of the project.

PERT is most useful when it is difficult to

either accurately estimate the time required

for project activities or to determine the percentage of work accomplished within an

activity. The percentage of work accomplished can be especially important when

analyzing the adequacy of resources applied

to an activity. Projects best suited for PERT

are one-of-a-kind complex programs that

involve new technology or processes and

research and development.

Fllowing the success of the Polaris program,

PERT became widely used throughout the

systems acquisition community, to include

attempts to combine it with cost data or

6

a +4 b m +

t =
37

other non-scheduling aspects of program

management. As a result, PERT became so

cumbersome that the cost of maintaining it

far outweighed the benefit. Consequently,

the use of PERT declined and, by the 1970s,

it was only occasionally employed in defense system programs. Over the last few

years, it has again become relatively popular, particularly in the private sector. This

resurgence is due, in part, to the development of PERT software or other networking

software programs that can be run on microcomputers.

In spite of misuses that have occurred in

PERT applications, the technique can be a

very useful tool because it enables the manager to visualize the entire program, see

interrelationships and dependencies, and

recognize when delays are acceptable. Thus,

the manager is better able to assess problems

as the program evolves.

6.1.2 CPM

The CPM scheduling technique was introduced at approximately the same time as

PERT. It was developed by J. E. Kelly of

Remington-Rand and M. R. Walker of

DuPont to aid in scheduling maintenance

shutdowns in chemical processing plants.

Over the years, CPM has enjoyed more use

than any other network scheduling technique. It is based on the concept of critical

path and was designed to focus on the time

and resources, particularly cost, necessary

to complete the activities of a project.

Although CPM and PERT are conceptually

similar, some significant differences exist,

Figure 6-1. Beta Distribution with PERT Time Estimates

am b

Most

Optimistic

Time

Most

Likely

Time

Most

Pessimistic

Time

Probability

of Meeting

Schedule
38

most as a result of the type of projects best

suited for each technique. As discussed

earlier, PERT is better to use when there is

much uncertainty and when control over

time outweighs control over costs. PERT

handles uncertainty of the time required to

complete an activity by developing three

estimates and then computing an expected

time using the beta distribution. CPM is

better suited for well-defined projects and

activities with little uncertainty, where accurate time and resource estimates can be

made, and the percentage of completion of

an activity can be determined. In CPM,

because of the greater certainty, a single

time estimate is used. This estimate is the

time planned for the activity under normal

conditions; it approximates the most likely

time estimate in PERT. The normal cost

estimate is the cost associated with finishing

the program in the normal time. A second

time and cost estimate, the crash estimate, is

also used in the CPM technique. The crash

time estimate is the time that will be required to finish an activity if a special effort

is made to reduce program time; crash cost

is the cost associated with performing the

effort on a crash basis so as to reduce the time

to completion. This is discussed in more

detail with a later example.

CPM is activity-oriented, concentrating on

activity start (early start, late start) and finish times (early finish, late finish); whereas

PERT is event-oriented, concentrating on

early event time and late event time. The

network diagrams used for CPM and PERT

are essentially the same (see Figure 4-3), as

are the procedures for using them. As discussed earlier, certain actions are essential to

applying network scheduling techniques.

The activities/events composing the project,

the relationships among them, and their time

estimates must be identified, and a network

diagram developed. Once the diagram is

completed, the following procedures are

applied:

• Complete and annotate the cumulative time required to reach each node along

the paths—This will indicate the earliest

time work can start on the next activity. The

final number will indicate total time required

to complete a particular path.

• Identify the critical path—This is the

sequence of events, or route, taking the longest time to complete.

• Starting at the program completion

node on the right side of the diagram, begin

working backward and compute the latest

time an activity can start without delaying

the overall program—For example, if the

total program takes 40 weeks and the final

activity requires 5 weeks, this activity cannot begin later than week 35. For CPM, the

difference between the latest and earliest

start of an activity is the slack or float. The

critical path contains no slack or float time.

For PERT, the difference between the earliest event time and the latest event time at

each event is the slack/float time.

The use of these procedures is illustrated in

a later example.

6.1.3 PDM

PDM is an activity-oriented technique that

was developed subsequent to PERT and

CPM. The impetus behind this development was the need for greater flexibility in

dealing with relationships and constraints

between project activities.

PERT/CPM, or the arrow diagram method

(ADM), essentially treats all relationships as

“finish-to-start” constraints; that is, Activity

A must be completed before Activity B can
39

begin. There are ways within PERT/CPM to

circumvent this limitation, but they are cumbersome and add more complexity to the

technique.

The PDM technique provides the capability

to treat other types of relationships that occur in complex projects. Figure 6-2 shows

examples of these types of relationships or

constraints.

In addition to depicting different relationships between activities, PDM also

handles time lags that would normally occur as the project progresses. Examples of

such lags are the time required for the movement of parts or components from one activity site to another, or the time involved in

the reallocation of resources—people, equipment, and facilities. Figure 6-3 shows examples of constraint lags and how they can

be depicted. These lags could be represented as activities in the ADM technique,

but this could add needless complexity to

the schedule. The use of lags in the PDM

technique is much less complicated.

PDM uses the same underlying principles as

the other networking techniques: clearly

defined activities, accurate time estimates,

Figure 6-2. Example PDM Relationships/Constraints

Finish-to-Start

B cannot start until A is finished—

normal PERT/CPM constraint

Finish-to-Finish

B cannot finish until A is finished

A

B

A

B

A

B

70%

40%

Symbols Constraint

Start-to-Start

B cannot start until A starts

Start-to-Finish

B cannot finish until A is started

(Rarely used)

Percent Complete

Remaining 40% of B cannot be

started until 70% of A is completed

A B

A

B
40

critical path, etc. The difference between

PERT/CPM (ADM) and PDM is in the way

the network is portrayed. In PERT/CPM,

the network nodes represent the events associated with activities (i.e., the beginning

and end of activities), and the connecting

lines represent the activities and the relationship/constraints. Activity time and resource estimates are normally shown on the

 lines. In PDM, the nodes represent the

estimates, early and late start and finish

dates, and other appropriate information

are normally shown in the boxes. Figure 6-

4 is an example of an activity node. The lines

connecting the nodes represent the relationships between the activities, e.g., finish-tostart, start-to-start, etc. The use of PDM is

demonstrated in a later example.

Figure 6-3. Example PDM Constraints with Lag Time

Resource

Requirements

Duration

3 Days

Early Start Time

7/12/99

Early Finish Time

7/15/99

Late Start Time

7/14/99

Late Finish Time

7/17/99

Activity Identification

Information

Finish-to-Start with Lag

B cannot start until 5 days after A

is completed

Start-to-Start with Lag

B cannot start until 7

days after A has started

A B

A

B

Symbols Constraint

Finish-to-Start with Negative Lag

B cannot start until 5 days before A

is completed

A B

Lag + 7 days

Lag - 5 days

Lag + 5 days

Figure 6-4. Example PDM Activity Node
41

• Show resources associated with activities and time.

6.2.2 DISADVANTAGES

• Network construction can be difficult and time consuming.

• Only as sound as the activity time

and resource estimates.

• Sometimes difficult to portray

graphically—too many lines, nodes and

intersections.

• Not particularly good for conveying

information in briefings/reviews.

• Complex networks, once sketched out

on a large wall chart, tend to become the

focus of management attention when, in

fact, a manager should be paying attention

to factors not on the chart, such as management/labor relations.

6.3 HOW AND WHEN NETWORK

SCHEDULES ARE EMPLOYED

Network scheduling techniques can be very

useful in complex projects that involve new

technologies or processes and that are not

repetitive, such as production. They are not

particularly easy to use for presentations

because of their complexity; however, they

can be used as the basis for other scheduling

techniques that are more suitable for presentation of information, i.e., Gantt or milestone charts.

Government managers may not use network techniques in the day-to-day management of their programs. However, they

should have an understanding of the techniques to ensure that contractors are using

them when appropriate.

6.2 NETWORK SCHEDULING

ADVANTAGES AND

DISADVANTAGES

Network scheduling techniques provide the

mechanisms necessary to conduct a systematic, disciplined, and thorough review of

what will be required to conduct and complete a project. Such an approach is essential

for large, complex projects and is also useful

in managing smaller, less complicated

projects. The advantages and disadvantages

of these techniques are identified below.

6.2.1 ADVANTAGES

• Provide graphical portrayal of project activities and relationships/constraints

• Force communications among team

members in identifying activities

• Organize what would otherwise be

confusing material, making it easier for managers to make tradeoffs and develop alternative plans

• Provide capabilities to evaluate

progress and control project

• Allow managers to predict shortages

and act on them early

• Once prepared, permit easy update

and rework

• Give managers more control over

activities/events and schedules

• Facilitate “what if” exercises

• Provide the basis for Gantt and

milestone chart information
42

The different types of network scheduling

techniques have many similarities. However, each of them provides different types

of information that can be useful to managers in evaluating progress, developing

alternatives, and managing the allocation of

resources within their projects. The following examples show the types of information

resulting from each technique and how managers may use them.

6.3.1 PERT EXAMPLE

Figure 6-5 shows a PERT network for a

project containing 8 activities (A-H), with

the nodes 1-7 representing the beginning

and end of the activities. The three time

estimates discussed earlier in this chapter

are shown for each activity. For example, for

Activity A, the time estimates are optimistic

time=1 week, most likely time=2 weeks, and

pessimistic time=3 weeks. The expected

time estimate for each activity, t, as derived

from the formula associated with Figure 6-1,

is also shown. From this information, the

project critical path can be computed by

adding the time estimates along all paths

leading to project completion. In this example, the critical path is determined as

follows:

Path A-B-E-H=2+3+2+4=11 weeks

Path A-C-F-H=2+4+3+4=13 weeks

Path A-D-G-H=2+8+9+4=23 weeks

Thus, path A-D-G-H is the critical path

since it requires the greatest time. Any

delay along this path will cause a delay in

project completion. The other paths are

shorter completion. The other paths are

shorter than the critical path and, therefore,

contain activities that can be completed before they are required. Therefore, delays

along these paths may not result in delays in

project completion. In the above example,

critical path activities, D and G, will require

17 weeks to complete. On path A-B-E-H,

activities B and E will require 5 weeks to

complete. Thus, there will be 12 weeks of

slack along that path. Actually, this slack is

only along path B, E since A and H are on the

critical path. Likewise path C-F has 10 weeks

of slack time. This concept of slack time,

sometimes called float time or path slack/

float, is important because it allows managers to reschedule activities not on the critical

path to use resources efficiently.

1

3

A

B

C

D

E

F

G

H 2 6

5

4 7 (1, 2, 3)

t=2

(2, 3, 4)

t=3

(2, 3, 4)

t=3

(1, 2, 3)

t=2

(3, 4, 5)

t=4

(3, 4, 5)

t=4

(8, 9, 10)

t=9

(7, 8, 9)

t=8

Figure 6-5. PERT Example
43

Figure 6-6. PERT Example with Slack Time

The following description of how slack time

is computed is intended to illustrate the

concept that managers can use it to their

advantage. Fortunately, software programs

compute slack time and managers do not

have to make these calculations.

Slack time should be computed for each

activity in the network. One way of doing

this is by comparing the earliest time an

activity can begin, TE, to the latest time the

activity can begin, TL. The difference is the

activity slack time. For all activities on the

critical path, TE and TL have the same value.

To determine the values of TE and TL for each

activity, start with the node representing the

beginning of the first activity and assign it a

value of TE=TL=0. Follow the critical path

and add the activity time estimate to the

value of TE of the preceding node to get the

value of TE for the next node. For example,

the node at the completion of Activity A and

the beginning of Activity D has a value of

TE=TL=2. Figure 6-6 shows how TE and TL

can be depicted on a network chart. Continue along the critical path to node 7, which

has a value of TE=TL=23, the time required to

complete the project. Next, compute the

values for TE for the remaining activities and

nodes not on the critical path. The value of

TE for node 3 is the value of TE from node 2

(TE=2) plus the duration of Activity B; for

node 3, TE=5.

To determine the latest starting times for

each activity, begin at the completion of the

project and work backward through the activities. Since Activity H is on the critical

path, its value of TL=19. Activity E is not on

the critical path so its value of TL (shown on

node 3) is the difference between TL at node

6 and the time estimate for Activity E, TL=19-

2=17. The activity slack is the difference

between TE and TL at each node. For Activity

E, the slack is TL-TE=17-5=12 weeks. This

activity could start anytime between weeks

5 and 17 without any adverse impact on the

critical path. Activity B is not on the critical

path so its value of TL is the difference between TL at node 3 and the time estimate for

Activity B (17-3=14). This is not shown at

node 2, since that node also represents the

start of Activity D, which is on the critical

path. The slack for Activity B is TL-TE=14-

2=12. (The same approach is used to determine the slack for Activity C.) Slack is not

additive along a path; it must be shared by

all activities on the path. Thus, if Activity B

starts at week 5 instead of week 2, Activity E

would have only 9 weeks of slack available.

1

3

A

B

C

D

E

F

G

H 2 6

5

4 7 (1, 2, 3)

t=2

(2, 3, 4)

t=3

(2, 3, 4)

t=3

(1, 2, 3)

t=2

(3, 4, 5)

t=4

(3, 4, 5)

t=4

(8, 9, 10)

t=9

(7, 8, 9)

t=8

TE=0

TL=0

TE=5

TL=17

TE=2

TL=2

TE=6

TL=16

TE=10

TL=10

TE=19

TL=19

TE=23

TL=23
44

Similarly, Activities C and F have a slack of

10 weeks.

The concept of slack and TE and TL can be

very useful to managers, providing the basis

for resource allocation and also providing

the means to determine the probability of

meeting the project schedule. This latter

topic is beyond the intended scope of this

guidebook; however, a number of available

books provide detailed discussion of the

application of PERT techniques. (See the

bibliography in Appendix D.)

6.3.2 CPM EXAMPLE

As discussed earlier, PERT and CPM are

conceptually similar, in that both techniques

use the same type of network structure, and

the concepts of critical path and slack time.

The following example will be used to illustrate basic application of the CPM technique.

Figure 6-7 shows the same project as used in

the PERT example, with the single time estimates for each activity. Table 6-1 shows the

time and crash estimates for each of the

activities.

The critical path for the CPM approach is

determined in the same way as in the PERT

example. While the concept of slack time

is essentially the same as in PERT, it is normally calculated in a different manner using

four different values for each activity:

• Earliest time the activity can start, ES

• Earliest time the activity can finish, EF

• Latest time an activity can start, LS

• Latest time an activity can finish, LF.

To compute ES, start at the first activity and

move forward through the network paths.

The earliest Activity A can start is at t=0.

The earliest that it can finish is ES plus the

activity duration; thus for A, ES=0 and EF=2.

The earliest start for subsequent activities is

the EF of the preceding activity. For Activity

Figure 6-7 CPM Examples

1

3

2 6

5

4 7 A (ES=0, EF=2)

2 (LS=0, LF=2)

B (2, 5)

3 (14, 17)

F (6, 9)

3 (16, 19)

E (

2 (17, 19)

5, 7)

C (2, 6)

4 (12, 16)

H (19, 23)

4 (19, 23)

G (10, 19)

9 (10, 19)

D (2, 10)

8 (2, 10)
45

B, ES=2. The earliest finish time for each

activity is the earliest start time plus the activity duration. For Activity B this is EF=2+3=5.

When activities converge, such as E, F, and G

at node 6, the earliest starting time for the next

activity is the latest value of EF of the preceding converging activities.

To compute the latest times, make a backward pass through the network, beginning

with the last activity. The date to begin the

pass can be either an established required

date or the early finish date for the project

completion. The latest starting date for the

final activity is determined by subtracting the

activity duration from the date used to begin

the pass. For subsequent activities, the latest

finish date is the same as the latest starting

date for the preceding activity. In the backward pass, the value of LF for an activity that

precedes a set of diverging activities in the

network (activity A in the example) is the

earliest of the values of LS of the diverging

activities (B, C, D).

The values of ES, EF, LS, and LF for all activities are shown in Figure 6-7. With this information, one can determine the slack for each

activity. Slack is determined using the following formula: Slack=LF-EF=LS-ES.

The relative certainty of time and resource

estimates enables managers to determine the

percent of work completed in each activity as

the project progresses. Being able to estimate

the percent of completion provides managers with the means to redistribute resources if

an activity is falling behind schedule. For

example, if an activity has fallen behind schedule, it is possible to estimate the work remaining and the cost of applying additional resources to complete the activity on schedule.

Network scheduling techniques, particularly

CPM, used on projects with relatively certain time and cost estimates can provide

managers with information to effectively

manage their projects. Using percent of

work completed or that is remaining on

ongoing activities, they can compare the

progress at a certain time with the original

plan. Based on this information, they can

develop revised time and cost estimates for

these activities and forecast new start and

completion dates for remaining activities

and a new project completion date. They

can then use the new forecast dates to determine action that can be taken and the appropriate resource planning and reallocation, if

necessary.

The CPM technique provides managers with

the means to investigate ways and impacts

of speeding up, or crashing, the schedule.

As part of the planning process, a set of crash

estimates should be developed if possible.

The estimates for this example are shown in

Table 6-1.

This table shows the time and cost estimates

and the crash cost per week. To crash a

schedule, some key points must be considered:

• Crash only along the critical path.

• When an activity is shortened, one or

more new critical paths may emerge.

• Parallel critical paths increase risk

dramatically.

• Generally, least additional cost is the

criterion used to select which activity to

crash, but other considerations (e.g., personnel hours) could be used.

In this example, assume that the project must

be crashed by 4 weeks at the least additional

cost. Looking at the activities on the critical

path, select the one with the lowest weekly
46

crash cost; in this case it is Activity D, which

can be crashed from 8 to 6 weeks for an

additional $6,000. Next, crash Activity G by

2 weeks at a cost of $10,000. Reducing both

of these activities does not change the critical path.

6.3.3 PDM EXAMPLE

The PDM technique focuses on program

activities and the meaning of the constraints

among activities. This technique is used in

many scheduling software applications, and

it relies on the same concepts—critical path,

slack time, etc., as the other network scheduling techniques.

Figure 6-8 shows a PDM network for a project

with Activities A–I. (Assume that the unit of

working time (duration) is one week.) Note

that Activity B cannot start until Activity A

starts, and Activity D cannot end until Activity C ends. The critical path is determined

in essentially the same way as in other networks. In PDM, however, one must account

for the different types of constraints. In this

example, Activities B (duration=4) and D

(duration=2) will require 6 weeks to complete. However, Activity D can not be completed until Activity C is finished, which is 9

weeks (5 weeks for Activity A and 4 weeks

for C). The difference between the 9 and 6

weeks (i.e. 3 weeks) must be added to the

time to complete Activity D when determining the critical path. This is shown below in

the parenthetical term for Path B-D-G-I. The

critical path for this example is determined

as follows:

Path A – C – F – I = 5 + 4 + 5 + 3 = 17 weeks

Path B–D–G–I = 4+(2+3)+2+3 = 14 weeks

Path B–E–H–I = 4+5+2+3 = 14 weeks

Thus, Path A-C-F-I is the critical path.

The slack times for the activities are determined in the same way as in the CPM technique, using earliest and latest start and

finish times, ES, EF, LS, LF. Earliest times are

computed by making a forward pass through

the networks paths, and latest times are

determined making a backward pass. FigTable 6.1 "Crashing" the Network

A

B

C

D

E

F

G

H

2

3

4

8

2

3

9

4

3 5

Yes

N o

N o

Yes

N o

N o

Yes

Yes

$4,000

$2,000

$3,000

$5,000

$1,500

$2,500

$20,000

$8,500

$6,000

$600

$400

$3,000

$700

$650

$5,000

$6,000

2

3

2

6

2

3

7

3

1st

(-2 days x

$3,000 per day)

=$6,000

2d (-2 days x

$5,000 per day)

= $10,000

Note: Example same as Figure 6-7

Time

Per

Activity

(wks)

Activity

Number

Critical

Path

Cost ($)

Per

Activity/wk

Crash

Estimates

(Accelerated

add'l

cost/week)

Min

time reqd

per Activity 

Crash

Priority
47

ure 6-9 shows the PDM network with these

values, using the activity format shown in

Figure 6-4. The values of ES, EF, LS, and LF

in Figure 6-9 represent the beginning of the

unit of work time, in this case a week; e.g., ES

for Activity A is the beginning of week 1,

while EF is the beginning of week 6. (The

beginning of week 6 corresponds to the end

of week 5.) The earliest and latest finish

dates for this project , Activity I, is the beginning of week 18, or the end of week 17. Using

the formula for slack,

Slack = LS – ES = LF – EF,

we see that on path B – D – G – I, activities B,

D, and G each have a slack of 3 weeks. This

slack is not additive; if Activity D starts at

week 9 vice week 8, then Activity G has only

2 weeks of slack remaining. We also see that

Activities B, E, and H have 3 weeks of slack

Figure 6-8. PDM Example

A

5

B

4

C

4

F

5

D

2

G

2

I

3

E

5

H

2

on their path. If Activity B uses 3 weeks of

slack, none will be left for either path.

The above example assumes that progressing from one activity to the next requires

zero time, which in most projects is unrealistic. The concept of lag time can be used to

incorporate the time required to transition

from one activity to another, such as machine set-up time or movement of material,

parts, or components from one site to another. Lag time can be shown on the network and must be accounted for in determining critical path and values of ES, EF, LS

and LF. Figure 6-10 shows that in moving

from Activity D to Activity G, there will be a

lag of 1 week. The figure also shows the

effect of this lag time on the earliest and

latest start times and on finish times. The

resulting slack for Activities D and G is now

2 weeks. This example shows that the PDM
48

Figure 6-9. PDM Example—Early and Late Start and Finish Times

Figure 6-10. PDM Example with Lag Time

A

5

B

4

C

4

F

5

D

2

G

2

I

3

E

5

H

2

1 6 6 10 10 15

1 6

1 5

6 10

4 8

8 10

11 13

5 10

8 13 13 15

10 12

13 15

10 12

10 15

15 18

15 18 Duration

LS LF

ES EF

Legend

A

5

B

4

C

4

F

5

D

2

G

2

I

3

E

5

H

2

1 6 6 10 10 15

1 6

1 5

6 10

4 8

8 10

10 12

5 10

8 13 13 15

10 12

13 15

11 13

10 15

15 18

15 18 Duration

LS LF

ES EF

Legend

LAG+1

FOOTNOTES

Note: The numbering convention used in this PDM network is similar to the CPM network in Figure 6-7; it is

described on page 46. Each computer scheduling program uses one (or gives a choice) of methods to relate

duration to the time unit.
49

technique provides considerably greater flexibility in handling different types of constraints than does ADM (PERT and CPM).

Consequently, it is better suited for use in

complex projects, particularly those with

many parallel activities and constraints other

than finish-to-start.

6.4 NETWORK SCHEDULING WHEN

RESOURCES ARE LIMITED

In the previous discussion, the assumption

was that a new activity could start as soon as

any constraints were satisfied because sufficient resources were available to perform

the work. In practice, however, resources to

proceed are not always available.

In those situations, Program Managers can

take one or more different actions to reduce

the adverse impact on the program. Those

actions include:

• Adding additional resources

• Reducing the scope of the program

• Adjusting the schedule to accommodate the resource shortfall

In this section, we show how network schedules and the concepts of critical path and

slack (float) can be applied to make better

use of limited resources. Figure 6-11 shows

a PDM network with activities A through J.

Each node of the network shows the number

of people required to complete the activity

along with the activity duration (in weeks)

and earliest and latest start and finish times,

represented as the beginning of the unit of

work time (week).

To determine the adequacy of resources

(people in this example), assume that each

activity will start as early as possible and

determine the resource requirements over

time. Figure 6-12 shows the personnel loading requirements by time for the duration of

the program. During week one, 11 people

are required to work on activities A, B, and

C. Now, let’s suppose only nine people

are available to work during this 11 week

period. The chart shows there will not be

sufficient workers during the first, fourth,

and fifth weeks. There will be sufficient

workers to perform the work

scheduledduring the second and sixth week.

During the third and seventh throughout

eleventh weeks, there will be a surplus of

workers for the work scheduled. The task

becomes one of rearranging the schedule so

that, insofar as possible, the peaks and valleys are evened out without scheduling more

work than nine people can do. In this example, this rearrangement can be accomplished quickly by hand. However, with

many activities, it becomes very difficult to

find the optimum answer. Fortunately,

scheduling software applications are available to assist in solving the problem. Regardless of the approach used (manual or

automated), the resource-leveling process is

an iterative step-by-step process using a set

of rules to establish the priority of the activities requiring the constrained resource, and

the actions to be taken.
50

Figure 6-12. Personnel Loading Chart

Figure 6-11. Network Schedule with Constrained Resources

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Time (Weeks)

People Required

1 2 3 4 5 6 7 8 9 10 11

A

B

C

A

B B

D

E

G

I I

H

E F

H

FFF J

Personnel Shortage

Personnel Available

Personnel

Surplus

J

A

2

1 3

8 10

C

1

1 2

9 10

B

3

1 4

1 4

D

1

4 5

9 10

I

2

4 6

8 10

F

4

6 10

6 10

G

1

7 8

4 5

E

2

4 6

4 6

J

10 12

10 12

3

People

2

6

3

4

5

H

2

8 10

5 7

4

6

2

2

4
51

As discussed earlier, the concept of float (or

slack) can be useful in the efficient allocation

of resources, and it should be considered in

establishing the rules to be followed. The

float demonstrated in earlier examples is

commonly called path float. Another type

of float that is particularly useful in resource

allocation is free float. Free float is the slack

that a single activity can experience without

affecting any other activity.1

 The free float of

a given activity is defined as the difference

between earliest start of the succeeding activity and earliest finish of the given activity.

In our example, the free float for Activity D

is FF(D)=ES(J)-EF(D)10-5=5.

In this example, the approach is to find

activities having the most free float and try

to delay them as long as possible without

delaying the entire program. By delaying

the start of Activity C for 2 weeks (to the

beginning of week 3), Activities A and B can

begin simultaneously without exceeding the

limit of nine workers. Similarly, Activities

D, H, and I can be delayed, resulting in the

revised personnel loading chart shown in

Figure 6-13.

Figure 6-14 shows the revised schedule using lag times to reflect the delays. Note that

Activity A has a start-start relationship with

Activity B. The “Lag 0” constraint indicates

that A should start when B starts. Any delay

in starting Activity A will result in a personnel shortage as the project progresses. It may

not always be possible to rearrange the schedule to stay within the resource constraints.

In those cases, other steps, such as adding

more resources or extending the schedule,

will have to be taken to minimize the adverse impact on the program.

6.5 SUMMARY

Network scheduling techniques (PERT,

CPM, and PDM) are much alike in providing such things as interdependencies, depth

of detail, a critical path, and slack. The

choice among these three techniques depends primarily on the type of program and

managerial objectives. The PERT method is

particularly useful if there is considerable

uncertainty in program activity times and if

control of the program schedule outweighs

other factors. On the other hand, CPM is

more appropriate when activity times can

be adjusted readily and when it is important

to plan an appropriate tradeoff between program time and cost. The PDM technique is

best suited for complex projects with different types of relationships/constraints between activities. In reality, the proliferation

of scheduling software has blurred many of

the differences among network scheduling

techniques as well as Gantt and milestone

techniques.
52

6-14. Revised Network Schedule with Constrained Resources

Figure 6-13. Revised Personnel Loading Chart

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Time (Weeks)

People Required

1 2 3 4 5 6 7 8 9 10 11

A

B

C A

B B

D G

E E

H I

FFFFJ

H I

J

A

2

1 3

8 10

C

1

3 4

9 10

B

3

1 4

1 4

D

1

5 6

9 10

I

2

8 10

8 10

F

4

6 10

6 10

G

1

6 7

4 5

E

2

4 6

4 6

J

10 12

10 12

3

People

2

6

3

4

5

H

2

8 10

6 8

4

6

2

2

4

Lag+1

Lag+4

Lag+1

Lag+2

Lag 0
53

1 Fleming, Bonn, and Humphreys, Project and Production Scheduling, Probus Publishing Co.,

Chicago, IL, 1987, Chapter 8.

ENDNOTES
53

7

PRODUCTION SCHEDULING

7.1 DESCRIPTION

The scheduling techniques discussed in

the previous chapters are best suited for

one-time development projects. Production scheduling, as its name implies, focuses on the planning, execution, and control of repetitive activities, such as those

involved in the manufacture of several identical items using the same processes. The

objective of production scheduling is to

balance the materials required to produce

the items with the production process and

the delivery schedule. Such scheduling is

essential to the efficient use of all resources

and facilities involved in the manufacturing process.

While the principles of planning and scheduling are essentially the same for both situations, there are differences that should be

considered. For example, in the development phase, planning and scheduling

should reflect the uncertainty inherent in

development of the product and processes

used. Consequently, planning and scheduling should permit sufficient flexibility to

allow for redesign and retest when inevitable problems arise. In production, there

is less uncertainty; the design is relatively

stable and the processes to be used are

fairly well-defined. In general, more definitive constraints exist in production

scheduling, such as quantities to be produced, required delivery dates, and capabilities and availability of production

assets.

Production planning and scheduling

should be very detailed. A top-level project

schedule should serve as the production

baseline. It should reflect the integration of

activities that different organizations involved in the production process conduct—

tooling, material procurement, etc. Lower

tier schedules should be developed for

each of the manufacturing activities, with

special attention to those having potential

impact on the delivery schedule, e.g., material procurement; tool design, fabrication, and prove-out; test equipment proveout; and capital equipment procurement.

Thorough planning and integration of all

production process activities are essential

to manage risk in the manufacturing approach. This also provides assurance that

necessary resources will be available when

needed, that no resources will be overloaded or completely expended during

execution of any manufacturing task, and

that product delivery dates are achievable.

An understanding of the production processes, to include such things as the sequence of operations, make or buy decisions, inspection methods, tooling, etc., is

critical to effective production planning

and scheduling. The planning and scheduling of all activities must be fully integrated and reflect a synchronized flow of

events that result in product or process

completion when required. The production schedule describing and integrating

such things as the acquisition of required

materials, fabrication flow, process times,
54

plant facilities to be used, and personnel

skills required should be developed as

early as possible in the development process and included in the manufacturing

plan.

Once the planning and scheduling are complete and production begins, managers

need the means to monitor progress and to

identify problem areas in the process that

could adversely affect the delivery schedule. A technique that is commonly used for

this purpose is the Line of Balance (LOB)

technique. It graphically portrays the key

activities of the production plan relative to

a required delivery schedule and provides

a view of the progress being made in each

activity. This enables managers to focus

their attention on specific problem areas in

the process.

Government PMs, except those associated

with an activity that builds or re-builds

equipment, will never be responsible for

developing a production schedule. However, they should understand the process

of creating one because the success of a

program is very dependent upon the producer to plan, schedule, and implement a

production plan.

The ensuing discussion provides a basis

for understanding the fundamentals of

production planning and monitoring. Most

companies have tailored planning software

programs to fit their needs, however the

principles are the same as those used in the

LOB approach. For that reason, LOB is the

subject of discussion.

The LOB technique consists of four elements as described below and shown in

Figure 7-1. The application and use of this

technique is demonstrated in a later section of this chapter.

7.1.1 Objective Chart

An Objective Chart (Figure 7-1A) is a display of the cumulative contract delivery

schedule over time. It shows cumulative

units on the vertical scale and dates of

delivery along the horizontal scale. It also

shows actual cumulative deliveries to date.

7.1.2 Production Plan Chart

This chart (Figure 7-1B) shows the major

production process activities and events

(control points) that are to be monitored

using this technique. It also shows the leadtime associated with each of the control

points.

The more steps that are monitored, the more

sensitive and more complicated the chart

becomes. Generally, control points on a

single chart should be limited to 50. If there

are more than 50, subsidiary production

plans can be used to feed the top plan. Thus,

each chart can be kept simple and easy to

understand. The shipping date of subsidiary charts is the point at which a subprogram must be ready to join the overall

schedule.

On the production plan chart, each monitored step is numbered, left to right. Step 1

has the longest lead time; the shipping date

is the highest-numbered step. When two

steps are done at the same time, they are

numbered from top to bottom, such as steps

8, 9, and 10. These control points can also be

given symbols that show whether they involve purchased items, subcontracted parts,

or parts and assemblies produced in-house.

Assemblies break down into subassemblies,

which break down into parts or operations.

Thus, one can develop a production plan

for any part or level of assembly.
Figure 7-1. Line of Balance Technique

55
The production plan chart shows the

interrelationships and the sequence of

major steps, as well as lead times required

for each step. An understanding of the

manufacturing processes involved and

sound judgment are required to know

which step and how many steps must be

monitored. Slack or float times for activities are not considered when plotting the

production/lead-time chart; only the estimated time (and latest finish point) for

each activity is used.

The 12 control points in the production

plan chart shown in Figure 7-1B represent

key tasks in manufacturing one lot of missiles. The plan indicates that control point

(1), fabricate ballistics shell, must begin 24

workdays before 1 January to meet the first

scheduled delivery of five units by the end

of December (see the objective chart). The

lead time for other control points can be

related to the scheduled delivery in a similar manner. Time for in-house transfer and

storage must be allowed in addition to the

processing time.

7.1.3 Program Status Chart

This chart (Figure 7-1C) shows the cumulative inventory status at each control point in

the process at a given time (in this case, 1

May). Looking at control point 12, we see

that the government has accepted 14 units of

the product. The bar for control point 9 shows

that 40 units of the guidance section have

been assembled, and the bar for control point

4 shows that in-house fabrication has begun

on 60 fins.

The cumulative numbers of units through

every control point can and should be measured monthly. Final deliveries (government

acceptances) are shown month-by-month on

the objective chart as actual deliveries.

7.1.4 Line of Balance

The LOB represents the number of units that

should have passed through each control

point (cumulatively) to satisfy the contract

delivery schedule. Managers use it to analyze how the status of each control point on a

given date will affect future schedules. This

LOB is drawn on the Program Status Chart

(Figure 7-1C) using the following procedures:

(1) Select a control point; for example, 7.

(2) From the production plan/lead-time

chart (Figure 7-1B), determine the lead time—

the time from control point 7 to the shipment

point, Government Acceptance (12

workdays).

(3) Using this number, determine the date

that the unit now at control point 7 should be

completed. (May 1 + 12 workdays = just over

halfway through a 22-workday month.)

(4) Find the point corresponding to this

date, approximately May 17, on the contract

schedule line and determine how many units

scheduled for completion this represents by

moving horizontally from the objective chart

to the program status chart (they share the

same vertical scale).

(5) Draw a line on the program status

chart (Figure 7-1C) at the level (43 units) over

control point 7.

(6) Repeat the above for each control

point and connect the horizontal lines over

the control points. The resulting line is the

LOB, indicating the quantities of (1) units

that should have passed through each control point on the date of the study or inventory (1 May) if the contract delivery schedule

were being met.

56
57

The difference between the LOB and the

top of the bar for each control point is the

number of units behind or ahead of schedule as of 1 May. Thus, control point 12 is 16

units behind schedule, control point 9 is 5

units ahead of schedule, and control point

7 is 21 units behind schedule. The main

impact of control point 7 being behind

schedule will be felt in 12 workdays, which

is the lead time for control point 7. As of 1

April, an insufficient number of air vehicle

components (shell, fins, engine) had passed

into the assembly (air vehicle body) phase.

This will adversely affect final deliveries

12 workdays hence. All other control points

can be analyzed in the same way.

7.2 WHEN AND HOW TO USE THE

 LINE OF BALANCE TECHNIQUES

7.2.1 General

The LOB technique should be considered

for use in any project requiring the manufacture of a specific quantity of a product

using repetitive processes. It is an effective

technique for identifying those activities

that require attention and possibly corrective action and can also be used for reporting the status of the manufacturing process

and delivery schedule to higher management. The LOB charts should be updated

on a periodic basis (weekly or monthly,

depending on such factors as the size of the

production run, the number of activities/

control points, and the level of automated

data management).

Government managers will probably not

be involved with the LOB technique in the

day-to-day management of their programs.

However, they should have a basic understanding of the technique, the type of information it can convey, and its applicability.

7.2.2 Analysis

Using the LOB charts in Figure 7-1, management can tell at a glance how actual

progress compares with planned progress.

Analysis of the charts can pinpoint problem areas. Delays at control point 7 in the

example may have been causing final delivery problems throughout the contract.

However, the purpose of LOB analysis is

not to show what caused the slippage in

the shipping date, but to detect potential

future problems.

In the example, the Government acceptance point is control point 12. The bar

doesn’t reach the LOB; therefore, deliveries are behind schedule. Control points 10

and 11 are short. However, point 9 is on

schedule. Since point 10 depends on points

8 and 9, we know control point 8 is the

offender. Both points 7 and 8 are short, but

there are more than enough purchased

items (engines) at control point 6.

What’s the problem with control point 8?

Trace it back to control point 7, which is

seriously short. It is obvious that not having enough completed fins is holding up

the whole process. Control points 2, 3 and

5 are short, but are not directly responsible

for the failure to meet the delivery schedule since 9 is ahead of schedule. Nevertheless shortages at 2, 3, and 5 could soon

cause problems at 9. The problem with the

fins 7 should be addressed before management attention is devoted to other short

operations. The overages at control points

1 and 6 may be examined from the point of

view of inventory control. Updating the

charts requires a good status-reporting system, which can be mechanized if the program is large and complex.
58

7.3 LINE OF BALANCE ADVANTAGES

 AND DISADVANTAGES

7.3.1 Advantages

(1) Points out problems before their

impact on finished product deliveries show

up, thereby allowing managers to correct

problems earlier.

(2) Allows managers to see, in the

middle of a contract, whether they can meet

the contract schedule if they continue working as they have been.

(3) Focuses attention on those production control points where there are problems; this allows a senior manager to pinpoint responsibility for slippages.

7.3.2 Disadvantages

(1) People working on a project may

not grasp what the LOB is measuring.

(2) Limited to production and/or

assembly-type processes.

(3) Shows only where the problem is,

not what it is.

(4) A monitoring device; not as easy

to use as a planning device.

7.4 SUMMARY

The LOB is a monitoring technique that

gives prior warning of problems within a

continuous production process. The key is

to catch problems in a production process

early; otherwise, the schedule is lost. The

LOB technique provides that warning.

Think of the production process as a natural gas pipeline. If a bubble of air gets

into the pipeline, it will eventually be

carried to the gas users, and the users

will find their burners extinguished as

the nonflammable air reaches them. The

manager of the pipeline company or the

natural gas utility doesn’t want clients to

suffer blowouts from air bubbles in their

lines. The same holds true for the managers of a continuous production process.

Waiting for problems to show up at the

end of the line is a mistake. Problems

need to be detected when they begin so

corrections are faster, before too much

damage (to cost, performance, or schedule) is done, and production schedules

fall too far off contract.

To do LOB, the following is needed: (1) a

contract schedule, or objective chart; (2) a

production plan or lead-time chart for

the production process itself; (3) control

points cumulative inventories; and (4) a

program status chart on which to plot

LOB and the cumulative quantities of

units that have passed through the control points of the assembly/production

process. If the objective and program

status charts are given the same vertical

scale, the LOB can be plotted graphically

from the former to the latter.

Remember that the shape of the LOB will

change over time, especially if the

production process has a beginning and

an end. Remember, too, that LOB charts

show where a problem is, but not necessarily why the problem exists or what the

solution is.
In most programs, especially in DoD and

defense-related industries, time is a resource that must be carefully managed. If

it is not, it can become a serious constraint

that can threaten the success of the program. This chapter addresses time management from two perspectives: first, as it

relates to a program, and second, as it

relates to the PMs use of time.

8.1 TIME MANAGEMENT AND

THE PROGRAM

This section concerns three aspects of time

management related to programs:

(1) Time reserve

(2) “Now” schedule

(3) Value of time.

8.1.1 Time Reserve

In contractor performance measurement,

much emphasis is placed on “management

reserve,” the reserve budget controlled by

the industry PM. What isn’t always recognized is that a time reserve is also needed in

order to accommodate unknowns in the program. However, use of a time reserve should

be approached with caution, because members of a program office team may be tempted

to fall back on it prematurely.

Literature describing time reserve is scarce.

However, there are some aspects of a time

reserve that are clear.

(1) Most PMs establish a time reserve of

about 10 percent. On a 40-month program,

for example, a 4-month time reserve would

be established.

(2) The time reserve must be held closely

by the PM. Otherwise, every manager on

his/her program may think “I know there’s

a time reserve; therefore, I don’t really have

to meet my schedule.” The PM may place

this reserve under “additional system tests”

or another downstream activity. The point

is, it shouldn’t be visible. (A built-in safety

factor between the manufacturing schedule and the delivery schedule is often used.)

(3) A tough and disciplined approach to

meeting the published schedule is required

from the start of a program in order to

maintain the reserve and, consequently, to

meet the program schedule in spite of slippages caused by the unknown unknowns

(unk-unks) that inevitably arise.

8.1.2 “Now” Schedule

There is a direct relationship between time

and cost for any activity. This relationship

takes into account the people, resources,

and method used. It also considers the

efficiency achieved. Generally, the least

costly schedule is the current one. Speeding up the schedule costs more; stretching

out the schedule also costs more.

The sum of the direct and indirect costs

gives a U-shaped total program cost curve.

8

TIME MANAGEMENT

59
The optimum schedule for implementing

the program is the schedule corresponding to the minimum point on this curve.

The relationship among direct, indirect,

and total program cost is shown graphically in Figure 8-1.

Because schedule stability affects program

costs, which may, in turn, affect technical

performance, it is clear that schedule stability has a great deal to do with whether

the program meets its cost and technical

objectives. Unfortunately, budget constraints and other factors, like changes in

quantities (items over which the PM has no

control), have often been imposed on a

program with the comment, “Do the best

you can.”

When a schedule must be revised, the

superseded schedule is often discarded. If

the new schedule is superseded, the process is repeated. However, there is some

value in retaining an obsolete schedule.

Often, the organization causing a slip in

schedule becomes a repeat offender. The

principal value of retaining a former schedule lies in being able to hold the offender’s

feet to the fire, thus making schedule

slips less palatable.

The significance of maintaining a stable

schedule is becoming more widely recognized. Appendix A describes the development of a master schedule and the importance of maintaining schedule discipline.

8.1.3 Value of Time

According to the late John H. Richardson,

president of Hughes Aircraft Company,

“A basic reason for adopting project (or

program) management, when tackling the

difficult and unique tasks associated with

developing and producing a system, is to

eliminate unnecessary delays in accomplishing the job at hand. Time is a resource

in systems management, to be treated with

Figure 8-1. Total Cost Analysis for Selecting

“Optimum” Program Duration

Program Cost

Optimum

Time

Total Program

Cost

Indirect Cost

Direct Cost

60
indifference or used well like any other

resource. For projects not yet in full swing,

it is important to recognize that time has

economic value, and that we may be taking

time too much for granted.”1

(1) Funding could create a problem. In

hungry years, the schedule is often

stretched because of reduced funding.

(2) A better product could be developed

if it were more thoroughly debugged and

tested. However, a system does not really

get wrung-out until it is in the user’s hands,

regardless of advance debugging.

(3) Cost of concurrency (overlap of development and production) might lead to a

decision not to overlap program phases.

Such a decision might be popular in many

cases, but it could never be tolerated when

the pendulum swings toward the importance of time; that is, when top management says, “Get the system out the door,

never mind what it costs.”2

Stretched-out schedules incur cost penalties because of inflation, additional engineering changes, and changes in key program management office positions. Another near-term cost is due to the increased

chance that a program will be canceled

because of obsolescence or competing technology. Stretch-outs invite cancellation.

Also, long schedules with no opportunities for incorporation of improvements are

a negative factor when considering a new

start.

Delayed decisions increase costs. According to R. W. Peterson, former DuPont executive, “All businessmen are concerned, and

properly so, about the long time it takes to

move a new development from its inception to a profit status. But frequently

forgotten is the fact that a month’s delay in the

early stages of development is exactly as

long as a month’s delay in the later stages.

While it may seem innocuous to put off a

decision for a month or two in the early years

of a project (or program) with an uncertain

future, that delay may turn out to be just as

costly as is procrastination when the final

decisions are made. In short, a sense of urgency is essential to decision making in all

stages of a new venture, not just the later

stages.”3

The useful life of a defense system must be

taken into consideration. Concentration on

the system or product often overlooks a key

point: whether the buyer obtains value upon

delivery. The most costly product is one that

appears when it no longer fulfills a useful

purpose, even though it has been produced

at minimum cost. Each month added to the

development and production of a new hightechnology system or product tends to reduce by 1 month the operational life of the

system or product.

In spite of the 10-20 percent cost premium

that may be paid for tight scheduling (as

compared to orderly but stretched-out scheduling), the resulting longer operational life

may provide greater economic value. This is

looking at time only from the viewpoint of

economics, i.e., acquisition cost per year of

operational availabil survival insurance.

Consideration of alternative plans and schedules will also help; e.g., if event so-and-so

occurs, proceed with plan A; if event suchand-such occurs, proceed with plan B and so

on. Anticipation and preparation for mostlikely events, along with the tools described,

and coupled with effective communication

of the plans, can change the management

style from crisis management to skillful

management.

61
8.2 TIME MANAGEMENT AND THE

 PROGRAM MANAGER4

PMs are busy people. They have the responsibility for the management of a

myriad of activities and the resources that

make up the program. In addition, they are

often required to perform specific program

activities, especially in smaller programs.

Thus, it is important that they manage their

time well. Some managers could be more

productive, perhaps as much as 20-40 percent, by better managing their time. A major difficulty in accomplishing this is the

failure to realize that there is a time management problem and that solutions are

possible. This section discusses various

aspects of time management and identifies

ways to better accomplish it.

In the early 1980s, a time management survey was conducted to identify the problems in achieving effective time management. More than 300 project managers in 24

industries, including the government, participated in the survey, which investigated

15 different areas. The survey identified

several time management problem areas.

Among the most common were time robbers and meetings.

Time robbers are simply those things that

can occur on a day-to-day basis that can

take away from the PMs ability and time to

accomplish his/her work. There are literally dozens, if not hundreds, of such things,

such as incomplete work, delayed decisions, poor communications channels, casual visitors, lack of effective program

management tools, etc. Appendix B contains a list of common time robbers. The

survey found that delayed decisions and

poor communications were the most commonly cited time robbers. Another common problem that affects a PMs time is the

inability or reluctance to say no. If a subordinate brings a problem to the PM, the

Manager must be alert to make sure not to

assume responsibility for the problem,

unless, of course, the situation warrants

such action. If subordinates believe that

PMs will assume responsibility for their

problems, needless demands on the PM’s

time will increase.

Meetings are a fact of life in program management. However, unless they are effectively planned and conducted, they can be

a severe drain on time and resources. A

number of common pitfalls, if not avoided,

can turn meetings into a complete waste of

time. Among them are: not having a clear

and focused agenda; spending too much

time on trivial matters; having too many or

too few meetings; not having the right

people at the meetings; and not keeping an

accurate record of decisions and actions

assigned.

To get the most value out of meetings, the

following actions should be considered:

(1) Understand the purpose of the meeting

and what results are expected

(2) Minimize the number of people attending the meeting

(3) Hold the meeting in a setting appropriate for the meeting objectives

(4) Develop and distribute the agenda

(5) Start and finish on time

(6) Summarize meeting results and prepare and distribute minutes.

In addition to focusing on time robbers

and the conduct of meetings, PMs should

62
63

also concentrate on other effective time

management techniques, such as:

(7) Prioritize activities

(8) Devote solid time blocks for important

activities

(9) Maintain “to do” lists and time logs

(10) Delegate

(11) Manage by exception

(12) Practice calculated neglect

(13) Control access—limit casual visits

and telephone calls.

8.3 SUMMARY

Planning and scheduling can do much to

prevent running out of time and having to

make the least desirable decision because

of lack of time. Establishing a time reserve

and a “now” schedule, and recognizing the

value of time in decision making all contribute to the PMs repertoire of good tools.

Sir Jeffrey Quill, manager of the British

Spitfire Development Program, commented during a visit to DSMC that; “After

1935, costs weren’t particularly important.

What mattered was time. We worked three

shifts a day. Everything was time. Quantity and time. It turned out that we probably produced at the lowest cost, too; but

the emphasis was on time.”

PMs must manage their time effectively if

they are to be successful. They must be

alert to those time robbers that affect their

ability to accomplish their work and understand the value of proven time management techniques.
1

John H. Richardson, Time Defeats Technology, Hughes Aircraft Company, Culver City, Calif., date unknown. 2

Ibid. 3

Russell W. Peterson, former DuPont executive, Governor of Delaware and White House advisor, “New

Venture Management in a Large Company,” Harvard Business Review, May-June 1967, p. 72. 4

Harold Kerzner, Project Management, Van Nostrand Reinhold, New York, 1998, Chapter 6.

ENDNOTES

64
9

AUTOMATED SCHEDULING TOOLS

65

Previous chapters have shown that managers use schedules in a variety of ways for a

wide range of purposes. Schedules are an

integral part of the program planning and

decision processes. Managers use them to

track progress, predict future work, manage resources, analyze alternatives, identify risk, and report program status. In

most cases, it is the PMs responsibility to

construct, revise, maintain, and report

schedule information.

 The PM must do these things in a complex

environment that cuts across contractor and

government boundaries and includes a

wide geographical area. The challenge is

complicated even further by the need for

instant information that must be available

to a wide audience that usually requires

the information in a specific format to suit

unique needs.

It would be impossible to meet these challenges without automated tools.The

remainder of this chapter discusses characteristics and features of some tools available on the market today and suggests

criteria that anyone searching for a tool

should consider. The intent is to provide

an overview of the types of products that

are available and the range of functions

these products support. The level of detail

presented is keyed to what would be useful to know about the program management software tools that would likely be

used in a mid-to-large Program Office.

9.1 AUTOMATED PLANNING AIDS

The idea to use the power of the computer

to assist in the planning and tracking process is not new. Industry has used automated scheduling software for at least the

past 30 years. Early versions of these tools,

however, usually employed a mainframe

computer that batch processed data offline and spewed reams of information for

managers to analyze when they arrived at

work on a Monday morning. Despite the

automated tools, the process of creating,

maintaining, and reporting schedule information was a daunting task.

The advent of PCs/workstations and network technologies has made life easier for

managers. The market encourages software vendors to develop a wide range of

programs readily available to P Ms to aid

them in effectively and efficiently dealing

with the details involved in creating a program plan, then tracking progress.

The introductory paragraph of this chapter lists many uses of a “schedule.” Software developers have responded to the

managers’ needs by creating programs

that build schedules and support program management functions. Even the

simplest program includes some program

management features. The focus of the

following discussion, therefore, is on the

broad category of Program (often called

Project) Management Software.
66

The focus is on providing a brief description of the functionality of these products,

highlighting some of the desirable features

that are available to support program

management, and identifying sources that

may be useful in determining what products are available and how their features

and performance might be assessed.

9.2 FUNCTIONAL CHARACTERISTICS

 AND FEATURES

Most of the Program Management Software that is available today is based on a

relational database design and is therefore

able to support a broad range of program

management activities including:

(1) Scheduling/Tracking

(2) Resource Planning/Management

(3) Risk Management

(4) Cost/Performance/Analysis

(5) Reports and Graphics.

The extent to which the different programs

support these activities varies from product to product. For example, some products provide the capability to create only

Gantt charts whereas others provide the

tools to make Gantt and network charts.

Program features, the way in which activities are implemented, are an important

factor in considering the usefulness of a

program. A convenient way to profile the

functional characteristics and associated

features of automated program management tools is to do so from these three

perspectives:

(1) System-Level Characteristics

(2) Project Management/Scheduling

Characteristics

(3) Ease of Use.

System-level features have a general

applicability, independent of any of the

specific project-management activities supported, that add to the overall capability

and desirability of the product. These features include, but may not be limited to:

• Collaboration/Workgroup—Enables

managers/team members to use a common system of communication and allow

access to common databases for the purpose of assigning tasks, updating project

data, assigning resources, and reporting

status.

• Integral e-mail—Allows exchange of

messages and file attachments to other

project team members from within the

project management application.

• Multiple Project/Multiple Tasks—Supports multiple programs and tasks within

a project.

• Security—Limits access to certain data

by individual or class of user, as well as

password protection for the system.

• Open Data Base Connectivity

(ODBC)—Enables users to import data

from other data sources and in various

formats into their scheduling applications

(e.g., data from your contractor’s project

database). This is a Microsoft-developed

standard for exchanging data with a variety of databases.
Most programs include features that focus

on program management and schedule

functions. Some features offered are:

• Project Scheduling/Tracking—Data

Entry Templates facilitate the entry of the

initial task, time, and resource data. OnScreen Tracking facilitates comparison of

actual performance versus the planned and

allows tracking of progress by cost, time,

or achievement.

• Resource Planning/Management—Resource Leveling is a capability that resolves

resource conflicts by delaying tasks and

assignments as well as by task splitting,

which entails dividing tasks into segments

with time gaps as necessary. Resource Calendars provide insight into the availability

of a particular resource by showing working and non-working times. Free/Total Slack

Time is a feature that is useful for adjusting

under-or-over allocated resources.

• Cost/Performance Analysis—Earned

Value Tools are essential for comparing actual performance with expected performance. Cost Analysis Tool Kits are tools for

analyzing data and making forecasts. This

feature may be integral to the product or

available by virtue of “exporting” data to

another application with this capability.

• Reports and Graphics—Pre-Defined Reports facilitate the presentation of project

data. Customization Controls provide users

with a convenient way to format reports to

their own specifications. Filters enable the

user to screen information, e.g., tasks or

resources, before capturing a screen-view

or preparing a report. Embedded Graphics

and Text capability allows a user to import

data from other applications for inclusion

in a project report.

• Import/Export—Import/Export data

from/to an external source, such as another database or spread sheets, facilitates

the ability to create custom reports or conduct analyses.

Finally, ease of use or user friendliness, is

the set of qualities that represent the degree in which people can employ the software without an inordinate amount of training or regular reference to user’s manuals.

User friendliness is an important consideration because program management software products can be complicated. Regardless of how powerful a program may

be, if it is difficult to use, managers probably will not spend the time to learn it.

Consequently, PM software is likely to be

effective and desirable if users can easily

learn to use it.

The following features typify user-friendly

systems:

• Graphical User Interfaces (GUIs)—

These are the screens in which a user interacts with the program. The operating environments in use today have led to the

development of interface screens that enable the user to interact with the software in

an intuitive way, using a variety of buttons, menu lists, and wizards.

• On-Screen Data Entry—The capability

to create schedule information by using

tools to create an on-screen graph. See Figure 9-1 for an example.

• Help Function—On-screen documentation as well as “context-sensitive”

help in which the software displays the

applicable text based on the functions being performed. This is a particularly useful

feature for someone learning to use it.

67
• Tutorials—Program instruction on performing certain functions and guidance

through a “canned” demonstration.

• Wizards—Templates that guide the

user through various project setup, data

entry, and report formatting procedures.

The features discussed above are a sample

of the characteristics of various program

management products. Moreover, there is

no common “feature list” or set of definitions that defines the various characteristics. Nonetheless, the summary should give

a sense of what is available and provide the

basis for a more exhaustive review as

needed.

9.3 EVALUATING PROJECT

MANAGEMENT SOFTWARE

PRODUCTS

Choosing a software program from the

wide range of available products can be

complex and time consuming. The selection process should begin with an analysis

of what managers want to do with the

software to identify the functions that are

needed. Other factors that should be part

of the assessment process are consideration of personnel skill levels/training requirements, integration with enterprise

(organizational) systems, hardware/system requirements, and cost.

Figure 9-1. On -Screen Data Entry Using Gantt Chart Feature

(AEC Software Fast Track Schedule)

68
Table 9-1. Project Management Software Functions and Criteria

USER FRIENDLINESS

Feature Consideration

Graphical User Interfaces (GUIs) Logical, intuitive, all inclusive, windows compliant

Robust Help Function Complete, easy to access, context based, examples

Wizards Exist for major functional areas, intuitive, tailorable results

Tools Exist for major functional areas, intuitive

Tutorials Complete and examples

On-Screen Data Entry Simple, logical, complete, intuitive

SYSTEM LEVEL FEATURES

Collaboration/Workgroup Support Desired capabilities available, non-proprietary

Integral e-mail Exists, simple, compatibility with existing e-mail

Multi-Project & Task Support Roll-up to higher levels, supported by reporting features

Security Meets specific security needs, compatible w/ existing system

Open Data Base Connectivity Data transfer with other program management S/W

PROJECT MANAGEMENT/SCHEDULING FUNCTIONS

Project Scheduling/Tracking

Multiple Schedule Methods Create Gantt, network charts, and go from one to the other

Roll-Up Display and report different levels

Ability to Tailor to Specific Needs Add/delete/modify activity and event information

Relationships Display and report dependencies among events/activities

Progress Tracking Compare and display plans and actual progress

Critical Path Display Highlight critical path

Interoperability w/ Other Programs Import and export data from other programs

Total Free/Slack Time Compute and display free and slack time

Time Estimates Use probability distributions to compute time to complete

Time Roll-Up Use statistical methods to compute roll-up times

Resource Planning/Management

Resource Determination Assist in determining resources needed

Resource Assignment Allow assignment and notification of assignment to activities

Interoperability w/ Other Programs Import and export resource data

Resource Leveling Easy to access, permits “what if” excursions

Resource Calendars Display resources over time

Task Assignment Filter and display assignment of responsibility

Analysis

Schedule Analysis Allow analysis and comparison of alternative schedules

Earned Value Analysis Assist in complete and accurate EV analysis

Cost Analysis Includes tool kits for analysis of program cost

Resource Analysis Compute resource utilization, identify conflicts

Reports

Pre-Defined Report Formats Automatically create reports based on program data

Customization Controls Allow reports to be tailored for specific purposes

Embedded Graphics and Text Add text and graphics to reports

69
Analyses of requirements and software

evaluation are beyond the scope of this

discussion. However, Table 9-1 shows

some of the functions that are available in

available program management software

and lists some ideas for consideration when

searching for the right software.

9.4 FINDING OUT MORE

The best method of gaining information

about a potential project management tool

is to talk to someone who is using the

product. A PM in the next office may have

a perfectly acceptable and proven product

that he/she is using. The company under

contract may have a product that it uses. If

the government and contractor program

70

offices are going to share information, it is

prudent to use the same software, if possible. At the very least, compatibility and

interoperability must be demonstrated before making a decision to buy a particular

product.

There is a considerable information on

project management and scheduling software from a variety of sources. The Defense

Acquisition Deskbook (DAD) has a list of tools

that are being used by program offices.

From a commercial aspect, specific product information is available on most companies’ World Wide Web home pages.

Virtually all developers provide information about their products on a web site and

show links/contact to additional sources.
71

The Integrated Master Schedule (IMS) for a

program should be a time reference

baseline for the activities and events that

make up the program. It should be incorporated into the program plan and linked

to approved performance and cost objectives. The IMS is developed by the contractor from the Integrated Master Plan (IMP),

which documents all the tasks required to

deliver a high quality product and to facilitate success throughout the product’s life

cycle. In an Integrated Product and Process

Development (IPPD) environment, which

is the standard approach for all DoD programs, the IMP and IMS provide an

overarching framework against which the

Integrated Product Teams (IPTs) can function, helping them understand their work

within the context of the total program.

The IMP and IMS evolve as the program

matures. During the initial stages of Concept Exploration, the integrated plan is

preliminary and its purpose is to provide

an understanding of the scope of work

required and the likely structure of the

program. It is constructed to depict a likely

progression of work through the remaining phases, with the most emphasis on the

current and/or upcoming phase (especially

the period to be contracted for next). As the

program is defined, the IMP is iterated

several times, each time increasing the level

of detail and confidence at which all essential work has been identified. The specific

format for this plan is not critical; however,

it usually reflects an Event/Accomplishment/Criteria hierarchical structure—a

format that greatly facilitates the tracking

and execution of the program.

In some cases, a preliminary IMP and its

corresponding IMS may be developed by

the government but include industry inputs obtained through open communications with potential sources during the

pre-solicitation phase of the acquisition.

Contractors are normally required to submit formal IMP and IMS with their proposals and to develop more detailed IMP/

IMS versions after the contract is awarded.

The IMS is event driven and is developed

with participation of all program stakeholders. It should identify all tasks that

need to be accomplished, their logical order, and the input conditions necessary to

complete each task. When documented in

a formal plan and schedule, this eventdriven approach can help ensure that all

tasks are integrated properly and that the

management process is based on significant events in the acquisition life cycle and

not on arbitrary calendar events. Developing the program schedule presents an opportunity to identify critical risk areas. As

IPT members estimate the times to complete specific tasks, events that may cause

delays will become apparent. These events

are potential areas of risk that the IPT

should consider for further analysis.

The IMS begins as an IMP with dates—the

starting points are the events, accomplishments, and criteria that make up the plan.

At a minimum, an IMS shows the expected

APPENDIX A

INTEGRATED MASTER SCHEDULE DESCRIPTION
72

start and stop dates for each activity in the

plan, but each activity may be broken down

into lower-level tasks that will be used to

manage the program on a day-to-day basis. The schedule can be expanded downward to the level of detail appropriate for

the scope and risk of the program. Programs with high risk show much lower

levels of detail in the integrated master

schedule in order to give the visibility

necessary to manage risk. The more detailed the IMS, however, the greater the

cost to track and update the schedule.

Under acquisition reform initiatives, the

dates in the IMS usually are not made

contractually binding so as to allow the

flexibility to take full advantage of eventdriven scheduling.

Additional information on the development

of IMSs can be found in various sections of

the Defense Acquisition Deskbook and in the

DoD Integrated Product and Process Development Handbook dated August 1998. Commercial standards EIA 632 and IEEE 1220-

1994 can also be consulted for more information on developing master plans and

schedules. See http://www.eia.org/eng/

published.htmand http://

standards.ieee.org for information on

how to obtain these standards. A DoD

Data Item Descriptor (DI-MISC-81183A)

has been developed for IMS guidance;

it is attached to this Appendix as Tab 1.

USE OF INTEGRATED MASTER

SCHEDULES

The primary purpose of the IMS is to track

schedule variations. By linking the IMS to

the IMP, it can also be used to track the

activities that provide functional and lifecycle inputs to product development. In

this role it provides a crosscheck not only

that the inputs were obtained, but also that

they were obtained at the right time. In

addition, the IMS can be useful for the

following events/activities that are common to all programs.

PROGRAM REVIEWS

The IMS can be a framework for periodic

program reviews within the program management office (PMO). If constructed properly, the schedule will illustrate the various levels of the program and will be compatible with the program cost/schedule

control system reports.

Program reviews can be an excellent forum

for resolution of schedule conflicts and the

genesis for controlled changes to the schedule from within the PMO. Most key members of the PMO team are present at these

reviews; therefore, proposed schedule

changes or slips can receive wide dissemination within the organization.

WHAT IF” EXERCISES

The IMS can serve as the framework for

“what if” exercises imposed on programs

from outside the PMO. Schedule changes

can be plotted manually by using overlays. Using the same grid coordinates on

an overlay allows the PMO team to see,

clearly and graphically, the effect of the

compressions or extensions of sub-milestones on the program. It may be even

easier (and more productive) for the PMO

team to run “what if” exercises on a computerized schedule. Without a master

schedule as a baseline, these exercises can

take longer to accomplish and they may

overlook important variances from the

program’s established baseline schedule

or plan.
73

PROGRAM BRIEFINGS

The IMS can serve as a baseline for program reviews at higher headquarters and

other reviews or briefings outside the PMO.

Most programs have key milestones taken

from the master schedule and presented in

summary form on viewgraphs or slides. If

these do not show the detail required to

make a point, the time span shown can be

reduced to the point where the details

become visible.

SCHEDULE DISCIPLINE

To be effective, an IMS must be kept upto-date and accurate. Maintenance of the

IMS requires a process similar to that

inherent in configuration control—one

that establishes discipline through a set of

rigorous procedures for managing schedule change. The degree of schedule discipline imposed within the PMO can be a

major factor in the success of a program.

The underlying philosophy of the schedule control process should reflect centralized control of the IMS. That is, changes to

the IMS baseline should be made only

with the approval of the P2M or his/her

designated representative and with full

justification and an understanding of the

impact of the changes on the overall program. Following are examples of some

simple procedures that, if practiced, will

instill discipline and prevent the unauthorized release of schedule information that

has not been approved for inclusion in the

IMS.

• Program changes, whatever the source,

should start as proposals and, if approved,

grow into a firm plan. Eventually, they are

incorporated into the IMS as changes. The

question of when to plot these changes is a

matter of judgment and should reflect the

PM's policy. Each change should be plotted as a proposed or tentative change until

approved.

• A permanent record of each change

should be maintained. If the program

schedule slips, it should be documented

until documentation no longer serves a

useful purpose.

• Whenever copies of the IMS are made,

they should be dated and authenticated by

the signature of the PM or the appointed

schedule manager. Undated and unauthenticated schedules should not be released

outside the PMO.
74

DATA ITEM DESCRIPTION Form Approved

OMB NO. 0704-0188

Public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of

Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. TITLE

Integrated Master Schedule (IMS)

2. IDENTIFICATION NUMBER

 DI-MISC-81183A

3. DESCRIPTION/PURPOSE

The IMS is an integrated schedule developed by logically networking detailed program

activities. The contract Integrated Master Plan (IMP)is the foundation of the program

schedule and provides a hierarchy for schedule traceability and summarization. IMP events,

accomplishments, and criteria are included in the schedule to monitor progress. This

information will be used to verify attainability of program objectives, evaluate the progress

of the government and contractor team toward meeting the program objectives, and to integrate

program schedule among all related components.

4. APPROVA L DATE (YYMMDD)

 960209

5. OFFICE OF PRIMARY RESPONSIBILITY (OPR)

F/ASC/FMCS

6a. DTIC APPLICABLE 6b. GIDEP APPLICABLE

7. APPLICATION/INTERRELATIONSHIP

7.1 This Data Item Description (DID) contains the format and content preparation

instructions for the data product generated by the specific and discrete task requirement as

delineated in the contract.

7.2 This DID may be applied to programs which utilize the Work Breakdown Structure (WBS)

during the concept exploration, demonstration and validation, engineering and manufacturing

and development, and production phases.

7.3 This DID supersedes DI-MISC-81183.

8. APPROVA L LIMITATION 9a. APPLICABLE FORMS 9b. AMSC NUMBER

 F7180

10. PREPARATION INSTRUCTIONS

10.1 Format . This precedence logic diagram shall be in the contractor’s format in the form

of a network, milestone, and Gantt chart. This diagram shall be provided in digital format.

10.2 Content . The schedule shall contain all of the contract IMP events and milestones,

accomplishments, criteria, and activities from contract award to the completion of the

contract. The schedule shall be an integrated, logical network-based schedule that

correlates to the program WBS, and is vertically and horizontally traceable to the

cost/schedule reporting instrument used to address variances (such as Cost Performance Report

(CPR), Cost/Schedule Status Report (C/SSR), etc.) It shall have a numbering system that

provides traceability through the IMP and Statement of Work (SOW). It shall contain program

events and milestones and definitions, summary, intermediate and detailed schedules, and

periodic analysis of progress to date. It shall be possible to access the information by

product, process, or organizational lines. Descriptions of the key elements are as follows:

10.2.1 Program milestones and definitions. Key programmatic events defined by IMP, the

contracting agency or weapon system contractor which define progress and completion in each

WBS element along with the definition for successful completion of the milestone.

10.2.2 Summary master schedules. A graphical display of top-level program activities and

key events and milestones of the IMP which depict major work activities in an integrated

fashion at the summary level of the WBS, e.g. level 1-3 of the WBS.

10.2.3 Intermediate schedules. A graphical display of top-level program activities and key

milestones which includes all associated accomplishments of the IMP, traceable to the WBS

element as necessary to display the work effort at the intermediate level of summarization,

e.g. level 3-5 of the WBS as appropriately tailored.

10.2.4 Detailed schedules. A graphical display of detailed activities and milestones which

depict work activities in a particular work breakdown structure element, to include the

criteria associated with each accomplishment of the WBS element as well as any additional

activities necessary to display the work effort to detailed WBS levels, e.g. level 4-8 of the

WBS as appropriately tailored.

11. DISTRIBUTION STATEMENT

 Distribution Statement A: Approved for public release; distribution is unlimited.

DD Form 1664, APR 89 Previous editions are obsolete Page 1 of 

 

3
75

Block 10, Preparation Instructions (Continued)

10.2.5 Periodic analysis. A brief summary which identifies progress to date, variances to the planned

schedule, causes for the variance, potential impacts and recommended corrective action to avoid

schedule delays. For each program milestone planned, forecasted and actual completion dates shall be

reported. The analysis shall also identify potential problems and a continuing assessment of the network

critical path. Thresholds for impact reporting shall be identified on the DD Form 1423, CDRL.

10.2.6 Integrated program network. Logical diagram of all activities in the program. The key elements of

the integrated network to be constructed in the diagram are as follows:

a. Milestone or event - A specific definable accomplishment in the program/project network, recognizable

at a particular point in time. Milestones are numbered and may be contained within an activity box.

b. Activity or task - A time consuming element, e.g. work in progress between interdependent events,

represented by an activity box.

c. Duration - Planned length of time needed to accomplish an event/activity.

d. Relationships - A line that defines how two activities or events are logically linked. It can take up to

four (4) forms:

(1) FS (finish to start) - An activity must finish before another can start.

(2) SS (start to start) - An activity depends on the start of another

 activity.

(3) FF (finish to finish) - One activity cannot finish until another activity

 is finished.

(4) SF (start to finish) - An activity cannot finish until another activity

 starts.

e. Slack or Float - Extra time available on an activity before it will impact an activity on the critical path.

f. Lag - The delay or wait period between two tasks.

g. Critical Path - A sequence of activities in the network that has the longest total duration through the

program or project. Activities along the critical path have zero or negative slack/float. It should be easily

distinguished on the report formats, e.g. a thick line, patterned or in red ink. This should be calculated by

computer-based software.

h. Target Start (TS) - A program defined date of when an activity should start. This is an operatordefined date rather than a computer-calculated date.

i. Target Complete (TC) - A program defined date of when an activity should finish. This is an operatordefined date rather than a computer-calculated date.

j. Actual Start (AS) - Actual start date of an activity.

k. Actual Finish (AF) - Actual finish date of an activity.

l. Early Start (ES) - The earliest start date an activity can begin the precedence relationships. Computercalculated date.

m. Early Finish (EF) - The earliest finish date an activity can end. Computer-calculated date.

n. Late Start (LS) - The latest start date an activity can start without delaying the program or project

target completion date. Computer-calculated date.

04/15/91 DI-MISC-81183
76

04/15/91 DI-MISC-81183

3 of 3

Block 10, Preparation Instructions (Continued)

o. Late Finish (LF) - The latest finish date an activity can have without affecting the

program or project target completion date. Computer-calculated date.

p. Percent Complete (PC) - Actual progress of an activity from its start to its finish.

10.3 Master Integrated Program Schedule. It shall display all of the proposed

activities, events, and milestones from contract award to the completion of the contract.

10.4 Descriptive titles. Activities, tasks, events, and milestones shall be labeled with

a brief descriptive title, numbered of coded and contain time constraints (e.g. duration,

TS, ES, EF, LS, LF, etc.). Standard abbreviations may be used to conserve space.

Descriptive titles used on activities, events, and milestones shall be identical on all

program schedules. A legend shall be provided to aid in ease of reading the schedules.

10.5 Schedule risk. The schedule shall include a description of the approach that will

be taken to limit the schedule risks identified as a result of the contractor’s risk

assessment. Risk shall be defined considering impact on cost and technical performance

and assessing the probability of schedule change. Additionally, technical performance

measurement tasks and their correlation with contractual cost/schedule elements permit

assessment of the program effort in terms of the schedule as well as cost of work

increments. As technical performance measurement tasks, as well as cost reviews, reveal

potential impacts to the schedule these risks will be identified.

10.5.1 Schedule Risk Assessment (SRA).

 

Optimistic, pessimistic, and most likely

durations for each MIPS activity/task and milestone/event shall be provided as the basis

for determining the probability of meeting schedule dates. The government will assess the

durations and use an appropriate cumulative probability (0-100%) for the chosen milestones

to determine expected completion dates.
77

• Incomplete work

• A job poorly done that must be done

over

• Poor communications channels

• Uncontrolled telephone calls

• Lack of adequate responsibility and commensurate authority

• Poor functional performance and

status reporting

• Changes without direct notification/

explanation

• Casual visitors and conversations

• Waiting for people

• Failure to delegate, or unwise

delegation

• Poor retrieval systems

• Lack of information in a ready-to-use

format

• Day-to-day administration

• Spending more time than anticipated

in answering questions

• Late appointments

• Impromptu tasks

• Having to explain “thinking” to

superiors

• Too many levels of review

• Too many people in a small area

• Misplaced information

• Record keeping

• Shifting priorities

• Indecision or delaying decisions

• Procrastination

• Setting up appointments

• Too many meetings

• Monitoring delegated work

• Unclear roles/job descriptions

• Unnecessary crisis intervention

• Need to get involved in details to get

job done

• Not enough proven or trustworthy

managers

• Vague goals and objectives

• Too many people involved in minor

decision making

• Lack of technical knowledge

• Lack of authorization to make

judgment decisions

• Unreasonable time constraints

• Lack of commitment from higher authorities

• Too much travel

• Lack of adequate project management

tools

APPENDIX B

Common Time Robbers1
• Poor functional communications/ writ

ing skills

• Inability to relate to peers in a personal

way

• Rush into decisions/beat the deadline

• Lack of reward (“a pat on the back can

do wonders”)

• Expecting too much from one’s staff

and oneself

• Going from crisis to crisis

• Conflicting directives

• Fire drills

• Lack of privacy

• Lack of challenge in job duties

• Bureaucratic roadblocks (“ego”)

• Empire-building line managers

• Too much work for one person to handle

effectively

• Excessive paperwork

• Lack of clerical/administrative support

• Workload growing faster than capacity

78

• Dealing with unreliable subcontractors

• Personnel not willing to take risks

• Demand for short-term results

• Lack of long-range planning

• Being overdirected

• Overreacting management

• Poor lead time on projects

• Documentation (reports/red tape)

• Large number of projects

• Inadequate or inappropriate require

ments

• Desire for perfection

• Lack of dedication by technical experts

• Lack of project organization

• Constant pressure

• Constant interruptions

• Project budget problems

• Shifting of functional personnel

• Lack of qualified manpower

1

Harold Kerzner, Project Management, Van Norstand Reinhold, New York, NY, 1998, Chapter 6.

ENDNOTES
ACQUISITION STRATEGY — A business and technical management approach

designed to achieve program objectives

within the resource constraints imposed. It

is the framework for planning, directing,

contracting for, and managing a program.

It provides a master schedule for research,

development, test, production, fielding,

modification, postproduction management, and other activities essential for program success. Acquisition strategy is the

basis for formulating functional plans and

strategies [e.g., test and evaluation master

plan (TEMP), acquisition plan (AP), competition, prototyping, etc.].

ACTIVITY — A task or measurable

amount of work to complete a job or part of

a project.

ACTUAL COST OF WORK PERFORMED (ACWP) — The costs actually

incurred and recorded in accomplishing

the work performed within a given time

period.

ARROW DIAGRAM METHOD (ADM)

— A type of network diagram that labels

the activities on the lines connecting nodes.

BAR CHART — The detailed graphical

working plan of a part providing sequence

and time for the job scheduled ahead and

progress to date.

BUDGETED COST OF WORK SCHEDULED (BCWS) — The sum of the budgets

for all work (work packages, planning pack79

ages, etc.) scheduled to be accomplished

(including in-process work packages), plus

the amount of level of effort and apportioned effort scheduled to be accomplished

within a given time period. (Planned Value)

BUDGETED COST OF WORK PERFORMED (BCWP) — A measurement of

work performed in cost/schedule control

systems criteria (C/SCSC) terminology.

BCWP is a measurement of work performed as compared to the original plan.

(Earned Value)

BUDGETING — The process of translating resource requirements into a funding

profile.

CRITICAL PATH METHOD (CPM) — A

technique that aids understanding of the

dependency of events in a project and the

time required to complete them. Delayed

activities that have an impact on the total

project schedule are critical and said to be

on the critical path.

EARNED VALUE MANAGEMENT SYSTEM (EVMS) — An integrated management system that coordinates work scope,

schedule, and cost goods and objectively

measures progress toward these goals. It

is based on an industry-developed set of

32 guidelines adopted for use by DoD in

1999 for evaluation of contractor management systems. A complete listing of the

guidelines is contained in DoD 5000.2-R,

Appendix VI.

APPENDIX C

GLOSSARY
FLOAT — The period of time that an activity may be delayed without becoming a

critical activity. Also known as slack or

path float/slack.

FREE FLOAT — The float that a single

activity can experience without affecting

any other activity.

GANTT CHART — A graphic portrayal of

a project which shows the activities to be

completed and the time to complete represented by horizontal lines drawn in proportion to the duration of the activity. Some

Gantt charts will be able to show the float

for the activity.

INTEGRATED MASTER PLAN (IMP) —

An event-based plan that depicts the overall structure of the program and the key

processes, activities, and milestones. It defines the accomplishments and criteria for

each event in the plan.

INTEGRATED MASTER SCHEDULE

(IMS) — The detailed task and timing of

the work effort in the IMP. A networked

schedule that identifies all IMP events,

accomplishment, and criteria, and the expected dates of each.

INTEGRATED PRODUCT AND PROCESS DEVELOPMENT (IPPD) — A management technique that simultaneously

integrates all essential acquisition activities through the use of multidisciplinary

teams to optimize the design, manufacturing, and supportability processes. IPPD

facilitates meeting cost and performance

objectives from product concept though

teamwork through Integrated Product

Teams (IPTs).

INTEGRATED PRODUCT TEAM (IPT)

— Team composed of representatives from

all appropriate functional disciplines working together to build successful programs,

identify and resolve issues, and make

sound and timely recommendations to facilitate decision making. There are three

types of IPTs: overarching IPTs (OIPTs)

focus on strategic guidance, program assessment, and issue resolution; working

IPTs (WIPTs) identify and resolve program

issues, determine program status, and seek

opportunities for acquisition reform; and

program-level IPTs focus on program execution and may include representatives

from both government and after contract

award industry.

LINE OF BALANCE (LOB) — A graphic

display of scheduled units versus actual

units produced over a given set of critical

schedule control points on a particular day.

MASTER PROGRAM SCHEDULE

(MPS)—The top-level schedule for the program. It is prepared by the government

and includes all policy and contractual

events/activities. It is derived from the

Program WBS and provides the baseline

for all subordinate schedules. It sometimes is called the program structure/

schedule.

MILESTONE (MS) — The point when a

recommendation is made and approval

sought regarding starting or continuing

(proceeding to next phase) an acquisition

program. Milestones are: 0 [Approval to

Conduct Concept Studies], I [Approval to

Begin a New Acquisition Program], II [Approval to Enter Engineering & Manufacturing Development (EMD)], and III [Production or Fielding/Development and

Operational Support (PF/DOS) approval].

A significant event that marks certain

80
81

progress, such as completion of a phase of

the project.

MILESTONE CHART — A graphic

portrayal of a program/project that shows

the events to be completed on a timeline.

NETWORK SCHEDULE — A scheduling

technique that provides the means for defining task relationships and relationship

lags. These may include such precedence

relationships as “Start to Start,” “Finish to

Finish," and "Start to Finish."

PERT — See Program Evaluation Review

Technique.

PERT Chart — A graphic portrayal of milestones, activities, and their dependency

upon other activities for completion and

depiction of the critical path.

PRECEDENCE DIAGRAM METHOD —

A network diagram in which the activities

are labeled in the nodes, usually boxes.

PRODUCTION SCHEDULES — Chronological controls used by management to

regulate efficiently and economically the

operational sequences of production.

PROGRAM EVALUATION REVIEW

TECHNIQUE (PERT) — A technique for

management of a program from inception

through to completion by constructing a

network model of integrated activities and

events and periodically evaluating the

time/cost implications of progress.

RESOURCE LEVELING — A process

whereby resources are sorted out among

tasks and activities to identify and avoid

conflicts between scheduling and availability.

RISK — A measure of the inability to

achieve program objectives within defined

cost and schedule constraints. Risk is associated with all aspects of the program, e.g.,

threat, technology, design processes, work

breakdown structure (WBS) elements, etc.

It has two components: the probability of

failing to achieve a particular outcome and

the consequences of failing to achieve that

outcome.

RISK MANAGEMENT — All plans and

actions taken to identify, assess, mitigate,

and continuously track, control, and document program risks.

SCHEDULE — Series of things to be done

in sequence of events within given period;

a timetable.

SCHEDULE RISK — The risk that a program will not meet its acquisition strategy

schedule objectives or major milestones

established by the acquisition authority.

SCHEDULE VARIANCE — A metric for

the schedule performance of a program. It

is the algebraic difference between earned

value (BCWP) and planned value (BCWS)

(Variance = BCWP - BCWS). A positive

value is a favorable condition while a

negaive value is unfavorable.

SCHEDULING — The prescribing of when

and where each operation necessary to the

manufacture of a product is to be performed.

WORK BREAKDOWN STRUCTURE

(WBS) — An organized method to break

down a project into logical subdivisions or

subprojects at lower and lower levels of

details. It is very useful in organizing a

project. See MIL-HDBK 881 for examples

of WBSs.
82
Q. W. Fleming, J. W. Bronn, and G. C.

Humphreys, Project and Production Scheduling, Probus Publishing Co., Chicago, IL,

1987.

H. Kerzner, Project Management: A Systems

Approach to Planning, Scheduling, and Controlling, Van Nostrand Reinhold, New York,

NY, 1998.

M. D. Rosenau, Jr., Successful Project Management: A Step-by-Step Approach With Practical Examples (2nd Edition), Van Nostrand

Reinhold, New York, NY, 1992.

D. C. Cleland, Field Guide to Project Management, Van Nostrand Reinhold, New York,

NY, 1998.

J. J. Mayer, Time Management for Dummies

(2nd edition), IDG Books Worldwide, Inc.,

Foster City, CA, 1999.

Defense Systems Management College,

Acquisition Strategy Guide, DSMC, Fort

Belvoir, VA, 1998.

APPENDIX D

BIBLIOGRAPHY

Defense Systems Management College,

Earned Value Management Textbook, DSMC,

Fort Belvoir, VA, April 16, 1998.

Office of the Under Secretary of Defense

(Acquisition and Technology), DoD Integrated Product and Process Development Handbook, DoD, Washington, DC, 1998.

D. T. Hulett, “Project Schedule Risk Assessment,” Project Management Journal,

March 1995.

PMI Standards Committee, A Guide to the

Project Management Body of Knowledge,

Project Management Institute, Newton

Square, PA, 1996.

J. R. Knutson, How To Be A Successful Project

Manager, IEEE Successful Management

Series, Undated.

J.P. Lewis, Project Planning, Scheduling &

Control, McGraw-Hill, New York, NY, 1995.

83
ii

DSMC PRESS

WANTS TO HEAR FROM YOU

Please rate this publication in various ways using the following scores:

4—Excellent 3—Good 2—Fair 1—Poor O—Does not apply

Name of this publication—Scheduling Guide for Program Managers

This publication:

A._____ is easy to read.

B._____ has a pleasing design and format.

C._____ successfully addresses acquisition management and reform issues.

D._____ contributes to my knowledge of the subject areas.

E._____ contributes to my job effectiveness.

F._____ contributes to my subordinate’s job effectiveness.

G._____ is useful to me in my career.

H._____ I look forward to receiving this publication.

I._____ I read all or most of this publication.

J._____ I recommend this publication to others in acquisition workforce.

How can we improve this publication? Provide any constructive criticism for us to

consider for the future.

What other DSMC publications do you read?

OPTIONAL

Name/

Title____________________________________________________________________

Company/Agency______________________________________________________________

Address_______________________________________________________________________

_______________________________________________________________________________

Work Phone ( )_________________DSN_________________FTS____________________

Fax_____________________________Email________________________________________

_____Please mail me a brochure listing other DSMC publications.

_____Please send a free subscription to the following at the address above.

 _____Acquisition Review Quarterly _____Acquisition Reform Today Newsletter

Copy this form and fax it to DSMC Press at (703) 805-2917.

84
iii