Capability Maturity Model^® Integration
A Model for Process Capability, Organizational Maturity Appraisal, and Improvement

Resume | Papers | Courses | Consulting | ContEd | HW/SW | Tech Interests (Quality)
SPI Overview -- Deming Bio | 14 Points -- CMM and CMMI | SEH | ITIL -- Process Models | Tools

Subweb: CMMI | Process Areas | CMM History | How different is CMMI? | CMM(i)²
Terminology | Organizations | Certifications | Standards | Methods | Companies | Tools | Schools (see Cont Ed link) | Conferences

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit

Strategy for Migrating to CMMI®? There are a number of potential impacts to an organization migrating to CMMI (see Differences). The most significant change is the increase of CMMI's scope, which may put the organization's existing "credentials" at risk, or at least their near-term achievement goals. Actual (felt) impact depends in-part on the characteristics of the organization and their defined processes, as are outlined below. "Felt" Impacts: Organizations just starting a process improvement program: Well, now have more to do to catch up! The "hurdle" for each level is a lot higher today than it was for SW-CMM 1.0 or 1.1, because the expectation of professionalism within the industry (and from customers) has been raised, especially for Maturity Level 3! For CMMI v.1.2, Supplier Sourcing no longer become a "choice" -- it will be embedded into the base model (and only tailored out if Supplier Agreement Management (SAM) does not apply). Software-only development organizations with SW-CMM: The added complexity (and newness) of CMMI may be perceived as a cost. Although not in SEI's original plan, due to customer demand, a CMMI-SW Staged representation was made available. This representation minimized the differences between CMM and CMMI, and allowed Organizations to minimize the impact of the transition [and add other disciplines as business needs dictated]. However, with version 1.2 that option goes away! There is mp longer a separation between the disciplines; Systems, Software, and Hardware are folded into the CMMI-Development "constellation" (CMMI-DEV). Systems-only development organizations with SECM: Progress against any of the System Engineering models (e.g., SE-CMM, SECM, INCOSE's Systems Engineering Handbook) will help the transition. The mapping to the CMMI-SE Continuous representation was fairly straight forward, and the transition was similar to the transition to that outlined for software. However, like "Option B" CMMI-DEV v.1.2 changes the approach to a "single book" format, so a "system engineering only" approach is no longer an option. Prior ISO-9001-2000 experience, but not CMM or CMMI: These organizations will have to deal with a slightly different architecture and terminology. ISO 9001 has a broader scope (including business practices, etc.), which are "assumed" but not explicit in CMMI. ISO Certified organizations should have established policies, standards, and a quality management system that should provide good coverage of Configuration Management (CM, including project records and quality records), Project Management (partially PP, PMC, SAM), and the Quality Management System (QA, MA, OPF, and OPD). Generally, additional "depth" will be required for SE or SW development procedures (REQM, RD, TS, DAR, PI, VER, VAL) and organizational training (OT). Levels 4 and 5 of the SW-CMM was, and CMMI now, are being used by previously ISO 9001 Certified organizations, especially in Europe, to continue their improvement efforts. These levels correspond to the Quality Management System Guidelines in ISO 9004. Previous "credentials" (SW-CMM, CMMI-SW, SECM, CMMI-SE), in an organization with a mix of systems and software projects: Especially large organizations, at higher levels of maturity, may find the greatest impact of CMMI to be to their existing "credentials"! Because of the change in appraisal scope, projects that were legitimately considered "out-of-scope" under SW-CMM, may now "in-scope" with CMMI-DEV. This can potentially "demote" an organization's maturity level (since a rating is based on the all projects within "organizational unit" defined by the scope of the appraisal). This is especially true, when management decides to "reorganize" without consideration of process improvement impacts! Possible Mitigations: The situations described above can usually be mitigated by, one or more, of the following approaches: Adjust the Organization: Restructure the organization to localize the more mature "organizational units" under common management. This can "insolate" them from lower maturity projects and minimize the risk to SCAMPI appraisals (and frustration of the staff). For example: If the software development projects were accessed under SW-CMM, these projects could be localized into a common organizational unit, with separate action plans, appraisal schedules, etc. (with the possibility of future integration when risk of impact is lower) To make the organizational units more homogeneous, projects could also be grouped by maturity levels, model history (e.g., ISO 9001), domains, contract types, product types, customer base, or other factors To avoid "reinventing the wheel", consideration should be given to assuring some type of information exchange between the organizations [e.g., common SSPG, common asset set, common improvement process, cross-organizational working groups, cross-functional process action teams, newsletters, etc.] . Adjust the Transition Plan: Allow for a Staged Roll-Out! Just like systems development, you do not change or integrate everything at once. The "big bag" approach is high-risk. Address the transition like you would (should) any other change! Evaluate the trade-offs and alternatives Evaluate the cost Plan the change Execute the plan Assess actual results against the plan The migration from SW-CMM to CMMI, or CMMI-SW to CMMI-DEV, should have a transition plan. The same (or similar) process to how you would normally address projects that are just starting, projects added by reorganizations, roll-out of new release of process assets to existing projects, adding a new maturity level, or adding a new discipline. Define criteria, tailoring guidance, approval process, or waiver process to allow for some judgment in determining if and when a project will "step up" to the new/revised/integrated processes or new "expectations"! Possibly, complete the Decision Analysis and Resolution (DAR) process to document the trade-offs considered, as well as the final decision. . Use Process Audits to measure and track gaps: If both systems and software projects share the same policy, and ideally the same organizational set of standard processes, then Quality Assurance Audits (or objective reviews), and related results/reports can be used to identify "gaps". Addressing the audit defect should close the process gaps. Monitoring action items to closure, provides a measure of the level of "compliance" and a distribution (and confidence level) based on the samples If the Quality Assurance staff are trained to use rigor in their process audits, similar to the SCAMPI process, then process audits can essentially be used to do iterative "mini-SCAMPIs" [and be a better predictor of appraisal "success"] . Adjust the SCAMPI Scope: The appraisal type can be adjusted based on risk: The SCAMPI-A process is costly! Therefore, it should (generally) be used only when you have: A high-confidence of success and A requirement for an "official rating" (e.g., to satisfy a contract requirement for a proposal, where your last appraisal is getting close to 3-years old) The SCAMPI-C or B methods relax some of the appraisal requirements, which reduces costs (time and money), if an "official" SCAMPI-A is not required by contract or other requirements. See below for a brief comparison of method classes (also see CMM-history). Note: New SCAMPI 1.2 rules limits the appraisal to 90 days and prevents the creation of artifacts after the start of evidence review (except periodic work products) The target maturity level can be adjusted to match the process roll-out and transition The model representation can be adjusted: a continuous appraisal (possibly with staged equivalence) can be used to assess the strengths and weaknesses and provide important data for creating an effective action plan (s long as you contract the appraisal team to do so). The "organizational unit" size can be adjusted: to complete Interim Appraisals. Smaller, but more frequent appraisals can be used to: identify gaps, create action plans, predict a rating, as a method for preparation for the SCAMPI-A, and as a method to prepare for a SCAMPI-A with a wider scope . Adjust the Sampled Projects: [Note: There are limitations to this approach based on the new v.1.2 rules for sample size and coverage] You may have some flexibility on what projects are considered "in-scope" at the time of an appraisal. It is reasonable and realistic that not all areas within an organization will (ever) at the same maturity level. Just reference SEI's material on change management -- it is a fact that there will be 'early adopters' and 'passive resisters' in every organization! There is typically some prioritization based on business need, risk, return on investment, available expertise, resources, and other factors. Therefore... Create an action plan to address the gaps identified in the existing projects being brought in-scope. Be up-front with, and obtain buy-in from, the appraiser on the approach. Assure the plan and the criteria for "in scope" [as well as the appraiser] are reasonable and realistic! The Appraiser can sample from the "in scope" projects. Action-Plan Considerations: In addition to the scoping issues of additional projects and disciplines, items mentioned above, the following impacts should be considered: Balancing multiple maturity levels: In any large organization, you may have to deal with pockets of lower maturity caused by: resistance or other cultural barriers differences in customers, contract vehicles, or business model buy-outs, mergers, and other reorganizations done without evaluating the impact to your process improvement efforts and related "credentials" Transitioning to CMMI-DEV can aggravate this issue Balancing units at higher-levels of maturity, ML 3, 4, and 5, can be done fairly easily through expanding the organizational standard set of processes (OSSP) to include existing systems engineering processes as optional or alternative asset selections, and eventually merging best practices through the change process Impact of lower maturity levels: Addressing ML2 organizations is a little more difficult, but software process assets can be used as a "strawman" for systems engineering projects, which can adapt/tailor the assets to address needs, risk can be reduced by applying to a few pilot projects first In organizations where system engineering projects have not been involved in previous process improvement experience, you may be stuck with integrating "mud-suckin' Level 1" projects into your organization! Remember the real hurdle from ML1 to ML2 is still cultural, not technical! Handing them a stack of documentation, or a link to an asset library, will not be adequate -- these organizations will probably have to through the same cultural-evolution your software projects went through, maybe 10, 15, or 20 years' ago!  Re-tooling your processes: Existing process descriptions, procedures, templates, will probably need to be "upgraded" to address the practices in CMMI, especially new process areas [see Additions and PAs]. It is not as simple as changing every instance of  "CMM" to "CMMI" and "software" to "product"! A related implementation risk is that an organization may find that their software-centric process asset sets, improvement organization, metrics, and training are not robust enough when applied to system development. Allow for "churn" -- the terminology, process, and cultural changes may cause some organizational confusion. This may also require a corresponding change in Training Curriculum.

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit

