Capability Maturity Model [CMM/CMMI]
written by gunther gerlach-2009
The CMMI is a collection of best practices for the development and maintenance of both products and services. It was developed to enhance and replace the use of multiple process models, while preserving the government and industry investments in process improvement. By combining multiple models into a single model, the CMMI has enabled the use of common terminology, components, appraisal methods, and training material across multiple disciplines. This, in turn, reduces the cost of establishing and maintaining process improvement efforts across the enterprise using multiple disciplines to deliver products or services. The CMMI currently covers systems engineering, software engineering, integrated product and process development, and supplier sourcing. The CMMI represents the consolidation of the following models:
SW-CMM: Capability Maturity Model for Software.
SECM: Systems Engineering Capability Model.
IPD-CMM: Integrated Product Development Capability Maturity Model.
The CMMI represents the incorporation of many improvements and lessons learned from earlier model use.
A supplier claiming to be Level 3 is no guarantee that the project within the supplier’s organization is following the organization’s processes. The only way an acquirer has to determine that the people actually doing the work are following mature process is to do a SCAMPI “B” or “C” assessment of the supplier. From the acquirer’s perspective, SCAMPIs are used as a risk identification and mitigation tool, so they must be performed on the groups doing the acquirer’s work.
Key CMM Concepts
Before we walk through the CMM’s six levels it is important to understand the five key concepts. These concepts are Consistency, Repeatable, Transferable, Quantitative and Qualitative. As I walk through these vital concepts I will use the IT task of project planning for illustrative purposes.
CMM Levels
The CMM is designed to be an easy to understand methodology for ranking a company’s IT related activities. The CMM has six levels 0 – 5. The purpose of these levels is to provide a “measuring stick” for organizations looking to improve their system development processes.
· Level 0 – Not Performed
· Level 1 – Performed Informally
· Level 2 – Planned and Tracked
· Level 3 – Well-Defined
· Level 4 – Quantitatively Controlled
· Level 5 – Continuously Improving
Level 0: Not Performed is common for companies that are just entering the IT field. At this level there are few or no best practices. Some IT activities are not even performed and all deliverables are done in “one-off efforts.” Typically new applications are built by a small number of people (possibly even one person) in a very isolated fashion.
Level 1: Performed Informally consistent planning and tracking of IT activities is missing and deliverables are accomplished via “Heroic” effort. “Heroic” effort means that a team might work long hours in order to build a particular application; however, there are very few IT standards and reuse/sharing is minimal. As a result, IT deliverables are adequate; however, the deliverables are not repeatable or transferable.
As a general rule, the amount of money a company spends on their IT applications does not impact what CMM level they are at. The closest exception to this rule is the move from Level 0 to Level 1. Typically, a company can move from level 0 to level 1 as a by-product of elevated IT spending. Aside from this exception, moving beyond level 1 is not impacted by money spent. A corporation could be spending well over $500 million on application development and be at this level. Indeed, the vast majority of Fortune 500 companies and large government organizations are at a CMM level of 1.
Level 2: Planned and Tracked has IT deliverables that are planned and tracked. In addition, there are some defined best practices within the enterprise (e.g. defined IT standards/documents, program version control, etc.). Some repeatable processes exist within an IT project team/group, but the success of this team/group is not transferable across the enterprise
Level 3: Well-Defined IT best practices are documented and performed throughout the enterprise. At level 3 IT deliverables are repeatable AND transferable across the company. This level is a very difficult jump for most companies. Not surprisingly, this is also the level that provides the greatest cost savings.
Level 4: Qualitatively Controlled it have established measurable process goals for each defined process. These measurements are collected and analyzed quantitatively. At this level, companies can begin to predict future IT implementation performance.
Level 5: Continuously Improving it have quantitative (measurement) and qualitative (quality) understanding of each IT process. It is at this level that a company understands how each IT process is related to the overall business strategies and goals of the corporation. Every programmer should understand how each line of SQL will assist the company in reaching their strategic goals.
Without focusing on the PI–process improvement–part of SCAMPI all you get is a SCAM. Too often, acquirers demand CMMI maturity or capability levels and rely heavily upon those claims without an adequate understanding of their impact upon the work that will be performed for the acquirer. Acquirers, also, too often do not effectively utilize the SCAMPI or other appraisal methods when performing supplier monitoring and oversight. These appraisal methods allow the acquirer to tailor the appraisal scope to target specific appraisal goals and information needs in order to identify the salient risks associated with the given supplier. Those same risks, defined as weaknesses associated with individual process areas, can be tracked or monitored as the contract progresses by doing the following:
· Identifying software-related risks
· Developing a plan to mitigate the risks
· Performing trade-off analyses to establish levels of surveillance for weak areas that need improvement and critical areas where performance must be maintained
· Defining adequate reporting or insight, through the use of metrics, to be provided to the program office to facilitate continuous monitoring.
It has been shown that an acquirer with low process maturity is at greater risk of having its program delivered over cost, behind schedule, and with reduced functionality and/or avoidable defects, even if the supplier is of a higher maturity; the result is a disparity in maturity, as shown in the graphic on the previous page. For example, acquirers may try to development and management processes because they feel that following the process impacts their ability to meet the goal, resulting in network or cost and schedule increases–which is exactly what the processes were designed to avoid in the first place.
To help the acquirer avoid such disparities, the Software Engineering Institute has developed the CMMI Acquisition Module (CMMI-AM), which defines effective and efficient practices performed by acquisition professionals in an acquisition program office. It provides a foundation for acquisition process discipline and rigor that enables product and service development to be repeatedly executed with high levels of acquisition success.
In order to avoid the feeling of being cheated or scammed, it is not enough simply to hire a supplier that claims to be of high CMMI capability or maturity. Without addressing the weaknesses of a supplier or at least taking the time to understand why they are considered weaknesses and making a conscious decision as to how to handle or not handle the weaknesses, one cannot influence the outcome or products. In addition to a supplier’s capabilities and maturities, the acquirer must also perform at a high maturity–or the supplier’s abilities really won’t matter.
