Beware becoming change-averse change agents! | ||
| --Barry Boehm, SEI Symposium 2000 Keynote Address | ||
When we blindly adopt a religion, a political system, a literary dogma, we become automatons. We cease to grow. | ||
| --Anaïs Nin, The Diaries of Anaïs Nin (1903–1977) | ||
What lies ahead for Capability Maturity Model Integration (CMMI) and for improvement efforts in general? How will process improvement methods and tools evolve to meet the changing needs of users? Will the concept of constellations—new to version 1.2 of the model—enable CMMI concepts to be more readily applied outside of the engineering disciplines? Will process improvement evolve away from the capability model concept?
Our discussion of (and musings on) such questions in this final chapter may be of greatest interest to those readers who are, in their heart of hearts, architects or system designers. Perhaps as you reflected on our description of the CMMI product suite in earlier chapters you found yourself wondering: “Why did they do it that way?” or “I would have done it differently” or “What were they thinking?” Perhaps you are just curious about the use of improvement models in an increasingly agile world. If such questions and issues interest you, read on.
In contrast, if your interest is focused (quite legitimately) on learning about and using the current CMMI products, then you may prefer to make this chapter a “quick read” on your way to the Afterword, which contains our concluding remarks.
From the very first meetings of the CMMI team, before version 1.0 existed, there have been calls for a simpler model. The original CMMI effort to merge the three source models inevitably required compromises related to the number and scope of the process areas (PAs). The decisions made then and in each revision of the model to date, while certainly thoughtful and deliberate, are not beyond the realm of debate. Are all of the current process areas needed? But beyond size, are there additional simplifications that could or should be made?
One big step toward simplification has already been made: the elimination of the staged and continuous representations as separately published entities. This makes the selection of a model easier for users of version 1.2. After all, the staged and continuous approaches do not represent distinct ways to make improvements as much as different ways of presenting appraisal results.
What steps are possible in the future? There has been discussion about the complexity of the model architecture, and the concept of generic practices (GPs) is a favorite target for critics of the model. As described in Section 10.3, a primary reason for GP bashing may be a lack of understanding about how they work. Of course, the GPs might also be a good place to try to simplify the model—albeit while working within the concept rather than outside it. Rewriting or rethinking GPs to reduce their number and clarify their meaning is certainly a possibility. The following sections provide for reflection and discussion of some ideas and questions on the future of CMMI.
There are always creative people who see opportunities to apply existing tools in new ways. Often, this sort of extension leads to changes in the tools as new stakeholder views are considered. CMMI can be a powerful vehicle for process improvement. In particular, it can be effective in identifying and mitigating risk in engineering, acquisition, and service organizations. If we wish to expand the domains to which CMMI may be applied, then changes in the overall CMMI concept and in the architecture of the model may be needed. In this section we look at one way to both simplify the model and use it in a much broader set of process domains.
With the advent of CMMI, and its inclusion of multiple engineering disciplines within a single architectural framework, the world of engineering process models was supposed to become more unified. The original CMMI architecture team spent a good deal of time trying to identify a hierarchy of process areas that would be represented in any domain. The constellation process built on this experience by defining the CMMI Model Foundation. The common elements in the CMF need to be interpreted and amplified for each domain in which they are applied.
Several members of the CMMI Team have long advocated a simpler, more streamlined approach to CMMI. One idea is to produce a model consisting of only generic practices and the process areas that “enable” or support them.[1] Written in a conceptual and extensible manner, those components would define a model that could apply to any process—engineering, acquisition, service, or otherwise. There would be a template for defining domain-specific and organization-specific target processes. Process capability levels would be measured by the implementation of generic practices. Maturity levels would be based on the staging of the enabling process areas in the same way as the current CMMI equivalent staging.
As an example, suppose that a printing company wanted to apply this domain-independent CMMI (DI-CMMI) to its processes. It would first need to establish its “core discipline” processes—perhaps layout, printing, finishing, and delivery—according to the template provided with the DI-CMMI. Once these processes were defined, the company could begin improvement with the level 2 generic practices and their enabling process areas.
Although the domain-independent model would be similar to the existing CMMI models, its lack of an orientation toward a particular constellation would provide several broad benefits:
It could act as a process improvement model for a much wider range of enterprises, such as banking, consulting services, light industry, government, and retail; such applications already have been suggested by countries with the need to institute various industrial and governmental processes in their emerging economies.
It could provide a layperson’s view of continuous improvement that could be taught in undergraduate management and business curricula.
Because of its lean structure, it would not require large development teams or a complex support infrastructure to apply it to additional disciplines.
A DI-CMMI may also have some drawbacks. For instance, it is not clear that the language in the model could be suitably simplified so as to apply across all disciplines. Some question might arise as to the comparability of level ratings, given the variation in the organization-specific processes.[2] Of course, training and appraisal materials would be needed that were as simple and clear as the model language, and most likely there would still be trainers and appraisers available to “guide” its use.
This approach could support an improvement community working to develop agile techniques, and would open up additional opportunities for improvement experts to expand their practices—possibly working in some specialty disciplines where they had additional interests. It could be used throughout the enterprise, from the CEO’s processes down to the processes found at the lowest level of the organizational hierarchy. It could also energize a number of communities that to date have been lukewarm to the current models because they are “too engineering oriented.” Finally, it would enable process engineering to evolve with the successful practices of the various domains.
The CMMI sponsors held a number of workshops in 2007 with the goal of capturing ideas from users about the evolution of CMMI. Our readers should keep an eye out for similar workshops in the future. So far these sessions have brought to light some common themes that may be useful in evolving CMMI.[3]
Not surprisingly, the workshops brought forth many more comments about appraisals and the appraisal process than about the model content and architecture. However, some of the appraisal issues may be based on a misunderstanding of the model. This was particularly true of the GP concept. It was striking how many people—including some folks who should—didn’t “get” GPs. There was also wide misunderstanding of capability levels and maturity levels, especially by more senior management. Correcting this state of affairs by making adjustments to the GPs and to how levels are characterized may be one of the goals defined in evolving CMMI.
One contributor to this issue may be the language used in the model itself. To be both precise in its content and generic in applicability, the model is written using words that—while carefully chosen—may be difficult to understand for average readers. Just as requirements and operational concepts should be written in terms that users and customers understand, so it may be necessary to find new ways to describe the model’s components and requirements. In the future we hope to see considerable innovation in this area.
Another issue that arose was the request for more project-related process improvement. CMMI, which relies on the notion of a “road to maturity,” is based on the concept of an organizational institutionalization of common processes. This assumption is perfectly reasonable for an organization that has several units that do roughly the same thing. However, that environment is rarer now than it was in the 1970s and 1980s when the original CMM concepts were defined.
Consider the current way in which systems with software are developed. Big, complex systems are usually developed by a team of large, multidisciplinary corporations that represent the result of a decade of mergers, buyouts, and other culture and process mixers. Pieces used to build the system are bought as commercial items from smaller companies, custom-developed by suppliers, obtained from open-source libraries, created internally from scratch, or are vestigial or legacy components. Every such project deals with different issues. What is the “corporate organization” in that scenario?
At the same time, software development and other engineering tasks are being driven by the need for agility in response to rapidly changing and emergent requirements and the expectations of early value to the customer. Agile approaches usually include mechanisms for improvement on a cycle-by-cycle basis, where the effects of new process components—whether good or bad—can be determined within weeks (rather than months and years). Unfortunately, most of the more traditional development and improvement approaches, while not totally inconsistent with agile thinking, are generally not supportive and, in some cases, are actually antagonistic.
Are there ways in which organizational maturity and multi-organizational maturity might be better integrated into the continuous improvement paradigm? Can future versions of CMMI (or improvement in general) move toward a more flexible approach that could work for programs and projects without forcing the assumption of artificial organizational constructs? Could process improvement be somehow coupled to acquisition or development milestones, perhaps requiring evidence of continuous improvement before moving to the next phase? This issue is somewhat addressed in the Boehm/IBM rational anchor-point milestones, where evidence must be presented as to the feasibility of the project or program, including the ability to meet the cost and schedule targets based on the results of the prior phase.[4] To address this concern within the current models requires reconsideration of some of the core concepts of CMMI and so will be painful and expensive—but then so is childbirth, and the result could be just as exciting to watch grow and mature.[5]
One of the continuing conundrums within the improvement community is whether the existing models and appraisal approaches give sufficient consideration to whether a process is working effectively, which is a central facet of lean engineering improvement techniques. Is the CMMI infrastructure supporting better end results or just more consistent and predictable results? The model authors will state unequivocally that the whole rationale for CMMI is to support better end results by improving organizational performance. Nevertheless, questions come from a large number of doubters, including some in the U.S. Department of Defense (DoD), who believe that the models (perhaps because of the hype about maturity level numbers) are more means of marketing and competitive comparison than serious improvement initiatives. In support of this view they point to a lack of statistical evidence that higher-level organizations actually perform better than lower-level ones on their contracts. The paucity of data leads to the question of how the models and appraisal methods can evolve to better accomplish the prime directive of continuously making improvements.
Probably the most interesting—and frustrating—issue is the question of model scope. On the one hand, there is strong support for simplifying the model. On the other hand, there is equally strong support for extending the model to more disciplines. On the surface, these perspectives seem to imply exactly opposite requirements. The constellation concept was intended to bridge this gap by providing a means to create new but highly compatible models. Since this concept was implemented, however, some sponsors and users have pushed back a good deal. While the original requirements for CMMI specifically included the need for extensibility into other disciplines and subject areas, some believe that constellations hearken back to the proliferation of CMMs, the elimination of which was a central goal of the CMMI project from the beginning. It may be that a radical change in the way the model is defined (e.g., something similar to the domain-independent proposal) could simplify model application while leading to a broader scope for CMMI. Only time and politics will determine which, if either, of these constituencies is satisfied.
Now it’s time to venture into really dangerous territory: Who should control CMMI? Currently, the product suite is controlled primarily by the U.S. defense industry. The decision authority for any changes to the model or to the disciplines is concentrated within three groups: the National Defense Industrial Association (NDIA), the acquisition organization of the U.S. Department of Defense (OUSD AT&L), and a federally funded research and development corporation (the SEI), which is sponsored by the DoD. While non-defense industry is represented as part of this initiative, members of the Steering group—which is co-chaired by NDIA and DoD—serve as the “deciders.” And the deciders are focused on DoD and its large suppliers, and on maintaining their investments in the current models. This is not bad per se, but there is a question whether this power structure is good for the long-term health of the model. Although it does provide much-needed stability, it also makes it very difficult to make significant changes and may bias the direction of CMMI evolution.
Several voices have called for the defense community to turn the model over to a more domain-neutral organization. It is not clear exactly how this handoff would be accomplished, given that the intellectual property belongs to Carnegie Mellon University; while provided ostensibly free of charge, CMMI remains a considerable asset to the University. Standards organizations such as ISO have been mentioned as a possible CMMI home. One benefit of this could be a broadening of interest in CMMI across a more diverse range of disciplines and industries. On the downside, however, standards organizations are governed by notoriously slow processes when developing or updating standards, typically they charge for copies of standards, and they are sometimes innovation averse. Although some CMMI practitioners may not like everything about the current CMMI products, decisions can be made relatively quickly under the current system when there is the need to do so. Other ideas for governance include pursuing an open-source approach, which means that the models would be able to change rapidly given that the changes are “tested and approved” by the source control team. Of course, that begs a new question: What will be the membership of the source control team?
Obviously, this very thorny and highly political issue will not be resolved quickly; just embarking on the discussion would require goodwill and trust in many places. Nevertheless, as the model finds proponents in more countries and more industries, this conversation may become more vibrant and change could come. We hope this subject is pursued in an open and positive manner, engaging all the stakeholders in the discussion and giving support to the best ideas and rationales that are presented.
The ideas presented in this chapter are no more than seeds of possibilities. How CMMI actually evolves should be driven by you—that is, by the user community. At the end of the day, if CMMI isn’t useful to organizations like yours, it won’t be applied; it will stagnate, wither, and disappear into the graveyard of lost management tools du jour. Conversely, if CMMI remains responsive to your needs by changing to better serve organizations like yours, it will be a vital and beneficial tool for a long period of time.
Widespread acceptance and adoption require the user community to actively participate in CMMI evolution. There are a number of ways you can join this movement:
Attend conferences, workshops, and courses to learn more about CMMI and to provide feedback to the sponsors.
Submit change requests to the CMMI Stewart (SEI).
Join organizations that are sponsors, and actively lobby for your positions on CMMI issues.
Participate in a CMMI working group such as the interpretive guidance project or a model extension development team.
Have your organization (or your industry association) join the CMMI Steering Group.
The more users who become involved, each of whom brings his or her diverse needs and viewpoints to the table, the better CMMI will be. And the better CMMI is, the easier it will be for integrated, continuous process improvement to benefit more and more organizations throughout the world. It really is up to you.
[1] For example, a process area for configuration management that supports the Configuration Management generic practice at CL 2.
[2] As noted earlier, we are not big fans of using CMMI ratings to compare organizations that have significant differences.
[3] In this section, we highlight just some of the ideas currently under discussion.
[4] Boehm, B., and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston, 2005 (Appendix D).
[5] While he was working on revisions to this chapter, Rich welcomed his first grandchild, Ian Fred Kadera, into this world. Dennis is expecting his first grandchild (a girl) in 2008. We all continue to be fascinated with how quickly a baby changes and changes those around him.