. 1
( 9)



>>

Blueprint for
Project Recovery”
A Project
Management Guide


Y
FL
AM
TE


Ronald B. Cagle




AMACOM
Blueprint for

PROJECT
RECOVERY”
A Project
Management Guide
This Page Intentionally Left Blank
Blueprint for

PROJECT
RECOVERY”
A Project
Management Guide
The Complete Process for Getting Derailed Projects Back on Track


Ronald B. Cagle



American Management Association
New York • Atlanta • Brussels • Buenos Aires • Chicago • London • Mexico City
San Francisco • Shanghai • Tokyo • Toronto • Washington, D.C.




.......................... 9758$$ $$FM 12-09-02 08:29:16 PS
Special discounts on bulk quantities of AMACOM books are
available to corporations, professional associations, and other
organizations. For details, contact Special Sales Department,
AMACOM, a division of American Management Association,
1601 Broadway, New York, NY 10019.
Tel.: 212-903-8316. Fax: 212-903-8083.
Web site: www.amacombooks.org


This publication is designed to provide accurate and authoritative
information in regard to the subject matter covered. It is sold with the
understanding that the publisher is not engaged in rendering legal,
accounting, or other professional service. If legal advice or other expert
assistance is required, the services of a competent professional person should
be sought.
Various names used by companies to distinguish their software and other
products can be claimed as trademarks. AMACOM uses such names
throughout this book for editorial purposes only, with no intention of
trademark violation. All such software or product names are in initial
capital letters or ALL CAPITAL letters. Individual companies should be
contacted for complete information regarding trademarks and registration.
A list of these trademarks can be found on page 273 following the
bibliography.

Library of Congress Cataloging-in-Publication Data
Cagle, Ronald B.
Blueprint for project recovery : a project management guide : the complete process for getting derailed
projects back on track / Ronald B. Cagle.
p. cm.
Includes bibliographical references and index.
ISBN 0-8144-0766-8 (hardcover)
1. Project management. I. Title.
HD69.P75 C345 2003
658.4 04”dc21 2002011733
2003 Ronald B. Cagle
All rights reserved.
Printed in the United States of America.
Although this publication is subject to copyright, permission is granted free of charge to reproduce the forms
that are required by each user and to print and use pages from the enclosed CD-ROM. Only the original
purchaser may make copies. Under no circumstances is permission granted to sell or distribute on a
commercial basis material reproduced from this publication.
Except as provided above, this publication may not be reproduced, stored in a retrieval system, or transmitted
in whole or in part, in any form or by any means, electronic, mechanical, photocopying, recording, or
otherwise, without the prior written permission of AMACOM, a division of American Management
Association, 1601 Broadway, New York, NY 10019.
Printing number
10 9 8 7 6 5 4 3 2 1




.......................... 9758$$ $$FM 12-09-02 08:29:17 PS
TABLE OF CONTENTS

PREFACE xiii

ACKNOWLEDGMENTS xvii

CHAPTER 1
GETTING STARTED 1

1.1 General 3
1.2 Requirements 7
1.3 The Search Methodology 7

CHAPTER 2
CHECKING PROGRAMMATIC PERFORMANCE 9

2.1 General 9
2.2 Programmatic Performance Checklist 9
2.3 Programmatic Explanations 10

CHAPTER 3
CHECKING TECHNICAL PERFORMANCE 38

3.1 General 38
3.2 Technical Performance Checklist 38
3.3 Technical Explanations 41
v




.......................... 9758$$ CNTS 12-09-02 08:29:08 PS
TABLE O F CONTENTS
vi


CHAPTER 4
RECOVERING FROM PROGRAMMATIC PROBLEMS 56


4.1 General 56
4.2 Programmatic Recovery Checklist 56
4.3 Programmatic Recovery Cause Descriptions 58


CHAPTER 5
RECOVERING FROM TECHNICAL PROBLEMS 109


5.1 General 109
5.2 Technical Search Tables 109
5.3 Technical Recovery Cause Descriptions 112


CHAPTER 6
EXPANDING THE CAUSE BASE FOR YOUR PROJECT 156


6.1 General 157
6.2 Brainstorming 158
6.3 Researching Appropriate Benchmarks 160
6.4 Researching the Processes 161
6.4.1 Standard Processes 161
6.4.2 Customer Processes 162
6.4.3 Enterprise Processes 162
6.4.4 Project/Program Processes 162


CHAPTER 7
GROUPING THE CAUSES FOR ACTION 165


7.1 General 165
7.2 Ordering Techniques 165
7.2.1 85:15 Rule 166
7.2.2 Cause and Effect Diagram 167
7.2.3 Af¬nity Diagrams 171
7.2.4 Relationship Diagrams 173
7.3 Interrelationships of Causes 176
TABLE OF CONTENTS vii


CHAPTER 8
SELECTING THE BEST OF THE BEST 177

8.1 General 177
8.2 Evaluation Techniques 178
8.2.1 Pareto Analysis 178
8.2.2 Force Field Analysis 180
8.2.3 Failure Mode Effect Analysis (FMEA) 182
8.2.4 Monte Carlo Simulation 184
8.3 Eliminating Holes and Overlaps 186
8.4 Choosing the Causes 187

CHAPTER 9
IMPLEMENTING THE TAILORED CHANGES 188

9.1 General 188
9.2 Implementation Techniques 188
9.2.1 Slipping in the Fix 189
9.2.2 Creating ˜˜On-Ramps™™ 189
9.2.3 ˜˜Dumping™™ the Fix 190
9.3 Selecting Your Technique 190

CHAPTER 10
CONCLUDING 191

10.1 General 191
10.2 The Concluding Process 192
10.2.1 Quantum Improvement 192
10.2.2 Documentation 193
10.3 Data Trail 195
10.4 Modifying Methods 196

CHAPTER 11
USING THE COMPACT DISK (CD) 197

11.1 General 197
11.2 Loading 198
11.3 Using the Tables 198
11.4 Using the Attachments 198
TABLE O F CONTENTS
viii


