columns
cmmi in focus
Appraisals Across the CMMI Constellations
As the door opens for appraisals using the CMMI for Acquisition methodology (CMMI-ACQ) in addition to CMMI for Development (CMMI-DEV), questions arise about multiple-constellation appraisals. This month’s column addresses our current thinking about these options.
First, the Need…
One of the strengths of the architecture associated with the collection of constellations that comprise CMMI is that there is a great deal of commonality among the models for CMMI-DEV and CMMI-ACQ today, and, in a few months, for CMMI for Services (CMMI-SVC). In virtually every presentation I’ve made since we created CMMI-ACQ, someone has asked about multiple-constellation appraisals. The CMMI Product Team has explored options with the CMMI Steering Group, and this column gives me an opportunity to share our approach toward multi-constellation appraisals with you.
Organizations that are committed to process improvement and have teams operating in more than one area of interest generally wish to avoid the need for multiple appraisals of their CMMI progress. A key driver for our constellation approach was to maximize the synergies among the CMMI models. Combined appraisals are one way to capitalize on that synergy.
There are actually several scenarios that deserve consideration:
- The organization may be primarily a development organization but with distinct acquisition projects that have not been previously covered by CMMI-DEV.
- On the other hand, the organization may be primarily an integrator of a large number of systems that provide a final product or service to the customer only once the systems are packaged together. (Examples of these organizations might be a sophisticated test environment or a school laboratory.) In these types of organizations, there may be development activities covered by CMMI-DEV, but the critical business activities are related to acquiring the products or services needed to provide the final product or service to the customer.
- Finally, the organization may contain a mixture of both types of projects, with no clearly dominant focus.
Recall that we have both continuous and staged representations available for appraisals. Continuous appraisals provide the flexibility we need as we examine the scenarios most easily and these have been approved by the Steering Group for initial use. The strategy for these appraisals is to determine the collection of process areas relevant to the organizational unit that desires the capability examination. CMMI-DEV process areas would be checked by teams qualified to appraise against CMMI-DEV V1.2. For the projects needing the appraisal based on CMMI-ACQ, the team members must have the additional training contained in the CMMI for Acquisition Supplement for Introduction to CMMI Version 1.2 course. The lead appraiser must be qualified in both constellations.
Worthy of note here are the choices needed for the process areas that are common to all CMMI models. (These are 16 of the 22 process areas—PP, PMC, CM, PPQA, MA, REQM, OPD, OPF, IPM, DAR, RSKM, OT, OPP, QPM, CAR, and OID.) Because of the additional material provided in CMMI-ACQ, it would be better to use the CMMI-ACQ model for all acquisition projects. Since support and organization-level process improvement will need to address both domains, the informative material in both models will likely be needed to recognize the distinctions between acquisition and development. The practical solution would be to compose an appraisal team of members who are familiar with both models.
What About Staged?
The benchmark aspects of staged appraisals or maturity level appraisals raise several rating challenges. Those of you who are familiar with these kinds of appraisals know that the appraisal team seeks a number of projects to confirm that the practices are institutionalized. Differences were designed into the two constellations that mark the distinctive activities of the two domains of interest. It is important to maintain the same confidence when two constellations are considered. Maintaining this confidence suggests that about twice the number of projects must be evaluated, with an equal distribution representing the two constellations. The evaluation would look like two appraisals being conducted together. In fact, the most reasonable approach would be to plan the event as two separate appraisals, with a team trained to examine CMMI-DEV performance and another to examine CMMI-ACQ performance. It’s possible that many of the interviews, particularly non-project interviews, would be shared between the two teams. While one lead appraiser might be able to handle two teams, we would strongly recommend two as we research this type of event.
As I mentioned earlier, the Steering Group has agreed with the Product Team’s recommendation that the continuous representation is more straightforward for combined appraisals. Because we all recognize the potential interest in combined maturity-level-yielding appraisals, we will work with organizations seeking to pilot such an approach. If your organization wishes to participate, please contact us at cmmi-comments@sei.cmu.edu.
Summary
We recognize that expanding coverage will lead to new challenges when multiple models are needed for appraisal purposes. As we work out the details of integrated maturity level appraisals, we can assure you that insight is gained by using continuous appraisals for organizations that must stretch beyond the current coverage approach. All of these answers must enable significant savings in effort over totally independent, separate appraisals.
About the Author
As the director of special projects at the Software Engineering Institute, Mike Phillips leads the Capability Maturity Model Integration (CMMI) project for the SEI. He was previously responsible for transition-enabling activities at the SEI. Prior to his retirement as a colonel from the Air Force, he managed the $36B development program for the B-2 in the B-2 SPO and commanded the 4950th Test Wing at Wright-Patterson AFB, Ohio. In addition to his bachelor’s degree in astronautical engineering from the U.S. Air Force Academy, Phillips has master’s degrees in nuclear engineering from Georgia Tech, in systems management from the University of Southern California, and in international affairs from Salve Regina College and the Naval War College.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.