Final thought on the Critical Process approach
In summary, the critical process approach has many benefits; however, the critical processes normally are not directly related to the individual WBS product elements comprising the weapon system being developed and produced.
The Product (Work Breakdown Structure) Approach
DoD 5000.2-R requires that DoD programs tailor a program Work Breakdown Structure (WBS) for each program using the guidance in MIL-HDBK-881, "Work Breakdown Structure," of 2 January 1998. MIL-HDBK-881 defines the WBS as:
"… a product oriented family tree composed of hardware, software, services,
data and facilities which results from systems engineering efforts during the
acquisition of a defense material item. A WBS displays and defines the
product(s) to be developed and/or produced and relates the [WBS] elements
of work to be accomplished to each other and to the end product(s)."
Functional processes are not WBS elements
A sound WBS clearly describes what the program manager wants to acquire. It has a logical structure and is tailored to a particular defense materiel item. As stated in MIL-HDBK-881, the WBS is product oriented. It addresses the products required, NOT the functional processes or costs associated with those products. For example, subjects, such as design engineering, requirements analysis, test engineering, etc. are not products. Rather, they are functional processes, each representing a discrete series of actions, with specific objectives, during product development and/or production. These are normally not identified as MIL-HDBK-881 WBS elements and as a result, generally do not receive adequate program consideration.
Section 2 of MIL-HDBK-881 states that the WBS provides a framework for specifying the technical objectives of the program by first defining the program in terms of hierarchically related, product oriented elements and the work processes required for their completion. Therefore, the emphasis on "product" is to define the product(s) to be developed and/or produced, and to relate the elements of work to be accomplished to each other and to the end product(s). Unfortunately, in this approach, programs frequently place little emphasis on "process."
WBS Tends To Be An After-The-Fact Measure Of Risk
A typical WBS technical risk management approach is based on the WBS products. Risk assessments and mitigation activities are conducted primarily on the individual WBS elements, with an emphasis on technology, product maturity or perceived quality, with little emphasis on related processes. Risk is typically expressed as a probability estimate rather than as a degree of process variance from a best practice. In the WBS approach, technical risks are identified, assessed, and tracked for individual WBS elements identified at their respective levels, primarily for impact on cost and schedule, and the resulting effect on the overall product. Since DoD programs are established around the WBS, the associated costs and schedule for each product can be readily baselined, against which risk can be measured as a deviation against cost and schedule performance. Taking the WBS to successively lower level entities will help to assure that all required products are identified in terms of cost and schedule performance (as well as operational performance) goals. In general, a typical WBS approach tends to be more reactive than proactive. Although a direct measurement of product performance against cost and schedule performance has its benefits, there are also some significant downsides to an approach in which processes are not considered. The WBS, by virtue of its inherent organizational properties, produces technical performance measurements that are, in essence, after-the-fact measures of risk. Also, by not focusing on processes, the overall risk to the program may not be identified until the program is in jeopardy.
As stated in DoD 5000.2-R, the WBS provides a framework for program and technical planning, cost estimating, resource allocations, performance measurements, and status reporting. Whereas the WBS is a good tool for measuring technical performance against cost and schedule, it is an incomplete measure of technical risk without considering processes. It is important to recognize that the WBS is a product of the systems engineering process, which emphasizes both product and process solutions required for the completion of technical objectives. However, history indicates that until recently, "process" solutions received too little emphasis.
The Integrated Process/Product Approach
The Integrated Process/Product approach to technical risk management is derived primarily from the Critical Process approach and incorporates some facets of the Product/WBS approach. The systems engineering function takes the lead in system development throughout any system’s life cycle. The purpose of systems engineering is to define and design process and product solutions in terms of design, test and manufacturing requirements. The work breakdown structure provides a framework for specifying the technical objectives of the program by first defining the program in terms of hierarchically related, product oriented elements and the work processes required for their completion.
This emphasis on systems engineering, including processes and technical risk, along with process and product solutions, validates and supports the importance of focusing on controlling the processes, especially the prime contractor and subcontractors critical processes. Such a focus is necessary to encourage a proactive risk management program, one that acknowledges the importance of understanding and controlling the critical processes especially during the initial phases of product design and manufacture.
Integrates The Best Aspects of Both Approaches
In summary, the Critical Process Approach provides a proactive concentration on technical "drivers" and associated technical risks as measured by process variance. Integrating this approach into the Product Approach enables the critical processes to be directly related to the products comprising the weapon system being developed and produced. In this manner, the benefits of both approaches are realized. Product maturity is accelerated, technical risk is reduced, CAIV objectives are more easily met, schedule slippages are avoided, and the Program Manager reaches Milestone decision points with a higher level of confidence. See Table 1-1 for an overview of the advantages and disadvantages of all three approaches.
Table 1-1. -- Comparison of Approaches
Proactive focus on critical processes
Encourages market search for best practices & benchmarks
Reliance on fundamental design, test and manufacturing principles
Addresses pervasive and subtle sources of risk
Technical discipline will pay dividends in cost and schedule benefits
Less emphasis on the product oriented elements of a program
Perception that technical issues dilute the importance of cost and schedule|
Commonly accepted approach using a logical, product oriented structure
Relates the elements of work to be accomplished to each other and to the end product
Separates a defense materiel item into its component parts
Allows tracking of product items down to any level of interest
Does not typically emphasize critical design and manufacturing processes, or product cost
Risk is typically expressed as a probability estimate rather than a process variance
Delayed problem identification (reactive)|
Integrated Process / Product
Maximizes the advantages of Process and Product approaches