Blueprint for Project Recovery--A Project Management Guide

Ronald B. Cagle

• Publisher: AMACOM
• Year: 2003
• ISBN:
  9780814427040
• Topic: Desarrollo personal
• Subtopic: Finanzas personales

With the acceleration of technology and information, projects are becoming more complex, costly, and time-constrained -- and every year thousands of them get cancelled or end up costing significantly more than their original projections. Project and program managers are sorely in need of tools to help them avoid failure. Blueprint for Project Recovery provides readers with a proven, proceduralized methodology for identifying where and how projects went off course, and a defined plan of action to bring them back on track. Based on years of research and including a CD-ROM packed with all the forms, checklists and resources used in the text, the book gives readers an entire process for both evaluating and repairing projects gone off course, and guidance for planning them more effectively in the first place. The book is designed as an easy reference troubleshooting guide that readers can use immediately to solve all their project difficulties. Every project or program has exigencies that can cause problems with cost, schedule, or outcome. Blueprint for Project Recovery! is the ultimate antidote.

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

Figure 1-1 — Project/Program Environment

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.

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 requirements 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 process. 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 product tree.

The requirements document (contract) and the WBS are the initial and major contributors to the all-important Requirements Traceability Matrix (see Attachment 7).

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 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 requirement 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 Breakdown Structure (WBS), a Requirements Traceability Matrix (RTM), a Requirements 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 fits 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 first that the Customer Requirement, consisting of the Statement Of Work (SOW) and the Specification (Spec), drives the RTM to the left and the RFM to the right. The RFM, in turn, drives all the remaining blocks in the diagram, including the Subcontract Requirements Flow-down Matrix (SRFM). The Customer Requirement (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 subcontract 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.

Figure 1-2 — Project/Program Requirements Control Relationships

Figure 1-3 — Documentation Interrelationships

A subcontract and possibly a purchase order will continue to be divided down in the same manner as the prime contract structure. The RTM keeps track of everything that is going on throughout the project. The flow of the requirements and the documentation are downward. The work and product obviously flow in an upward direction.

Most projects or programs are planned by the Program Office from the top down. Cost and schedule are allocated to the organizational elements to make the project fit 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 shuffling and negotiation and, yes, “the weeping and gnashing of teeth,” begin. At the Work Packages 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 fit into the proverbial five-pound bag. Tasking involves recognizing that the time or budget allocated (downward) is not what has been requested (upward). Whether or not it is sufficient is the basis of tasking. So, as project manager, you task the leader of the performing organization to accomplish the assigned 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 Mitigation 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 Office 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.

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 marketplace demanded so-called “rapid prototyping” to get there first. Second, eliminating hard requirements allowed more latitude in developing new and different 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 figure out how to lower the risk and still have the grand advances. I’m not sure we’ve figured 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 definition 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 redefine those parts of the project that are going wrong. This will become 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 findings. Tie these elements together and voilà! 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 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 assertion, 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 find 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 identified, the search changes to looking for the specific 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 identified 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 specification, 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.

Table of contents

• Cover Page
• Title Page
• Copyright Page
• Table of Contents
• Figures
• Tables
• Preface
• Acknowledgments
• Chapter 1: Getting Started
• Chapter 2: Checking Programmatic Performance
• Chapter 3: Checking Technical Performance
• Chapter 4: Recovering from Programmatic Problems
• Chapter 5: Recovering from Technical Problems
• Chapter 6: Expanding the Cause Base for Your Project
• Chapter 7: Grouping the Causes for Action
• Chapter 8: Selecting the Best of the Best
• Chapter 9: Implementing the Tailored Changes
• Chapter 10: Concluding
• Chapter 11: Using the Compact Disk (CD)
• Summary
• Glossary
• Attachments
• Bibliography
• Index