This article focuses on applying technology adoption concepts in moving toward using the Software Engineering Institute's (SEI) Capability Maturity Model^® (CMM^®) Integration^SM (CMMI^SM) framework. It is assumed that the reader has a basic understanding of the CMMI concepts and the project that formulated it. If not, please see the CMMI area within the SEI's Web site at www.sei.cmu.edu. For more in-depth information, see CMMI Distilled [1] for basic information on the model and the project written by some of the CMMI project team members.

What is technology adoption? Generally, it is the set of practices and factors related to organizations selecting, deploying, and sustaining the use of a technology. Why look at CMMI adoption as "technology" adoption? First, CMMI "is" a technology (a tool or tool system by which we transform parts of our environment, derived from human knowledge, to be used for human purposes [2]) -- a "process technology" -- and what is more, it is "radical."

"Radical innovation is the process of introducing something that is new to the organization and that requires the development of completely new routines, usually with modifications in the normative beliefs and value systems of organization members [3]." Treating CMMI as a technology adoption first mobilizes a different mindset than the one we typically apply to process improvement, and second may make us more inclined to use some of the useful tools of technology adoption for our CMMI adoption.

Given that the factors involved in technology adoptions are complex, it stands to reason that each adoption is highly situational; its strategy will be unique to that situation and context. Some basic concepts can, however, be applied in generating that unique strategy, including the following:

