Process Maturity Models: ISO 9000 and CMMI
In short Maturity models describe how an organization’s way of working evolves from improvised to measured and continuously improving. ISO 9000 offers general quality management principles; CMM and CMMI give software and systems organizations a staged path, with requirements management among the first practices to establish.
Based on: Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture notes (in Russian), lecture 8; K. Wiegers, Software Requirements, 2nd ed., appendix B.
On this page
Key ideas#
ISO 9000#
The ISO 9000 family grew out of continuous process improvement and Total Quality Management (TQM), ideas widely credited with helping Japan’s post-war industrial recovery. The quality management principles behind ISO 9001:2000 are customer focus, leadership, involvement of people, a process approach, a system approach to management, continual improvement, decisions based on facts, and mutually beneficial supplier relationships.
Maglinets notes its strength (proven in many organizations worldwide) and its weakness (the guidance is general and ignores the specifics of IT). IT-specific models include SEI CMM and CMMI, ISO/IEC 15504 (SPICE), Bootstrap and TickIT.
CMM: five maturity levels#
The Capability Maturity Model (CMM), from the Software Engineering Institute (SEI) at Carnegie Mellon University, rates a software organization on five levels: initial, repeatable, defined, managed and optimizing. From level 2 upward, each level is defined by key process areas.
In the original software CMM (SW-CMM), as Wiegers describes it, requirements management sits at level 2, alongside project planning, project tracking, subcontract management, quality assurance and configuration management. There is no separate area for developing requirements; that work is partly absorbed into software product engineering at level 3.
CMMI#
CMMI for systems and software engineering (CMMI-SE/SW, 2000) integrates the earlier models and has two representations: - Staged: five maturity levels and 22 process areas. Level 2 (managed) includes requirements management, project planning, project monitoring and control, supplier agreement management, measurement and analysis, quality assurance and configuration management. Level 3 (defined) adds requirements development, technical solution, product integration, verification, validation and risk management, among others. Levels 4 (quantitatively managed) and 5 (optimizing) add quantitative control and continuous innovation. - Continuous: the same process areas, grouped into four categories (process management, project management, engineering, support), each rated on its own capability level. An organization can decide how far to develop each area independently.
Why requirements management comes first#
Requirements management is at level 2 because it makes projects predictable: agreed baselines, controlled changes, and traceability. In CMMI, traceability explicitly includes recording where each requirement came from, tracing it down to the work products that implement it, and linking related requirements to each other. Only at level 3 does the model ask for better requirements development: deriving customer requirements from stakeholder needs, allocating product requirements to components and interfaces, and validating derived requirements.
This does not mean you skip gathering requirements until level 2. It means controlling them is the first step toward predictable delivery, and improving how you develop them comes next.
How to improve: a cycle from Wiegers#
Wiegers, as summarized by Maglinets, recommends improvement that is gradual, continuous, cyclical, driven by real pain, aimed at clear goals, and run as a project. A typical cycle: 1. Assess current practice through interviews, workshops and an as-is model. Outside consultants help keep the assessment impartial. 2. Plan: a strategic plan plus short action plans of no more than ten items, each finished within two to three months. 3. Create and pilot new processes: evolution, not revolution. Pilot on real projects with open-minded participants. 4. Evaluate and decide: allow for the learning curve. Productivity usually dips while people learn the new way, before it improves.
How to apply it#
- Use maturity levels as a diagnostic, not a badge. Ask which missing practices make your projects unpredictable.
- If requirements changes keep derailing projects, start with level 2 basics: baselines, a change process and traceability.
- If projects are predictable but requirements are weak, invest in level 3 practices: structured elicitation, modeling and validation.
- Keep each improvement action small and time-boxed, and pilot it on one project.
- Warn sponsors about the learning-curve dip before it happens.
Example#
The outside development team working for The Workshop, a fictional bike-repair chain, keeps missing release dates because requirements change by phone and email. A quick assessment against level 2 practices shows no baseline and no change log. The action plan for the next quarter has three items: agree a requirements baseline for each release, route every change through one change log reviewed weekly with the owner, and trace each change to the affected user stories. Better elicitation waits for the next cycle.
Pitfalls#
- Chasing a certificate → solve the problems that hurt delivery.
- Changing everything at once → keep action plans short and time-boxed.
- Mixing up scales → CMMI rates software and systems organizations; the BPM CBOK scale rates enterprise process management.
Sources and further reading#
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 8 “Improving requirements processes” (ISO 9000, SEI CMM/CMMI, Wiegers’s improvement cycle).
- K. Wiegers. Software Requirements, 2nd ed. Microsoft Press, 2003, appendix B “Requirements and Process Improvement Models” (SW-CMM and CMMI-SE/SW).
- ISO 9001:2000; SEI CMM and CMMI-SE/SW, as described in the two works above.