Beside my desk is a picture of a skyscraper that is under construction to remind me that every impressive work of architecture goes through a maturation process. I printed the picture to bring to my start-up company’s first annual holiday party.
All man-made things of beauty go through a construction phase.
The purpose of the picture was to make a point that architects do not get discouraged when the wind blows through their creation, because all skyscrapers are built the same way—one I-beam at a time. This imagery has helped me to keep perspective since giving that talk at that holiday party over ten years ago.
In the early 1990’s the Software Engineering Institute (SEI) introduced the Capability Maturity Model. The SEI CMM was a set of guidelines for improving the software development process. This maturity model has its roots in the Total Quality Movement and was based on Philip Crosby’s notion that an organization will go through five maturity levels.
Since the Software Engineering Institute first published the capability maturity model, many other organizations have adapted the concepts to process maturity above and beyond software development.
Some good examples of this include:
- Organizational Project Management Maturity Model (OPM3),
- The Open Group Service Integration Maturity Model (OSIMM), and
- The Building Security In Maturity Model (BSIMM4)
Despite its legacy as one of seminal frameworks for understanding process capability, many folks do not understand the high level concepts of the CMM. One reason for this may be that to fully implement the CMM requires a certain amount of rigor that many equate to high dollar consulting invoices. Or perhaps they have had exposure to frameworks such as ISO 9000, ISO 27000, or COBIT that left them buried with compliance tasks.
I encourage you to set aside the baggage of frameworks and take a fresh look at some of the conceptual elements of the Capability Maturity Model. I think that this will give you a fresh way of looking at organizational and personal change.
Maturity Levels
There are five levels in the CMM. I use the acronym “IRDMO” to remember them, in order. These are:
- Initial – Few processes are defined and success depends on individual effort and heroics
- Repeatable – Basic processes are in place with enough discipline to repeat earlier successes
- Defined – The processes are documented, standardized, and integrated across the organization
- Managed – Quantitative measures are used to understand the process and product quality
- Optimizing — Innovative continuous improvement is enabled by quantitative feedback
The 5 Levels of the Capability Maturity Model
A start-up software company will often have just a handful of rock star software developers that make all of the magic happen. Next comes the Repeatable level, where someone else (typically not one of the rock stars) tries to document how the magic happens. This level cannot be rushed through too quickly because processes need time to mature. Expect the process documentation to undergo multiple revisions as it is frequently rewritten to reflect how things are really being done. Some of the software rock stars may leave the organization because they feel that they are being constrained by bureaucracy, but others will become leaders. Eventually, but only because of intentional management focus, the software development process will become well-documented and people will be held accountable to follow the written processes. Metrics used to control the software process are the hallmark of the Managed level. Once the metrics are used to make data-driven decisions that drive innovational improvements to the software development process and the software product itself, the organization has achieved the Optimizing level.
Key Process Areas
Another important conceptual element of the CMM is the construct of “Key Process Areas.” According to SEI, “each key process area is a cluster of related activities, that when performed collectively, achieve a set of goals considered important for enhancing process capability” (Software Engineering Institute, 1994). The CMM goes on to define key practices that comprise each of the key practice areas, but the details of this are beyond the scope of this article.
Once the requirements for all key process areas at a certain maturity level are met, and the requirements for the preceding maturity levels, then the organization is said to have attained that maturity level.
Each of the maturity levels of the CMM form a foundation for the next level of maturity. For this reason, skipping levels is generally counterproductive. The important take-away here is that if you work on the key practices that are above your maturity level, the process improvement will be unsustainable!
Crawl – Walk – Run
The CMM is rich with detail about how an organization can improve their software engineering processes. It also serves as an excellent model for other maturity frameworks. I have found the descriptions of the characteristics of an organization at each level to be the most helpful because it helps me to evaluate my own operation and those of my business partners and vendors.
However, the most important realization is that it is foolish to try to run before you can walk, and to try to walk before crawling. Each stage is important to proper development.
Also, remember that just because a particular organization is at a specific maturity level doesn’t necessarily mean that its managers don’t know how to build capability in that organization. That would be the same mistake as thinking that a construction company doesn’t know what they are doing because their skyscraper is unfinished.
Reference
Software Engineering Institute. (1994). The capability maturity model: Guidelines for improving the software process. Reading, Massachusetts: Addison-Wesley.