Chapter 2: Overview of the Project Management Maturity Model. The Software Engineering Institute Capability Maturity Model Beginning as early as 1986 the Software Engineering Institute (SEI), which is affiliated with Carnegie Mellon University, began developing a process maturity framework for software development [1]. With financial support from the Department of Defense this early effort resulted in the publication of the Capability Maturity Model® (CMM®) [2] in 1991. This is a lengthy foundation chapter in which the detailed description of the five-level maturity model is presented and applied to each of the 39 processes that define the project management body of knowledge. | 2 Overview of the Project Management Maturity Model The Software Engineering Institute Capability Maturity Model Beginning as early as 1986 the Software Engineering Institute SEI which is affiliated with Carnegie Mellon University began developing a process maturity framework for software development 1 . With financial support from the Department of Defense this early effort resulted in the publication of the Capability Maturity Model CMM 2 in 1991. This is a lengthy foundation chapter in which the detailed description of the five-level maturity model is presented and applied to each of the 39 processes that define the project management body of knowledge PMBOK . These descriptions provide the content for the survey that will be used to measure process and practice maturity. Maturity assessment will be the basis for a continuous improvement program for project management processes. Purpose The purpose of the CMM is to provide organizations with a guide for establishing process improvement programs for software development. The guide can be used both as a foundation for establishing tools and as input to creating a maturity questionnaire for process improvement. 19 20 Project Management Process Improvement Structure The CMM defines five levels of maturity initial repeatable defined managed and optimizing which are briefly described below. Initial The process is ad hoc. There may be a few defined processes. Some software engineers bring tools and templates they may have learned elsewhere but otherwise successful software development is largely dependent upon heroic efforts. Repeatable Processes are established and put in place for use across software development projects. Process use is recommended but not required. For some large or critical mission projects the use of these standard processes is often required. Defined Processes are standardized and documented. There is a standard software development process that all .