SUMMARY 199

GLOSSARY 203

ATTACHMENTS 217

1 Standard Program Plan Outline 219
2 Standard Technical Plan Outline 223
3 Risk Mitigation Plan 227
4 Contract/Subcontract Outline 231
5 Con¬guration Management Plan Outline 234
6 Quality Assurance Plan Outline 237
7 Requirements Traceability Matrix 241
8 Requirements Flow-Down Matrix 245
9 Data Delivery Matrix 247
10 Capability Matrix 249
11 Policy-to-Plan Trail 251
12 Experience Window 253
13 Standards Traceability Matrix 255
14 Vendor Evaluation Process 258
15 Design Review Approval Form 263
16 In-Process Review Approval Form 265
17 Negotiation Checklist 267
18 Critical Success Factor (CSF) Matrix 269

BIBLIOGRAPHY 271
FIGURES

Figure 1-1 Project/Program Environment 2
Figure 1-2 Project/Program Requirements Control
Relationships 4
Figure 1-3 Documentation Interrelationships 5
Figure 2-1 Vendor Evaluation Sheet 32
Figure 4-1 Vendor Evaluation Sheet 93
Figure 5-1 Requirements Allocation 123
Figure 5-2 Design Review Approval Form 128
Figure 5-3 In-Process Review Approval Form 130
Figure 7-1 Fishbone Diagram 168
Figure 7-2 Tree Diagram 169
Figure 7-3 Af¬nity Diagram 172
Figure 7-4 Relationship Diagram 174
Figure 8-1 Pareto Analysis: Raw Data 179
Figure 8-2 Pareto Analysis: Ordered Data 179
Figure 8-3 Force Field Schematic 181
Figure 10-1 A Typical Traditional Library 194
Figure 10-2 Schematic of an Electronic Library 195
Figure A3-1 Risk Mitigation Form 228
Figure A13-1 Policy-to-Program Plan to Support Document Flow 257
Figure A14-1 Vendor Evaluation Sheet 260
Figure A14-2 Vendor Evaluation Summary 261
Figure A14-3 Vendor Selection Summary Score Sheet 262
Figure A15-1 Design Review Approval Form 264
Figure A16-1 In-Process Review Approval Form 266
ix
This Page Intentionally Left Blank




Y
FL
AM
TE
TABLES

Table 2-1 Programmatic Performance Checklist 11
Table 2-2 Experience Window 13
Table 2-3 Meetings and Reviews 16
Table 2-4 Speci¬cation Types 18
Table 2-5 Experience Window 19
Table 2-6 Task Quali¬cation 19
Table 2-7 Requirements Traceability Matrix (RTM) 22
Table 2-8 Standards Traceability Matrix (STM) 23
Table 2-9 Standards Traceability Matrix (STM) 24
Table 2-10 Standards Traceability Matrix (STM) 25
Table 2-11 Requirements Flow-Down Matrix (RFM) 27
Table 2-12 Subcontracts Requirements Traceability Matrix
(SRTM) 27
Table 3-1 Technical Performance Checklist 39
Table 4-1 Programmatic Recovery Checklist 57
Table 4-2 Experience Window 61
Table 4-3 Task Quali¬cation 62
Table 4-4 Meetings and Reviews 66
Table 4-5 Task Quali¬cation 69
Table 4-6 Requirements Traceability Matrix (RTM) 73
Table 4-7 Problem Cross-Reference Table 74
Table 4-8 Standards Traceability Matrix 75
Table 4-9 Standards Traceability Matrix 76
Table 4-10 Standards Traceability Matrix 77
Table 4-11 Requirements Flow-Down Matrix (RFM) 84
Table 4-12 Requirements Traceability Matrix (RTM) 84
Table 4-13 Task Quali¬cation 86
Table 4-14 Meetings and Reviews 90
xi




.......................... 9758$$ TBLS 12-09-02 08:29:18 PS
TABLES
xii


Table 4-15 Meetings and Reviews 96
Table 4-16 Data Delivery Matrix 104
Table 5-1 Technical Recovery Checklist 110
Table 5-2 Critical Success Factor (CSF) Matrix 112
Table 5-3 Requirements Traceability Matrix (RTM) 119
Table 5-4 Requirements Traceability Matrix (RTM) 121
Table 5-5 Issue Pairs and Recoveries 131
Table 5-6 Requirements Traceability Matrix (RTM) 134
Table 5-7 Requirements Flow-Down Matrix (RFM) 135
Table 5-8 Requirements Flow-Down Matrix (RFM) 135
Table 5-9 Requirements Traceability Matrix (RTM) 136
Table 5-10 Requirements Traceability Matrix (RTM) 137
Table 5-11 Requirements Flow-Down Matrix (RFM) 137
Table 5-12 Standards Traceability Matrix (STM) 138
Table 5-13 Requirements Traceability Matrix (RTM) 143
Table 5-14 System Effectiveness Parent Organization 155
Table 6-1 Expansion Methodologies 158
Table 6-2 Brainstorming Software 159
Table 6-3 Policy-to-Program Plan Cross Reference 163
Table 7-1 Ordering Techniques 166
Table 7-2 Cause and Effect Table 170
Table 7-3 Cause and Effect Software 170
Table 7-4 Af¬nity Diagram Software 173
Table 7-5 Relationship Diagram Software 175
Table 8-1 Analysis Techniques 178
Table 8-2 Pareto Analysis Software 180
Table 8-3 Analyzing Holes and Overlaps 187
Table 9-1 Spaces for ˜˜Slipping in the Fix™™ 189
Table 9-2 Spaces for ˜˜On-Ramps™™ 190
Table 12-1 Process Flow-Through Tables 201
Table A3-1 Risk List 229
Table A4-1 Speci¬cation Types 233
Table A7-1 Requirements Traceability Matrix (RTM) 243
Table A8-1 Requirements Flow-Down Matrix (RFM) 246
Table A9-1 Data Delivery Matrix 248
Table A10-1 Capability Matrix 250
Table A11-1 Policy-to-Plan Table 252
Table A12-1 Experience Window 254
Table A12-2 Capability Matrix 254
Table A13-1 Standards Traceability Matrix 256
Table A18-1 Critical Success Factor (CSF) Matrix 270
PREFACE

