Cagle R.B. - Blueprint for Project Recovery[c] A Project Management Guide (2003)(en)

This Page Intentionally Left Blank

		Y
	L
	F
	M
A
E
T

TABLES

Table 2-1	Programmatic Performance Checklist	11
Table 2-2	Experience Window	13
Table 2-3	Meetings and Reviews	16
Table 2-4	Specification Types	18
Table 2-5	Experience Window	19
Table 2-6	Task Qualification	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 Qualification	62
Table 4-4	Meetings and Reviews	66
Table 4-5	Task Qualification	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 Qualification	86
Table 4-14	Meetings and Reviews	90

xi

xii		T A B L E S
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	Affinity 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	Specification 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 combination 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 consolidated view into what all businesses, large, small, government, and commercial, are doing.

xiii

xiv	P R E F A C E

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 meaning for you. It uses many federal policies, plans, processes, and standards as references. It uses these references for two reasons: first, 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 specific business area or your specific 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 difficult 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 flames 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 flames 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 resurrection 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 first 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 recovery 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

P R E F A C E

xv

and methodologies for expanding the provided database and tailoring it to your specific 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

C H A P T E R 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 experienced a failure in some part of your project, you are in the right place.

To begin, let’s set the baseline by establishing some definitions. You may or may not agree with all the definitions, 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 definition, 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 ramifications between the enterprise and the customer. (See Figure 1-1.) The discriminator is the legal document or contract. Stated in another way, a program manager has Profit 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

2					B L U E P R I N T F O R P R O J E C T R E C O V E R Y
F i g u r e 1 - 1 — P r o j e c t / P r o g r a m E n v i r o n m e n t
		Contract
							Enterprise
Customer
						Program

Requirement

Customer

Project

Enterprise

set than a project manager. Some people like to define 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 Offices (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 understand why I have a lot of trouble with that definition.

For simplicity, I intend to use the term ‘‘project’’ throughout this book except in those cases where the term ‘‘program’’ is called for under this definition.

The second definition 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.