CMMI Architecture Both the SW-CMM (v.1.1.1) and CMMI (v.1.1, v.1.2) define five maturity levels. For CMMI, the name of the building blocks have changed from "Key Process Areas" (KPAs) to simply Process Areas (PAs). The lower levels, and related PAs, focus mainly on management processes (and industry minimal standards). Higher levels focus more on organizational and technical processes (and more on industry best practice). The fifth and highest level, Optimizing, is Kaizen -- continuous improvement. The objective of CMMI was to provide a framework or architecture that could support multiple models. Therefore, some meta-structure was introduced to enable the framework to handle different representations, disciplines, and create useful collections of practices. See the Hierarchy of these components in Table 1. In SW-CMM the major architectural components of the model were Common Features. Common features included not only the activities or practices, but the infrastructure needed to make the practices "stick" -- to become the way of doing business, to become "institutionalized." Although the activities, and some of the verification techniques, may be specific to software, the other three common features definitely had a Deming influence. The mappings between Common Features and Goals were indirect in the SW-CMM. Usage showed that some organizations "negligently complied" to certain practices, rather that selecting an alternative that was more appropriate for their organization. Also, some appraisers did not give "credit" when an organization followed an alternative approach. Therefore, in CMMI, the practices are explicitly mapped to the Goals, e.g., specific practices are examples of how each specific goal is typically achieved. CMMI also made explicit what was required and what was informative, the object is to achieve the goals, not prescribe a method to the goals. In CMMI 1.0 and 1.1, Common Features co-existed with, and we mapped to, Generic Practices and served as a bridge between model architectures. In the new architecture, most "activities" became Specific Practices, and the remainder of the common features became Generic Practices [see Table 2: Comparison of Model Components]. However, to simplify the model, in CMMI v. 1.2 the Common Features go away all together and only the Specific and Generic Practices remain [see Future Changes]. The first column, in Table 1 below, still applies. See the Table 2 below showing some of the relationships between CMM Common Features, CMMI Generic Practices, and Deming's quality system principles. What is CMM? | Migrating to CMMI | CMMI Architecture SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit   Table 1: Hierarchy of CMMI Architecture Components Model Definition: the Framework Constellations: Definition: a model containing a related collection, group, cluster, or class, of (1:n) integrated Disciplines established to address process improvement for a specific industry sector [concept introduced in v. 1.2] "Group of stars from the universe" A "tool-box" of potential tools Composed-Of: A list of possible Disciplines (can-be-a relationship) A set of composition rules for selecting options and alternatives used to constrain a Model Instance Examples: The first, in CMMI v.1.2, is the Development and Maintenance Constellation (DEV) derived from the v.1.1 of the model with the SE/SW disciplines The second, planned is the Acquisition Constellation Software Acquisition used to be a separate model (see above) With CMMI, SA is currently a module (guidance for tailoring a model for a discipline, SA-CMM) The third, is likely to be the Services Constellation should address operations and support disciplines [see SPE-Note on CMMI PA page and separate CMM(i)2 page] Disciplines: Definition: bodies of knowledge, work types, business domains Composed-Of: one or more of the following: Additional Process Areas [this was the approach for SS in version 1.1] Additional Specific Goals and Practices [i.e., extensions or additions to "base" process areas, the approach that will be used for IPPD in CMMI v.1.2] Additional Informative Components [e.g., Discipline Amplifications, Notes, Examples, References related to the discipline] Example: For CMMI v.1.1 the disciplines were: SE = Systems Engineering SW = Software Engineering IPPD = Integrated Product and Product Development SS = Supplier Sourcing For CMMI v.1.2, the separation between two of the v.1.1 disciplines was removed SE and SW were combined more explicit support of HW = Hardware Engineering was added to create the DEV constellation SS is now embedded in SAM Additions (originally called Extensions): CMMI v. 1.2 introduces this concept, separate from Disciplines Definition: Additional goals and practices, within PAs, to support a capability Example: IPPD = Integrated Product and Product Development, became an addition in v.1.2. See Recent and Future Changes [also see other models: IPD-CMM]. [Model] Instance: Definition: the composition or view of the model, defined by the specific selection of Disciplines (from a list of possibilities defined by a constellation) used to define part of the scope of an assessment Composed-Of: Disciplines, satisfying appropriate composition rules (is-a relationship) Composition Rules were simplified for v. 1.2: for CMMI version 1.1: SE/SW were recommended as the base model [only differ in informational content] IPPD and SS were optional, and could be selected independently This minimized the transition impact Those migrating from SE-CMM to use CMMI-SE Continuous Representation Those migrating from SW-CMM  to use CMMI-SW Staged Representation However, it complicated the model and allowed for a number of "legal" combinations, each either "staged" or "continuous": CMMI-SE CMMI-SW CMMI-SE/SW CMMI-SE/SW/SS CMMI-SE/SW/IPPD CMMI-SE/SW/SS/IPPD for CMMI version 1.2,  the following combinations are available in either "staged" or "continuous" (see Recent and Future Changes): CMMI-DEV CMMI-DEV/IPPD 5-Maturity Levels (of staged model) composed of: Process Areas composed of: Specific Goals (SG) supported by: Specific Practices (SP) Generic Goals (GG) supported by: Generic Practices (GP) The "authority" of each component varies Goals are required, implemented, and institutionalized [normative] Practices are expected; alternative practices are acceptable if effective at meeting the goals All else is informative

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit
 

