The D e fin e P has e 167

Project Decomposition Large projects must be broken down into smaller projects and, in turn, into specific work elements and tasks. The process of going from project objectives to tasks is called decomposition. The result of decomposition is the project scope: the particular area of interest and focus for the project, in process terms.

Work Breakdown Structures Ruskin and Estes (1995) offer work breakdown structures (WBS) as a process for defining the final and intermediate products of a project and their relationships. Defining project tasks is typically complex and accomplished by a series of decompositions followed by a series of aggregations. For example, a software project to develop an SPC software appli­cation would disaggregate the customer requirements into very specific analytic require­ments (e.g., the customer 's requirement that the product create X-bar charts would be decomposed into analytic requirements such as subroutines for computing subgroup means and ranges, plotting data points, drawing lines, etc.). Aggregation would involve linking the various modules to produce an X-bar chart displayed on the screen.

The WBS can be represented in a tree diagram, as shown in Fig. 6.2. Tree diagrams are used to break down or stratify ideas in progressively greater detail. The objective is to partition a big idea or problem into its smaller components, to reach a level where projects are "tiny." By doing this, you will make the idea easier to understand, or the problem easier to solve. The basic idea is that, at some level, a problem's solution becomes relatively easy to find, or is isolated enough in scope as to be simpler than other solutions necessary to satisfy all possible conditions. This is the tiny level. Work takes place on the smallest elements in the tree diagram.

For example, an order processing project team for a software sales and training firm decomposed the order processing tasks based on Software or Professional Service; then by product family (e.g. Product Family A, Product Family B, Product Family C), then by the type of sale within that family (Download, Shipment, Support Renewal) . The break­down allows the team to then further consider which of these somewhat unique ele­ments should be considered for improvement.

While the WBS provides a graphical view of the potential project elements, it pro­vides no insight into the relative benefits to be obtained in improving a given element. Here, a Pareto analysis is often helpful. Pareto diagrams are useful in the Define, Mea­sure and Analyze stages to focus project resources on the areas, defects, or causes yield­ing the highest return.

Pareto Analysis A Pareto diagram is a vertical bar graph showing problems (or perhaps more directly opportunities) in a prioritized order, so it can be determined which problems or oppor­tunities should be tackled first. The categories for the vertical bars represent mutually exclusive categories of interest. The categories are sorted in decreasing order from left to right in the Pareto diagram by their count or cost, whichever is being displayed.

In the Define phase, the Pareto diagram is used in conjunction with the WBS to quantify the opportunities inherent in each of the tiny elements resulting from the WBS.

For example, the data in Table 6.1 have been recorded for orders received in the Order Processing function considered in the WBS.

168 C hap te r Six

Downloads

Pro duct Fam ily A Shipped

Support Renewals

/"'~ ~" ".'--''' ''''''''' Downloads ! ..

~:::=<_' _p_rO_d_Uel_,_F3_m_i_

l

v_

B

..... , ",, ___ ::_:_:_:rt_d_R_en~, ewals

~.- ~ Downloads

Product FamilyC Shipped

Support Renewals

On-site

Product Family A

Web-ba~ed

On-sfte

Online

Web·based

On~ite

Product Family C Online

Web-based

FIGURE 6.2 Example WBS for Order Processing project; constructed using Mind Genius software (www. qualityamerica.com by permission).

Product Family Download Shipment Support

A 27 3 30

B 33 5 8

C 13 5 0

TABLE 6.1 Raw Data for Pareto Analysis

The data in Table 6.1 is shown in a massaged format in Table 6.2, to demonstrate how it is analyzed for the Pareto diagram of Fig. 6.3. In this case, a "stacked" Pareto diagram is used to display the type of order that is processed: the bottom section of each bar represents Downloads; the middle section Shipments; and the top section Support Renewals.

The D e fin e P has e 169

... c = 0 ()

Rank Product Family Count Percentage

1 A 60 48.39

2 C 46 37.10

3 B 18 14.52

TABLE 6.2 Data Organized for Pareto Analysis

140

120

1010

80

6° 1 40

2:

Number Orders Downloaded; Shipped; Support Renewals

85%

60

4 6

18

< >-·e rtI

LI..

"C Q L. Q.

Cum %

48.39

85.49

100.01

FIGURE 6.3 Example Pareto diagram constructed using Green Belt XL software (www. qualityamerica.com by permission).

20

.w c: OJ Ll L. OJ Q.

Note that, as often happens, the final percentage is slightly different than 100%. This is due to round-off error and is nothing to worry about.

Deliverables Six Sigma projects focus on one or more of the following three critical deliverables: cost, quality, and schedule. Factors Critical to Cost (CTC) include parameters that impact work in progress, finished goods inventory, overhead, delivery, material and labor, even when the costs can be passed on to the customer. Critical to Quality (CTQ) factors are perhaps most familiar to operational personnel since they directly impact the