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.

Work

Package

Work

Package

Work

Package

Work

Package

Work

Package

Work

Package

Dept A

Dept B

Dept C

Dept D

Requirements

Cost

Metric

Condition

Measurement

Goal

Schedule

Metric

Condition

Measurement

Goal

Quality

Metric

Condition

Measurement

Goal

Implementation

Documentation

Methodologies

Procurement Test

Fabrication

Design

Closure

WBS

Customer

Requirement

(SOW & Spec)

WBS

Subcontract

(SOW & Spec)

RTM RFM

S/C WBS

Work Package

SRTM SRFM

Work Package

Subcontract

Purch. Order

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.