Table 2: Comparison of Model Components  

CMMI-DEV Generic Practices	CMMI 1.1 Common Features	SW-CMM Common Features	Deming's System of Profound Knowledge and 14 Points
GP 1.1 Perform Base Practices	Specific Practices	Ac: execution Activities to Perform
GP 2.1 Establish an Organizational Policy	Commitment to Perform	Co: Commitment to Perform • Written organizational policy	• Develop constancy of purpose (see P1) • Strategic leadership (P7) • Management sponsorship of change (P14)
GP 2.2 Plan the process GP 2.3 Provide resources GP 2.4 Assign responsibility GP 2.5 Train People GP 3.1 Establish a Defined Process	Ability to Perform • GPs 2.2, 2.3, and 2.4 distribute Project Planning, and Project Management and Control PAs from ML2 • GP 2.5 is also addressed by Organizational Training PA at ML3 • GP 3.1 is also addressed by Organizational Process Focus/Definition	Ab: Ability to Perform • Roles defined and assigned • resources and funding • support tools • both skills and knowledge, both practitioner and cross-team orientation + planning Activities to Perform	• Need for training (see P6 and P13) • At ML 2 & 3 the focus is on defining a repeatable organizational process, defining what the system is (see K1, K2, and K3)
GP 2.6 Manage Configurations GP 2.7 Identify and involve relevant stakeholders GP 2.8 Monitor and control the process GP 3.2 Collect Improvement information	Directing Implementation • GP 2.6 distributes Configuration Management PA (or version control) from ML2 • GP 2.7 is addressed in Project Planning PA at ML2 and increases customer focus of other PAs • GP 2.8 is addressed in Measurement and Analysis PA at ML2 • GP 3.2 is also addressed by Organizational Process Focus/Definition	Me: Measurement and Analysis • Measurements used to determine status • At ML 4 & 5 those measures are used for Statistical Quality Control, technology insertion, and process efficiency. + monitor and control Activities to Perform	• The focus of measurement is on the process, not the people (driving out fear, P8). • Focus on stakeholders and Integrated Teaming (formerly Intergroup Coordination) at ML3 helps break down barriers between staff areas (P9).
GP 2.9 Objectively evaluate adherence GP 2.10 Review status with higher level management	Verifying Implementation	Ve Verifying Implementation • Review with Senior Mgmt • Review with Project Mgmt • QA Review of activities and work products	• Need to apply P3 (cease dependence on mass inspection), using small samples for control charts to achieve or to maintain statistical control
GP 4.1 Establish and maintain quantitative objectives for the process that address quality and process performance based on customer needs and business objectives GP 4.2 Stabilize the performance of one or more subprocesses to determine the ability of the process to achieve the established quantitative quality and process-performance objectives		L4: Managed (see PAs)	• At ML4 the focus is on managing a controlled process and addressing special causes of variance (see K2)
GP 5.1 Ensure continuous improvement of the process in fulfilling the relevant business objectives of the organization GP 5.2 Identify and correct the root causes of defects and other problems with the process		L5: Optimizing (see PAs)	• At ML5 the focus is continual improvement of the controlled process by addressing common causes of variance (see K2), by reducing variance or improving the process capability mean

 

