CMMI is the initialism for Capability Maturity Model Integration.
CMMI is a numeric scale used to “rate” the maturity of a software development process or team. Maturity can be thought of like enlightenment. An immature process is not much different from the old “infinite monkeys” yarn – maybe we get it right, but probably not. A fully matured or enlightened process not only does it right, but improves itself over time.
The Software Engineering Institute (SEI) at Carnegie Mellon (Go Tartans! BSME90) created the CMM model for software engineering in the late 80’s and early 90’s. In an effort to consolidate multiple CMM models for different process areas, the SEI team created the CMMI in 2002. In this post, we will understand what each level represents.
Technically, the name of the model is the Capability Maturity Model Integration for Software Engineering, or SW-CMM, but in practice people just use CMM. The 645 page document can be found on the CMU SEI site.
Five levels of maturity in CMMI
The folks at the SEI created five classifications or levels of process maturity. Every software project can be classified into one of the levels. The levels are progressively harder to achieve, and each builds on the previous level. To be classified in a particular level, a process must meet all of the criteria of that level. If a process meets all the criteria of level 2, and some of the criteria of level 3, then that process is considered to be a level 2 process.
Note that there is a level 0, or incomplete. This level represents the absence or incompleteness of activity. If we are developing software, we are at least at level 1.
- Performed.
- Managed.
- Defined.
- Quantitatively Managed.
- Optimizing.
CMMI Level 1: Performed
The lowest possible CMMI level (there is no level 0) represents software development essentially in the absence of a process. Specifically, the SEI defines level 1 as being achieved if the goals of the process are met. If we are trying to write software, and we write software, then we are at level 1. In practice, level 1 processes are the ones described as chaotic and unordered. A team with a level 1 process can easily be dependent upon individual effort for success.
Most small software companies, independent developers, as well as many corporate IT departments operate at level 1. If we can point to projects that were “saved” by a superstar on the team, we are probably operating at CMMI level 1. We love having superstars on our teams – we hate being dependent upon them for survival.
CMMI Level 2: Managed
SEI defines CMMI level two as follows:
A managed process is a performed (capability level 1) process that is also planned and executed in accordance with policy, employs skilled people having adequate resources to produce controlled outputs, involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.
Our interpretation: take a CMMI level one process, and add a project manager to coordinate the chaos. The distinction is that at this level, the activities are planned, and then managed according to the plan. No additional insight is applied, just orchestration.
CMMI Level 3: Defined
To achieve CMMI level three, we have to take a process that qualifies for CMMI level two, and institute it as a corporate standard. Then we tailor and apply that standard process to individual projects.
CMMI Level 4: Quantitatively Managed
When we incorporate quantitative measurement or statistical analysis tools as part of our process management process, we are operating at CMMI level four. This level represents “hard” introspection that utilizes quantified data to improve the management of the current project within our defined project.
CMMI Level 5: Optimizing
When we analyze the quantitative data from our projects and apply it to refining our processes for the future, we are operating CMMI level five. This level represents an introspective approach to quantitative project management, combined with a continuous improvement objective.
Articles In This Series
- Foundation Series: CMMI Levels Explained
- What CMMI Level Should We Use?
- CMMI Levels and RMM Introduction
- CMMI Levels and RMM Level 1 – Written Requirements
- CMMI Levels and RMM Level 2 – Organized Requirements
- CMMI Levels and RMM Level 3 – Structured Requirements
- CMMI Levels and RMM Level 4 – Traced Requirements
- CMMI Levels and RMM Level 5 – Integrated Requirements
- Don’t forget to take our One Minute Survey on CMMI and RMM.
– – –
Also check out the index of the Foundation Series posts for other introductory articles.
I like what Demarco and Lister have to say about CMM in Peopleware: Productive Projects and Teams. Some quotes:
“The paradox of the CMM is that process improvement is good, but process improvement programs aren’t, or at least they often aren’t.”
“When process improvement (as in ‘Level 3 by the end of the year!’) becomes the goal, the scary projects get put onto the back burner. It’s those scary projects, unfortunately, that are probably the ones most worth doing.”
“Organizations become more and more averse to risk as they ‘mature’. An organization under the gun to demonstrate increased CMM level is not going to go looking for a real challenge.”
“The projects most worth doing are the ones that will move you DOWN one full level on your process scale.”
And finally:
“Identifying an ideal practice, or at least a candidate ideal practice, is a useful endeavor. But the programs that mandate such a practice are something else entirely.”
Thanks Roger – I haven’t read that piece yet. They do raise a great point – that it’s easy to lose sight of the goal. I think of the wide receiver who focuses too much on running and avoiding tackles and fails to catch the ball.
Doing the job is most important, getting better at doing it is secondary.
Most of the people I’ve worked with are either overly focused on tactical execution, and fail to catch the ball, or they are rabidly intent on catching the ball, and then they get tackled immediately. The first group never scores, the second group scores less frequently.
CMMI can be used most effectively as a means to provide benchmarking of internal improvements, it shouldn’t be the driver of change. Achieving a particular CMMI level is not valuable. Having a process that would be measured at a CMMI level is valuable.
Thanks!
CMMI is not just for software engineering or IT, it also includes systems engineering. There was a SW-CMM, but it was retired and replaced by CMMI.
CMMI is compatible to ISO9000-2000. ISO9000-2000 is the certification for meeting international standard in quality management by an enterprise. CMMI defines the best practices, at each level, for enterprise processes. When a company is certified at level 5 of CMMI, many large organizations (e.g. US Department of Defence – the largest purchaser of technologies, services, and products in the world) accept the bids from that company immediately, without reference check, if the prices are right.
By the way, Systems Engineering is the discipline that oversees all activities carrying out by other professional disciplines (IT and Software Engineering included) over the product life cycle of every product from inception to disposal. US Air Force was the original sponsor of CMM and CMMI. The Defence and Aerospace industries are now also active stakeholders of CMMI, but US DoD remains the key stakeholder. A representative from US DoD signs every release of CMMI. The prime reason for having CMM and CMMI is that many products and systems are software intensive. US DoD wants its suppliers not only ISO9000-2000 certified but also at least CMMI Level 3 and EVMS certified! EVMS (Earned Value Management System), an international project management standard for reporting and measuring project progress, is one of the quantitative managed processes in Project Management. There is a signed agreement between US, UK, Canada, Australia, and New Zealand on EVMS standard. When a company gets EVMS certified in one country, other countries recognize the certification.
The attempt in matching the levels in CMMI against RMM is an interesting academic exercise, but it compares apples and oranges. Moreover, Requirements Management is one set of processes within CMMI!
Nice point about the Superstars in Level 1. It reminded me of an article on forming alliances that referred to these “Superstars” as “wounded princes (which meet an unwholesome end). That put a different take on it for me.
Hey Justin, thanks for commenting, and welcome to Tyner Blain!
I’m not quite sure how you connect the superstars who make things happen with the wounded princes who feel threatened by change. Regardless, thanks for the link to the article. I love it when someone (in any context) appreciates that people trump process (and mergers)!
I remembered this blog entry when I saw Jerry Weinberg post the following tweet:
“Maturity Models Have It Backwards http://amplify.com/u/qy0“
Funny!