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

1.1General

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

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

WBS

Work Package

Subcontract

Purch. Order

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

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.

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.