Comparison of SCAMPI Class Types

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit

SCAMPIsm is not a shrimp dinner (in spite of the picture), but the... Standard CMMI Appraisal Method for Process Improvement. For more information on the SCAMPI method, see the Differences page. The following table compares the major differences in the three SCAMPI method classes. The contents are based on Appendix A, of Handbook for Conducting SCAMPI B and SCAMPI C Appraisals (19-Aug-2004). The major cost saver for SCAMPI-C is team size ($$), other contributing areas indicated in light yellow ($) below. Also see changes for SCAMPI-A, version 1.2.

 

Comparison of Process Areas (PAs)
see separate file: cmmi-pa.htm

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit

Recent and Future Changes [also see CMM History] Major Changes to CMMI v. 1.2: Introduced the concept of Constellations [see architecture discussion above] Introduces the concept of Additions (referred to as Extensions in earlier publications), separate from Disciplines [see architecture discussion above] Wording added to ensure that standard processes are deployed on projects at their startup. There were also some changes to the SCAMPI-A v.1.2, which also increases scrutiny here. SS = Supplier Sourcing was was eliminated in v.1.2 Integrated Supplier Management (ISM) was folded into the baseline CMMI as part of Supplier Agreement Management (SAM) at Level 2 The specific practice associated with COTS in SAM (SP- 2.1), will move to the Technical  Solutions (TS) PA, where it is usually applied Due to increased constraints, SAM is envisioned to be the only PA where the use of "non-applicable" will be valid [on the other hand, you no longer have the option to ignore this discipline, if it is applicable] IPPD = Integrated Product and Product Development Version 1.1: Was a discipline Extended an existing PA, adding goals and practices to create IPM for IPPD Added two new PAs: OEI--Organizational Environment for Integration IT--Integrated Teaming Version 1.2: Became an Addition (rather than a discipline) Integrated goals and practices into other existing PAs: "Enable IPPD Management" in OPD "Apply IPPD Principles" in IPM Removed OEI and IT Note: the number of PAs, now remains constant, with or without the discipline Other "Improvement" Areas: Glossary improved Overview text in the first portion of the model Clarification of material based on 1000+ change requests Discipline amplifications improved Hardware amplifications and examples were added Added two specific practices to address "work environment" One to OPD for organizational view One to IPM for project specifics Eliminate the concept of Common Features (artifacts of SW-CMM) Eliminate the concept of Advanced Practices, the a few engineering-related specific practices with a capability level above 1 will be integrated into practices that are similar "Single Book" approach (CMMI-DEV) [providing separate development models no longer considered useful] On-Line Upgrade Training created to bridge from 1.1 to 1.2 Existing Lead Appraisers have to attend one-day upgrade training Available to: previous attendees of the Introduction to CMMI courses Introduction to CMMI Instructors SCAMPI Lead Appraisers SCAMPI B and C Team Leaders Major Policy Changes for SCAMPI-A v.1.2 announced 10-Sep-2006: The maximum limit, on the validity of for SCAMPI Class A appraisals, shall be three (3) years Version 1.1 SCAMPI Class A appraisals shall expire August 31, 2007, or three years after their appraisal end date, whichever is later. Any SCAMPI appraisal, with its on-site period beginning on or after November 1, 2006, whether v1.1 or v1.2, shall use the v1.2 Appraisal Disclosure Statement (ADS) and must be signed by the sponsor Class A SCAMPI v1.2 appraisals that will become public record or used in a proposal in response to U.S. Department of Defense requirements shall be led by an SEI-authorized SCAMPI Lead Appraiser from an external, third-party organization. Capability or maturity levels 4 and 5 v1.2 appraisals shall be lead by an SEI-certified High Maturity Lead Appraiser (HMLA) Initial certification requires oral examination of existing Appraisers Second phase, will require written and oral exams Other Major SCAMPI-A Changes: Removed the requirement for surveys Clarified "face-to-face" interviews to allow "virtual" interviews Added guidance on how to characterize alternative practices Set limits for the maximum length of appraisals [90 days from the first review of evidence to the completion of the on-site interviews] Added requirements for sampling and incremental appraisals Expanded the scope of the readiness reviews to include the readiness of the organization, the team, and logistics Reduced the redundancy between the Appraisal Disclosure Statement (ADS) and other appraisal documents Planned Future Changes: CMMI-ACQ -- Acquisition Constellation [see architecture discussion above] CMMI-SVC -- Services Constellation to address delivery, installation, operations, and support disciplines See on-line references.

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links  | Credit