Blueprint For Project Recovery”A Project Management Guide is a unique combi-
nation of text and interactive CD that provides:

’ A tutorial for the aspiring project manager
’ A text for the newly assigned project manager
’ A checklist for the ongoing project manager
’ A quick-response recovery tool for the project manager with a project in
trouble

If you are part of a small business, this book provides insight into all levels
of projects. It draws from the ˜˜best-of-the-best™™ to provide you with a consoli-
dated view into what all businesses, large, small, government, and commercial,
are doing.
xiii




.......................... 9758$$ PREF 12-09-02 08:29:23 PS
P RE FA C E
xiv


If you are part of a large business or are associated with the federal, state, or
local government as an employee or as a contractor, this book has special mean-
ing for you. It uses many federal policies, plans, processes, and standards as
references. It uses these references for two reasons: ¬rst, they are thorough, and
second, you, as a taxpayer, have already paid for them”why not use them?
Projects and programs usually consist of three principal periods”planning,
conducting, and concluding. The conducting period is divided into two parts
that occur sporadically: normal and terrifying. The normal part consists of the
day-to-day activities that are going according to plan. The terrifying part is
when the project goes off track”roughly akin to a ˜˜near-miss™™ in an airplane.
This book was written to take some of the terror out of the ˜˜near-miss.™™
While this book won™t solve all your problems, it will give you a leg up on a
lot of them. In addition, this book will provide techniques to tailor or customize
the process to your way of doing business or for your speci¬c business area or
your speci¬c technical problems.
Many companies reward project and program managers for jobs well done.
These rewards come in a number of different forms. One of the rewards is in
the category of recovery. It is a coveted award because any project or program
manager who has been around for a while knows that it is considerably more
dif¬cult to restore a project or program than it is to start up or maintain one.
Frequently, the recovery award is called the Phoenix Award. It is called the
Phoenix Award because it relates to the mysterious phoenix”the bird that is
the symbol of immortality, resurrection, life, and death. In ancient mythology,
the phoenix was said to consume itself in ¬‚ames and then, three days later arise
from the ashes, allowing the cycle of life to continue. . . .
All too often, projects and programs are consumed in ¬‚ames and turn to
ashes. The purposes of this book are to recommend up-front planning, provide
a checklist for ongoing projects, and, if you are really in a bind, effect the resur-
rection from the ashes and allow the project™s cycle of life to continue.
Now, let™s look at what is forthcoming in this book and how we are going to
handle these elements.
The ¬rst part of the book consists of Chapters 1 through 5. Chapter 1 sets
the stage with an overview of the project/program environment and the recov-
ery process. Chapters 2 and 3 present checklists for programmatic and technical
issues, together with the associated explanations that can be used as a checklist
for planning a project or checking an ongoing project. Chapters 4 and 5 follow
the same convention but, this time, offer a recovery approach for those issues
that have, or may have, gone off track.
The second part of the book, Chapters 6 through 10, provides techniques
PREFACE xv


and methodologies for expanding the provided database and tailoring it to your
speci¬c needs.
I recommend that you read the book from beginning to end and follow the
process that is outlined. However, I recognize that you may not have time to
do all that. For that reason, I have provided checklists to make the process easier
and, if you have a problem that needs immediate attention, you can jump to
Chapter 11 and use the interactive CD to help you solve the problem staring
you in the face. If you take that approach, however, take some time to go back
and read the whole book so you won™t get in that bind again!



Ronald B. Cagle
This Page Intentionally Left Blank
ACKNOWLEDGMENTS

This book would never have come to print without the efforts of a number of
people. First among these is Dr. Wallace G. Berger. Wally was instrumental in
helping with some of the concepts and many of the technical details. He is the
guru of architecture and metrics. We spent many hours in planning, and he
spent a great deal of time reviewing the manuscript at all levels.
I want to offer special thanks to the following people:
To Mr. Robert Gray, an expert in software programs and in program rescue
as well. He was a candidate for the coveted Phoenix Award several years ago.
Bob is presently chief engineer for a transportation company in Canada. His
reviews of content and contributions were extremely helpful.
To Mr. Larry Kile, an electrical engineer and program manager, and now a
director of engineering for a large company in Atlanta.
To Mr. David Botto, a former engineering section head and programs
director. He is now the president and CEO of his own airport implementation
company.
xvii




.......................... 9758$$ $ACK 12-09-02 08:29:28 PS
CHAPTER 1




GETTING STARTED

Whether you are preplanning your project or your project is up and running
and you want to conduct an in-process evaluation or whether you™ve experi-
enced a failure in some part of your project, you are in the right place.
To begin, let™s set the baseline by establishing some de¬nitions. You may or
may not agree with all the de¬nitions, and that™s okay as long as you understand
how these terms are to be used in the book.
We™ll start with the difference between a project and a program. Everybody
has his own de¬nition, so here™s mine. A project is conducted for a customer
who is internal to an enterprise. A program is conducted for a customer who is
external to the enterprise; a program has legal rami¬cations between the enter-
prise and the customer. (See Figure 1-1.) The discriminator is the legal docu-
ment or contract. Stated in another way, a program manager has Pro¬t and
Loss (P&L) and legal responsibility in addition to cost, schedule, and technical
responsibilities. The project manager, on the other hand, has cost, schedule, and
technical assignments. Thus, a program manager needs a slightly different skill
1




.......................... 9758$$ $CH1 12-09-02 08:29:33 PS
BLUEPRINT FOR PROJECT RECOVERY
2


Figure 1-1 ” Project/Program Environment


Contract
Enterprise

Customer Program




Requirement



Customer Project

Enterprise




