SINCE ITS INTRODUCTION JUST OVER 15 YEARS AGO, THE CAPABILITY MATURITY MODEL HAS QUICKLY become a major player in the IT world of process improvement and quality management. Today, it runs second only to its more established relative, the ISO 9001 program, in acceptance and use around the world. And in terms of momentum, CMM is probably leading. It is being adopted as the preferred IT quality standard by more and more businesses, organizations, and government agencies. With ISO and Six Sigma, it has taken its place as one of a trio of quality management options the executive world is looking to. Its rising popularity can be attributed to many factors. It is relatively compact. It is specifically shaped to the needs of technology development. And it is a public-domain specification, free to anyone who wants to use it.
Perhaps more important, the CMM framework has been proven to work. Its benefits have been demonstrated both quantitatively and qualitatively. The corporations that have adopted its recommendations and consciously applied them within their technology development projects have seen measurable performance improvements. Planning estimates and projections have become more accurate. Work paths have become more established. Efficiencies have increased. Defect rates and rework have dropped.
And so, CMM's potential for impact makes it a worthwhile model that should be at least tangentially understood by IT management across corporate America. For that reason, I'll now take a look at what the Capability Maturity Model is all about.
I'll do that in this section by presenting an overview of the most current version of the Capability Maturity Model, the CMMI-DEV. The "I" in the model's name stands for "integration." As we'll see, CMMI is an extension of the CMM. It both expands and refines the CMM by incorporating generic approaches for software engineering, systems engineering, and integrated process and product development together into a single framework. And it does this while allowing for greater flexibility in reaching the model's goals. The "Dev" stands for Development. The CMMI-Dev (version 1.2) is the model useful for technology organizations that have to develop products, processes, or both for their customers. (There is also a CMMI-ACQ model for Acquisitions, but discussion of this model is not in the scope of this book.)
But before we look at the components that make up the Capability Maturity Model Integration, let's take a brief look at the history of the model and its parent organization, the Software Engineering Institute.
The Capability Maturity Model, and its evolution into CMMI, began in the wake of the PC revolution in the early 1980s. During that time, data-processing departments across America underwent an abrupt and radical change. The once predictable landscape of centralized processing, batch loads, and dumb terminals gave way to a kaleidoscope world of personal computing. This change split the discipline of data processing two ways. First, it discarded the concept of "stability through limitation." Computer departments were now faced with a myriad of options, a constantly changing (to this day) sea of choices. New architectures, programming languages, database systems, spreadsheets, and communications avenues all promised to deliver a host of rich and robust capabilities that were faster and cheaper than ever before.
Second, and perhaps more important, the control of technology moved from the back room to the front desk. Personal computing became people computing. Users gained an unprecedented degree of control over what popped up on their screens. And they quickly became a savvy bunch to deal with.
In the span of a decade, factors such as choice and accessibility, falling costs, and rising performance flipped data processing from being load-driven to being demand-driven, so much so that today we no longer "process data," we "manage information." DP is now IT. And software, once an adjunct to any business, has now become fully absorbed by business. The two have become inseparable. This integration became apparent quickly. Even in the mid-80s, the dominance of this trend was making headlines in technology circles. And its impact was being seriously assessed. The effective management of software and technology directly translated into business success. This rationale extended a step further: for America to compete in a rising global economy, it needed resources for effective technology management.
That conclusion did not go unnoticed by technology theorists, politicians, and corporate strategists. These new technology dimensions were recognized as part of a permanent shift in the dynamics of information management. And the theorists, politicians, and strategists knew the weight of this shift. These disparate parties organized their voice into one and appealed to the U.S. Congress to establish a national resource for advancing knowledge of software engineering and technology, and to address what was seen as a growing need for effective technology-management models.
Congress responded by establishing the Software Engineering Institute at Carnegie Mellon University in Pittsburgh, Pennsylvania. The SEI was chartered to operate in the public interest as a federally funded research and development center. Placed under the sponsorship of the U.S. Department of Defense, the SEI began its mission with work on a framework for quality management in the arena of software development. That framework became the Capability Maturity Model.
At the time, quality management models for the manufacturing industry were in full bloom. The ISO 9000 series was enjoying broad interest. Japanese innovations like Just-in-Time delivery, Assembly-Line-Control, and LEAN were attracting worldwide press. Six Sigma was emerging at places like Motorola and General Electric. The SEI was taking a close look at all of these. And it was also dissecting the work of noted American experts on quality. The work and philosophies of quality pioneers such as Philip Crosby, Malcolm Baldridge, George Box, and Edwards Deming were explored and analyzed for application. This effort culminated in 1987 with the publication of Watts Humphrey's book Managing the Software Process (Addison-Wesley Professional). The book synthesized the critical thinking in quality management and applied it to a series of practical steps, organized by maturity levels, that an organization could undertake to manage its development projects. Later that year, the SEI used Humphrey's approach as the basis for version 1.0 of the Capability Maturity Model. The name reflects the attitude of the quality approach: the more mature an organization becomes in its use and management of process, the greater its capabilities grow.
The CMM was founded on two well-known quality principles. The first is the idea that "process works." In other words, in the manufacturing realm, where you execute a series of distinct steps to create a final product (whether that's coat hangers or surgical lasers), a proven, tested process will ensure better quality than a haphazard, ad hoc one. The second principle is "a performing organization is a learning organization." The idea here is that successful cultures succeed through continuous innovation and improvement, and for those traits to exist, the organization must operate in learning mode, in a mode where it regularly assesses its performance and looks for ways to do its work better. The organization welcomes self-consciousness.
Those two principles were new to the newly transformed technology industry. But the Department of Defense, the SEI's official sponsor, saw the value and was first to broadly adopt the model. Soon it was able to demonstrate CMM's effectiveness. That led to the CMM's wide dissemination. Within five years, over 5,000 IT organizations had adopted the CMM as a working quality model. The SEI meanwhile was taking the base concepts of process improvement and applying them to a wider range of IT disciplines. The original CMM was termed SW-CMM, since its primary focus was on process improvement for the tasks of software engineering. The SEI then designed a similar model for the discipline of systems engineering, SE-CMM. Later it shaped a model for integrated product and process development, IPPD, and Supplier Sourcing.
Each model found its niche in IT departments around the world. But soon, users discovered they were employing several models within the same organization to meet different but similar needs. They expressed the desire for a single integrated model that could be followed for systems engineering, software engineering, or integrated product development. The SEI saw this as an opportunity not only to consolidate several models into one, but also to simplify and, to an extent, "genericize" the requirements of CMM, no matter what its flavor.
The resulting integrated model was released in 1999 as CMMI. Then in August of 2006, the SEI released updates to CMMI (with some streamlines and consolidations, and the introduction of "constellations" of models) known as version 1.2. From this came CMMI-Development for product and process development, and CMMI-ACQ for acqusitions. In this book we discuss the CMMI-Dev model. For the sake of convenience, we'll refer to it simply as CMMI.
CMMI, then, can be seen as a gift from America to America, as a toolkit to help make American IT enterprise remain innovative, competitive, and productive. But it has actually become more than that. Today, we can see it—as many people in other countries doubtlessly do—as a gift from America to the world. In the following section, I'll look at the question of ownership regarding CMMI.