What is CMMI?
CMMI is a collection of best practices used by software, hardware, IT development, and service organizations to improve their cost, schedule and quality results. It is organized into a roadmap that can be implemented incrementally over time.
- CMMI for Development Summary
- CMMI for Services Summary
- Changes from CMMI V1.3 to V2.0
- Formal and informal CMMI appraisals
- Custom appraisals using your criteria
- CMMI for Development resource page
- CMMI for Services resource page
- Integration with Agile/PMBOK
The Capability Maturity Model Integration (CMMI) for Development is a collection of practices aimed at organizations that develop products, systems and IT solutions. The model is organized into maturity levels, each level defining more advanced practices to improve schedule, budget, risk and quality performance. The levels provide a road map for sustained incremental improvement. Example development organizations that use CMMI for Development are:
- Software application / embedded
- IT solutions
- Hardware (electrical, mechanical, optical, electronic)
- Systems engineering (large software or hardware systems or a software/hardware combination)
See link: Who Uses CMMI?
The purpose of using any framework is to improve the performance of an organization. For a group that develops products, this can include: improving schedule and budget accuracy, managing risks, eliciting requirements, defining designs, implementation, finding defects early, reducing rework and sharing best practices across the organization.
CMMI practices can be implemented within any life cycle or methodology (such as Scrum, Waterfall, Spiral, Incremental or a hybrid).
The benefits from using CMMI practices are to:
- Clarify customer requirements early
- Scope, plan, estimate and negotiate work to manage expectations and achieve commitments
- Track progress to know project status at any time
- Maintain defined quality standards throughout the organization and report strengths and problems to management
- Manage versions of documents, drawings and code so that time is not wasted using incorrect versions or recreating lost versions
- Manage and coordinate multiple teams that have cross dependencies
- Employ engineering practices for design, implementation, verification and testing to reduce defects
- Use defect data to understand and manage work quality throughout the project
- Collect lessons learned and project data to systematically improve future organizational performance
Which CMMI Version Should You Use?
Here is our guidance for which version to use:
|Your Situation||Our Recommendation|
|Starting out with CMMI||Use 2.0|
|Want a lighter weight model to use that focuses the organization on improvement with required management support written into the model||Use 2.0|
|Renewing an appraisal rating >= 4Q2020 (V1.3 will sunset 30 September 2020)||Use 2.0|
|Renewing an appraisal rating <= 2Q2019||Use 1.3|
|Renewing an appraisal rating between 3Q2019 and 3Q2020||Use 1.3 or 2.0|
Summary of the CMMI for Development models.
There are two versions of the CMMI available (the legacy 1.3 version and the new 2.0 version.) V2.0 was released in 2018. V1.3 expires in September 2020.
When used correctly, both provide the same benefits of performance improvement. The difference is that V2.0 explicitly states that performance should be measured and improved, and includes a specific set of practices (the GOVernance practice area) to help senior management lead the way. The picture below shows a simple comparison of the two models.
The Process Areas / Practice Areas (PA) are summarized below.
Configuration Management (CM): Establish and maintain the integrity of work products using configuration identification (labeling), configuration control (known modifications and permission to modify), configuration status accounting (final status of work products), and configuration audits (checks to verify changes).
Measurement (was MA, now MPM): Develop and sustain a measurement capability that is used to support management information needs.
Planning and Estimation (was PP, now PLAN+EST): Establish and maintain plans (major tasks, estimates, stakeholders, risks and resources) for project work.
Monitoring and Control (was PMC, now MC): Understanding the group’s progress so that appropriate corrective actions can be taken when performance deviates significantly from the plan.
Process/Product Quality Assurance (was PPQA, now PQA): Provide staff and management with objective insight into processes and associated work products.
Requirements Management/Development (was REQM+RD, now RDM): a) Define requirements baselines for a project, b) manage changes so that technical and resource impacts are assessed, c) trace requirements to related downstream work products so that test coverage of requirements can be performed and the impact of requirements changes assessed with more accuracy, d) analyze requirements for ambiguities and errors.
Supplier Agreement Management (SAM): Manage the acquisition of products and services from suppliers. This model component can be declared Not Applicable (after discussion with the appraiser) if there are no custom, risky, or integrated suppliers.
Technical Solution (TS): Select among design alternatives, perform design activities and implement the design.
Product Integration (PI): Plan and execute integration testing of components as they are completed, or when all components are complete. Check that interfaces are correct before spending time in system testing. Communicate interface changes to impacted areas.
Verification and Validation (was VER+VAL, now VV+PR): a) Perform peer-reviews (PR) on selected documents and code to find errors early and quickly, b) Plan and execute component level testing and analyze the results (e.g., defect density, defect pass rate, defect escape rate and root cause), c) Plan and execute testing focused on the end-user’s environment and needs, d) Analyze the results (e.g., defect density, pass rate, escape rate and root cause).
Process Focus/Management (was OPF, now PCM): Coordinate all improvements. Take what is learned at the team level and organize and deploy this information across the organization. The result is that all teams improve faster from the positive and negative lessons of others.
Process Definition (was OPD, now PAD): Organize best practices and historical data into a useful and usable library.
Organizational Training (OT): Assess, prioritize and deploy training across the organization, including domain-specific, technology and process skills needed to reduce errors and improve team efficiency.
Integrated Project Management (was IPM, now PLAN and MC): Perform project planning using company defined best practices and tailoring guidelines. Use organizational historical data for estimation. Identify dependencies and stakeholders for coordination, and comprehend this information into a master schedule or overall project plan. As project work progresses, coordinate all key stakeholders. Use thresholds to trigger corrective action (such as schedule and effort deviation metrics).
Risk Management (was RSKM, now RSK): Assess and prioritize all types of risks and opportunities in a project and develop mitigation actions for the highest priority ones. Start by considering a predefined list of common risks and use a method for setting priorities.
Decision Analysis and Resolution (DAR): Systematically select from alternative options using criteria, prioritization and an evaluation method.
Causal Analysis and Resolution (CAR): Was at Level 5, now a simpler implementation starts at Level 3.
- CMMI V1.3: Condensed list of Level 2 and 3 practices: http://www.processgroup.com/condensed-cmmi1p3-dev-v1.pdf
- CMMI V1.3 full model text: PDF
- CMMI V2.0 Condensed list of practices: PDF — account registration required
- CMMI V2.0 full model text: Web viewer + PDF option — account registration needed + fee
The Process Group is a CMMI Partner