Using a framework such as a Capability Maturity Model (CMM) brings many benefits to any organization, for any project or program.
Would you eat in a restaurant that had not been inspected periodically by the local inspector? Of course, you would not – because you could not be sure that the restaurant followed the best sanitary practices as a matter of routine. But passing the inspection doesn’t guarantee good food. In fact, I recall a restaurant in Philadelphia with excellent food that probably could not have passed such an inspection. What we do know is that there are certain best practices that restaurants must follow to guarantee the food is safe, regardless of the quality of the product. Guaranteeing that the food and workplace are safe is the goal of the restaurant inspector; he does not guarantee the tastiness of the food. To a certain extent, this is what the Capability Maturity Model (CMM)1 seeks to do – establish a set of practices by which to benchmark the quality of software development organizations. Those that achieve the highest level of certification are expected to produce quality (and possibly good) software, or other functions such as enterprise data management . Those that don’t follow even the minimum recommended practices might offer good software or data management, but we have no confidence that it was developed in the best way (much like that restaurant in Philadelphia).
Many believe that software development or data management organizations should conform to certain accepted practices to attempt to guarantee that the function meets some level of quality and consistency. With the debates about outsourcing and off-shoring of software development, and the continuing concerns over the challenges of managing data as an organizational resource, the issues of quality and consistency are foremost in the minds of many business and IT management.
The Capability Maturity Model was designed to address the need to understand what practices a software development organization follows routinely so partners, customers, and other consumers of the software can rest assured that the right “safety” procedures were followed. Whether the software performed as expected is not within the goals of the CMM, but software developed within the guidelines of the Capability Maturity Model might be “tasty” as well as “safe.” Subsequently, the CMM has been extended to include the practices for enterprise data management, to allow an organization’s data management practices to be measured against relevant industry standards and best practices. For more information on a specific enterprise data management maturity model, click here.
The information systems community has developed a long-standing reputation for poor quality in their product development and delivery, and in the management of data and information. As evidenced by the need for multiple “patches,” incremental “releases”, supplemental “upgrades” to packaged software and custom-designed applications, along with the challenges in all the components of data management, many organizations need to improve the quality of their practices in software development and in data management.
There have been several programs that attempt to address the identification of quality and its improvement for manufacturing processes (e.g. Total Quality Management, ISO 9000, and Six Sigma). These programs were designed primarily for measuring quality in generic manufacturing processes, and may not be very useful in the realm of software engineering or data management, with their amorphous development phases and their need to depend on input from user communities and the reliance on increasingly advanced information technology.
Capability Maturity Model History
In 1984, the Software Engineering Institute (SEI) was founded at Carnegie Mellon University as a federally funded, non-profit organization, responding to the need for a software-oriented process improvement technique. The purpose of the SEI was to establish protocols and methodologies in the field of software development that would assist the United States to maintain a competitive edge in technological endeavors, especially in the improvement of the practice of software engineering.
One of the early results of the SEI’s efforts was the development of a “Capability Maturity Model” (CMM), based on the work of Watts Humphrey at IBM. This model strives to assist organizations in improving the quality of their software development through implementation of processes that are “mature,” meaning that these processes have a high predictability of results and low risk of encountering unknown variables or situations. The model takes an organization through five scales, from Level 1 (Initial) through Level 5 (Optimizing), and measures the operation’s effectiveness at each level based on assessment of certain areas.
Capability Maturity Model Benefits
Benefits to using a process improvement framework such as the CMM have been identified by numerous researchers, both academic and professional, and would include:
- More accurate identification of flaws in process development operations
- Reduction in cost of software development or management of data as a resource
- Increase in productivity from software development and / or data management professionals (staff and contractors)
- Reduction in post-release defects and essential enhancements
- Reduction in time-to-market for implementation
The Capability Maturity Model, whose first version was released in 1991, is based on actual industry practices, reflects the best practices of the industry, and reflects the needs of individuals performing software process improvement and process appraisals (measurement and benchmarking). The CMM is intended to be a cohesive, coherent, ordered set of incremental improvements, all relating to experienced success in the field, and packaged into a framework that demonstrates how effective practices can be built on one another into a logical and repeatable progression. Far from a “quick fix,” successful use of the CMM requires attention to detail, support, and participation from senior management and a rational approach to all aspects of software development or data management, and implementation.
Many organizations raced to embrace the CMM, recognizing the high costs of poor quality software development and implementation. However, their enthusiasm in adopting the CMM was not accompanied by an understanding of the foundations of quality improvement and the CMM’s role in assisting organizations to recognize and implement consistent quality improvement methods. Before implementing the CMM, organizations must understand fully the history of quality and process improvement methodologies, and the place the CMM holds in this environment.
Figure 1: Levels of the CMM: (from www.dis.wa.gov/portfolio/tr25/tr25.html )
Initial Level (ad-hoc, immature): At the initial level, the organization typically does not provide a stable, consistent environment for developing new products or processes. When an organization lacks consistent project management practices, the benefits of good integrated product development practices are undermined by ineffective planning and reaction-driven commitment systems.
Repeatable Level: At the repeatable level, policies for managing a development project and procedures to implement those policies are established. Effective management processes for development projects are institutionalized, which allow organizations to repeat successful practices developed on earlier projects, although the specific processes implemented by the projects may differ.
Defined Level: At the defined level, the standard process for developing new products is documented, these processes are based on integrated product development practices, and these processes are integrated into a coherent whole. Processes are used to help the managers, team leaders, and development team members perform more effectively.
Managed Level: At the managed level, the organization establishes metrics for products and processes and measures results. Projects achieve control over their products and processes by narrowing the variation in their process performance to fall within acceptable boundaries. Meaningful variations in process performance can be distinguished from random variation (noise).
Optimized Level: At the optimized level, the entire organization is focused on continuous process improvement. The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing the occurrence of defects. Data on the effectiveness of the development process is used to perform cost benefit analyses of new development technologies and proposed changes to the organization’s development process. Innovations that exploit the best-integrated product development practices are identified and transferred throughout the organization.
If an organization of any size truly is interested in discovering an approach to process improvement in their software development and integration, or enterprise data management efforts, a study of the Capability Maturity Model and the practices it encompasses is a fine place to start. CMM-related efforts can be as simple or detailed as the organization needs or desires, but education in the model and its techniques is essential for a successful self-assessment and any improvement activities that arise from the results of the assessment.
1 For those purists, yes, I know it’s “CMMI” for Capability Maturity Model Integration, the successor to the original CMM. CMMI is the generalized version of the software CMM that encompasses the total system, including software. Nevertheless, this article uses “CMM” throughout without loss of generality.