Scheduling Cost

.....
Preface
PREFACE
................................................................
Dear Reader -
www.pmptools.com, inc. is excited to have published this book titled “A Project
Managers Guide to Scheduling and Cost Control”. We believe it is the first of its kind in
the field of project management.
Just as the Project Management Institute is committed to establishing measurable
standards for the project management professional, www.pmptools.com, inc. is happy
to help assist professionals with the knowledge needed to meet those standards.
This book assumes you have at least read “A Guide to the Project Management Body
of Knowledge” (PMBOK®) and have some general project management skills. We
highly recommend that you obtain the PMBOK® if you do not currently have a copy.
COPYRIGHT INFORMATION
................................................................
Copyright 2003 www.pmptools.com, inc. All rights reserved. No part of this publication
may be stored in a retrieval system, transmitted, or reproduced in any way, including
but not limited to photocopy, photographs, magnetic, or other record, without the prior
agreement and written permission of the publisher.
The author and publisher have made their best efforts to prepare this book. The author
and publisher make no representation or warranties of any kind with regards to the
completeness or accuracy of the contents herein and accepts no liability of any kind,
including but not limited to performance, merchantability, fitness for any particular
purpose or any losses or damages of any kind caused or alleged to be caused directly
or indirectly from this book.
Trademarks: www.pmptools.com, inc., has attempted throughout this book to
distinguish proprietary trademarks from descriptive terms by following the capitalization
style used by the manufacturer.
Understanding How to Manage Projects Preface

Published by: www.pmptools.com
Email: publishing@pmptools.com
www.pmptools.com, inc., publishing division welcome corrections and comments on its

documents. In addition to comments, please send comments on typographical,
formatting, or other errors. Simply make a copy of the relevant page, mark the error,
and send it to www.pmptools.com, inc., Publishing Division, P.O. Box 30291, Phoenix,
Arizona 85032, or email at booked@pmptools.com.
Books and testing materials are available at special quantity discounts to use as
premiums and sales promotions, or for corporate training programs, as well as other
educational programs. For more information, please write the Business Manager at
business@pmptools.com.
Printed in the United States of America. No part of this work may be reproduced or
transmitted in any form or by any means, electronic, manual, photocopying, recording,
or by any information storage and retrieval systems, without prior written permission of
the publisher.
ISBN 0-9726656-7-6 (paperback)
Preface Understanding How to Manage Projects

.....
Table of Contents
Contents
Chapter 1 - Introduction
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 2 - Project Management Review

What Is Scheduling and Cost Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Why Scheduling and Cost Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The Project Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Requirements Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Scheduling and Cost Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Organizational Context for Scheduling and Cost Control . . . . . . . . . . . . . . . . . . . . 9
Scheduling and Cost Control Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Work Breakdown Structure Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 3 - Resource Allocation & Estimating

Resource Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Resource/Responsibility Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Resources As Estimating Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The Rules of Estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Estimating Methods: Analogy and Vendor Bids. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Estimating Methods: Parametric Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Budget Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Budget Estimating––Types of Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Bottom-Up Method: Detailed Estimates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Estimating Durations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Establishing Task Durations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Productivity and Availability in Resource-Driven Estimates. . . . . . . . . . . . . . . . . . 32
Program Evaluation and Review Technique (PERT). . . . . . . . . . . . . . . . . . . . . . . 33
Standard Deviation in PERT Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Standard Deviation for a Path Using PERT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Time-Constrained Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Resource-Constrained Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
How to Review an Estimate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A Project Managers Guide to Scheduing and Cost Control Table of Contents

