CMMI RoadmapsJan Jaap CannegieterAndré HeijstekBen LindersRini van SolingenNovember 2008TECHNICAL NOTECMU/SEI-2008-TN-010Software Engineering Process ManagementUnlimited distribution subject to the copyright.

This report was prepared for theSEI Administrative AgentESC/XPK5 Eglin StreetHanscom AFB, MA 01731-2100The ideas and findings in this report should not be construed as an official DoD position. It is published in theinterest of scientific and technical information exchange.This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federallyfunded research and development center sponsored by the U.S. Department of Defense.Copyright 2008 Carnegie Mellon University.NO WARRANTYTHIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL ISFURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OFANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITEDTO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTSOBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKEANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, ORCOPYRIGHT INFRINGEMENT.Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.Internal use. Permission to reproduce this document and to prepare derivative works from this document forinternal use is granted, provided the copyright and "No Warranty" statements are included with all reproductionsand derivative works.External use. Requests for permission to reproduce this document or prepare derivative works of this document forexternal and commercial use should be directed to [email protected] work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 withCarnegie Mellon University for the operation of the Software Engineering Institute, a federally funded researchand development center. The Government of the United States has a royalty-free government-purpose license touse, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so,for government purposes pursuant to the copyright license under the clause at 252.227-7013.For information about purchasing paper copies of SEI reports, please visit the publications section of our website(

Table of ContentsAbstractv1Introduction1.1 The Rationale for Roadmaps1.2 The History of Roadmaps1112Use of the Roadmaps2.1 Roadmaps in an Improvement Project2.2 Structure of a Roadmap3353Project Roadmap3.1 Purpose3.2 Potential Users3.3 Process Areas3.4 Rationale for Inclusion or Exclusion of Process Areas3.5 Possible Next Steps6666774Product Roadmap4.1 Purpose4.2 Potential Users4.3 Process Areas4.4 Rationale for Inclusion or Exclusion of Process Areas4.5 Possible Next Steps999910105Product Integration Roadmap5.1 Purpose5.2 Potential Users5.3 Process Areas5.4 Rationale for Inclusion or Exclusion of Process Areas5.5 Possible Next Steps1212121213146Process Roadmap6.1 Purpose6.2 Potential Users6.3 Process Areas6.4 Rationale for Inclusion or Exclusion of Process Areas6.5 Possible Next Steps1515151616167Measurement Roadmap7.1 Purpose7.2 Potential Users7.3 Process Areas7.4 Rationale for Inclusion or Exclusion of Process Areas7.5 Possible Next Steps181818181919Appendix AAttendees of the SPIder WorkshopReferencesi CMU/SEI-2008-TN-0102021

ii CMU/SEI-2008-TN-010

List of FiguresFigure 1:Using the Roadmapsiii CMU/SEI-2008-TN-0105

iv CMU/SEI-2008-TN-010

AbstractCMMI “roadmaps”—which are a goal-driven approach to selecting and deploying relevantprocess areas from the CMMI-DEV model—can provide guidance and focus for effective CMMIadoption. The Dutch Software Process Improvement (SPIder) network convened a workshop inNovember 2006 to develop several CMMI roadmaps for the continuous representation, each witha specific set of improvement goals. These roadmaps combine the strengths of both the staged andthe continuous representations.v CMU/SEI-2008-TN-010

vi CMU/SEI-2008-TN-010

1 Introduction1.1 The Rationale for RoadmapsCMMI uses two representations: staged and continuous. The staged representation is the mostused representation, although the continuous representation is commonly perceived to be a moreflexible option. Often, potential CMMI users do not select the continuous representation becausethey find it difficult to pick “the right set and order” of process areas for their situation. Potentialusers may then choose the staged representation because they don’t know where to start in thecontinuous representation.The staged representation could be considered a comprehensive roadmap for the continuous representation. This approach fits those organizations that want to systematically improve the capability of their development activities. The order of process areas (the selection of process areasthat belong to a certain maturity level) is mainly determined by historical analysis of processproblems in development organizations. Project management and commitment problems havetypically prevented an efficacious development from taking place—which explains why maturitylevel 2 focuses on project-management-related process areas. Once these problems were resolved,companies needed to achieve economies of scale and align their processes for all projects at maturity level 3.However, sometimes this approach is not the most beneficial. Organizations may have projectmanagement that functions reasonably well, but might still face many product defects. Other organizations may not develop software, hardware, or systems themselves, but integrate components from external suppliers instead. For these (and other) situations, the continuous representation offers the possibility of designing a customized roadmap as an alternative to the stagedrepresentation. To support companies in their selection of an appropriate sequence of processareas, we have developed several roadmaps for the continuous representation, each addressing aspecific set of improvement goals. These roadmaps combine the strengths of both the staged andthe continuous representations.1.2 The History of RoadmapsThe first idea—that there are different roadmaps within the continuous representation—arose during a management workshop at the start of a CMMI implementation activity. This particular management team had difficulties in deciding which process areas to implement first. The consultantwho facilitated this workshop asked, “What do you want to improve first: project quality, productquality, or process quality?” Everybody agreed on process quality.This approach was discussed with a fellow CMMI expert, and this discussion led to the publication of an article about the concept of roadmaps in a leading IT journal in the Netherlands [Cannegieter 2006a], as well as a keynote presentation at the PROFES International Conference onProduct Focused Process Improvement [Cannegieter 2006b]. Other CMMI consultants and experts had a positive reaction—many were interested and saw this concept as a contribution to theexisting CMMI Product Suite.1 CMU/SEI-2008-TN-010

To further elaborate on the roadmaps concept and to increase the support for roadmaps, the authors organized a workshop on 15 November 2006 in cooperation with the Dutch SPI network(SPIder). Thirty-five CMMI practitioners from The Netherlands and Belgium attended this workshop. In small groups, they developed the roadmaps described in this report. The attendees of thisworkshop are listed in the appendix.The outcomes of this workshop led to this technical note. It has been reviewed by the workshopattendees and the SEI, whose review led to further refinements. This technical note is a contribution of the Dutch SPI community to the international SPI community.2 CMU/SEI-2008-TN-010

2 Use of the Roadmaps2.1 Roadmaps in an Improvement ProjectThe roadmaps in this report are primarily intended for organizations that are starting a CMMI forDevelopment implementation, deciding to use the continuous representation, and needing help indeciding what process areas to implement first.An improvement project starts with the recognition by the management of an organization thatimprovements are needed. These reasons need to be clear, understood, and widely accepted withinthe organization. In the IDEAL model, this phase is described as the Initiate phase.To achieve a shared understanding of the current situation, an analysis can help. A CMMI appraisal is one way to analyze the current situation, but the use of an appraisal implies the selectionand use of a particular CMMI constellation, which may be premature for some organizations.Other ways to analyze the current situation include evaluations of projects or processes, customersatisfaction investigations, causal analysis of defects, benchmarks, or audits. In the IDEAL model,this phase is described as the Diagnose phase.After the analysis of the current situation, the goals of the improvement project and the problemsthat have to be solved must be clear, understood, and widely accepted. If the goals fall within thescope of a CMMI constellation, that constellation can be used as a reference model for the improvement project. At this point, the organization needs to select which representation to use—achoice that is determined by business, cultural, and legacy factors [SEI 2006].When an organization decides to use the continuous representation, it needs to determine whichprocess areas to implement first. To achieve this goal, one needs to understand the architecture ofCMMI, the content of the process areas, and the relationships among the process areas, which canbe difficult for organizations that have no experience with CMMI. In practice, this can lead tothree situations:1.An experienced consultant advises an organization about the implementation sequence. Onedrawback to this is a lack of ownership for this decision within the organization itself and adependency on the consultant.2.An improvement team from the organization studies the CMMI for Development model (orthe CMMI for Acquisition model or the CMMI for Services model) and its process areas indetail. One advantage is that the organization develops a better understanding of CMMI. Onedrawback, however, is that this process takes a lot of time, which could instead be spent onimproving processes. Another possible drawback is that the choices made may not fit thegoals and problems of the organization.3.The organization selects the Staged representation. One drawback of this approach is that theselected process areas may not represent the most direct approach to addressing the improvement goals.CMMI model roadmaps are tools to aid organizations that want to use the continuous representation. The roadmaps help those organizations select which process areas to implement first, based3 CMU/SEI-2008-TN-010

on the improvement goals and problems that the organization wants to solve. At the same time,organizations that choose to use roadmaps can be more confident that they have selected an appropriate set of process areas to address their initial needs.The focus of this report will also be on CMMI for Development, though analogous roadmapscould be developed for the other constellations.Five roadmaps are recognized at this point in time:Project RoadmapFor organizations with project management-related goals or business problemsProduct RoadmapFor organizations with product-related goals (e.g., for improvedproduct quality) or business problemsProduct IntegrationRoadmapFor organizations with product-assembling goals or businessproblems. Applicable when the primary challenge for projects iscorrectly integrating software components, hardware components,or both software and hardware componentsProcess RoadmapFor organizations with process management-related goals orbusiness problemsMeasurement RoadmapFor organizations with measurement-related goals or businessproblemsEach roadmap contains a limited set of four to eight process areas, which limits the scope and duration of the first improvement cycle(s) and helps organizations to focus their improvement activities on the critical few process areas that are most likely to provide direct benefit to their situation.Since each organization is unique, the improvement goals and problems to solve first are differentfor each organization.After finishing its implementation of a roadmap, the organization will generally have enough experience with process improvement in general and with CMMI in particular to define the nextsteps themselves. However, hints are given to suggest likely follow-on process areas.Figure 1 provides an overview of how the roadmaps can be used.4 CMU/SEI-2008-TN-010

Determine need for improvementAnalyze current situationSelect roadmap or define your own roadmapPossibly tailor roadmapImplement (tailored) roadmapFigure 1: Using the Roadmaps2.2 Structure of a RoadmapEvery roadmap has the same basic structure.The first element of a roadmap is its purpose. The purpose characterizes the typical improvementgoals addressed by this roadmap and the typical set of problems being solved.The second element of a roadmap is its potential users. Some roadmaps are specifically applicableto certain types of organizations, and if this is the case, the applicable types of organizations arestated.The third element of a roadmap presents the set of process areas that belong to that particularroadmap, as every roadmap contains a limited number of process areas. The rationale is that thefirst step in a process improvement project should never be too big. Process and Product QualityAssurance (PPQA) is almost always one of the included process areas, because without thisprocess area, an organization can never be certain that a process is actually in use by the organization. PPQA may also be useful in identifying shortcomings in a new (or refined) process’s definition, deployment, or implementation.The next element, rationale for inclusion or exclusion of process areas, describes the motivationfor selecting a particular set of process areas.The last element in the roadmap structure is possible next steps. The roadmaps contain certainprocess areas, and after the first improvement cycle, an organization can identify its next improvement path by selecting another roadmap or by identifying its own additional set of processareas. In this section, some possible next steps are suggested.5 CMU/SEI-2008-TN-010

3 Project Roadmap3.1 PurposeThe purpose of the Project roadmap is to establish control of projects. Organizations choosing theProject roadmap typically want tobe sure that each project meets its requirementsimprove the estimation of time and effort on projectsimprove the planning of projectsimprove the involvement of relevant stakeholdersimprove the monitoring and control of projectsThis roadmap is meant for organizations that are having problems such aspoor planning of projectsno clear scope and requirements for projectslimited involvement of relevant stakeholders in projectslimited insight into the progress of projectsprojects that suffer continuous scope creep, budget overruns, or delayed end-dates3.2 Potential UsersThis roadmap is used by organizations whose business is generally carried out within projects.The success of these organizations depends heavily on their ability to control projects. Examplesof such organizations area software house that carries out projects for customersa software department of an organization that consists of projects such as developing software for in-house systems3.3 Process AreasTo achieve the goals and resolve the problems described above, the following process areasshould be implemented.Project PlanningThis process area will help establish and maintain plans that define project activities.Project Monitoring & ControlThis process area will help provide an understanding of a project’s progress so that appropriatecorrective actions can be taken if the project’s performance deviates significantly from the plan.Requirements ManagementThis process area will help manage the requirements of a project’s products and product compo6 CMU/SEI-2008-TN-010

nents and identify inconsistencies between those requirements and the project’s plans and workproducts.Configuration ManagementThis process area will help establish and maintain the integrity of selected work products usingconfiguration identification, configuration control, configuration status accounting, and configuration audits.Process and Product Quality AssuranceThis process area will help provide staff and management with objective insight into the processesbeing defined and deployed and associated work products.3.4 Rationale for Inclusion or Exclusion of Process AreasThese five process areas provide for the basic control of projects. They help organizations planand monitor projects, as well as ensure that the project focuses on the established requirements.The addition of the Process and Product Quality Assurance process area ensures that improvedprocesses are used. This roadmap overlaps with a part of the process areas of 'staged' maturitylevel 2—addressing these project problems first has certainly been the main motivation of the authors of the Software CMM and of CMMI.The Integrated Project Management and Risk Management process areas are not included in theroadmap because they are only effective when the Project Planning and Project Monitoring andControl process areas are implemented.The Measurement and Analysis process area can be a good addition to this roadmap. It improvesthe measurement capability of the organization, which can help to improve project control. It isnot included in the roadmap because the first priority of the roadmap is to achieve basic projectcontrol (including taking corrective action) before the measurement capability is improved.If there are suppliers to a project, the Supplier Agreement Management process area can be agood addition to this roadmap.3.5 Possible Next StepsAfter finishing this roadmap, the organization may choose to implement one of the other roadmaps, depending on the problems and goals of the organization at that time. No other roadmap isinherently preferred to any other after the Project roadmap is implemented.Another possible next step is implementing the Measurement and Analysis and Supplier Agreement Management process areas. When implementing these process areas, the organization notonly improves its control over projects—it also reaches maturity level 2.It is also possible to bring project control to a higher level by implementing the Integrated ProjectManagement and Risk Management process areas. Rather than addressing these process areas in away that introduces completely new processes, implementing these process areas should insteadresult in refinements to the definitions of the processes already introduced as part of the Projectroadmap.7 CMU/SEI-2008-TN-010

After having completed the Project roadmap, organizations can improve their measurement capabilities and quantitatively control their projects further by first implementing the Measurementand Analysis process area and then by implementing, with care, selected practices from the Quantitative Project Management process area.Organizations can also define their own improvement path after finishing the Project roadmap bychoosing process areas that best meet their improvement goals at that time. Furthermore, it is agood option to further improve the organization’s implementation of the process areas in thisroadmap by bringing the selected process areas to higher capability levels.8 CMU/SEI-2008-TN-010

4 Product Roadmap4.1 PurposeThe purpose of the Product roadmap is to effectively develop products that meet the needs of customers and to improve pr