set than a project manager. Some people like to de¬ne a program as bigger than
a project or as a collection of projects. While this can sometimes be true when
a large program is subdivided into segments, or Sub Program Of¬ces (SPOs),
this makes projects appear to be less important than programs. They™re not!
Consider the enormity of the Manhattan Project, and I think you will under-
stand why I have a lot of trouble with that de¬nition.
For simplicity, I intend to use the term ˜˜project™™ throughout this book ex-
cept in those cases where the term ˜˜program™™ is called for under this de¬nition.
The second de¬nition is the project and program environment. This consists
of three elements: The customer (the one who creates the requirement), the
enterprise (the company, corporation, or other legal entity), and the project or
program itself. I visualize the program and project environments as shown in
Figure 1-1.
The real difference is that the project is fully contained within the company,
which is the creator of both the requirements and the home of the project. In
the case of the program, however, the customer is outside the company. In this
case, carefully note that the ensuing contract is between the customer and the
company and not the customer and the program. The program is not a legal
entity.
GETTING STARTED 3


1.1 General

Figure 1-2 is a composite drawing that shows the relationships between several
different parts of the overall project/program process.
The requirements (near the middle) are actually the beginning. The require-
ments drive the project/program implementation concept (up) and the project/
program documentation and methodologies (down). On the upward leg, the
requirements are converted into schedule and budget. On the downward leg,
the requirements are decomposed into the Work Breakdown Structure (WBS).
The WBS is arguably the most important tool of the project planning proc-
ess. The WBS shows the decomposed task to be accomplished by dividing the
requirement into ˜˜chunks™™ that can be scheduled, costed, and controlled. Each
of these chunks is then assigned to an appropriate operating organization for
accomplishment. The majority of the WBS is product-oriented although it does
contain some organizational and control aspects. Without these organizational
and control aspects, the WBS is really a design tree, an equipment tree, or a
Y
product tree.
FL
The requirements document (contract) and the WBS are the initial and
major contributors to the all-important Requirements Traceability Matrix (see
Attachment 7).
AM


Finally, you add the methodologies of schedule, budget, and processes or
procedures to control the cost, schedule, and quality of the product at the lowest
level of the WBS, which is called the Work Package (WP). The Work Package
TE




appears in the WBS at the lowest level of the WBS at the intersect with the
organizational element that will accomplish the task. Thus, the Work Package
is really the heart of the WBS. The remainder of the structure is simply an
organized way to get down to the Work Package by decomposing the require-
ment or a way to get back to a higher level by rolling up from the bottom.
Throughout the text of this book you will see references to a Work Break-
down Structure (WBS), a Requirements Traceability Matrix (RTM), a Require-
ments Flow-down Matrix (RFM), and a Work Package (WP). Each of these
documents serves a vital role, and it is important to understand how each ¬ts
into the overall scheme of things. Figure 1-3 ties all these activities together in
one diagram.
There are subtleties in Figure 1-3 that are worth mentioning. Notice ¬rst that
the Customer Requirement, consisting of the Statement Of Work (SOW) and
the Speci¬cation (Spec), drives the RTM to the left and the RFM to the right.
BLUEPRINT FOR PROJECT RECOVERY
4


Figure 1-2 ” Project/Program Requirements Control Relationships




Design

Fabrication
Implementation
Test
Procurement

Closure


Requirements



WBS




Documentation
Work Work
Dept A
Package Package

Work Work
Dept B
Package Package

Work
Dept C
Package

Work
Dept D
Package



Quality
Schedule
Cost


Measurement
Measurement
Measurement


Goal
Goal Metric
Metric
Goal Metric Methodologies




Condition
Condition
Condition
GETTING STARTED 5


Figure 1-3 ” Documentation Interrelationships


RFM
RTM Customer
Requirement
(SOW & Spec)



WBS


Work Package

Subcontract
Purch. Order



SRFM
Subcontract
SRTM
(SOW & Spec)



S/C WBS


Work Package




The RFM, in turn, drives all the remaining blocks in the diagram, including the
Subcontract Requirements Flow-down Matrix (SRFM). The Customer Require-
ment (SOW and Spec) also drives the WBS terminating in the lowest level of
the WBS, the Work Package. In this diagram, the Work Package is divided in
half. That division represents an internal Work Package on top and a subcon-
tract or purchased item on the bottom. This representation is for presentation
purposes only. In a real WBS, Work Packages are physically separated from
subcontract packages. All of these elements contribute to the overall product.
A subcontract and possibly a purchase order will continue to be divided
BLUEPRINT FOR PROJECT RECOVERY
6


down in the same manner as the prime contract structure. The RTM keeps
track of everything that is going on throughout the project. The ¬‚ow of the
requirements and the documentation are downward. The work and product
obviously ¬‚ow in an upward direction.
Most projects or programs are planned by the Program Of¬ce from the top
down. Cost and schedule are allocated to the organizational elements to make
the project ¬t an overall cost/schedule envelope. Conversely, most projects are
built from the bottom up by the operating organizations. The two approaches
meet at the Work Package, and it is at this point where the shuf¬‚ing and negoti-
ation and, yes, ˜˜the weeping and gnashing of teeth,™™ begin. At the Work Pack-
ages you can realize and calculate the risk level inherent in each Work Package
and, by summary, in the overall project. As project manager, you may need to
˜˜task™™ (some call it ˜˜challenge™™) the Work Package Leaders to make the entire
project ¬t into the proverbial ¬ve-pound bag. Tasking involves recognizing that
the time or budget allocated (downward) is not what has been requested (up-
ward). Whether or not it is suf¬cient is the basis of tasking. So, as project man-
ager, you task the leader of the performing organization to accomplish the as-
signed task within the budget or schedule (or both) that you have allocated. It
must be understood that tasking involves risk. Here is where your Risk Mitiga-
tion Plan (see Attachment 3) comes in, but how you handle this part of the
project is pretty much up to you. The amount of work and negotiation that is
necessary here will be, in great part, dependent on how this was handled during
the Project Planning Phase.
This is, as they say, ˜˜where the rubber meets the road.™™ All the schedule
elements, the cost elements, and the quality factors must be applied to the Work
Package. In order to determine whether the project is working properly, you
must use measurements and apply them to goals in order to create metrics.
Now you have a project or program that has the controls you need in order to
make it work. If a Work Package is derailed, the project is derailed, so this is
the point where you must not only monitor the project but the point at which
you must control the project as well. Yes, the $500,000 project as well as the
$500,000,000 program must be controlled at this level.
Accomplishment and reporting are assigned to an organizational element.
Progress is monitored by the Program Of¬ce according to the metrics that have
been established for each Work Package.
Using the tools shown above, you run and monitor the project throughout
its lifecycle. There is periodic feedback from performance to requirement and
frequent change from requirement to performance. With all of this going on,
you can see how easily something can get derailed.
GETTING STARTED 7


