1.1 General
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118
119 120 121 122 123
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.