(this faq is just an outline of the official sei-cmmi-faq!
for detailed information visit CMMI Frequently Asked Questions (FAQ) )

Why was the Capability Maturity Model® Integration (CMMI) project initiated?

In the fall of 1997, a review of Software Engineering Institute (SEI) activities was conducted by the Office of the Under Secretary of Defense for Acquisition and Technology (hereafter referred to as OSD). An OSD-led team comprised of government, industry, and the SEI decided to focus on developing an integrated framework for maturity models and associated products. As a result of interest expressed by the model user community, the SEI had already initiated an effort to develop a framework to integrate existing maturity models.

Who was involved in developing the CMMI Product Suite?

The CMMI development project was a collaborative effort among members of industry, government, and the SEI. The project was sponsored by OSD and the National Defense Industrial Association (NDIA) Systems Engineering Committee.

How was the scope of the CMMI project determined?

The CMMI project was formed to improve the usability of CMM® technology for a set of disciplines beyond software engineering. This mission called for use of common terminology, common components, and common rules for constructing CMMI models. These models would be available in a form that would reduce the amount of training necessary and reduce the process improvement effort required by users improving processes in multiple disciplines, thus resulting in a savings of time, effort, and cost to the organization pursuing enterprise-wide process improvement.

As the CMMI concept developed, it became clear that the initial scope of the CMMI project should be restricted to a few of the disciplines most needed by government and industry, until the concept was proven. The selection of software engineering, systems engineering, and integrated product development CMMs was made by industry and government participants for the initial proof-of-concept phase. However, the CMMI Product Suite was designed to accommodate expansion of its discipline coverage and product and project life-cycle coverage. The first such expansion was the inclusion of Supplier Sourcing in the March 2002 release of Version 1.1. Expansion of the CMMI Framework to accommodate the coverage of additional disciplines such as security systems engineering is also possible. Expansion decisions will be made based on

1. the success of the initial release
2. user community needs and support
3. availability of funding and participants to support development activities

The CMMI models cover the same life cycles as the source models: Software CMM, EIA/IS 731 (the Systems Engineering Capability Model), and Integrated Product Development CMM.

What ever happened to Version 2 of the SW-CMM?

In October 1997, the Office of the Undersecretary of Defense for Acquisition and Technology, the sponsor of the SEI, directed the SEI to place higher priority on CMM Integration. As part of this direction, the successor to the Software CMM Version 1.1 was to be incorporated into the CMMI Product Suite.

On August 11, 2000, the CMMI Project released Version 1.0 of the integrated model for systems and software engineering (CMMI-SE/SW, Version 1.0) for public use. One of the three major source models and standards used in its development was Version 2 Draft C of the Software CMM from October 1997. Nearly all of the content and value obtained from the public review of the Version 2 drafts of the Software CMM have been incorporated and retained in the CMMI models.

If you are familiar with any of the Version 2 drafts of the Software CMM, you will recognize much of their content in the CMMI models.

Will the CMMI models make obsolete the models that are represented as source documents (SW-CMM, EIA/IS 731, and IPD-CMM)?

The models that were designated as the starting point for CMMI Product Suite development and identified as source documents in the A-Spec will no longer be updated or supported by their issuing organizations. The product suite is intended to replace these source models. As other disciplines are incorporated into the CMMI Product Suite, their source models will follow the same process. As improvements are incorporated into the CMMI Product Suite, the original source documents will become obsolete and less representative of industry practice.

While the CMMI models are being adopted by the community instead of the single-discipline models they replace, there will be a period during which the CMMI Product Suite and the source documents will both be in use and supported. The intent is to preserve any investment that an organization has made in implementing and using the source models. Sunset of the SW-CMM is described in the article at http://www.sei.cmu.edu Sunset of EIA/IS 731 is being planned by its sponsoring organizations.

How do CMMI products relate to the International Organization for Standards (ISO) documents?

The CMMI A-Spec includes a requirement that the CMMI Product Suite be consistent and compatible with ISO/IEC 15504. Some of those involved in the CMMI effort are also involved in related ISO/IEC efforts as members of the JTC1/SC7 US Technical Advisory Group. This assures that future compatibility can be "continually improved." A mapping to compare ISO 9000:2000 with CMMI will be provided on the CMMI Web site soon.

What are the "staged" and "continuous" representations?

There are two representations of each CMMI model: staged and continuous. A representation reflects the organization, use, and presentation of model elements. Both representations contain essentially the same information. Each representation consists of process areas that contain a purpose statement, introductory text, specific goals, specific practices, generic goals, and generic practices. For more information about these components, refer to Chapter 2, "Model Components" in any CMMI model.