1.2 Requirements

In the last ten years or so, the absoluteness of requirements has been set aside.
This is particularly true in the software world. The reasons requirements have
softened are several. First, the demands of the marketplace have insisted that we
bring a product to market before our competition”the mantra of the 1980s
and 1990s was ˜˜greed and speed.™™ This has meant eliminating the front end of
many projects to try to get a jump on the competition. The pace of the market-
place demanded so-called ˜˜rapid prototyping™™ to get there ¬rst. Second, elimi-
nating hard requirements allowed more latitude in developing new and differ-
ent products. Products that were, in some cases, not even envisioned at the
outset of the project evolved or appeared during the process. Finally, the culture
of ˜˜generation X™™ created a ˜˜Leave me alone and let me do my own thing™™
attitude. The results? Some miraculous strides in progress, particularly software,
and some colossal failures. The analysis? The less control, the greater the art,
but the greater the risk. We are now at a point where we are trying to ¬gure out
how to lower the risk and still have the grand advances. I™m not sure we™ve
¬gured all that out quite yet, but that™s a big reason for this book. With all the
failures we™ve suffered, we need some ways to try to prevent the failures and to
recover when we do fail.
It appears a compromise is needed in the de¬nition and how it is applied.
For those projects you consider artful or creative in nature, how about at least
establishing a charter at the outset to guide the project and establish some
boundaries. If the project begins to falter, use the concepts of this book to back
up and rede¬ne those parts of the project that are going wrong. This will be-
come an iterative process. It won™t solve all the problems, but it will capture the
best of each process and allow maximum advances. Whenever you go back,
document the change, and update the charter to include your new ¬ndings. Tie
`
these elements together and voila! You have a crude requirements document.
Now that you have more visibility, use the opportunity to try to extend to the
next failing and shortstop it as well. This thing we have established as the charter
now takes the place of the requirements document (contract), and you can read
the following cause descriptions with that in mind.

1.3 The Search Methodology

Before we get to the Search Tables, let™s look at the search methodology that is
applicable to all the Search Tables in Chapters 2, 3, 4, and 5. The reason for this
BLUEPRINT FOR PROJECT RECOVERY
8


methodology will become clear when we get to ˜˜How To Use The Compact
Disk (CD).™™ The purpose of Chapters 2 and 3 is to act as a checklist for planning
and checking a project, and the purpose of Chapters 4 and 5 is to get a derailed
project back on track.
In Chapters 2 and 3, read the assertions in order. If necessary, go to the
page number shown under the ˜˜Explain™™ column to get a broader and deeper
understanding of the assertion. If and when you can answer YES to the asser-
tion, proceed to the next assertion. In this way you can evaluate the plans you
have developed for your project either before the project is launched or while it
is running. Be critical of each assertion.
In Chapters 4 and 5 again, read the assertions in numerical order. This time,
however, you are looking for something that has failed on the project. In other
words, you answer YES or NO to the assertion, as appropriate. If and when you
can answer YES to the assertion, proceed to the next assertion. If your answer
is NO, go to the page number listed in the Search Table under that assertion to
¬nd an explanation of the issue and a recovery plan to assist you in getting your
project back on track.
There are eleven Categories of Causes containing thirty-nine assertions
within the Programmatic Tables and twelve Categories of Causes containing
forty-three assertions within the Technical Tables.
After a category of causes has been identi¬ed, the search changes to looking
for the speci¬c cause. The primary number of a cause is directly related to a
category of causes. For instance Cause Group 1 relates to the SOW, and Cause
Group 51 relates to the Architecture and so on. Each group is subdivided and
identi¬ed by a letter.
Do not assume that, just because you are in the design phase, the problem
itself is in the design phase. As you might suspect, problems that occur early in
the project, such as misinterpreting the SOW or speci¬cation, do not show up
until much later. Most problems or issues are not straightforward, and many
require extensive digging and analysis. That™s why you should always start at
the beginning of each checklist, and that™s why these checklists are so useful.
Now you should be ready to start using the Search Tables and, later, the
interactive CD.
CHAPTER 2




CHECKING PROGRAMMATIC
PERFORMANCE


2.1 General

Checking programmatic performance is fundamental to a smooth-running
project. The best time to accomplish this task, of course, is when you are plan-
ning the project; however, you can check your project performance at any time
by using the checklist presented here.

2.2 Programmatic Performance Checklist

Table 2-1 is the Programmatic Performance Checklist. Use this table to check
the content of your plans and processes when planning the project or to con¬rm
the Project Plan when the project is running. The Programmatic Recovery
Checklist is presented in Chapter 4 of this book.
9




.......................... 9758$$ $CH2 12-09-02 08:29:36 PS
BLUEPRINT FOR PROJECT RECOVERY
10


With your project in mind and starting at 1a, read each assertion in the table.
If you can answer YES to the assertion with respect to your project, check it off
and proceed to the next one. If you need an explanation of the assertion, go to
the page number listed under the ˜˜Explain™™ column for that assertion. If your
answer is NO, you need to go to Chapter 4 and look in the Programmatic
Recovery Tables using the same reference number.

2.3 Programmatic Explanations

Each assertion listed in the Programmatic Performance Checklist, shown in
Table 2-1, is supported by a Cause Description. In the case of the Performance
Checklist, the support is to broaden and deepen the understanding of the asser-
tion. Following are explanations of the assertions found in the Programmatic
Performance Checklist.

1 STATEMENT OF WORK (SOW)
1a The SOW was properly de¬ned.
An SOW is properly de¬ned when it fully describes the products or services
to be delivered and states when and where they are to be delivered. Each product
or service (sometimes called Contract Line Item Numbers or CLINs) must be
separately listed. Additionally, the following documents should be referenced
but are usually not included:

’ Task Description
’ Deliverable Documents List (sometimes called Contract Data Require-
ments List or CDRL)
’ Period of Performance
’ Schedule
’ Reference Documents (referenced but not included)
’ Modifying Factors (for example, the number of labor hours of speci¬c
disciplines that must be provided)
’ Speci¬cation
’ Financial Information (usually referenced but not included in SOW)

Any item in or referenced by the SOW is a legal part of the SOW. Therefore,
each of these items must be understood. It is a good idea to search the entire
CHECKING PROGRAMMATIC PERFORMANCE 11


Ta b l e 2 - 1 ” P r o g r a m m a t i c P e r f o r m a n c e C h e c k l i s t

1 STATEMENT OF WORK (SOW) Explain Yes
1a The SOW was properly de¬ned 10
1b The SOW is within our capabilties 12
1c The SOW was propertly interpreted 13
1d The SOW was properly negotiated 14
1e The SOW is properly monitored 15
1f The SOW is being properly performed 16
2 SPECIFICATION Explain Yes
2a The Speci¬cation was properly de¬ned 17
2b The Speci¬cation is within our capabilities 18
2c The Speci¬cation was properly interpreted 20
2d The Speci¬cation was properly negotiated 20
2e The Speci¬cation was properly monitored 21
2f The Speci¬cation is being properly performed 22
3 POLICIES, PLANS, AND PROCESSES Explain Yes
3a There is a clear trail between standard policies and plans and the 23
Project/Program Plan and Technical Plan
3b There is a clear trail between customer policies and plans and the 23
Project/Program Plan and Technical Plan
3c There is a clear trail between enterprise policies and plans and the 24
Project/Program Plan and Technical Plan
4 ORGANIZATION Explain Yes
4a The numbers of personnel assigned to each task are correct 25
4b The mix of personnel to accomplish the task is appropriate 26
4c The personnel are acting and reacting as a team 26
5 TEAMING, ALLIANCES, AND SUBCONTRACTS Explain Yes
5a The subcontracts were properly de¬ned 26
5b The subcontract tasks are within the capabilities of each team 28
member, partner, or subcontractor
5c The subcontracts were properly negotiated 28
5d The subcontracts are properly monitored 29
5e Team members, partners, and subcontractors are performing 29
properly
6 MATERIALS Explain Yes
6a Purchase Orders were properly written 30
(continues)
BLUEPRINT FOR PROJECT RECOVERY
12


Ta b l e 2 - 1 ” ( C o n t i n u e d )

6b All vendors are competent to perform their tasks 31
6c Purchase Orders are properly monitored 31
6d Vendors are performing properly 33
7 PERSONNEL Explain Yes
7a Each person is competent to perform the tasks assigned 33
7b Each person is available when needed 34
7c Salaries/wages are equal to or less than those bid 34
7d Interpersonal con¬‚icts do not exist 34
8 TRAINING Explain Yes
8a All personnel have been adequately trained 35
8b The training program is economical 35
9 DATA MANAGEMENT Explain Yes
9a The proper amount of data is being delivered on time 35
10 QUALITY Explain Yes
10a The Quality Plan is thorough, complete, and authorized 36
10b Speci¬c quality characteristics were identi¬ed that are important to 36
the project
10c Quality is measured so that improvement or degradation is clear 36
11 FINAL DELIVERY Explain Yes
11a Final delivery was accepted by the customer without delay 36
11b Third-party or drop shipping is not involved 37




SOW and ¬nd all the requirements and the modi¬ers and group them together
for your own purposes.
A properly de¬ned SOW will contain (either incorporated or appended) the
¬ndings of the requirements discussions (negotiations). These ¬ndings are as
much a part of the requirements document (contract) as the initial document.

ADDITIONAL RESOURCES:

MIL-STD-245 (see glossary)

1b The SOW is within our capabilities.
CHECKING PROGRAMMATIC PERFORMANCE 13


You can make a quick assessment of your ability to perform the task by using
the Experience Window in Table 2-2. Ask yourself the customer and product
questions and then compare your answers to the answers and capabilities shown
in the table.
Ta b l e 2 - 2 ” E x p e r i e n c e W i n d o w

Have Customer Have Product Capability to
Condition Experience Experience Perform
1 Yes Yes High
2 No Yes Moderate
3 Yes No Low
4 No No Unknown


That™s not the end of it, however. Just having customer experience and prod-
uct experience is not enough; it must be positive experience. If you have had
experience with this customer, but it was not positive experience, you must
Y
neutralize the negative effects. If you do not do this, your ability to perform (or
FL
win) is in doubt. The same is true of product experience. If you have negative
experience with a product, you are in the same boat. If either your customer
experience or your product experience is negative, it is likely you will move
AM


downward at least two conditions on the chart. In other words, if you have
good product experience but bad customer experience, you no longer have a
high ability to perform. It is likely you now have a low to unknown ability to
TE




perform. Generally speaking, negative experience is worse than no experience.
In addition to satisfying the conditions of the table and the extra conditions,
you must:

’ Provide the personnel required to perform the task.
’ Provide the facilities required by the task.
’ Provide the ¬nances required by the payment schedule to support the
task.
’ Perform the requirements of the Speci¬cation (as evaluated under Cause
Description 2e).
1c The SOW was properly interpreted.
An SOW is properly interpreted when it is fully de¬ned and when you fully
understand the products or services to be delivered and the conditions sur-
rounding the deliveries.
BLUEPRINT FOR PROJECT RECOVERY
14

An SOW is properly de¬ned when it fully describes the products or services
to be delivered and when and where they are to be delivered. Each product
or service (sometimes called Contract Line Item Numbers or CLINs) must be
separately listed. Additionally, the following documents should be referenced,
but are usually not included:

’ Task Description
’ Deliverable Documents List (sometimes called Contract Data Require-
ments List or CDRL)
’ Period of Performance
’ Schedule
’ Reference Documents (referenced but not included)
’ Modifying Factors (for example, the number of labor hours of speci¬c
disciplines that must be provided)
’ Speci¬cation
’ Financial Information (usually referenced but not included in the SOW)

Any item in or referenced by the SOW is a legal part of the SOW in a program
and an ethical part of the SOW in both a program and a project. Therefore,
each of these items must be understood. It is a good idea to search the entire
SOW and ¬nd all the requirements and the modi¬ers and group them together
for your own purposes.
To ensure you fully understand the SOW, you should:

’ Meet with the customer and use the content listing above as a guide for
your meeting. Ensure every item is covered.
’ Go through each paragraph of the SOW that is or might be in question.
’ Come to an understanding with the customer as to exactly what is wanted.
’ Come to an understanding with the customer on how recovery can be
made.

You should have the project manager and the technical manager on the pro-
posal team and the requirements de¬nition (negotiation) team.

1d The SOW was properly negotiated.
A properly negotiated SOW is one that has a balance between all its elements,
is complete, and for which:




.......................... 9758$$ $CH2 12-09-02 08:29:39 PS
CHECKING PROGRAMMATIC PERFORMANCE 15

’ The amount of money to be paid is adequate to complete the task.
’ The time allowed is adequate to complete the task.
’ The requirements de¬nition (negotiation) minutes are documented and
signed by both parties.

Again, follow the procedure outlined under Cause Description 1c above.
It is the responsibility of the requirements de¬nition (negotiation) team to
ensure that this balance exists and that minutes are taken and con¬rmed. One
of the best ways to ensure balance is to require that the project manager be on
the requirements de¬nition (negotiation) team. The project manager will en-
sure there is a balance or will suffer the consequences.
And now, to be mugged by reality! Sometimes a strategic decision is made
by the company to accept a task at a price less than it will actually cost; this is
commonly called ˜˜buying in™™ (see glossary). In that event you must negotiate
your position with your management to understand who will take the ˜˜hit.™™
Get that understanding in writing!

1e The SOW is properly monitored.

The SOW is properly monitored when the work being performed is being
monitored by lead technical and program personnel using accepted monitoring
techniques such as:

’ Schedule Reviews
’ Budget Reviews
’ Design Reviews
’ Technical Interchange Meetings
’ Team Meetings
’ In-Process Reviews
’ Project Reviews
’ Customer Meetings

See the glossary for an expanded explanation of each of these meetings or
reviews. Due to the variability of projects, the content of these meetings and
reviews must be your own.
These interchanges must be conducted at frequent intervals. The lower the
position in the hierarchy, the more frequent the interchange needs to be. In




.......................... 9758$$ $CH2 12-09-02 08:29:39 PS
BLUEPRINT FOR PROJECT RECOVERY
16


other words, Team Meetings should be held more often than Project Reviews,
and Project Reviews should be held more often than Customer Meetings, and
so forth.
Just because the SOW is being properly monitored does not necessarily mean
the program is running properly; it only means that it is being monitored prop-
erly. The point is that if the program is not being monitored properly, you will
not know it until it is too late.
These meetings and reviews pervade the entire process, as Table 2-3 shows.

Ta b l e 2 - 3 ” M e e t i n g s a n d R e v i e w s

Review or Meeting Cause Description Appearance
Schedule Reviews 1f, 5e, 6d
Budget Reviews 1f, 5e
Design Reviews 11a, 51e, 52a, 53
Technical Interchange Meetings 1f, 5d, 5e, 6d
Subcontractor Meetings 5d, 5e
In-Process Reviews 5d
Customer Meetings 5d, 5e


The reviews must have metrics established to indicate if each event is in
tolerance or out-of-tolerance. The content of each of the reviews must be appro-
priate for that review.

1f The SOW is being properly performed.

The SOW is being properly performed when the Design Reviews, the In-
Process Reviews, the status meetings, the schedule, and the actual production
of the product is on schedule, within budget, and is being produced in accor-
dance with the Speci¬cation. These factors should be evident in such reviews
as:

’ Schedule Reviews
’ Budget Reviews
’ Design Reviews
’ Technical Interchange Meetings
’ Team Meetings
CHECKING PROGRAMMATIC PERFORMANCE 17


’ In-Process Reviews
’ Project Reviews


See the glossary for an expanded explanation of each of these meetings or
reviews. Due to the variability of projects, the content of these meetings and
reviews must be your own.
The reviews must have metrics established to indicate whether each event is
in tolerance or out-of-tolerance.

2 SPECIFICATION

2a The Speci¬cation was properly de¬ned.

The proof, as they say, is in the pudding. Can you understand exactly what
the customer wants? Is it testable and is it provable? If you can answer YES
to both those questions, the Speci¬cation is properly de¬ned. A well-de¬ned
Speci¬cation contains at least the following topics:


’ Scope of the Document
’ Applicable Documents
’ Requirements
’ Item De¬nition
’ Performance Characteristics
• The performance requirements related to manning, operating, main-
taining, and logistically supporting the prime item to the extent these
requirements de¬ne or constrain design of the prime item and include
response time, throughput rates, and exclusion times
’ Physical Characteristics
• The design constraints and standards necessary to assure compatibility
of prime item components
’ The electrical, mechanical, functional, and other interfaces between the
principal item being speci¬ed and other items with which it must be com-
patible
’ The major components of the principal item and the primary interfaces
between such major components
BLUEPRINT FOR PROJECT RECOVERY
18


’ Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)
’ Process Requirements, if needed
’ Materials Requirements, if needed

There are several types of Speci¬cations. MIL-STD-490 has established and
de¬ned ¬ve different Speci¬cation (Spec) types as well as a number of subtypes.
The standard provides a great deal of good information regarding the content
and purpose of each Speci¬cation type. The Speci¬cation types are shown in
Table 2-4.
Ta b l e 2 - 4 ” S p e c i f i c a t i o n Ty p e s

Type Speci¬cation
A System/Subsystem/Segment
B Development
B1 Prime Item
B2 Critical Item
B3 Noncomplex Item
B4 Facility of Ship
B5 Software
C Product
C1a Prime Item Function
C1b Prime Item Fabrication
C2a Critical Item Function
C2b Critical Item Fabrication
C3 Noncomplex Item Fabrication
C4 Inventory Item
C5 Software
D Process
E Material




2b The Speci¬cation is within our capabilities.
A quick assessment can be made of your capabilities to perform by using the
Experience Window in Table 2-5.
CHECKING PROGRAMMATIC PERFORMANCE 19


Ta b l e 2 - 5 ” E x p e r i e n c e W i n d o w

Have Customer Have Product Capability to
Condition Experience Experience Perform
1 Yes Yes High
2 No Yes Moderate
3 Yes No Low
4 No No Unknown



In addition to satisfying the conditions of the table above, you must:

’ Provide the personnel required to perform the task.
’ Provide the facilities required by the task.
’ Provide the ¬nances required by the payment schedule to support the
task.
’ Perform the requirements of the Speci¬cation.

The Speci¬cation is within your capabilities if you have previously estab-
lished credentials in performing each requirement.
In order to ¬ll in the ˜˜Have Product Experience™™ column in Table 2-5 prop-
erly, you may need to construct a matrix similar to the one shown in Table
2-6. The matrix lists all the requirements or tasks along the side and the programs
(including Independent Research and Development (IR&D) programs) that the
company has performed across the top. Every requirement or task should have
an ˜˜X™™ at the intersection between the task and at least one program.

Ta b l e 2 - 6 ” Ta s k Q u a l i f i c a t i o n

Project A Project B Project C Project D Project E
Task 1 X
Task 2 X X
Task 3 X
Task 4 X
Task 5 X X
Task 6
BLUEPRINT FOR PROJECT RECOVERY
20


If you do not have the requisite quali¬cations and thus cannot enter an ˜˜X™™
into the intersect, continue with the process to bring your capabilities up to
the requirements of the Speci¬cation. Refer to Cause Description 2b (NO) for
recovery.

2c The Speci¬cation was properly interpreted.
A Speci¬cation is properly interpreted when you fully understand the prod-
ucts or services to be delivered. Each product or service must be fully described
in the Speci¬cation.
At a minimum, the Speci¬cation should contain:

’ Scope of the Document
’ Applicable Documents
’ Requirements
’ Item De¬nition
’ Performance Characteristics
• The performance requirements related to manning, operating, main-
taining, and logistically supporting the prime item to the extent these
requirements de¬ne or constrain design of the prime item and include
response time, throughput rates, and exclusion times
’ Physical Characteristics
• The design constraints and standards necessary to assure compatibility
of prime item components
’ The electrical, mechanical, functional, and other interfaces between the
principal item being speci¬ed and other items with which it must be com-
patible
’ The major components of the principal item and the primary interfaces
between such major components
’ Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)
’ Process Requirements, if needed
’ Materials Requirements, if needed

2d The Speci¬cation was properly negotiated.
The Speci¬cation was properly negotiated if there is a thorough understand-
ing and agreement on the part of both parties as to what constitutes the scope,
CHECKING PROGRAMMATIC PERFORMANCE 21


the schedule, and the budget. A well-de¬ned Speci¬cation contains at least the
following topics:

’ Scope of the Document
’ Applicable Documents
’ Requirements
’ Item De¬nition
’ Performance Characteristics
• The performance requirements related to manning, operating, main-
taining, and logistically supporting the prime item to the extent these
requirements de¬ne or constrain design of the prime item and include
response time, throughput rates, and exclusion times
’ Physical Characteristics
• The design constraints and standards necessary to assure compatibility
of prime item components
’ The electrical, mechanical, functional, and other interfaces between the
principal item being speci¬ed and other items with which it must be com-
patible.
’ The major components of the principal item and the primary interfaces
between such major components
’ Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)
’ Process Requirements, if needed
’ Materials Requirements, if needed

The negotiator must keep thorough and complete minutes regarding all
changes to the Speci¬cation and these changes must be covered by both schedule
and budget considerations. The minutes will have been signed by both parties
of the negotiation. Later these minutes will be incorporated into the Speci¬ca-
tion as changes.

2e The Speci¬cation was properly monitored.

A Speci¬cation that is properly monitored is one that is under constant and
complete control and has a change process that controls all changes made to
the baseline.
BLUEPRINT FOR PROJECT RECOVERY
22


One of the ¬rst things to be done in the Planning Phase is to develop a
Requirements Traceability Matrix (RTM). You should have one RTM for the
programmatics (SOW) and one for the product (Speci¬cation). Once you know
where the requirement is being satis¬ed, it should be reasonably easy to assign
a person to monitor the performance. The content of the RTM should follow a
requirement from beginning to end. An example of such a document is shown
in Table 2-7.

Ta b l e 2 - 7 ” R e q u i r e m e n t s Tr a c e a b i l i t y M a t r i x ( R T M )

Unit System
SOW/ WBS S/C SOW/ Test Test
Spec Para Requirement Number Spec Para Number Para Monitor
SOW
4.3.1 Security 06-03-02 N/A T-0304 4.4.1 Smith


Spec
3.2.1 System weight 02-04-03 3.4.6 T-0045 3.4.1 Jones
shall be less
than 10,000
pounds




In this case, an additional column should be added for the name of the
monitor.
For additional information, see Attachment 7.

. 1
( 9)



>>