Chapter 6: Understanding Maturity Level 3: Defined

Summary

Although at first glance it appears that Level 2 of the CMMI has not changed significantly from Level 2 of the CMM for Software, reality must set in. While the words in the CMMI and the layout of the Process Areas appear to be very similar, they are not. Remember: the CMMI includes Systems Engineering, Software Engineering, Supplier Sourcing, and Integrated Product and Process Teams. So when planning and implementing these Process Areas, all levels and departments that will be necessary to create the final product (and any interim products) must be included.

There is also redundancy across the model. Examples at Maturity Level 2 are that the Measurement and Analysis and Product and Process Quality Assurance Process Areas must be performed at all levels and within all process areas, not just at Level 2. Further redundancy is shown within the Generic Practices. For example, GP2.2: Plan the Process can be traced back to the Project Planning Process Area. GP2.5: Train People is related to Organizational Training at Level 3. GP2.8: Monitor and Control the process is a reflection of the Project Monitoring and Control Process Area. GP2.6: Manage Configurations reflects Configuration Management. GP2.9 Objectively evaluate adherence is directly related to Product and Process Quality Assurance. While the argument has been made that these redundancies are included to aid the reader in how to implement the Generic Practices, we feel the hints provided are simply confusing. For example, when assessed, if GP2.6 is not followed in the Project Planning Process Area, does that mean that the organization is faulted in both Project Planning and in Configuration Management? Is this double jeopardy? To what degree is the organization in violation? Are these "showstoppers"? These supposed "hints and how-tos" just do not seem very helpful. They are either too generic or too prescriptive, depending on where the reader is referred.