Staged. The staged representation offers a roadmap to approach process improvement one predetermined step at a time. Process areas are grouped at maturity levels that provide organizations with a proven approach for process improvement. The staged representation prescribes the order of implementation for each process area according to maturity levels. Achieving each maturity level ensures that an adequate improvement foundation has been laid for the next maturity level, thus minimizing the organization's process improvement investment and risk while maximizing the benefits to the organization.

Continuous. The continuous representation offers a more flexible approach to process improvement. It is designed for organizations that would like to choose a particular process area or set of process areas based on trouble spots in the organization or a set of process areas that are closely aligned to the organization's business objectives. Process-improvement objectives are mapped to process areas in the model to identify the process areas to be implemented. As a process area is implemented, the specific practices and generic practices are grouped into capability levels. These capability levels enable the organization to implement the chosen process area(s) incrementally. The continuous representation also allows an organization to implement different process areas at different rates.

How will my organization know which representation to use?

Three categories of factors may influence your decision: business, cultural, and legacy.

Business Factors: An organization with mature knowledge of its business objectives is likely to have a strong mapping of its processes to its business objectives. An organization such as this may find the continuous representation more useful to assess its processes and to determine how well the organization's processes support and meet business goals. The staged representation is widely used and maturity level ratings are often published. If your organization is concerned about benchmarking with your competitors and/or publishing results, the staged representation might be selected.

Cultural Factors: Cultural factors to consider when selecting a representation have to do with an organization's ability to deploy a process improvement program. For instance, an organization might select the continuous representation if the culture is experienced in process improvement or has a specific process that needs to be improved quickly. An organization that has little experience in process improvement might choose the staged representation, which provides additional guidance about the order in which changes should occur.

Legacy: Organizations with a strong systems engineering culture might be more familiar with the continuous representation, whereas software organizations may be more accustomed to a staged representation. If an organization has experience with a staged representation, it may be wise to continue with the staged representation of CMMI, especially if it has invested resources and deployed processes across the organization that are associated with a staged representation. The same is true for an organization that has experience with a continuous representation. Both staged and continuous representations were made available so that the communities that have used the different representations successfully could continue in a manner that is comfortable and familiar to them.

An organization isn't forced to select one representation over another. In fact, an organization may find utility in both representations. It is rare that an organization will implement either representation exactly as prescribed. Organizations that are successful in process improvement often define an improvement plan that focuses on the unique problems of that organization and therefore use the principles of both the staged and continuous representations. For example, organizations that select the staged representation that are at maturity level 1 often implement the maturity level 2 process areas but also the Organizational Process Focus process area that is staged at maturity level 3. An organization that selects the continuous representation for guiding their internal process improvement effort might then choose the staged representation to conduct a formal assessment.

Is the framework core robust enough to support future models?

The architecture of the framework is designed to allow the future addition of other models as well as the integration of additional disciplines into the integrated models. The common components that relate to process management and improvement are likely to be appropriate for almost all CMMI models that have process improvement as a major concern. It is likely that, if the scope expands outside of engineering, additional subsets of shared components will be necessary, but the architecture is designed to readily handle this type of addition.

What should organizations that are using CMMs do now that CMMI products are available?

Organizations that are in the process of moving along the maturity continuum in applying one or more of the existing CMMs are encouraged to compare their current processes and approach with the CMMI model and create a transition strategy that meets their business needs. More information can be found in Chapter 6, "Using CMMI Models," of any CMMI model document.

Organizations that are already using another model for process improvement will need a transition strategy rather than an adoption strategy. Many of the lessons learned from EIA 731 and SW-CMM start-ups will be equally beneficial in a CMMI effort, since the issues are essentially the same. Organizations that are well on the way to a process improvement milestone may want to measure their progress before making the transition to CMMI.

Must my organization already have a CMM-based process improvement program under way to successfully implement CMMI?

No. It is helpful, but not required. Organizations that are not already using a model to guide their process improvement efforts can plan by exploring a CMMI model for areas of greatest immediate business value.

Can the CMMI-SE/SW model be used for improving the processes in electrical and mechanical engineering disciplines?

Yes. The CMMI-SE/SW model guides engineering development of systems. We sought to ensure that the broader needs for system development practices were included in it, along with the "typical work products" applicable to the software community. More specific discipline areas like electrical and mechanical engineering may wish to supplement that guidance to address elements that have not been covered. For that and similar reasons, we provide a Microsoft® Word version of the model that can be tailored to meet specific needs. Over time, other disciplines may be added to the product suite, to the extent that this can be done without adding inordinate complexity to the model.