Chapter 4 - Scheduling
Network Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Validating the Time Frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Project Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Network Diagram Rules of Thumb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Arrow Diagramming Method (ADM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Building an AOA Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Precedence Diagramming Method (PDM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Building a Precedence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Basic Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Calculating the Forward Pass (Finish-Start Relationships) . . . . . . . . . . . . . . . . . . 51
Forward Pass (Full Precedence Diagram). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Backward Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Backward Pass (Full Precedence Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Float/Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Types of Float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Critical Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Scheduling Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Lag and Lead Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Precedence Relationships in PDM - Finish-start . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Precedence Relationships in PDM - Finish-finish . . . . . . . . . . . . . . . . . . . . . . . . . 67
Precedence Relationships in PDM - Start-start . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Precedence Relationships in PDM - Start-finish . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Calculating the Network with Additional Constraints . . . . . . . . . . . . . . . . . . . . . . . 70
Crashing a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Crashing a Network—Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Alternative Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Resource Trade-Offs: Leveling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Sample Procedure (Develop Software): WBS Example . . . . . . . . . . . . . . . . . . . . 77
Define the Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Assign ES/EF Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Review Float (Early Schedule). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Review Resource Loading (Early Schedule/Transferable Resources) . . . . . . . . . 80
Resource Loading Histogram (Early Schedule). . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Review Logic (Late Start/Late Finish) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Review Float (Late Start/Late Finish). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Review Resource Loading (Late Schedule). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Resource Loading Histogram (Late Schedule) . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Review Resource Loading (Resource-Limited) . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Resource Loading Histogram (Resource-Limited). . . . . . . . . . . . . . . . . . . . . . . . . 87
Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Creating a Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Setting Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Building a Milestone Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Table of Contents A Project Managers Guide to Scheduing and Cost Control

.....
Table of Contents
Chapter 5 - The Baseline

The Basics of Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Cost Baseline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Cost Baseline - Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Technical Baseline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Time and Cost Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Time and Cost Trade-offs - Exercise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Cost/Time Slope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Review the Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Chapter 6 - Managing Change Within the Project

What Is Control and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Where Do Changes Come From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Change Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Identify Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Evaluating Change Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Coping with Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Updating the Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Communicating Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Implementing Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Using Reserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 7 - Evaluation and Forecasting

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Monitoring Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Evaluating Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Conduct Trend Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Project Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Why Consider Earned Value (EV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
One Type of Detailed Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Key Earned Value Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Integrated Cost/Schedule Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Schedule Variance (SV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Cost Variance (CV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Cost Performance Index (CPI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Latest Revised Estimate or Estimate at Completion (EAC) . . . . . . . . . . . . . . . . . 129
Variance at Completion (VAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Estimate to Complete (ETC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Percent Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
To-Complete Performance Index (TCPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Schedule Performance Index (SPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Earned Value Schedule Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Project Evaluation and Forecast: EV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
The 50-50 Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Analyze Variance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
A Project Managers Guide to Scheduing and Cost Control Table of Contents

Replan and Reforecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Status Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Chapter 8 - The Exit Strategy

Project Closeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Exit Strategy Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Fulfill Contract Obligations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Conduct Final WBS Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Organize Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Finalize Customer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Celebrate A Successful Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Administration Closeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Appendix A - Project Management Tools

Tool 1 - Project Requirements Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Tool 2 - Roles and Responsibilities Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Tool 3 - Sample Cost Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Tool 4 - Project Estimating Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Tool 5 - Change Control Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Tool 6 - Change Responsibility Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Tool 7 - Document Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Tool 8 - Evaluation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Tool 9 - Project Status Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Tool 10 - Evaluation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Tool 11 - Project Audit Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Tool 12 - Earned Value Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Tool 13 - Project Binder Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Tool 14 - Transition Meeting Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Tool 15 - Project Termination Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Exercise & Assignments

Exercise 1 -Scheduling and Cost Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Exercise 2 -Organizational Context for Scheduling and Cost Control . . . . . . . . . . . 9
Exercise 3 -The Rules of Estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Exercise 4 -Critical Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Exercise 5 -Calculating the Network with Additional Constraints . . . . . . . . . . . . . . 70
Exercise 6 -Creating a Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Exercise 7 -Building a Milestone Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Exercise 8 -Updating the Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Exercise 9 -Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Exercise 10 -Cost Performance Index (CPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Table of Contents A Project Managers Guide to Scheduing and Cost Control

INTRODUCTION
...................................
1
.....
By purchasing and reading this book “A Project Managers Guide to Scheduling and
Cost Control,” you’ve taken a lasting step in getting a solid understanding of project
management methods. This book will help you gain hands-on experience in proven
project management methods. You will also discover valuable, flexible tools that can
be used to ensure the success of any project in any organization.
This book will also give you the foundation, knowledge, techniques/tools to manage
each stage of the project life cycle. You will also learn how to work within
organizational and cost constraints, set goals tied directly to stakeholder needs.
Finally learn how to get the most from your project management team, and use the
proper project management tools to get the work done on time and within budget.
A Project Managers Guide to Scheduling and Cost Control delves into the detailed
nature of the tools of scheduling and cost control. There is also an emphasis on
developing the project requirements and the work breakdown structure. This book also
explores the detailed nature of building network diagrams and developing cost
estimates. We will also show you how to integrate these into a coherent project
baseline against which we can both monitor and manage the project.
After working through the issues of establishing baselines, the book focuses on
monitoring and control, evaluating the project, and reporting those evaluations to
management and the project team. We have included a Tools Section in Appendix A
which includes templates and forms.
We have divided this book into several different scheduling and cost control elements
and you should read the book in sequence, because some chapters and sections build
on the understanding provided from earlier sections and exercises.
A Project Managers Guide to Scheduing and Cost Control Introduction 1-1

INTRODUCTION
1
Getting Started
The book begins with a review of terms and issues related specifically to the early stages
of scheduling and cost control, including requirements definition and the work
breakdown structure. After the terms are defined, you will begin the fundamental
practices of scheduling and cost control.
Resource Allocation and Estimating
In resource allocation and estimating, you will look at the issues surrounding resource
selection and loading, as well as the effect of those choices on project estimating.
Estimating is examined at various levels, from the common ballpark estimate to the
detailed, bottom-up estimates created from the work package up.
Scheduling
In this chapter, you have the opportunity to examine and build schedules using
fundamental tools and practices that you can apply in any project environment, from the
basic to the complex. Specifically, you will work through network diagrams, including
both activity-on-arrow and activity-on-node.
The Baseline
The baseline integrates the components developed so far and sets the foundation
against which the project will eventually be judged. You will learn how to set and
communicate a baseline and how to interpret it for effective project reporting and control.
Managing Change
With the baseline in place, the course examines project change control from the looser
change structures embraced by some organizations to the rigors of configuration
management.
Evaluation and Forecasting
This chapter persuades the project manager to become a visionary, providing the
project manager with tools to examine project histories to develop project forecasts. This
important chapter also reviews the concerns associated with comprehensive project
evaluations, as demanded by many rigorous project management organizations.
The Exit Strategy
As the book wraps up, it examines in detail the most under-valued and under-
performed elements of project management - the closeout phase.
1-2 Introduction A Project Managers Guide to Scheduing and Cost Control

.....
INTRODUCTION
Book Objectives
After reading this book, you will be able too:
• Identify the elements of scheduling and cost control
• Identify tools to apply in scheduling and cost control
• Apply a project requirements document (PRD) in preparation for scheduling and
cost control
• Build a PRD
• Apply a work breakdown structure (WBS) in preparation for scheduling and cost
control
• Apply different estimating tools in the project management process
• Define estimating variables and their roles in the project management process
• Develop a bottom-up estimate
• Critique at least three types of estimates for accuracy
• Assign and control project responsibility using resource allocation
• Develop criteria for selecting the appropriate scheduling tool
• Construct a usable project schedule
• Review and practice working against data constraints
• Determine project baselines using fundamental estimating processes
• Interpret data gained from time-based distribution of project costs
• Establish a baseline for a project
• Develop a cumulative cost curve
• Apply techniques to manage against the baseline
• Identify specific elements available for control in an active project and implement
methodologies to exercise that control
• Predict and control change against the baseline
• Establish change management practices
• Define methods for measuring project progress
• Review and apply the disciple of earned value and its role in scheduling and cost
control
• Set up an earned value system, and evaluate project progress using that system
• Determine when a project is out of control
• Determine when a project is complete
• Appraise the project plan in the context of project completion
• Provide concrete measurements of project success at completion
A Project Managers Guide to Scheduing and Cost Control Introduction 1-3

INTRODUCTION
1
1-4 Introduction A Project Managers Guide to Scheduing and Cost Control

P ROJECT M ANAGEMENT REVIEW
...................................
2
.....
OBJECTIVES
At the end of this chapter, you will be able to—
• Identify the elements of scheduling and cost control

• Identify tools to apply in scheduling and cost control
• Observe scheduling and cost control in action
• Apply a project requirements document (PRD) in preparation for scheduling and
cost control
• Build a project requirements document (PRD)
• Apply a WBS in preparation for scheduling and cost control
• Appraise the benefits of the WBS in the project management process
• Use the WBS to clarify project scope and tasks for baseline management
• Explain the role of the WBS in scheduling and cost control
WHAT IS SCHEDULING AND COST CONTROL?

................................................................
Scheduling and cost control (S&CC) involves—
• Directing progress
• Directing actions
• Controlling results
• Conserving resources
Imagine for a moment, if you will, you are trying to set a world record on home construction.
That’s right: you are trying to set the world record [for shortest time]. The big question in
scheduling and cost control is what needs to be done? For one, you need to be directing
progress, telling people where to be going in the next 15, 20, 30 minutes down the road.
You cannot afford to be sitting there waiting for people to take action or waiting for actions to
be completed. You have to be thinking ahead. You also have to be directing actions. If
A Project Managers Guide to Scheduing and Cost Control 2-5

PROJECT MANAGEMENT REVIEW
2 Why Scheduling and Cost Control?
somebody is taking an action that is in detriment to the project, you need to make sure that
is identified and corrected as quickly as possible.
That correction comes to controlling results. You need to ensure that the results and
outcomes are exactly what you anticipated and that they are showing up in the form you
anticipated. You have to control every little component. That may mean backing up and
doing things over again. And you need to conserve resources—no project has unlimited
resources. There is always going to be a need to recognize that there are limitations, and
we have to live within those limitations, be they time, money and patience.
WHY SCHEDULING AND COST CONTROL?

................................................................
• The “triple constraint”
• Most clearly measurable indexes for project management
• Deliver business results
I mean, really, why go about this in the first place? Many project managers are satisfied to
simply implement a project and ensure that it goes to fruition. They do not monitor
schedules and costs because, frankly, they have never been told to. Unfortunately, that is
not best practice. That is not where the industry is headed. The industry is headed toward
project managers who can clearly control all of their costs and all of their time. That does not
mean to make it cost-free, but it does mean that they are going to manage their costs to a
reasonable degree in order to identify where costs are being incurred and how to manage
them more effectively. We do it because they are the easiest things to measure on a project.
It is often very hard to measure just how satisfied a customer might be, but it is relatively
easy to measure cost and time. How close were we to schedule? How close were we to the
budget? It is what we do. It is the business results that we provide.
THE PROJECT LIFE CYCLE

................................................................
Where does scheduling and cost control begin? This is a difficult question. Ideally,
scheduling and cost control begins at the top of our diagram. It begins with defining the
2-6 A Project Managers Guide to Scheduing and Cost Control

.....
Requirements Review
project. Though most project managers I have spoken with over the years, however tell me
that they really don't get involved in the project until well after estimating and scheduling. In
fact most project managers in a recent survey claim to be assigned to projects somewhere
at the bottom of this diagram. If so, just so you understand, that is not best practice in project
management. The best practices in project management ensure that project managers are
actually involved in defining the project, in making sure they have a clear understanding of
what the project is and how it is being laid out. Other people are not doing that work ahead
of them. That is what best practice is. In the real world, we acknowledge that in many cases
you will not get brought in until it is time to develop the WBS or until it is actually down to
estimating and scheduling. In either case, as the project manager, scheduling and cost
control can begin virtually at any point on this cycle. It becomes our responsibility to do the
best job possible given the point where we are brought into the process.
REQUIREMENTS REVIEW
................................................................
Please refer to the Appendix and review Tool 1- "Project Requirements Document". This
document is extremely important for the simple reason - we are looking at stakeholders and
their stakes. We are looking at cost, schedule, and specification targets, and we are looking
at the acceptance criteria. To get that information takes quite a while, because think about
all the stakeholders that are involved in your processes and your projects. There are quite a
few.
As you look through your project, try to identify any number of people who might be
involved. Let’s look at it from the perspective of, say, the world-record house that we
mentioned earlier. If you are going to set a world record on building a home, try to think who
would be the major the stakeholders? You should have identified the family who is going to
move into the house, the project manager who is going to be building the house, the
construction crews, the painters, the landscapers—all the various participants become
stakeholders in that process. Unless you know what their stakes are, you cannot do a
thorough review of the requirements for that given home.
The cost, schedule, and specification targets are crystal clear. Those are the things we
manage against. They become the baseline for our project and the success criteria. If you
remember from Managing Projects in Organizations, one of the things you talked about was
managing by objective. In managing by objective one of the clear and most challenging

2 Scheduling and Cost Control - Exercise
elements is to ensure that you manage to a measurable criterion. Finding those measurable
criteria is no mean feat. It can be extremely challenging. So part of what you need to do in a
requirements review is make sure that you have requirements that you can actually live to,
requirements that you can actually work to, requirements that everybody who is participating
can understand and be involved in, requirements that you can walk away from when it is
over and know they are done. That is the hard part: knowing something is done. When is a
room painting job done? Does it match the chip or is it to customer satisfaction? Those are
two radically different ideas in terms of acceptance criteria. And they would often drive our
projects to either success or failure.
When you are doing a requirements review you need to make sure you have all the
requirements. “Brent, I do not get to do the requirements! That is done by other people in
the process.” If it has not been done before, somebody needs to ensure the requirements
are in place by the time that you take over and on most projects it is not that easy.
SCHEDULING AND COST CONTROL - EXERCISE

................................................................
One of the quickest and easiest ways to understand scheduling and cost control is seen in
action with the following example.
Our task will be to build 5-bedroom, 2-bath home with a poured slab foundation in world-
record time. What are some of the challenges you will face in this particular project? Please
list those challenges. As you do that, also consider the specific challenges with scheduling
and cost control that you would face during this project. And, think about controls you would
try to put in place—what would you do if you were managing this project to ensure it was
successful?
Specifically, we are looking for—
• Project challenges regarding scheduling and cost control in the world-record house
environment
• Tools that can be used to address those challenges
• Some of the benefits of using those tools
We would love to see the WBS as one of those tools, but that is not only what we are
looking for. We are also looking for the real mechanics that you would put in place to ensure

.....
Organizational Context for Scheduling and Cost Control- Exercise
that the house you built was constructed in world-record time. What tools might you use?
Specifically, what management tools? It is often not as easy to see what is needed, but by
using the following chart you are better able to get a complete view of the process. If you are
using this book and working towards PDU’s, please submit your assignment as directed.
Challenges Tools Benefits
ORGANIZATIONAL CONTEXT FOR SCHEDULING AND COST

CONTROL- EXERCISE
................................................................
What are your organization’s methods, tools, and documentation?
Here we would like you to send us a description of your organizational context for
scheduling and cost control. What are the methods you are using? What processes do you
have in place to deal with scheduling and cost control issues? If you have an in-house
methodology, simply cite the methodology. If you have a set of methods and processes that
you use, identify some specifics that stand out in your organization.
Also list some tools you are using. You obviously cannot be using every tool that is out
there, so specify what tools you do use in your organization.
And finally, does your organization use special documentation just for dealing with
scheduling and cost control? You might look to progress reports or other types of tracking
mechanisms that you have in place in your organization for dealing with scheduling and cost

2 Scheduling and Cost Control Documentation
control. If you are using this book and working towards PDU’s, please submit your
assignment as directed.
Methods Tools Documentation
................................................................
SCHEDULING AND COST CONTROL DOCUMENTATION
And have I got a list for you! Look at all these: the scope statement, the responsibility matrix,
the work breakdown structure, time and cost estimates, concept plans, project requirements
documents. As you look at all this documentation you may wonder, is that all we are
pushing—paper? Are we simply trying to encourage you to generate more paper and more
reports? Not at all. What we are trying to do is instill some best practice and give you a
sense of what best practice is.
These documents represent the body of what many organizations do in terms of best
practices in scheduling and cost control. Each one of these is vital. In many cases they are
incorporated into other documents. The scope statement, for example, may readily be
incorporated as part of the project charter; that is not uncommon at all. The conceptual
plans may be attached to that as well, as might be time and cost estimates. A responsibility
matrix is an interesting animal in that many tools are now going to that as being a key
feature. In fact, one tool, Cascade software by Mantix, actually uses that as the default view
for looking at projects. The responsibility matrix—who is doing what for whom—is vital to
any good project. The work breakdown structure, the PRD [project requirements

.....
Work Breakdown Structure Review
document]—those documents should all be in place to ensure good scheduling and cost
control as the project progresses.
Once again, you may doubt that your organization has the wherewithal to put these
together, or you may simply say, “By the time I get a project, all of this has already been
generated.” Whether that is the case or not, you still need to review this information and
ensure it is in place, whether you created it or someone else did. It is all equally vital. And it
all has to be there for good scheduling and cost control. In a moment, we are going to talk
about the world-record house.
WORK BREAKDOWN STRUCTURE REVIEW

................................................................
The following bullets are key in trying to understand the WBS.
• Does the WBS define the whole project?

• Are the work packages SMART?
• Will the tasks support the responsibility matrix?
• Will the WBS support estimates and budgets?
As you look at this particular section, I want you to think about your own WBS and ask
yourself if you meet these criteria. Does your work breakdown structure define the entire
project? That means everything. Have you covered the entire package? Are the work
packages specific, measurable, achievable, realistic, and time constrained? Will the tasks
support a responsibility matrix? In other words, do we have folks to do the job? Are
personnel available? And finally, will the WBS support the estimates and the budget?
I told you a moment ago that we were going to take another look at the world record house.
Well, now we are. The big question to you is how quickly could you do it? Three hundred
and fifty people, the best in their craft, working together to build a world-record house. They
are working diligently, they have done it before—they did a practice home 1 week earlier
together as a team—and now they have the opportunity with all the materials on the job,
with everything at the ready, all the planning done. They even have quick cure concrete that
can set in 45 minutes. And they have the inspectors on hand to do the work.

2 Work Breakdown Structure Review
My question to you is how quickly could they do it? How quickly they can get the job done
from the time the workers start running out onto the job site to the time the house is
inspected and the permit is finaled out. How long is that going to take? Remember there are
other criteria. What do you think? Three days? Two days? Less than a day? Eight hours?
Six hours?
Well, the previous record was just over 4 hours and 10 minutes, and that was set just
several years ago. The most recent record, however, was set in San Diego, California, and
it was set not that long ago. When they set the new world record, they did something pretty
impressive: they had a schedule that was going to go 3 hours and 39 minutes. They beat
that schedule. They beat that schedule handsomely. They finished the world-record house
in 2 hours and 53 minutes. Two hours and 53 minutes. In large part, they did it because they
had all of this other information in place up front. They had done tons of planning, and they
were ready to put that planning to work. And they did so—very, very effectively.
WORK BREAKDOWN STRUCTURE REMINDERS

• Start with a verb
• Structure the WBS to your level of control
• Ensure that each work package accomplishes a discrete element of work
• Organize the WBS to—
• Allow for realistic estimating
• Represent one type of work
• Allow assignment to a single organizational unit or for exclusive
responsibility
• Represent own level of control
• Be geographically separate
In this section I like to share a little insight called 60-second consulting. It is one of those fun
things you can do as a project manager if somebody else asks you to review their project. If
they call you in to take a look at it, simply do what I call 60-second consulting. Do a quick
scan of the WBS and try to identify, specifically, where are there some shortcomings? What
they are asking you to do, specifically, is to find places where there is a lack of clarity. One
way to do that is with the first bullet on this page—start with a verb. If you can find spots
where there is not a verb-object relationship, particularly at the work package level, you may
have identified some shortcomings in terms of clarity on their projects. It takes about 60
seconds to scan an entire WBS and look for verb-object relationships. It is often pretty

.....
Work Breakdown Structure Review
impressive if you can take 200 activities in and then identify a problem in less than a minute
flat.
The other thing you want to make sure of is that the WBS, the work breakdown structure, is
built to their level of control or your level of control. How far down do you control? Some of
us control down to the hour or the week. Others control down to the minute. That is what
they were doing on the 4-hour house or the 2-hour-and-53-minute house. Structure the
WBS down to your level of control.
Also, you want to make sure that each work package actually gets something done, that it is
going somewhere, that it is going to get something accomplished, that it is not some vague
administrative function and that it actually gets work done.
And finally, look at the WBS and how you can organize it. There are a variety of ways to do
that, but you need to make sure that it makes good common sense. If it does not make good
common sense, you may need to break it down just a little bit further to achieve all of the
subbullets that are listed here: to allow for realistic estimating, to represent a single type of
work, to allow assignment to a single organization, to represent our real levels of control,
and to be geographically separate from any organizations. That creates an extra level on
the WBS that would not otherwise exist.

2 Work Breakdown Structure Review

R ESOURCE A LLOCATION & E STIMATING
...................................
3
.....
OBJECTIVES
• Apply different estimating tools in the project management process

• Define estimating variables and their roles in the project management process
• Develop a bottom-up estimate
• Critique at least three types of estimates for accuracy
• Assign and control project responsibility using resource allocation
• Integrate estimating with the WBS for scheduling and cost control data
• Determine variables associated with estimating for baseline management
We have a lot of things we are going to try to accomplish by the end of this chapter. Toward
that end, the one big objective I would like you to keep in mind is that you are going to learn
ways to work with some different tools to develop your estimates. That does not mean that
you have to be able to use them all. Sometimes estimates will be applied that, frankly, are
not appropriate to the given project. People will try to apply a detailed estimate in a situation
where detailed information is not available. Do not go down that road. It is very important
that you use the proper tools at the proper time.
RESOURCE PLANNING
................................................................
The following are some fundamental questions that you need to ask yourself each time you
start the resource planning phase of a project. Failure to ask all the right resource planning
questions will always lead to poor resource planning.
• Who and what do we need?
• Who and what can do the work?
• Who and what can we get?

RESOURCE ALLOCATION & ESTIMATING
3 Resource Planning
• What level of excellence and competence is essential?

• How will we use them?
• How will they affect schedules and costs?
I like this section because, well, it is one that I deal with on a daily basis in my real life. It is
one that comes to mind for most of us as we deal with the ordinary problems of project
management. Very recently I had some work done in my own home, and as that work was
getting done, I marveled at how well, how quickly, how effectively the workmen could
accomplish what needed to be done inside my house. Specifically, there was some work
being performed to repair a hole in the wall. I had spent hours with spackle and plaster
trying to fix that hole. It took them a grand total of about 8 minutes to get the job done. It was
the difference in resources that made the difference. These were master resources: people
who knew their craft well.
When it came down to that type of work, it broke down to the two types of resources I often
look at on a project. There are Einstein’s on every project. Einstein is the person everybody
wants to have on their project—they know the process, they know the project, they know the
people, they can do the job very effectively. Unfortunately, every organization has a very
limited number of Einstein’s.
By contrast, there are also those individuals that I will refer to as Beavis. Beavis is, well,
Beavis. They are not well trained, not highly skilled, do not have a lot of background and
don’t have a great understanding of what needs to be done. And frankly, that is a real
challenge. It becomes a major problem. Toward that end, we need to make sure that if we
are using Beavis, we are using him wisely. Beavis comes along and can be a great asset if
it is work that has never been done before for which someone can be trained. If that is the
case, then there is hope and promise that Beavis may be the appropriate resource.
In some cases, however, Beavis will not be the appropriate resource, and we need to go out
and beg for Einstein. It happens. There are times when nobody but Einstein will do. But we
need to choose our battles carefully when it comes to resource planning. Picking the wrong
resource or identifying Einstein as the only solution too frequently can often leave us without
the resources that we so desperately need.

.....
Resource/Responsibility Matrix
RESOURCE/RESPONSIBILITY MATRIX
................................................................
As I look at this document, I am reminded of a project my organization was involved in with
the Miami Port Authority. We were doing an initial process review and trying to identify who
was responsible for what: who would be doing what for whom. As we went through that
review, we were trying to settle who was going to be handling which tasks. During the
review, the first task clearly went to the Chief Engineer. The second task was assigned to
both 1st Officer and Navigator. The third task we realized had been assigned to absolutely
no one. As you can imagine, the third was not getting done, but neither were the tasks that
were assigned to 1st Officer and Navigator.
Stores Provisions
Chief Engineer
Port Authority
Navigator
1st Office
Captain
Purser
Milestone/Task
Chart Route C R/A I I
Order Provisions C C R/A
Order Fuel C A R
Gain Approval to leave A R R R
Set Sail A C R I
Take Control from Pilot R/A I I
R = Responsible
A = Accountable
C = Consulted
I = Keep Informed
That’s the trick. When it comes to a responsibility matrix, you need to make sure that all of
the tasks are assigned responsibility with a single individual. That is very important,
because in many cases we want to ascribe those responsibilities out to multiple individuals.

3 Resources As Estimating Sources
You really cannot afford to do that. By doing that, you usurp the authority of a single
individual to actually get the job done. You need to have one person with that responsibility.
Just as you want to be the one person with the responsibility for your project, you need to
have one person responsible for each task. You can have multiple people doing the task,
but one person must have ultimate responsibility. And who assigns that responsibility? You
do.
RESOURCES AS ESTIMATING SOURCES

................................................................
Who provides the best rough estimates?
• Outside sources
• Those who know the work
• Those who are accountable
I was teaching this program recently in a public university and got into a heated discussion
on just this one, single topic. Who gives you the best information for your estimates?
Ultimately we came to the conclusion that for any given estimate, there is going to be a
different answer as to who is the best resource. You will need to consider all these possible
sources before you settle on one as being the best for a given task or a given activity.
As you look down the list, you can see some places where the information would best come
from outside sources. PMI® is big on outside sources right now, saying that they can
provide more objective estimates. The estimates come from people who have less of a
stake in the project or less of a stake in a given estimate or given activity. That is fair and
reasonable.
But there are going to be times when the best estimate is indeed going to come from those
who do the work. The best estimate comes from those who do the work in situations where
those individuals are doing new work—it has never been done before. They are going to be
the ones performing the work, and they have a good sense of exactly what the parameters
of that work are. Others will not be able to develop such a comprehensive estimate. Hence,
they become the best estimators on those particular tasks.
Those who are accountable are going to give a good estimate if they feel like they are
empowered to come in with an estimate that is indeed a little low or a little high. If we punish

.....
Resources As Estimating Sources
bad estimates in our organization, those who are accountable are going to pad their
estimates. It is inevitable. They will provide some additional pad in there that will not
necessarily occur or will not necessarily come to pass. And the reason will be because,
frankly, they do not want to be punished for a bad estimate. If we do not punish for bad
estimates, we are likely to get an accurate estimate from those who are accountable.
Also it says “those who know the work.” In some cases, those who are doing the work have
never done it before. They do not know the pitfalls; at the same time, they do not know the
shortcuts. If they are going to be trained and informed by those who do have that
information, then those who know the work can probably provide a better estimate.
Definitions
Cost estimating: Estimating the costs of the resources needed to complete project activities.
Cost budgeting: Allocating the cost estimates to individual project components so they can
be measured or managed.
7
Project Cost
Management
7.1 7.2 7.3 7.4

Resource Cost Cost Cost
Planning Estimating Budgeting Control
Cost estimating and cost budgeting. It is important to make the distinction between these
two terms. And if your organization does not, it might be an opportunity for you to educate
them somewhat as to what the differences in these terms are.
The difference is that “cost estimating” is when you are planning. It is working through the
numbers. It is coming up with a logical, sensible number as to how much the overall project
is going to cost. Ultimately “cost budgeting” is when you take those costs you have defined
as going to be incurred against the project, and you are now allocating them within a budget.
There is a big difference between the two: estimating is a planning function, budgeting is an
allocation function. They are two radically different tasks. If you are strictly doing cost
estimating, then you are not necessarily saying where the money is going to come from.
However, if you are exclusively doing cost budgeting, then you are waiting to find out where

3 Estimates
the money is coming from and how it is going to be disbursed out of the corporate or
organizational budget. That is the difference between those two.
In many cases the line is blurred because organizations want to have some clear-cut
definition as to where the money is coming from as they build the estimates. This has a
tendency to lead to dishonest estimates. People will tend to estimate based on the money
available. Instead, what we should do is try to define exactly what the work is, and then,
based on that information and that information alone, we should build a cost estimate. Then
we can figure out whether or not it fits into the budget or whether or not we are going to have
to make adjustments to scope to make it fit into the budget, rather than the other way
around.
ESTIMATES
................................................................
WBS Level Estimate Name(s) Precision When to Use
and Range
Top Levels Portfolio, conceptual, Order of When only very basic information is
factored, feasibility, Magnitude, available or needed
SWAG +75, -25%
Middle Preliminary, design, Budget When resource materials, expense,
Summary appropriation , +25, -10% and overhead information is available;
Levels and the objective is clearly defined
All Levels Finalized, expense, Definitive, When detailed information is available
engineering +10, -5%
For those of you doing some preparation for the PMP® certification exam, this is an
important section. It is one you want to memorize because it incorporates a lot of
information that they [the Project Management Institute] expect you to know. They expect
you to know the various levels of estimating, and they also expect you to know the precision,
the range, and some of the different estimate names.
The top-level estimates are the broad estimates. Those are the estimates in your
organization where they say those magic words: “Do not worry. I am not going to hold you to
this. Just give me a ballpark, just give me a conceptual estimate, just a quickie, just a
SWAG,” (which stands for scientific, wild anatomical guess).

.....
The Rules of Estimating
The reason we use these top-level estimates is to get a general sense of where the project
is going. Is this something we can even think about doing within our organization, given its
current parameters? That is what those estimates are good for. They are order-of-
magnitude accurate, which means they could go as high as 75% above what we guessed or
as low as 25% below what we guessed, according to PMI® analysis.
The next level are the budget estimates: the mid-level estimates, preliminary estimates,
design estimates, appropriation estimates. They are the estimates that are built on some of
the facts. This is often built on a project requirements document but not a WBS. It is built on
a clear understanding of exactly what the work is going to entail and what areas are going to
be involved in the development of this project or product. As you go through this type of
estimate you are building a budget or you are preparing for a budget, and these have an
accuracy level of +25% to -10%.
Down at the nitty-gritty, at the detail level, we have the finalized estimate, the engineering
estimate, the grass-roots estimate. This is a bottom-up estimate. It is definitive. It is an
estimate built on the WBS—the work breakdown structure, the best available tool for
building an estimate. A work breakdown structure or WBS estimate comes up from the work
package—where the work has been assigned, activity by activity, and task by task. Each
one is allocated a certain set of resources, of materials costs, of any fixed costs, and then
aggregated to come up with a total estimate for the project. This is considered to be the
most accurate estimate. It is indeed definitive.
THE RULES OF ESTIMATING

................................................................
• Use the most accurate method available
• Communicate the level of precision
• Ensure project controls reflect the level of precision planned
• Involve the team
• Assess the environment
• Base estimates on history
• Use standards (if available)
• Do not back into estimates
• Do not pad the estimates

3 The Rules of Estimating
If you are using this book and working towards PDU’s, you should be to be prepared to
submit some information regarding this section. Specifically, as we go through these rules,
what I am going to ask you to do is to identify any of these rules that your organization
regularly breaks and the rationale they use for breaking them.
Specifically, what we are looking for is, why would an organization want to break the rules? I
will give you the rationales I have heard in the past, and perhaps some of them will ring
familiar. On the first bullet, using the most accurate method, it actually goes to the second
one, which is communicating the level of precision. Most organizations do not want to use
the most accurate method available because they find out that they cannot handle the
numbers that are coming up. They prefer the ballpark estimate because it is fuzzier, it is less
defined. And because no one bothers to communicate the level of precision in most cases, it
becomes more comfortable for them to take that fuzzy estimate.
The third bullet ensures project controls reflect the level of precision that has been planned.
If you are planning from a ballpark perspective, from a very broad perspective, there is no
need for minute, highly micro-managed controls. They do not have to be there.
Involving the team in the estimates is important, even if you are not having the team develop
the estimates, even if they are being developed from the outside. Assess the environment.
Recognize that a 4-hour house, if you will, being built in Arizona is not the same as a world-
record house being built in, say, Beaver Creek, Oregon. They are not the same things. They
are radically different.
Base the estimates on history. Do not assume that history will somehow change itself, that it
is somehow going to be modified. Use standards if they are available. If there are general
practices that we follow on a regular basis, use them. Use them frequently. Use them well,
but employ them in the environment in which they are supposed to be used. Do not try and
use them toward other ends.
The last two are the ones that most organizations violate most regularly. Do not back into
the estimates, which we do very often, and do not pad the estimates, adding budget to those
estimates solely for the sake of ensuring that we have enough funds. We need to be honest
about our estimates, and if we are going to put additional funding in there, it is going to be in
the form of contingency, not in the form of pad. Pad disappears, and we will talk about that a
little bit later.

.....
Exercise
EXERCISE
................................................................
Now as we have gone through this list, you should have identified one or two that your
organization has a tendency to do. If you are using this book and working towards PDU’s,
please submit your assignment as directed.
ESTIMATING METHODS: ANALOGY AND VENDOR BIDS

................................................................
When evaluating methods use the following steps -
1 Evaluate Project
2 Find Analogous Project
3 Assess Analogous Qualities
4 Evaluate Price/Cost of Previous Project
5 Apply to New Project
It is interesting: in my career I have had the good fortune of working for almost all the major
telecommunications companies. It is surprising how frequently they use this method to
establish their baseline budgets. They use analogy and vendor bids. They use the vendor
bids of their competition. They try to best assess what the competition is going to come in at
on a given project, and then they attempt to beat that budget by a particular dollar figure. It is
compelling because they are working in completely different environments. It may not even
make sense for them to make those kinds of comparisons, and yet in some cases they go
ahead and do just that.
It can work out. It can work out by virtue of the fact that sometimes they do find, indeed,
analogous projects. They find analogous projects and they find out that they have qualities
that are the same, that they are working in an analogous environment, and that they can
make honest and fair comparisons.
Unfortunately, the flip side is also true. In many cases they develop these elaborate
estimates based on exactly what the competition is doing, but they are working in
completely different environments.

3 Estimating Methods: Parametric Modeling
Analogy and vendor bids are good for getting a sense of where the project ought to fall
within a given range. But because the environment from company to company and from
organization to organization is so radically different, it is impossible to make wholly
analogous estimates. You cannot make a purely analogous estimate from one organization
to the next or from one project to the next. The best use of analogy estimating is by virtue of
doing estimates against individual tasks or components of the project. There you can make
the analogies far more finite, and by doing that, you come up with up with a far better
estimate, a far more accurate number.
................................................................
ESTIMATING METHODS: PARAMETRIC MODELING
I really enjoy parametric models, and the reason is because I have been living them a lot
lately. As we have had different vendors come in to look at doing some repairs on our home,
I have heard every parametric model you can possibly imagine. We would like to put on an
addition—how many square feet is it going to be? And how many stories? They run it
through a model; they come up with a clear-cut estimate.
When I ask for painting jobs, they say, how big are the walls, and how tall are they? They
are gathering that information to develop a parametric estimate based on the number of
square feet that have to be painted, built, constructed, or repaired. That is how they are
developing their estimates—using parametric models.
Parametric models are perhaps most famous for their applications in software and one of
the Holy Grails of software estimating: function point analysis. The ability to take different
components of a software estimate versus the number of lines of code that ultimately will be
written to come up with a clear-cut estimate as to how much the project is going to cost.
Those are parametric models. Parametric models are used when the information is
historically available, when there have been clear analogous efforts to which the parametric
model can be applied.
The problem is that most organizations do not have the time or energy to really build a
proper parametric model. It takes a lot of time and a large investment. Because technology
is changing so rapidly, parametric models often do not apply for one year or even one
season to the next. Be very cautious in using parametric models. If you are going to use
one, make sure you have checked it for the following criteria: ensure that it is valuable and

.....
Budget Method
applicable, that it has historic integrity, and that it just makes sense in terms of your
environment.
BUDGET METHOD
................................................................
In developing estimates, this is perhaps the most common for many of us. It is the one that
is familiar. We identify the number of resources we are going to get for a given activity, and
we identify just how long we are going to need them.
Normally we get resources for a large component of, or at least a segment of, our projects;
we do not get them activity by activity. Thus, this becomes a very accurate method of
developing an estimate. Not quite as accurate as the bottom-up estimate—one that is
developed definitively from the work package—but it is a very accurate method because it
reflects the realities of our organizations. We get our resources for a distinct period of time,
and their costs will be assigned to us for that period of time.
In this scenario, you can see we are going to be using a number of carpenters, painters,
roofers, plumbers, electricians, and so forth. We have all these resources at our disposal.
What it does not do is give us extensive control over what these individual resources are
going to be using and doing during the life of the project. It does not give us the opportunity
to identify, specifically, what tasks they are going to be assigned to individually.
What it does do, however, is add two items down at the bottom: direct costs and indirect
costs. Direct costs are normally accounted for somewhere in the project. The indirect costs,
however, tend to be a little fuzzier. Indirect costs sometimes do not get accounted for. They
sometimes fall out to other areas. Indirect costs tend to be ignored, and the budget method
does take them into account. That has some very definite value because, otherwise, they
could be lost.

3 Budget Estimating––Types of Costs
BUDGET ESTIMATING––TYPES OF COSTS

................................................................
BUDGET ESTIMATING––TYPES OF COSTS
Direct costs
o Expenses
§ Fees
§ Travel
§ Incidentals
o Labor
§ Direct
§ Contract
o Materials and Equipment
Indirect costs
o General
o Administrative
Fixed costs
Variable costs
Semi variable costs
There are a variety of different types of costs you will need to take into account in any good
budget. Among them, direct and indirect. Those are the two obvious categories. Either it is
something that can be directly attributed to the project, or something that is indirect—
something that cannot be narrowed down to just that given project.
Direct costs. Some of the key examples here are the expenses of fees, travel, or incidentals;
labor—direct and contract labor; and materials and equipment. I should note here that travel
is the most frequently and most consistently underestimated expense on projects. Normally,
when we are developing travel estimates we tend to develop them based on a limited
amount of travel. By a “limited amount of travel” I mean we are planning our travel well when
we are doing our estimates. We are planning for travel 2 to 3 weeks in advance, we are
going to be getting discount fares, we are going to make sure we are going to get
nonrefundables that are going to be extremely cheap—we are planning our travel well.
Invariably, however, travel is the one component that tends to change. Schedules get
changed at the last minute, and as a result, we tend to lose track of how much extra it is
going to cost us. A last-minute plane ticket is far more expensive than a plane ticket that is
purchased 3 weeks in advance. Labor costs tend to remain somewhat stable, although in
many cases we will add labor toward the end of a project. Materials and equipment costs
tend to be somewhat stable as well.

.....
Contingency
As you look at the indirect costs, those are normally factored in as a function of the other
costs—as a function of our direct costs.
Fixed costs, variable, and semi variable are terms that will show up on the PMI® exam,
although technically, all the costs that I have cited up to this point have been either fixed,
variable, or semi variable. Fixed cost is something that once you buy it, it is there for the
duration of the project. Variable costs are costs like our labor: they come at an hourly rate or
a daily rate, or based on usage. Semi variable costs are costs that have a fixed component,
but the remainder tends to be variable, based on usage or the amount that is being
consumed.
Those are the various types of costs you need to consider when developing a budget
estimate. The advantage to developing a budget estimate considering all these types of
costs is that each time you ask, have we considered all our direct costs? have we
considered all our labor costs? have we considered all our fee costs, travel costs, incidental
costs?—you tend to find one or two more that you may have otherwise missed. By
identifying those and consistently asking those questions in categories, you tend to explore
and brainstorm out a few more of those numbers that you might have otherwise missed.
CONTINGENCY
................................................................
Contingency is set aside so that we can effectively manage our projects. It is one of the
major bones of contention in most organizations about project management, because most
organizations will not allow for contingency. They see it as potentially dangerous. They see
it as a slush fund for project managers.
It is our job to educate upper management on what contingency is properly used for. It is
properly used when the budget underlying it is honest, when the information on that bottom
line—the one that is marked as “Budget” on this section—clearly is a true and honest
budget. There is no pad; there is no extra worked in there. It is an honest, clean budget
estimate provided by the project team.
The range between that budget and the reserve is what has been identified as the
contingency. That is how much extra it may take, based on the risks that have been
identified, to accomplish the project effectively. That is what that range is for.

3 Bottom-Up Method: Detailed Estimates
The advantage to contingency over simply working it in as pad, activity by activity: when it is
hidden in there as pad, or what I like to call “fudge,” fudge gets eaten. Fudge is consumed.
Project managers do not know where fudge went. If you add a dollar here and an hour there
to activities, it never gets tracked. If you use this kind of approach, where budget and
contingency are always being tracked, it enables the project manager to keep track of
exactly what has gone wrong and what has generated extra costs within the project. That is
what contingency is all about. That is why we use contingency. It promotes honesty. It
encourages the project manager to develop an honest budget, and it allows the project
manager to track exactly what has gone right and which risks have been encountered
during the project. That is what contingency is all about.
BOTTOM-UP METHOD: DETAILED ESTIMATES

................................................................
Filling A
Vacant Position
The
The Job The Selection
Candidate
The Need Job Spec Attracting Short Listing The Interview Post Selection
Advertising
Budget The Job Criteria Venue Terms
Content
Advertising Review
Options Training Interview Induction
Location Resume's
Short list Tour Relocation

Approval Person
Decision

.....
Bottom-Up Method: Detailed Estimates
As you examine this particular example, you can see how the costs have been rolled up
from the work package. As you go through this, you will be able to identify that none of the
costs—and I stress this—none of the costs has been assigned at the phase level or at the
WBS summary levels. All the costs have stemmed from the work package level. That is vital
to understand how to do a good bottom-up estimate.
There is a temptation in many of the software packages to go ahead and incorporate some
costs at the phase level because they are incurred across an entire phase. That is not an
accurate way of doing an estimate, because a phase simply expresses a group of activities.
If there is actual work to be done, it should be ascribed as a work package. All work should
be defined down to the work package level; thus, no resources should be assigned and no
costs should be assigned up at the phase level or the summary level or at the project level.
There is a temptation to do that simply to expediently track certain costs, but I would advise
you instead to find a way to develop those as work packages, because that is where the
work really gets done. And that is the best way to build an honest bottom-up estimate.
TIPS ON BUILDING DETAILED ESTIMATES

• Focus on controllable costs
• Obtain timely information
• Control implementation expense
In many cases you may be challenged on a detailed estimate because, frankly, it comes out
as being too darn expensive. There is a reason for that. Detailed estimates tend to catch the
details, and as a result they identify some of the real costs that are going to be incurred, the
costs that otherwise might not show up until the very far end of the project. Thus, in building
a detailed estimate we often come in with higher estimates than we came in with previously.
It becomes important at that point to begin analyzing how can we make these estimates
palatable to our organization—that is still part of our job. To do that, these are three tips that
can help you out a great deal.
One is to focus on the costs we really can control. What can you control? The cost of
resource hours is within your control. The cost of a fixed utility is not. Obtain timely
information. Make sure the information you have reflects today’s realities, not the realities of
a similar project done several months or years ago.

3 Estimating Durations
And we can look at controlling the implementation expenses. How much is this really going
to cost once we begin to put it to work? We may be able to identify by controlling our
implementation expenses that we are in fact making the project itself, particularly the design
and planning phases, much more reasonable in the eyes of our client.
ESTIMATING DURATIONS
................................................................
There was a paper presented at the PMI® National Symposium several years ago that
talked about 50—count them, 50—different ways to describe time. We are not going to look
at quite that many here, but it is kind of compelling that there are that many different ways to
look at the concept of time.
Here we are looking at the difference between working time, personal time, calendar time,
and clock time. When you think of calendar time, that means how many days have passed,
and that means real time passage. Saturdays and Sundays count.
In a workday week, Saturdays and Sundays normally do not count. We normally only
account for Monday, Tuesday, Wednesday, Thursday, and Friday when we are talking
about a week.
It is important to make that distinction. Because if you say, “This is going to take a week,” is
that 5 days of effort or is that 7 days of effort? Seven days of effort is different from 5 days of
effort. Seven days of effort means a week and a half if you are talking about working time.
Personal time: What time am I really going to be working with on my calendar? Some of us
take our birthday off. Some people take other holidays off. Some people declare personal
holidays with their own families and friends. Others tend to stick to tradition and take only
traditional holidays off. The differences in personal time are going to be as radical as the
difference between calendar time, from city to city, country to country. There are going to be
some significant differences.
If you have ever tried to do business in Europe during any of the major holiday times, which
are July and August, you know exactly what I am referring to. Europe tends to shut down in
July and August. If you are estimating durations across that time, you had better be
estimating them in clock time rather than in working time, because not a lot of work is going
to get done. Make those distinctions carefully.

.....
Estimating Durations
DURATION CONSIDERATIONS
• Working time: Activity duration based on number of hours in a workday or work
week (24 hours = 3 days)
• Effort hours: Resource hours required to complete a task (24 hours = 3 resource
days)
• Elapsed time: Calendar durations including weekends, holidays, and breaks (24
hours = 1 day)
• Productivity: Rate at which work is produced
• Availability: Resource present and ready to work
• Contiguous duration: Work time that is not interrupted
• Interruptible duration: Work time that may be interrupted
Some of the things we just discussed in the previous section are also discussed here.
Working time: How much time is actually going to be accomplished? Effort hours: How
many hours are going to be required to complete a task? Tasks may require 40 effort hours
but may be accomplished in 1 day if we have 5 people available to work that 8-hour shift.
Elapsed time: The calendar durations, including the weekends; the holidays; all the various
components that go into elapsed time. That is the calendar time we were talking about.
Productivity also becomes an important consideration. How well are we producing? Einstein
may produce at 100%; Beavis may only produce at about 50%. It makes a difference.
Availability: Beavis may have 100% availability; Einstein may only be available 25% of the
time. It is going to make a difference as to how quickly the job can get done.
Contiguous duration is when an activity goes uninterrupted.
Interruptible duration is work time that might be interrupted where we can start a task, take a
break from it, and come back to it without any significant change in the level of effort.
Knowing these various components to duration are going to go a long way toward
determining what kind of answer we give to the customer when they ask that magic
question, when are you going to be done? Because almost invariably, that is the question
that gets asked.

3 Establishing Task Durations
ESTABLISHING TASK DURATIONS

................................................................
As with everything we have discussed up to this point, establishing task durations is a
function of how well have we considered all the components that go into establishing how
long something is going to take. Have we taken the completion criteria into account? Are
they unambiguous and realistic? Can we clearly identify what has to be done to make this
task finished? Have we identified the resources that are actually going to be available when
we want to do the task? And have we identified what kind of time we are working under? Is
it contiguous duration or interruptible duration? Can we afford to have someone working
part-time on this? Those are critical issues before you ever establish just how long
something is going to take.
PRODUCTIVITY AND AVAILABILITY IN RESOURCE-DRIVEN

ESTIMATES
................................................................
As you go to calculate these numbers, you will want to consider a number of factors. One is,
how much does a resource cost? Then, how much effort is it going to take to do the task?
How productive is the resource? And how available is that resource? With those pieces of
information, you can do a lot in terms of establishing the numbers for resource-driven
estimates. Specifically what you can do is establish the cost. The cost is a function of
determining how much effort is this task going to take. It takes a master painter 1 hour to
paint a room the size of my office. That is 1 hour for a master painter. That is 1 hour of effort.
They are 100% productive. However, if you give me the paintbrush, it is going to take me a
lot longer. My productivity is perhaps half of that of a master painter. So if you take the effort
(which is 1 hour of effort hours) and you take my productivity (which is 50%), divide that 1
hour by that 50%, and you come up with 2 hours, times my unit cost versus the master
painter’s unit cost. That is how we are going to get the cost for our estimates if we are doing
them properly and we are doing them in a resource-driven environment.
If we are trying to establish the duration—in other words, how long is it going to take to get a
task done?—we take the level of effort (in this case, 1 hour), divide it by the productivity (in
my case, 50% productive, so it is going to take me 2 hours to paint this room) against my
availability (I am only available 25% of the time). So it is going to take 8 hours for this work

.....
Program Evaluation and Review Technique (PERT)
to ever get accomplished. That is because we have now divided the effort over the
productivity by my availability. All those factors have to be taken into consideration when
you are dealing with resource-driven estimates.
PROGRAM EVALUATION AND REVIEW TECHNIQUE (PERT)

................................................................
You have probably heard any number of times a network diagram referred to as a PERT
diagram. Nine out of 10 times that is actually a misnomer. A PERT diagram is one that
incorporates the data from the formula found on this section. That is the PERT formula—the
Program Evaluation and Review Technique formula. It is designed to factor risk into our
schedules. What we do is we take the optimistic schedule, plus 4 times the most likely
schedule, plus the pessimistic schedule, and divide it by 6.
Optimistic + (4 X Most Likely) + Pessimistic

6
3 Days + (4 X 5 Days) + 9 Days

6
In the example here, we have 3 days, plus 4 times 5 days, plus 9 days, divided by 6. When
you are using the Program Evaluation and Review Technique, you are taking into account
how good things can get as well as how bad things can get. Almost invariably, using PERT
estimates drives us toward higher numbers, higher durations. The reason is because things
can get almost infinitely bad. They cannot get infinitely good. Thus, we wind up with
estimates that tend to be somewhat higher than the most likely estimates. That tends to
make our estimating a little more realistic.

3 Standard Deviation in PERT Estimates
STANDARD DEVIATION IN PERT ESTIMATES

................................................................
Pessimistic - Optimistic
6
Standard
Deviation
1 3 6 9 12
9-3
6
In developing PERT estimates, it is important to recognize where the “6” comes from. The
problem is there is little agreement on where it does come from. Some will argue it is a
function of triangular distribution. Others say it is a function of standard deviation—the fact
that 95% of the instances, or the most likely occurrences, are accounted for within 2
standard deviations, thus accounting for 4 spots from either side of the mean. The optimistic
and the pessimistic become the outliers.
The other account is for Runge Katta. That is a mathematical equation that is pretty involved
and, frankly, more than you need to know as a project manager.

.....
Standard Deviation for a Path Using PERT
What you do need to understand is that PERT takes into account a range of possibilities.
And with the range of possibilities, it is possible to establish what kind of deviations we can
anticipate: How far from that most likely estimate are we probably going to wind up? Or how
far from the mean estimate, the PERT estimate, are we going to wind up?
With standard deviation in PERT, what we first do is establish PERT using the formula from
the previous page. We take the optimistic and the pessimistic and 4 times the most likely,
and divide it by 6. That gives us our PERT mean. Now all we have to do is establish the
standard deviation. On this section we have standard deviation formula: pessimistic, minus
the optimistic, divided by 6. Notice it does not even take the most likely into account. This
gives us a sense of the range of risk. How dramatic is it? How far afield are those two
estimates? And that is how we come up with standard deviation.
If you are taking the PMI® exam, you will want to know this, and you will also want to know
just what standard deviations mean. One standard deviation takes into account about 68%
of the instances. Two standard deviations accounts for about 95%. Three standard
deviations takes you out to over 98%.
STANDARD DEVIATION FOR A PATH USING PERT

................................................................

3 Time-Constrained Process
Specifically what you do when using PERT and standard deviation in PERT against a whole
path: you take the standard deviations of each activity on the critical path and you square
them; then you simply add the squares together and take the square root of the sum of the
squares. Well, while that is a mouthful, what it does is give you a sense of the range of risk
for an entire path. It tends to be narrower than if we simply added all the activities together.
The reason it is narrower is because we do not expect all the activities to fall out to their
worse case scenarios. We do not expect them all to be just as bad as they can get. We
expect some to come out a little better than normal, some to come out a little worse than
normal, and most will fall near the most likely. Thus, standard deviation for a path using
PERT narrows down the risk and gives us a realistic expectation of just how things are
going to wind up in our final project.
TIME-CONSTRAINED PROCESS
................................................................
Define
Select WBS Establish
Completion
Activity Duration
Criteria
Identify Calculate
Add Other
Resources and Resource
Related Costs
Technical Effort Costs
In order to honestly schedule any project, you must set out at first by establishing whether
you are using a time-constrained process or a resource-constrained process. It is going to
make all the difference in the world as to how your schedule turns out. Look at the world-
record house and what they did there. When it came to that particular situation, it was a
time-constrained process. They had the activities, they defined the completion criteria for
those activities, they established durations for those activities, and then they tried to figure
out ways to make them shorter. How many workers would it take? They identified the
resources and the technical effort, as many as it would take to meet those time constraints,
then calculated the resource costs and added any other related costs. In their case, the
related costs became much higher by virtue of the fact that they were indeed time
constrained. They added extra resources, including material resources as well as human

.....
Resource-Constrained Process
resources, to ensure that they could meet those time constraints. Time was the driver, and it
makes all the difference in the world when you are establishing what your costs are going to
be—whether they are going to be time constrained or resource constrained.
RESOURCE-CONSTRAINED PROCESS
................................................................
Define Identify
Select WBS
Completion Resources and
Activity
Criteria Technical Effort
Translate Calculate
Add Other
Effort Into Resource
Related Costs
Duration Costs
While we just finished the example of a time-constrained process with the world-record
house, let’s look at a resource constrained process because, in reality, this is where most of
us live. This is where most of us do our day-to-day work. We have the same activities in
terms of selecting the WBS activity and defining the completion criteria. What changes here
is that we identify the resources and the technical effort first. We identify them first and then
translate that level of effort into the duration. Not the other way around. We do not set the
duration first.
By doing this, what it enables us to do is to work from a realistic level of resources. How
many people are we going to have available to us at any given time on the project? Who is
going to be working, and who is going to be working at what time? That is what is driving this
particular schedule. If you only have one resource, it is going to take longer than if you have
200 or 300, in most cases. However, when you are doing a resource constrained schedule,
what you are able to do is create an honest level of effort. You are not adding extra
resources simply to beat a particular schedule. You are using the resource level that is most
appropriate to the task at hand. That can make this far more cost effective than a time-
constrained process.

3 How to Review an Estimate
HOW TO REVIEW AN ESTIMATE

................................................................
• Review definition of the system
• Study ground rules, constraints, and assumptions
• Focus on sources of data
• Compare estimate with established standards
• Determine whether methodology is acceptable
• Look for “cost drivers”
• Determine whether estimate is within target
This is a pretty practical approach, whether you are reviewing an estimate for a project or
reviewing an estimate for something within your home. I, for example, recently had some
work done on a garden tractor that I own, and went through this process with the people
who were doing the work. I had to review the definition of the system. What exactly was it
that I was asking them to do? The estimate came in surprisingly high, and I wanted to find
out just what was driving them to that estimate. I looked at the ground rules, the constraints,
and the assumptions.
I found out they had some different assumptions from mine. For one, they assumed that
they were going to have to come out, pick up my garden tractor, take it to their location, and
then return it. My intent was actually to take it out to them. We had a different set of
assumptions, and it made a difference in terms of the final estimate.
We focused on the sources of the data. They were considering margins and overhead, and
frankly, I had not been. They had a different data source than I did. We compared the
estimate with established standards. I did that by looking at some other vendors and found
out, frankly, the one I had chosen was the least expensive. We determined whether the
methodology used in developing the estimate was acceptable. They used their experience
and their established business practices. I did not have a lot to argue with there. I looked for
the cost drivers. I looked specifically at the items that were going to cost the most. It was not
sharpening the blade that was going to cost a lot. It was not tuning up the engine. It was
having them install a new bagger on the back of the mower that was going to cost so much.
That was the cost driver. That is where I was able to make the cost-trimming actions that
were necessary to bring it in line with my expectations.

.....
How to Review an Estimate
And finally we have to determine if the estimate is within the target. If it is not, we need to
make sure we are alerting the proper authorities—in my case, my family—and letting them
know exactly what to anticipate. We do not want people to be surprised by the estimates. If
it is off the target, we need to let people know that. It is honest estimating.

3 How to Review an Estimate

S CHEDULING
...................................
4
.....
OBJECTIVES

• Identify different scheduling techniques and tools
• Develop criteria for selecting the appropriate scheduling tool
• Construct a usable project schedule
• Review and practice working against data constraints
I want you to walk away from this chapter knowing how to use the various tools. Many of us
have gotten into the default mode of using the computer and relying on the computer to do
some of our scheduling for us. Invariably, however, we run into those error messages that
just do not seem to make sense—the ones regarding circular relationships and the ones
regarding certain dependencies and how they can or cannot be established. What we want
to do is by the end of this chapter is to ensure that you are comfortable with those messages
and know how to resolve the issues that they represent. We also want you to be able to
construct a usable project schedule. There is an operative word there, that is “usable”—
something that can actually be applied. That means scheduling down to your level of
control: not below your level of control, where that much detail will simply bog you down,
and not above your level of control, where you cannot have an influence over how things
change and how they are going to work.
NETWORK SCHEDULING
................................................................
I know some of you probably looked down at the bottom of this page and said, “Ah, a PERT
chart—something familiar.” I hate to break it to you, but that is not a PERT chart. The data
that is incorporated in that chart did not come from a PERT evaluation. What it came from
instead was the best estimates of the people available. Thus, it is not truly a PERT chart.

SCHEDULING
4 Validating the Time Frame
What it is, however, is a network diagram. And it is a well-crafted network diagram, because
it reflects all the activities reflected in the WBS up above. It comes from a WBS or from a
task list. It represents all the work that needs to be done to accomplish the project. Without
that information you could not build a good network diagram. The WBS or the task list has to
be built first, before you can ever get into this part of network scheduling. It is a network, a
sequential order, of all the activities that have to be performed to accomplish the project,
and all the activities need to be reflected in the work breakdown structure.
WBS
1.0
1.1 1.2 1.3
1.1.1 1.1.2 1.2.1 1.2.2 1.3.1 1.3.2
Start 1.1.1 1.1.2 1.2.2 Finish
1.2.1 1.3.1 1.3.2

.....
SCHEDULING
Validating the Time Frame
VALIDATING THE TIME FRAME

................................................................
With the customer, organization, and team—
• When can we start?

• When is it due?
• What’s the business need driving the deadline?
• What constraints could affect the calendar?
It is interesting how frequently we go into a project without having truly validated the time
frames that have been established. What is driving the time frames? I was doing a review
for a major governmental organization and found out that the time frame that had been
established—one that was written down as a deadline that had to be carved in stone, that
no one could afford to miss—was actually being driven by a manager’s spouse. An upper
manager had determined the driving date of the project simply because it was the birth date
of their spouse. They had established that as being the reason the time frame was valid.
Everyone else was working double (and in some cases, triple) overtime simply to meet that
crisis deadline. In fact, there was no crisis at all. The time frame had never truly been
validated as to, what is the business need that drove us to that particular time frame? We
need to ask that question before we start the project so that we understand what is
compelling us to meet the particular deadlines at hand.
When can we start? In many cases we do not have that information at hand. How soon can
we actually get the resources and get rolling on this? When is it due? What is the business
need driving the deadline (and note those words, business need)? And finally, what
constraints could affect the calendar? What other things are hanging out there that could get
in our way? Birthdays, other celebrations, or incidents that are on the horizon as risks may
all have an influence in terms of, how valid is the time frame? Can we survive all those
risks?

SCHEDULING
4 Project Network Diagram
PROJECT NETWORK DIAGRAM

................................................................
For most of you, one of these is terribly familiar and the other looks somewhat foreign. The
reason is because most people are accustomed to dealing with network diagrams in one
format or the other. Most people do not tend to deal with both. The one on the left is an
activity-on-node diagram. All the activities are embedded on the nodes or in the boxes in
which those activities are written down. By contrast, the one on the right is an activity-on-
arrow diagram.
Start 1.1.1 1.1.2 1.2.2 Finish 2 4 6
1 8
1.2.1 1.3.1 1.3.2

3 5 7
We are going to talk about each of these and the relationships they have to schedules, how
you might run into them, and how you need to interpret them if you do encounter them in
your projects. If you are taking the PMI® exam, you will want to know the PMBOK® Guide
definition here as well.
NETWORK DIAGRAM RULES OF THUMB

................................................................
• There is a starting point
• There is an ending point
• There are predecessors for all activities
• There are successors for all activities (no hangers!)
• The network must be updated and current
• There are no loops
• The logic is always updated

.....
SCHEDULING
Arrow Diagramming Method (ADM)
As you look over any activity-on-arrow diagram and activity-on-node diagram, you notice
some radical differences. But I would like to point out a few of the similarities—some of the
common ground.
For one, both have a starting point. There is a distinct point at which the project is supposed
to start, which is represented by the schedule. The tough one is on the other end. There is
an ending point. In many projects we do not define a single end point. We need to make
sure that the entire project comes together to a single point, or moment in time, on a single
milestone that says, “This project is indeed complete.”
All activities must have predecessors. Those predecessors may be nothing more than a
milestone that says, “Start the project,” but there must be a predecessor for each activity.
Similarly, there must be an end point, as I have just mentioned; thus, there must be
successors for every activity. There are no activities that start but do not have something
that they connect to at the end of the project. The worst case is, simply, they connect to the
finish milestone, but they must connect to something at the end of the project. The network
must be updated and current. There are no loops, which tells us that an activity will not
repeat. And the logic is always updated.
“Brent, I am a little uncomfortable with that—saying there are no loops. In our projects we
tend to repeat processes.” If you want to reflect that in a conventional network diagram, you
must build in the recurrences of that activity.
If you want to consider some other approaches, perhaps network diagramming is not the
right way to go. If you need to reflect those loops, you may need some fancy process
diagramming software. Software like Process Charter from Scitor Corporation will take into
account those kinds of loops, and you can assign the resources as necessary. However, it
is more involved than most project managers really need. So when you are dealing with a
fundamental network diagram, there will be no loops. If you put loops in, you will get the
error messages.
ARROW DIAGRAMMING METHOD (ADM)

................................................................
This is, from most people’s perspective, an older approach to network diagramming. Very
few organizations still actively used ADM. However, it is popular enough that you may
encounter it at some point in your travels. If you do, you will need to know how to interpret

SCHEDULING
4 Arrow Diagramming Method (ADM)
the diagram. Specifically, what happens in an arrow diagramming method diagram is that
the activities are on the arrows rather than on the nodes. In other words, the activity is
between the 1 and 2, rather than being on the 1 or 2 in this diagram. Thus, the activity
becomes named Activity 1-2. No matter what type of activity it might be, we know, because
it is Activity 1-2, that the activities that are subsequent to it will begin with—that’s right—the
number 2. So, Activity 1-2 is a predecessor to Activities 2-4 and 2-5. We know that because
of the way the names are set up in activity-on-arrow diagramming. Activity 1–3 is a
predecessor for—that’s right—Activity 3-5.
Activity-on-Arrow (AOA) Diagram
2 4 6
1 8
3 5 7
As you look at this you can see we have a variety of activities going on, but you will also see
that there is a bizarre line in there. It is Activity 5-6. Activity 5-6 does not seem to be a solid
line. It is in fact a dashed line, and that dashed line has a very significant meaning in activity-
on-arrow diagramming. That dashed line means it is a dummy—it is a dummy activity. (That
is a term you will need to know on the PMI® exam, by the way, if you happen to be going for
PMP® certification.) That dummy activity represents a dependency. Activity 3-5 must occur
before Activity 6-8, but there is no way in the diagram to reflect that, given the other
constraints. So to account for that relationship, we had to create a connection between
those two activities. That connection has no duration. And since all the other activities are
on the arrows, you need to reflect that duration differently than with a solid arrow. That
dashed arrow is a dummy activity. It shows a relationship but no duration.

.....
SCHEDULING
Building an AOA Diagram
BUILDING AN AOA DIAGRAM

................................................................
List the Create a Start Draw Arrows from
Activities and Node with the Start Node for all
Relationships Number "1" Initial Activities
Sequentially Repeat Process Double Check

Number Nodes from Successors for Missed
at Arrow Ends for all Activities Relationships
These are the steps you must take to build an activity-on-arrow diagram. You list the
activities and the relationships. You create a start node with the number 1 and then draw all
the arrows out from there. Draw the arrows from the start node for all the initial activities,
and then have a finish node for each one of those activities. The activity’s finish node
becomes the start node for all the successors to that activity. And if you have a relationship
that cannot be reflected, given the constraints of the basic diagram, what kind of activity do
you need? You need a dummy. You need to put a dummy relationship in there to reflect
those kinds of dependencies that cannot otherwise be expressed.
................................................................
PRECEDENCE DIAGRAMMING METHOD (PDM)
A network diagramming technique in which activities are represented by boxes (or nodes).
Activities are linked by precedence relationships. (PMBOK® Guide)

SCHEDULING
4 Building a Precedence Diagram
Activity-on-Node (AON) Diagram
Start 1.1.1 1.1.2 1.2.2 Finish
1.2.1 1.3.1 1.3.2
The activity-on-node diagram differs from the activity-on-arrow diagram in that the activity-
on-node diagrams of PDM actually have the activities nestled within the nodes. This
changes one key feature between the two diagrams. In activity-on-arrow diagramming that
you just completed, you could only generate clear finish-to-start relationships. This activity
must finish before this activity can start. In activity-on-node diagramming you can change
the relationships of those arrows so that you can try for different types of relationships. You
can represent different relationships, and you can show multiple precedents and
successors. That is important. That is the value of using the more modern approach:
precedence diagramming method.
However, there are some disadvantages as well. It is much easier in the precedence
diagramming method to forget to hook something up to its next activity. Each activity should
have a predecessor and a successor, as we discussed earlier in the rules. In the
precedence diagramming method, that is something a little too easy to forget.
BUILDING A PRECEDENCE DIAGRAM

................................................................
You will notice the first activity there is to list all the activities and their relationships. Listing
the activities is actually something you have already done. You did it when you built your
work breakdown structure, your WBS, down at the work package level. Every one of those
work packages is going to be connected within your precedence diagram. However, be very

.....
SCHEDULING
Basic Scheduling
cautious not to create precedential relationships with the summary activities. In fact, that is
where a lot of problems stem when you get error messages in the software. In many cases
you will have created a precedence relationship between a summary task and a work
package. Later on, you will try to connect two work packages that are somehow related
under the summary task, and you will get an error message. That is because you are only
trying to identify activities that actually have work in them for the precedence diagram; thus,
you do not connect summary activities when you are building a precedence diagram—only
the work packages.
List the Draw Arrows from

Create a
Activities and Start Node to First
Start Node
Relationships Activity's Node
Sequentially
Repeat Process Double Check
Arrange all
from Successors for Missed
Activities from
for all Activities Relationships
"Start"
You begin by creating a start node, you draw arrows from the start out to the very first
activities that you are going to be doing, and then you sequentially arrange all the activities
beyond that point. As you go through, it is important to make sure that you have covered all
the relationships. Not all activities have a single predecessor or a single successor. It is
important to make sure every relationship is accounted for throughout the network diagram.

SCHEDULING
4 Basic Scheduling
BASIC SCHEDULING
................................................................
Early Start Early Finish

(ES) (EF)
How Early Can This Activity Start or Finish

Based on the Network Logic and Constraints?
Late Start Late Finish

(LS) (LF)
As you look at this diagram, I cannot stress enough to you that this is one of the most
important concepts that you will need to get down to truly understand effective scheduling.
As you look at the four corners of this diagram, if you know these four corners for every
single activity on your project, you have gone a long way toward becoming an effective time
manager. Specifically, what you are looking at is the early start and the early finish. How
early can this activity start or finish based on the network logic and constraints? The ones
across the bottom tend to be the ones we forget: the late start and the late finish. How late
can we get it done and still get the project done on time? Those are vital questions to be
asked of each and every activity. How early can we start it? How late can we start it? By
balancing those activities that can start a little earlier or start a little later, we can try to
manage our time more effectively and, in many cases, manage our resources more
effectively as well.

.....
SCHEDULING
Calculating the Forward Pass (Finish-Start Relationships)
CALCULATING THE FORWARD PASS

(FINISH-START RELATIONSHIPS)
................................................................
Use the Formulas
Set the Early Begin at Left, Work
Start Date for Left-to-Right, (ES + Duration = EF)
the First Activity Top-to-Bottom (EF + Lag = ES for
Successors)
When a Successor has Multiple Predecessors,

use the Latest Early Finish Date of the Continue to End
Predecessors as the Early Start Date for the of Network
Successor
The easiest way to explain a forward pass is walk through the demonstration with me, so
before we go any further, I would like you to draw a network diagram. Please keep your
diagram drawing; we will refer to it in other sections.
Draw four boxes in a row—just four boxes, across, in a row. Connect each box with an
arrow. In the first box put an S. In the second box put a number 1. In the third box put a
number 2. In the fourth box put the letter F.
Then draw one more box beneath box 2 and put a number 3 inside that new box. Draw an
arrow from box 1 to box 3, and from box 3 to box F. You now have a three-activity network.
I would like you to assign durations to each of these activities. Activity 1 will be a 4-day
activity. Activity 2 will be a 3-day activity. Activity 3 will be a 2-day activity.
Now that you have that established, I would like you to look at the section to understand
exactly what we are trying to accomplish here. We are trying to find the early start and the
early finish for each of these activities. The forward pass establishes the early start and
early finish information—the ES and the EF. In the upper left-hand corner, you want to set
the early start date for the first activity (that is Activity 1, the 4-day activity). You want to
make that early start a zero, so if you will, in the upper left-hand corner of that box, put a
zero up there. That zero indicates it is starting at the very beginning of the project.

SCHEDULING
4 Forward Pass (Full Precedence Diagram)
Beginning at the left, working left to right, top to bottom, we are going to continue across the
diagram. Activity 1 takes 4 days. Zero plus 4 is—did not need a calculator for that one—it is
4 days. So go ahead and put a 4 in the early finish. That is the earliest you can finish this
activity. That 4 carries over to the beginning of any successors for that given activity. So
Activity 2 begins on the fourth day. Activity 3 begins on the fourth day. That is because we
started on Day Zero. If we had started on Day 1, we would have advanced those numbers
by 1, which is an approach that some textbooks use. We prefer starting with zero so you can
just carry the numbers across.
Take a look at that 4-day activity. It took us out from Day Zero to Day 4. We are now starting
Day 4 with a 3-day activity (Activity 2). Activity 2 is 3 days. It starts on the fourth day. Four
plus 3 is? Seven. What is the early finish? The earliest we can finish that activity is Day 7.
Let’s go down to the bottom. The earliest we can start Activity 3, the 2-day activity, is—that’s
correct—Day 4. Four days plus 2 days is—that’s right—6 days. So it is going to end on Day
6. That means that we are left with a relationship where the second activity is finishing on
Day 7, and the third activity is ending on Day 6. The question is when does the project get
finished? It finishes in 7 days. You have now completed a forward pass through the network.
Let’s take a look at a little more involved example.
FORWARD PASS (FULL PRECEDENCE DIAGRAM)

................................................................
The following diagram is a little more involved than the one we just created for ourselves.
This one involves a series of activities. Notice that we did exactly the same thing here that
we did on our simpler diagram earlier. We started with zero and carried across the numbers.
Zero plus 7, for Task A, is 7 days, so the forward pass takes us to 7. The early start of the
next activity on that path, which is Activity C, begins on Day 7. It is 6 days long. Seven plus
6 is 13. Doing the forward pass is simply a function of addition—we add up all the activities
across the path.
Notice down across the bottom we have Task B, which is 3 days, so it goes from zero to 3.
Then we have Tasks D and F. Task D begins on Day 3 and is 3 days long. It finishes on Day
6. Task F begins on Day 3 and is 2 days long. It ends on Day 5. Notice that it is the 6 that
carried across for the next one, for Task E. Task E must begin on Day 6. Why can’t it begin
on Day 5? Think about that for a moment. It cannot begin on Day 5 because it has to wait

.....
SCHEDULING
Forward Pass (Full Precedence Diagram)
until Task D is complete. Both D and F must be complete before E can begin, and Task D
will not be done any earlier than Day 6, so it is impossible to start Task E before Day 6.
Similarly, look at Task H. Task H has to wait until Tasks G and E are both complete. Task G
has an early finish of Day 16. Task E has an early finish of Day 9. The 16 is what carries
over as the early start. The earliest Task H can start is Day 16 because both G and E must
be finished before it can begin.
ES EF ES EF ES EF
0 7 7 13 13 16
Duration = 7 Duration = 6 Duration = 3
Task A Task C Task G
LS LF LS LF LS LF
ES EF
16 18
Duration = 2
Start Finish
Task H
LS LF
ES EF ES EF ES EF
0 3 3 6 6 9
Task B Task D Task E
LS LF LS LF LS LF
ES EF
3 5
Duration = 2
Task F
LS LF
Similarly, look at Task H. Task H has to wait until Tasks G and E are both complete. Task G
has an early finish of Day 16. Task E has an early finish of Day 9. The 16 is what carries
over as the early start. The earliest Task H can start is Day 16 because both G and E must
be finished before it can begin.
And the entire project is going to take us how long? When is the project going to be done? It
is going to wrap up on Day 18. That is the forward pass, and that gives us some vital
information. But we get even more data with a backward pass.

SCHEDULING
4 Backward Pass
BACKWARD PASS
................................................................
We are now back to where we were before, with an explanation of the fundamentals of the
backward pass. So what I would like you to do is to get your diagram from the previous
exercise that I asked you to do, with Activities 1, 2, and 3—the very simple network diagram
that we built a few minutes ago. What I would like you to do now is simply to do the
backward pass with me as we walk through these steps of the exercise.
Set the late Finish Date of the Last Task Begin at Right,
Equal to the Early Finish Date of the Last Work Right-to-Left,
Task (or set to customer date) Top-to-Bottom
Use the Formulas When a Successor has Multiple Successors,

Continue to
(LF - Duration = LS) use the Earliest Late Start Date of the
Beginning of
(LS - Lag = LF for Successors as the Late Finish Date for the
Network
Predecessors Predecessor
Set the late finish date of the last task equal to the early finish date of the last task. Now, let
me explain that—it sounds a little more complicated than it is. If you look at our 3-activity
network, the late finish date of the last task is going to be Day 7. That is because that is the
end of our network. We can just go ahead and put as the late finish for both activities—both
Activity 2 and Activity 3—the late finish is going to be 7 days, because that is when the
project is going to be done. That is all there is to it. The number carries down.
Notice there is a parenthetical comment there about setting it to the customer date. Setting it
to the customer date is when we have an imposed deadline from the customer. In some
cases, the customer will come to us and say, “I need this done within 8 days,” in which case
instead of simply carrying down our number of 7 days, which will establish a basic critical
path, we can use the customer’s date and use that to drive our schedule as well.
For this example, let’s go ahead and use our imposed date from the network itself rather
than the customer’s date. We start at the right, and we work from right to left. So our late
finish is 7 days. Activity 3 is 2 days long. Seven days minus 2 days is—what is the latest we

.....
SCHEDULING
Backward Pass (Full Precedence Diagram)
can start this activity and still get it done on time? Seven days minus 2 days. That’s right—
Day 5. Day 5 is the latest we can start this and still get the project done on time for Activity 3.
Look at Activity 2, the 3-day activity. As you look at Activity 2—7 days. Seven days minus 3
days is 4. That’s correct: 4 days. That is the latest we can start Activity 2 and still get the
project done on time—4 days in.
Notice something about Activity 2. The earliest we can start Activity 2 and still get the project
done on time is 4 days. The latest we can start Activity 2 and still get the project done on
time is 4 days. What happens if we are even a minute late with that activity? The project is
going to be delayed. We have no slack whatsoever. We will talk about that more in a
moment.
We use the formula of late finish minus the duration to get the late start, and we continue to
work our way back across. What is the latest we can finish Activity 1 and still get this project
done on time? The latest we can finish it is Day 4, so we put that 4 days down there. Four
days minus 4 days is zero. Once again, Activity 1 has the early start and the late start
match. The early finish and the late finish match.
Why couldn’t we say we could finish Activity 1 on Day 5? That is what is driving Activity 3.
We cannot do that because, if we go out to 5 days on Activity 1, Activity 2 is going to be late.
That is the basics of a backward pass. Now let’s do it with a slightly more involved example.
................................................................
BACKWARD PASS (FULL PRECEDENCE DIAGRAM)
You will notice in this network diagram we have once again taken our early finish and
converted it to be the late finish for the project. We are letting the network drive the
schedule. We are not letting the customer drive it in this particular instance. We will talk
about that momentarily. Notice on Task H—we are working backwards—Task H is ending
on Day 18. That is the late finish. That late finish minus that 2-day duration gives us a late
start of Day 16. The early start is Day 16; the late start is Day 16. That task is critical.
Look at the tasks that lead into that. Task G has a duration of 3 days. Its late finish is Day
16. Its late start is Day 13. Sixteen minus 3 is 13. It makes sense.
Look down at Task E. Task E can finish as late as Day 16. However, it has a 3-day duration.
Sixteen minus 3 is, once again, 13. So it has a late start of Day 13. But it has an early start

SCHEDULING
4 Backward Pass (Full Precedence Diagram)
of Day 6. The latest it can start and still get the project done on time is Day 13. The earliest
it can start is Day 6.
ES EF ES EF ES EF
0 7 7 13 13 16
Task A Task C Task G
0 7 7 13 13 16
LS LF LS LF LS LF
ES EF
16 18
Duration = 2
Start Finish
Task H
16 18
LS LF
ES EF ES EF ES EF
0 3 3 6 6 9
Task B Task D Task E
7 10 10 13 13 16
LS LF LS LF LS LF
ES EF
3 5
Duration = 2
Task F
11 13
LS LF
There is a big difference between those numbers. The difference between those numbers is
the slack or float that is available to the project manager. This is an important component of
networking diagramming. The importance of this component is that it is something that we
as project managers can actually manage. We can actually get in there and make some
changes with our schedules and our resources, and have an affect on the outcome of the
project. Many project managers complain that they do not get actual control over that much
in their projects. This is something the project manager clearly has control over, some level
of autonomy.
Continue going backwards and we continue to carry the late start number over to the late
finish of each activity. Notice that Task D has a late finish of 13. It carried over from Task E.
It is 3 days long. Thirteen minus 3 is 10.
Notice down at the bottom, Task F. Thirteen with a 2-day duration. Thirteen minus 2 is 11.
The latest we can start Task F is Day 11. The earliest we can start Task F is Day 3. That is
8 days of slack. Task E has 7 days. Task F has 8 days. But do not be deceived into

.....
SCHEDULING
Float/Slack
believing that slack is all cumulative. Slack, once it is used, generally is expended for that
activity and other activities on the path.
As you carry this backward you can see, all the way across at the top, there is no slack on
any of the activities. A, C, G, and H have no slack. As a result, they are the critical path.
FLOAT/SLACK
................................................................
• Float = Late finish – Early finish
• Float = Late start – Early start
• Float/slack > 0 (time is available)
• Float/slack = 0 (situation is critical)
• Float/slack < 0 (project is behind/critically late)
Float and slack are actually interchangeable terms, although we will find there are different
types of float that are available to us. What you need to understand is that float is what we
manage as project managers. It is the difference between the late finish and the early finish.
Float is the late finish minus the early finish.
In an earlier example we talked about the fact that we have some activities that will have a
late finish that is driven by the project date. Sometimes we have late finishes that are driven
by the customer’s dates. That makes a big difference, because sometimes customers
impose somewhat unrealistic schedules. We have all been there before. If you are dealing
with that kind of scenario, your late finish may be earlier than your early finish.
Take a look at the following examples. In the first scenario you have the float of an activity
that has a late finish of Day 54 and an early finish of Day 45. Fifty-four minus 45 is 9. You
have 9 days of slack or float. You have 9 days of float. That is important information. That is
9 days you can manage. Our float is greater than zero. There is some time available. We
can deal with the situation. If both of those numbers had been 54, then we would have been
in a critical situation. That activity would have been on the critical path.

SCHEDULING
4 Types of Float
32 45 32 45
Float? Float?
41 54 28 41
On the last one, on the second box, you will notice that the late finish is Day 41. The early
finish is Day 45. Forty-one minus 45 is a negative number—it is minus 4. That means we
are late; we are in trouble. It means you are probably getting some kind of error message on
your software that indicates you are in a negative-slack condition. If you have seen those
error messages before, this is what they are talking about. You cannot complete this task
and make the project deadline based on the constraints as they are currently lined up. You
are going to be late. If your early finish is later than your late finish, this project is in some
trouble. Some remedial action will need to be taken to correct the situation.
TYPES OF FLOAT
................................................................
• Free float
• ESj – EFi
• Total float
• LSn – ESn or LFn – EFn
Free float and total float. As we get into this, it is going to be important for you to understand
some of the basic nomenclature of scheduling. Toward that end, you will notice that there
are mathematical formulas here that use an “i” and a “j.” i and j have basically become the
province of project management to represent the predecessor and successor relationships:
i is always the predecessor, j is always the successor. You will see this referenced in
numerous textbooks and other materials, and you should be aware that it is there. I have
done some extensive research trying to find out, why i and j? I have not been able to come
up with anything concrete, save for one instructor who told me, “I guess all the rest of the
letters of the alphabet were taken.” So, be that as it may, you need to understand what an i
is and what a j is—i is always the predecessor, j is the successor.

.....
SCHEDULING
Types of Float
1.1.1 1.1.2 1.2.2

Start Finish
3 4 9
1.2.1 1.3.1 1.3.2

6 4 3
So for free float you will notice that we are taking the early start of the successor and
subtracting the early finish of the predecessor. If you go back to our earlier example that we
created on paper, I asked you to create a 3- activity network. We identified Activity 3 as
having some float. Let’s find out if that is free float. The early start of Activity 3 is Day 4. The
early finish of its predecessor, Activity 1, is Day 4. Day 4 minus Day 4 is zero, so we have no
free float.
Free float normally only occurs in significantly complex networks. It only shows up when we
have a more involved network. Take a look at the network that is on your section here. As
you look at this you can calculate it out. As a matter of fact, I would like you to take a minute
and do just that.
You have now calculated out the network:
The early start of Activity 1.1.1 is zero. The early finish, 3.
On 1.1.2 the early start is 3, the early finish is 7.
1.2.2, the early start is 7, the early finish is 16.
1.2.1, the early start is zero, the early finish is 6.
Total duration of the network is 16. Critical path is 1.1.1 and 1.1.2, and 1.2.2. The finish of
this project is Day 16. The finish activity has an early start of Day 16. Activity 1.3.2 has an
early finish of Day 13. Sixteen minus 13 is 3. Activity 1.3.2 is the only activity in this entire

SCHEDULING
4 Critical Path
network that has any free float, and that is 3 days of free float at the end of the project. If it is
late, no other activities are going to be delayed, not even the successor activity that is
noncritical. That is what free float is all about.
Total float is what we normally calculate across the entire network and across the paths.
That is where you take the late start minus the early start of any given activity to identify how
much total float it has. That is a function of the larger network as a whole. As you look
across to Activity 1.3.1, it has a late finish of 13 days. It has an early finish of 10 days.
Thirteen minus 10 is 3. It has 3 days of total float. Let’s look and see if it has any free float.
Its early start is Day 6. The early finish of its predecessor is Day 6. Day 6 minus Day 6 is
zero. It has no free float. Generally, if it is in the middle of the path, it is not going to have
free float.
CRITICAL PATH
................................................................
This section is designed to bring it all home for you. If you do not understand the
fundamental concepts, here is one more chance to understand what exactly the critical path
is.
Start Set Theme Fix Date Select Site Costumes Hire Band Finish
0d 24h 3d 5d 5d 21d 0d
Set Budget Invitations

6d 1d
It is the longest of all the paths through the project. If you are looking for a quick and simple
way to figure out which path is critical, simply add each possible path within your network
diagram. The one with the highest total is the critical path. It is the longest of all the paths
through the project.
It is the path with zero float or slack time. There will be no float or slack if you are using the
network to drive your schedule.

.....
SCHEDULING
Exercise
The critical path is the shortest time in which the project can be completed. This may seem
paradoxical, but it really isn’t. In other words, the critical path shows how quickly can we
accomplish this project—that shortest project time is driven by that longest path. That is
what will drive our schedule. That is what drives the critical path.
EXERCISE
................................................................
Now I would like you to consider the fourth activity, “Select site,” on the critical path.
Calculate this activity’s early start, early finish, late start, and late finish dates. If you are
SCHEDULING SAMPLES
................................................................
CONSTRUCTION CHART
You have here and over the next couple of pages a look at the differences between activity-
on-arrow, activity-on-node, and spreadsheet diagramming. This basic spreadsheet that you
have before you does not really provide a lot of insight. It provides information, it provides
data, but it really does not provide any insight as to how this schedule is going to pan out
and how it is going to look. If you were looking for specifics, this would be a good place to
go. But when it comes to getting a sense of how things tie together, you really need the
network diagrams.

SCHEDULING
4 Scheduling Samples
Activities and Times to Build a House

Activity Preceding Expected Completion Time
Activity (days)
(a) Excavate - 5
(b) Poor Foundation a 2
(c) Outside Plumbing a 6
(d) Frame House d 12
(e) Inside Plumbing d 10
(f) Wire House d 9
(g) Lay Roof d 5
(h) Lay Brick b 9
(i) Inspect Plumbing c, e 1
(j) Lay Shingles g 2
(k) Finish Walls f, i, j 3
(l) Finish Interior k 9
(m) Finish Exterior h, g 7
(n) Landscape Yard m 8
ACTIVITY-ON-ARROW
Activity-on-arrow. This activity-on-arrow diagram gives you a sense of the level of
complexity that can be involved in the arrow diagramming method. As you look through this
diagram you can clearly see what is critical and what is not. You can also identify activities
that have relationships—which activities must finish before the next activity can start. That is
easy to track in this type of diagram. It is relatively clear. It is not hard to follow the arrows
because they are not bent all over the place. However, in extremely complex diagrams,
some of these arrows can get very, very long, and it becomes difficult to follow across the
entire diagram. But for relatively simple diagramming, like the one displayed here, this can
be a very effective tool.

.....
SCHEDULING
Scheduling Samples
Outside Inspect
Plumbing Plumbing
Inside 1
c i
Plumbing
10
6 e
Start
5 2 12 9 3 9 Finish
a b d f k l
Excavate Poor Frame Wire Cover Finish
Foundation House House Walls Interior
9
h 8 n
Lay Landscape
Brick Yard
m
Finish
Exterior
ACTIVITY-ON-NODE
Here is the precedence diagram with the full complement of activities all neatly arrayed
according to the same names and same structure they had in the activity-on-arrow diagram.
This one becomes a little more involved to follow. As you can see, the arrows sometimes
get a little bit tangled. And if you have used any of the software packages you know that
some of them do network diagramming more effectively than others. For some of them, you
may want to consider an add-on product to arrange these diagrams, because some of them
are not too effective at laying them out.
This is a nicely arranged diagram that gives you a clear delineation of relationships.
However, if you look at the Frame activity, Activity D, and the next activities that follow it—
Plumb the inside, Wire, and Roof—it is hard to tell exactly where the lines are going, where
one line tracks into the next. It sometimes gets to be a little bit challenging. Similarly, the
Wire line is hard to follow because you are not sure if it is going back to Shingle or whether
it is going up to Cover walls. Only the arrowhead gives you that indicator. Without that piece
of information, you might otherwise be lost.

SCHEDULING
4 Scheduling Samples
Start
(a) Excavate
5 days
(b) Pour (c) Outside

Foundation Plumbing
2 days 6 days
(h) Lay Brick (d) Frame

9 days House 12 days
(e) Inside
(g) Lay Roof (f) Wire House
Plumbing
5 days 9 days
10 days
(m) Finish (i) Inspect

(j) Shingle Roof
Exterior Plumbing
2 days
7 days 1 day
(n) Landscape
(k) Cover Walls
Yard
3 days
8 days
(l) Finish
Interior
9 days
Finish
Sometimes network diagrams and activity-on-node can get so involved that it is hard to
track which arrows go where. That is one of the downfalls or the shortcomings of activity-on-
node diagramming. But since you do a lot of the structure yourself, and since you often have
to reorganize these diagrams because the tools do not do it quite as effectively as they

.....
SCHEDULING
Lag and Lead Times
might otherwise, you may want to consider this as a viable option. Still, it is best for
informational purposes and to gain some insight. It is not really an ideal diagram for display
or for presentation.
LAG AND LEAD TIMES

................................................................
Lag: A modification of a logical relationship that directs a delay in the successor
task. — PMBOK® Guide
Lead: A modification of a logical relationship that allows an acceleration of the

successor task. - PMBOK® Guide
Here you have good definitions for both lag and lead. But in simpler terms, lag time is just
the time spent waiting for something. It is the time spent waiting for other things to take
place; not other events, but time to pass. Lag time could be waiting for paint to dry, for
plastic moldings to cool, for a process to finish its cycle (as in procurement, for example).
Lag time is imposed. It is something we can look at and schedule for. It is something we
plan into the schedule. It is not something that takes up any resources, but it is something
we recognize as being a delay—it holds off the start of the next activity.
Lead, however, is rather the opposite. Lead time is starting an activity before the previous
activity is scheduled to end. When considering lead time we ask, what can we get a head
start on? PMBOK® Guide describes it as “a modification of a logical relationship that allows
an acceleration of the successor task.”

SCHEDULING
4 Precedence Relationships in PDM - Finish-start
A classic example is taking a lead on writing projects when doing development work. If
development work is under way, we do not necessarily want to wait until it is complete
before we start writing the documentation. Writing can be started with a little lead time. We
can get a head start based on the development work that has been accomplished so far.
PRECEDENCE RELATIONSHIPS IN PDM - FINISH-START

................................................................
Examples include:
• Pour the concrete; raise the frame

• Define requirements; write the code
• Set budget; select design
This is the classic relationship in the precedence diagramming method—the finish-start

relationship. It is also the only relationship that can exist in an activity-on-arrow diagram.
Everything there is finish-start. Activity i must finish before Activity j can start. One thing
must finish before another can start.
You have some examples here: pour the concrete, then raise the frame; define
requirements, then write the code; set the budget, then select the design. Notice the
operative word here is “then.” We do one thing, and then we do the next thing. We mask the
walls, and then we paint them. We lay down the glue, and then we put down the flooring. All
of these are first-this-then that relationships. It is a finish-start relationship. It is the most
fundamental of the relationships.
Let me use the example, if I might for a moment, of a Thanksgiving turkey and the process
of cooking it and then carving it. Activity i would be Cook the turkey; Activity j would be
Carve the turkey. But there is going to be something along that arrow between the two. That
would be lag time. We need to assign some lag time to allow that turkey to cool. That is
important, because otherwise you are going to wind up with little more than turkey dust. You
need to have time for the turkey to cool when it comes out of the oven. It is an important part
of that relationship—finish then start. But, as we just discussed a moment ago, we do not
want to forget that sometimes we have to impose lag to account for the environment in
which we are working.

.....
SCHEDULING
Precedence Relationships in PDM - Finish-finish
We also need to be aware that, in some relationships, there is not hard logic. Hard logic is
mandated by the environment in which we are operating. Hard logic would be, for example,
“You must pour the concrete and then raise the frame.” You cannot put a frame onto wet
concrete. It simply will not stay there.
However, you can have preferential logic, or soft logic, as it is also called. It is “Define the
requirements and then write the code.” In that example, it is preferential logic. It is the way
we prefer to do things; it is not the way things are mandated to be. It is important to
understand the difference between hard logic and soft logic when you go to network your
projects. Because in many cases, soft logic will be purported to be hard logic, and in those
cases, you need to be aware of what changes you can make to improve the situation from a
scheduling perspective.
PRECEDENCE RELATIONSHIPS IN PDM - FINISH-FINISH

................................................................
Examples include:
• Bake the turkey; bake the yams

• Reproduce disks; generate documentation
• Select design; allocate funding
We just covered the finish-start relationship, and now it is time for finish-finish—a different
kind of relationship, where the finish of j depends on the finish of i. Whenever i is done, then
j may finish. And there may be some lag time assigned in there as well.
At the bottom of this section is a diagram that shows the exact same relationship, only it
looks like a finish-start. This is how finish-finish is generally displayed in your software
packages. The arrows do not go from the finish-side of a task to the finish-side of another
task. It is just not done that way. Most of your software packages display the finish-finish
relationship as presented at the bottom of the section: it looks like a finish-start, but along
the arrow it indicates a finish-finish relationship. It shows that Activity i must finish, then
Activity j may finish.
Also notice the “+ 2” in that diagram. That is the amount of lag time that has been assigned:
i may finish, and then, anytime 2 days after that, or 2 hours after that, or 2 time units after
that, j may finish. That is how those relationships are usually expressed.

SCHEDULING
4 Precedence Relationships in PDM - Finish-finish
The classic example of finish-finish is the holiday meal. My great aunts used to put on quite
the spread every holiday. They would serve a fabulous feast. It was all driven by the timing
of the turkey. When the turkey came out, then the rest of the meal could be set into motion.
Thirty minutes after the turkey came out, Uncle Bob would begin to carve at the table. That
was the turkey, plus 30 minutes of lag time, then the rest of the meal could hit the table. And
it all had to hit the table, by their standards, hot and ready to eat. Everything was timed out
against when Uncle Bob would start carving the turkey, but the driver of that was the
schedule of when the turkey was cooked and 30 minutes past that point in time. It was a
classic finish-finish relationship with 30 minutes of lag.
Let’s use the example presented here. It says, “Bake the turkey/bake the yams.” The turkey
normally took about 5-1/2 hours to cook. Then there was 30 minutes of lag time for it to cool
a bit. The yams took about an hour to cook. Now, if the turkey went into the oven at 6:00
a.m., when should the yams go into the oven? Notice that I am not asking, when is
everything done? I am asking, when do the yams go in the oven based on this finish-finish
relationship? So, it is 6:00 a.m. plus 5-1/2 hours of cooking time—that takes us up to 11:30
in the morning. Now add the l/2 hour of lag time, and it is now 12:00 noon. This means the
yams must be finished at 12:00 noon. But they cook how long? One hour, which backs us
off to 11:00 a.m. So the yams must go in the oven at 11:00 a.m., if the turkey goes in at 6:00
a.m. And if we put in the turkey an hour later, at 7:00 a.m., the yams would go in the oven at
12:00 noon. It is all being driven by the turkey. That is what a finish-finish relationship is all
about. Activity i must finish then Activity j can finish.
Look at the expression ESj=EFi+FFij-DURj. Wow. That is the mathematical expression of

what we just talked about. If you plug in the numbers from our turkey example, you will find
that they work perfectly there. We were trying to determine the early start of the yams. So
we took the early finish of the turkey, plus the relationship—the lag time—that existed
between i and j, and subtracted out the duration of the yams. That is how we came up with
the early start of Activity j. Similarly, we could have figured out the late finish of i, which is
equal to the late finish of j minus the finish-finish of ij. We could have calculated it that way
as well, if we wanted to work it backwards.

.....
SCHEDULING
Precedence Relationships in PDM - Start-start
PRECEDENCE RELATIONSHIPS IN PDM - START-START

................................................................
Examples include:
• Write text; edit text

• Install plumbing; install wiring
• Select design; select vendors
The start-start relationship is the other classic relationship in precedence diagramming. We

start Activity i, and then we can start Activity j. In many cases, these activities will start
simultaneously. However, there will be occasion where lag is assigned as well.
Take the examples we provided for you. You can write the text, and then you may edit the
text. Specifically, you have to write the text first before there is something there to be edited.
It is a start-start relationship. You do not have to write all of the text to start editing, but you
do have to have at least some of it in hand. It is a start-start relationship, but there is some
lag imposed within that relationship.
If you will look at the bottom of the section you will notice you have the ij relationship and it
looks finish-start, but once again, on the arrow you have the “SS + 1.” That indicates that it
is a start-start relationship. Even though the arrows do not connect at the beginning, it is
doing what many of the software packages are doing, which is to express the relationship. It
looks like a finish-start; however, when you look at the arrow, it indicates what type of
relationship it truly is. In this case, it is a start-start relationship with 1 day of lag.
We select the design and then we select the vendors—another classic example of the start-
start relationship. You do not necessarily have to finish the design, but you do need to have
the design in process before you can go out and select the vendors. It is a start-start
relationship.
Notice we have, once again, the mathematical formulas for start-start. The early start of j
equals the early start of i, plus the start-start of ij. That start-start of ij is the lag or lead time
that has been assigned there. The late finish of i equals the late start of j, minus the start-
start of ij, plus the duration of j.

SCHEDULING
4 Precedence Relationships in PDM - Start-finish
PRECEDENCE RELATIONSHIPS IN PDM - START-FINISH

................................................................
Examples include:
• Initiate project management; complete proposal

• Start relay runner 2; finish relay runner 1
• Start car engine; finish car starter
This sounds like the most ordinary relationship of all, doesn’t it? Start to finish. It is actually
the oddest one of the precedence diagramming collection. It is the weird relationship. It is
unusual because it is: Activity i must start before Activity j can finish. It is normally used to
represent some kind of organizational mandate, some kind of requirement within the
organization that is structured to establish and present a process.
The example here, the first bullet, is perhaps the classic example. It comes from ABB. ABB
says: You must initiate project management before the proposal can finish. You cannot
finish a proposal until project management has been initiated. They have to go through the
initiation process before they can complete their proposal process.
There is a reason for that type of relationship. It sets clear guidelines as to what must
happen and what rules and regulations have to be set up. But aside from that type of
environment, it is very rare that you will run into or encounter a start-finish relationship. This
is not an ordinary relationship. In fact, most start-finish relationships can be expressed
either as start-start, finish-start, or finish-finish. There is almost always another way to slice
it so that it will fit under one of the other three relationships. In fact, the start-finish
relationship is odd enough that in many cases it does not even show up in the software
programs. They will not enable you to do that. So you need to be aware that if you are trying
to use a lot of start-finish relationships, you might want to reconsider and look at some other
avenues of relationship building.

.....
SCHEDULING
Crashing a Network
CALCULATING THE NETWORK WITH ADDITIONAL

CONSTRAINTS - EXERCISE
................................................................
It is your first chance to really look at how these types of relationships fit together within the
network diagramming process. Specifically, you are presented here with a network
diagram—a very short one, only six activities—but there are two unusual relationships
established within this network diagram. Activity 1.1.1 and Activity 1.1.2 have a finish-finish
relationship with 3 days of lag. Activity 1.2.1 and Activity 1.3.1 have a start-start relationship
with no lag whatsoever. What you need to do is to calculate through the network specifically
two pieces of information: (1) What is the early finish of Activity 1.2.2? (2) What is the early
finish of Activity 1.3.2? You may have to go back and review some of the other sections to
make sure that you are doing it properly. Calculate through and figure out how long it is
going to take until you arrive at Activity 1.2.2 and Activity 1.3.2. Start with zero as your
opening date to calculate it across. If you are using this book and working towards PDU’s,
please submit your assignment as directed.
FF + 3
1.1.1 1.1.2 1.2.2

Start Finish
8 4 6
SS + 0
1.2.1 1.3.1 1.3.2
5 2 1

SCHEDULING
4 Crashing a Network—Approach
CRASHING A NETWORK
................................................................
Decreasing the total project duration after analyzing a number of alternatives to
determine how to get the maximum duration compression for the least cost.
(PMBOK® Guide)
Crashing has some negative connotations, particularly for those of you working in the
software universe. However, in project management, crashing is not inherently a bad thing.
It simply means compressing the schedule by adding more resources to the activities
involved. We are trying to decrease the total project duration.
One of the fundamentals of crashing is you always and only crash the activities on the
critical path. If you are taking the PMP® certification exam, one of the things you will want to
be aware of, however, is PMI® puts a big emphasis on the fact that it is compression
achieved using the least cost. PMI® puts a real emphasis on that—the lowest cost is what
you are driving for when you go to crash the schedule. You want to find the least expensive
activities to crash. That is critical, and they will have to be activities that are on the critical
path.
................................................................
CRASHING A NETWORK—APPROACH
This flowchart is pretty involved, but what it affords you is a way to look at network crashing
from the perspective of a process or a flow diagram. Walk through this diagram step by step
by step, and you can figure out exactly which activities are going to be the best ones to
crash. This diagram, by the way, does adhere to the basics of the PMI® model, looking for
the lowest-cost activity to crash. We are consistently looking for the most reasonable cost.

.....
SCHEDULING
Crashing a Network—Approach
Compute Normal Time Schedule
Compute Total Direct Cost at Normal Time
Is There More Than NO

One Critical Path?
Reduce a Lowest
YES Are There Activities Cost Activity One
Common to all Paths? Time Unit
Identify Low Search all Parallel Critical Paths for Lowest Cost
Cost Activity Combination of Activities that Shorten Project
Select Sets of Activities that Reduce Duration

One Time Unit at Lowest Cost
Reduce Schedule One Time Unit. Add Cost to Total

Direct Cost. Recompute Network Critical Path(s)
NO Is Duration Reduced to
Desired Level?
YES
Sum Direct and Indirect Costs for Each

Duration, and Determine Optimum Schedule
However, as you continue crashing, sooner or later, things start getting very expensive. We
learned that with the world-record house. You reach a saturation point with resources.
There are only so many people you can put in a room to paint it at the same time. When you
have achieved that point—where you are down to diminishing returns, where it is no longer
of value to add more resources—you have reached what is known as an activity’s crash
time. Its crash time is the shortest period of time in which that activity can realistically be

SCHEDULING
4 Alternative Constraints
accomplished. And when you are looking at a network that is crashed down as short as it
can be—all the activities are at their crash time and they are all still on the critical path—
then you have achieved the totally crashed network. You have crashed it down as far as it
can go. You have achieved as short a schedule as you can possibly achieve based on the
logic that you have provided to date.
ALTERNATIVE CONSTRAINTS
................................................................
This sections is actually broken down into four quadrants, if you will: early schedule and
network-driven alternative constraints, the late schedule network-driven alternative
constraints, the late schedule date-driven alternative constraints, and the early schedule
date-driven alternative constraints. You may encounter any or all of these in the various
software packages you will be using. The default tends to be ASAP: assign all activities as
soon as possible; get them accomplished as quickly as possible. ALAP [as late as possible]
is also a common scheduling constraint. You run into those quite frequently.
The rest, however, are ones that may be a little more unusual. Not all the software will
account for all these relationships, but this does account for all the relationships available in
the various software packages.
FNLT is “finish no later than.” It puts a hard date at the far end so that it does not get done
any later than that specific point in time. It does allow for earlier scheduling, however.
Start no earlier than [SNET]. This is often a constraint when it comes to when we are
bringing new employees or new resources on board. We start no earlier than the event
when they are going to join us. They do not necessarily have to start on that task on Day 1
on the job. However, we want to make sure that it does not start before that point in time.
Finish no earlier than [FNET]. We do not want to deliver early to some customers, for
example, particularly if we are working in a just-in-time environment.
Or start no later than [SNLT]. Do not want it to start any later than a given point in time. That
is the “drop dead” date, if you will, for when an activity has to begin.
“Work between” is when we have dates that are assigned but we do not care when, within
that time frame, it actually gets done. If it has to be done sometime between January 1 and
February 28, then that is a work-between time frame if it is only a week-long activity.

.....
SCHEDULING
Resource Trade-Offs: Leveling
A fixed start and end. That is when we absolutely know it must start on one day and must
finish on another.
As to those last two comments, MSO and MFO are “must start on” and “must finish on.” All
these constraints are going to help drive your schedule. Be aware, however, if you use the
hard date constraints—which are the FNLT, SNET, SNLT, FNET, work between, fixed start
and end, MSO, and MFO—in some software packages those are interpreted as hard dates.
They come across as hard dates, which means that they are coded into the software. They
work with the algorithms to establish a firm fixed date. Because that date is fixed, slack is
calculated against those dates. Thus, if slack were zero, often, using those constraints
alone will drive a path to critical even though it may not be critical all the way through the
network. Thus, in some software packages you will go halfway through the network and
have a critical path just stop in the middle of nowhere. That is often because of these types
of relationships. You need to be watching for them.
RESOURCE TRADE-OFFS: LEVELING

................................................................
Take a look at the diagram on the next page, and look at it carefully. The one question I
have for you is, if you are working at an office where they say you get absolutely no more
than four resources at any given point in time, could you still accomplish this schedule in 10
weeks if it was truly, purely resource-driven? Think about that for a moment. You are limited
to four resources; you still only have 10 weeks. Based on the resource loading that is
established here, could you still get it accomplished in just 10 weeks? What is your answer?
I hope your answer was yes, you can still get it done, because leveling involves reducing an
overcommitment of resources. We are overcommitted in this diagram on weeks 2, 3, 4, and
9. However, we are undercommitted in weeks 6, 7, 8, and 10. If we can off load some of the
resources from 2, 3, and 4 into weeks 6 and 7, and backload some of the ones from week 9
down into week 8 and over into week 10, we can accomplish the same level of effort within
10 weeks without exceeding that four-resource limit that has been placed on us. That is
what leveling is all about: reducing the overcommitment of resources.

SCHEDULING
4 Resource Trade-Offs: Leveling
Resource Trade-Offs: Leveling
7
6
Resources
Number of
5
4
3
2
1
0
1 2 3 4 5 6 7 8 9 10
Number of Working Weeks
However, be forewarned: if you decide to use automatic leveling or the leveling in the
software packages, we would not be able to accomplish that same goal with this same
diagram. We would not be able to do it, because when the software tools level, they always
level forward. They always level forward in a schedule. So while we could meet the 10-week
schedule based on weeks 2, 3, and 4, because those would fall into weeks 6 and 7, those
additional resources, when you go out to week 9, rather than pushing some of the resources
back in to week 8, the software package has a natural proclivity to move forward into weeks
10 and 11. It would push the resources over, beyond the end of our accepted schedule.
Beware of that if you are thinking about using the software package functions that say they
will level it for you—the automatic leveling features. Frankly, I always recommend to my
clients that we turn those off. You do not need to have those on. You should be doing
leveling yourself. If you are trying to analyze where your resources are going, you should
not be trusting the tool to simply move them out for you. It is a good idea to check it out,
each and every one, by yourself.

.....
SCHEDULING
Sample Procedure (Develop Software): WBS Example
Leveling is reducing the overcommitment of resources. To do that, you need to know where
you have free time available and where you are overcommitted. That is important
information for you as a project manager. It is not something you should leave to an
automatic function in a software package.
SAMPLE PROCEDURE (DEVELOP SOFTWARE):

WBS EXAMPLE
................................................................
I. Receive software modules
A. Develop testing algorithms—6 days
B. Prepare test area—2 days
C. Finish test procedures—3 days
D. Test algorithm and speed—10 days
E. Review documentation—3 days
F. Install hardware and software—2 days
G. Review software code—4 days
H. Test software against documentation—5 days
J. Run software test against procedures—8 days
K. Identify and document bugs—4 days
L. Test man-machine interface—6 days
M. Prepare test report—2 days
II. Finish testing
Over the next dozen sections—that’s right, the next 12 sections—you are going to look at a
single example. What we are doing with this example is walking you through the
fundamentals of a network and, at the same time, walking you through some of the
fundamental practices associated with resource leveling. You will want to examine each one
of these activities very carefully and try to identify some of the issues that are being raised

SCHEDULING
4 Define the Logic
here. Specifically, one of the things you should be looking at is the durations and the dates.
Make sure you are keeping track of where we are putting people on which days. That
becomes important as you work through the rest of this network.
DEFINE THE LOGIC

................................................................
Here you will notice that we have incorporated the activities and their durations and built
them into a network diagram. Specifically, we used the precedence diagramming method.
As you go through you will note that we began with a start node and a finish node and filled
in all the blanks in between. None of the activities are hangers. None is out there dangling
by itself with no connection, either a predecessor or successor. They are all interconnected,
at least to the start and/or the finish node. All the activities have some predecessor and
successors. You will notice they also have the durations written above them.
10
D. Test
Algorithm
6 3 5
A. Develop Testing E. Review H. Test

Algorithms Documentation Software
0 2 2 8 4 0
Receive B. Prepare F. Install J. Software K. Document Finish
Start
Software Test Area Software Test Test Results Testing
3 4 6 2
C. Finish Test G. Review L. Test M. Prepare
Procedures Software Code Interface Test Report

.....
SCHEDULING
Assign ES/EF Dates
ASSIGN ES/EF DATES

................................................................
Early start/early finish. Now we have taken the durations from the previous section and we
have now incorporated them as early start and early finish dates. Here you may find
something worth arguing about. In a regular schedule I might be challenged by the fact that
all the early starts and early finishes represent full days. In other words, in this calendar, we
are working weekends. We are working through the weekends and across any holidays that
might exist here. In some organizations that would be wholly unacceptable. In some
organizations that is business as usual. You need to make sure you are checking the
assumptions as you go through a network diagram. Are the assumptions indeed valid? In
this situation you would need to ask yourself, are these valid assumptions for our
organization? Do we work weekends?
4/6 4/16
D. Test
Algorithm
3/31 4/6 4/6 4/9 4/9 4/15

3/31 3/31 4/2 4/2 4/7 4/7 4/15 4/15 4/19 4/19 4/19
Receive B. Prepare F. Install J. Software K. Document Finish
Start
3/31 4/3 4/3 4/7 4/7 4/13 4/13 4/15


SCHEDULING
4 Review Float (Early Schedule)
REVIEW FLOAT (EARLY SCHEDULE)

................................................................
As you look across this modified Gantt chart, what we have done is we have taken the
information from our network diagram and plotted it out into this Gantt using the earliest
possible schedule—ASAP would be the default setting within your software. As you look at
this early schedule you can see, in the early parts of the schedule, we have virtually no
slack. The only slack or float that appears is on days 4, 5, and 6, and that stems from the
fact that there is one small chunk of the network where there is some float inherent in the
way it is laid out. The rest of the float all falls at the very end of the project. While that is nice
if you are trying to keep as much of the work as early as possible, it does not necessarily
reflect the best business practices or the best allocation of our resources.

.....
SCHEDULING
Review Resource Loading (Early Schedule/Transferable Resources)
REVIEW RESOURCE LOADING

................................................................
(EARLY SCHEDULE/TRANSFERABLE RESOURCES)
Those words up across the top may sound like just another header, but they actually have
some great significance. They bear into the decisions that have been made against this
project. Specifically, the point is that it is transferable resources. That is something that does
not exist on all projects. Transferable means that one resource has basically the same skill
set as another. That does not exist in many projects in the real world, unfortunately.
However, most software packages do assume that, indeed, all our resources are somehow
transferable—having one staff member work on it is the same as having another staff
member work on it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Total
E. Review
Documentation 3 3 3 9
H. Test Software 2 2 2 2 2 10
A. Develop
Testing Algorithms 4 4 4 4 4 4 24
D. Test Algorith 4 4 4 4 4 4 4 4 4 4 40
B. Prepare Test Area 2 2 4
F. Install Software 4 4 8
C. Finish Test Procedures 4 4 4 12
G. Review Software Code 2 2 2 2 8
J. Run Software Test
Against Proce 3 3 3 3 3 3 3 3 24
K. Identify and
Document Bugs 2 2 2 2 8
L. Test Interface 6 6 6 6 6 6 36
M. Prepare Test Report 3 3 6
TOTAL 10 10 12 10 6 6 9 16 16 15 15 15 15 12 10 6 2 2 2 189
As you look across this diagram, you get a sense of how our resource loading is going to
occur. You will notice if you look at the very bottom, in the Total row, you will have a large
number of resources early in the project, an even larger number in the middle of the project,
and at the very end of the project we are down to just two staff members wrapping things up.

SCHEDULING
4 Resource Loading Histogram (Early Schedule)
That is how it goes with an early schedule. The emphasis is on the beginning and the
middle, not on the end.
................................................................
RESOURCE LOADING HISTOGRAM (EARLY SCHEDULE)
Based on information we have from the previous section, once again we have another way
of looking at the resource issues associated with this project. Just look at this and think
about presenting it to your management. What challenges might you face presenting this
section to your boss? Or, what challenges might you face managing this particular project?
Resource Loading Histogram
20
18
16
Resources
Number of
14
12
10
8
6
4
2
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Workdays
In our organization I can tell you what I might face. Workdays 7 and 8, I am simply ramping
up with a large number of additional resources. Adding all those resources in such a short
period of time is almost bound to create some kinds of challenges within the organization.
People either will not be available or, if they are available, there is going to be an

.....
SCHEDULING
Review Logic (Late Start/Late Finish)
expectation that I get them on the job, up to speed, at exactly the same time. Getting that
many people informed as to what is going on in a project at the same time is a challenge for
anny manager.
REVIEW LOGIC (LATE START/LATE FINISH)

................................................................
4/6 4/16
D. Test
Algorithm
4/9 4/19
3/31 4/6 4/6 4/9 4/9 4/15
4/3 4/9 4/11 4/14 4/14 4/19
3/31 3/31 4/2 4/2 4/7 4/7 4/15 4/15 4/19 4/19 4/19
Receive B. Prepare F . Install J. Software K. Document Finish
Start
3/31 4/3 4/5 4/5 4/7 4/5 4/15 4/15 4/19 4/19 4/19
3/31 4/3 4/3 4/7 4/7 4/13 4/13 4/15
3/31 4/3 4/3 4/7 4/11 4/17 4/17 4/19
We have taken the same network diagram we had just a little while ago, and now we have
done the backward pass. We have calculated it from the back to the start. By doing this we
have established the late finish and late start dates for each activity. And we have calculated
them and put them down in the lower right- and lower left-hand corner of each activity. That
is important information, because it gives us a sense of, how late can everything run and still
get the project completed on time? It creates a completely different outlook on the project.

SCHEDULING
4 Review Float (Late Start/Late Finish)
REVIEW FLOAT (LATE START/LATE FINISH)

................................................................
As we look at this diagram—once again, it is our modified Gantt chart—this modified chart
has all the float pushed to as early as possible, based on the fact that we are working with
the latest possible schedule. Now, early in the project we have very few activities going on;
at mid project, we have a little more float; but at the far end of the project, everyone is fully
engaged. The entire team is going to be fully active. That is a radically different look at the
project than we had with the early schedule, and it requires a different type of management.
REVIEW RESOURCE LOADING (LATE SCHEDULE)

................................................................
This is the same chart you just looked at a few pages back, only this time, all the resources
have been loaded as late as possible. You may recall at the end of the project in the earlier
sections, we had resources down to two a day for the last several days of the project. Now
the last several days of the project include as many as 14 resources. That is a very busy
project down to the bitter end. Also note that early in the project we only have as few as four
resources working. If we have limited access to our resources early in the project, this may
be a viable way of approaching the schedule. If management is not ready to handle the

.....
SCHEDULING
Resource Loading Histogram (Late Schedule)
resources until the project is under way, this may be the only solution to still get the project
accomplished in the same amount of time. But realistically, what we often try to achieve is a
balance.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Total
E. Review
A. Develop
D. Test Algorith 4 4 4 4 4 4 4 4 4 4 40
Against Proce 3 3 3 3 3 3 3 3 24
K. Identify and
TOTAL 4 4 4 8 8 10 10 7 7 7 7 16 16 16 15 14 14 11 11 189
RESOURCE LOADING HISTOGRAM (LATE SCHEDULE)

................................................................
Earlier I identified as one of my key concerns the fact that in about week 8 or 9 I was going
to be adding significant resources to the project. Now I still have that problem—only,
because I am using the late schedule, that problem does not occur until Day 12. On Day 12
of the project, I suddenly add a lot of resources. It is going to require extensive management
attention, and I am going to have to work to keep them on board for the entire final week of
the project. That may not be an easy task. Note that early in the project, however, my
management efforts may be reduced, in that I have fewer resources to deal with early in the
project.

SCHEDULING
4 Review Resource Loading (Resource-Limited)
Resource Loading Histogram (Late Schedule)

Number of Resources
20
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Workdays
................................................................
REVIEW RESOURCE LOADING (RESOURCE-LIMITED)
In both the earlier schedules, both the as-early-as-possible and the as-late-as-possible
schedules, we had the opportunity to use as many as 15 or more resources at any given
time. Now we are working under the assumption that management has come to us and said,
“Oh, no, project manager. You only have 13 resources to work with. That is the most you
can possibly use.”
Take a look at this section carefully and notice how we have pushed some of the activities to
their early schedule and some to their late schedule, all for the sake of accommodating that
resource limitation. That is true resource leveling. Reducing the overcommitment of
resources and, at the same time, making sure that we are getting best value for the
organization. This had to be done one person at a time to ensure that we were getting the
right number of resources on the right days. It was painstaking, it took time, but it also was
honest, quality management.

.....
SCHEDULING
Resource Loading Histogram (Resource-Limited)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Total
E. Review
A. Develop
D. Test Algorith 4 4 4 4 4 4 4 4 4 4 40
Against Proce 3 3 3 3 3 3 3 3 24
K. Identify and
TOTAL 10 10 12 10 6 6 5 12 12 13 13 13 13 10 12 6 8 8 8 189
RESOURCE LOADING HISTOGRAM (RESOURCE-LIMITED)

................................................................
Here is the histogram with the resources allocated according to our modified schedule. Yes,
we still have the challenge of adding new resources in week 8, but we have balanced out
our use of the resources across the rest of the schedule by adjusting when we are having
some activities with their float, and when we are not.
Amazingly, project managers consistently complain about the lack of something to manage.
They claim that we are assigned loads of responsibility with no authority. Float within these
network diagrams often gives the project manager more to manage than he or she may
realize. There is often the opportunity to actually exact some management skill here based
on how the schedule is laid out. Using the schedule effectively, we can work with just 13
resources. We can get the entire project accomplished on schedule and within budget
without going into any overtime or into any overallocated resources—specifically, by just
moving the network to accommodate float well and to recognize our resource limitations.

SCHEDULING
4 Gantt Chart
Resource Loading Histogram (Resource Limited)

Number of Resources
20
18
16
14
12
10
8
6
4
2
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Workdays
GANTT CHART
................................................................
The Gantt Chart is the one that most project managers cite as being the tool they use most
often to display project information. It is convenient. It is organized. It is laid out very nicely.
It is a bar chart created by Henry Gantt back in the 1910s. It is a relatively simple information
source. It is a great place to go for information. But it also does not tell much of the story
behind it. Still, it is one you will be using regularly and one you will want to make sure you
understand.
If you are using multiple bars on a Gantt chart, remember: they do not always print out as
effectively as they might look on the screen. You want to make sure that you understand
what all the bars are and that you have made them clear enough so that anyone who is
looking at your Gantt chart can readily interpret exactly what it means.
For most instances, you will see them going in a neat stair-step effect, going down the Gantt
chart. That is fine with linear projects. But with a product-oriented WBS, more and more

.....
SCHEDULING
Creating a Gantt Chart- Exercise
often you are going to see Gantt charts that do not necessarily reflect a nice stair-step
schedule. That does not mean there is anything wrong with the way the project is laid out. It
is just a matter of the way the information is being interpreted. Do not confuse the two. A
Gantt chart that has a bunch of serrated edges, if you will, is not inherently a bad Gantt
chart.
CREATING A GANTT CHART- EXERCISE

................................................................
Here you have it: an opportunity to build a Gantt chart all your own. It is a very simple
request. All we are asking you to do is simply line up your activities on the left-hand side of
the diagram by their WBS number: 1.1.1, 1.1.2, and so forth. Then, simply align the
activities below them in Gantt-chart fashion. After you have done this, the answer that you
need to submit is, how does the stair-step effect work here? Is it one clean set of stairs, or
do we have a more serrated edge, a more jagged edge, if you will? If you are using this
book and working towards PDU’s, please submit your assignment as directed.
1.1.1 1.1.2 1.2.2

Start Finish
3 4 9
1.2.1 1.3.1 1.3.2

6 4 3

SCHEDULING
4 Setting Milestones
SETTING MILESTONES
................................................................
• Activities of zero duration
• Significant events
• Denote achievement (time, money, task)
Every project has its milestones. We tend to think of the obvious ones: Start, Finish, Kickoff
meeting complete. Those are probably the biggest ones. Remember the big things about
milestones, though. For one, a milestone is an activity of zero duration. It has no resources
assigned to it. That means “Kickoff meeting” is not a milestone. “Kickoff meeting
complete”—there is a milestone. It is always like a light switch—it is either on or it is off. It
has either happened or it has not. It is an absolute. It is an attribute. There is no way that
you can have any variable in there. With a milestone it is one way or the other, and it
denotes some kind of achievement. It can be the allocation of resources, time, money,
completion of tasks—any variety of things can be used to establish what milestones are. But
the important thing to remember is that a milestone is nothing more than a marker in time. It
is a road sign along the way: hey, we have made it this far; we have accomplished this
much.

.....
SCHEDULING
Building a Milestone Chart - Exercise
BUILDING A MILESTONE CHART - EXERCISE

................................................................
• Kickoff meeting: Day 3
• First half of Phase 1: Days 1–16
• Needs analysis: Days 4–8
• Draft needs analysis report: Days 9–12
• Customer reviews analysis: Days 13–20
As soon as you looked at this diagram you should have had a moment’s pause. You should
have been thinking, “Hey, Brent, those are not milestones.” That’s right. These are activities.
These have duration. Some of them are even summary activities. But specifically you need
to be aware of what kind of milestones might you establish against this schedule?
These are specific activities. What you need to do is create a list at least with at least four
different milestones that might be extracted from these activities. Do not necessarily
assume the obvious. Do not just put the word “complete” behind each one. That has been
done before. Try and find some different milestones that you might be able to ascribe to
each one of these activities. If you are using this book and working towards PDU’s, please
submit your assignment as directed.

SCHEDULING
4 Building a Milestone Chart - Exercise

THE B ASELINE
...................................
5
.....
OBJECTIVES
• Determine project baselines using fundamental estimating processes

• Interpret data gained from time-phased distribution of project costs
• Establish a baseline for a project
• Develop a cumulative cost curve
By the end of this chapter, we have a number of goals we really do want you to accomplish.
Specifically, what we want you to recognize more than anything else is what a baseline is
and how it is actually deployed in the project environment—how you use the baseline as a
tool for both setting expectations, as well as implementing the project itself.
THE BASICS OF BASELINES

................................................................
• What: The original plan, plus or minus approved changes (PMBOK® Guide)
• Why: To define a standard against which project success can be judged
• When: Upon approval and endorsement of all baseline components
Every project should have a baseline. That is exactly what the project manager is supposed
to report against. The baseline is the original plan plus or minus approved changes. Notice
the word “approved.” That is critical to the idea of a baseline. A baseline is not a baseline
unless it has been approved. It gives us a standard against which the project can be judged,
and it gives us the opportunity to get other people to buy in to the project plan—to get them
to agree to the general concepts that we are putting forth. It gets everybody in on the act.

THE BASELINE
5 Baselines
BASELINES
................................................................
The baselines that we need to deal with are the technical baseline, the schedule baseline,
and the cost baseline. Obviously, because of the course you are working in right now, the
ones we are going to focus on are the schedule and cost baselines. But for all these
baselines, you need to deal with the three issues to the left of this section. You need to
define the work, establish a baseline budget, and establish the baseline schedules.
All that information is going to go together to create the ultimate project baseline. All of it
funnels into the diagram you see on the right. We set a performance measurement baseline
and then, above that, we set a budget estimate. Notice the difference between the two.
Notice that they are not one and the same. The performance measurement baseline is
based on the information that has been provided to us as we develop the estimates for the
individual tasks. Each one of those tasks creates the performance measurement baseline. It
is the work we are going to do and what we expect it to cost.
Normally, folks have a tendency, above and beyond what they expect it to cost, to add in
their own little bit of pad or fudge. We do not want to do that in our projects if we are going to
be doing honest estimating. Instead, what we want to do is have a baseline for performance
measurement and above that have a segment of reserve. That reserve is in case something
does go wrong—in case we are not able to meet the performance measurement baseline.
We then put our budget as the performance measurement baseline plus the reserve. That
allows us to track when things go awry, when we encounter problems in our projects. That is
what that reserve is all about. That gives us the pad that we would normally put in activity by
activity, and frankly, normally gets lost activity by activity. The baseline is the real, honest
effort that it is going to take to do the work based on the work, the budget, and the schedule.
COST BASELINE
................................................................
Take a look at this cost baseline. There is a lot of information that goes into what establishes
our costs. The contract price is made up of our target fee plus our target costs. This
particularly applies in cost-plus contracts and in fixed-price-incentive-fee contracts. We
normally have a separate fee from our costs. Sometimes this information is hidden from the
customer, as in fixed-price contracts. In firm-fixed-price contracts you will not see the
separate target fee and target costs, but they are embedded there.
Within the target cost, we have our performance measurement baseline. That is made up of
what has already been distributed to various cost accounts for the work packages that we

.....
THE BASELINE
Cost Baseline
have open, and for the undistributed budget for the work packages that we have not opened
up yet. We are holding that money back until we are ready to open those work packages,
because things change. We may change some of those work packages as the project
progresses.
Contract
Price
Target Fee Target Cost
Performance
Measurement Reserve
Baseline
Unidentified
Distributed Undistributed Overruns on
Work within
(Cost Accounts) Budget Existing Work
Scope
Over on the other side, we have reserve. It is held back for unknowns, and there are
different types of unknowns. There is unidentified work that is within the scope of the
project, and there are overruns on existing work—sometimes things just go wrong, they run
long. So we make those corrections here with the reserve, where we can track the changes
that have occurred. That is what reserve is all about. By using these components to break
down our cost baseline, we can keep far better track of the information that is going into a
given project and keep better track of our costs and how we are expending them.
The following is an exercise and what I want you to do is analyze this project and, based on
the early schedule, go through and calculate what our cost baseline is if each resource is
costing us $100 per day; that is, $100 per day, and each activity requires only one resource.
Yes, activities can be conducted in parallel; we have more than one resource at our

THE BASELINE
5 Cost Baseline - Exercise
disposal. First, create the baseline using the early schedule. How early can we get all this
work done, doing it all as soon as possible? Then, send the data points for Days 5 and 10.
Also send Days 5 and 10—their points on the cost baseline—based on the late schedule.
What if we do all this as late as possible? You will want to use the late start and late finish to
calculate those times.
You will need to go through the network, calculate the network, do a forward and a
backward pass, and then calculate the cost baseline for both the early schedule and the late
schedule.
COST BASELINE - EXERCISE

................................................................
You will notice that you have two different curves based on those two schedules. Plot them
on this graph and then look at Days 5 and 10 and send those pieces of information for both
the early schedule and the late schedule. It is a cumulative cost curve that you are building
here, so expect it to do nothing but increase as you go toward the end of the project. If you
are using this book and working towards PDU’s, please submit your assignment as directed.
2500
2000
1500
1000
500
0
1 5 10 15 20

.....
THE BASELINE
Technical Baseline
Start Duration = 3 Duration = 4 Duration = 4
Duration = 5 Duration = 3 Duration = 4 Finish
TECHNICAL BASELINE
................................................................
• Specification
• Detailed design
• Customer sign-off
Up to this point we have been talking about the cost baseline primarily, and it is interesting
that we have not paid a lot of attention to the technical baseline. Frankly, it is a Scheduling
and Cost Control course, so that is not too much of a surprise. However, without a good
quality technical baseline, it is impossible to build a good cost baseline or a good schedule
baseline.
As you have learned in any of the basics courses, the triple constraint says that anytime you
change one side of the constraint, the other two sides must inherently somehow be affected.
Thus, when the technical baseline changes, it is going to affect our costs and/or our
schedules. It has to happen.
The technical baseline consists of the specification, the detailed design, and it goes through
customer sign-off. It is what it takes to get the customer’s signature. That makes it very
important. And it also leads us to the question of, how much are we willing to give the
customer for what they are paying and for the schedule they have allowed us?

THE BASELINE
5 Time and Cost Trade-Offs
TIME AND COST TRADE-OFFS

................................................................
These networks look like the same network presented twice with different costs assigned to
each. But they are not the same. Look at Task 1.2.2. That task went from a 5-day duration
down to a 4-day duration. It got shorter because we tossed some additional resources at
it—we added more staff. By adding more staff, we increased our costs by $400 but saved
ourselves a day of time.
Total
1.1.1 1.1.2 1.2.2
Cost Start
8 6 5
Finish
$5,400
1.2.1 1.3.1 1.3.2

10 2 4
Total 1.1.1 1.1.2 1.2.2

Cost Start
8 6 4
Finish
$5,800
1.2.1 1.3.1 1.3.2

10 2 4
That is often what happens in the corporate environment. We increase our costs by adding
resources. Last-minute resources cost more than resources we have carefully planned for.
In this particular scenario, we have established a couple of basic rules. (You may want to
print out this section, because we want you to look at it in-depth.) Specifically, I am going to
give you a few rules, and I would like you to make note of them. First, cutting any task in this
network by 1 day will cost you $400. Cutting a task by 2 days will cost you $1,000. That is
the most that any activity can be cut on this network. Why these rules? Well, that is how it

.....
THE BASELINE
Time and Cost Trade-offs - Exercise
happens to affect this particular corporate environment. And frankly, it represents the way a
lot of organizations do business. If you are adding last-minute resources, they cost more. No
task in this network could be trimmed more than 2 days or cut by more than half.
TIME AND COST TRADE-OFFS - EXERCISE

................................................................
My question to you is, just how tight can we make this network? How short can we make the
duration? How expensive will it be to get it down that close? We cannot change the
relationships; we can only trim the activities by no more than half. And cutting an activity
costs $400 for 1 day and $1,000 for 2 days. The question is, how short can you make this
network diagram, and where is the critical path? If you are using this book and working
towards PDU’s, please submit your assignment as directed.
COST/TIME SLOPE
................................................................
If you were working on the previous section, you now get a chance to look at how your work
could have turned out had you come up with any variety of durations. That is what a
cost/time slope does; it looks at, how much are we getting for the money we are investing in
terms of time?

THE BASELINE
5 Cost/Time Slope
$12,000
$10,000
$8,000
$6,000
$4,000
$2,000
$0
13 14 15 16 17 18 19
Days
On the far right-hand side of this diagram, we have the full schedule at 19 days and $5,400.
If we reduce Task 1.2.2, as we did in the previous diagram, we are reduced to 18 days, and
the total cost of the project goes up to $5,800.
Want to cut it by another day? Reduce Task 1.1.2. That will drop us down to 17 days, and it
is going to raise the cost to $6,200. If we want to reduce by another day, we are going to
have to cut back on Task 1.1.1. That is going to bring us to 16 days and a cost of $6,600. Up
to this point, we have never cut any task by more than 1 day.
Beyond this point it gets very expensive to make any additional cuts. To cut back to 15 days,
we have to reduce two tasks: Tasks 1.2.2 and 1.2.1. That second reduction on 1.2.2 is going
to cost us $600. It is the first cut on 1.2.1, so it is going to cost us $400. The total cost to the
project is now $7,600 for that 15-day duration.
Going back to 14 days, it goes up to $8,600; going back to 13 days costs us $9,600. Both
Tasks 1.1.1 and 1.3.2 have been reduced. At this point, Tasks 1.1.1, 1.1.2, and 1.2.2 have
all been reduced by 2 days, and Tasks 1.2.1, 1.3.1, and 1.3.2 have all been reduced by 1
day. All those costs go together to generate expensive projects. It is becoming expensive
because we are cutting back on the amount of time the project is going to take.
Now, if you are asked to cut back your schedule, using a cost/time slope can be a very
valuable tool. Management, your management, can now assess how much they are willing

.....
THE BASELINE
Review the Baseline
to increase your budget to accommodate the cut in schedule, particularly if you can show
them, day to day, just how much it is going to cost (or week to week, depending upon the
magnitude of your particular project). You can give your management the opportunity to
walk through the schedule and get a sense of how much each additional day is costing
them. Most of them would tend to stop at about Day 16 because that is where the slope
increases most significantly. That is where you can make the big difference. That is what the
cost/time slope is all about.
REVIEW THE BASELINE

................................................................
• Ensure that the baseline is agreed upon
• Work to prevent risks before setting the baseline
• Know when and how to change the baseline
• Be clear about when and how to access management reserve
• Know the objective measures to identify when the baseline is out of control
There is an old Texas saying about a frog in a skillet: if you put a frog into a skillet of water,
it will stay there. It will stay there even if you raise the temperature of the water up to boiling.
It will stay there until it is cooked to death. However, put a frog in hot water, it will jump right
out.
Reviewing the baseline is important because the baseline keeps us from being that cooked
frog. Specifically, we want to review the baseline to ensure it is agreed upon, that we know
what risks are out there, that we know when and how we are going to make changes, we
know what management reserve is in place and what is not, and we can set objective
measures to identify when the baseline is out of control. If we do not set the baseline and we
do not set those objective measures against the baseline in advance, we will be just like that
frog. We will watch as our project slowly, incrementally, gets out of control, and we will not
panic until it is far too late.
We need to make sure that we have reviewed the baseline thoroughly, and that we have set
those thresholds so that we know when it is time to jump, when it is time to take distinctive
management action to deal with the problems that arise associated with our baselines and
our projects. Reviewing the baseline is a critical step in doing effective project management,
and especially in doing effective cost and schedule controls.

THE BASELINE
5 Review the Baseline

MANAGING C HANGE W ITHIN THE P ROJECT
...................................
6
.....
OBJECTIVES

• Design a project control system
• Understand how to use management reserve
• Apply techniques to manage against the baseline
• Identify specific elements available for control in an active project, and implement
methodologies to exercise that control
• Predict and control change against the baseline
• Establish change management practices
We have a lot of things we would like to accomplish during this particular chapter. The thing
I want to make sure that you understand is that it becomes incumbent on you to implement
the change control system that we generate here. No matter what we do here, it becomes
your responsibility to work the change control systems that are put in place. Many
organizations have very strong change control systems that are never used; they are never
actively implemented. And as such, the organizations lose the advantage of having change
control.
It becomes incumbent on individual project managers to work together across an
organization to ensure the change control is consistent. That means you become
responsible for other project managers, and unfortunately, they become responsible for you
as well. That means that everybody has to take responsibility for change control, and if a
single link in that chain is broken, if a single project manager decides change control is not
that important, it has the potential to jeopardize it across an organization. It is something
that has to change culturally within the organization to truly make it effective. We will talk
about that more as we go on.

MANAGING CHANGE WITHIN THE PROJECT
6 What Is Control and Management?
WHAT IS CONTROL AND MANAGEMENT?

................................................................
Plan Actuals
Comparison
Trend
Analysis
Variances
Replanning Forecasts
Variance
Analysis
Decisions on
Actual Plan
Well, I have some good news and some bad news. The good news is that most of us have
the information that goes in those top two boxes on this section: plan and actuals. In some
organizations, however, I have walked in to teach and had them say, “Brent, we do not have
that information.” If you do not have that information, you cannot control or manage. You
just cannot. You need, very simply, to have those pieces of information before you can
really get in and do any true management.
Let’s take the example of the world-record house. In that situation, there was a plan, and the
plan was to pour the concrete about 15 minutes into the project. In reality, the concrete was

.....
Where Do Changes Come From?
poured only 10 minutes into the project. The comparison? They had some extra time. The
variance? About 5 minutes. The analysis? Well, they realized that could affect framing and
some of the other issues down the line. Decision on the action plan? They took the extra
minutes to line up the frame more perfectly to ensure a good fit. Preplanning? Done and
communicated to the subtask leaders, and the new plan involved an earlier schedule than
the original world-record house. The actuals were evaluated for trends, the house was
moving along ahead of schedule, and it became not a 4-hour house, but a 3-hour house.
Pretty impressive. They used the basics of control and management.
WHERE DO CHANGES COME FROM?

................................................................
• Customers
• Project team members
• Government
• Environment
• Product obsolescence
• Managerial alterations
• Technological advances
• Funding changes
I love that question. It is a classic because, frankly, change comes from everywhere. It is
coming from customers, from team members, from the environment, from the government,
from the marketplace, from obsolescence, from technological advances, from changes in
the money that is available to us—there is change coming from virtually every source you
could ever fathom. You could make a longer list for this particular section than we could ever
generate in PowerPoint. There are dozens, hundreds of places where change comes from,
and it is up to us to be proactive about those changes. That’s right—proactive, not reactive.
We have to anticipate where the changes are going to come from. On every project you
learn that as you go, but early in the project you should start identifying where you anticipate
the most change. Is it going to come from the customer? Is it going to come from some team
members? Unfortunately, some of our team members have, well, vision. They get these
insights that they feel they have to implement on the project, and as a result, it costs us in
terms of the cost and the schedule.

6 Change Management Process
We need to make sure that we have identified where the changes might be coming from and
how we can deal with them. We talk about that a lot in risk management, but it plays in
heavily here, because identifying these changes early becomes the responsibility of the
project manager. And preparing for them is a big element of scheduling and cost control.
................................................................
CHANGE MANAGEMENT PROCESS
Every organization has its own type of change management process. For some
organizations, it is extremely formal and far more elegant than the one on this section. In
other organizations, it is a matter of “Do what you think is best and in the best interest of the
organization and the project.”
Identify and
Screen Assess
Submit Change
Request Impact
Request
Get Customer Inform Implement and

Approval Stakeholders Document
Well, the change management process that is defined here is rather generic, if you will. It
asks you to identify and submit the change request, have some means by which the change
request is actually documented as it comes in—and that includes even the smallest
changes. “Brent, I do not have time to document the small changes.” Sure you do. You do
not have time to deal with the problems that will be generated if you do not document even
the smallest changes. Because unfortunately, from team member to team member, project
manager to project manager, if those small changes are not documented, it is going to be
make-work down the road beyond belief.
A classic example came when I was doing some work in an aluminum factory recently. They
were about to do a major project on moving some lines. Unfortunately, some of the lines that
had been laid in the ground (these are high-voltage lines) were not properly documented.
They had made some minor changes to go around a rock here and around a pit there, and
as a result, the wires were not where they thought they were underground. The change
management process had not been properly followed. Nobody had identified and submitted
any change requests. As a result, people’s lives were put in danger because they did not

.....
Identify Change Request
know exactly where the power lines were underground. And as a result, that organization is
doing a major investment in trying to find those power lines before it can move forward on
any project in that part of the site.
We need to screen the requests. Does the change make sense? Is it good business?
We need to assess the impact—and that is part of the latter question.
We need to get customer approval. Even if the customer submits the change request, they
need to approve it. They need to go back and say, “Yes, I realize that is what I am asking
for. I realize it has that impact on the cost, or on the schedule, or simply on the management
level required for this project. I understand those parameters.”
We need to inform the stakeholders. Team members need to know when changes occur,
even if it only affects them peripherally. If they do not have a sense of what is going to
change, they are going to be left out of the process, and it is going to hurt.
Finally, we need to implement and document the changes. We need to track those changes
carefully. We need to make sure that they are saved for posterity so that we do not wind up
with those power lines running underground with somebody trying to find them without
getting hurt.
IDENTIFY CHANGE REQUEST

................................................................
• Who
• What
• When
• Document
Let’s walk through the process, and as we do, think about how change is managed in your
organization. See Tool 5 in the Appendix.
Identify change requests. If it is not written down, it does not count. If we have not
documented it, it does not exist. No matter how much the customer said it was urgent, it was
important, they desperately needed it, it is something they will document later—if it is not
written down, it does not exist in the project record. You must have some form for tracking
this information, whether by e-mail, on paper, or electronically. Ensure that somewhere
there is a change request that identifies who requested the change, what the request is,
when that request came in—and ensure that documentation is saved.

6 Evaluating Change Effects
Many organizations have been rescued by virtue of effective change control and effective
change documentation. And I am sure you have experienced once or twice, as most
seasoned project managers have, an undocumented change that came back to injure your
project. You must make sure that does not happen.
Your change document may be as simple as the one presented here. If you do not have a
change form in place, use this one until you create one that will work in your organization.
Make sure, even if the customer is not filling it out, that you are filling it out every single time
a change comes through. Some documentation must be kept, and there must be a
consistent record. A tool like this goes a long way toward creating consistency.
EVALUATING CHANGE EFFECTS

................................................................
• Triple constraints
• Functional areas
• Team
• Project
Any time there is a change, we need to make sure that we are evaluating the effect on
everything associated with the project. That includes checking the effect on the triple
constraint. As we said at the very outset of the course, any time you make a change to one
side of the triple constraint, you are going to affect the other two. If the customer comes to
you and requests a change in the scope of the project, you inherently are going to expect a
change in either the time or the cost involved in that project. Similarly, if I request a change
in the cost, I can expect a change in either the time or the scope of the project as well.
That is not all we need to check the effect on, though. We need to be looking at the
functional areas. How is this going to affect the other projects and issues they are working
with? If I request more resources or request them for a longer period of time, it is going to
inherently involve some impact on their other work.
I need to look at the effect on the team. In many cases, pushing a team too hard can be just
as detrimental as overspending a budget. You can ruin the progress of a project that way.
And you have to look at the effect on the project. Will you still be able to carry off the project
and get it done effectively according to spec? If you cannot, then the change just is not
worth it, and the customer needs to be made aware of that.

.....
Coping with Change
COPING WITH CHANGE

................................................................
• The project master plan should be amended
• Performance variance outside accepted forecast limits must be explained
• When a change will not be effective, the project manager must shield the team and
the organization
• Go for the close
The bullets in this particular section represent citations from sources (some of the best
sources, in fact) of project management. Specifically, the reflection on the project master
plan—the need for an amendment there—it needs to be amended in a variety of ways.
Think about how you would do that. You might add some tasks to the WBS. You might
update the network diagram. You might update the budgets. You might go in and modify the
scope documents. You need to make sure that everybody is in on the changes to the master
plan—the customer, the team.
You also need to deal with performance variance. That comes from Dinsmore’s material
[see bibliography in Library]. There is talk about communicating change across the
organization and how important that is. You need to make sure that everybody knows what
the new expectations are, based on the variances that have been generated by the change.
Remember that some changes simply will not be effective. Some changes are going to hurt
the project, and you need to get that across to the customer. There is a quote from Wes
Roberts that says, “When victory will not be sweet, the chieftain must keep his Huns from
war.” It is actually from his book, Management Secrets of Attila the Hun [see bibliography in
Library]. It is a great book, and it makes a great point. If you cannot win the war, do not go to
battle. It is not worth it. If it is not going to allow for a successful project, do not make the
change.
Let the customer know what is going to happen, and you need to make sure that you have
made clear what you are saying. You need to go for the close. You need to make sure the
customer absolutely, positively hears what and why we are changing or why we are not
changing. That is very important. It is not an easy sell sometimes, but sometimes it needs to
be made. And we need to make it more strongly than we have in the past. That old quote
about the project manager’s least-used word and most-needed word being “no” applies very
strongly right here.

6 Updating the Plan
UPDATING THE PLAN

................................................................
• Cost
• Schedule
• Resources
• Milestones
• Documentation
1.1.1 1.1.2 1.2.2

Start Finish
7 5 4
1.2.1 1.3.1 1.3.2

6 4 3
11
1.1.1 1.1.2 1.2.2

Start Finish
7 5 4
1.2.1 1.3.1 1.3.2

6 4 3
Whenever you make a change, the plan must reflect that change. A project manager in one
of my classes once remarked, “When we make changes in our organization, we kind of
keep them in our heads.” I was frightened by that statement. I could not help but think that if

.....
Exercise
that student—that project manager—could not serve through the end of the project, some of
that data would be lost. And there will be problems with that project. And those problems
could lead to project failure. And if there is a project failure, the second project manager will
not know what happened, because that change will not be documented. The plan will not be
updated, and that is frightening.
Look at the change exhibited here. As you look at this particular change, you see that one
11-day task added to the project will make a significant impact. It is Day 6 of this project. We
are going to add an 11-day task to this project. How will that affect those things listed in the
bullets? What will happen to the cost? What will happen to the schedule? What will happen
to our resources and our resource utilization? What will happen to our critical path? Will we
see any changes in milestones?
I would like you to answer this question: In a project you are currently involved with, either
as project manager or team member, what would happen if an 11-day task were added?
That’s it—just one more 11-day task to the cycle. What would be the impact?
I know that a lot of you are working on radically different projects. Some of your projects
may be stretching across the span of years; some of you may be on a 3-day project, a very
short burn, as it were. I am not really interested in the scope of your project; I really want a
sense of what would happen if somebody added 11 days to your project.
EXERCISE
................................................................
What documentation would you need to record and deal with that change? What would you
do in your organization to make sure that the change was properly documented? If you are
COMMUNICATING CHANGE
................................................................
If you can track it, you can prove your arguments. (See Tools 6 & & in the Appendix) And if
you can prove your arguments, you can manage a lot more effectively. Think about it. Who
wins the discussions that go on about he said, she said? When those kinds of discussions
occur in any kind of contract arrangement, invariably it is the person with the best
documentation.

6 Implementing Change
Now, granted, no one wants to spend their lives filling out forms. Change responsibility
documents, document control documents—nobody wants to be tracking all of these data.
However, in many cases, the person with the best data wins.
I reflect back on one of my former coworkers. Vern kept a notorious phone log. He was
renowned for his ability to track phone information. If you called Vern, he knew exactly what
was said, what day, what time, who said it, and what agreements were made. No one ever
argued with Vern about what was said during a phone conversation. When it came to phone
discussions, Vern invariably won. Why? He kept the best records. He kept the best
documentation.
What you have here are two pieces of sample documentation that help you be a winner
when you are in a change discussion—when you are trying to resolve who asked for what or
what was the reasoning behind a particular change. Change is where projects are often won
or lost. And this kind of documentation can often make it or break it for you or your
customer.
As you deal with change, my recommendation to you is not necessarily to foist this kind of
documentation on your customer but, instead, to make sure that it is filled out every time a
change is requested. That does not mean the customer has to be the one filling it out. In
many cases, in a good customer-service model, we will take responsibility for filling it out,
simply ensuring the customer knows it has been filled out and, in some cases—the
important cases—making sure a customer’s signature is attached.
IMPLEMENTING CHANGE
................................................................
• Plans and interim plans
• Interim baselines
I love the fact that a lot of people simply keep track of the original baseline and the current
status of the project. In most projects, particularly projects that run more than a few months,
that is pretty unrealistic. We have a lot of baselines. We have the baseline that existed when
the project was originally conceived. We have a new interim plan or interim baseline, if you
will, that was generated when the new boss came on board. We have another interim plan
that was developed when the new customer’s boss came on board.
Every time there is a significant level of change to the project, we often need to track that
change and establish just what was said at that given point in time. What agreements were
established there?

.....
Using Reserve
If you keep track of the different baselines, you have the original baseline; then you have an
interim baseline; then you have a second interim baseline. All that information gives the
project manager an opportunity to analyze where changes occurred and the impact that
change had on the project as a whole.
It is important to know exactly what happened and when it happened and to make sure that
the project manager can identify how those changes impact the project in the long run. In
many cases, we are asked to go back and reflect on what happened, when it happened, and
who caused it to happen. These kinds of interim plans allow us to do just that.
USING RESERVE
................................................................
I cannot tell you how many organizations and how many individuals I have sat down with,
long form, and tried to discuss the concept of using reserve. Using reserve is a good idea if,
and only if, you can keep track of it—if you can track where the information is going and who
is consuming it, and why. You need to track reserve because it is a means to keep track of
where the project has run well and where it needs to be running more effectively.
In the actual deployment of reserve, it is not used for the little stuff; it is used when we have
significant cost overruns or significant time overruns. When those occur, you need to deploy
reserve, and you need to document exactly what happened to cause deployment of that
reserve.
We use reserve to deal with specific contingencies. They can be special cases or just
significant changes that we did not anticipate within existing work packages. But we need to
have the reserve so that we can identify, here’s where we incurred additional cost or time,
and here’s how we spent that cost or time. It encourages honest reporting in organizations
that use it well. Otherwise, it is, as some critics charge, a slush fund for project managers.
Only if you can track the information and if you are reporting the information back up to
upper management is reserve effectively deployed.

6 Using Reserve

E VALUATION AND F ORECASTING
...................................
7
.....
OBJECTIVES
• Define methods for measuring project progress

• Review and apply the discipline of earned value and its role in scheduling and cost
control
• Set up an earned value system, and evaluate project progress using that system
• Determine when a project is out of control
What I really would like to see you be able to do at the end of this chapter is not necessarily
defined by these bullets here. They do not define it as well as I would like them to. What I
really would like you to be able to do at the end of this chapter is to be able to walk into your
project meeting, your very next one, and feel comfortable making some clear predictions of
where things are going to go, how the project has performed to date, and how that
performance is going to have an influence on the future performance of the project. If you
can accomplish that, these bullets will have some significant meaning within the context of
your project. Otherwise, they tend to run a little stale and just sound like numbers-crunching.
That is not what we are doing here. What we are trying to do is to look into the crystal ball
and look into the future.
EVALUATION
................................................................
• Examine
• Update and revise
• Report
Evaluation is not just a look back through the history books. It is not just a look back in time.
We are examining data, we are looking for clues. There is a reason for having that
microscope here. That microscope represents the research that is really going on here. It is

EVALUATION AND FORECASTING
7 Exercise
not a matter of a read-through of the information garnered to date. It is a careful examination

of what has been done. We want to go back and update and revise our project plans to
accommodate what really happened. We want them to reflect the realities, not just what we
had originally planned. And we want to report that out to the organization. We want to
communicate it out to the team.
In many cases, the team does not know if they are on schedule, behind schedule, or ahead.
They only know about their individual tasks. They need to have a sense of the whole project,
of the whole vision of where things have gone and where they are going.
Make some notes to yourself about what goals you have out of an evaluation—what you
really wanted to accomplish. What are those goals, what are the missions of your
evaluations, and how do you normally accomplish those? What are some of the tricks of the
trade, if you will, that you use to let people know how you have gotten as far as you have?
What are some of the ways that you do your own personal evaluations, and what are you
trying to achieve by them?
EXERCISE
................................................................
Take that information and document it in the format that is outlined here. Make a list of your
goals for the evaluations and a list of your methods for doing the evaluations. If you are
MONITORING PROJECTS
................................................................
I once had a student who was vehement with me about this particular section,
argumentative to the point of saying that project managers should never monitor. I asked
why. He stressed that project managers need to do so much more than monitor, and
monitor is such a passive term. He was very upset about the whole thing.
I pointed out that unless you are monitoring your project, you do not know what to take
action on. It is a small, incremental process. It is like looking at the ties in a railroad track. As
you look down the road, you are not looking very far. You can only keep track of a few ties
down the track. You cannot look down too far, or else you start blending them all together.

.....
Evaluating Projects
You cannot really see that far down the road. This is micro-level activity. And each act of
monitoring is relatively cheap. It is the little stuff we do on a day-to-day basis: How are you
doing? How is your task doing? How is your project doing? How are your activities going?
We check them in small, small increments.
Monitoring is not an expensive proposition, but it is important to do. A project manager who
is acting in the best interests of his or her project will be doing monitoring on an ongoing
basis, day to day, hour to hour.
EVALUATING PROJECTS
................................................................
• Done to a specific point in time (“data date”)
• Planned vs. actual
• Critical items
• Broad scale
• Task groups, cost centers, system, function, phase
It is important that you understand here that evaluating projects is done to a specific point in
time. (See Tool 8 in the Appendix) It is a broad-based, more expensive proposition than
monitoring. Doing evaluations is going to cost you some time, and it is going to cost you
some money.
And it is done to a specific point in time. That point in time is a reference that will show up if
you have not yet taken the PMP® certification exam. That point in time is called the data
date. That’s right—a data date. And data dates are terms that will show up in the PMI®
exam. They are the point in time to which we are doing a specific evaluation or review. We
do the evaluations to a specific data date because we have to stop tracking at some point
and add up or aggregate all the information. You cannot keep aggregating that information
on an ongoing basis because it continues to flow into the project.
There are ways of looking at evaluations. Some people look at them strictly from a schedule
perspective. That may be their emphasis. Some people look at cost issues. Some people
look at personnel and management issues. Evaluations should cover the gamut. They
should ensure that we are taking care of costs, schedule, and scope. All three sides of the
triple constraint will be considered in a good, quality evaluation.

7 Conduct Trend Analysis
CONDUCT TREND ANALYSIS

................................................................
Are any of these warning signs present?
• Project finish date gets later and later
• Costs increase faster than planned for work accomplished
• Quality deteriorates
• Schedule-oriented problems and arguments increase
• Negative float increases
If you do not look into the cup, you cannot read the tea leaves. It is important to keep an eye
on what is going on in your project. You need to be keeping track of what is going on. You
need to be conducting analyses of what trends are actually occurring. What are some of the
signs that go on that need to generate a blip, as it were, on the radar screen of project
management? What are some of the occurrences that may drive you that way?
Look at the signs that are there on this section. Is your schedule continually getting later and
later? Are costs escalating? Or are costs continually being underrun? Trends either way
need to be evaluated for what they mean to the core of the project. Trends can be good.
Trends can be bad. Neither way can they be ignored. You need to be keeping an eye on
what is going on.
We need to make sure we are keeping track of these things because, frankly, they are the
things that are going to make a difference in the outcome of our project. If we identify the
trends, they often point to future problems as well as existing traits.
PROJECT AUDIT
................................................................
• Status
• Forecasts
• Assessments
• Tracking
• Communication
• Recommendations
Audit is a word that can strike fear in the heart of any project manager or just about
anybody, for that matter. Audits can be a very frightening thing. They mean a thorough—

.....
Project Audit
very thorough—comprehensive review of where things have gone and where they are
headed in the long term. That is what an audit is all about. It is a chance to clean house, as
it were—to ensure that we know what all the problems are and how they are being resolved,
knowing what has gone wrong and what has gone right in a project.
140
120
100 Planned Work/Cost
80 Work Complete/Planned
Cost
60
Actual Cost
40
20
0
j f m a m j
When we do an audit, invariably we are looking at all the critical areas of the project. We are
looking at the status of the project. What is the current state of the project? Activities
complete, customer satisfaction, budget expended? We are looking at the forecast—the
predictions we can make from the information we have up to this point.
Look at the chart that is here. When you can follow those lines, you might be able to start
making some guesses from the information derived thus far in the project. Predictions are
going to be made based on an assessment of performance to date and anticipated
performance. We need to look at the realities of what has happened versus what was
anticipated, and what drove us to any changes. We need to be able to track well if we are
going to build any future assumptions.

7 Why Consider Earned Value (EV)?
We also want to make sure that we are communicating this information out across the
organization. An audit is only valuable if the information is being used to improve
performance in the long run. We need to make some recommendations. In the Appendix
section you have an audit outline that can be used to expand on these concepts. Make sure
you use it.
WHY CONSIDER EARNED VALUE (EV)?

................................................................
Because it—
• Allows for objective assessment of variance
• Allows for common understanding
• Is incorporated in all the major modern project management software packages
• Is consistent from project manager to project manager
I guess I could argue the flip question, which is, why not? But the real answer to this
question is, because earned value has value. There is a lot of merit in using this auditing
process and this tracking process to keep track of all your project information. Believe me, I
have heard all the arguments against earned value. I have heard people say it is too
onerous, there is too much tracking, we do not have that information. To the contrary, you
actually have most of the information you need to do earned value, even if you are living
with just the barest bones of the information that is available. If you just have resource-hours
in your project and know how many people are there for how long each day, you have
enough information to do some fundamental earned value.
ONE TYPE OF DETAILED AUDIT

................................................................
• How much is the work scheduled to be done worth?
• How much is the work we have done worth?
• How much did we pay to get it done?
That is all earned value is. It is just one kind of detailed audit. And without the right pieces of
information, you cannot audit a project.
What we are going to do now is be the Acme Picket Fence Company. That’s right—you are
making picket fences for a living, just for the sake of this particular project. “Shielding homes

.....
One Type of Detailed Audit
for a tenth of a century.” These fences do not come cheap. They are made of mahogany,
and they are made to last. Each one is sanded on site, by hand, and each picket in the
fence is handplaced. We can sand, prepare, and place about three pickets in a day, and
they are consistent in price. It is the end of the second day. Now think about that for a
moment—it is the end of the second day. We can sand and place and prepare about three
pickets a day. How much work is scheduled to be done? I would like you to write this down.
Two days’ worth. Two days’ worth is how many pickets, at three pickets a day? That’s
right—it is six pickets. And as you can see by the section, each picket has a value of $100.
So two days’ worth of work is $600. That is what is scheduled to be done.
Now we look across our group, and we find our official picket person (we will call him Bob),
and Bob tells us that he has completed four pickets. My question to you is, how much value
has Bob earned? How much value has he earned at $100 a picket? He has put up four
pickets. He has earned $400 worth of value. He has performed $400 worth of work. He was
scheduled to do $600 worth of work. He has performed $400 worth of work.
Well, that raises the question, is Bob ahead of or behind schedule? He is supposed to have
done $600 worth of work (six pickets), and he has done four pickets ($400 worth of work).
He is behind schedule. By how much? Two pickets, or $200.
Now, let’s ask the big question that they always ask in our organization: how much did this
cost? How much did this really cost our organization? Well, we go to the accounting division
to try to find that out. How much? And there it comes: $500. It cost Bob $500 to do the work.

7 Key Earned Value Data
Now, is he ahead of budget or behind budget? He is scheduled to have done $600 worth of
work. He has done $400 worth of work and has put in for $500 worth of pay. Hmm—$500
worth of pay versus $400 for what it was supposed to cost to get that much work done. Well,
he is over budget. He is over budget by $100. That’s right—he is over budget by $100. So
he is behind schedule by $200 and over budget by $100.
Those are the fundamental pieces of earned value. Each one of those pieces has a name.
The work that was scheduled to be done—six pickets in two days—that is the budgeted cost
of work scheduled. The budgeted cost for the work that was scheduled in two days was
$600. The budgeted cost of work scheduled—the acronym for that is BCWS—the budgeted
cost for the work that was scheduled to be done. That is how much, according to the
calendar, we were supposed to have done as of this point in time. How much work Bob has
done is the BCWP—how much work he has performed. The budgeted cost of work
performed—or, if you prefer, Bob’s cost of work performed—is $400.
The actual cost for what Bob did (we went to accounting to get that information) was $500.
And we have a cost variance. The cost variance on that—remember? He was budgeted to
do $400 worth of work for what he got accomplished, but it actually cost us $500. His cost
variance was $100 to the negative. We took the budget that was allotted for Bob to do four
pickets and the actuals for what he actually did (four pickets). That $400 that was budgeted
less the $500 in actuals is minus $100. We have a negative cost variance. That negative
cost variance is minus $100. Negative numbers in earned value are bad news.
We also have a schedule variance of minus $200. The budgeted cost of work scheduled
taken from the budgeted cost of the work performed gives us minus $200. That is our
schedule variance, or SV.
KEY EARNED VALUE DATA

................................................................
• Planned cost for planned work: BCWS (budgeted cost of work scheduled)
• Planned cost for work accomplished: BCWP (budgeted cost of work performed)
• Actual cost for work accomplished: ACWP (actual cost of work performed)
• Total baseline budget without reserves: BAC (budget at completion)
• Total baseline budget with reserves: CTC (cost to complete)
The information provided here is essentially everything we just talked about. This is just the
translation, if you will, from earned value to English. The planned cost for planned work.

.....
Key Earned Value Data
How many pickets had we planned to have completed as of today? How many pieces of that
fence? We had planned to have six pickets at $100 a picket. We had planned to have $600
worth of work done as of today. That is the budgeted cost of work scheduled—the BCWS.
That translates out to be what we had planned to have accomplished at any given point in
time—or as we discussed earlier, what we had planned to have accomplished as of the data
date. You remember, the data date—the point at which we are setting the evaluation.
Let’s go down to the next bullet. The planned cost for work accomplished. The budgeted
cost of work performed—BCWP. How much had we budgeted for the work that is actually
done? If you will remember, Bob only got four pickets done. At $100 per picket, he only got
$400 worth of work done. That is the budgeted cost for the work that was performed—$400.
The planned cost for the work that was actually done.
The next piece of it is one where people say, “Wait a minute. I do not know where you got
that piece of information.” The actual cost of work accomplished—the ACWP, the actual
cost of work performed. This means, what money was actually spent to get the work that
has been done? How much did we actually spend? We normally go to accounting for this
information, or we look at people’s hours and multiply it against their hourly rate.
For the entire fence—let’s suppose for a moment that you were working with a 20-picket
fence. Twenty pickets at $100 a picket would be $2,000. That’s right—$2,000. It is the total
budget without any reserves, without any money set aside as the just-in-case fund or to deal
with problems as they arise and to account for those problems.
When we add in the total baseline budget with the reserves, then we have our cost to
complete. How much is it going to cost to get this whole project done? How much is it going
to cost to get the whole project done? That is the cost to complete. That is how much the
entire project will cost, including any reserve funds that need to be set aside.
Those are the key components of earned value data. If you can get the first four bullet
items—the budgeted cost of work scheduled, the budgeted cost of work performed, the
actual cost of work performed, and know the budget at completion—you have enough
information to do a comprehensive, exhaustive audit on your project.

7 Integrated Cost/Schedule Status
INTEGRATED COST/SCHEDULE STATUS

................................................................
As you look at this particular diagram, you are probably wondering, “I seem to be missing
some pieces of information on the first few tasks.” Notice you have only been given the
budgeted cost of the work scheduled and the actual cost of the work performed. You have
only been given those two pieces of information for the first three tasks. You actually have
the budgeted cost of work performed there. You should be able to figure out what it is.
Let’s look at the first one. The budgeted cost of the work scheduled was $4,525, and that
task is complete. How much work has been performed? How much had we budgeted for
that task? That’s right. Because it is complete and past its scheduled completion date, the
budgeted cost of work scheduled and the budgeted cost of work performed are now the
same.

.....
Integrated Cost/Schedule Status
Look at the next task. It has a budgeted cost of work scheduled of just over $6,000. It has an
actual cost of work performed of $7,000. How much was budgeted for that task? Take a
moment to think that question through. For the second activity, how much was budgeted for
the task? There was a budget exactly the same as what is there for the BCWS. The
budgeted cost of work scheduled and the budgeted cost of work performed at the end of an
activity, after its scheduled completion date, will be the same.
Look down at the next one. The budgeted cost of work scheduled was $4,450. So the
budgeted cost of the work that has been performed on that activity is? That’s right—the
same—$4,450.
Now we get down to some of the more confusing tasks. Look at the task Target Group A.
We have a budgeted cost of work scheduled of just over $6,000. We have a budgeted cost
of work performed that is less than that. Now, if we subtract the BCWS (budgeted cost of the
work scheduled) from the budgeted cost of the work performed (BCWP), we have bad
news. That’s right—we have performed less work than is scheduled to be done. We have
performed about $4,500 of work, and we were scheduled to have done about $6,000 of
work. We are late!
Now, look at the amount we spent to get this far. We were supposed to have spent just over
$4,500, and we have spent just over $4,500. So, while we are late, we are not over budget.
On Target Group B, the picture is pretty much the same.
Look at the next activity. It has a budgeted cost of work scheduled as of the data date of
$1,112. The budgeted cost of the work performed to date, you should be able to figure out
on your own. What is the BCWP for that activity? It is zero. No work has been performed.
The bar has not been filled in at all. That is how you start working the budgeted cost of work
scheduled and the budgeted cost of work performed together.

7 Schedule Variance (SV)
SCHEDULE VARIANCE (SV)

................................................................
SV = BCWP – BCWS
= 26,365 – 30,587
= –4,222
where—
BCWP = 26,365
BCWS = 30,587
Schedule variance is the difference between what we have actually gotten done and what
we had planned to have done. Sounds pretty simple, doesn’t it? The only difference is that
in earned value it is expressed in monetary values. In this example, let’s use British pounds
rather than dollars. The budgeted cost of the work performed—the amount that had been
set aside for the work we have actually gotten done—was just over £26,000. We subtract
out how much work was scheduled to have been done as of today. In this instance, it is over
£30,000. The difference between the two—between what we had planned to have done and
what we actually got done—is minus £4,222. That means we have a schedule variance of
negative £4,222. It is negative. In earned value, as I said before, that is bad news.
A negative schedule variance, being bad news, means we are late; we are very late. We
have a problem. Well, are we very late or just a little late? That is a matter of the relative
value of the schedule variance. In this case, we are scheduled to have £30,000 worth of
work done. Instead, we are £4,000 behind schedule—4,000 versus 30,000. That is a pretty
significant percentage. It is more than 10%. So we are pretty far behind schedule, and we
need to take some remedial action. That is what schedule variance tells us—where are we
in terms of the whole project, or in relative terms when looking at the whole project?

.....
Cost Variance (CV)
COST VARIANCE (CV)

................................................................
CV = BCWP – ACWP
= 26,365 – 27,465
= –1,110
where—
BCWP = 26,365
ACWP = 27,465
This is obviously the same project, but now we are looking at a different parameter. We are
no longer looking at the schedule criteria; we are looking at the costs. How are we doing in
terms of cost? When we look at costs, we ask a fundamental question: how much is the
work we have done to date worth, and how much did we spend to get it done? Those are
the fundamental questions we ask when we look at cost variance.
Once again, the first part of that parameter is the amount of money that was set aside for the
work that we have done—the budgeted cost of the work performed. In this case, we have
done £26,000 worth of work, and it cost us just over £27,000 to get it done. That means we
overspent by £1,100 in this instance—£26,365 minus £27,465 gives us £1,100 difference. It
is a negative number. That negative number—remember, in earned value, negatives are…?
That’s right—it is bad news. Negative numbers are bad news in earned value. So this
negative number means we have overrun our budget by £1,100.
COST PERFORMANCE INDEX (CPI)

................................................................
CPI = BCWP / ACWP
= 26,365 / 27,465
= 0.959
where—
BCWP = 26,365
ACWP = 27,465

7 Exercise
This, frankly, to me, is the most valuable chunk out of the earned value lesson. This, to me,
is the one thing that made me understand the real value of earned value. So watch this one
closely.
The cost performance index is that indicator that gives us a sense of, how far away are we
from where we are supposed to be? How close are we to what we are supposed to be
achieving? In this instance, we have a CPI, which is the BCWP over the ACWP—96% is our
cost performance index. £26,365 over £27,465—96%.
That means for every dollar we invest, we get 96 cents back on the dollar. Is that
acceptable? In some organizations, that is a major achievement. In other organizations, that
would be a major disaster. It all depends on your perspective of how well projects are
supposed to go. How close are they supposed to be to your budget?
In a major multibillion-dollar effort, this could represent thousands, even hundreds of

thousands or millions, of dollars. Or in a much smaller effort, it could represent several
hundred dollars. Either way, it is the same relative value as to, how close are we to 100%
cost performance? In this case, we are just under 96%. Ask yourself, “Would my
organization be willing to live with that?”
EXERCISE
................................................................
What I would like you to do is submit your answer to the above question. What percentage
of cost performance do you think your organization would tolerate, and why do you think
that? What drove you to those conclusions? By answering that question, you are not only
providing yourself with information, you are also getting a sense of how tolerant your
organization is of variance. Organizations need to have some tolerance for variance, but the
question is, how far will they let it go? Different organizations, even different divisions within
the same organization, will have radically different perspectives. If you are using this book
and working towards PDU’s, please submit your assignment as directed.

.....
Latest Revised Estimate or Estimate at Completion (EAC)
LATEST REVISED ESTIMATE OR

ESTIMATE AT COMPLETION (EAC)
................................................................
EAC = BAC / CPI
= 46,475 / 0.9599
= 48,416.50
where—
BAC = 46,475
CPI = 0.9599
You may recall that earlier I told you one of the pieces that you would need to have to truly
do earned value well and to take full advantage of it would be the BAC, or the budget at
completion. This is where that comes into play.
You use the budget at completion to help establish what the entire project is going to cost
based on current performance. Not how much did we set aside for it to cost, but based on
current performance, how much is it going to cost? Specifically, what we are looking at here
is, what is our latest revised estimate for the completion of this project? In this instance, we
have the budget at completion of £46,475, and we divide that by the cost performance
index. We divide it by that 96%. In this case, it gives us just over £48,400. That means the
final budget is going to be overrun by about £2,000. That is an important figure. It is one that
management is often looking for.
I would like you to take a moment and go back, if you will (or think about, if you will) the
example with the picket fence. Our budget at completion, you may recall, was going to be
$2,000. That was our budget at completion. We have completed how many? How many of
those pickets did Bob actually complete? Well, he had completed four of them. He had
completed four of them. He was supposed to have completed—the budgeted cost of work
scheduled was six, and his performance was five pickets. So to get this figure, we first need
to get the CPI, which is the budgeted cost of work performed ($400) divided by the actual
cost of work performed ($500). In Bob’s case, that works out to be—4 divided by 5 is 0.8.
That 0.8 becomes our CPI. We are getting 80% cost performance.
That 80% cost performance now becomes a key figure in calculating our estimate at
completion. The total project was to have cost $2,000. We now divide that $2,000 by that
0.8. That will give you the estimate at completion. And what are you going to find? You are
going to find that it is significantly higher than $2,000. And that little bit of information goes a

7 Variance at Completion (VAC)
long way toward answering the question that management often comes to us on.
Management comes to us and asks us, “How much is this thing going to cost?”
VARIANCE AT COMPLETION (VAC)

................................................................
VAC = BAC – EAC
= 46,475 – 48,417
= –1,942
where—
BAC = 46,475
EAC = 48,417
This is another one of those big management questions, the ones that your managers come
to you and ask. “How far off is this thing going to be? How close are we going to be to where
we were supposed to be when the project is all over?” It is the key answer that is often
sought in an audit. It is a key answer that can be provided using earned value.
The variance at completion is actually a very simple formula. What is our budget at
completion? How much did we think the whole project was going to cost? In the example
given here, it was £46,475. That is how much was budgeted. Our current estimate at
completion is £48,417. That is how much it is going to cost. It is a higher number than the
budget, which means that the answer, the VAC (variance at completion), is minus £1,942. It
is a negative number, and this is earned value. What does that mean? I am afraid you are
right. It means it is bad news. It means it is negative. It is going to be bad news. The
variance at completion, anytime it is a minus number, means we have some corrective
action that will need to be taken to get us back on track.

.....
Estimate to Complete (ETC)
ESTIMATE TO COMPLETE (ETC)

................................................................
ETC = EAC – ACWP
= 48,417 – 27,465
= 20,952
where—
EAC = 48,417
ACWP = 27,465
The estimate to complete is different from the EAC. The EAC is how much the whole project
will cost, in total, when it is done. ETC is asking the question, how much more do we have to
spend to finish this particular project?
In the example provided on this section, it is £48,417 minus £27,465. That leaves us with an
ETC of £20,952. That answers that fundamental question of, how much more will this
project cost to get it to fruition? That piece of information is crucial, because in many cases
the budget or the allocation simply will not be there to complete the project. In an audit, this
question is often vital to the success or failure of the effort.
PERCENT COMPLETE
................................................................
% Complete = BCWP / BAC
= 26,365 / 46,475
= 0.5673
where—
BCWP = 26,365
BAC = 46,475
One of the questions we will often ask our team members and a question that often comes
back to haunt us is, how far along is this project? How much work has actually been done?
In earned value, this gives us a project-wide view of that question. What is the percentage of
the project that has actually been completed? What is the percent complete? To do that, we
look at the amount of work we have performed and how that stacks up against the entire
project. The budgeted cost of work performed divided by the total budget. In this case, it is
£26,365 divided by £46,475. That leaves us with a percent complete of 56.7%. We are 56%

7 To-Complete Performance Index (TCPI)
of the way done in terms of the budget for the work that was set aside and the total budget
of the project. That assumes that those values, those monetary values, are the same from
task to task and from element of the project to element of the project.
Percent Spent
% Spent = ACWP / BAC
= 27,465 / 46,475
= 0.5910
where—
ACWP = 27,465
BAC = 46,475
Yet one more way to turn the earned value numbers around. In this case, we are answering
that age-old question of, how much of the money have we actually spent? What is the actual
cost of the work that we have done so far, and how does that compare to the total budget for
the project? In this instance, we have actually incurred £27,465 against the work that has
been done. We have allocated for the whole project £46,475. That means that the percent
of the money that has been spent is 59%.
A moment ago, we realized that we were 56% complete. Now we realize that we have spent
59% of our money. We know where this is going—no place but trouble. 56% complete, 59%
spent—it means we are overspending, and we need to take some corrective action. And
now we know how much we have to make up.
TO-COMPLETE PERFORMANCE INDEX (TCPI)

................................................................
TCPI = Work remaining / money remaining
= (BAC – BCWP) / (BAC – ACWP)
= (46,475 – 26,365) / (46,475 – 27,465)
= 20,110 / 19,010
= 1.058
where—
BAC = 46,475
BCWP = 26,365
ACWP = 27,465

.....
Schedule Performance Index (SPI)
The TCPI is one of those great values in earned value that tells you something important
from a management perspective. It is also a number that is hard to come by in conventional
evaluations. That is what makes earned value so valuable. Specifically, the TCPI looks at
the work remaining and compares it against the amount of money that is remaining.
In this instance we take the budget at completion, and we subtract out the budgeted cost of
the work that has been performed to date. That leaves us with the budgeted cost of the work
that remains. In this instance, it happens to be £20,110. Then we look at the amount of
money remaining. We take the budget at completion and subtract out the actuals—the
actual spending to date. In this instance, it is £19,010. 20,000 over 19,000 gives us a TCPI
(a to-complete performance index) of just about 106%. That means that for the rest of this
project, to bring it back up to a perfect budget figure at the end, to restore our original
budget, we must get 106% performance out of everybody working on this effort.
Is that realistic? In some organizations it may very well be. In others, that may be a dream, a
fantasy. It might not be possible. But we get a sense of just how much of an improvement
there is going to have to be in the project to turn it around and make that change. We were
getting 96% performance. Can we turn that around to 106%? That is questionable. And it is
going to take some serious management action.
SCHEDULE PERFORMANCE INDEX (SPI)

................................................................
SPI = BCWP / BCWS
= 26,635 / 30,587
= 0.86
where—
BCWP = 26,635
BCWS = 30,587
This is, from some individuals’ perspectives, one of the lesser used and less valued
components of earned value. But it does show up on the PMI® exam, so we thought it was
important to make sure that you are at least aware that it exists.

7 Earned Value Schedule Conversion
The SPI is the schedule performance index. It is out there. It is a number that you may be
able to use. But be forewarned: schedule performance indexes will always, at the end of a
project that is past its scheduled completion date, ultimately drive to one. Someday that
project schedule performance index will be 100%. It is transitory. It changes over time,
because the budgeted cost of work scheduled and the budgeted cost of work performed
ultimately, at some point in time, will equal one. They will be exactly the same. They will
achieve parity.
Take a look at the formula provided here. The budgeted cost of work performed—£26,365.
We divide that by the budgeted cost of work scheduled of £30,000-plus. That gives us a
schedule performance index of 86%. In other words, we are getting 86% toward the
schedule. We are not doing very well, frankly, in getting to the scheduling. These numbers
are driven by the budgets. How much had we set aside to do this work? This has nothing to
do with the monetary values incurred to date.
EARNED VALUE SCHEDULE CONVERSION

................................................................
Projected completion = [(BAC / SPI) – BAC] / Average time period BCWS
= [(46,475 / 0.86) – 46,475] / (30,587 / 20)
= [53,915.31 – 46,475] / 1,529.35
= 7,440.31 / 1,529.35
= 4.87 (days behind)
where—
BAC = 46,475
SPI = 0.86
BCWS = 30,587 (over 20 workdays)
Well, friends, this is about as scary as earned value can get. This is converting those
numbers from the schedule performance index and all the other figures you have had to
date, converting them into a meaningful amount of information about the schedule. We will
talk about just how meaningful that is in a moment.
Specifically, what you want to take is your budget at completion and divide it by your
schedule performance index. In this case, that is £46,475 divided by 0.86. That gives us a
figure of £53,915. We subtract from that the budget at completion. The budget at completion
is £46,475. And then we come up with a rather bizarre number. We have the average time

.....
Earned Value Schedule Conversion
period of budgeted cost of work scheduled. In other words, across the number of time
periods that are being evaluated here, what is the average time period’s budgeted cost of
work scheduled? To do that, we take the budgeted cost of work scheduled for the project
and for the work done to date, and we divide that by the number of time periods involved.
We divide by the number of time periods involved. In this case, that works out to be £1,529.
So 7,440 divided by 1,529 gives us 4.87. That is 4.87 days behind.
Now, does that mean that the project is actually 4.87 days late? No. What it means is that
we are that far behind in terms of the earned value of the project. That becomes important
because that 4.87 days may not be on the critical path. It may be on a period where we have
an extensive amount of slack. It may not be a problem at all in terms of the overall schedule
of the project. What it means is, as a percentage of the entire project duration, we are 4.87
effort-days, if you will, behind. That is how far behind we are, based on earned value. It does
not calculate in the critical path. The actual picture may be much worse or much better. It is
very hard to tell with earned value data.
While earned value provides a comprehensive audit on virtually all cost aspects, this is the
one piece that it does not do remarkably well. But there seems to be a formula for
everything, and this is the one for the earned value schedule conversion. Once again, it is
one of those that you really ought to know if you want to understand the breadth of what
earned value is capable of.
Keep in mind that all these tools are available in the various software packages. Most of
them will do these calculations for you. What this is for is so that you will understand what is
going into the calculations, what is driving them, and how you can use them for good
management practice. In this instance, if somebody wants a sense of the relative delays you
are experiencing in the entire project and really is not that concerned with the schedule, this
is a good, honest number to present. And that is what it is all about—good, honest project
reporting.

7 Project Evaluation and Forecast: EV
PROJECT EVALUATION AND FORECAST: EV

................................................................
As you look at this chart, it is the culmination of everything we have talked about up to this
point. For some upper managers, this is a dream chart. It is everything they could ever wish
to see about a project. What are the actuals, and where are those actuals headed? What
will the estimate at completion be? Look at the budgeted cost of work scheduled—where is
it headed? How much are we scheduled to spend at any given point in time on the project,
and what is our budget at completion? How about performance? How are we doing on
performance? How have we done historically, and where ultimately is it going to lead us?
What is our cost variance? What is our schedule variance? What is our estimate to get this
thing finished? How much money do we have left? What is the reserve that we have set
aside to get this work accomplished? All these questions are answered in this one
fundamental graph.

.....
The 50-50 Rule
If you understand all the gaps that exist in this graph and the differences in what they mean,
then you understand the basics of earned value. If you are still wrestling with it make sure
you clarify those before you move forward, because these are all the pieces of earned
value, with the exception of the indexes—the cost performance index, the schedule
performance index, and the to-complete performance index. But if you understand these,
you understand the fundamentals.
THE 50-50 RULE

................................................................
The 50-50 rule is actually a wonderful rule for keeping track of how far along a task is. It is
wonderful because we often do not really know the answer to that age-old question of, how
far along are you in a given task? Since we do not have an answer to that question, the 50-
50 rule gives it to us.
Under the 50-50 rule, any task that is under way is 50% complete. Any task that is at any
point under way is 50% complete. Just started? It is 50% complete. Almost done? It is 50%
complete. Under the 50-50 rule, that is the way it falls out. Any task that has begun is 50%
complete. There is no other percent complete available to you. Work is either 0, 50 or 100%
complete, there is no other option.
Percent Complete? 50 Percent Complete? 50
The reason for that is because, you know as well as I do, sometimes you go to people and
ask them, “How far along are you on a task?” “I am 99.999% of the way there.” That last
one-thousandth of a percent is going to take them just as long as the first 99% did. It is
amazing how people mismanage their estimates of how far along they are in a given task.
So the 50-50 rule operates under the assumption that any task, no matter how grand or how
small, is consistently 50% done the moment it is started.

7 Analyze Variance
The earned value 50-50 rule works well when there are a lot of activities that are occurring
in parallel, because some activities are close to done, some activities are just getting
started. It provides a balance on how earned value is reported; it provides a balanced sense
of where we are in the project. Traditionally, the 50-50 rule makes the project managers look
a little worse then they truly are in terms of performance. That is not inherently a bad thing,
as long as you understand that is what the rule is going to do. Because normally we tend to
estimate that we are further along in tasks than 50%. Very rarely will you hear someone give
an estimate of project or task completion that is under 50%.
There are some other rules that are available, too, similar to the 50-50 rule. The 20-80 rule:
any task that is open is 20% complete; when it is completed, you get the remaining 80%.
And then there is the 0-100 rule, which is the most conservative: any time a task is open,
you get no credit for it until it is 100% complete under earned value reporting.
The advantage to using these rules is that they provide a modicum of consistency. There is
going to be similar reporting from task to task. And that makes the project a little more
balanced in terms of how you are reporting from Day 1 and how you are reporting from Day
100 based on different reporters giving you that information. Different team members have
different perspectives on how far along given tasks may be. This creates some balance
among those reports.
ANALYZE VARIANCE
................................................................
• Estimating errors
• Technical problems
• Design
• Software
• Test
• Management problems
• Personnel skills
• Labor availability
• Organization
• Economics
• Acts of nature
• Market fluctuations
• Subcontractors and vendors
• Lead times

.....
Replan and Reforecast
We are always asked why. Why did the project become more expensive? Why is it running
a couple of days late? We need to have that information at our disposal. The way we get
that information, the way we answer that why question, is by doing this step in the process.
We analyze the variance. Where did the variance come from? We look and try to figure out
what could have driven the variance.
In many cases, it is basic project management practice. Did we have a good estimate to
begin with? Where did the estimate come from? Was it given to us by careful development,
or was it developed by someone who really did not understand the questions at hand? That
is an important issue, because many times we are working to other people’s estimates. And
in those instances, we sometimes are driven to bad projects by virtue of the fact that it was
a bad estimate on Day 1. We need to establish that as we analyze the variance.
It can be other factors as well. Sometimes the design was too expensive, too elegant, too
simple. Sometimes it is management problems—resources do not work as well as
anticipated; one person keeps coming in late. What about economics? Sometimes there is
an up-tick in the price. Prices do go up. Acts of God can drive us to changes, can drive us to
variance. A tornado, for example, might change the tenor of a project completely. What
about market fluctuations? Is the demand there? Has the demand completely vanished?
Subcontractors—blaming it on others is a popular practice in project management.
Each one of those has a different level of management required by you, the project
manager. We need to analyze variance so that we know what we should be doing. And
these are not the little acts of what we should be doing. Because this is an evaluation, these
are the larger acts that may require a significant change in our management style. We may
need to look at these and realize that our management style is not appropriate, or the
current management style we are deploying is not appropriate, for that component of the
project. We need to spend time analyzing variance so that we know what we are doing as
managers and can act appropriately. We need to find the root cause.
REPLAN AND REFORECAST

................................................................
There is a basic concept of replanning that we must sometimes deal with—we must go back
and reassess how we are doing the project based on what has happened to date. It is why
we conduct evaluations: to know what we should be doing managerially.

7 Status Reporting
One of my colleagues gets very excited about this. He says, “Every chart, every graph tells
a story!” Try and discern the story from this Gantt chart. It is a decent story. The project
manager has set the plan to begin on January 1—and it got pushed back a few days. The
project manager saw the schedule on the first activity pushed out a bit—but salvaged it by
January 15. But the second activity then expanded in scope and crept ever onward,
progress slowly moving forward, slowly and steadily.
What would you do each time a significant change was implemented? How would you
handle it? How would you communicate it across the organization? There is now a heavy
emphasis in project management on integration—ensuring that our projects are integrated
across the organization and that the rest of the organization knows when our projects are
facing some serious concerns.
When updating the baselines, the important thing is communication. We must ensure that,
as we change things, those changes are approved by the customer if they will result in a
new baseline. And we must ensure that they are approved internally if they will result a new
baseline. If we are simply replanning and reforecasting, then we must ensure that our team
knows exactly what is going on—they must know what changes have been made to the
project to get us to its successful conclusion.
STATUS REPORTING
................................................................
• Reports
• Meetings
Reports and meetings—two terms that stir fear in the heart of any project manager.
Something we have all come to know and love—the paperwork, the meetings. Whenever I
discuss this section in a class, I can always hear the collective groan out of the room. And
the reason is that we have all suffered through too much reporting and too many meetings.
However, there are ways to make meetings effective. And let me just stress here that if you
are going to make meetings and reports effective, keep them to the level of control that you
really need. Do not have people overreport, and do not make the meetings any longer than
necessary to address the issues at hand.
Look at how we communicate management information: meetings, reports, management by

walking around, one on one, e-mails, voicemails, mail, notes, letters, Websites, Lotus

.....
Status Reporting
Notes. Some management information systems are more effective than others, and the
degree of effectiveness will depend on you and your organization.
How do you communicate when a project has a major problem? Do you go up to your
management? Do you go over to the functional managers? Do you go to the project team?
What about your team members and the communication they need? How do you make sure
they clearly understand what everyone else in the project is doing?
I talked to one project manager who emphasized that she always builds a project
newsletter. She keeps it cute, incorporating a lot of cartoons, but she always sends it out
regularly to ensure that the project team members are aware. She has a team of about 28
people, and you need a newsletter with that size group. For a team of two or three, a
newsletter might look silly.
Our goal is to ensure that we communicate our management information across the team.
The two most conventional methodologies are regular reports and staff meetings. But if you
do not like these approaches, look for ways to break out of the conventions. If they do not
work for you, try other ways. And if those new ways do not work for you, consider more
alternatives. For example, do not make your meetings the same each and every time. Hold
them in different locations and have different activities to ensure that all the information is
communicated in new and innovative ways.
Here you have an earned value report, which is very valuable. (See Tool 12 in Appendix)
Although this tool is very effective in communicating the information, frankly, it could have
just as readily been printed out of any of the major project management software packages.
You do not need to generate a separate type of report.

7 Status Reporting

THE E XIT S TRATEGY
...................................
8
.....
OBJECTIVES

• Determine when a project is complete
• Appraise the project plan in the context of project completion
• Provide concrete measurements of project success at completion
Take a look at these bullets. You may have to laugh at some of them. At the end of this
chapter, you will be able to determine when a project is complete. “Ah, Brent, I think I
already know that.” Well, in many cases, you may not realize it, but you might not. You
might not really know when your project is truly done. Often, we prematurely declare a
project complete only to have to come back and do repair work later on. And the other side
is true as well. Sometimes we will continue to work on a project long after it is formally
completed, and that is not necessarily appropriate either.
We will also be able to do reviews of the project plan at the end of our projects—that is
something else I want you to be able to do at the end of this chapter. And we will also have
some concrete measurements of, how did we succeed? Not just what was done, but how
did we succeed in the project?
PROJECT CLOSEOUT
................................................................
• Scope verification
• Contract closeout
• Administrative closure
• Identified and planned for during project requirements document development
Take a look at these four bullets. What we are trying to achieve at closeout is more than just
making sure the project is done. To get the project closed out properly we have to ensure

THE EXIT STRATEGY
8 Exit Strategy Process
that, first, the scope is indeed verified—that we finished what we said we would finish. The
second component is to make sure that we have finished what we are contractually
obligated to do (and we will talk about that in greater depth momentarily). Also, this third
bullet: administrative closure. That is something we need to be dealing with as we close out
the project, in depth. That means covering all the paperwork, making sure all the
documentation is in place so that this project does not come back to haunt us time and time
again.
This is something that is identified and planned for during the project. We need to set this
out at the very beginning of our projects so that when we get down to the end, we can
successfully close them out. Let me emphasize this. If you have not participated in
developing the project requirements, that does not mean that you cannot close out
successfully. What it does mean, however: if you did not participate in originally developing
the project requirements, you need to do so at mid project. You need to sit down with the
customer and review precisely what is going to be required to close out the project. If this
information is not in hand during the project, it will not suddenly appear or miraculously
occur at the end of the project. You need to have this information in advance of the last days
of the project.
EXIT STRATEGY PROCESS

................................................................
Fulfill Contract Conduct Final Organize

Obligations WBS Review Files
Finalize Celebrate
Admin
Customer Successful
Closeout
Relationship Project
As you walk through the individual steps or components of this process, we are going to be
recognizing just how much work has to be done in advance of closeout to ensure the
closeout goes well. It is surprising how many people anticipate that at the end of the project,
the customer will simply shake hands and say goodbye. It does not work that way unless
you have planned for it to work that way. You need to have the exit strategy, or you are
never going to get out of the project. This leads to the syndrome that occurs in many

.....
THE EXIT STRATEGY
Fulfill Contract Obligations
organizations where they suffer from projects that simply will not die. The customer will not
sign off on a project, the other parties will not agree that a project is over, and so the
projects linger, continuing to consume resources for longer than anyone had anticipated.
We need to plan for this well in advance.
FULFILL CONTRACT OBLIGATIONS

................................................................
• Identify outstanding deliverables
• Customer analysis
• Internal analysis
• Identify outstanding promises
• Written
• Oral
• Review project charges
• Hand off deliverables
• Ensure customer acceptance
There was a project in a quasi-governmental agency in which a team member had promised
the customer one small, modest change in the look of a screen in their software. As the
project was coming to closure, on time and in budget, the team was chagrined to find out
that this one promise had not been fulfilled, and the customer was beginning to make noises
that they might complain to upper management in the organization that this one single
promise had not been fulfilled—despite the fact that everything agreed to in the project
charter, everything agreed to in the project documentation, had been met. That one
outstanding promise had the potential to burn the entire project, had the potential to create a
negative image of the project. We also need to look at our project charges. Have we
charged all the appropriate things to the project? The last thing you want to do, after a
project is closed out, is to have to return to accounting and tell them to reopen those files.
You do not want to have to make late charges against your project.
We need to hand off the deliverables. On that, let me offer a suggestion, if I might. Make it
ceremonial. Think about some of the great projects of our time. When they have occurred,
there has been some sort of ceremony to recognize the accomplishment. When they open a
new highway, they generally have a ribbon-cutting. The same thing for a building. When we
hand over software, it is very rare that anybody will go to that length, that they will have
some formal kind of ribbon-cutting. However, I have seen some of my peers in industry who
do this extremely well, who have recognized this as being a failing of their projects. What

THE EXIT STRATEGY
8 Conduct Final WBS Review
they have done instead is simply mounted a disk or a CD onto a plaque and handed that off
to the customer with a little notation as to the date of handover—something to
commemorate the event, something to seal it, something to recognize that they have had an
accomplishment, and to make sure that the customer is aware that there is a sense of
closure as well. All of these things work together to ensure successful project acceptance
and successful projects.
CONDUCT FINAL WBS REVIEW

................................................................
We need to do that last check—that last look-through of the WBS, the work breakdown
structure—to ensure that everything we said we were going to do has been done. In many
cases as we go through these activities, even on my projects, I have run into the experience
where you find an activity, you had planned to do it, you thought you were going to have to
do it, but it never got done. And the project was still whole and complete. I do not know
exactly how it happened, but it got done. I am not complaining. However, what do we do
about that work package? Do we just leave it at 0% complete? Well, yes and no. Document
precisely what happened to it. I do not care if you mark it as 0% or 100% complete. But just
make sure that somewhere in the documentation you reflect the fact that this activity either
never had to occur or that this activity occurred in tandem with another activity, was
completed in a different fashion, or was handled in a different way. You need to make sure
that there is some record as to what happened with this particular activity, what transpired
that you finished the project and this activity was never physically carried out. That needs to
be a part of the record, to reflect the as-built condition of the project, so that if someone else
goes to re-create your efforts, they will not be re-creating activities that, frankly, had no
impact on the project whatsoever.
ORGANIZE FILES
................................................................
• Accumulate project data
• Formal
• Informal
• Organize data
• Update data
• Eliminate superfluous data

.....
THE EXIT STRATEGY
Finalize Customer Relationships
At the end of any project, organizing the project files is a rather major challenge. You have a
lot of information left over, and it can be hard to discern what is worth keeping.
Important questions to ask yourself are, could any of this be used in a legal action related to
this project? If anything were to go horribly wrong with the project, would this information be
valuable in a legal action? If so, you should save it.
Also, organize the data in a sensible way. Find a way that makes good sense—not
something that is orchestrated to ensure you save everything. Most of us have seen project
binders with four, five, or even a dozen Gantt charts, and it is hard to tell what each means.
What is supposed to be accomplished by this ton of data? When you are building this kind of
information—when you are trying to store it all—be sure to store it in a way that makes
sense. Organize it.
Include a table of contents. The most effective project binders I have seen have a
comprehensive table of contents, which is so valuable. A good table of contents provides
structure and organization and lets you know what information is available and what is not.
Be sure that the information going into this binder is updated—that it has all the latest and
most current information available on the project. Finally, get rid of the garbage. That is not
easy to do. It is hard to sort through all the information and determine whether each piece is
important, but it must be done at this stage of the process.
FINALIZE CUSTOMER RELATIONSHIPS

................................................................
• Finalize acceptance
• Signatures
• Activate ongoing responsibilities
• Audit
• Maintenance
I always find it fascinating when I ask, what is best practice in terms of finalizing customer
relationships? Invariably, I hear, “to get all the last customer signatures, and to get the
customer to sign off on the project.” The most effective way to accomplish that, however, is
to have been doing it all through the project. It is not necessarily something done at
closeout. It is done on an ongoing basis and then culminated at project closeout.

THE EXIT STRATEGY
8 Celebrate A Successful Project
This practice allows for a smooth transition. How do we achieve a smooth transition in
handing off a project? We have plenty of documentation. We have good interaction. We
know the customer well and know what they are anticipating. We also have a clear
delineation of responsibilities: here is what we will do, and here is what you will do. And our
records reflect all this information.
If you follow these practices, it will be much easier to have the customer walk away from the
project happy—to have the customer accept the final deliverables and be satisfied.
The tools in the Transition Meeting Package provide a good structure for smoothly
transitioning your project in your organization and making it their project in their
organization.
CELEBRATE A SUCCESSFUL PROJECT

................................................................
• Conduct lessons-learned review
• Celebrate
• Give awards
I should warn you that in this stage, the project manager is at great risk. Project managers
can make horrible mistakes in attempting to celebrate success. Allow me to share one story
from a major telecommunications organization. They had planned to celebrate success at
the end of their project. The project manager planned it all out. What they were going to do
was, very simply, bring the team together for a celebration and rewards ceremony. The
project manager, however, decided to take it one step further. He went out and very
carefully planned a weekend for all his team members, who had been on the road for over
40 weeks. When the project was over, they got together for their final meeting, and the
project manager announced: “Guess what? I am rewarding you all with a weekend for two
out of town."
The team was devastated. The last thing they wanted to do was to get out of town. They
wanted to be in town. They wanted to be home with their family and their friends. The
project manager took a risk when it came to celebrating success. We need to ensure that
when it comes to celebrating success, we have identified the problems that it may generate
in and of itself.
Also, if you fail to celebrate success, you may indeed incur additional schedule problems
and cost problems later on. How so? The cost issue may relate to your ability to track down

.....
THE EXIT STRATEGY
Administration Closeout
the resources you need to finalize or close out the project—after it is closed out. There are
always some lingering issues after a project is closed out that require attention of the team
members who participated. If you have not celebrated their successes, they may not be
terribly anxious to lend you a hand. Thus, celebrating success can actually work in the best
interest of the project from a financial perspective.
ADMINISTRATION CLOSEOUT
................................................................
• Reassign personnel
• Redistribute materials
• Circulate and archive documentation for historical reference
When it comes to the financial and the schedule issues, this is perhaps the most important
of the closeout issues: administration. All the little administrative issues that can come back
to haunt a project manager if they are not taken care of properly are identified here. Think
about all the things that could possibly go wrong in a project. All of them can go wrong at the
end of a project as well. And if they are not attended to at the end of a project, they can
fester for a long period of time and can come back to cost the organization significantly.
A classic example came in one organization where a project was completed with very thin
margins. It barely eked out a profit. It had been challenging to begin with, and they had a
bunch of programmers who had been locked away in a war room, as it were, with 14 rented
computers and laser printers. Three months after the project was closed out, the project
manager was called in by accounting to ask about a current bill from a computer rental
company. Together, they learned the computers were never returned to the rental company.
And that small margin that project had made was completely wiped out by the additional
expense of months of computer rentals. The project manager had failed to take care of
administrative closeout.
Administration means making sure that all your team members have indeed been
reassigned; making sure they have gone someplace else; making sure all the materials
have been reassigned; making sure that you know where all the paperwork is and that
someone else is aware of what documentation has been created, recorded, and where it
has been placed. All that information goes into project termination, and if it is not taken care
of administratively, there is a significant chance for project failure in the long run.
You have a tool here, as well, Tool 15. It is the Project Termination Checklist. The Project
Termination Checklist is a wonderful tool for beginning to analyze what areas need to be

THE EXIT STRATEGY
8 Administration Closeout
closed out administratively at the end of a project. It does not cover everything, but it is a
great start.

APPENDIX
...................................
A
.....
Appendix A - Project Management Tools
Tool 1 - Project Requirements Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Tool 2 - Roles and Responsibilities Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Tool 3 - Sample Cost Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Tool 4 - Project Estimating Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Tool 5 - Change Control Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Tool 6 - Change Responsibility Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Tool 7 - Document Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Tool 8 - Evaluation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Tool 9 - Project Status Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Tool 10 - Evaluation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Tool 11 - Project Audit Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Tool 12 - Earned Value Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Tool 13 - Project Binder Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Tool 14 - Transition Meeting Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Tool 15 - Project Termination Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A Project Managers Guide to Scheduing and Cost Control A-151

APPENDIX
A
A-152 A Project Managers Guide to Scheduing and Cost Control

TOOL 1
Project Requirements Document
Project Name Project Ref. No. Prepared By (print) Preparer’s Initials
Customer Contact Contact’s Phone Date Prepared
Background/Summary of Project
Comments
Project Goals/Objectives
Comments
Project Phases/Deliverables
Comments
Key Milestones
Comments
Assumptions
Comments
Risks
Comments
Key Resource Requirements

Comments
Constraints
Comments
Interrelated Projects
Comments
Acceptance Criteria
Comments
Signatures
Comments
Reviews
Comments
Communication Plan
Comments
Change Management Plan

Comments
Financial Analysis
Comments
TOOL 2
Roles and Responsibilities Matrix
Guidance
1. Map the work breakdown structure (WBS) into the matrix.
2. Analyze each WBS element to determine which individuals will be responsible for which activities (or
summary activities). (Insert columns as needed to identify all required resources.)
3. After all WBS elements are analyzed, review the matrix for unidentified resources and roles.
4. Obtain resource commitments from appropriate organizations for the identified resources and roles; modify the
matrix as appropriate to reflect those negotiations.
5. Repeat Steps 1 through 4 for each level of detail added to the WBS down to the work package level.
6. Review and update the matrix with the project team members and organization authorities.
Roles and Responsibilities Matrix
Activity Task Subtask (if applicable) PM [Name] [Name] [Name] [Name] [Name] [Name] [Name] [Name]
1
1.1
[Summary Activity]
1.1.1
Task
1.1.2
Task
1.1.3
Task
1.2
[Summary Activity]
1.2.1
Task
1.2.2
Task
1.2.3
Task
1.2.4
Task
1.3
[Summary Activity]
1.3.1
Task
1.3.2
Task
2
2.1
[Summary Activity]
2.1.1
Task
2.1.2
Task
KEY: PM = Project Manager; [Insert acronyms/definitions as appropriate]

TOOL 3
Sample Cost Table
Costs Unit Cost No. of Units Total

Direct
Fixed
Hardware
Software
Materials
Equipment
Rent
Variable
Direct Labor
Direct Labor—Overtime
Contract Labor
Contract Labor—Overtime
Extraordinary Services
Storage Charge
Special Handling
Transportation Charge
Travel
Training
Indirect
Fringe
G&A
Total
TOOL 4
Project Estimating Worksheet
Activity ID Activity Description
Completion Criteria
Resources
Calculated
Effort Resource Resource
Resource Required Availability Productivity Duration Unit Cost Cost
Tool 4 Project Estimating Worksheet
Materials/Other
Calculated
Materials/ Effort Resource Resource
Other Required Availability Productivity Duration Unit Cost Cost
Total Cost Calculated Duration Constraining Duration Activity Duration Assumptions
(attach)
TOOL 5
Change Control Form
Initiator Information
Name of Person Who Initiated Change Organization Name (identify as internal or external)
Organization Address
Phone Fax E-mail
Change Information
Last Plan Update Current Plan Location
Nature of Change
Does change represent a scope change? Yes No

If yes, complete 1–3.
1. Detail breadth of change to project cost, including organizational responsibility.
2. Detail breadth of change to project schedule, including organizational responsibility.
3. Detail breadth of change to project technical specification, including organizational responsibility.
Change Authority —Internal Signature Change Authority —Customer Signature
Signatures in the boxes above indicate acceptance of the change and the organizational responsibility as described. Authorized signatures are thos e
from individuals with the rights to sign contracts on behalf of their organizations.
TOOL 6
Change Responsibility Document
Role Name Title
Project Manager (PM)

Phone Fax E-mail
Responsibilities
q Establish configuration baseline

q Maintain documentation related to baseline
q Manage change control process
q Integrate change and report out
Role Name Title
Customer Project Manager (CPM)

Phone Fax E-mail
Responsibilities
q Review configuration baseline with PM

q Accept/reject proposed change
Role Name Title
Project Change Control Board

(CCB) Representative 1
Phone Fax E-mail
Responsibilities
q Identify potential specification changes

q Periodically review status of configuration database
q If authorized, enter changes to configuration database
Change Responsibility Document
Role Name Title

Phone Fax E-mail
Responsibilities

Role Name Title

Phone Fax E-mail
Responsibilities

Role Name Title
Phone Fax E-mail
Responsibilities
q
q
q
Role Name Title
Phone Fax E-mail
Responsibilities
q
q
q
TOOL 7
Document Control
Document Distribution
Name Title Organization
Change History
Date Change Description Approved By
TOOL 8
Evaluation Report—Management Level
Project Manager
Highlights
Comments
Cost
Comments
Schedule
Comments
Quality
Comments
Issues
Comments
Plan Changes Implemented

Comments
Plan Changes Outstanding

Comments
Attachments
1.
2.
3.
TOOL 9
Project Status Report
Project Team Member WBS No. and Title Location
Phone Fax E-mail
Completed Incomplete/Pending
Task/ Planned Planned Actual Not Yet Actual Est.
WBS No. Start Finish Finish Started Start % Complete Compl.
Date
Issues Suggestions
1. 1.
2. 2.
3. 3.
4. 4.
TOOL 10
Evaluation Checklist
Guidance: Check off each item as completed responses to questions are logged in project binder.
Project Evaluation Questions

✟ Where is the project with respect to schedule?
✟ Where is the project with respect to cost?
✟ Where is the project with respect to meeting specifications?
✟ Where is the project with respect to overall objectives and goals?
✟ Where are the WBS elements (at desired level of evaluation) with respect to schedule?
✟ Where are the WBS elements with respect to costs?
✟ Where are the WBS elements with respect to meeting technical requirements?
✟ Where are the WBS elements with respect to project goals and objectives?
✟ What project areas are running well?
✟ What project areas are running poorly?
✟ What opportunities are evolving from the project?
✟ What concerns are developing with the project?
✟ Is the project still in line with organizational objectives?
✟ Is the customer satisfied?
✟ Is the project team satisfied?
✟ Have outside sources examined project progress?
✟ Is the project team functioning well?
✟ Is the project still a strategic fit for the organization?
✟ Does the project remain profitable?
✟ Are there any potential reasons on the horizon that the project should be stopped?
Note: Your organization’s questions may vary depending on type of project.

TOOL 11
Project Audit Outline
Guidance: Use this outline to prepare a comprehensive Project Audit Report.
1.0 Summary
Write an executive-level summary describing the audit and its findings, results, and
recommendations.
1.1 Audit Description. Record what was being audited: area, date(s), type, scope, and basis.
1.2 Findings. Summarize major findings that guide the result and recommendations.
1.3 Conclusion. State the result: pass or fail.
1.4 Recommendations. Summarize the follow-up actions detailed in the audit results section of
the report.
2.0 Audit Description
2.1 Area(s). Indicate the area(s) and department(s) audited.
2.2 Audit Dates. Record the date or date range of the audit.
2.3 Type. Specify whether this was a system, compliance, process, or project audit, or some
combination thereof.
2.4 Scope. Indicate whether this was a full or partial audit.
2.5 Basis. Describe the basis of the audit (what the areas audited were compared with, such as
requirements, policies, standards, procedures, and so on).
2.6 Personnel Contacted. List the personnel who were contacted by the auditors and their titles,
organizations, and roles.
2.7 Auditors. List the auditors and their titles, organizations, and roles.
3.0 Audit Results
3.1 Auditors’ Conclusion. Reiterate the result: pass or fail.
3.2 Recommendations. Recommend one of the following: no follow-up audit (only if “pass”);
follow-up audit to verify completion of corrective actions; follow-up audit (specify whether full
or partial).
3.3 Findings and Corrective Action Plans. Briefly describe the major findings of the audit on the
following page. For each finding, show who is responsible for the corrective action plan and
the target date for the plan’s completion. In this section, note the major findings and
observations, but avoid providing extensive detail, unless it represents a significant problem
or jeopardy to the project and/or the organization’s processes or procedures.
3.4 Other Issues Summary. Insert summary of minor findings and observations.
4.0 Audit Report Distribution
Specify the distribution list for the audit report.
Corrective Action
Audit Finding Finding Summary Target Date Assigned To
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
TOOL 12
Earned Value Report
Reporting Period: ________ to ________

Current Period Cumulative to Date Estimate at Completion
WBS Item Budgeted Cost Actual Cost Variance Budgeted Cost Actual Cost Variance Latest
Work Work of Work Work Work of Work Revised
Scheduled Performed Performed Schedule Cost Scheduled Performed Performed Scheduled Cost Budgeted Estimate Variance
Explanation of Variances
Significant Issues or Problems

TOOL 13
Project Binder Content and Update Guide
Contents Location Update Information

Project Plan Ensure that changes to the project plan
Include key elements of the project are incorporated here as they are
plan and other project plan elements created.
that will be used extensively in
managing the project.
q Work breakdown structure Update as approved change requests
are processed.
q Project schedule Update as change requests are
processed and status reports are
received for filing.
q Project budget Revise based on approved change
requests and on cost data provided in
status reports.
q Index to supporting plans Not updated
Risk Management Plan Make changes to risk element
descriptions to reflect actual events, add
risk element descriptions for new risks,
and incorporate information based on
the effects of risk migration strategies.
q Opportunity overview Not updated
Contract Elements
q Contract Update the contract to incorporate
contract modifications and changes as
they are approved by the customer.
q Statement of work Include changes to the SOW as
approved by the customer.
q Contract tracking summary Not updated
q Subcontract tracking summary Not updated
q Customer commitment log Not updated
Audit Reports Not updated
Project Binder Content and Update Guide
Contents Location Update Information

Status Reports Not updated
Lessons-Learned Documentation Not updated
Correspondence Not updated
Change Control
q Change requests Not updated
q Impact statements Not updated
Test and Acceptance Not updated
q Acceptance test review and Not updated
disposition
q Customer sign-off procedures Not updated
Meetings Not updated
q Issue/action item logs Not updated
q Minutes Not updated
q Agendas Not updated
q Meeting attendance check-in Not updated
sheets
Postproject Summary Not updated
Supporting Plans Not updated
q List appropriate plans
TOOL 14
Transition Meeting Package
General Information
Project Manager Organization
Address
Phone Fax E-mail

Tool 14 Transition Guidelines
Transition Guidelines
Purpose
In a formal meeting with the customer, the project manager describes all the warranty provisions and
continuing responsibilities covered by the contract or project charter and how the PM’s organization
and/or third parties will satisfy those provisions. Any service providers are introduced to the customer.
Preparation Checklist
q Collect and review documentation of warranty coverage, continuing responsibilities, and
requirements
q Contract (review requirements)
q Project charter (as appropriate)
q As-built system, product, or process delivered to customer (review provisions)
q Organization service documentation
q Third-party service documentation
q List and describe any components covered under warranty and those covered under third-party
warranties
q Describe the process by which the PM’s organization will provide warranty service
q Describe the process by which third parties will provide warranty service
q Ensure that the customer knows how to contact the organization and third parties for warranty
service
q List and describe any ongoing organizational responsibilities not covered under warranty
q Describe the process by which the PM’s organization will meet those responsibilities
q Develop a list of third-party service providers who should attend
q Notify selected attendees
q Prepare and distribute agenda
Tool 14 Transition Meeting Agenda
Transition Meeting Agenda
Announcement Information
To From Date
Meeting Information
Date Start Time End Time Location
Meeting Purpose
Called By Phone Fax E-mail
Sponsored By Phone Fax E-mail
Agenda Items Presenter Time

Welcome and introductions
Meeting purpose
Overview of system, product, or
process and identification of warranties
Overview of supplemental
requirements of PM organization
Review of contract
Review of project charter (as
appropriate)
Review of warranty
Review of third-party service
warranties
Introduction of service providers
Summary
Close
TOOL 15
Project Termination Checklist
Guidance: Check off when complete response is logged in project binder.
Project—Internal
q Are any deliverables outstanding?
q Have internal certifications been signed and received?
q Are there any internal outstanding commitments?
q Have all costs been appropriately charged to the project?
q Have all work packages and work orders been completed?
q Have any incomplete work packages been documented and rationalized?
q Has management been notified regarding the availability of project personnel?
q Has management been notified regarding the availability of project facilities?
q Has the project plan been archived with all support data?
q Has excess project material been dealt with?
Project—External
q Has agreement been reached with the project owner on disposition of remaining deliverables?
q Have external certifications and authorizations been signed and approved?
q Have suppliers been notified regarding any outstanding commitments?
q Are all parties aware of pending termination?
q Have on-site project facilities been closed?
q Have auditing and maintenance procedures been put in place and activated?
Project Termination Checklist
Personnel—Internal
q Have project team concerns regarding future employment been addressed?
q Is the project team dedicated to remaining project commitments?
q Are motivating factors still in place for remaining tasks and obligations?
q Have concerns regarding team identity been addressed?
q Have personnel been reassigned or notified of reassignment methodology?
Personnel—External
q Are efforts being made to ensure project owner interest remains high?
q Are efforts being made to ensure project owner attitudes and perceptions regarding the project are
stable?
q Are shifting personnel issues being addressed with the project owner?
q Are key project (and project owner) personnel still being apprised of project status?
q Does a communication methodology exist to maintain relations between owners and project
managers?

Scheduling Cost

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Scheduling Cost

Caricato da

Copyright:

Formati disponibili

.....

Understanding How to Manage Projects Preface

www.pmptools.com, inc., publishing division welcome corrections and comments on its

ISBN 0-9726656-7-6 (paperback)

Preface Understanding How to Manage Projects

Chapter 2 - Project Management Review

Chapter 3 - Resource Allocation & Estimating

A Project Managers Guide to Scheduing and Cost Control Table of Contents

Table of Contents A Project Managers Guide to Scheduing and Cost Control

Chapter 5 - The Baseline

Chapter 6 - Managing Change Within the Project

Chapter 7 - Evaluation and Forecasting

A Project Managers Guide to Scheduing and Cost Control Table of Contents

Chapter 8 - The Exit Strategy

Appendix A - Project Management Tools

Exercise & Assignments

Table of Contents A Project Managers Guide to Scheduing and Cost Control

A Project Managers Guide to Scheduing and Cost Control Introduction 1-1

1-2 Introduction A Project Managers Guide to Scheduing and Cost Control

A Project Managers Guide to Scheduing and Cost Control Introduction 1-3

1-4 Introduction A Project Managers Guide to Scheduing and Cost Control

At the end of this chapter, you will be able to—

• Identify the elements of scheduling and cost control

WHAT IS SCHEDULING AND COST CONTROL?

A Project Managers Guide to Scheduing and Cost Control 2-5

WHY SCHEDULING AND COST CONTROL?

THE PROJECT LIFE CYCLE

2-6 A Project Managers Guide to Scheduing and Cost Control

A Project Managers Guide to Scheduing and Cost Control 2-7

SCHEDULING AND COST CONTROL - EXERCISE

Specifically, we are looking for—

2-8 A Project Managers Guide to Scheduing and Cost Control

Challenges Tools Benefits

ORGANIZATIONAL CONTEXT FOR SCHEDULING AND COST

A Project Managers Guide to Scheduing and Cost Control 2-9

Methods Tools Documentation

2-10 A Project Managers Guide to Scheduing and Cost Control

WORK BREAKDOWN STRUCTURE REVIEW

• Does the WBS define the whole project?

A Project Managers Guide to Scheduing and Cost Control 2-11

WORK BREAKDOWN STRUCTURE REMINDERS

2-12 A Project Managers Guide to Scheduing and Cost Control

A Project Managers Guide to Scheduing and Cost Control 2-13

2-14 A Project Managers Guide to Scheduing and Cost Control

At the end of this chapter, you will be able to—

• Apply different estimating tools in the project management process

A Project Managers Guide to Scheduing and Cost Control 3-15

• What level of excellence and competence is essential?

3-16 A Project Managers Guide to Scheduing and Cost Control

A Project Managers Guide to Scheduing and Cost Control 3-17

RESOURCES AS ESTIMATING SOURCES

3-18 A Project Managers Guide to Scheduing and Cost Control

7.1 7.2 7.3 7.4

A Project Managers Guide to Scheduing and Cost Control 3-19

3-20 A Project Managers Guide to Scheduing and Cost Control

THE RULES OF ESTIMATING

A Project Managers Guide to Scheduing and Cost Control 3-21

3-22 A Project Managers Guide to Scheduing and Cost Control

ESTIMATING METHODS: ANALOGY AND VENDOR BIDS

2 Find Analogous Project

3 Assess Analogous Qualities

4 Evaluate Price/Cost of Previous Project

5 Apply to New Project

A Project Managers Guide to Scheduing and Cost Control 3-23