TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
In the 1980s, Watts S. Humphrey, a researcher and manager who came to the SEI from IBM, took the ideas of the software lifecycle and combined them with the idea of quality maturity levels, which lead to CMM. That initial publication then became the focal point for the development of CMM, as we know it today [4].
In a Crosstalk article from 1998, Humphrey explained the basic motivation behind the development of CMM:
The US Air Force asked the Software Engineering Institute to devise an improved method to select software vendors.... A careful examination of failed projects shows that they often fail for nontechnical reasons. The most common problems concern poor scheduling and planning or uncontrolled requirements. Poorly run projects also often lose control of changes or fail to use even rudimentary quality processes [5].
It's pretty clear that if you think most projects fail because of poor project management or change control, then you are likely to come up with a method that, like CMM, focuses on installing improved project control. If, on the other hand, you think that the reason most projects fail is the result of poor user communication, poor development practices, and poor programming, you are likely to come up with a different approach.
Agile . since Jun 23 . Index . DOCs TOP TOC
It is easy to see how CMM has been associated closely over its history with the DOD and with military systems. This is not surprising, since the DOD is perhaps the largest long-term purchaser of software development services in the world and its influence has been immense, especially in the earliest days of computers. The defense folks have been developing large-scale systems longer than anyone and, some would say, more successfully than almost any other organization.
DOD has also been funding research in software development and software methods longer than any other organization, with the possible exception of the telecommunications industry.2 The reason for this interest in software development is that critical DOD systems tend to be immense and state-of-the-art, relying on huge amounts of custom hardware and software. Moreover, almost all DOD systems are developed using outside contractors. With so much money at stake, DOD has worked mightily to take as much risk out of their critical systems projects as possible.
For decades, DOD has been promoting rigorous systems methodologies. In the 1950s and 1960s, for example, DOD began to promote the first waterfall methodologies adapted from its work on hardware development.3 This approach emphasizes the idea of a serial, phased approach to development: planning, requirements, design, development/testing, and deployment. Each phase produces voluminous documentation used by the next phase.
The waterfall approach allows careful consideration of problems and ensures that major elements are not missed. This serial approach also makes it possible to break up the work so that one organization can do the planning and requirements, while another can do design, development/test, and deployment -- a standard procurement process with government projects.
Because DOD was such a big customer, many large military/aerospace firms adopted (or were forced to adopt) waterfall methods very similar to DOD's.4 As a result, those organizations with the most rigorous methods were often large, military software vendors. This pattern is being repeated today in the private sector. As more and more large organizations are buying huge chunks of their software development from outside vendors, they are looking for better ways to manage this important relationship. And since the DOD has had the most experience in controlling outsourced software projects, these organizations are taking a clue from DOD's efforts and are beginning to force the adoption of CMM practices among their vendors.
One particular segment that has picked up CMM is the outsourcing software vendors, especially those in India. For more than a decade, large Indian software companies have been among the most aggressive in the world in pursuing higher and higher levels of CMM certification.5 This certification was initially sought to allay fears that customers might have about having software work done by Indian firms, and then it was used to convince people that it was all right to move development to another continent. Cutter Business Technology Council Fellow Ed Yourdon, who sits on the board of directors of an Indian software company says that, by now, many of these companies have become experts at following CMM best practices and have even found ways of applying CMM management techniques to small projects.