1. Multiple dimensions have to be addressed simultaneously to achieve success, not just the technology (in this case, CMMI) content.
2. Different audiences with different roles and responsibilities in an organization respond differently as they are introduced to the technology.
3. Acceptance of a new technology does not happen in a linear, predictable fashion no matter how pretty the charts look!
4. There are both different "levels of diffusion" (breadth of technology acceptance) and "levels of use" (degree to which the technology becomes embedded in the organization's governing and social practices). One does not imply the other.
5. Different "mechanisms" are useful at different points in the transition to address different implementation issues with different audiences.
6. Most organizations are very poor at transferring what they've learned from one technology adoption effort to another. Communities of practice are one strategy for addressing this.

In talking to individuals and groups contemplating CMMI adoption, I have sometimes run into this mindset: "We've been successful at implementing Software CMM (SW-CMM); what's the big deal about implementing CMMI?"

From one viewpoint, this is an attractive mindset -- it indicates that the individuals speaking see strong similarities between SW-CMM version 1.1 and the CMMI framework. Indeed there are many similarities, although there are more between SW-CMM version 2 draft C and CMMI since version 2 draft C was one of the seed documents for CMMI, rather than version 1.1.

However, the CMMI framework also provides an opportunity to expand the scope of application of CMM concepts beyond just the software organization into the other parts of the organization involved in product or service development. This means involving new players in the CMM adoption and expanding the scope of effect of CMMs on the subsystems of the organization.

Consider this: Which subsystem elements in Figure 1(see page 20) are "the same" in context, roles, or resources between different disciplines such as software engineering and systems engineering in your organization? Creating alignment among these elements is not a sequential process. For example, changing the technical practices of the organization could have a strategic effect if those practice changes enable the organization to compete in a marketplace that was previously closed to them.


Figure 1: Organizational Subsystems
(Click on image above to show full-size version in pop-up window.)

The managerial and structural subsystems almost always have to be dealt with in parallel. The social/cultural subsystem provides an underpinning for all the other subsystems, and the negative effects of neglecting the social design when redesigning other elements is well established [1]. However, if these subsystem elements are aligned in the same direction, perhaps via use of a similar improvement model like CMMI, then not only is technology adoption smoother, but operations are also often smoothed as well. The elements that follow, in many cases, cross more than one of these subsystem elements.

Who in your organization has to change something in their behavior, attitudes, or values to adopt CMMI: executives, managers, technology users, support groups? What things make these groups more or less likely to change? Edgar Schein's work in organizational subcultures cites distinct differences, for example, between the executive and engineering cultures.

"Executives and engineers are task focused and assume that people are the problem. Executives band together and depersonalize their employees. Executives and engineers can't agree on how to make organizations work better while keeping costs down. Enough mutual understanding must be created among the cultures to evolve solutions that all groups can commit to [3]."

Within subculture groups, "individuals" also differ in their response to a technology adoption. Different "adopter types" move through adoption at different speeds. These groups are distinguished from each other by their characteristic response to an innovation (either process or technology) that requires a change in their behavior. Figure 2 illustrates where each adopter category falls in the technology adoption life cycle. Geoffrey Moore's Crossing the Chasm [4] and Inside the Tornado [5] popularized the description and use of these characteristics in great detail, based on ongoing work in the diffusion of innovations research area by Everett Rogers [6]. A brief summary of each adopter type is provided in the sidebar for those who are not familiar with this work.


Figure 2: The Technology Adoption Life Cycle
(Click on image above to show full-size version in pop-up window.)

Adoption populations are used extensively in planning technology adoption strategies. Understanding the adoption category of intended early users is extremely important. For example, if an intended pilot for new practices turns out to be a group composed primarily of late majority or laggard participants in relation to that set of practices, then I could easily predict the following: Any adoption that (1) does not provide a completely packaged solution and (2) is not mandated by the organization, including sanctions for not adopting, is highly likely to fail. In addition to planning who will get the technology when, adopter categories can be used to categorize what kinds of adoption support mechanisms (see "Transition Mechanisms" section) are likely to be needed to ensure that each category of interest is more likely to successfully adopt the technology.


Adopter Types
(Click on image above to show full-size version in pop-up window.)

Work done in the educational innovations area has provided valuable insight in understanding the patterns that are often operating as a technology adoption such as CMMI adoption occurs. The original chart used by Patterson and Conner [7], reproduced as Figure 3, shows several milestones of increasing commitment to an adoption as time progresses.


Figure 3: Patterson-Conner Commitment Curve
(Click on image above to show full-size version in pop-up window.)

The SEI has found that the path through these milestones is rarely linear, and there are a plethora of approaches for successfully navigating this progression, depending on the individual situation. However, a couple of points in Figure 3 are worthy of note:

• There are clear signs if the organization has "dropped out" of the adoption process. Looking at the behaviors of the organization in relation to the technology can provide a clue as to the point in adoption where translation to the next milestone was not made successfully.
• "Understanding" -- the point at which decision makers in the organization have sufficient knowledge and context information to make a relevant decision about the technology -- does not typically happen on first, or even second contact. This has always helped me to be tolerant of organizational members who "aren't getting it." I ask myself, "Have I given them enough contact and depth to have the right to 'expect' understanding?"

In considering a particular process technology adoption like the CMMI, some time should be spent determining the adoption goals. Some of the other concepts previously described such as what kinds of adopters the adoption is targeting, what elements of the organization need to be realigned, etc., can be used to help set some of these goals.

Another area related to setting goals that should be considered is the relative emphasis that will be placed on CMMI "diffusion" (how widespread the use of CMMI has become) vs. CMMI "infusion" (how deeply embedded into the organizational infrastructure the CMMI has become). This latter area, technology infusion, focuses on the extent to which the work system and social system of the organization are affected by the technology. To measure infusion, one can measure "levels of use" of a technology. For example, the evolution of the infusion of CMMI use in an organization might look something like this:

1. CMMI adoption has occurred in a few projects whose local procedures and processes have been changed to reflect the new practices.
2. One of the divisions of the organization has changed its policies to reflect the practices recommended in CMMI and has formulated and published a set of standard process assets that are used as the basis for initiating and managing new product development projects.
3. Reward and incentive systems in the new projects adopting CMMI practices have been examined and changed where necessary to encourage productive use of the new processes. Existing projects within the division have been evaluated to determine which parts of the set of standard process assets might beneficially be applied to the projects at their current point in the life cycle. Projects are being provided the training and other support needed to make it feasible for them to adopt new practices in mid-project.
4. Members of projects in the division adopting the CMMI are being recruited for projects in other parts of the organization due to the projects' reputation for meeting customer expectations. However, many of them choose to stay within the division rather than move to the other parts of the organization that are less disciplined in their management and engineering practices.

Zmud and Apple, the authors of various articles in this area [8], recommend that an organization that wants to understand the infusion of a technology into the organization identify different configurations that reflect the levels of use that are the goals for the adoption as time continues. Like the CMMI itself, this is a cumulative approach since each configuration builds on the prior configuration's functionality.

This viewpoint has particular applicability to a technology like the CMMI, which in a sense has several embedded configurations enabled by the capability levels or maturity levels. For those using the staged view of CMMI, the maturity levels provide a priori configurations that translate to certain functionality related to the model being present. For those organizations for whom the staged-view functionality is not compatible with their business drivers, thinking of groups of process areas to be adopted as a "configuration" for measuring levels of use is one way to provide measurable anchor points to the improvement effort.

Diffusion -- how broadly the technology has penetrated -- is also an important measure. One of the most useful ways of approaching this that I have encountered is found in Kim Caputo's book CMM Implementation Guide: Choreographing Software Process Improvement [9]. She suggests that the organization "operationalize" the stages of the Patterson-Conner commitment curve ("What does it mean for us to achieve awareness, understanding, etc.?") in terms of events and symptoms of behavior change; then use a histogram to show the organization's population against those events and behaviors.

At the beginning, one might expect that the organization might have a profile like Figure 4 (see page 22). As time goes on, the profile should shift to something like that shown in Figure 5 (see page 22) as more and more members of the organization participate in the activities of CMMI adoption. One use of this measure is to help senior managers understand the time needed to see tangible return on investment of a CMMI implementation. When they understand how many people have to go through several events before one can expect their behavior, and therefore their results, to change, it can help them tolerate some of the time lag that is typical between starting an adoption effort and seeing business results.


Figure 4: Notional Profile Early in Adoption
(Click on image above to show full-size version in pop-up window.)



Figure 5: Notional Profile Later in Adoption
(Click on image above to show full-size version in pop-up window.)

Transition mechanisms are products, events, and methods for translating from one commitment milestone to another. Many transition mechanisms are typically developed by the technology provider. By translation, we mean the process of communicating about the CMMI adoption in terms and language that are likely to be understood and usable by the individuals/groups we are working with. As we proceed in the adoption, the mechanisms move in character from communication and education more toward implementation support and incentives management.

See the "Adoption Mechanisms" sidebar for an example set of mechanisms that could be used in your organization for each CMMI adoption stage. Which ones are right for you depends on your organization's context and culture, and the list is certainly not exhaustive. However, it is based on the list elicited from the May 2001 "The Road to CMMI" technology transition workshop hosted by SEI's Accelerating Software Technology Adoption (ASTA) for organizations that are already using CMMI to support their improvement efforts.


Adoption Mechanisms From the Road to CMMI Workshop
(Click on image above to show full-size version in pop-up window.)

A resource that is available to the community to help understand how early adopters of CMMI have approached their adoption is a presentation of "The Road to CMMI: What Works, What's Needed" [10] from the CMMI Technology Conference and User Group held in Denver in November 2001. Also keep an eye on the SEI publications page for the full technical report that will be published from the workshop results. The reader can access the SEI publication page at www.sei.cmu.edu/publications.

Figure 6 shows an SEI adaptation of the Patterson-Conner commitment curve with commonly used adoption mechanisms embedded with each stage. Note that rather than a straight line, it shows a more curved progress. This is intended to reflect the observation that organizational investment increases significantly once "understanding" has been achieved and the organization is trying to achieve "trial use" and then "adoption."


Figure 6: Notional Commitment Curve for Adopting CMMI, with Possible Transition Mechanisms
(Click on image above to show full-size version in pop-up window.)

Innovators and Early Adopters will tend to create their own transition mechanisms and make do with what is available from the technology producer. Early and Late Majority adopters expect many of these mechanisms to be readily available for them to acquire without development.

Technology producers (in this case, the CMMI Product Team) and SEI transition partners [11] often have many of the mechanisms in "contact, awareness, and understanding" available in their marketing kits. Technology adopters usually have to adapt these to help "sell" the technology to the intended users. Transition mechanisms can include events and activities as well as "products."

One of the exciting areas of research at the SEI within its ASTA initiative is exploratory work that is being done in seeding and helping to sustain "communities of practice." This concept is one of the underpinnings of much of the work in knowledge management, but is particularly useful when looking at adopting a technology like the CMMI. The SEI is incorporating this concept into a larger research project called KNiTT (Knowledge Networks in Technology Transition), which looks at concepts from the communities of practice literature as well as systems engineering techniques, case-based learning, and knowledge repositories to formulate environments and approaches to supporting a technology adoption context.

Even before this work matures, some of the early ideas are worth considering in your CMMI adoption. One of the crucial ideas in this arena is the notion that deep learning about a new technology tends to be problem-centric, that is, the technology will be evaluated by potential users when there is a problem they are trying to solve that appears to be a match for the technology. Until that time, many of the mechanisms that could be used to support adoption of the technology will help build knowledge and positive impressions of the technology, but will not be able to achieve trial use or adoption.

Once problems are being solved with a technology, the possibility exists to seed a community of practice, which contains members of the organization who are motivated to continue learning about the technology. They might build "translations" of the technology for other users who may not be as far along in their adoption of the technology, and communicate and problem-solve with each other to improve their use of the technology. At this point, a community of practice may be considered to be initiated.

In CMM adoption history, many of the Software Process Improvement Networks (SPINs) exhibit characteristics of communities of practice. We believe that bringing the ideas of continued learning and involvement by the practitioners and change agents inside the organization can accelerate the adoption of a technology like the CMMI, since this approach tends to access the informal networks of influence that exist within the organization outside the normal organizational structure. Stay tuned to the ASTA section of the SEI Web site for information on these and other ASTA research areas as they evolve.

The CMMI is early in its own maturation/transition life cycle. This means that there are little hard data on successful (and unsuccessful) strategies for its use, and there are no return-on-investment data that a chief financial officer would find credible. There are many approaches from the technology adoption arena that can be useful in making effective use of the CMMI as it matures. A few of these have been highlighted in this article. As an early adopter of CMMI, you need to be prepared to invest in creating the transition mechanisms your organization will need to be successful and to apply creative approaches to making progress. Understanding and applying technology adoption concepts can help you maximize your return on your investment.

1. Tornatzy, Louis G., and Mitchell Fleischer, eds. The Process of Technological Innovation. Lexington, Mass.: Lexington Books, 1990.
2. Nord, W. R., and S. Tucker, eds. Implementing Routine and Radical Innovations. Lexington, Mass.: Lexington Books, 1987, p. 41, as quoted in [1].
3. Schein, Edgar. "The Three Cultures of Management: Implications for Organizational Learning." Sloan Management Review 38: 9-20.
4. Moore, Geoffrey A. Crossing the Chasm. New York: HarperCollins Publishers, 1991.
5. Moore, Geoffrey A. Inside the Tornado: Marketing Strategies from Silicon Valley's Cutting Edge. New York: HarperCollins Publishers, 1995.
6. Rogers, E. M. Diffusion of Innovations. New York: Free Press, 1995.
7. Patterson, Robert W., and Darryl R. Conner, eds. "Building Commitment to Organizational Change." Training and Development Journal Apr. 1982: 18-30.
8. Zmud, Robert W,. and L. Eugene Apple, eds. "Measuring Technology Incorporation/Infusion." Journal of Product Innovation Management 1992: 9: 148-155.
9. Caputo, Kim. CMM Implementation Guide: Choreographing Software Process Improvement. Reading, Mass.: Addison-Wesley, 1998.
10. Wemyss, Gian. "Results from the Road to CMMI: What Works, What's Needed." Proceedings of the 1st CMMI Technology Conference and User Group, Nov. 2001.
11. Software Engineering Institute. "Transition Partner Program." www.sei.cmu.edu/collaborating/partners/trans.partners.html.

1. See the CMMI Web site www.sei.cmu.edu/cmmi, or the ASTA Web site www.sei.cmu.edu/asta.
2. Contact Software Engineering Institute Customer Relations: Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890; Fax: (412) 268-5800; E-mail: customer-relations@sei.cmu.edu.

Suzanne Garcia is a returning senior member of the technical staff at the Software Engineering Institute (SEI) of Carnegie Mellon University, working in the Accelerating Software Technology Adoption initiative. From November 1997 to May 2001, she worked with aimware, Inc.'s U.S. customers, focusing on technology-supported organizational improvement. She spent the previous five years at the SEI working in various capacities in the Capability Maturity Models initiative. Twelve years prior to that Garcia worked in multiple improvement-related roles at Lockheed Missile and Space Co.

Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213
Phone: (412) 268-9143 Fax: (412) 268-5758
E-mail: smg@sei.cmu.edu