Other Capability Maturity Models The Capability Maturity Model for Software (SW-CMM) was the first, but not the only model for improvement! Some other models include: Obsolete Models from SEI: Capability Maturity Model® for Software (SW-CMM), was incorporated into CMMI-SW [now CMMI-DEV] Integrated Product Development CMM® (IPD-CMM), renamed as Integrated Product and Process Development (IPPD), when it was incorporated into CMMI-IPPD (v.1.1) as a discipline; and as an addition in CMMI v. 1.2 Software Acquisition CMM® (SA-CMM) (See Crosstalk, March 1997), became a module for CMMI v. 1-1.1, may soon become a constellation (see Changes) Systems Engineering CMM® (SE-CMM), was incorporated into CMMI-SE See CMMI Source Documents under CMMI Technical Approach Other Models from SEI: People CMM® (P-CMM) for Training, career development, and human-resource-related issues Personal Software Processsm (PSPsm), see book by Watts Humphrey, A Discipline For Software Engineers, 1995 or article "Using a Defined and Measured Personal Software Process." IEEE Software 13, 3 (May 1996): 77-87. See also Crosstalk, Dec. 1996 Team Software Processsm (TSPsm). See Crosstalk, March 2005 Team Software Process Security, (TSP-S) an extension of TSP for evaluating application security, see security-related Crosstalk issue: Oct 2005 Other Models not from SEI: FAA-iCMM® - a completed project, similar to CMMI, developed by the Federal Aviation Administration. Although not directly responsible, the SEI did participate on the development of this model. Includes SW-CMM, SE-CMM, and SA-CMM. See FAA-iCMM® online at: http://www.faa.gov/aio/ProcessEngr/iCMM/index.htm FAA CIO website http://www.faa.gov/aio See the FAA SEPG Home Page: http://www.faa.gov/ Testing-MM (TMM) unofficial Testing Maturity Model - Crosstalk, Part 1 August 96, Part 2 Sept. 96 see Testing Technologies There is also Capability Im-Maturity Model (CIMM) - This is a tongue 'n cheek article about barriers to process improvement, by Capt. Tom Schorch (in Crosstalk, Nov 1996). Anyone who has been involved in process improvement can identify some of the "Kounter Productive Activities" in their organization! Includes levels:  0 = Negligent -1 = Obstructive -2 = Contemptuous -3 = Undermining See pages elsewhere on this site: BPR Covey Malcolm Baldrige ISO-9001 Overview and standards ITIL Quality "Standard" Six Sigma

