| --The Grail Knight, Indiana Jones and the Last Crusade (1989) | ||
We choose our joys and sorrows long before we experience them. | ||
| --Kahlil Gibran, Sand and Foam (1926) | ||
Once you have defined the scope of your planned process improvement efforts, your next important decision is to pick an architectural representation: continuous or staged. In Chapter 5, we described the distinguishing features of staged and continuous models, including some basic information about how CMMI provides these two alternative representations in its integrated suite of model products.
Each of the two architectural representations can provide a solid foundation for process improvement. For some people, however, the preference for one representation is deeply rooted and emotionally charged: They may simply mistrust the other representation. For other people, the preference is based on habit and grounded in the source model to which they are accustomed. For most users, this preference will be developed (we hope) through a comprehensive understanding of the benefits (in their organization’s specific environment) provided by each representation. Perhaps this choice merits the use of a structured decision-making process and the application of the CMMI process area for Decision Analysis and Resolution. While members of each organization must explore this issue for themselves, this chapter highlights some important issues and considerations in making that decision.
This chapter is arranged so as to start you on the path to making the best decision for your organization. The first two sections address the representations individually and present (for undecided voters or independents) the salient arguments offered by the proponents of each representation. The third section brings these general considerations into the CMMI context.
Staged models have been used successfully and with proven results for many years. This fact heads the list of reasons for using staged models; indeed, it is a powerful argument. Like Washington, D.C., insiders, staged model users can claim, “Real Experience, Real Results.” The path from an immature organization to a mature one has been demonstrated repeatedly both in the past with the Software CMM and more recently with CMMI. Use of a staged representation of the model offers the following benefits:
An ability to manage processes across the organization
Good communication about process among employees
Improved accuracy of project estimates
Improved cost and quality control
The use of measurable data to guide problem analysis and improvement efforts
These results are made possible and supported by a process infrastructure that provides discipline and motivation for both project and organizational process improvement.
For an organization that is just beginning its journey to greater process maturity, a staged model provides a well-defined and proven path. First the organization’s personnel work at process areas that facilitate improved project management (ML 2), then they provide organization-wide process definition (ML 3), and finally they use the standardized process definitions to support quantitative analysis for improving (ML 4) and optimizing (ML 5) project results. By building the staging of the process areas into its architecture, this model offers a clear path for improvement that can be followed without a lot of discussion and debate.
Consider the analogy of a child who is told to clean his room. There are toys everywhere, with nary any floor to be seen. The child just looks at the problem. It seems so overwhelming that he doesn’t know where to start. If he is told to pick up the blocks, however, he can sort through the mess and put all of the blocks away. Next, he can be told to pick up the balls and put them away. This process continues until the room is tidy. The approach taken by the staged model is similar, in that the model architects (rather than the model users) decide on the best order for process improvement.
Having a single system for defining process maturity facilitates making improvements over time within an organization. The maturity levels are broadly understood, so that (proponents would argue) there is a single meaning (more or less) regarding what it means for the organization to be at ML 2, for example.[1]
For all of these reasons (and others), staged models have been used by organizations to achieve notable success in support of their efforts related to process improvement.
The concept of a continuous model for process improvement precedes the development of staged models. The writings of Philip Crosby, for example, define levels for improvement within individual areas.[2] In spite of this heritage, continuous process improvement models have been used less often than staged models, and no systematic data collection related to the business results of continuous model usage has taken place. Nonetheless, there is no shortage of proponents for the continuous approach, especially among systems engineers.
Proponents cite two fundamental reasons for using a continuous (as opposed to a staged) model: freedom and visibility. Unlike a staged model, which provides a single improvement path for all model users, a continuous model offers additional freedom for users, who can select the order for process improvement activities based on their organization’s specific business objectives.[3] With a continuous model, individual organizations or organizational groups have the option of defining organizational maturity and an ordering for the process areas which (they may believe) are a better fit for their unique business environment. They may wish to achieve given capability levels for the process areas in an alternative order, rather than accepting the constraints of the “one size fits all” philosophy advocated by proponents of the staged models.
Given that the capability level scale is defined for each process area, an appraisal based on a continuous model may provide increased visibility into process improvement strengths and weaknesses. This greater transparency derives from the way in which the results are reported, rather than the model content. Despite the unflattering portrayal of managers in the cartoon world of “Dilbert,” those with more detailed process data can make more informed decisions. For instance, a capability level profile that includes a separate rating for each individual process area could provide greater insight than a single maturity level number.[4] Even a manager who initially may prefer the simplicity of a single number could, in time, develop greater appreciation for the capability profile that only a continuous representation provides. In the end, managers may want both.
By providing more detailed insight that is tailored to the individual business environment, an organization can benefit from the following aspects of the continuous model:
The complete application of all generic practices in each process area
A clearer focus on risks that are specific to individual process areas
A structure that is more immediately compatible with ISO/IEC 15504
A structure that more easily facilitates the addition of new process areas with minimal effects on the existing model structure
For managers who have used and found benefit in having a single maturity level number, a continuous model can provide the same information. A “staging” is possible with any continuous model,. Fundamentally and simply, a staging comprises a set of rules of the following form: For an organization to be at maturity level x, it must achieve capability level y in process areas PA1, PA2, ..., PAn.[5] To produce a single maturity level number, the model need not have a staged architecture; it requires only an algorithm to produce the maturity rating based on a set of staging rules. As described in Section 5.3.3, CMMI includes an equivalent staging for users of the continuous representation.
For organizations that want or need a predefined path for process improvement, a staging mapped onto a continuous model provides the same guidance as a staged model. If some groups support different staging schemes, however, then model users must choose a path for process improvement; they will not be given the path.
Based on the considerations cited in the preceding sections for liking either a staged or continuous architectural representation, a decision to favor one or the other would seem to involve almost philosophical musings. On the one hand, all things being equal, having a single number rating score and a proven standard path for process improvement would seem to have many potential benefits. Many organizations would prefer to avoid the “anything goes” approach to process improvement that the continuous representation may seem (incorrectly) to engender. On the other hand, a rating profile may ultimately prove more useful than a single number.
Furthermore, recognizing the realities of different business environments may lead to multiple approaches to process improvement, all of which are equally valid.[6] Most of us would likely prefer to receive the benefits available on both sides. That is, it would be nice to have a relatively small number of choices in process improvement paths (one of which is the most common in any given business environment). Likewise, it would be nice to have clear recognition that one predefined path may not be appropriate for the entire world and all business environments. Finally, it would be nice to have a single number rating for some contexts and a rating profile for other contexts.
Both staged and continuous representations of CMMI certainly hold the promise of at least some benefits. A close examination reveals that the differences between the staged representation and the continuous representation are less pronounced in CMMI v1.2, and the representation choice is less polarized than is the case with the legacy models that are either staged or continuous, but not both.[7] In an effort to ensure that each representation would be just an alternative view of the same base model, both representations are now contained in a single published model version for each constellation, and the process areas in both representations are the same. The primary difference is that the generic goals residing at capability levels 1, 4, and 5 are not needed in the staged representation. The goals (the required items) are also the same. The specific practices (the expected items from individual process areas) are the same. The generic practices are the same for maturity level 2 and 3 generic goals. In an appraisal for maturity level 2, the process areas staged at maturity level 2 use the level 2 generic practices only. In an appraisal for maturity level 3 or higher, all process areas use the level 2 and 3 generic practices.
Because the two representations are so closely aligned, the reasons for preferring one over the other become more practical and less philosophical. Will your organization need less of a training effort with one representation than with the other owing to legacy issues? Is the staging that is integral to the staged architecture and provided in the equivalent staging for the continuous architecture the better one for your business environment? Does management need the detail provided by a capability profile? Questions such as these may not have easy answers, but they can be investigated across all organizational components that seek to develop an integrated process improvement strategy.
Because the two architectural representations in CMMI are not dramatically different, in some ways you cannot make a bad choice: The fundamentals are the same. Perhaps, in time, the use of CMMI will show that two distinct representations are not necessary at all.
[1] By having each process area reside at a specified maturity level and hence at a well-understood position in the path to organizational maturity, the model authors can create more uniform process areas. For example, in a staged model, a process area that is written for ML 2 would differ from a similar process area that is written for ML 3. When appraisals are conducted, the intended scope and application for the process area become very clear, as they are based on the staged level.
[2] The five levels of Crosby’s Quality Management Maturity Grid are Stage I—Uncertainty; Stage II—Awakening; Stage III—Enlightenment; Stage IV—Wisdom; and Stage V—Certainty. See Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. New York: McGraw-Hill, 1979.
[3] Just as a staged model allows for many choices and options, so the wise use of a continuous model requires an understanding of the many inherent ordering relationships between various model elements. As with any freedom, the situation for the user of a continuous model is not “anything goes.” In the CMMI continuous representation, for example, the organization needs to reach CL 1 in the Configuration Management process area before it applies the generic practice on configuration management, which resides at CL 2, to any process area. Even without a staging of process areas, CMMI continuous representations have many such ordering constraints. Chapter 7 highlights some of these constraints.
[4] While a staged model appraisal doesn’t normally report a profile, it does provide organizational strengths and weaknesses on a process-area-by-process-area basis.
[5] Complex rules are possible. For example, to achieve maturity level x, you must reach capability level y in one set of process areas and capability level z in another set of process areas.
[6] Within the U.S. Department of Defense environment, for example, personnel are not far removed from the debates that raged about the programming language Ada. While many claimed that having a single programming language within the Department of Defense offered strong potential benefits, others demurred, citing a need to recognize alternative, equally valid approaches in different kinds of systems. For example, the software in a management information system and the software in a real-time weapon system may be very different. Trade studies of widely varying system types relating to the best choice for a programming language would not rate any one language as always preferable. Sometimes the best place in standardization efforts is the middle ground, somewhere between one (at one extreme) and hundreds (at the other extreme); perhaps three—or seven—approaches would keep everyone happy.
[7] The IPD CMM (the Integrated Product Development model, which served as the third source model for the initial CMMI work) was a hybrid model, as is the FAA-iCMM (the Federal Aviation Administration’s model).