What is CMM? | Migrating to CMMI | CMMI Architecture
SCAMPIs Comparison | Changes | Other CMMs | Related Links | Credit

Related Links

• On-line copies of CMMI can be found at: http://www.sei.cmu.edu/cmmi/
• SEI
  • SEI Appraiser Directory http://www.sei.cmu.edu/managing/appraiser.listing.html
  • Software Engineering Information Repository (SEIR) http://seir.sei.cmu.edu/
  • SEI SEMA: Semi-Annual Maturity Profile http://www.sei.cmu.edu/sema/profile.html
• SSC San Diego SEPO homepage http://sepo.spawar.navy.mil
• SEPO Documentation http://sepo.nosc.mil/Docs.html
• Scrum http://www.controlchaos.com/ (A CMM alternative which claims chaos is OK, a scrum is a team pack in rugby)
• Also see CMMI-related topics:
  • Development Standards page
  • Standards of Professionalism on SE Organization page
  • Domain Engineering and OO links
  • Management
  • Quality
  • CM
  • SEPG

Giving Credit...

^® CMM, CMMI, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
^SM CMM Integration, SCAMPI, SCAMPI Lead Appraiser, SEI (Software Engineering Institute), SEPG, IDEAL, Personal Software Process, PSP, SCE, and TSP are service marks of Carnegie Mellon University.
^® FAA-iCMM^® is registered in the U.S. Patent and Trademark Office by the Federal Aviation Administration.

©1994-2007 Gregory M. Bowen, CSDP