• Save
CMMI for Development, 3rd Edition
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

CMMI for Development, 3rd Edition

on

  • 2,430 views

CMMI for Development describes best practices for the development and maintenance of products and services across their lifecycle. By integrating essential bodies of knowledge, CMMI-DEV provides a ...

CMMI for Development describes best practices for the development and maintenance of products and services across their lifecycle. By integrating essential bodies of knowledge, CMMI-DEV provides a single, comprehensive framework for organizations to assess their development and maintenance processes and improve performance. Already widely adopted throughout the world for disciplined, high-quality engineering, CMMI-DEV Version 1.3 now accommodates other modern approaches as well, including the use of Agile methods, Lean Six Sigma, and architecture-centric development.

Statistics

Views

Total Views
2,430
Views on SlideShare
2,430
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
1

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CMMI for Development, 3rd Edition Document Transcript

  • 1. Process Areas by CategoryProcess ManagementOPD Organizational Process DefinitionOPF Organizational Process FocusOPM Organizational Performance ManagementOPP Organizational Process PerformanceOT Organizational TrainingProject ManagementIPM Integrated Project ManagementPMC Project Monitoring and ControlPP Project PlanningQPM Quantitative Project ManagementREQM Requirements ManagementRSKM Risk ManagementSAM Supplier Agreement ManagementEngineeringPI Product IntegrationRD Requirements DevelopmentTS Technical SolutionVAL ValidationVER VerificationSupportCAR Causal Analysis and ResolutionCM Configuration ManagementDAR Decision Analysis and ResolutionMA Measurement and AnalysisPPQA Process and Product Quality Assurance
  • 2. Generic Goals and PracticesGG1 Achieve Specific GoalsGP 1.1 Perform Specific PracticesGG2 Institutionalize a Managed ProcessGP2.1 Establish an Organizational PolicyGP 2.2 Plan the ProcessGP 2.3 Provide ResourcesGP 2.4 Assign ResponsibilityGP 2.5 Train PeopleGP 2.6 Control Work ProductsGP 2.7 Identify and Involve Relevant StakeholdersGP 2.8 Monitor and Control the ProcessGP 2.9 Objectively Evaluate AdherenceGP 2.10 Review Status with Higher Level ManagementGG3 Institutionalize a Defined ProcessGP 3.1 Establish a Defined ProcessGP 3.2 Collect Process Related Experiences
  • 3. CMMI® for DevelopmentThird EditionWow! eBook <WoweBook.Com>
  • 4. The SEI Series in Software Engineering represents is a collaborativeundertaking of the Carnegie Mellon Software Engineering Institute (SEI) andAddison-Wesley to develop and publish books on software engineering andrelated topics. The common goal of the SEI and Addison-Wesley is to providethe most current information on these topics in a form that is easily usable bypractitioners and students.Books in the series describe frameworks, tools, methods, and technologiesdesigned to help organizations, teams, and individuals improve their technicalor management capabilities. Some books describe processes and practices fordeveloping higher-quality software, acquiring programs for complex systems, ordelivering services more effectively. Other books focus on software and systemarchitecture and product-line development. Still others, from the SEI’s CERTProgram, describe technologies and practices needed to manage softwareand network security risk. These and all books in the series address criticalproblems in software engineering for which practical solutions are available.Visit informit.com/sei for a complete list of available products.The SEI Series inSoftware EngineeringWow! eBook <WoweBook.Com>
  • 5. CMMI® for DevelopmentGuidelines for Process Integration andProduct ImprovementThird EditionMary Beth ChrissisMike KonradSandy ShrumUpper Saddle River, NJ • Boston• Indianapolis • San FranciscoNew York • Toronto • Montreal • London • Munich • Paris • MadridCapetown • Sydney • Tokyo • Singapore • Mexico CityWow! eBook <WoweBook.Com>
  • 6. The SEI Series in Software EngineeringMany of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where thosedesignations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with ini-tial capital letters or in all capitals.CMM, CMMI, Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CERT, and CERT Coordination Centerare registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.ATAM; Architecture Tradeoff Analysis Method; CMM Integration; COTS Usage-Risk Evaluation; CURE; EPIC; EvolutionaryProcess for Integrating COTS Based Systems; Framework for Software Product Line Practice; IDEAL; Interim Profile; OAR;OCTAVE; Operationally Critical Threat, Asset, and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Soft-ware Process; PLTP; Product Line Technical Probe; PSP; SCAMPI; SCAMPI Lead Appraiser; SCAMPI Lead Assessor; SCE; SEI;SEPG; Team Software Process; and TSP are service marks of Carnegie Mellon University.Special permission to reproduce portions of CMMI for Development (CMU/SEI-2010-TR-035), © 2010 by Carnegie MellonUniversity, has been granted by the Software Engineering Institute.The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of anykind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages inconnection with or arising out of the use of the information or programs contained herein.The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which mayinclude electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, andbranding interests. For more information, please contact:U.S. Corporate and Government Sales(800) 382-3419corpsales@pearsontechgroup.comFor sales outside the United States, please contact:International Salesinternational@pearsoned.comVisit us on the Web: informit.com/awLibrary of Congress Cataloging-in-Publication DataChrissis, Mary Beth.CMMI for development : guidelines for process integration and productimprovement / Mary Beth Chrissis, Mike Konrad, Sandy Shrum.—3rd ed.p. cm.Includes bibliographical references and index.ISBN 978-0-321-71150-2 (hardcover : alk. paper)1. Capability maturity model (Computer software) 2. Softwareengineering. 3. Production engineering. 4. Manufacturing processes.I. Konrad, Mike. II. Shrum, Sandy. III. Title.QA76.758.C518 2011005.1—dc222010049515Copyright © 2011 Pearson Education, Inc.All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must beobtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or byany means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:Pearson Education, Inc.Rights and Contracts Department501 Boylston Street, Suite 900Boston, MA 02116Fax: (617) 671-3447ISBN-13: 978-0-321-71150-2ISBN-10: 0-321-71150-5Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.First printing, March 2011Wow! eBook <WoweBook.Com>
  • 7. This book is dedicated to Watts Humphrey, in appreciation for allhe accomplished as a leader, visionary, and teacher. You onlyneeded to be in a room with Watts Humphrey a short time to real-ize what a special person he was. Watts’ leadership, vision, andinsights helped many over his lifetime. He was a student of learn-ing and he shared that quest for learning with everyone with whomhe came into contact. He had a vision that he shared with theworld and the world became a better place. CMMI would not havebeen possible without Watts Humphrey. May he continue to inspireus for years to come.Wow! eBook <WoweBook.Com>
  • 8. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 9. CONTENTSLIST OF PERSPECTIVES xiiiPREFACE xvBOOK ACKNOWLEDGMENTS xxiPART ONE—ABOUT CMMI FOR DEVELOPMENT 11 INTRODUCTION 3About Process Improvement 4About Capability Maturity Models 9Evolution of CMMI 10CMMI Framework 14CMMI for Development 182 PROCESS AREA COMPONENTS 19Core Process Areas and CMMI Models 19Required, Expected, and Informative Components 19Required Components 19Expected Components 20Informative Components 20viiWow! eBook <WoweBook.Com>
  • 10. Components Associated with Part Two 20Process Areas 20Purpose Statements 22Introductory Notes 22Related Process Areas 22Specific Goals 22Generic Goals 23Specific Goal and Practice Summaries 23Specific Practices 23Example Work Products 24Subpractices 24Generic Practices 24Generic Practice Elaborations 25Additions 25Supporting Informative Components 25Notes 25Examples 25References 26Numbering Scheme 26Typographical Conventions 273 TYING IT ALL TOGETHER 31Understanding Levels 31Structures of the Continuous and Staged Representations 32Understanding Capability Levels 34Capability Level 0: Incomplete 35Capability Level 1: Performed 35Capability Level 2: Managed 35Capability Level 3: Defined 35Advancing Through Capability Levels 36Understanding Maturity Levels 41Maturity Level 1: Initial 42Maturity Level 2: Managed 42Maturity Level 3: Defined 43Maturity Level 4: Quantitatively Managed 43Maturity Level 5: Optimizing 44Advancing Through Maturity Levels 45viii ContentsWow! eBook <WoweBook.Com>
  • 11. Process Areas 46Equivalent Staging 49Achieving High Maturity 524 RELATIONSHIPS AMONG PROCESS AREAS 59Process Management 60Basic Process Management Process Areas 60Advanced Process Management Process Areas 62Project Management 64Basic Project Management Process Areas 64Advanced Project Management Process Areas 66Engineering 68Recursion and Iteration of Engineering Processes 74Support 77Basic Support Process Areas 78Advanced Support Process Areas 795 USING CMMI MODELS 85Adopting CMMI 90Your Process Improvement Program 94Selections that Influence Your Program 98CMMI Models 99Interpreting CMMI When Using Agile Approaches 100Using CMMI Appraisals 104Appraisal Requirements for CMMI 105SCAMPI Appraisal Methods 105Appraisal Considerations 106CMMI Related Training 1076 ESSAYS AND CASE STUDIES 113Case Studies 113Essays 137Contents ixWow! eBook <WoweBook.Com>
  • 12. PART TWO—GENERIC GOALS AND GENERIC PRACTICES,AND THE PROCESS AREAS 163GENERIC GOALS AND GENERIC PRACTICES 165CAUSAL ANALYSIS AND RESOLUTION 233CONFIGURATION MANAGEMENT 243DECISION ANALYSIS AND RESOLUTION 257INTEGRATED PROJECT MANAGEMENT 267MEASUREMENT AND ANALYSIS 287ORGANIZATIONAL PROCESS DEFINITION 303ORGANIZATIONAL PROCESS FOCUS 317ORGANIZATIONAL PERFORMANCE MANAGEMENT 331ORGANIZATIONAL PROCESS PERFORMANCE 351ORGANIZATIONAL TRAINING 365PRODUCT INTEGRATION 377PROJECT MONITORING AND CONTROL 393PROJECT PLANNING 403PROCESS AND PRODUCT QUALITY ASSURANCE 425QUANTITATIVE PROJECT MANAGEMENT 433REQUIREMENTS DEVELOPMENT 455REQUIREMENTS MANAGEMENT 473RISK MANAGEMENT 481SUPPLIER AGREEMENT MANAGEMENT 497TECHNICAL SOLUTION 509VALIDATION 531VERIFICATION 541PART THREE—THE APPENDICES 553A REFERENCES 555B ACRONYMS 561C CMMI VERSION 1.3 PROJECT PARTICIPANTS 565D GLOSSARY 573x ContentsWow! eBook <WoweBook.Com>
  • 13. BOOK CONTRIBUTORS 605INDEX 623Contents xiWow! eBook <WoweBook.Com>
  • 14. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 15. PERSPECTIVESLOOKING AHEADWattsHumphrey 5CMMI: INTEGRATION AND IMPROVEMENT CONTINUESBob Rassa 12THE ARCHITECTURE OF THE CMMI FRAMEWORKRoger Bate with a postscript byMike Konrad 14APPLYING PRINCIPLES OF EMPIRICISMVictor R. Basili, Kathleen C. Dangle, and Michele A. Shaw 37USING PROCESS PERFORMANCE BASELINES AND PROCESSPERFORMANCE MODELS TO ENABLE SUCCESSMichael Campo, Neal Mackertich, and Peter Kraus 53EXPANDING CAPABILITIES ACROSS THE “CONSTELLATIONS”Mike Phillips 72MEASUREMENT MAKES IMPROVEMENT MEANINGFULDavid N. Card 75PEOPLE, PROCESS, TECHNOLOGY, AND CMMIGargi Keeni 80THE ROLE OF PROCESS STANDARDS IN PROCESS DEFINITIONJamesW. Moore 85EXECUTIVE RESPONSIBILITIES IN PROCESS IMPROVEMENTBill Curtis 91xiiiWow! eBook <WoweBook.Com>
  • 16. IMPLEMENTING ENGINEERING CULTURE FOR SUCCESSFULPROCESS IMPROVEMENTTomoo Matsubara 95PROCESS IMPROVEMENT IN A SMALL COMPANYKhaled El Emam 101IMPROVING INDUSTRIAL PRACTICEHans-Jürgen Kugler 107SWITCHING TRACKS: FINDING THE RIGHT WAY TO GETTO MATURITY LEVEL 2Heather Oppenheimer and Steve Baldassano 113USING CMMI AS A BASIS FOR COMPETITIVE ADVANTAGE AT ABBAldo Dagnino 123LEVERAGING CMMI AND LSS TO ACCELERATE THE PROCESSIMPROVEMENT JOURNEYKileen Harrison and Anne Prem 130GETTING STARTED IN PROCESS IMPROVEMENT: TIPSAND PITFALLSJudah Mogilensky 137AVOIDING TYPICAL PROCESS IMPROVEMENT PITFALLSPat O’Toole 141TEN MISSING LINKS TO CMMI SUCCESSHillel Glazer 146ADOPTING CMMI: HIRING A CMMI CONSULTANT ORLEAD APPRAISERRawdon Young, Will Hayes, Kevin Schaaff, and Alexander Stall 152FROM DOUBTER TO BELIEVER: MY JOURNEY TO CMMIJoseph Morin 157xiv PerspectivesWow! eBook <WoweBook.Com>
  • 17. PREFACECMMI (Capability Maturity Model Integration) models are collec-tions of best practices that help organizations to improve theirprocesses. These models are developed by product teams with mem-bers from industry, government, and the Software Engineering Insti-tute (SEI).This model, called CMMI for Development (CMMI-DEV), pro-vides a comprehensive integrated set of guidelines for developingproducts and services.PurposeThe CMMI-DEV model provides guidance for applying CMMI bestpractices in a development organization. Best practices in the modelfocus on activities for developing quality products and services tomeet the needs of customers and end users.The CMMI-DEV V1.3 model is a collection of development bestpractices from government and industry that is generated from theCMMI V1.3 Architecture and Framework.1 CMMI-DEV is based on theCMMI Model Foundation or CMF (i.e., model components commonxv1. The CMMI Framework is the basic structure that organizes CMMI components and com-bines them into CMMI constellations and models.Wow! eBook <WoweBook.Com>
  • 18. to all CMMI models and constellations2) and incorporates work bydevelopment organizations to adapt CMMI for use in the develop-ment of products and services.Model AcknowledgmentsMany talented people were involved in the development of the V1.3CMMI Product Suite. Three primary groups were the CMMI SteeringGroup, Product Team, and Configuration Control Board (CCB).The Steering Group guided and approved the plans of the ProductTeam, provided consultation on significant CMMI project issues, andensured involvement from a variety of interested communities.The Steering Group oversaw the development of the Develop-ment constellation, recognizing the importance of providing bestpractices to development organizations.The Product Team wrote, reviewed, revised, discussed, and agreedon the structure and technical content of the CMMI Product Suite,including the framework, models, training, and appraisal materials.Development activities were based on multiple inputs. These inputsincluded an A-Specification and guidance specific to each releaseprovided by the Steering Group, source models, change requestsreceived from the user community, and input received from pilotsand other stakeholders.The CCB is the official mechanism for controlling changes toCMMI models, appraisal related documents, and Introduction toCMMI training. As such, this group ensures integrity over the life ofthe product suite by reviewing all proposed changes to the baselineand approving only those changes that satisfy identified issues andmeet criteria for the upcoming release.Members of the groups involved in developing CMMI-DEV V1.3are listed in Appendix C.AudienceThe audience for CMMI-DEV includes anyone interested in processimprovement in a development environment. Whether you are famil-iar with the concept of Capability Maturity Models or are seeking infor-mation to begin improving your development processes, CMMI-DEVxvi Preface2. A constellation is a collection of CMMI components that are used to construct models,training materials, and appraisal related documents for an area of interest (e.g., development,acquisition, services).Wow! eBook <WoweBook.Com>
  • 19. will be useful to you. This model is also intended for organizationsthat want to use a reference model for an appraisal of their develop-ment related processes.3Organization of this DocumentThis document is organized into three main parts:• Part One: About CMMI for Development• Part Two: Generic Goals and Generic Practices, and the Process Areas• Part Three: The Appendices and GlossaryPart One: About CMMI for Development, consists of five chapters:• Chapter 1, Introduction, offers a broad view of CMMI and the CMMIfor Development constellation, concepts of process improvement,and the history of models used for process improvement and differentprocess improvement approaches.• Chapter 2, Process Area Components, describes all of the compo-nents of the CMMI for Development process areas.4• Chapter 3, Tying It All Together, assembles the model componentsand explains the concepts of maturity levels and capability levels.• Chapter 4, Relationships Among Process Areas, provides insight intothe meaning and interactions among the CMMI-DEV process areas.• Chapter 5, Using CMMI Models, describes paths to adoption and theuse of CMMI for process improvement and benchmarking of prac-tices in a development organization.• Chapter 6, Essays and Case Studies, contains essays and case studiescontributed by invited authors from a variety of backgrounds andorganizations.Part Two: Generic Goals and Generic Practices, and the ProcessAreas, contains all of this CMMI model’s required and expected com-ponents. It also contains related informative components, includingsubpractices, notes, examples, and example work products.Preface xvii3. An appraisal is an examination of one or more processes by a trained team of professionalsusing a reference model (e.g., CMMI-DEV) as the basis for determining strengths andweaknesses.4. A process area is a cluster of related practices in an area that, when implemented collec-tively, satisfies a set of goals considered important for making improvement in that area. Thisconcept is covered in detail in Chapter 2.Wow! eBook <WoweBook.Com>
  • 20. Part Two contains 23 sections. The first section contains thegeneric goals and practices. The remaining 22 sections each repre-sent one of the CMMI-DEV process areas.To make these process areas easy to find, they are organizedalphabetically by process area acronym. Each section containsdescriptions of goals, best practices, and examples.Part Three: The Appendices and Glossary, consists of foursections:• Appendix A: References, contains references you can use to locatedocumented sources of information such as reports, process improve-ment models, industry standards, and books that are related toCMMI-DEV.• Appendix B: Acronyms, defines the acronyms used in the model.• Appendix C: CMMI Version 1.3 Project Participants contains lists ofteam members who participated in the development of CMMI-DEVV1.3.• Appendix D: Glossary, defines many of the terms used in CMMI-DEV.How to Use this DocumentWhether you are new to process improvement, new to CMMI, oralready familiar with CMMI, Part One can help you understand whyCMMI-DEV is the model to use for improving your developmentprocesses.Readers New to Process ImprovementIf you are new to process improvement or new to the CapabilityMaturity Model (CMM) concept, we suggest that you read Chapter 1first. Chapter 1 contains an overview of process improvement thatexplains what CMMI is all about.Next, skim Part Two, including generic goals and practices andspecific goals and practices, to get a feel for the scope of the bestpractices contained in the model. Pay close attention to the purposeand introductory notes at the beginning of each process area.In Part Three, look through the references in Appendix A andselect additional sources you think would be beneficial to read beforemoving forward with using CMMI-DEV. Read through the acronymsand glossary to become familiar with the language of CMMI. Then,go back and read the details of Part Two.xviii PrefaceWow! eBook <WoweBook.Com>
  • 21. Readers Experienced with Process ImprovementIf you are new to CMMI but have experience with other processimprovement models, such as the Software CMM or the SystemsEngineering Capability Model (i.e., EIA 731), you will immediatelyrecognize many similarities in their structure and content [EIA2002a].We recommend that you read Part One to understand how CMMIis different from other process improvement models. If you haveexperience with other models, you may want to select which sectionsto read first. Read Part Two with an eye for best practices you recog-nize from the models that you have already used. By identifyingfamiliar material, you will gain an understanding of what is new,what has been carried over, and what is familiar from the models youalready know.Next, review the glossary to understand how some terminologycan differ from that used in the process improvement models youknow. Many concepts are repeated, but they may be called somethingdifferent.Readers Familiar with CMMIIf you have reviewed or used a CMMI model before, you will quicklyrecognize the CMMI concepts discussed and the best practices pre-sented. As always, the improvements that the CMMI Product Teammade to CMMI for the V1.3 release were driven by user input.Change requests were carefully considered, analyzed, and imple-mented.Some significant improvements you can expect in CMMI-DEVV1.3 include the following:• High maturity process areas are significantly improved to reflectindustry best practices, including a new specific goal and severalnew specific practices in the process area that was renamed fromOrganizational Innovation and Deployment (OID) to OrganizationalPerformance Management (OPM).• Improvements were made to the model architecture that simplify theuse of multiple models.• Informative material was improved, including revising the engineer-ing practices to reflect industry best practice and adding guidance fororganizations that use Agile methods.• Glossary definitions and model terminology were improved toenhance the clarity, accuracy, and usability of the model.Preface xixWow! eBook <WoweBook.Com>
  • 22. • Level 4 and 5 generic goals and practices were eliminated as well ascapability levels 4 and 5 to appropriately focus high maturity on theachievement of business objectives, which is accomplished by apply-ing capability level 1-3 to the high maturity process areas (CausalAnalysis and Resolution, Quantitative Project Management, Organi-zational Performance Management, and Organizational ProcessPerformance).For a more complete and detailed list of improvements, seehttp://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/.Additional Information and Reader FeedbackMany sources of information about CMMI are listed in Appendix Aand are also published on the CMMI website—http://www.sei.cmu.edu/cmmi/.Your suggestions for improving CMMI are welcome. For informa-tion on how to provide feedback, see the CMMI website athttp://www.sei.cmu.edu/cmmi/tools/cr/. If you have questions aboutCMMI, send email to cmmi-comments@sei.cmu.edu.xx PrefaceWow! eBook <WoweBook.Com>
  • 23. BOOK ACKNOWLEDGMENTSThis book wouldn’t be possible without the support of the CMMIuser community and the work of a multitude of dedicated peopleworking together on CMMI-based process improvement. Ultimately,without the work of those involved in the CMMI project since itbegan in 1998, this book would not exist. We would like to speciallythank our many CMMI partners who help organizations applyCMMI practices.The complete CMMI-DEV model is contained in the book, whichwas created based on more than one thousand change requests sub-mitted by CMMI users. The CMMI Product Team, which includedmembers from different organizations and backgrounds, used thesechange requests to improve the model to what it is today.We would also like to acknowledge those who directly con-tributed to this book. All of these authors were willing to share theirinsights and experiences and met aggressive deadlines to do so: SteveBaldassano, Victor Basili, Michael Campo, David Card, Bill Curtis,Aldo Dagnino, Kathleen Dangle, Khaled El Emam, Hillel Glazer,Kileen Harrison, Will Hayes, Watts Humphrey, Gargi Keeni, PeterKraus, Hans Juergen Kugler, Neal Mackertish, Tomoo Matsubara,Judah Mogilensky, James Moore, Joseph Morin, Heather Oppen-heimer, Mike Philips, Pat O’Toole, Anne Prem, Robert Rassa, KevinSchaaff, Michele Shaw, Alex Stall, and Rusty Young. We are delightedthat they agreed to contribute their experiences to our book and wexxiWow! eBook <WoweBook.Com>
  • 24. hope that you find their insights valuable and applicable to yourprocess improvement activities.Special thanks go to Addison-Wesley Publishing Partner, PeterGordon, for his assistance, experience, and advice. We’d also like tothank Kim Boedigheimer, Curt Johnson, Stephane Nakib, and JulieNahil for their help with the book’s publication and promotion.From Mary Beth ChrissisI am so very blessed and humbled to be fortunate enough to be partof the third edition of this book. Working on CMMI has allowed methe opportunity to interact with many people. From the SEI Partnerswho work with the community daily, to the many individuals I’vehad the privilege to teach, to the people in organizations that believeCMMI will help them improve their business, I’ve learned so muchfrom you. I’d like you all to know that I realize although my nameappears on this book, I’m really just representing all of you. I don’tknow why I have been given this opportunity, but please know I amgreatly appreciative.I have a very special thank you for my colleagues at the SEI andespecially those in the SEPM Program. You’ve encouraged and sup-ported me. Thanks to Anita Carleton, Mike Phillips, Barbara Tyson,Bob McFeeley, Stacey Cope, Mary Lou Russo, and Barbara Baldwinfor all of your day-to-day assistance. I can’t forget Bill Peterson whohas supported CMMI and the work on this book since its inception.Version 1.3 wouldn’t have been accomplished without the manyvolunteers who worked on it. I’d like to recognize the training team,particularly Mike Campo and Katie Smith, for spending many hourswriting and reviewing the model and training materials. Thanks toDiane Mizukami Williams who had the vision and expertise toimprove the CMMI-DEV Intro course. I’d also like to thank BonnieBollinger for her sage wisdom and comments. Lastly, thanks to EricDorsett, Steve Masters, and Dan Foster for their help with the train-ing materials.To my coauthors Sandy and Mike, you’re the best. Each time wewrite a book, it is a different experience and I wouldn’t want to workwith anyone else. Thanks for your patience and understanding dur-ing this busy time.If you know me, you know my family is the center of my life. Tomy husband, Chuck, and my children, Adam, Pamela, and Kevin,thank you again for supporting me with this book. I love you and Iam grateful to have you in my life.xxii Book AcknowledgmentsWow! eBook <WoweBook.Com>
  • 25. From Mike KonradI came to the SEI 23 years ago hoping to contribute to an interna-tional initiative that would fundamentally improve the way systemsand software are built. CMMI has become that initiative. For this, Ithank my many colleagues at the SEI and Industry, past and present.Over the years I’ve been honored to work with some of the mosttalented individuals in systems and software engineering. My favoriteteachers have been Roger Bate, Jack Ferguson, Watts Humphrey, andBill Peterson.For Version 1.3, I’ve been particularly honored to work with JimArmstrong, Richard Basque, Rhonda Brown, Brandon Buteau, MikeCampo, Sandra Cepeda, Mary Beth Chrissis, Mike D’Ambrosa, EileenForrester, Brian Gallagher, Will Hayes, Larry Jones, So Norimatsu,Alice Parry, Lynn Penn, Mike Phillips, Karen Richter, Mary LouRusso, Mary Lynn Russo, Winfried Russwurm, John Scibilia, SandyShrum, Kathy Smith, Katie Smith-McGarty, Barbara Tyson, and RustyYoung.I also continue to learn from my two coauthors, Mary Beth andSandy; one could not hope for better or more talented coauthors.With respect to my family, words cannot express my heartfeltthanks to my wife, Patti, and our family, Paul, Jill, Christian, Katie,Alison, Tim, David, and Walter, for their patience while I was work-ing on the book and for sharing their time and insights of the worldwe all share; to my father, Walter, and my late mother, Renée, fortheir years of nurturing and sacrifice; and to my sister, Corinne, forher encouragement over the years.From Sandy ShrumWorking simultaneously on three CMMI books has tested my limitsin many ways. Those that have helped me along the journey pro-vided both professional and personal support.Many thanks to Rhonda Brown and Mike Konrad for their part-nership during CMMI model development. They are peerless as teammembers and friends. Our joint management of the CMMI CoreModel Team was not only effective, but enjoyable.Affectionate thanks to my boyfriend, Jimmy Orsag, for his lovingsupport and for helping me keep my focus and sense of humorthrough all the hours of work preparing three manuscripts. Heartfeltthanks to my parents, John and Eileen Maruca, for always beingthere for me no matter what and instilling my strong work ethic.Book Acknowledgments xxiiiWow! eBook <WoweBook.Com>
  • 26. Finally, thanks to the coauthors of all three CMMI books: Bran-don Buteau, Mary Beth Chrissis, Eileen Forrester, Brian Gallagher,Mike Konrad, Mike Phillips, and Karen Richter. They are all terrificto work with. Without their understanding, excellent coordination,and hard work, I would never have been able to participate.xxiv Book AcknowledgmentsWow! eBook <WoweBook.Com>
  • 27. PART ONEAboutCMMIforDevelopmentWow! eBook <WoweBook.Com>
  • 28. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 29. CHAPTER 1INTRODUCTIONNow more than ever, companies want to deliver products and servicesbetter, faster, and cheaper. At the same time, in the high-technologyenvironment of the twenty-first century, nearly all organizations havefound themselves building increasingly complex products and serv-ices. It is unusual today for a single organization to develop all thecomponents that compose a complex product or service. More com-monly, some components are built in-house and some are acquired;then all the components are integrated into the final product or serv-ice. Organizations must be able to manage and control this complexdevelopment and maintenance process.The problems these organizations address today involve enter-prise-wide solutions that require an integrated approach. Effectivemanagement of organizational assets is critical to business success.In essence, these organizations are product and service developersthat need a way to manage their development activities as part ofachieving their business objectives.In the current marketplace, maturity models, standards, method-ologies, and guidelines exist that can help an organization improvethe way it does business. However, most available improvementapproaches focus on a specific part of the business and do not take asystemic approach to the problems that most organizations are fac-ing. By focusing on improving one area of a business, these modelshave unfortunately perpetuated the stovepipes and barriers that existin organizations.CMMI for Development (CMMI-DEV) provides an opportunityto avoid or eliminate these stovepipes and barriers. CMMI for Devel-opment consists of best practices that address development activitiesapplied to products and services. It addresses practices that cover theproduct’s lifecycle from conception through delivery and maintenance.3Wow! eBook <WoweBook.Com>
  • 30. The emphasis is on the work necessary to build and maintain thetotal product.CMMI-DEV contains 22 process areas. Of those process areas, 16are core process areas, 1 is a shared process area, and 5 are develop-ment specific process areas.1All CMMI-DEV model practices focus on the activities of thedeveloper organization. Five process areas focus on practices specificto development: addressing requirements development, technicalsolution, product integration, verification, and validation.About Process ImprovementIn its research to help organizations to develop and maintain qualityproducts and services, the Software Engineering Institute (SEI) hasfound several dimensions that an organization can focus on toimprove its business. Figure 1.1 illustrates the three critical dimen-sions that organizations typically focus on: people, procedures andmethods, and tools and equipment.What holds everything together? It is the processes used in yourorganization. Processes allow you to align the way you do business.4 PART ONE ABOUT CMMI FOR DEVELOPMENT1. A core process area is a process area that is common to all CMMI models. A shared processarea is shared by at least two CMMI models, but not all of them.Tools andequipmentPeoplewith skills,training, andmotivationProcessAProcedures and methodsdefining the relationshipof tasksBCDFIGURE 1.1The Three Critical DimensionsWow! eBook <WoweBook.Com>
  • 31. 2. Leo Tolstoy, Anna Karenina, Modern Library, New York.They allow you to address scalability and provide a way to incorpo-rate knowledge of how to do things better. Processes allow you toleverage your resources and to examine business trends.This is not to say that people and technology are not important.We are living in a world where technology is changing at an incredi-ble speed. Similarly, people typically work for many companiesthroughout their careers. We live in a dynamic world. A focus onprocess provides the infrastructure and stability necessary to dealwith an ever-changing world and to maximize the productivity ofpeople and the use of technology to be competitive.Manufacturing has long recognized the importance of processeffectiveness and efficiency. Today, many organizations in manufac-turing and service industries recognize the importance of qualityprocesses. Process helps an organization’s workforce to meet businessobjectives by helping them to work smarter, not harder, and withimproved consistency. Effective processes also provide a vehicle forintroducing and using new technology in a way that best meets thebusiness objectives of the organization.Looking Aheadby Watts HumphreyNearly 25 years ago when we first started the maturity model workthat led to the CMM and CMMI, we took a diagnostic approach.What are the characteristics of organizations that performed goodsoftware work? We were following the principle that Tolstoy statedin Anna Karenina.2“Happy families are all alike; every unhappy family is unhappy inits own way.”In applying the Tolstoy principle to software organizations, welooked for those markers that characterized effective software oper-ations and then formed these characteristics into a maturity model.The logic for the maturity model was that, to do good work, organi-zations must do everything right. However, since no one could pos-sibly fix all of their problems at once, our strategy was to determinewhat organizations were doing and compare that to what theyChapter 1 Introduction 5Wow! eBook <WoweBook.Com>
  • 32. 6 PART ONE ABOUT CMMI FOR DEVELOPMENTshould be doing to be a “happy family.” Then, using the model as aguide, they should start fixing the omissions and mistakes in theorder defined by the model.Keep Doing the Good ThingsUnfortunately, we were not sufficiently clear with our initial guid-ance, and some people felt that, if they were only trying to get tomaturity level 2, they should not do things that were at levels 3, 4,and 5. That is not what we meant. Organizations should continuedoing all of the “good” things they now are doing and only focus onthe problem areas. The objective at level 2 is to address those level 2things that are missing or inadequate, and fix them first. Then theorganization should consider addressing the level 3, 4, and 5 gaps.Again, they should not stop doing any things that work.The Logic for the Maturity Level 2The logic that we followed in establishing the maturity levels was asfollows. First, organizations cannot do good work, and they cer-tainly cannot improve, if they are in a perpetual state of crisis.Therefore, the first improvement efforts should focus on those thingsthat, if done poorly or not at all, will result in crises. These are plan-ning, configuration management, requirements management, sub-contract management, quality assurance, and the like.The Logic for Maturity Level 3Second, after the crises are largely controlled and the organization isplan-driven rather than crisis-driven, the next step is learning. Howcan people learn from each other rather than having to learn fromtheir own mistakes? Again, from Tolstoy’s principle, there is an infi-nite number of ways to fail, so improving by reacting to failures is anever-ending and fruitless struggle. The key is to find out what worksbest in the organization and to spread that across all groups. There-fore, maturity level 3 focuses on learning-oriented things like processdefinition, training, and defined ways to make decisions and evalu-ate alternatives.The Logic for Maturity Levels 4 and 5At level 4, the focus turns to quantitative management and qualitycontrol, and at level 5, the efforts include continuous improvement,technological innovations, and defect prevention. Unfortunately, wenever included an explicit requirement in CMM or CMMI that high-maturity organizations must look outside of their own laboratoriesWow! eBook <WoweBook.Com>
  • 33. Chapter 1 Introduction 7to identify best industry practices. Then, after they find these prac-tices, they should measure, evaluate, and prototype them to see ifthese practices would help improve their operations. This seemedlike such an obvious step that we never explicitly required it. How-ever, judging from the slow rate of adoption of new and well-provensoftware and systems development innovations, such a requirementshould have been included in the model.Continuous ImprovementAt this point, of the many organizations that have been evaluated atCMMI level 5, too many have essentially stopped working onimprovement. Their objective was to get to level 5 and they arethere, so why should they keep improving? This is both an unfortu-nate and an unacceptable attitude. It is unfortunate because thereare many new concepts and methods that these organizationswould find beneficial, and it is unacceptable because the essence oflevel 5 is continuous improvement.Unfortunately, many organizations have become entangled inthe weeds of process improvement and have lost sight of the forestand even of the trees. Six Sigma is a powerful and enormously help-ful statistically based method for improvement, but it is easy forpeople to become so enamored with these sophisticated methodsthat they lose sight of the objective. This is a mistake. The key is pri-orities and what will help organizations to improve their businessperformance. This is where external benchmarking and internalperformance measures are needed. Use them to establish improve-ment priorities and then focus your improvement muscle on thoseareas that will substantially improve business performance.Next StepsWhile CMMI has been enormously successful, we have learned agreat deal in the last 25 years, and there are now important newconcepts and methods that were not available when we started. Thekey new concept concerns knowledge work. Peter Drucker, theleading management thinker of the twentieth century, definedknowledge work as work that is done with ideas and conceptsrather than with things. While a great deal of today’s technical workis knowledge work, large-scale knowledge work is a relatively newphenomenon. Except for software, until recently, the really big proj-ects all concerned hardware systems. Now, however, software workpervades most parts of modern systems, and even the work of hard-ware designers more closely resembles that of software developersthan traditional hardware bread boarding and manufacturing.Wow! eBook <WoweBook.Com>
  • 34. To properly manage this new kind of work, new methods areneeded, and Drucker enunciated the key new management concept.This is that knowledge work can’t be managed with traditionalmethods; the knowledge workers must manage themselves.3 Thelogic behind Drucker’s view is compelling, but the story is tooextensive to cover in this short perspective. However, there is agrowing number of publications that describe knowledge work andhow and why new management methods are needed.4In summary, the key point is that software and complex systemsdevelopment projects are large-scale knowledge work, and the rea-son such projects have long been troubled is that they have notbeen managed with suitable methods. The first method that hasbeen designed to follow Drucker’s knowledge-management princi-ples is the Team Software Process (TSP), but there will almost cer-tainly be more such methods in the future.Using the TSP to guide software and systems development proj-ects turns out to be highly effective, and TSP projects are typicallydelivered on schedule, within budget, and with substantiallyimproved quality and productivity.5 To assist CMMI users in contin-uously improving their performance, the SEI has defined a newCMMI-based strategy and a family of practices to guide them inevaluating and piloting these methods. This method is calledCMMI-AIM (Accelerated Improvement Method), and it is currentlyin use by a growing number of organizations.ConclusionsAs we continue refining our processes and methods to address theneeds and practices of creative teams and people, new opportunitieswill keep showing up for broadening the scope of our processes andincluding new methods and technologies as they become available.Because many of these advances will be new to most users, userswill need specific guidance on what these new methods are andhow to best use them. The SEI strategy has been to provide thisguidance for each new family of methods as it becomes availableand is proven in practice.8 PART ONE ABOUT CMMI FOR DEVELOPMENT3. Peter Drucker, Knowledge-Worker Productivity: the Biggest Challenge, California Man-agement Review, Winter 1999, 41, 2, ABI/INFORM Global.4. Watts S. Humphrey, “Why Can’t We Manage Large Projects?” CrossTalk, July/August 2010,pp. 4–7; and Watts S. Humphrey and James W. Over, Leadership, Teamwork, and Trust: Build-ing a Competitive Software Capability, Reading, MA: Addison Wesley, 2011.5. Noopur Davis and Julia Mullaney, Team Software Process (TSP) in Practice, SEI TechnicalReport CMU/SEI-2003-TR-014, September 2003.Wow! eBook <WoweBook.Com>
  • 35. Chapter 1 Introduction 9Two examples of such new methods are CMMI- and TSP-relatedguidance on how to develop secure systems and on how to architectcomplex systems. As we look to the future, there will be many moreopportunities for improving the performance of our systems andsoftware engineering work. The key is to couple these methods intoa coherent improvement framework such as TSP-CMMI and to pro-vide the explicit guidance organizations need to obtain the potentialbenefits of these new methods. To avoid chasing the latest fads,however, organizations should measure their own operations, eval-uate where they stand relative to their leading peers and competi-tors, and focus on those improvements that will measurablyimprove their business performance.About Capability Maturity ModelsA Capability Maturity Model (CMM), including CMMI, is a simpli-fied representation of the world. CMMs contain the essential ele-ments of effective processes. These elements are based on theconcepts developed by Crosby, Deming, Juran, and Humphrey.In the 1930s, Walter Shewhart began work in process improve-ment with his principles of statistical quality control [Shewhart 1931].These principles were refined by W. Edwards Deming [Deming1986], Phillip Crosby [Crosby 1979], and Joseph Juran [Juran 1988].Watts Humphrey, Ron Radice, and others extended these principlesfurther and began applying them to software in their work at IBM(International Business Machines) and the SEI [Humphrey 1989].Humphrey’s book, Managing the Software Process, provides a descrip-tion of the basic principles and concepts on which many of the Capa-bility Maturity Models (CMMs) are based.The SEI has taken the process management premise, “the qualityof a system or product is highly influenced by the quality of theprocess used to develop and maintain it,” and defined CMMs thatembody this premise. The belief in this premise is seen worldwide inquality movements, as evidenced by the International Organizationfor Standardization/International Electrotechnical Commission (ISO/IEC) body of standards.CMMs focus on improving processes in an organization. Theycontain the essential elements of effective processes for one or moredisciplines and describe an evolutionary improvement path from adhoc, immature processes to disciplined, mature processes withimproved quality and effectiveness.Wow! eBook <WoweBook.Com>
  • 36. Like other CMMs, CMMI models provide guidance to use whendeveloping processes. CMMI models are not processes or processdescriptions. The actual processes used in an organization depend onmany factors, including application domains and organization struc-ture and size. In particular, the process areas of a CMMI model typi-cally do not map one to one with the processes used in yourorganization.The SEI created the first CMM designed for software organiza-tions and published it in a book, The Capability Maturity Model:Guidelines for Improving the Software Process [SEI 1995].Today, CMMI is an application of the principles introducedalmost a century ago to this never-ending cycle of process improve-ment. The value of this process improvement approach has been con-firmed over time. Organizations have experienced increasedproductivity and quality, improved cycle time, and more accurate andpredictable schedules and budgets [Gibson 2006].Evolution of CMMIThe CMM Integration project was formed to sort out the problem ofusing multiple CMMs. The combination of selected models into asingle improvement framework was intended for use by organiza-tions in their pursuit of enterprise-wide process improvement.Developing a set of integrated models involved more than simplycombining existing model materials. Using processes that promoteconsensus, the CMMI Product Team built a framework that accom-modates multiple constellations.The first model to be developed was the CMMI for Developmentmodel (then simply called “CMMI”). Figure 1.2 illustrates the mod-els that led to CMMI Version 1.3.Initially, CMMI was one model that combined three source mod-els: the Capability Maturity Model for Software (SW-CMM) v2.0 draftC, the Systems Engineering Capability Model (SECM) [EIA 2002a],and the Integrated Product Development Capability Maturity Model(IPD-CMM) v0.98.These three source models were selected because of their success-ful adoption or promising approach to improving processes in anorganization.The first CMMI model (V1.02) was designed for use by develop-ment organizations in their pursuit of enterprise-wide processimprovement. It was released in 2000. Two years later Version 1.1was released and four years after that, Version 1.2 was released.10 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 37. By the time that Version 1.2 was released, two other CMMI mod-els were being planned. Because of this planned expansion, the nameof the first CMMI model had to change to become CMMI for Devel-opment and the concept of constellations was created.The CMMI for Acquisition model was released in 2007. Since it builton the CMMI for Development Version 1.2 model, it also was namedVersion 1.2. Two years later the CMMI for Services model was released.It built on the other two models and also was named Version 1.2.In 2008 plans were drawn to begin developing Version 1.3, whichwould ensure consistency among all three models and improve highmaturity material in all of the models. Version 1.3 of CMMI forAcquisition [Gallagher 2011, SEI 2010b], CMMI for Development[Chrissis 2011, SEI 2010c], and CMMI for Services [Forrester 2011,SEI 2010a] were released in November 2010.Chapter 1 Introduction 11FIGURE 1.2The History of CMMs66. EIA 731 SECM is the Electronic Industries Alliance standard 731, or the Systems Engineer-ing Capability Model. INCOSE SECAM is International Council on Systems Engineering Sys-tems Engineering Capability Assessment Model [EIA 2002a].V1.02 (2000)V1.1 (2002)History of CMMsCMM for SoftwareV1.1 (1993)Systems EngineeringCMM V1.1 (1995)EIA 731 SECM(1998)INCOSE SECAM(1996)Software CMMV2, draft C (1997)CMMI for DevelopmentV1.2 (2006)CMMI for AcquisitionV1.2 (2007)CMMI for ServicesV1.2 (2009)CMMI for AcquisitionV1.3 (2010)CMMI for DevelopmentV1.3 (2010)CMMI for ServicesV1.3 (2010)Software AcquisitionCMM V1.03 (2002)Integrated ProductDevelopment CMM(1997)Wow! eBook <WoweBook.Com>
  • 38. 12 PART ONE ABOUT CMMI FOR DEVELOPMENTCMMI: Integration and Improvement Continuesby Bob RassaCMMI is almost 15 years old, and has clearly become the world-wide de facto standard for process improvement in the developmentof systems, including systems engineering, software engineering,design engineering, subcontractor management, and program man-agement. Since the release of CMMI V1.2 (for Development) almost5 years ago, CMMI has embraced process improvement for Acquisi-tion as well as the delivery of Services.The full product suite of CMMI-DEV, CMMI-ACQ, and CMMI-SVC covers the complete spectrum of process improvement for theentire business, including commercial and defense industry, govern-ments, and even military organizations. After the initial release ofCMMI in November 2000, well over 1,000 Class A appraisals werereported in just four years—very successful numbers by our mea-sures at that time; whereas recently almost 1,400 Class A appraisalswere conducted in 2009 alone—quite a significant improvement.As of January 2006, more than 45,000 individuals had receivedIntroduction to CMMI training. As of July 2010, that number hasexceeded more than 117,000 students.CMMI-DEV has been translated into Japanese, Chinese, French,German, Spanish, and Portuguese. Translation of CMMI-SVC intoArabic is beginning. The success in CMMI recognition and adop-tion worldwide is undeniable.The CMMI V1.2 architecture was altered slightly to accommo-date two additional CMMI constellations, which we designatedCMMI-ACQ (CMMI for Acquisition) and CMMI-SVC (CMMI forServices). CMMI V1.3 focuses on providing some degree of simpli-fication as well as adding more integrity to the overall productsuite. V1.3 model improvements have a heavy concentration on thehigh maturity aspects embodied in levels 4 and 5, in both the modelstructure as well as the appraisal method.We learned that there were certain ambiguities within the V1.2product suite, and the areas affected are now clarified in V1.3 toachieve greater consistency in overall model deployment andappraisal conduct of CMMI. The criteria that are used in theappraisal audit process, which was implemented in 2008, have nowbeen incorporated in the product suite where appropriate. We havealso provided clarification on the sampling of “focus programs” inWow! eBook <WoweBook.Com>
  • 39. the appraised organization to reduce the complexity and timeinvolved in conducting Class A appraisals, thereby reducing thecost of implementing CMMI.It has been noted by some that CMMI is only for large organiza-tions, but the data tells a different story. In fact, a large number ofsmall organizations have been appraised and have told us that theyreap benefits of CMMI far beyond the investment. A comprehensiveBenefits of CMMI report is now on the website of the designatedCMMI Steward, the Software Engineering Institute of Carnegie Mel-lon University (http://www.sei.cmu.edu/cmmi). This report, essen-tially a compendium of real benefits provided by users, clearlyshows positive effects such as reduced defects on delivery, reducedtime to identify defects, and more. The data tells us that CMMI istruly state-of-the-art in-process improvement, and the substantivebenefits reported confirm this.However, to be truly effective, CMMI must be applied conscien-tiously within the organization. When we started the initial devel-opment of CMMI, it was well-publicized that its purpose was tointegrate the divergent maturity models that existed at the time. Wesoon realized that the real purpose that should have been commu-nicated as the ultimate benefit of CMMI was that this integratedmodel would integrate the design and management disciplines interms of both process and performance.To achieve this ultimate benefit, care is needed to ensure thatintegrated processes are put into place within the organization, thatsuch processes are implemented across the enterprise on all newprograms and projects, and that such implementation is done in athorough manner to assure that new programs start out on the rightfoot.This book provides the latest expert and detailed guidance foreffective CMMI implementation. It covers all the specifics of V1.3and addresses nuances of interpretation as well as expert adviceuseful to the new and experienced practitioner.Hundreds of process improvement experts have contributed tothe overall CMMI development and update, and many of them con-tributed their expertise to this volume for the benefit of the world-wide user community. We trust you will enjoy their work and findit useful as you continue your journey along the path of continuousprocess improvement.Remember, great designers and great managers will still likelyfail without a proven process framework, and this is what CMMIprovides.Chapter 1 Introduction 13Wow! eBook <WoweBook.Com>
  • 40. 14 PART ONE ABOUT CMMI FOR DEVELOPMENTCMMI FrameworkThe CMMI Framework provides the structure needed to produceCMMI models, training, and appraisal components. To allow the useof multiple models within the CMMI Framework, model compo-nents are classified as either common to all CMMI models or applica-ble to a specific model. The common material is called the “CMMIModel Foundation” or “CMF.”The components of the CMF are part of every model generatedfrom the CMMI Framework. Those components are combined withmaterial applicable to an area of interest (e.g., acquisition, develop-ment, services) to produce a model.A “constellation” is defined as a collection of CMMI componentsthat are used to construct models, training materials, and appraisalrelated documents for an area of interest (e.g., acquisition, develop-ment, services). The Development constellation’s model is called“CMMI for Development” or “CMMI-DEV.”The Architecture of the CMMI Frameworkby Roger Batewith a postscript by Mike KonradOver the years, as the CMMI Product Suite has been used in dis-parate industries and organizations, it became apparent that CMMIcould be applied to all kinds of product development, especially ifthe terminology was kept general for similar practices.A further revelation was that the process and project manage-ment practices of the model are suitable for a wide range of activi-ties besides product development. This discovery led me to proposethat we should enable the expansion of CMMI, including the exten-sion of the scope of CMMI, by creating a new architecture for theCMMI Framework.This new architecture would accommodate other areas of inter-est (e.g., Services and Acquisition). I was musing one day about thevaluable best practices that were contained in models. I began tothink of them as the stars of process improvement. I pushed thismetaphor a little further to call the collection of components thatwould be useful in building a model, its training materials, andappraisal documents for an area of interest a constellation. This wasthe beginning of the architecture that was eventually created.Wow! eBook <WoweBook.Com>
  • 41. There are two primary objectives for the CMMI Frameworkarchitecture:• Enable the coverage of selected areas of interest to make use-ful and effective processes.• Promote maximum commonality of goals and practices acrossmodels, training materials, and appraisal methods.These objectives pull in opposite directions; therefore, thearchitecture was designed as a bit of a compromise.The CMMI Framework will be used in the future to accommo-date additional content that the user community indicates is desir-able. The framework contains components used to constructmodels and their corresponding training and appraisal materials.The framework is organized so that the models constructed willbenefit from common terminology and common practices that haveproven to be valuable in previous models.The CMMI Framework is a collection of all model components,training material components, and appraisal components. Thesecomponents are organized into groupings, called constellations,which facilitate construction of approved models and preserve thelegacy of existing CMM and CMMI models.In the framework, there are constellations of components thatare used to construct models in an area of interest (e.g., Acquisition,Development, and Services). Also in the framework, there is aCMMI model foundation. This foundation is a skeleton model thatcontains the core model components in a CMMI model structure.The content of the CMMI model foundation is apropos to all areasof interest addressed by the constellations. A CMMI model for aconstellation is constructed by inserting additional model compo-nents into the CMMI model foundation.Because the CMMI architecture is designed to encourage pre-serving as much common material as is reasonable in a multipleconstellation environment, the framework contains and controls allCMMI material that can be used to produce any constellation ormodel.CMMI models have a defined structure. This structure isdesigned to provide familiar placement of model components ofvarious constellations and versions. If you look at the structure of aprocess area, you’ll see components including Process Area Name,Category, Maturity Level, Purpose, Introductory Notes, References,and Specific Goals. You will also find that every process area in thisChapter 1 Introduction 15Wow! eBook <WoweBook.Com>
  • 42. model (i.e., CMMI for Development) and all other CMMI modelsproduced from the CMMI Framework have the same structure. Thisfeature helps you to understand quickly where to look for informa-tion in any CMMI model.One of the benefits of having a common architecture and a largeportion of common content in the various models is that the effortrequired to write models, train users, and appraise organizations isgreatly reduced. The ability to add model components to the com-mon process areas permits them to expand their scope of coverageto a greater variety of needs. In addition, whole new process areasmay be added to provide greater coverage of different areas of inter-est in the constellations.CMMI models have a great deal of well-tested content that canbe used to guide the creation of high performance processes. TheCMMI architecture permits that valuable content to continue towork in different areas of interest, while allowing for innovationand agility in responding to new needs.You can see that CMMI has grown beyond the star practices ofthe three original source models to constellations. This expansioninto the galaxy is only possible with a well-thought-out anddesigned architecture to support it. The CMMI architecture hasbeen designed to provide such support and will grow as needed tocontinue into the future.PostscriptRoger passed away in 2009, about two years after this perspectivewas written for the second edition of this book. Roger’s grand visionof constellations and a flexible architecture that established a deeplevel of commonality among CMMI models was largely realized inthe sequential release of the three V1.2 CMMI models publishedbetween 2006 and 2009.One of many anecdotes that reveals Roger’s transcending visionand greatness and reflects on the early days of CMMI is when I wascontacted by friend and colleague Tomoo Matsubara-san in 1997.He asked me to provide a short opinion piece for his Soapbox col-umn in IEEE Software magazine. At the time, we at the SEI wereconfronted with consternation from many Software CMM transitionpartners because they felt that we were abandoning the SoftwareCMM product line. Instead, we were pursuing the convergence ofthe software engineering and systems engineering process improve-ment communities by creating a product line that both could use.16 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 43. We hoped such a convergence would not only eliminate theneed to separately maintain two models and associated productlines (those for the Software CMM and the EIA 731 Systems Engi-neering Capability Model), but also would encourage synergismwithin organizations addressing system-wide performance issues.To me, the Soapbox column provided an opportunity to communi-cate what we were hoping to accomplish with CMMI, so I suggestedto Roger that he write something for Matsubara-san’s column onwhy software engineering would benefit from a “systems engineer-ing” perspective.This chain of events led to Roger’s Soapbox piece, “Do SystemsEngineering? Who, Me?”7 This anecdote typifies Roger’s brilliance,ability to span multiple disciplines, and talent for motivating multiplestakeholders with a unifying vision and a shared mission to changethe organization’s behavior and achieve superior performance.As mentioned, Roger’s vision was largely realized with therelease of the Version 1.2 CMMI Product Suite. For V1.3, however,we confronted a challenge that required some modification toRoger’s initial vision for the CMMI architecture.The challenge was the term “project,” which commonly refersto an endeavor whose purpose and end are marked by the deliveryof something tangible (e.g., a product). This term appearedthroughout many of the process areas (PAs) and was generally agood fit for CMMI-ACQ and CMMI-DEV but not for CMMI-SVC.After researching the problem, we devised a solution: for V1.3, wewould allow the CMF to vary across constellations in a very limitedway. CMF material in CMMI-DEV and CMMI-ACQ could continueto refer to “projects;” whereas in CMMI-SVC, the reference wouldinstead be to “work,” “work activities,” “services,” or similar. In thisway, the CMMI user community could continue to use commonEnglish terms in a familiar and consistent way while benefittingfrom a sharing of CMMI terminology and best practices (for 17PAs) across a broad range of process improvement communities.(This idea was researched by exploratory implementation, a survey,and pilots; and it worked well.)V1.3 benefits from many synergies. The sequential release of newconstellations for V1.2 between 2006 and 2009 provided the oppor-tunity to evaluate what CMF should be—one context at a time.However, in V1.3 development, model material originally proposedChapter 1 Introduction 177. Roger R. Bate, “Do Systems Engineering? Who, Me?” IEEE Software, vol. 15, no. 4, pp.65–66, July/Aug. 1998, doi:10.1109/52.687947.Wow! eBook <WoweBook.Com>
  • 44. for one area of interest was sometimes extended to all three. Exam-ples include the concept of quality attributes; prioritization ofrequirements; ontology for products and services; a richer set ofexamples for measurement and analysis; a sharper focus on what isessential to team performance (i.e., team composition, empower-ment, and operational discipline); and alignment of high maturitypractices with business objectives enabled by analytics. The V1.3user may be unaware of these synergies or their sources, but mayderive benefit from them.With V1.3, we’ve only begun to explore ideas for the future ofCMMI. Beyond V1.3, there are lots of promising directions forward,which is only the case because of Roger’s original pioneering visionfor CMMI. With Roger’s passing, his Chief Architect mantle hasbeen passed on to someone many years his junior (me) and I canassure our readers that well into his mid-80s, Roger remained atruly brilliant man, retaining his clear thinking and ear for nuancewhile maintaining a broad perspective when rendering an opinion;and so I recognize almost as much as anyone how big a space he hasleft behind. Although he was the one who conceived of the termconstellations as a way of thinking about CMMI architecture, to uswho knew him well, he was the real star of CMMI.CMMI for DevelopmentCMMI for Development is a reference model that covers activities fordeveloping both products and services. Organizations from manyindustries, including aerospace, banking, computer hardware, soft-ware, defense, automobile manufacturing, and telecommunications,use CMMI for Development.CMMI for Development contains practices that cover projectmanagement, process management, systems engineering, hardwareengineering, software engineering, and other supporting processesused in development and maintenance.Use professional judgment and common sense to interpret themodel for your organization. That is, although the process areasdescribed in this model depict behaviors considered best practicesfor most users, process areas and practices should be interpretedusing an in-depth knowledge of CMMI-DEV, your organizationalconstraints, and your business environment.18 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 45. CHAPTER 2PROCESS AREA COMPONENTSThis chapter describes the components found in each process areaand in the generic goals and generic practices. Understanding thesecomponents is critical to using the information in Part Two effec-tively. If you are unfamiliar with Part Two, you may want to skim theGeneric Goals and Generic Practices section and a couple of processarea sections to get a general feel for the content and layout beforereading this chapter.Core Process Areas and CMMI ModelsAll CMMI models are produced from the CMMI Framework. Thisframework contains all of the goals and practices that are used toproduce CMMI models that belong to CMMI constellations.All CMMI models contain 16 core process areas. These processareas cover basic concepts that are fundamental to process improve-ment in any area of interest (i.e., acquisition, development, services).Some of the material in the core process areas is the same in all con-stellations. Other material may be adjusted to address a specific areaof interest. Consequently, the material in the core process areas maynot be exactly the same.Required, Expected, and Informative ComponentsModel components are grouped into three categories—required,expected, and informative—that reflect how to interpret them.Required ComponentsRequired components are CMMI components that are essential to achiev-ing process improvement in a given process area. This achievement19Wow! eBook <WoweBook.Com>
  • 46. must be visibly implemented in an organization’s processes. Therequired components in CMMI are the specific and generic goals.Goal satisfaction is used in appraisals as the basis for decidingwhether a process area has been satisfied.Expected ComponentsExpected components are CMMI components that describe the activ-ities that are important in achieving a required CMMI component.Expected components guide those who implement improvements orperform appraisals. The expected components in CMMI are the spe-cific and generic practices.Before goals can be considered to be satisfied, either their prac-tices as described, or acceptable alternatives to them, must be presentin the planned and implemented processes of the organization.Informative ComponentsInformative components are CMMI components that help modelusers understand CMMI required and expected components. Thesecomponents can be example boxes, detailed explanations, or otherhelpful information. Subpractices, notes, references, goal titles, prac-tice titles, sources, example work products, and generic practiceelaborations are informative model components.The informative material plays an important role in understand-ing the model. It is often impossible to adequately describe thebehavior required or expected of an organization using only a singlegoal or practice statement. The model’s informative material providesinformation necessary to achieve the correct understanding of goalsand practices and thus cannot be ignored.Components Associated with Part TwoThe model components associated with Part Two are summarized inFigure 2.1 to illustrate their relationships.The following sections provide detailed descriptions of CMMImodel components.Process AreasA process area is a cluster of related practices in an area that, whenimplemented collectively, satisfies a set of goals considered importantfor making improvement in that area. (See the definition of “processarea” in the glossary.)20 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 47. The 22 process areas are presented in alphabetical order byacronym:• Causal Analysis and Resolution (CAR)• Configuration Management (CM)• Decision Analysis and Resolution (DAR)• Integrated Project Management (IPM)• Measurement and Analysis (MA)• Organizational Process Definition (OPD)• Organizational Process Focus (OPF)• Organizational Performance Management (OPM)• Organizational Process Performance (OPP)• Organizational Training (OT)• Product Integration (PI)• Project Monitoring and Control (PMC)Chapter 2 Process Area Components 21FIGURE 2.1CMMI Model ComponentsProcess AreaPurposeStatementIntroductoryNotesRelatedProcess AreasExpected InformativeRequiredKey:GenericPracticesExample WorkProductsSubpractices Subpractices Generic PracticeElaborationsSpecificPracticesSpecificGoalsGenericGoalsWow! eBook <WoweBook.Com>
  • 48. • Project Planning (PP)• Process and Product Quality Assurance (PPQA)• Quantitative Project Management (QPM)• Requirements Development (RD)• Requirements Management (REQM)• Risk Management (RSKM)• Supplier Agreement Management (SAM)• Technical Solution (TS)• Validation (VAL)• Verification (VER)Purpose StatementsA purpose statement describes the purpose of the process area and isan informative component.For example, the purpose statement of the Organizational ProcessDefinition process area is “The purpose of Organizational ProcessDefinition (OPD) is to establish and maintain a usable set of organi-zational process assets, work environment standards, and rules andguidelines for teams.”Introductory NotesThe introductory notes section of the process area describes themajor concepts covered in the process area and is an informativecomponent.An example from the introductory notes of the Project Monitoringand Control process area is “When actual status deviates significantlyfrom expected values, corrective actions are taken as appropriate.”Related Process AreasThe Related Process Areas section lists references to related processareas and reflects the high-level relationships among the process areas.The Related Process Areas section is an informative component.An example of a reference found in the Related Process Areas sec-tion of the Project Planning process area is “Refer to the Risk Man-agement process area for more information about identifying andanalyzing risks and mitigating risks.”Specific GoalsA specific goal describes the unique characteristics that must be pres-ent to satisfy the process area. A specific goal is a required model22 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 49. component and is used in appraisals to help determine whether aprocess area is satisfied. (See the definition of “specific goal” in theglossary.)For example, a specific goal from the Configuration Managementprocess area is “Integrity of baselines is established and maintained.”Only the statement of the specific goal is a required model com-ponent. The title of a specific goal (preceded by the goal number)and notes associated with the goal are considered informative modelcomponents.Generic GoalsGeneric goals are called “generic” because the same goal statementapplies to multiple process areas. A generic goal describes the charac-teristics that must be present to institutionalize processes that imple-ment a process area. A generic goal is a required model componentand is used in appraisals to determine whether a process area is satis-fied. (See the Generic Goals and Generic Practices section in PartTwo for a more detailed description of generic goals. See the defini-tion of “generic goal” in the glossary.)An example of a generic goal is “The process is institutionalizedas a defined process.”Only the statement of the generic goal is a required model compo-nent. The title of a generic goal (preceded by the goal number) andnotes associated with the goal are considered informative modelcomponents.Specific Goal and Practice SummariesThe specific goal and practice summary provides a high-level sum-mary of the specific goals and specific practices. The specific goaland practice summary is an informative component.Specific PracticesA specific practice is the description of an activity that is consideredimportant in achieving the associated specific goal. The specific prac-tices describe the activities that are expected to result in achievementof the specific goals of a process area. A specific practice is anexpected model component. (See the definition of “specific practice”in the glossary.)For example, a specific practice from the Project Monitoring andControl process area is “Monitor commitments against those identi-fied in the project plan.”Chapter 2 Process Area Components 23Wow! eBook <WoweBook.Com>
  • 50. Only the statement of the specific practice is an expected modelcomponent. The title of a specific practice (preceded by the practicenumber) and notes associated with the specific practice are consid-ered informative model components.Example Work ProductsThe example work products section lists sample outputs from a spe-cific practice. An example work product is an informative modelcomponent. (See the definition of “example work product” in theglossary.)For instance, an example work product for the specific practice“Monitor Project Planning Parameters” in the Project Monitoringand Control process area is “Records of significant deviations.”SubpracticesA subpractice is a detailed description that provides guidance forinterpreting and implementing a specific or generic practice. Sub-practices can be worded as if prescriptive, but they are actually aninformative component meant only to provide ideas that may be use-ful for process improvement. (See the definition of “subpractice” inthe glossary.)For example, a subpractice for the specific practice “Take Correc-tive Action” in the Project Monitoring and Control process area is“Determine and document the appropriate actions needed to addressidentified issues.”Generic PracticesGeneric practices are called “generic” because the same practiceapplies to multiple process areas. The generic practices associatedwith a generic goal describe the activities that are considered impor-tant in achieving the generic goal and contribute to the institutional-ization of the processes associated with a process area. A genericpractice is an expected model component. (See the definition of“generic practice” in the glossary.)For example, a generic practice for the generic goal “The processis institutionalized as a managed process” is “Provide adequateresources for performing the process, developing the work products,and providing the services of the process.”Only the statement of the generic practice is an expected modelcomponent. The title of a generic practice (preceded by the practicenumber) and notes associated with the practice are consideredinformative model components.24 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 51. Chapter 2 Process Area Components 25Generic Practice ElaborationsGeneric practice elaborations appear after generic practices to pro-vide guidance on how the generic practices can be applied uniquelyto process areas. A generic practice elaboration is an informativemodel component. (See the definition of “generic practice elabora-tion” in the glossary.)For example, a generic practice elaboration after the generic prac-tice “Establish and maintain an organizational policy for planningand performing the process” for the Project Planning process area is“This policy establishes organizational expectations for estimatingthe planning parameters, making internal and external commit-ments, and developing the plan for managing the project.”AdditionsAdditions are clearly marked model components that contain infor-mation of interest to particular users. An addition can be informativematerial, a specific practice, a specific goal, or an entire process areathat extends the scope of a model or emphasizes a particular aspectof its use. There are no additions in the CMMI-DEV model.Supporting Informative ComponentsIn many places in the model, further information is needed todescribe a concept. This informative material is provided in the formof the following components:• Notes• Examples• ReferencesNotesA note is text that can accompany nearly any other model compo-nent. It may provide detail, background, or rationale. A note is aninformative model component.For example, a note that accompanies the specific practice“Implement Action Proposals” in the Causal Analysis and Resolutionprocess area is “Only changes that prove to be of value should beconsidered for broad implementation.”ExamplesAn example is a component comprising text and often a list of items,usually in a box, that can accompany nearly any other componentWow! eBook <WoweBook.Com>
  • 52. and provides one or more examples to clarify a concept or describedactivity. An example is an informative model component.The following is an example that accompanies the subpractice“Document noncompliance issues when they cannot be resolved inthe project” under the specific practice “Communicate and Ensurethe Resolution of Noncompliance Issues” in the Process and ProductQuality Assurance process area.Examples of ways to resolve noncompliance in the project include thefollowing:• Fixing the noncompliance• Changing the process descriptions, standards, or procedures that wereviolated• Obtaining a waiver to cover the noncomplianceReferencesA reference is a pointer to additional or more detailed information inrelated process areas and can accompany nearly any other modelcomponent. A reference is an informative model component. (Seethe definition of “reference” in the glossary.)For example, a reference that accompanies the specific practice“Compose the Defined Process” in the Quantitative Project Manage-ment process area is “Refer to the Organizational Process Definitionprocess area for more information about establishing organizationalprocess assets.”Numbering SchemeSpecific and generic goals are numbered sequentially. Each specificgoal begins with the prefix “SG” (e.g., SG 1). Each generic goalbegins with the prefix “GG” (e.g., GG 2).Specific and generic practices are also numbered sequentially.Each specific practice begins with the prefix “SP,” followed by a num-ber in the form “x.y” (e.g., SP 1.1). The x is the same number as thegoal to which the specific practice maps. The y is the sequence num-ber of the specific practice under the specific goal.An example of specific practice numbering is in the Project Plan-ning process area. The first specific practice is numbered SP 1.1 andthe second is SP 1.2.26 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 53. Each generic practice begins with the prefix “GP,” followed by anumber in the form “x.y” (e.g., GP 1.1).The x corresponds to the number of the generic goal. The y is thesequence number of the generic practice under the generic goal. Forexample, the first generic practice associated with GG 2 is numberedGP 2.1 and the second is GP 2.2.Typographical ConventionsThe typographical conventions used in this model were designed toenable you to easily identify and select model components by pre-senting them in formats that allow you to find them quickly on thepage.Figures 2.2, 2.3, and 2.4 are sample pages from process areas inPart Two; they show the different process area components, labeledso that you can identify them. Notice that components differ typo-graphically so that you can easily identify each one.Chapter 2 Process Area Components 27Wow! eBook <WoweBook.Com>
  • 54. FIGURE 2.2Sample Page from Decision Analysis and Resolution28 PART ONE ABOUT CMMI FOR DEVELOPMENTA Support Process Area at Maturity Level 3The purpose of Decision Analysis and Resolution (DAR) is to analyzepossible decisions using a formal evaluation process that evaluatesidentified alternatives against established criteria.The Decision Analysis and Resolution process area involves estab-lishing guidelines to determine which issues should be subject to aformal evaluation process and applying formal evaluation processesto these issues.A formal evaluation process is a structured approach to evaluatingalternative solutions against established criteria to determine a rec-ommended solution.A formal evaluation process involves the following actions:Establishing the criteria for evaluating alternativesIdentifying alternative solutionsSelecting methods for evaluating alternativesEvaluating alternative solutions using established criteria andmethodsSelecting recommended solutions from alternatives based on evalua-tion criteriaRather than using the phrase “alternative solutions to addressissues” each time, in this process area, one of two shorter phrases areused: “alternative solutions” or “alternatives.”A formal evaluation process reduces the subjective nature of adecision and provides a higher probability of selecting a solution thatmeets multiple demands of relevant stakeholders.Process Area NameProcess Area CategoryMaturity LevelevaluatesPurpose StatementIntroductory NotesWow! eBook <WoweBook.Com>
  • 55. FIGURE 2.3Sample Page from Causal Analysis and ResolutionChapter 2 Process Area Components 29SG 2 ADDRESS CAUSES OF SELECTED OUTCOMESRoot causes of selected outcomes are systematically addressed.Projects operating according to a well-defined process systematicallyanalyze where improvements are needed and implement processchanges to address root causes of selected outcomes.SP 2.1 IMPLEMENT ACTION PROPOSALSImplement selected action proposals developed in causal analysis.Action proposals describe tasks necessary to address root causes ofanalyzed outcomes to prevent or reduce the occurrence or recurrenceof negative outcomes, or incorporate realized successes. Action plansare developed and implemented for selected action proposals. Onlychanges that prove to be of value should be considered for broadimplementation.Example Work Products1. Action proposals selected for implementation2. Action plansSubpractices1. Analyze action proposals and determine their priorities.Criteria for prioritizing action proposals include the following:• Implications of not addressing the outcome• Cost to implement process improvements to address the outcome• Expected impact on qualityProcess performance models can be used to help identify interactionsamong multiple action proposals.2. Select action proposals to be implemented.Refer to the Decision Analysis and Resolution process area for more infor-mation about analyzing possible decisions using a formal evaluationprocess that evaluates identified alternatives against established criteria.3. Create action plans for implementing the selected action proposals.Specific GoalisSpecific PracticeSubpracticeExample Work ProductExample BoxReferenceWow! eBook <WoweBook.Com>
  • 56. FIGURE 2.4Sample Page from the Generic Goals and Generic Practices30 PART ONE ABOUT CMMI FOR DEVELOPMENTGG 2 INSTITUTIONALIZE A MANAGED PROCESSThe process is institutionalized as a managed process.GP 2.1 ESTABLISH AN ORGANIZATIONAL POLICYEstablish and maintain an organizational policy for planning and performingthe process.The purpose of this generic practice is to define the organizationalexpectations for the process and make these expectations visible tothose members of the organization who are affected. In general, sen-ior management is responsible for establishing and communicatingguiding principles, direction, and expectations for the organization.Not all direction from senior management will bear the label “pol-icy.” The existence of appropriate organizational direction is theexpectation of this generic practice, regardless of what it is called orhow it is imparted.CAR ElaborationThis policy establishes organizational expectations for identifyingand systematically addressing causal analysis of selected outcomes.CM ElaborationThis policy establishes organizational expectations for establishingand maintaining baselines, tracking and controlling changes to workproducts (under configuration management), and establishing andmaintaining integrity of the baselines.DAR ElaborationThis policy establishes organizational expectations for selectivelyanalyzing possible decisions using a formal evaluation process thatevaluates identified alternatives against established criteria. The pol-icy should also provide guidance on which decisions require a formalevaluation process.IPM ElaborationThis policy establishes organizational expectations for establishingand maintaining the project’s defined process from project startupGeneric Goaland performingGeneric PracticengngkGeneric PracticeElaborationWow! eBook <WoweBook.Com>
  • 57. CHAPTER 3TYING IT ALL TOGETHERNow that you have been introduced to the components of CMMImodels, you need to understand how they fit together to meet yourprocess improvement needs. This chapter introduces the concept oflevels and shows how the process areas are organized and used.CMMI-DEV does not specify that a project or organization mustfollow a particular process flow or that a certain number of productsbe developed per day or specific performance targets be achieved.The model does specify that a project or organization should haveprocesses that address development related practices. To determinewhether these processes are in place, a project or organization mapsits processes to the process areas in this model.The mapping of processes to process areas enables the organiza-tion to track its progress against the CMMI-DEV model as it updatesor creates processes. Do not expect that every CMMI-DEV processarea will map one to one with your organization’s or project’sprocesses.Understanding LevelsLevels are used in CMMI-DEV to describe an evolutionary path rec-ommended for an organization that wants to improve the processes ituses to develop products or services. Levels can also be the outcomeof the rating activity in appraisals.1 Appraisals can apply to entireorganizations or to smaller groups such as a group of projects or adivision.311. For more information about appraisals, refer to Appraisal Requirements for CMMI and theStandard CMMI Appraisal Method for Process Improvement Method Definition Document[SEI 2006a, SEI 2006b].Wow! eBook <WoweBook.Com>
  • 58. CMMI supports two improvement paths using levels. One pathenables organizations to incrementally improve processes correspon-ding to an individual process area (or group of process areas)selected by the organization. The other path enables organizations toimprove a set of related processes by incrementally addressing suc-cessive sets of process areas.These two improvement paths are associated with the two typesof levels: capability levels and maturity levels. These levels corre-spond to two approaches to process improvement called “representa-tions.” The two representations are called “continuous” and “staged.”Using the continuous representation enables you to achieve “capabil-ity levels.” Using the staged representation enables you to achieve“maturity levels.”To reach a particular level, an organization must satisfy all of thegoals of the process area or set of process areas that are targeted forimprovement, regardless of whether it is a capability or a maturitylevel.Both representations provide ways to improve your processes toachieve business objectives, and both provide the same essential con-tent and use the same model components.Structures of the Continuous and Staged RepresentationsFigure 3.1 illustrates the structures of the continuous and staged rep-resentations. The differences between the structures are subtle butsignificant. The staged representation uses maturity levels to charac-terize the overall state of the organization’s processes relative to themodel as a whole, whereas the continuous representation uses capa-bility levels to characterize the state of the organization’s processesrelative to an individual process area.What may strike you as you compare these two representations istheir similarity. Both have many of the same components (e.g.,process areas, specific goals, specific practices), and these compo-nents have the same hierarchy and configuration.What is not readily apparent from the high-level view in Figure3.1 is that the continuous representation focuses on process areacapability as measured by capability levels and the staged representa-tion focuses on overall maturity as measured by maturity levels. Thisdimension (the capability/maturity dimension) of CMMI is used forbenchmarking and appraisal activities, as well as guiding an organi-zation’s improvement efforts.32 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 59. Capability levels apply to an organization’s process improvementachievement in individual process areas. These levels are a means forincrementally improving the processes corresponding to a givenprocess area. The four capability levels are numbered 0 through 3.Maturity levels apply to an organization’s process improvementachievement across multiple process areas. These levels are a meansof improving the processes corresponding to a given set of processareas (i.e., maturity level). The five maturity levels are numbered 1through 5.Table 3.1 compares the four capability levels to the five maturitylevels. Notice that the names of two of the levels are the same in bothrepresentations (i.e., Managed and Defined). The differences are thatthere is no maturity level 0; there are no capability levels 4 and 5; andat level 1, the names used for capability level 1 and maturity level 1are different.Chapter 3 Tying It All Together 33FIGURE 3.1Structure of the Continuous and Staged RepresentationsStaged RepresentationSpecificGoalsSpecificPracticesContinuous RepresentationGenericGoalsGenericPracticesProcess AreasCapability LevelsSpecificGoalsSpecificPracticesGenericGoalsGenericPracticesProcess AreasMaturity LevelsWow! eBook <WoweBook.Com>
  • 60. The continuous representation is concerned with selecting both aparticular process area to improve and the desired capability level forthat process area. In this context, whether a process is performed orincomplete is important. Therefore, the name “Incomplete” is givento the continuous representation starting point.The staged representation is concerned with selecting multipleprocess areas to improve within a maturity level; whether individualprocesses are performed or incomplete is not the primary focus.Therefore, the name “Initial” is given to the staged representationstarting point.Both capability levels and maturity levels provide a way toimprove the processes of an organization and measure how wellorganizations can and do improve their processes. However, the asso-ciated approach to process improvement is different.Understanding Capability LevelsTo support those who use the continuous representation, all CMMImodels reflect capability levels in their design and content.The four capability levels, each a layer in the foundation for ongo-ing process improvement, are designated by the numbers 0 through 3:0. Incomplete1. Performed2. Managed3. DefinedA capability level for a process area is achieved when all of thegeneric goals are satisfied up to that level. The fact that capability34 PART ONE ABOUT CMMI FOR DEVELOPMENTTABLE 3.1 Comparison of Capability and Maturity LevelsContinuous Representation Staged RepresentationLevel Capability Levels Maturity LevelsLevel 0 IncompleteLevel 1 Performed InitialLevel 2 Managed ManagedLevel 3 Defined DefinedLevel 4 Quantitatively ManagedLevel 5 OptimizingWow! eBook <WoweBook.Com>
  • 61. levels 2 and 3 use the same terms as generic goals 2 and 3 is inten-tional because each of these generic goals and practices reflects themeaning of the capability levels of the goals and practices. (See theGeneric Goals and Generic Practices section in Part Two for moreinformation about generic goals and practices.) A short descriptionof each capability level follows.Capability Level 0: IncompleteAn incomplete process is a process that either is not performed or ispartially performed. One or more of the specific goals of the processarea are not satisfied and no generic goals exist for this level sincethere is no reason to institutionalize a partially performed process.Capability Level 1: PerformedA capability level 1 process is characterized as a performed process. Aperformed process is a process that accomplishes the needed work toproduce work products; the specific goals of the process area aresatisfied.Although capability level 1 results in important improvements,those improvements can be lost over time if they are not institution-alized. The application of institutionalization (the CMMI genericpractices at capability levels 2 and 3) helps to ensure that improve-ments are maintained.Capability Level 2: ManagedA capability level 2 process is characterized as a managed process. Amanaged process is a performed process that is planned and executedin accordance with policy; employs skilled people having adequateresources to produce controlled outputs; involves relevant stakehold-ers; is monitored, controlled, and reviewed; and is evaluated foradherence to its process description.The process discipline reflected by capability level 2 helps toensure that existing practices are retained during times of stress.Capability Level 3: DefinedA capability level 3 process is characterized as a defined process. Adefined process is a managed process that is tailored from the organi-zation’s set of standard processes according to the organization’s tai-loring guidelines; has a maintained process description; andcontributes process related experiences to the organizational processassets.Chapter 3 Tying It All Together 35Wow! eBook <WoweBook.Com>
  • 62. A critical distinction between capability levels 2 and 3 is thescope of standards, process descriptions, and procedures. At capabil-ity level 2, the standards, process descriptions, and procedures can bequite different in each specific instance of the process (e.g., on a partic-ular project). At capability level 3, the standards, process descriptions,and procedures for a project are tailored from the organization’s set ofstandard processes to suit a particular project or organizational unitand therefore are more consistent, except for the differences allowedby the tailoring guidelines.Another critical distinction is that at capability level 3 processesare typically described more rigorously than at capability level 2. Adefined process clearly states the purpose, inputs, entry criteria,activities, roles, measures, verification steps, outputs, and exit crite-ria. At capability level 3, processes are managed more proactivelyusing an understanding of the interrelationships of the process activ-ities and detailed measures of the process and its work products.Advancing Through Capability LevelsThe capability levels of a process area are achieved through the appli-cation of generic practices or suitable alternatives to the processesassociated with that process area.Reaching capability level 1 for a process area is equivalent to say-ing that the processes associated with that process area are performedprocesses.Reaching capability level 2 for a process area is equivalent to say-ing that there is a policy that indicates you will perform the process.There is a plan for performing it, resources are provided, responsibil-ities are assigned, training to perform it is provided, selected workproducts related to performing the process are controlled, and so on.In other words, a capability level 2 process can be planned and mon-itored just like any project or support activity.Reaching capability level 3 for a process area is equivalent to sayingthat an organizational standard process exists associated with thatprocess area, which can be tailored to the needs of the project. Theprocesses in the organization are now more consistently defined andapplied because they are based on organizational standard processes.After an organization has reached capability level 3 in the processareas it has selected for improvement, it can continue its improve-ment journey by addressing high maturity process areas (Organiza-tional Process Performance, Quantitative Project Management,Causal Analysis and Resolution, and Organizational PerformanceManagement).36 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 63. Chapter 3 Tying It All Together 37The high maturity process areas focus on improving the perform-ance of those processes already implemented. The high maturityprocess areas describe the use of statistical and other quantitativetechniques to improve organizational and project processes to betterachieve business objectives.When continuing its improvement journey in this way, an organi-zation can derive the most benefit by first selecting the OPP andQPM process areas, and bringing those process areas to capabilitylevels 1, 2, and 3. In doing so, projects and organizations align theselection and analyses of processes more closely with their businessobjectives.After the organization attains capability level 3 in the OPP andQPM process areas, the organization can continue its improvementpath by selecting the CAR and OPM process areas. In doing so, theorganization analyzes the business performance using statistical andother quantitative techniques to determine performance shortfalls,and identifies and deploys process and technology improvementsthat contribute to meeting quality and process-performance objec-tives. Projects and the organization use causal analysis to identifyand resolve issues affecting performance and promote the dissemina-tion of best practices.Applying Principles of Empiricismby Victor R. Basili, Kathleen C. Dangle,and Michele A. ShawThinking EmpiricallyThinking empirically about software engineering changes the wayyou think about process improvement.Software engineering is an engineering discipline. Like otherdisciplines, software engineering requires an empirical paradigmthat involves observing, building models, analyzing, and experi-menting so that we can learn. We need to model the products, theprocesses, and the cause/effect relationships between them in thecontext of the organization and the project set. This empiricalmindset provides a basis for choosing the appropriate processes,analyzing the effects of those selections, and packaging the result-ing knowledge for reuse and evolution; it drives an effective processimprovement initiative.Wow! eBook <WoweBook.Com>
  • 64. 38 PART ONE ABOUT CMMI FOR DEVELOPMENTNote: Systems and software engineering have a lot in common;both require human-intensive implementation approaches and fun-damentally focus on the issue of design, unlike manufacturing. Assuch, this empirical thinking can be applied to systems engineeringas an underlying approach to improving systems engineeringoutcomes.Empirical PrinciplesThere are several principles associated with software engineering.In what follows, we discuss a few of these principles as they relateto process improvement.P1. Observe your business. Organizations have different characteris-tics, goals, and cultures; stakeholders have different and competingneeds. Well-engineered systems and software depend on many vari-ables and context plays a significant role in defining goals andobjectives for what can be and what must be achieved. Organiza-tions must strive to build quantitative and qualitative models tounderstand the cause and effect relationships between processesand products in the context of the development/maintenanceefforts.How else can these organizations articulate the differences andsimilarities among projects in the organization so they have a basisfor selecting the processes to use to achieve their goals?P2. Measurement is fundamental. Measurement is a standard abstrac-tion process that allows us to build models or representations ofwhat we observe so we can reason about relationships in context.The use of models in conjunction with experience, judgment, andintuition can guide decision-making. Measurement through modelsprovides a mechanism for an evidence-based investigation so thatdecisions are supported with facts versus a system of pure beliefs.P3. Process is a variable. Processes need to be selected and tailoredto solve the problem at hand. In order to find the right process forthe right situation, organizations must understand the effects of theprocess under differing conditions. This means a process must bemeasurable so that its effects can be quantified. It also means organ-izations must compile evidence that shows what works under whatcircumstances.P4. Stakeholders must make their goals explicit. There is a wide rangeof stakeholders for any project (e.g., customers, end users, contractmanagers, practitioners, and managers). The organization itself andWow! eBook <WoweBook.Com>
  • 65. different stakeholders have different goals and needs. Organizationsmust make these goals and needs explicit through models andmeasures so they can be communicated, analyzed, synthesized,evaluated, and used to select and tailor the right processes. Makingthem explicit allows them to be packaged so they can be remem-bered and used again.P5. Learn from experience. Organizations have the opportunity tolearn from their experiences and build their core competence insystems and software engineering. For process improvement, thefocus should be on learning about processes and how they interactwith the environment on each project. This learning is evolutionaryand each project should make the organization smarter about howto do the next project. But this learning must be deliberate andexplicit or it will not be available for the organization to leverage.P6. Software Engineering is “big science.” Improving software engi-neering processes must be done through observation and experi-mentation in the context of where the actual products are beingdeveloped. There is a synergistic relationship between practice andresearch. Industrial, government, and academic organizations mustpartner to expand and evolve systems and software competencies.There are so many facets to software engineering that it requiresmultiple talents and differing expertise. We need real-world labora-tories that allow us to see the interactions among teams, processes,and products.The Role of Empiricism in CMMIAt CMMI level 5, process improvement is intended to be an empiri-cally-based activity. Each project is planned and executed usingpractices that are selected based on the context of the environment,the project needs, and past experiences. A level 5 organizationunderstands the relationship between process and product and iscapable of manipulating process to achieve various product charac-teristics. It is this capability that provides the greatest value fromprocess improvement to the organization.Empirical thinking shifts the process-improvement mindsetfrom “putting processes in place” to “understanding the effects ofprocesses so that appropriate processes can be adopted.” Differentand better decisions are made regarding how we choose improve-ment initiatives (prioritize), how we implement practices, and howwe manage efforts in projects and in organizations when ourexplicit approach is based on empirical principles. That mindsetChapter 3 Tying It All Together 39Wow! eBook <WoweBook.Com>
  • 66. should be in place at the beginning of the process improvement ini-tiative, thereby focusing the effort on the real objectives of the proj-ect or the organization, the specific product and process problems,relevant experience with methods, and so on.Organizations that are effective at implementing processimprovement understand and apply empirical principles. Addition-ally, practices that support these principles are evident withinCMMI. CMMI prescribes that data be used to make decisions aboutprocess definition at the project level as well as process change atthe organizational level. Measurement and learning are catalysts forall of the practices; that is, they provide the bases for why specificpractices are selected and how processes are implemented. Systemsand software engineering practices are refined and fine-tuned astheir effects are better understood.Some Empirical Techniques That Support CMMIMany techniques and methods exist to assist organizations andprojects realize their goals by implementing CMMI practices. Beloware some techniques that the Fraunhofer Center has effectivelyimplemented that you may wish to consider:Goal/Question/Metric (GQM) Approach—An essential technique formeasurement in any context, GQM can support realization of P2and P4. Originally, GQM was defined for NASA Goddard SpaceFlight Center to evaluate software defects on a set of projects.2Quality Improvement Paradigm (QIP)—A phased process for organi-zational improvement that integrates the experience of individualprojects with the corporate learning process, and can help realizeEmpirical Principles P1, P3, and P5. QIP includes characterizingthe organization through models, setting goals, choosing appropri-ate processes for implementation on projects, analyzing results, andpackaging the experience for future use in the organization.3Experience Factory (EF)—A concept based on the continual accu-mulation of project experiences that are essential to organizationaland project improvement, EF highlights the logical separationbetween the project organization and the factory that processes the40 PART ONE ABOUT CMMI FOR DEVELOPMENT2. V. Basili, G. Caldiera, and H. D. Rombach, “Goal Question Metric Approach,” Encyclope-dia of Software Engineering, pp. 528–532, John Wiley & Sons, Inc., 1994.3. V. Basili and G. Caldiera, “Improve Software Quality by Reusing Knowledge and Experi-ence,” Sloan Management Review, MIT Press, vol. 37(1): 55–64, Fall 1995.Wow! eBook <WoweBook.Com>
  • 67. project experiences in an organization experience base to make itreusable. EF can help realize Empirical Principles P1, P2, and P5.4GQM+Strategies—An approach that supports strategic measure-ment by extending GQM to support goal definition and alignment,strategy development, measurement implementation, and assess-ment across an enterprise.5 GQM+Strategies assists the organizationin tying together its approach and motivations underlying theimplementation of the Empirical Principles.Adopting these empirical principles early, understanding theirrole in CMMI, and deliberately selecting techniques to support youreffort can have a profound effect on the success of the organizationas you embark the process improvement path.4. V. Basili, G. Caldiera, and H. D. Rombach, “The Experience Factory,” Encyclopedia of Soft-ware Engineering, pp. 469–476, John Wiley & Sons, Inc., 1994.5. Victor R. Basili, Mikael Lindvall, Myrna Regardie, Carolyn Seaman, Jens Heidrich, JurgenMunch, Dieter Rombach, and Adam Trendowicz, “Linking Software Development and Busi-ness Strategy Through Measurement,” IEEE Computer, pp. 57–65, April, 2010.Understanding Maturity LevelsTo support those who use the staged representation, all CMMI modelsreflect maturity levels in their design and content. A maturity levelconsists of related specific and generic practices for a predefined setof process areas that improve the organization’s overall performance.The maturity level of an organization provides a way to character-ize its performance. Experience has shown that organizations dotheir best when they focus their process improvement efforts on amanageable number of process areas at a time and that those areasrequire increasing sophistication as the organization improves.A maturity level is a defined evolutionary plateau for organiza-tional process improvement. Each maturity level matures an impor-tant subset of the organization’s processes, preparing it to move tothe next maturity level. The maturity levels are measured by theachievement of the specific and generic goals associated with eachpredefined set of process areas.The five maturity levels, each a layer in the foundation for ongoingprocess improvement, are designated by the numbers 1 through 5:1. Initial2. ManagedChapter 3 Tying It All Together 41Wow! eBook <WoweBook.Com>
  • 68. 3. Defined4. Quantitatively Managed5. OptimizingRemember that maturity levels 2 and 3 use the same terms ascapability levels 2 and 3. This consistency of terminology was inten-tional because the concepts of maturity levels and capability levelsare complementary. Maturity levels are used to characterize organiza-tional improvement relative to a set of process areas, and capabilitylevels characterize organizational improvement relative to an individ-ual process area.Maturity Level 1: InitialAt maturity level 1, processes are usually ad hoc and chaotic. Theorganization usually does not provide a stable environment to sup-port processes. Success in these organizations depends on the com-petence and heroics of the people in the organization and not on theuse of proven processes. In spite of this chaos, maturity level 1organizations often produce products and services that work, butthey frequently exceed the budget and schedule documented in theirplans.Maturity level 1 organizations are characterized by a tendency toovercommit, abandon their processes in a time of crisis, and beunable to repeat their successes.Maturity Level 2: ManagedAt maturity level 2, the projects have ensured that processes areplanned and executed in accordance with policy; the projects employskilled people who have adequate resources to produce controlledoutputs; involve relevant stakeholders; are monitored, controlled,and reviewed; and are evaluated for adherence to their processdescriptions. The process discipline reflected by maturity level 2helps to ensure that existing practices are retained during times ofstress. When these practices are in place, projects are performed andmanaged according to their documented plans.Also at maturity level 2, the status of the work products are visi-ble to management at defined points (e.g., at major milestones, at thecompletion of major tasks). Commitments are established among rel-evant stakeholders and are revised as needed. Work products areappropriately controlled. The work products and services satisfytheir specified process descriptions, standards, and procedures.42 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 69. Maturity Level 3: DefinedAt maturity level 3, processes are well characterized and understood,and are described in standards, procedures, tools, and methods. Theorganization’s set of standard processes, which is the basis for matu-rity level 3, is established and improved over time. These standardprocesses are used to establish consistency across the organization.Projects establish their defined processes by tailoring the organiza-tion’s set of standard processes according to tailoring guidelines. (Seethe definition of “organization’s set of standard processes” in theglossary.)A critical distinction between maturity levels 2 and 3 is the scopeof standards, process descriptions, and procedures. At maturity level 2,the standards, process descriptions, and procedures can be quite dif-ferent in each specific instance of the process (e.g., on a particularproject). At maturity level 3, the standards, process descriptions, andprocedures for a project are tailored from the organization’s set ofstandard processes to suit a particular project or organizational unitand therefore are more consistent except for the differences allowedby the tailoring guidelines.Another critical distinction is that at maturity level 3, processesare typically described more rigorously than at maturity level 2. Adefined process clearly states the purpose, inputs, entry criteria, activ-ities, roles, measures, verification steps, outputs, and exit criteria. Atmaturity level 3, processes are managed more proactively using anunderstanding of the interrelationships of process activities anddetailed measures of the process, its work products, and its services.At maturity level 3, the organization further improves itsprocesses that are related to the maturity level 2 process areas.Generic practices associated with generic goal 3 that were notaddressed at maturity level 2 are applied to achieve maturity level 3.Maturity Level 4: Quantitatively ManagedAt maturity level 4, the organization and projects establish quantita-tive objectives for quality and process performance and use them ascriteria in managing projects. Quantitative objectives are based onthe needs of the customer, end users, organization, and processimplementers. Quality and process performance is understood in sta-tistical terms and is managed throughout the life of projects.For selected subprocesses, specific measures of process perform-ance are collected and statistically analyzed. When selecting sub-processes for analyses, it is critical to understand the relationshipsChapter 3 Tying It All Together 43Wow! eBook <WoweBook.Com>
  • 70. between different subprocesses and their impact on achieving theobjectives for quality and process performance. Such an approachhelps to ensure that subprocess monitoring using statistical andother quantitative techniques is applied to where it has the mostoverall value to the business. Process performance baselines andmodels can be used to help set quality and process performanceobjectives that help achieve business objectives.A critical distinction between maturity levels 3 and 4 is the pre-dictability of process performance. At maturity level 4, the perform-ance of projects and selected subprocesses is controlled usingstatistical and other quantitative techniques, and predictions arebased, in part, on a statistical analysis of fine-grained process data.Maturity Level 5: OptimizingAt maturity level 5, an organization continually improves itsprocesses based on a quantitative understanding of its businessobjectives and performance needs. The organization uses a quantita-tive approach to understand the variation inherent in the process andthe causes of process outcomes.Maturity level 5 focuses on continually improving process per-formance through incremental and innovative process and technolog-ical improvements. The organization’s quality and process performanceobjectives are established, continually revised to reflect changingbusiness objectives and organizational performance, and used as cri-teria in managing process improvement. The effects of deployedprocess improvements are measured using statistical and other quan-titative techniques and compared to quality and process performanceobjectives. The project’s defined processes, the organization’s set ofstandard processes, and supporting technology are targets of measur-able improvement activities.A critical distinction between maturity levels 4 and 5 is the focuson managing and improving organizational performance. At maturitylevel 4, the organization and projects focus on understanding andcontrolling performance at the subprocess level and using the resultsto manage projects. At maturity level 5, the organization is con-cerned with overall organizational performance using data collectedfrom multiple projects. Analysis of the data identifies shortfalls orgaps in performance. These gaps are used to drive organizationalprocess improvement that generates measurable improvement inperformance.44 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 71. Advancing Through Maturity LevelsOrganizations can achieve progressive improvements in their matu-rity by achieving control first at the project level and continuing tothe most advanced level—organization-wide performance manage-ment and continuous process improvement—using both qualitativeand quantitative data to make decisions.Since improved organizational maturity is associated withimprovement in the range of expected results that can be achieved byan organization, maturity is one way of predicting general outcomesof the organization’s next project. For instance, at maturity level 2,the organization has been elevated from ad hoc to disciplined byestablishing sound project management. As the organization achievesgeneric and specific goals for the set of process areas in a maturitylevel, it increases its organizational maturity and reaps the benefits ofprocess improvement. Because each maturity level forms a necessaryfoundation for the next level, trying to skip maturity levels is usuallycounterproductive.At the same time, recognize that process improvement effortsshould focus on the needs of the organization in the context of itsbusiness environment and that process areas at higher maturity lev-els can address the current and future needs of an organization orproject.For example, organizations seeking to move from maturity level 1to maturity level 2 are frequently encouraged to establish a processgroup, which is addressed by the Organizational Process Focus processarea at maturity level 3. Although a process group is not a necessarycharacteristic of a maturity level 2 organization, it can be a usefulpart of the organization’s approach to achieving maturity level 2.This situation is sometimes characterized as establishing a matu-rity level 1 process group to bootstrap the maturity level 1 organiza-tion to maturity level 2. Maturity level 1 process improvementactivities may depend primarily on the insight and competence of theprocess group until an infrastructure to support more disciplined andwidespread improvement is in place.Organizations can institute process improvements anytime theychoose, even before they are prepared to advance to the maturitylevel at which the specific practice is recommended. In such situa-tions, however, organizations should understand that the success ofthese improvements is at risk because the foundation for their suc-cessful institutionalization has not been completed. Processes with-out the proper foundation can fail at the point they are neededmost—under stress.Chapter 3 Tying It All Together 45Wow! eBook <WoweBook.Com>
  • 72. A defined process that is characteristic of a maturity level 3 organ-ization can be placed at great risk if maturity level 2 managementpractices are deficient. For example, management may commit to apoorly planned schedule or fail to control changes to baselinedrequirements. Similarly, many organizations prematurely collect thedetailed data characteristic of maturity level 4 only to find the datauninterpretable because of inconsistencies in processes and measure-ment definitions.Another example of using processes associated with higher matu-rity level process areas is in the building of products. Certainly, wewould expect maturity level 1 organizations to perform requirementsanalysis, design, product integration, and verification. However,these activities are not described until maturity level 3, where theyare defined as coherent, well-integrated engineering processes. Thematurity level 3 engineering process complements a maturing projectmanagement capability put in place so that the engineering improve-ments are not lost by an ad hoc management process.Process AreasProcess areas are viewed differently in the two representations. Fig-ure 3.2 compares views of how process areas are used in the continu-ous representation and the staged representation.The continuous representation enables the organization to choosethe focus of its process improvement efforts by choosing thoseprocess areas, or sets of interrelated process areas, that best benefitthe organization and its business objectives. Although there are somelimits on what an organization can choose because of the dependen-cies among process areas, the organization has considerable freedomin its selection.To support those who use the continuous representation, processareas are organized into four categories: Process Management, Proj-ect Management, Engineering, and Support. These categories empha-size some of the key relationships that exist among the process areas.Sometimes an informal grouping of process areas is mentioned:high maturity process areas. The four high maturity process areasare: Organizational Process Performance, Quantitative Project Man-agement, Organizational Performance Management, and CausalAnalysis and Resolution. These process areas focus on improving theperformance of implemented processes that most closely relate to theorganization’s business objectives.46 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 73. Chapter 3 Tying It All Together 47FIGURE 3.2Process Areas in the Continuous and Staged RepresentationsContinuousTarget ProfileProcess Area 1Process Area 2Process Area 3Process Area 4Process Area NTargeted Capability LevelsSelectedProcessAreasCL1 CL2 CL3= Groups of process areas chosen for process improvement to achieve maturity level 3PMCPPPPQACMMAREQMSAMStagedSelected Maturity LevelMaturity Level 5Maturity Level 4Maturity Level 2Maturity Level 3Wow! eBook <WoweBook.Com>
  • 74. Once you select process areas, you must also select how muchyou would like to mature processes associated with those processareas (i.e., select the appropriate capability level). Capability levelsand generic goals and practices support the improvement ofprocesses associated with individual process areas. For example, anorganization may wish to reach capability level 2 in one process areaand capability level 3 in another. As the organization reaches a capa-bility level, it sets its sights on the next capability level for one ofthese same process areas or decides to widen its view and address alarger number of process areas. Once it reaches capability level 3 inmost of the process areas, the organization can shift its attention tothe high maturity process areas and can track the capability of eachthrough capability level 3.The selection of a combination of process areas and capability lev-els is typically described in a “target profile.” A target profile definesall of the process areas to be addressed and the targeted capabilitylevel for each. This profile governs which goals and practices theorganization will address in its process improvement efforts.Most organizations, at minimum, target capability level 1 for theprocess areas they select, which requires that all of these processareas’ specific goals be achieved. However, organizations that targetcapability levels higher than 1 concentrate on the institutionalizationof selected processes in the organization by implementing genericgoals and practices.The staged representation provides a path of improvement frommaturity level 1 to maturity level 5 that involves achieving the goalsof the process areas at each maturity level. To support those who usethe staged representation, process areas are grouped by maturitylevel, indicating which process areas to implement to achieve eachmaturity level.For example, at maturity level 2, there is a set of process areasthat an organization would use to guide its process improvementuntil it could achieve all the goals of all these process areas. Oncematurity level 2 is achieved, the organization focuses its efforts onmaturity level 3 process areas, and so on. The generic goals thatapply to each process area are also predetermined. Generic goal 2applies to maturity level 2 and generic goal 3 applies to maturity lev-els 3 through 5.Table 3.2 provides a list of CMMI-DEV process areas and theirassociated categories and maturity levels.48 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 75. Equivalent StagingEquivalent staging is a way to compare results from using the contin-uous representation to results from using the staged representation.In essence, if you measure improvement relative to selected processareas using capability levels in the continuous representation, howdo you translate that work into maturity levels? Is this translationpossible?Up to this point, we have not discussed process appraisals inmuch detail. The SCAMPI method6 is used to appraise organizationsusing CMMI, and one result of an appraisal is a rating [SEI 2011a,Chapter 3 Tying It All Together 49TABLE 3.2 Process Areas, Categories, and Maturity LevelsProcess Area Category Maturity LevelCausal Analysis and Resolution (CAR) Support 5Configuration Management (CM) Support 2Decision Analysis and Resolution (DAR) Support 3Integrated Project Management (IPM) Project Management 3Measurement and Analysis (MA) Support 2Organizational Process Definition (OPD) Process Management 3Organizational Process Focus (OPF) Process Management 3Organizational Performance Management (OPM) Process Management 5Organizational Process Performance (OPP) Process Management 4Organizational Training (OT) Process Management 3Product Integration (PI) Engineering 3Project Monitoring and Control (PMC) Project Management 2Project Planning (PP) Project Management 2Process and Product Quality Assurance (PPQA) Support 2Quantitative Project Management (QPM) Project Management 4Requirements Development (RD) Engineering 3Requirements Management (REQM) Project Management 2Risk Management (RSKM) Project Management 3Supplier Agreement Management (SAM) Project Management 2Technical Solution (TS) Engineering 3Validation (VAL) Engineering 3Verification (VER) Engineering 36. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) method isdescribed in Chapter 5.Wow! eBook <WoweBook.Com>
  • 76. Ahern 2005]. If the continuous representation is used for an appraisal,the rating is a “capability level profile.” If the staged representation isused for an appraisal, the rating is a “maturity level rating” (e.g.,maturity level 3).A capability level profile is a list of process areas and the corre-sponding capability level achieved for each. This profile enables anorganization to track its capability level by process area. The profileis called an “achievement profile” when it represents the organiza-tion’s actual progress for each process area. Alternatively, the profileis called a “target profile” when it represents the organization’splanned process improvement objectives.Figure 3.3 illustrates a combined target and achievement profile.The blue portion of each bar represents what has been achieved. Theunshaded portion represents what remains to be accomplished tomeet the target profile.50 PART ONE ABOUT CMMI FOR DEVELOPMENTFIGURE 3.3Example Combined Target and Achievement ProfileRequirementsManagementProjectPlanningProjectMonitoringand ControlSupplierAgreementManagementMeasurementand AnalysisProcess andProduct QualityAssuranceConfigurationManagementCapabilityLevel 1CapabilityLevel 2CapabilityLevel 3Wow! eBook <WoweBook.Com>
  • 77. An achievement profile, when compared with a target profile,enables an organization to plan and track its progress for eachselected process area. Maintaining capability level profiles is advis-able when using the continuous representation.Target staging is a sequence of target profiles that describes thepath of process improvement to be followed by the organization.When building target profiles, the organization should pay attentionto the dependencies between generic practices and process areas. If ageneric practice depends on a process area, either to carry out thegeneric practice or to provide a prerequisite work product, the genericpractice can be much less effective when the process area is notimplemented.7Although the reasons to use the continuous representation aremany, ratings consisting of capability level profiles are limited intheir ability to provide organizations with a way to generally com-pare themselves with other organizations. Capability level profilescan be used if each organization selects the same process areas; how-ever, maturity levels have been used to compare organizations foryears and already provide predefined sets of process areas.Because of this situation, equivalent staging was created. Equiva-lent staging enables an organization using the continuous representa-tion to convert a capability level profile to the associated maturitylevel rating.The most effective way to depict equivalent staging is to provide asequence of target profiles, each of which is equivalent to a maturitylevel rating of the staged representation reflected in the process areaslisted in the target profile. The result is a target staging that is equiva-lent to the maturity levels of the staged representation.Figure 3.4 shows a summary of the target profiles that must beachieved when using the continuous representation to be equivalentto maturity levels 2 through 5. Each shaded area in the capabilitylevel columns represents a target profile that is equivalent to a matu-rity level.The following rules summarize equivalent staging:• To achieve maturity level 2, all process areas assigned to maturitylevel 2 must achieve capability level 2 or 3.• To achieve maturity level 3, all process areas assigned to maturity lev-els 2 and 3 must achieve capability level 3.Chapter 3 Tying It All Together 517. See Table 7.2 in the Generic Goals and Generic Practices section of Part Two for more infor-mation about the dependencies between generic practices and process areas.Wow! eBook <WoweBook.Com>
  • 78. 52 PART ONE ABOUT CMMI FOR DEVELOPMENTFIGURE 3.4Target Profiles and Equivalent StagingName Abbr. ML CL1 CL2 CL3Configuration Management CM 2Measurement and Analysis MA 2Project Monitoring and Control PMC 2Project Planning PP 2Process and Product Quality Assurance PPQA 2Requirements Management REQM 2Supplier Agreement Management SAM 2Decision Analysis and Resolution DAR 3Integrated Project Management IPM 3Organizational Process Definition OPD 3Organizational Process Focus OPF 3Organizational Training OT 3Product Integration PI 3Requirements Development RD 3Risk Management RSKM 3Technical Solution TS 3Validation VAL 3Verification VER 3Organizational Process Performance OPP 4Quantitative Project Management QPM 4Causal Analysis and Resolution CAR 5Organizational Performance Management OPM 5TargetProfile 4TargetProfile 3TargetProfile 2TargetProfile 5• To achieve maturity level 4, all process areas assigned to maturity lev-els 2, 3, and 4 must achieve capability level 3.• To achieve maturity level 5, all process areas must achieve capabilitylevel 3.Achieving High MaturityWhen using the staged representation, you attain high maturitywhen you achieve maturity level 4 or 5. Achieving maturity level 4involves implementing all process areas for maturity levels 2, 3, and4. Likewise, achieving maturity level 5 involves implementing allprocess areas for maturity levels 2, 3, 4, and 5.Wow! eBook <WoweBook.Com>
  • 79. When using the continuous representation, you attain high matu-rity using the equivalent staging concept. High maturity that isequivalent to staged maturity level 4 using equivalent staging isattained when you achieve capability level 3 for all process areasexcept for Organizational Performance Management (OPM) andCausal Analysis and Resolution (CAR). High maturity that is equiva-lent to staged maturity level 5 using equivalent staging is attainedwhen you achieve capability level 3 for all process areas.Using Process Performance Baselines and Process PerformanceModels to Enable Successby Michael Campo, Neal Mackertich, and Peter KrausProcess performance baselines and process performance models areexpected CMMI high maturity (maturity levels 4 and 5) artifactsthat build on the measurement and analysis activities established atCMMI maturity level 2 to lift an organization from a reactive man-agement state to a proactive management state. At maturity level 2,measurements are analyzed and action taken based on trend analy-sis or thresholds being crossed. By contrast, the process perform-ance baselines and models developed using high maturity practicesenable an organization to predict the ability of its processes to per-form in relationship to its business objectives. By aligning processperformance and business objectives, process performance base-lines and models act as facilitators to organizational and projectsuccess. In this essay, we examine the concepts of process perform-ance baselines and models based on our experiences at RaytheonIntegrate Defense Systems (IDS).Before discussing process performance baselines and models,it’s important to understand the concept of “quality and processperformance objectives.” Quality and process performance objec-tives derived from business objectives are used to leverage valuefrom process performance baselines and models. This connectionbetween quality and process performance objectives, baselines, andmodels is key. Without it, baselines and models may still providesome benefit to an organization, but not the systematic optimiza-tion that comes from using the baselines and models as enablingtools to focus process performance on achievement of businessobjectives.Chapter 3 Tying It All Together 53Wow! eBook <WoweBook.Com>
  • 80. 54 PART ONE ABOUT CMMI FOR DEVELOPMENTIn the Measurement and Analysis process area, an organizationand its projects develop a measurement system used to supportmanagement information needs that are derived from organizationaland project objectives. For example, a project with an objective tomeet or beat its customer delivery date has an information need tounderstand its progress toward achieving that milestone. Measuressupporting that information need might include schedule perform-ance, productivity, and size. By collecting and analyzing such mea-sures, the project can react to trends that indicate risk to the deliverydate. These activities align with the Goal Question Metric (GQM)approach developed by Dr. Victor Basili and others from his work withthe United States National Aeronautics and Space Administration.Quality and process performance objectives build on the GQMapproach by explicitly analyzing business, organizational, or projectobjectives and creating quantified “goals” related to processes thatsupport those objectives. These goals become the quality andprocess performance objectives. Quality and process performanceobjectives are typically more strategically aligned than maturitylevel 2 Measurement and Analysis objectives and are developedfrom an understanding of historical process performance data.Often, business and organizational objectives may be expressed innonquantitative terms. For example, “Improve Customer Satisfac-tion” may be a business objective. In such cases, it may be necessaryto derive quality and process performance objectives by askingadditional questions, such as “What does it take to improve cus-tomer satisfaction?” The answer may be meeting cost, schedule, orquality targets from which quantitative quality and process per-formance objectives can be established. Individual projects mayalso establish quality and process performance objectives related totheir specific project context, such as objectives related to award feecriteria.Raytheon IDS has specific business objectives associated withcost and schedule performance. Although many things impact costand schedule performance on a project, drivers from a process per-spective involved improving productivity and reducing rework.Quantitative quality and process performance objectives wereestablished for productivity, defect containment, and defect densityin support of the cost and schedule performance objectives. Processperformance baselines were then created to understand our abilityto achieve the quality and process performance objectives. Histori-cal data related to productivity, defect containment, and defect den-sity was statistically analyzed. Prediction intervals and statisticalWow! eBook <WoweBook.Com>
  • 81. Chapter 3 Tying It All Together 55process control charts were established at both the organizationaland individual project levels. Analysis results graphically depict theprocess performance capability of the organization and its projectsas related to the quality and process performance objectives. Theyrepresent our process performance baselines.Process performance baselines are integral enabling manage-ment tools. Projects maintain their process performance baselinesusing ongoing project data as part of their normal ongoing manage-ment activity. Process performance baselines are compared againstthe quality and project performance objectives. Causal analysis isperformed and corrective action taken when process performancebaselines indicate risk that the quality and process performanceobjectives may not be achieved. In some cases, analysis involvesusing statistical techniques to evaluate lower level measures thatsupport a quality and process performance objective. For example,using statistical techniques to analyze peer review data supportsquality and process performance objectives related to defect con-tainment and defect density. Organizational process performance base-lines are used to maintain quality and process performance objectivesby relating current organizational process performance capability tochanging business objectives.The direct relationship between business objectives and qualityand process performance objectives, and the use of process per-formance baselines to quantitatively manage our progress towardachieving these objectives, focused our organization on the charac-teristics of success. If organizational objectives are subjective (e.g.,“Improve customer satisfaction”), projects may become disengagedwith those objectives. Making process performance baselines andquality and process performance objectives an integral part of proj-ect management clarifies each project’s role in business success. Theprojects become enlisted in a grass-roots effort to help achieve thebusiness objectives. An organization where all individuals recognizetheir role and responsibility for business success is an organizationthat is more likely to achieve success.The versatility of the Goal Question Metric approach furtherenabled our development and deployment of process performancemodels in the form of a Goal Question Model approach. As withprocess performance baselines, all process performance modelefforts initiate through the linkage and alignment with quality andprocess performance objectives derived from business objectives.This approach is absolutely critical to effective process performancemodeling since without this up-front business alignment, there is aWow! eBook <WoweBook.Com>
  • 82. tendency to create elegant models rather than effective models thatsupport business objectives.Organizational leadership engagement is integral to this process.Development of our Systems Lifecycle Analysis Model (SLAM)process performance model was a direct result of a Raytheon IDSEngineering Leadership expressed concern around the productivityand rework risks associated with accelerated concurrent engineer-ing efforts and their impact on downstream cost performance. Thisconcern naturally led to our generation of questions around whatfactors related to our concurrent engineering efforts influence ourachievement of cost performance, and what controllable sub-processes relate to those factors.Of specific interest in the development of the SLAM model wasthe potential statistical relationship between requirements volatilityand the degree of requirements—design overlap with that of down-stream software and hardware development cost performance.Modeling the relationship between potential input factors and proj-ect outcomes involved the use of statistical methods such as regres-sion analysis and Monte Carlo simulation. In the specific case of theSLAM model, a mathematical function of the input factors was rea-sonably well correlated with the output responses using linearregression techniques (with an adjusted r-squared value = 0.65, p =.000). See Figure 3.5. Additionally collected project data fromSLAM piloting and deployment further confirmed the strength ofthis underlying relationship. The regression equation associatedwith this statistical correlation was the building block for our SLAMmodel development efforts.This is a nice point in our Perspective to reflect on the healthyingredients of process performance models developed by the Soft-ware Engineering Institute:• Are statistical, probabilistic, or simulation in nature• Predict interim and/or final project outcomes• Use controllable factors tied to subprocesses to conduct theprediction• Model the variation of factors and understand the predictedrange or variation of the outcomes• Enable “what-if” analysis for project planning, dynamic replan-ning, and problem resolution during project execution• Connect “upstream” activity with “downstream” activity• Enable projects to achieve midcourse corrections to ensureproject success56 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 83. These captured ingredients have served us well in guiding ourprocess performance model development and deployment efforts.The SLAM model leverages the statistical correlation of controllablefactors to an outcome prediction in the form of a regression equa-tion. A user-friendly Excel-based interface was then created usingCrystal Ball (an industry available software package) to model andstatistically generate a cost performance prediction interval usingMonte Carlo simulation. See Figure 3.6.Note that the SLAM model user interface also includes work-sheets containing Crystal Ball download instructions, step-by-stepguidance for projects on Running SLAM, an Interpreting the Resultsguide, and a listing of potential mitigation Strategies based on bestpractices and lessons learned from previous deployment efforts.Information on these worksheets has proven itself to be invaluableChapter 3 Tying It All Together 57FIGURE 3.5Relationship of Hardware/Software Cost Performance and DesignCompletion/Requirements Volatilityf(% Design Complete, System Volatility) vs HW/SW CPILowLow HighHighf(% Design Complete, System Volatility)HW/SWCPIR2= 0.67Adj R2= 0.65FIGURE 3.6SLAM Model User InterfaceWow! eBook <WoweBook.Com>
  • 84. in enabling “what-if” analysis for project planning, dynamic replan-ning, and problem resolution during project execution.Projects with aggressive schedules where hardware and softwaredesign activities begin prior to requirements release can quantifythe associated cost performance risks, determine the requirementsvolatility level that must be maintained to meet the cost perform-ance objectives, and identify the process changes necessary to man-age requirements accordingly. The SLAM model has been effectivelyused by integrated project teams made up of Systems, Software,Hardware, and Quality Engineering during project planning andexecution to predict, manage, and mitigate risk in achieving projectcost objectives. Integrated SLAM project deployment has deliveredsignificant cost and cycle time benefits for our programs and hasbecome an integral part of our risk management and decision-mak-ing processes.The SLAM model has helped projects address real issues regard-ing their ability to meet their cost performance objectives. The suc-cess of SLAM promoted further business investment in the processperformance modeling of the product development lifecycle. Thisinvestment has led to the development of a family of process per-formance models that support Raytheon IDS cost and schedulebusiness objectives.Effective development and deployment of process performancebaselines and models have significantly improved our process align-ment and performance against Raytheon Integrated Defense Sys-tems business and engineering objectives. Resulting efforts in theareas of statistical process management, root cause analysis and cor-rective action, interdependent execution, and statistically-basedrisk assessment have resulted in increased productivity, reducedrework, and improved cost and schedule performance. Return-on-investment analysis pertaining to our Raytheon IDS CMMI highmaturity efforts has indicated a 24:1 return from our process invest-ment. Process performance baselines and models are the spark thatignited these results and fuels our drive for more.58 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 85. CHAPTER 4RELATIONSHIPS AMONG PROCESS AREASIn this chapter we describe the key relationships among process areasto help you see the organization’s view of process improvement andhow process areas depend on the implementation of other processareas.The relationships among multiple process areas, including the infor-mation and artifacts that flow from one process area to another—illustrated by the figures and descriptions in this chapter—help youto see a larger view of process implementation and improvement.Successful process improvement initiatives must be driven by thebusiness objectives of the organization. For example, a commonbusiness objective is to reduce the time it takes to get a product tomarket. The process improvement objective derived from that mightbe to improve the project management processes to ensure on-timedelivery; those improvements rely on best practices in the ProjectPlanning and Project Monitoring and Control process areas.Although we group process areas in this chapter to simplify thediscussion of their relationships, process areas often interact andhave an effect on one another regardless of their group, category, orlevel. For example, the Decision Analysis and Resolution processarea (a Support process area at maturity level 3) contains specificpractices that address the formal evaluation process used in the Tech-nical Solution process area for selecting a technical solution fromalternative solutions.Being aware of the key relationships that exist among CMMIprocess areas will help you apply CMMI in a useful and productiveway. Relationships among process areas are described in more detailin the references of each process area and specifically in the RelatedProcess Areas section of each process area in Part Two. Refer toChapter 2 for more information about references.59Wow! eBook <WoweBook.Com>
  • 86. Process ManagementProcess Management process areas contain the cross-project activi-ties related to defining, planning, deploying, implementing, monitor-ing, controlling, appraising, measuring, and improving processes.The five Process Management process areas in CMMI-DEV are asfollows:• Organizational Process Definition (OPD)• Organizational Process Focus (OPF)• Organizational Performance Management (OPM)• Organizational Process Performance (OPP)• Organizational Training (OT)Basic Process Management Process AreasThe Basic Process Management process areas provide the organizationwith a capability to document and share best practices, organizationalprocess assets, and learning across the organization.Figure 4.1 provides a bird’s-eye view of the interactions amongthe Basic Process Management process areas and with other processarea categories. As illustrated in Figure 4.1, the OrganizationalProcess Focus process area helps the organization to plan, imple-ment, and deploy organizational process improvements based on anunderstanding of the current strengths and weaknesses of the organi-zation’s processes and process assets.Candidate improvements to the organization’s processes areobtained through various sources. These activities include processimprovement proposals, measurement of the processes, lessonslearned in implementing the processes, and results of processappraisal and product evaluation activities.The Organizational Process Definition process area establishesand maintains the organization’s set of standard processes, workenvironment standards, and other assets based on the process needsand objectives of the organization. These other assets includedescriptions of lifecycle models, process tailoring guidelines, andprocess related documentation and data.Projects tailor the organization’s set of standard processes to cre-ate their defined processes. The other assets support tailoring as wellas implementation of the defined processes.Experiences and work products from performing these definedprocesses, including measurement data, process descriptions, process60 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 87. 61FIGURE 4.1Basic Process Management Process AreasResources andcoordinationStandardprocess andother assetsTraining for projects andsupport groups in standardprocess and assetsOrganization’sprocess needsand objectivesStandard process, workenvironment standards,and other assetsOrganization’sbusinessobjectivesTraining needsImprovement information(e.g., lessons learned,data, and artifacts)Process improvement proposals;participation in defining, assessing,and deploying processesOPD = Organizational Process DefinitionOPF = Organizational Process FocusOT = Organizational TrainingSeniorManagementOPF OPDOTProject Management,Support, and Engineeringprocess areas
  • 88. artifacts, and lessons learned, are incorporated as appropriate intothe organization’s set of standard processes and other assets.The Organizational Training process area identifies the strategictraining needs of the organization as well as the tactical trainingneeds that are common across projects and support groups. In partic-ular, training is developed or obtained to develop the skills requiredto perform the organization’s set of standard processes. The maincomponents of training include a managed training developmentprogram, documented plans, staff with appropriate knowledge, andmechanisms for measuring the effectiveness of the training program.Advanced Process Management Process AreasThe Advanced Process Management process areas provide the organ-ization with an improved capability to achieve its quantitative objec-tives for quality and process performance.Figure 4.2 provides a bird’s-eye view of the interactions amongthe Advanced Process Management process areas and with otherprocess area categories. Each of the Advanced Process Managementprocess areas depends on the ability to develop and deploy processesand supporting assets. The Basic Process Management process areasprovide this ability.As illustrated in Figure 4.2, the Organizational Process Perform-ance process area derives quantitative objectives for quality andprocess performance from the organization’s business objectives. Theorganization provides projects and support groups with commonmeasures, process performance baselines, and process performancemodels.These additional organizational assets support composing adefined process that can achieve the project’s quality and process per-formance objectives and support quantitative management. Theorganization analyzes the process performance data collected fromthese defined processes to develop a quantitative understanding ofproduct quality, service quality, and process performance of the orga-nization’s set of standard processes.In Organizational Performance Management, process perform-ance baselines and models are analyzed to understand the organiza-tion’s ability to meet its business objectives and to derive quality andprocess performance objectives. Based on this understanding, theorganization proactively selects and deploys incremental and innova-tive improvements that measurably improve the organization’sperformance.62 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 89. 63FIGURE 4.2Advanced Process Management Process AreasBusiness objectivesPerformancecapabilityQuality and processobjectivesCost and benefitdata from pilotedimprovementsQuality and processmeasures, baselines,performance objectives,and modelsPerformancecapability dataAbility to develop anddeploy standard processesand other assetsImprovementsCommonmeasuresOPM = Organizational Performance ManagementOPP = Organizational Process PerformanceOrganizationSeniorManagementBasicProcess Managementprocess areasProject Management,Support, and Engineeringprocess areasOPPOPM
  • 90. The selection of improvements to deploy is based on a quantita-tive understanding of the likely benefits and predicted costs ofdeploying candidate improvements. The organization can also adjustbusiness objectives and quality and process performance objectivesas appropriate.Project ManagementProject Management process areas cover the project managementactivities related to planning, monitoring, and controlling the project.The seven Project Management process areas in CMMI-DEV areas follows:• Integrated Project Management (IPM)• Project Monitoring and Control (PMC)• Project Planning (PP)• Quantitative Project Management (QPM)• Requirements Management (REQM)• Risk Management (RSKM)• Supplier Agreement Management (SAM)Basic Project Management Process AreasThe Basic Project Management process areas address the activitiesrelated to establishing and maintaining the project plan, establishingand maintaining commitments, monitoring progress against theplan, taking corrective action, and managing supplier agreements.Figure 4.3 provides a bird’s-eye view of the interactions amongthe Basic Project Management process areas and with other processarea categories. As illustrated in Figure 4.3, the Project Planningprocess area includes developing the project plan, involving relevantstakeholders, obtaining commitment to the plan, and maintainingthe plan.Planning begins with requirements that define the product andproject (“What to Build” in Figure 4.3). The project plan covers thevarious project management and development activities performedby the project. The project reviews other plans that affect the projectfrom various relevant stakeholders and establishes commitmentswith those stakeholders for their contributions to the project. Forexample, these plans cover configuration management, verification,and measurement and analysis.64 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 91. 65FIGURE 4.3Basic Project Management Process AreasWhat to buildWhat to doWhatto monitorReplanPlansStatus, issues,and results ofreviews andmonitoringProduct component requirements, technical issues,completed product components, and acceptancereviews and testsProduct and productcomponentrequirementsProduct andproductcomponentrequirementsStatus, issues, and results of process andproduct evaluations, measures, and analysesMeasurement needsCorrective actionSupplieragreementCorrectiveactionCommitmentsPMC = Project Monitoring and ControlPP = Project PlanningREQM = Requirements ManagementSAM = Supplier Agreement ManagementSupplierSAMPPREQMPMCEngineering and Supportprocess areas
  • 92. The Project Monitoring and Control process area contains prac-tices for monitoring and controlling activities and taking correctiveaction. The project plan specifies the frequency of progress reviewsand the measures used to monitor progress. Progress is determinedprimarily by comparing project status to the plan. When the actualstatus deviates significantly from the expected values, correctiveactions are taken as appropriate. These actions can include replan-ning, which requires using Project Planning practices.The Requirements Management process area maintains the require-ments. It describes activities for obtaining and controlling requirementchanges and ensuring that other relevant plans and data are kept cur-rent. It provides traceability of requirements from customer require-ments to product requirements to product component requirements.Requirements Management ensures that changes to requirementsare reflected in project plans, activities, and work products. Thiscycle of changes can affect the Engineering process areas; thus,requirements management is a dynamic and often recursive sequenceof events. The Requirements Management process area is fundamen-tal to a controlled and disciplined engineering process.The Supplier Agreement Management process area addresses theneed of the project to acquire those portions of work that are pro-duced by suppliers. Sources of products that can be used to satisfyproject requirements are proactively identified. The supplier is selected,and a supplier agreement is established to manage the supplier.The supplier’s progress and performance are tracked as specifiedin the supplier agreement, and the supplier agreement is revised asappropriate. Acceptance reviews and tests are conducted on the sup-plier-produced product component.Advanced Project Management Process AreasThe Advanced Project Management process areas address activitiessuch as establishing a defined process that is tailored from the orga-nization’s set of standard processes, establishing the project workenvironment from the organization’s work environment standards,coordinating and collaborating with relevant stakeholders, formingand sustaining teams for the conduct of projects, quantitatively man-aging the project, and managing risk.Figure 4.4 provides a bird’s-eye view of the interactions amongthe Advanced Project Management process areas and with otherprocess area categories. Each Advanced Project Management processarea depends on the ability to plan, monitor, and control the project.The Basic Project Management process areas provide this ability.66 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 93. 67FIGURE 4.4Advanced Project Management Process AreasProcess performance objectives, baselines, and modelsOrganization’s standardprocesses, workenvironment standards,and supporting assetsLessons learned,planning, andperformancedataProject’sdefined processand work environmentCoordination, commitments,and issues to resolveTeams for performing engineeringand support processesStatistical management dataRisk taxonomiesand parameters,risk status, riskmitigation plans,and correctiveactionRisk exposure due tounstable processesQuantitative objectives, subprocesses tostatistically manage, project’s composed,and defined processIdentified risksTeaming rules andguidelinesProduct architecturefor structuring teamsProject’s composed anddefined processesProjectperformancedataProject’sshared visionIPM = Integrated Project ManagementQPM = Quantitative Project ManagementRSKM = Risk ManagementEngineering and Supportprocess areas BasicProject Managementprocess areasProcess Managementprocess areasQPMRSKMIPM
  • 94. The Integrated Project Management process area establishes andmaintains the project’s defined process that is tailored from the orga-nization’s set of standard processes (Organizational Process Defini-tion). The project is managed using the project’s defined process.The project uses and contributes to the organizational processassets, the project’s work environment is established and maintainedfrom the organization’s work environment standards, and teams areestablished using the organization’s rules and guidelines. The proj-ect’s relevant stakeholders coordinate their efforts in a timely mannerthrough the identification, negotiation, and tracking of criticaldependencies and the resolution of coordination issues.Although risk identification and monitoring are covered in theProject Planning and Project Monitoring and Control process areas,the Risk Management process area takes a continuing, forward-lookingapproach to managing risks with activities that include identificationof risk parameters, risk assessments, and risk mitigation.The Quantitative Project Management process area establishesobjectives for quality and process performance, composes a definedprocess that can help achieve those objectives, and quantitativelymanages the project. The project’s quality and process performanceobjectives are based on the objectives established by the organizationand the customer.The project’s defined process is composed using statistical andother quantitative techniques. Such an analysis enables the project topredict whether it will achieve its quality and process performanceobjectives.Based on the prediction, the project can adjust the definedprocess or can negotiate changes to quality and process performanceobjectives. As the project progresses, the performance of selectedsubprocesses is carefully monitored to help evaluate whether theproject is on track to achieving its objectives.EngineeringEngineering process areas cover the development and maintenanceactivities that are shared across engineering disciplines. The Engi-neering process areas were written using general engineering termi-nology so that any technical discipline involved in the productdevelopment process (e.g., software engineering, mechanical engi-neering) can use them for process improvement.The Engineering process areas also integrate the processes associ-ated with different engineering disciplines into a single product68 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 95. development process, supporting a product oriented process improve-ment strategy. Such a strategy targets essential business objectivesrather than specific technical disciplines. This approach to processeseffectively avoids the tendency toward an organizational “stovepipe”mentality.The Engineering process areas apply to the development of anyproduct or service in the development domain (e.g., software prod-ucts, hardware products, services, processes).The five Engineering process areas in CMMI-DEV are as follows:• Product Integration (PI)• Requirements Development (RD)• Technical Solution (TS)• Validation (VAL)• Verification (VER)Figure 4.5 provides a bird’s-eye view of the interactions amongthe six Engineering process areas.The Requirements Development process area identifies customerneeds and translates these needs into product requirements. The setof product requirements is analyzed to produce a high-level concep-tual solution. This set of requirements is then allocated to establishan initial set of product component requirements.Other requirements that help define the product are derived andallocated to product components. This set of product and productcomponent requirements clearly describes the product’s perform-ance, quality attributes, design features, verification requirements,etc., in terms the developer understands and uses.The Requirements Development process area supplies require-ments to the Technical Solution process area, where the requirementsare converted into the product architecture, product componentdesigns, and product components (e.g., by coding, fabrication).Requirements are also supplied to the Product Integration processarea, where product components are combined and interfaces areverified to ensure that they meet the interface requirements suppliedby Requirements Development.The Technical Solution process area develops technical data pack-ages for product components to be used by the Product Integrationor Supplier Agreement Management process area. Alternative solu-tions are examined to select the optimum design based on estab-lished criteria. These criteria can be significantly different acrossChapter 4 Relationships Among Process Areas 69Wow! eBook <WoweBook.Com>
  • 96. 70FIGURE 4.5Engineering Process AreasProduct and productcomponent requirementsCustomer needsRequirements, product components,work products, verification, andvalidation reportsProductcomponentsAlternative solutionsRequirementsProductPI = Product IntegrationRD = Requirements DevelopmentTS = Technical SolutionVAL = ValidationVER = VerificationRequirementsVER VALTS PIRD CustomerProcess Managementprocess areas
  • 97. products, depending on product type, operational environment, per-formance requirements, support requirements, and cost or deliveryschedules. The task of selecting the final solution makes use of thespecific practices in the Decision Analysis and Resolution processarea.The Technical Solution process area relies on the specific prac-tices in the Verification process area to perform design verificationand peer reviews during design and prior to final build.The Verification process area ensures that selected work productsmeet the specified requirements. The Verification process area selectswork products and verification methods that will be used to verifywork products against specified requirements. Verification is gener-ally an incremental process, starting with product component verifi-cation and usually concluding with verification of fully assembledproducts.Verification also addresses peer reviews. Peer reviews are a provenmethod for removing defects early and provide valuable insight intothe work products and product components being developed andmaintained.The Validation process area incrementally validates productsagainst the customer’s needs. Validation can be performed in theoperational environment or in a simulated operational environment.Coordination with the customer on validation requirements is animportant element of this process area.The scope of the Validation process area includes validation ofproducts, product components, selected intermediate work products,and processes. These validated elements can often require reverifica-tion and revalidation. Issues discovered during validation are usuallyresolved in the Requirements Development or Technical Solutionprocess area.The Product Integration process area contains the specific prac-tices associated with generating an integration strategy, integratingproduct components, and delivering the product to the customer.Product Integration uses the specific practices of both Verificationand Validation in implementing the product integration process. Ver-ification practices verify the interfaces and interface requirements ofproduct components prior to product integration. Interface verifica-tion is an essential event in the integration process. During productintegration in the operational environment, the specific practices ofthe Validation process area are used.Chapter 4 Relationships Among Process Areas 71Wow! eBook <WoweBook.Com>
  • 98. 72 PART ONE ABOUT CMMI FOR DEVELOPMENTExpanding Capabilities Across the “Constellations”by Mike PhillipsAs we are finishing the details of the current collection of processareas that span three CMMI constellations, this perspective is myopportunity to encourage “continuous thinking.” My esteemedmentor as we began and then evolved the CMMI Product Suite wasour Chief Architect, Dr. Roger Bate. Roger left us with an amazinglegacy. He imagined that organizations could look at a collection of“process areas” and choose ones they might wish to use to facilitatetheir process improvement journey.Maturity levels for organizations were acceptable, but not asinteresting to him as being able to focus attention on a collection ofprocess areas for business benefit. Small businesses have been thefirst to see the advantage of this approach, as they often find the fullcollection of process areas in any constellation daunting. An SEIreport, “CMMI Roadmaps,” describes some ways to construct thematicapproaches to effective use of process areas from the CMMI forDevelopment constellation. This report can be found on the SEI web-site at http://www.sei.cmu.edu/library/abstracts/reports/08tn010.cfm.As we created the two new constellations, we took care to referback to the predecessor collection of process areas in CMMI forDevelopment. For example, in CMMI for Acquisition, we note thatsome acquisition organizations might need more technical detail inthe requirements development effort than what we provided inAcquisition Requirements Development (ARD), and to “reach back”to CMMI-DEV’s Requirements Development (RD) process area formore assistance.In CMMI for Services, we suggest that the Service SystemDevelopment (SSD) process area is useful when the developmentefforts are relatively limited, but the full engineering process areacategory in CMMI-DEV may be useful if major service systems arebeing created and delivered.Now with three full constellations to use for process improve-ment, many additional “refer to” possibilities exist. With the releaseof the V1.3 Product Suite, we offer the option to declare satisfactionof any of the process areas from the CMMI portfolio. What are someof the more obvious expansions?We have already mentioned two expansions: ARD using RD andSSD expanded to capture RD, TS, PI, VER, and VAL. What aboutWow! eBook <WoweBook.Com>
  • 99. Chapter 4 Relationships Among Process Areas 73situations in which most of the development is done outside theorganization, but final responsibility for effective systems integra-tion remains with your organization? Perhaps a few of the acquisi-tion PAs would be useful beyond SAM. A simple start would be toinvestigate using SSAD and AM as a replacement for SAM to get theadditional detailed help. And ATM might give some good technicalassistance in monitoring the technical progress of the elementsbeing developed by specific partners.As we add the contributions of CMMI-SVC to the mix, severalprocess areas offer more ways to expand. For example, in V1.2 ofCMMI-DEV, we added informative material in Risk Management toaddress beforehand concerns about continuity of operations aftersome significant disruption occurs. Now, with CMMI-SVC, we havea full process area, Service Continuity (SCON), to provide robustcoverage of continuity concerns. (And for those who need evenmore coverage, the SEI now has the Resilience Management Model(RMM) to give the greater attention that some financial institutionsand similar organizations have expressed as necessary for theirprocess improvement endeavors. For more, see http://www.cert.org/resilience/rmm.html.)Another expansion worthy of consideration is to include theService Systems Transition (SST) process area. Organizations thatare responsible for development of new systems—and maintenanceof existing systems until the new system can be brought to fullcapability—may find the practices contained in SST to be a usefulexpansion because the transition part of the product lifecycle haslimited coverage in CMMI-DEV. In addition, CMMI-ACQ addedtwo practices to PP and PMC to address planning for and monitor-ing transition into use, so the CMMI-ACQ versions of these twocore process areas might couple nicely with SST.A topic that challenged the development team for V1.3 wasimproved coverage of “strategy.” Those of us with acquisition expe-rience knew the criticality of an effective acquisition strategy to pro-gram success, so the practice was added to the CMMI-ACQ versionof PP. In the CMMI-SVC constellation, Strategic Service Manage-ment (STSM) has the objective “to get the information needed tomake effective strategic decisions about the set of standard servicesthe organization maintains.” With minor interpretation, this processarea could assist a development organization in determining whattypes of development projects should be in its product developmentline. The SVC constellation authors also added a robust strategy estab-lishment practice in the CMMI-SVC version of PP (Work Planning)Wow! eBook <WoweBook.Com>
  • 100. 74 PART ONE ABOUT CMMI FOR DEVELOPMENTto “provide the business framework for planning and managing thework.”Two process areas essential for service work were seriously con-sidered for insertion into CMMI-DEV V1.3: Capacity and Availabil-ity Management (CAM) and Incident Resolution and Prevention(IRP). In the end, expansion of the CMMI-DEV constellation from22 to 24 process areas was determined to be less valuable than con-tinuing our efforts to streamline coverage. In any case, these twoprocess areas offer another opportunity for the type of expansion Iam exploring in this essay.Those of you who have experienced appraisals have likely seenthe use of target profiles that gather the collection of process areasto be examined. Often these profiles specifically address the neces-sary collections of process areas associated with maturity levels, butthis need not be the case. With the release of V1.3, we have ensuredthat the reporting system (SCAMPI Appraisal System, or SAS) isrobust enough to allow depiction of process areas from multipleCMMI constellations. As use of other architecturally similar SEImodels, such as the RMM mentioned above as well as the PeopleCMM, grow in use, we will be able to depict profiles using mixturesof process areas or even practices from multiple models, givinggreater value to the process improvement efforts of a growing rangeof complex organizations.Recursion and Iteration of Engineering ProcessesMost process standards agree that there are two ways that processescan be applied. These two ways are called recursion and iteration.Recursion occurs when a process is applied to successive levels ofsystem elements within a system structure. The outcomes of oneapplication are used as inputs to the next level in the system struc-ture. For example, the verification process is designed to apply to theentire assembled product, the major product components, and evencomponents of components. How far into the product you apply theverification process depends entirely on the size and complexity ofthe end product.Iteration occurs when processes are repeated at the same systemlevel. New information is created by the implementation of oneprocess that feeds that information back into a related process. Thisnew information typically raises questions that must be resolvedbefore completing the processes.Wow! eBook <WoweBook.Com>
  • 101. For example, iteration will most likely occur between require-ments development and technical solution. Reapplication of theprocesses can resolve the questions that are raised. Iteration canensure quality prior to applying the next process.Engineering processes (e.g., requirements development, verifica-tion) are implemented repeatedly on a product to ensure that theseengineering processes have been adequately addressed before deliv-ery to the customer. Further, engineering processes are applied tocomponents of the product.For example, some questions that are raised by processes associ-ated with the Verification and Validation process areas can beresolved by processes associated with the Requirements Develop-ment or Product Integration process area. Recursion and iteration ofthese processes enable the project to ensure quality in all compo-nents of the product before it is delivered to the customer.The project management process areas can likewise be recursivebecause sometimes projects are nested within projects.Measurement Makes Improvement Meaningfulby David N. CardMeasurement is an essential component of engineering, manage-ment, and process improvement. CMMI defines measurementrequirements in Measurement and Analysis, Project Planning, Proj-ect Monitoring and Control, Quantitative Project Management,Organizational Process Performance, and, to lesser degrees, in otherprocess areas. Measurement and analysis are two of the five steps inthe Six Sigma DMAIC cycle. Lean is based on the application of themathematical principles of queuing theory to processes. Unless per-formance can be quantified in terms of productivity, quality, or cycletime, it is hard to gauge improvement, regardless of the improve-ment approach adopted.An effective measurement and analysis program is essential tothe long-term business success of CMMI users. Measurement is themechanism by which an organization gains insight into its perform-ance and confronts “goodness.” A minimal measurement programmay pass an appraisal but will limit the organization’s opportunitiesfor real improvement. Moreover, without meaningful feedback, amaturity level is not likely to be maintained.Chapter 4 Relationships Among Process Areas 75Wow! eBook <WoweBook.Com>
  • 102. What roles should measurement and analysis play in an organi-zation? Measurement often is defined in terms of collecting dataand thus is distinguished from analysis, the interpretation and useof data. Clearly, the collection of data must be driven by its intendeduse. As Mark Twain observed, “Data is like garbage. You better knowwhat you are going to do with it, before you start collecting it.” Fourclasses (or levels) of measurement users or decision-making processesmay be defined. CMMI introduces these decision-making processes atdifferent maturity levels. Each class of decision-making has a differ-ent focus, as described below:• Enterprise. The long-term survival of the organization. Theenterprise offers products and/or services in a market. Sur-vival typically means maintaining or increasing profitabilityand market share. (Organizational Performance Management,a CMMI maturity level 5 process area.)• Process. The efficiency and effectiveness of the organization’smeans of accomplishing work. The processes of a typicalorganization may include software engineering, informationtechnology, marketing, and administration. (CMMI maturitylevels 4 and 5.)• Project. Realization of a specific product or service for a specificcustomer or class of customers. Projects use organizationalprocesses and resources to produce products and/or services forthe enterprise to market. (CMMI maturity levels 2 and 3.)• Product. Resolution of the technical aspects of the product orservice necessary to meet the customer’s requirements. Proj-ects manage the resources necessary to deliver the desiredproduct or service. (CMMI maturity level 3.)As indicated in the preceding descriptions, these areas of con-cern are inter-related. Moreover, measurement and analysis at all ofthese levels depend on many of the same sources of data. However,the level of detail and the manner in which the data is analyzed orreported for different purposes may vary.1Measurement specialists often focus on the technical challengesof statistical analysis rather than addressing some of the human andsocial reasons why measurement systems sometimes fail. Many of76 PART ONE ABOUT CMMI FOR DEVELOPMENT1. For a more detailed discussion, see D. Card, “A Practical Framework for Software Mea-surement and Analysis,” Auerbach, Systems Management Strategies, October 2000.Wow! eBook <WoweBook.Com>
  • 103. these problems are common to organizational change initiatives.Three issues specific to measurement are as follows:• The cost of data collection and processing is always visible,but the benefits of measurement are not. The benefitsdepend on what decisions are made based on the data. Nodecisions—no action—no benefits. Organizations mustestablish an action orientation.• Measurement and analysis is new to many software and sys-tems engineers and managers. Training and coaching inthese new skills are essential to their successful implementa-tion. As the scope of measurement increases with highermaturity, more sophisticated techniques must be mastered,making training even more critical.• Measurement provides insight into performance. However,gaining and using that insight may be threatening to thosewhose performance is measured, and even to those who arejust the messengers of performance information. Measure-ment systems must protect the participants.All of these issues can, and have been, overcome. CMMI’s Mea-surement and Analysis process area provides a good starting pointfor introducing measurement into an organization. Building on thatwith skills and techniques appropriate to the target maturity leveland intended uses of measurement, as well as confronting thehuman issues that are sure to be encountered, facilitates the transi-tion to management by fact, rather than opinion. Without an appro-priate and effective measurement program, maturity levels areinsignificant assertions.SupportSupport process areas cover the activities that support product devel-opment and maintenance. The Support process areas addressprocesses that are used in the context of performing other processes.In general, the Support process areas address processes that are tar-geted toward the project and can address processes that apply moregenerally to the organization.For example, Process and Product Quality Assurance can be usedwith all the process areas to provide an objective evaluation of theprocesses and work products described in all the process areas.Chapter 4 Relationships Among Process Areas 77Wow! eBook <WoweBook.Com>
  • 104. The five Support process areas in CMMI-DEV are as follows:• Causal Analysis and Resolution (CAR)• Configuration Management (CM)• Decision Analysis and Resolution (DAR)• Measurement and Analysis (MA)• Process and Product Quality Assurance (PPQA)Basic Support Process AreasThe Basic Support process areas address fundamental support func-tions that are used by all process areas. Although all Support processareas rely on the other process areas for input, the Basic Supportprocess areas provide support functions that also help implementseveral generic practices.Figure 4.6 provides a bird’s-eye view of the interactions amongthe Basic Support process areas and with all other process areas.The Measurement and Analysis process area supports all processareas by providing specific practices that guide projects and organiza-tions in aligning measurement needs and objectives with a measure-ment approach that is used to support management information78 PART ONE ABOUT CMMI FOR DEVELOPMENTFIGURE 4.6Basic Support Process AreasMeasurementsand analysesInformationneedsConfigurationitems and changerequests Controlled configuration items,baselines, and audit reportsProcesses andwork products,standards, andproceduresQuality andnoncomplianceissuesCM = Configuration ManagementMA = Measurement and AnalysisPPQA = Process and Product Quality AssuranceMA PPQACMAll processareasWow! eBook <WoweBook.Com>
  • 105. needs. The results can be used in making informed decisions andtaking appropriate corrective actions.The Process and Product Quality Assurance process area supportsall process areas by providing specific practices for objectively evalu-ating performed processes, work products, and services against theapplicable process descriptions, standards, and procedures, andensuring that any issues arising from these reviews are addressed.Process and Product Quality Assurance supports the delivery ofhigh quality products and services by providing the project staff andall levels of management with appropriate visibility into, and feed-back on, the processes and associated work products throughout thelife of the project.The Configuration Management process area supports all processareas by establishing and maintaining the integrity of work productsusing configuration identification, configuration control, configura-tion status accounting, and configuration audits. The work productsplaced under configuration management include the products thatare delivered to the customer, designated internal work products,acquired products, tools, and other items that are used in creatingand describing these work products.Examples of work products that can be placed under configura-tion management include plans, process descriptions, requirements,design data, drawings, product specifications, code, compilers, prod-uct data files, and product technical publications.Advanced Support Process AreasThe Advanced Support process areas provide the projects and organ-ization with an improved support capability. Each of these processareas relies on specific inputs or practices from other process areas.Figure 4.7 provides a bird’s-eye view of the interactions amongthe Advanced Support process areas and with all other process areas.Using the Causal Analysis and Resolution process area, projectmembers identify causes of selected outcomes and take action to pre-vent negative outcomes from occurring in the future or to leveragepositive outcomes. While the project’s defined processes are the ini-tial targets for root cause analysis and action plans, effective processchanges can result in process improvement proposals submitted tothe organization’s set of standard processes.The Decision Analysis and Resolution process area supports allthe process areas by determining which issues should be subjected toa formal evaluation process and then applying a formal evaluationprocess to them.Chapter 4 Relationships Among Process Areas 79Wow! eBook <WoweBook.Com>
  • 106. People, Process, Technology, and CMMIby Gargi KeeniOrganizations that have been successful in their process improve-ment initiatives are known to have taken a holistic approach. Anydiscussion on process improvement would invariably emphasizethe importance of addressing the people, process, and technology(PPT) triad. However, in reality, it is not so common to see synergybetween the individuals or groups responsible for these PPT aspectsin an organization. Synchronizing the goals of an individual or teamwith those of the organization is the key for any successful improve-ment program.In the context of CMMI, this becomes more evident for theprocess areas whose activities would have an inherent conflictbetween individuals/teams priorities and the organization’s priori-80 PART ONE ABOUT CMMI FOR DEVELOPMENTFIGURE 4.7Advanced Support Process AreasDefects, otherproblems, andsuccessesSelectedissuesProcessimprovementproposalsFormalevaluationsDARCARAll process areasCAR = Causal Analysis and ResolutionDAR = Decision Analysis and ResolutionWow! eBook <WoweBook.Com>
  • 107. ties. Organizations may unknowingly amplify this conflict by hav-ing reward and recognition systems in which individual incentivesand career goals are only tied to individual/team performance,thereby inhibiting realization of organizational goals.Let’s take an example of an organization that is trying to imple-ment a Process and Product Quality Assurance (PPQA) process.PPQA is a process area at maturity level 2 whose purpose is to pro-vide objective insight into processes and their associated workproducts.Now consider each component of the PPT triad:• Process. Though it may seem relatively simple to just definethe processes that need to be implemented and with whichprojects are thus expected to comply, that alone is rarely suffi-cient to ensure that the intent for the process will be under-stood or achieved.Possible evidence for this is when individuals/teams workovertime to get records in place just before the compliancecheck is scheduled!• People. Further probing might highlight the fact that anincentive system links the number of noncompliances to theperformance of the project leader or project team. This link-age motivates the individual or team to spend nonvalue-adding effort just to ensure that the number ofnoncompliances is as low as possible.The reason for the noncompliance in the first place couldhave been any of the following:• The processes are not suitable for the activities done bythe individuals/teams.• The process definition is too complicated to be fol-lowed.• The individuals/teams are not aware of the process andits intent.In this case, the organization cannot reap the benefits ofthe PPQA activities (because the team will “fake it” to “getby” the audit) unless it revisits its people practice of linkingthe number of noncompliances to the performance of an indi-vidual or team. In other words, the organization needs to pro-mote an environment that encourages employee participationin identifying and reporting quality issues (which can includeissues with the processes that have been defined as well asnoncompliances), which is subpractice 1 of PPQA SP1.1.Chapter 4 Relationships Among Process Areas 81Wow! eBook <WoweBook.Com>
  • 108. • Technology. To obtain effective and timely conclusions withrespect to the preceding reasons cited for possible noncompli-ance, organizations need to have systems for tracking andanalyzing in near real time the noncompliances and the asso-ciated corrective actions. This tracking and analysis, in turn,will provide managers at all levels with appropriate visibilityinto the processes and work products. However, just procur-ing a tool for managing noncompliances without properdeployment of processes turns out to be counterproductive inmost cases.Here’s what needs to be realized in the situation just described:Objectivity in PPQA evaluations is critical and can be achieved byboth independence and the use of criteria; however, the credibilityand motivation of the independent entity has a major impact on thequality of PPQA evaluations. In organizations where individualsfrom other teams conduct the PPQA activities, it is very importantto ensure that the right individual is made available for the task.However, as experience says, the right people are usually not avail-able unless the right motivation is provided. If individuals arealways evaluated based on the work they do for their team, there isno motivation for them to provide any service external to the team.However, PPQA being a Support PA that runs across the organiza-tion, the organization needs to review its incentive measures to pro-vide the right motivation for these activities which are beyond theindividuals’/teams’ current functions and performance. Incentivesthat are more fully aligned with organizational objectives will moti-vate early identification of noncompliances, which in turn will helpidentify possible problem areas in the processes that the organiza-tion is trying to deploy.As you can see by the PPQA example, it is important to con-sider all three dimensions of people, process, and technology whenaddressing any of the activities described in the process areas inCMMI. The PPT impact becomes even more apparent for PAs athigher maturity levels, which have inherently built-in organiza-tional perspectives irrespective of whether it is a large or smallorganization.It is essential for an organization to provide an environmentthat fosters effective deployment of processes. Analysis of the out-come/results on a regular basis provides insights into the effective-ness of the processes and the changes required to meet businessobjectives.82 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 109. The PAs at higher maturity levels often directly address peopleand technology in the practices. However, when implementingthese practices, it is important to understand the natural relation-ships that exist to nurture these behaviors so that an organizationcan readily adapt to improvement and change, which is necessary intoday’s environment.Chapter 4 Relationships Among Process Areas 83Wow! eBook <WoweBook.Com>
  • 110. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 111. CHAPTER 5USING CMMI MODELSThe complexity of products today demands an integrated view ofhow organizations do business. CMMI can reduce the cost of processimprovement across enterprises that depend on multiple functions orgroups to achieve their objectives.To achieve this integrated view, the CMMI Framework includescommon terminology, common model components, commonappraisal methods, and common training materials. This chapterdescribes how organizations can use the CMMI Product Suite notonly to improve their quality, reduce their costs, and optimize theirschedules, but also to gauge how well their process improvementprogram is working.The Role of Process Standards in Process Definition†by James W. MooreSuppose you decide to take a physics course at a university. Natu-rally, you want to get a good grade. You faithfully attend the lec-tures, read the textbooks, attend the lab sessions, do the homework,take the final examination, and hope for the best outcome. Alterna-tively, if you can find a willing instructor, you could ask the instruc-tor for a copy of the final exam on the first day of the course. Astime permits, you could figure out the answers to the questionsand, by the end of the course, turn in your answers to the exam85† © 2010 The MITRE Corporation. All rights reserved.[The author’s affiliation with The MITRE Corporation is provided for identification purposesonly, and is not intended to convey or imply MITRE’s concurrence with, or support for, thepositions, opinions or viewpoints expressed by the author.]Wow! eBook <WoweBook.Com>
  • 112. questions with a request for the corresponding grade. Which ofthese two approaches is the more effective way to learn physics?We’ll return to this question at the end of this article.There is a long tradition of prescriptive process definition stan-dards, like DoD-Std-2167A, that were intended to tell the softwaredevelopers what they must do to achieve an acceptable level of pro-fessional practice; one conformed to such a standard by implement-ing processes meeting all of its provisions.1 In the last dozen or soyears, that binary form of pass-fail evaluation has lost favor to amore graded approach of assessing the “maturity” or “capability” ofthe developer’s processes. ISO/IEC 15504, Process Assessment(commonly called SPICE), describes this approach. ISO/IEC 15504is “agnostic” with respect to the processes being employed. Meth-ods conforming to the standard can be used to assess to any set ofprocesses that are described in a particular stylized manner, calledthe process reference model. One such process reference model isprovided by ISO/IEC/IEEE 12207, Software Lifecycle Processes.Another is provided by ISO/IEC/IEEE 15288, System LifecycleProcesses.The 15504 standard is used in some nations, but CMMI mayhave greater recognition in others, especially the U.S. marketplace.Unlike 15504, CMMI provides a great deal of guidance regardingthe definition of processes. The criteria that are applied to assess theprocesses implicitly specify practices that should be embedded inthe developer’s processes. So this begs the question of whether anyother standards are needed for process definition. After all, why notsimply implement processes meeting the CMMI criteria and bedone with it?There are four reasons why one should consider using processstandards for defining an organization’s processes: scope, suitability,communication, and robustness.First, let’s look at scope. Although CMMI is broad, it isn’t broadenough for all possible uses. An obvious example is quality man-agement. Although CMMI includes provisions addressing the qual-ity of software products and systems, it does not address theorganization-level quality management systems specified by ISO9001, Quality management systems—Requirements. Because ISO86 PART ONE ABOUT CMMI FOR DEVELOPMENT1. Because they were generally over prescriptive, these standards were often “tailored” bymodifying their detailed provisions. Of course, conformance to a tailored standard alwaysbegs the question of whether the tailoring was done responsibly, or simply consisted ofdeleting all inconvenient provisions.Wow! eBook <WoweBook.Com>
  • 113. 9001 conformance is regarded as highly important in many coun-tries, multinational suppliers will find it appropriate to considerthat standard in defining their processes—even software and systemprocesses—related to quality. Although less prominent than ISO9001, there are many other standards describing processes of vari-ous kinds. In particular situations, suppliers should consider theprovisions of those standards.The second reason for considering process standards is suitabil-ity. It should be obvious that not every organization needs the sameset of processes. After all, every organization has some unique char-acteristics that cause it to differ from its competitors. That competi-tive advantage should be addressed in organizational processes sothat the advantage is relevantly applied to every project of theorganization—maintaining its competitive edge. Defining a set oforganizational processes (e.g., for software and systems engineer-ing) should consider a number of factors, including:• Size of the organization• The nature of the products and services provided by theorganization• The competitive structure of the relevant marketplace• The nature of the competition• The regulatory structure that is relevant, including regulatoryrequirements• Customs, traditions, and regulation in the relevant industrysector• The “culture” of the organization, including the degree of reg-imentation that the workforce will tolerate• Organizational attitudes toward quality• The amount of investment capital available for process defini-tion and the extent to which it can be amortized over a baseof projects• The uniformity (or diversity) of anticipated projectrequirements• The competitive advantages to be “captured” by the processes• The form in which documentation (either paper or elec-tronic) is to be captured, saved, and possibly deliveredAll of these considerations, and many more, affect the defini-tion of organizational processes, leading to the conclusion that theChapter 5 Using CMMI Models 87Wow! eBook <WoweBook.Com>
  • 114. selection and implementation of cost-effective processes requires adifferent solution for every organization.Of course, available process standards do not directly accountfor all of these factors. They simply provide alternatives to be con-sidered in the overall process definition. In some cases, theydescribe specific practices that are important in regulatory environ-ments—for example, the Modified Condition Decision Criteria (ofRTCA DO-178B, Software Considerations in Airborne Systems andEquipment Certification) that is applied to the testing of avionicssystems. More generally, they provide a starting point, a shortcutthat allows the process definers to avoid a large volume of relativelystraightforward decisions. Perhaps most importantly, they record abaseline of responsible practice, a “safety net,” that is overlookedonly at some risk.The third reason for considering process standards is communi-cation. Terminology in software engineering is notoriously vagueand flexible—a sign of an emerging profession. This can lead toimportant misunderstandings: “Oh, when you paid me to ‘imple-ment’ the software, you meant I should ‘test’ it also? I didn’t includethat in the price; you have to pay me extra for that!” Even the con-sideration of proposals is difficult without a baseline of terminologyfor comparing processes.Suppose the buyer asks the supplier what sort of design reviewpractices are performed by the supplier. One possible answer is toprovide dozens of pages of proposal prose; another possible answeris for the supplier to say, “We use IEEE Std 1028, SoftwareReviews.” The second answer has the advantage of being succinct,of being precise in terms of what is included, and of being generallyaccepted as responsible practice.2The international standards forlifecycle processes, ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288,provide a comprehensive set of processes that span the lifecycles ofsoftware products and systems.If a supplier states that its software development process con-forms to that of 12207, a buyer knows the answer to a large numberof pertinent questions. To pick only one example, the buyer wouldknow that the software requirements, the architectural design, thedetailed design, and the code will all be evaluated for feasibility ofoperation and maintenance—important downstream activities.88 PART ONE ABOUT CMMI FOR DEVELOPMENT2. By the way, I avoid the term best practice. Responsible practice is as good as it gets with me.I simply don’t believe that any single practice can be regarded as being the best in all possi-ble situations. I believe that most organizations should strive to use responsible practicesthat are suited to their particular needs. —James W. MooreWow! eBook <WoweBook.Com>
  • 115. The final reason for considering process standards is robust-ness. Reliance on a single source may lead to defining processes thatare inadvertently oriented toward a particular concept of usage.Applying the processes in a different context may lead to unin-tended results. Despite best attempts at generality, it is impossible toanticipate all possible situations; so it is up to the process designerto consult multiple sources to find processes that are suitable forthe particular organization.The level of prescription is an important consideration here.Those who define processes (including the people who wroteCMMI) necessarily have to make a trade-off of generality versusspecificity. Many very good practices were omitted from CMMIbecause they weren’t generally applicable; and many were “watereddown” to improve their generality. By consulting multiple sources,including multiple standards, process definers will find practicesthat are specifically suitable and effective in the intended contexteven though they were omitted from CMMI because they could notbe generalized to the broad CMMI audience. Those who must practiceat a more demanding level—e.g., developing safety-critical soft-ware—can supplement their baseline processes by applying stan-dards that provide more detailed or stringent treatments of selectedpractices, e.g., IEEE Std 1012, Software Verification and Validation.We are now ready to return to the original question of whethera person who wants to learn physics should sit through the courseor ask for a copy of the final exam on the first day. The answer tothe question: “It depends!” It depends on whether the goal is togain a broad and useful understanding of physics or to get the high-est possible grade with the least possible effort. In business, bothanswers are reasonable ones depending on the circumstances.Applying this analogy to the subject at hand, we can conclude(with some cynicism) that if the organization’s goal is to attain thehighest possible CMMI rating with the smallest possible invest-ment, it is probably appropriate to accept the final exam on the firstday of the course—that is, to define a set of organizationalprocesses that directly and straightforwardly address the evaluationcriteria of CMMI. On the other hand, if the organization’s goal is todefine a set of organizational processes that are robust, descriptive,and suitable to the scope and circumstances of the organization—that is, to gain the intended advantages of process improvement—the organization should consult multiple sources, including processdefinition standards, select suitable ones, and use them as a baselinefor defining a cost-effective solution to the organization’s needs.Chapter 5 Using CMMI Models 89Wow! eBook <WoweBook.Com>
  • 116. Adopting CMMIResearch has shown that the most powerful initial step to processimprovement is to build organizational support through strong sen-ior management sponsorship. To gain the sponsorship of senior man-agement, it is often beneficial to expose them to the performanceresults experienced by others who have used CMMI to improve theirprocesses [Gibson 2006].For more information about CMMI performance results, see theSEI website at http://www.sei.cmu.edu/cmmi/research/results/.The senior manager, once committed as the process improvementsponsor, must be actively involved in the CMMI-based processimprovement effort. Activities performed by the senior managementsponsor include but are not limited to the following:• Influence the organization to adopt CMMI• Choose the best people to manage the process improvement effort• Monitor the process improvement effort personally• Be a visible advocate and spokesperson for the process improvementeffort• Ensure that adequate resources are available to enable the processimprovement effort to be successfulGiven sufficient senior management sponsorship, the next step isestablishing a strong, technically competent process group that rep-resents relevant stakeholders to guide process improvement efforts[Ahern 2008, Dymond 2005].For an organization with a mission to develop software-intensivesystems, the process group might include those who represent differ-ent disciplines across the organization and other selected membersbased on the business needs driving improvement. For example, asystems administrator may focus on information technology support,whereas a marketing representative may focus on integrating cus-tomers’ needs. Both members could make powerful contributions tothe process group.Once your organization decides to adopt CMMI, planning canbegin with an improvement approach such as the IDEAL (Initiating,Diagnosing, Establishing, Acting, and Learning) model [McFeeley1996]. For more information about the IDEAL model, see the SEI Web-site at http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm.90 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 117. Executive Responsibilities in Process Improvementby Bill CurtisWe constantly hear that the primary reason process improvementprograms fail is from lack of executive leadership. That said, thoseresponsible for facilitating process improvement programs are hard-pressed to specify exactly what they expect from executives. Hereare 12 critical actions executives should take to ensure the successof process improvement programs.1. Take personal responsibility. Executives do not deliver systemsto customers. Project managers deliver them. Executives buildorganizations that deliver systems to customers, and this respon-sibility cannot be delegated. At the core of Watts Humphrey’sProcess Maturity Framework that underlies CMMI is a uniquemodel of organizational change and development. Because theresponsibility for organizational transformation rests in theexecutive office, CMMI is a tool for executives to use inimproving the performance of their organizations. CMMI willnot only transform development practices, but also the organi-zation’s culture and the way business results are attained. Exec-utives should not launch an improvement program until theyare willing to become personally accountable for its success—or failure.2. Set realistic goals. Executives must initiate process improve-ment with a clear statement of the issues driving change andthe objectives to be achieved. Slogans such as “Level 2 in 2years” do little more than reinforce the very behaviors thatLevel 2 was designed to eliminate. If the improvement objec-tives are unrealistic, the improvement program will be just onemore of the organization’s chaotic death march projects.Process improvement programs must model the behaviors thatexecutives want the organization to adopt, especially plan-driven commitments. Schedules for attaining maturity levelsshould result from planning, not catchy slogans or bonuscycles. Rewards and bonuses should be based on accomplish-ing planned behavioral or performance improvements, ratherthan arbitrary dates for appraisal results.3. Establish an improvement project. Process improvement mustbe conducted as a project. Executives must assign responsibil-ity for managing the project, provide funding and resources,Chapter 5 Using CMMI Models 91Wow! eBook <WoweBook.Com>
  • 118. 92 PART ONE ABOUT CMMI FOR DEVELOPMENTapprove improvement plans, review status reports, and mea-sure results. The person assigned to lead the improvementproject must be a strong role model for other project managers.Executives should ask frequent questions about project plansand the assumptions underlying them. The guidebooks,defined processes, measures, checklists, and other artifacts pro-duced through process improvement are organizational assets.They should be treated as products, albeit for internal use, andbe produced with the same project discipline used in produc-ing any other product.4. Manage change. How many initiatives can dance on the head ofa project manager? Many organizations have multiple improve-ment programs underway simultaneously. In the initial stagesof these programs, project managers are the people mostaffected and are often inundated with the number of changesexpected. Executives must determine the amount of change theorganization can absorb, prioritize the changes to be made, andshield the organization from improvement overkill. The goodnews is that some improvement programs such as Six Sigmaand CMMI can be synergized, since they both evolved from theconcepts initiated by Shewhart and Deming.5. Align management. Process groups have no power to enforceimprovements or change management behavior. If middle man-agers resist improvements, only executives can force them toalign with the program. Executives must build consensusamong managers on the objectives and tactics for improvementand hold them accountable for achieving improvement objec-tives. In particular, middle managers must develop the skills ofthe project or program managers who report to them. Manage-ment steering committees reporting to executives are one wayto ensure middle and project managers share responsibility forimprovement success.6. Align incentives. Executives must ensure that incentives arealigned with improvement goals and do not send mixed mes-sages about the behaviors the organization values. Incentivesmust shift from rewarding heroes to rewarding those whosesound practices avoid the need for heroes. Promotions shouldgo to those who are strong role models of the behaviors theimprovement program is trying to instill. Incentives must senda message that management values contributions to buildinga strong organization just as much as it values individualvirtuosity.Wow! eBook <WoweBook.Com>
  • 119. Chapter 5 Using CMMI Models 937. Establish policies and empower assurance. Policies that merelyregurgitate goals from CMMI process areas represent a lostopportunity for executives to communicate their expectationsfor behavior in their organizations. After policies are estab-lished, executives need visibility into compliance. Assurancegroups have influence only to the extent that executivesenforce policies and address noncompliance. However, thegreatest value of assurance groups, and this is subtle in PPQA,is when they serve as mentors to project managers and techni-cal staff on practices that support compliance. Consequently,assurance groups need to be staffed with competent developersand managers so that they are credible in transferring knowl-edge of best practices across the organization.8. Involve customers. Unless customers understand how they willbenefit from new practices, they may perceive the changes asmaking projects bureaucratic and inflexible. Consequently,project managers are often trapped in a conflict between theirimprovement objectives and the demands of their customers.Executives own the relationship with customers and must meetwith their peers to explain the improvement strategy and howit will make the development organization a more reliable busi-ness partner. Involving customers in improving requirementspractices is a good initial step for engaging them in theimprovement program.9. Involve developers. The Process Maturity Framework beginsthe empowerment of developers by involving them in estimat-ing and planning at Level 2 and it increases their responsibilityat each subsequent level. Executives must understand andencourage this cultural transition. They must also ensure thatdevelopers are involved in improvement activities becausedevelopers have the freshest knowledge of best practices. Devel-opers are also more realistic about how much change they canabsorb in an improvement cycle. The role of the process assur-ance groups is to assist managers and developers in identifyingand deploying best practices.10. Review status. Executives own the organization’s commit-ments. They must approve external commitments and reviewprogress in accomplishing them. Project reviews should notonly focus on work status, but also on the progress being madein adopting improvements and of impending risks. Executiveshighlight their commitment through measurement and shouldadd indicators of improvement progress and results to theirWow! eBook <WoweBook.Com>
  • 120. 94 PART ONE ABOUT CMMI FOR DEVELOPMENTdashboards. Improvement measures should reflect that benefitsaccrue project by project, rather than in one big bang.11. Replace laggards. The process group owns responsibility forassisting improvements with the innovators, early adopters,and early and late majority. Executives own the problem of lag-gards, especially if they are in management. For an improve-ment program to succeed, executives must be willing toremove even friends for failure to make progress. Successfulorganizational change programs often end up with differentmanagement teams than they started with.12. Never relent. True leadership begins under stress. With all thepressures generated by demanding business schedules and costcutting, executives must nevertheless stand firm in driving theimprovements they know the organization must make. If theyrelent under pressure, the organization learns the art ofexcuses. The ultimate appraisal of maturity is determined bywhich practices the organization refuses to sacrifice undergrinding pressure.There are other responsibilities executives can assume in sup-porting process improvement. Nevertheless, these 12 have provencritical since they require executive authority and represent acts ofleadership around which the improvement program can galvanize.Executives with little experience in process-disciplined environ-ments are understandably concerned about risking their career onpractices that have not contributed significantly in their advance-ment. Fortunately, there is a growing body of data and communityof mature organizations to attest that faith in sensible CMMI-basedimprovement programs is well placed. It does not take leadership tofollow the trodden path. It takes leadership to pursue the promiseof new ways.Your Process Improvement ProgramUse the CMMI Product Suite to help establish your organization’sprocess improvement program. Using the product suite for this pur-pose can be a relatively informal process that involves understandingand applying CMMI best practices to your organization. Or, it can bea formal process that involves extensive training, creation of aprocess improvement infrastructure, appraisals, and more.Wow! eBook <WoweBook.Com>
  • 121. Implementing Engineering Culture for Successful ProcessImprovementby Tomoo MatsubaraAs most early software professionals, I came from another profes-sional area: mechanical engineering. While I worked at Hitachi’smachine factory, which manufactured cranes, pumps, and bulldoz-ers, the factory was in the midst of the Kaizen (i.e., improvement)movement that reduced direct and indirect costs and improvedquality. Because the factory was an engineering community, all ofthe improvement activities were done in an engineering way. Engi-neers are very practical and don’t decide anything without seeing,touching, and measuring things.The typical problem-solving process used in this environmentwas to (1) identify problems at the factory floor or in front of realthings and phenomena, (2) discuss presumable causes, and (3) con-duct experiments and build prototypes.For mechanical engineers, conducting experiments, measuringthings, and drawing charts are a way of life. In this environment, tounderstand a problem and to observe the progress of improvement,they produced a lot of charts. For efficient and precise fabrication,they developed and applied jigs (i.e., tools used to create specificshapes) and then used small tools for specific fabrication. In somecases, a component with a complex shape, such as convolutedbeams for a monorail, were impossible to fabricate without well-designed jigs.The culture of the factory was very exciting. Designers andworkers were friendly and interacted well together. Once a month,there were sports and cultural events such as a lunchtime (onehour) marathon, boat races, and musical concerts. Twice a year,there were safety-work related competitive games such as measur-ing distances, heights, and weights without using gauges, scales, orother measuring devices. Most of the games involved competitionamong divisions including design, fabrication, and raw materials(i.e., casting and welding). They were like the “constructive disorders”that Tom DeMarco and Tim Lister wrote about in “Peopleware.”3Chapter 5 Using CMMI Models 953. Tom DeMarco and Timothy Lister, “Peopleware: Productive Projects and Teams,” DorsetHouse, 1999.Wow! eBook <WoweBook.Com>
  • 122. 96 PART ONE ABOUT CMMI FOR DEVELOPMENTAfter nine years at the machine factory, I moved to a computerfactory in 1965. As the general manager of the development organi-zation, I was responsible for developing a banking system. Thedevelopment organization consisted of hardware makers, softwaredevelopers, and service providers. I had to anticipate all the risksinvolved in such a development. One of the biggest potential prob-lems I saw was meeting the systems’ high-performance requirements.To begin meeting these requirements, I provided a scheme thatconsisted of a series of dynamic steps. These steps were allocated toeach of the development groups to use, and measures associatedwith each of these steps were defined. I performed a drastic triageon the requirements to meet time constraints. In the final stage ofdevelopment, I had to deal with troubleshooting problems createdas the result of being saddled with components developed by differ-ent organizations. The system was successfully delivered in 1969.While I was in charge, I had to determine the causes of prob-lems that occurred among these intricately interacting componentsand prioritize action items to address them. I learned much aboutsystem engineering and other fields of engineering from this taskand other real-world experiences and thus became acquainted witha large number of talented individuals having differing expertise.After a short stint working with banking systems management,I moved again to a software organization called the “software fac-tory” in 1966 immediately after it was formed. It was named byHitachi’s then-CEO Mr. Komai since his philosophy was that soft-ware should be treated the same as other industrial products. WhenI started working at the software factory, it was a culture shock.Everything seemed to be different from the way the machine factoryworked or the computer factory worked. I found no experiment-related approach to problem solving, and, in turn, there was mini-mal use of measurement, numbers, and charts. Designers boldlyadopted new ideas and made decisions without using any experi-ments. Tools are rarely used. What most impressed me was thatthey didn’t boast about their products and systems that theydesigned and developed.When Hitachi created its software subsidiary, Hitachi SoftwareEngineering (HSE), in 1970, I was asked to join and plan for itsoperation. It was just two years later that the term software engi-neering was coined as a new engineering field at a NATO confer-ence. At that time, HSE initiated its software development withabout 200 programmers who had been working at the software fac-Wow! eBook <WoweBook.Com>
  • 123. tory. These programmers were scattered on multiple projects inmanpower contracts with Hitachi. Because nobody had projectmanagement skills and experience, “death march” projects wererampant. Top management worried about the company’s survival.While we were coping with these incessant problems, we were spec-ulating how to eliminate root causes of problems. Eventually, thecompany improved its practices enough to deserve to call what itwas doing “software engineering.”It was obvious that we needed to train project managers andengineers to give them the power to detect, control, and resolveproblems. To do this, management (including me) tried to create aculture of self-reliance, engineering attitude, and systematic think-ing. The first thing we did was to better align the people. We gath-ered the people who were scattered onto various projects andgrouped them into teams that were headed by fledgling HSE projectmanagers. Then, I provided these project managers with three typesof charts for them to use and trained them how to plot current sta-tus of the project on the charts weekly. This approach allowed us tosee the project’s status and its deviation from target curves forschedule, quality, and cost from a controllability point of view (youcan see some of these charts in Tom DeMarco’s classic book,4 Con-trolling Software Projects, and our papers5). This idea is based on mybelief that most people spontaneously act to take control if he orshe realizes the situation. We trained the project managers not onlyhow to plot status on the charts, but also what typically is going onin the project when specific curve patterns appeared. This strategyalso succeeded and within a few years we achieved profitable, punc-tual, and higher quality projects.Besides these charts, I introduced a lot of mechanisms and sys-tems to help attack problems. I introduced a tool proposal system,borrowed from the idea of applying jigs that I mentioned earlier. Wealso introduced war game competitions on coding within the soft-ware factory. The primary principles behind these ideas are verysimple: First, we observed real processes in real projects (i.e., don’tdecide anything without observation). Second, take an engineeringChapter 5 Using CMMI Models 974. Tom DeMarco, “Controlling Software Projects, Management, Measurement & Estima-tion,” Yourdon Inc., 1982.5. D. Tajima and T. Matsubara, “The Computer Software Industry in Japan,” IEEE Computer,Vol. 14, no. 5 (May 1981), pp. 89–96.Wow! eBook <WoweBook.Com>
  • 124. 98 PART ONE ABOUT CMMI FOR DEVELOPMENTattitude to deal with any and all phenomena. Finally, think system-atically and build-in feedback mechanisms to lead to steady and sta-ble improvement (i.e., all the principles that I experienced at themachine and computer factories). About 30 years after HSE wascreated, its five divisions achieved CMMI maturity level 3 in 2002and 2003, and one of them achieved maturity level 5 in 2004. It wasone of the earliest such achievements in the world.Software process is based on software engineering, which is abranch of engineering. However, when I visited some softwareorganizations, I used to be surprised that they lacked engineeringexpertise as part of software engineering to deal with problems.Developing software requires a complex system in which humanbeings are critical elements. Consequently, I believe that we mustimplement appropriate mechanisms for continuous improvement.Currently, many organizations are coping with integratedprocess improvement that includes the development of software,hardware, and other related work. To streamline integrated processimprovement, an engineering attitude and system-level thinking arecommon and critical keys.Selections that Influence Your ProgramYou must make three selections to apply CMMI to your organizationfor process improvement:1. Select a part of the organization.2. Select a model.3. Select a representation.Selecting the projects to be involved in your process improvementprogram is critical. If you select a group that is too large, it may betoo much for the initial improvement effort. The selection shouldalso consider organizational, product, and work homogeneity (i.e.,whether the group’s members all are experts in the same discipline,whether they all work on the same product or business line, and so on).Selecting an appropriate model is also essential to a successfulprocess improvement program. The CMMI-DEV model focuses onactivities for developing quality products and services. The CMMI-ACQ model focuses on activities for initiating and managing theacquisition of products and services. The CMMI-SVC model focuseson activities for providing quality services to the customer and endWow! eBook <WoweBook.Com>
  • 125. users. When selecting a model, appropriate consideration should begiven to the primary focus of the organization and projects, as well asto the processes necessary to satisfy business objectives. The lifecycleprocesses (e.g., conception, design, manufacture, deployment, opera-tions, maintenance, disposal) on which an organization concentratesshould also be considered when selecting an appropriate model.Select the representation (capability or maturity levels) that fitsyour concept of process improvement. Regardless of which youchoose, you can select nearly any process area or group of processareas to guide improvement, although dependencies among processareas should be considered when making such a selection.As process improvement plans and activities progress, otherimportant selections must be made, including whether to use anappraisal, which appraisal method should be used, which projectsshould be appraised, how training for staff should be secured, andwhich staff members should be trained.CMMI ModelsCMMI models describe best practices that organizations have foundto be productive and useful to achieving their business objectives.Regardless of your organization, you must use professional judgmentwhen interpreting CMMI best practices for your situation, needs, andbusiness objectives.This use of judgment is reinforced when you see words such as“adequate,” “appropriate,” or “as needed” in a goal or practice. Thesewords are used for activities that may not be equally relevant in allsituations. Interpret these goals and practices in ways that work foryour organization.Although process areas depict the characteristics of an organiza-tion committed to process improvement, you must interpret theprocess areas using an in-depth knowledge of CMMI, your organiza-tion, the business environment, and the specific circumstancesinvolved.As you begin using a CMMI model to improve your organization’sprocesses, map your real world processes to CMMI process areas.This mapping enables you to initially judge and later track your orga-nization’s level of conformance to the CMMI model you are usingand to identify opportunities for improvement.To interpret practices, it is important to consider the overall con-text in which these practices are used and to determine how well thepractices satisfy the goals of a process area in that context. CMMIChapter 5 Using CMMI Models 99Wow! eBook <WoweBook.Com>
  • 126. 100 PART ONE ABOUT CMMI FOR DEVELOPMENTmodels do not prescribe nor imply processes that are right for anyorganization or project. Instead, CMMI describes minimal criterianecessary to plan and implement processes selected by the organiza-tion for improvement based on business objectives.CMMI practices purposely use nonspecific phrases such as “rele-vant stakeholders,” “as appropriate,” and “as necessary” to accom-modate the needs of different organizations and projects. The specificneeds of a project can also differ at various points in its life.Interpreting CMMI When Using Agile ApproachesCMMI practices are designed to provide value across a range of dif-ferent situations and thus are stated in general terms. Because CMMIdoes not endorse any particular approach to development, little infor-mation that is approach-specific is provided. Therefore, those whodon’t have prior experience implementing CMMI in situations simi-lar to the one they are now in may find interpretation non-intuitive.To help those who use Agile methods to interpret CMMI practicesin their environments, notes have been added to selected processareas. These notes are added, usually in the introductory notes, tothe following process areas in CMMI-DEV: CM, PI, PMC, PP, PPQA,RD, REQM, RSKM, TS, and VER.All of the notes begin with the words, “In Agile environments”and are in example boxes to help you to easily recognize them andremind you that these notes are examples of how to interpret prac-tices and therefore are neither necessary nor sufficient for imple-menting the process area.Multiple Agile approaches exist. The phrases “Agile environ-ment” and “Agile method” are shorthand for any development ormanagement approach that adheres to the Manifesto for Agile Devel-opment [Beck 2001].Such approaches are characterized by the following:• Direct involvement of the customer in product development• Use of multiple development iterations to learn about and evolve theproduct• Customer willingness to share in the responsibility for decisions andriskMany development and management approaches can share one ormore of these characteristics and yet not be called “Agile.” For exam-ple, some teams are arguably “Agile” even though the term Agile isWow! eBook <WoweBook.Com>
  • 127. not used. Even if you are not using an Agile approach, you might stillfind value in these notes.Be cautious when using these notes. Your ultimate interpretationof the process area should fit the specifics of your situation, includ-ing your organization’s business, project, work group, or team objec-tives, while fully meeting a CMMI process area’s goals and practices.As mentioned earlier, the notes should be taken as examples and areneither necessary nor sufficient to implementing the process area.Some general background and motivation for the guidance givenon Agile development approaches are found in the SEI technical noteCMMI or Agile: Why Not Embrace Both! [Glazer 2008].Process Improvement in a Small Companyby Khaled El EmamIn this brief perspective, I will describe how a small companyimplemented maturity level 2 and 3 processes of a CMMI Stagedmodel. In this case, both the organization (30 staff members) andthe organizational unit developing software (a 10-member softwaredevelopment group and a five-member quality assurance group)were small.ContextTrialStat Corporation develops software used in clinical trials ofdrug development. A number of FDA regulations apply to both thesoftware and the processes used to develop and maintain that soft-ware. Because the software is used to collect and store sensitive per-sonal health information, the security of the application is criticaland is usually included in the scope of regulatory audits.Implementing an Iterative ProcessBecause of competitive pressures, the release cycle for the applica-tion had to be short. A decision was made to adopt an Agilemethodology, which promised rapid releases—a release cycle last-ing three weeks or less.At the outset, the three-week release cycle created many prob-lems and resulted in rapid burnout of the development team. Thecompany was at risk of losing key developers, who were unwillingto work overtime and weekends to maintain the rapid release cycle.The short cycle also required curtailing many requirements analysisChapter 5 Using CMMI Models 101Wow! eBook <WoweBook.Com>
  • 128. 102 PART ONE ABOUT CMMI FOR DEVELOPMENTactivities and minimizing quality assurance of the product—both ofwhich were unacceptable.The development team then experimented with increasing therelease interval. After a few attempts, it was decided that a three-month interval was sufficient. This interval was short enough toaddress the rapidly changing business needs, but long enough to avoidsome of the problems encountered with the shorter interval. Thelonger interval resulted in a development team that was not over-burdened, early and sufficient requirements analysis work, andeffective quality assurance.This process demonstrated that there is no inconsistency betweenusing CMMI and implementing an Agile development process withshort release cycles. In fact, it was an advantage to implementprocess improvements within this framework.Introducing CMMI Practices IterativelyBecause of the regulated nature of the company’s business, a strongprocess focus (OPD) was necessary from the start. Standard operat-ing procedures documenting all of the engineering and businessprocesses were developed at the same time as project managementpractices were being implemented. Regular internal audits (PPQA)ensured process compliance.Because of TrialStat’s small size, there was no difference betweenorganizational and project procedures. Training capabilities werenot developed in-house, but were outsourced. However, trainingplans and records were maintained for all staff as part of the com-pany’s regulatory requirements (OT).The iterative development process enabled the continuousintroduction of new project practices (in the Project Management,Engineering, and Support process areas), and rapid feedback ontheir effectiveness. Each iteration represented an opportunity tointroduce new processes, a new technology, or expertise (e.g., anindividual with specialized skills). After three months, it was possi-ble to determine whether the intervention succeeded and had thedesired impact. If it did, it was kept for subsequent iterations. Thosethat caused problems were either adjusted or eliminated.This mode of introducing changes imposed some constraints.The interventions could not be large; the development team had tolearn, master, and apply them well enough to provide feedback.Therefore, new practices had to be introduced gradually. For exam-ple, when peer reviews were introduced, they initially focused onlyon requirements. Only one or two interventions could be intro-Wow! eBook <WoweBook.Com>
  • 129. duced in each iteration. If there were too many interventions, thedevelopment team could not focus on delivering features.Formal CMMI-based process appraisals were not utilized. How-ever, audits against FDA regulations and guidelines were commonlyperformed by third parties and clients to ensure compliance.Measurement and Decision MakingThe collection and use of metrics for decision making (MA) startedfrom the very beginning of the project, and was subsequentlyexpanded in a series of iterations. First, data on post-release defectswere collected. This data was necessary to manage and prioritizedefect correction activities and resources. After that system was inplace, the metrics related to the ability to meet schedule targetswere collected.Scope management was the next issue. Because the deliverydate of each iteration was fixed, flexibility involved controlling thescope. Features scheduled for each iteration were sized for a three-month cycle. In some cases, features were split and implementedover multiple releases. The challenge was coming up with an appro-priate approach to measuring the size of the requirements early.Currently, using the number of use cases to measure the size ofrequirements has worked well in this environment.The measurement of size and complexity became the subse-quent focus of measurement. As the system grew, it became criticalto manage its size and complexity. One approach used was to refac-tor specific parts of the system to reduce complexity.Lessons LearnedThere were surprisingly few fundamental changes needed to applyCMMI in a regulated environment. Many of the practices requiredin larger settings still applied. Because the company operates in aregulated environment, executive and investor support for processimprovement existed from the outset. Therefore, in a different envi-ronment, additional effort may be required to obtain such support.The iterative approach to implementing process improvementsallowed the organization to incrementally and continuously improveits practices, and provided a rapid feedback mechanism to evaluateprocess changes. As more metrics are collected, it will become pos-sible to quantitatively evaluate the improvements.Process documentation proved helpful for this small organiza-tion, making it easier to integrate new staff and ensure that theycontributed sooner. Without that documentation, corporate growthChapter 5 Using CMMI Models 103Wow! eBook <WoweBook.Com>
  • 130. 104 PART ONE ABOUT CMMI FOR DEVELOPMENTwould have been more painful. The people typically attracted to asmall organization are not necessarily process oriented. Processdocumentation contributed to establishing clear ground rules fornew staff and enforcing a process-oriented corporate culture.Requirements development and requirements managementprocesses ensured predictability. These processes were addressedearly in the improvement effort and served as a foundation for otherengineering processes. For a company in the early stages of marketpenetration, it is critical that the requirements are right for eachiteration.Measurement began, and was needed, from the start. As theorganization’s practices matured, the types of things that weremeasured changed, as did the types of decisions made based on thatdata.The experience of TrialStat has demonstrated that CMMI canwork well in a small organizational setting. Process improvement ina small setting requires a gradual and incremental approach tointroducing change to ensure that the organization is not overbur-dened with an amount of change that affects its ability to deliver itsproduct. A pure Agile approach did not seem to work well; how-ever, with some modification and in combination with CMMI, someAgile practice could be of benefit to the organization.Using CMMI AppraisalsMany organizations find value in measuring their progress by con-ducting an appraisal and earning a maturity level rating or a capabil-ity level achievement profile. These types of appraisals are typicallyconducted for one or more of the following reasons:• To determine how well the organization’s processes compare toCMMI best practices and identify areas where improvement can bemade• To inform external customers and suppliers about how well the orga-nization’s processes compare to CMMI best practices• To meet the contractual requirements of one or more customersAppraisals of organizations using a CMMI model must conformto the requirements defined in the Appraisal Requirements for CMMI(ARC) [SEI 2011b] document. Appraisals focus on identifying improve-ment opportunities and comparing the organization’s processes toCMMI best practices.Wow! eBook <WoweBook.Com>
  • 131. Appraisal teams use a CMMI model and ARC-conformantappraisal method to guide their evaluation of the organization andtheir reporting of conclusions. The appraisal results are used (e.g., bya process group) to plan improvements for the organization.Appraisal Requirements for CMMIThe Appraisal Requirements for CMMI (ARC) document describes therequirements for several types of appraisals. A full benchmarkingappraisal is defined as a Class A appraisal method. Less formal meth-ods are defined as Class B or Class C methods. The ARC documentwas designed to help improve consistency across appraisal methodsand to help appraisal method developers, sponsors, and users under-stand the tradeoffs associated with various methods.Depending on the purpose of the appraisal and the nature of thecircumstances, one class may be preferred over the others. Sometimesself assessments, initial appraisals, quick-look or mini appraisals, orexternal appraisals are appropriate; at other times a formal bench-marking appraisal is appropriate.A particular appraisal method is declared an ARC Class A, B, or Cappraisal method based on the sets of ARC requirements that themethod developer addressed when designing the method.More information about the ARC is available on the SEI websiteat http://www.sei.cmu.edu/cmmi/tools/appraisals/.SCAMPI Appraisal MethodsThe SCAMPI A appraisal method is the generally accepted methodused for conducting ARC Class A appraisals using CMMI models.The SCAMPI A Method Definition Document (MDD) defines rules forensuring the consistency of SCAMPI A appraisal ratings [SEI 2011a].For benchmarking against other organizations, appraisals mustensure consistent ratings. The achievement of a specific maturitylevel or the satisfaction of a process area must mean the same thingfor different appraised organizations.The SCAMPI family of appraisals includes Class A, B, and Cappraisal methods. The SCAMPI A appraisal method is the officiallyrecognized and most rigorous method. It is the only method that canresult in benchmark quality ratings. SCAMPI B and C appraisalmethods provide organizations with improvement information thatis less formal than the results of a SCAMPI A appraisal, but nonethe-less helps the organization to identify improvement opportunities.Chapter 5 Using CMMI Models 105Wow! eBook <WoweBook.Com>
  • 132. More information about SCAMPI methods is available on the SEIwebsite at http://www.sei.cmu.edu/cmmi/tools/appraisals/.Appraisal ConsiderationsChoices that affect a CMMI-based appraisal include the following:• CMMI model• Appraisal scope, including the organizational unit to be appraised,the CMMI process areas to be investigated, and the maturity level orcapability levels to be appraised• Appraisal method• Appraisal team leader and team members• Appraisal participants selected from the appraisal entities to beinterviewed• Appraisal outputs (e.g., ratings, instantiation-specific findings)• Appraisal constraints (e.g., time spent on site)The SCAMPI MDD allows the selection of predefined options foruse in an appraisal. These appraisal options are designed to helporganizations align CMMI with their business needs and objectives.CMMI appraisal plans and results should always include adescription of the appraisal options, model scope, and organizationalscope selected. This documentation confirms whether an appraisalmeets the requirements for benchmarking.For organizations that wish to appraise multiple functions orgroups, the integrated approach of CMMI enables some economy ofscale in model and appraisal training. One appraisal method can pro-vide separate or combined results for multiple functions.The following appraisal principles for CMMI are the same as thoseprinciples used in appraisals for other process improvement models:• Senior management sponsorship6• A focus on the organization’s business objectives• Confidentiality for interviewees• Use of a documented appraisal method• Use of a process reference model (e.g., a CMMI model)• A collaborative team approach• A focus on actions for process improvement106 PART ONE ABOUT CMMI FOR DEVELOPMENT6. Experience has shown that the most critical factor influencing successful process improvementand appraisals is senior management sponsorship.Wow! eBook <WoweBook.Com>
  • 133. CMMI Related TrainingWhether your organization is new to process improvement or isalready familiar with process improvement models, training is a keyelement in the ability of organizations to adopt CMMI. An initial setof courses is provided by the SEI and its Partner Network, but yourorganization may wish to supplement these courses with its owninstruction. This approach allows your organization to focus on areasthat provide the greatest business value.The SEI and its Partner Network offer the introductory course,Introduction to CMMI for Development. The SEI also offers advancedtraining to those who plan to become more deeply involved in CMMIadoption or appraisal—for example, those who will guide improve-ment as part of a process group, those who will lead SCAMPIappraisals, and those who will teach the Introduction to CMMI forDevelopment course.Current information about CMMI related training is available onthe SEI website at http://www.sei.cmu.edu/training/.Improving Industrial Practiceby Hans-Jürgen KuglerHow many software products have a design that can be maintainedover the lifetime of the product? How many have a design thatexhibits elegance and embodies the principles of good softwareengineering, as for instance, laid down in Dave Parnas’ seminal1972 paper?7 How many projects can truly trace the relationshipbetween customer requirements and the features that they areimplementing? We now have the second or even third generation ofdevelopers—depending on your viewpoint—contributing to or suf-fering in the software crisis. Do we ever learn? The answer cannotonly come from the developer community.The recent TechRepublic Live 2010 Conference8 asked, “BuggySoftware: Why do we accept it?” The answers made a clear distinc-tion between IT software and other products (e.g., automobiles),Chapter 5 Using CMMI Models 1077. D. L. Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules,” Com-munication of the ACM, 15, no. 12 (1972), pp. 1053–1058.8. TechRepublic Live 2010: The Changing Face of IT conference, Louisville, Kentucky, 30June to 2 July 2010.Wow! eBook <WoweBook.Com>
  • 134. with IT software suffering from a continuous feature increase irre-spective of the dangers of increased complexity. This situation doesnot hold only for the end consumer market, but also for enterpriseIT. Mies van der Rohe—“less is more”—must be turning in hisgrave. Numbers of features are used as apparent market differentia-tors, since they are easily highlighted. It was even suggested that theuser community of the IT movement showed the same signs of aStockholm Syndrome9 that hostages may develop.In a market that does not value product qualities other thancost, it is difficult to develop the urge for quality initiatives. Disci-pline in consequently applying known good practices is often seen asinterfering with the time and cost dimensions. A twisted version ofCrosby’s “quality is free” statement is what seems to drive the actions:There is rarely time to do it right, but always time to do it again.However, not only IT systems contain software. “EmbeddedSoftware Rules”10 is an article that discusses how software is every-where: from shavers and most kitchen equipment to airplanes andautomobiles. In the automotive industry, 80% to 90% of all in-vehi-cle innovations are software-driven. Software is the “glue” betweenfunctional groups inside and outside the vehicle, but at a cost: 50 to100 interconnected special purpose computers cooperate in a vehi-cle running software load measuring in the order of 107 lines ofcode and many thousand (interdependent) calibration parameters.“The dynaxity is actually increasing exponentially,” according toProf. Heinecke, CEO of BMW Car IT,11 where dynaxity is the com-pound effect of dynamics of change (in market and technology) andcomplexity of the system under development. The automotiveindustry is a competitive market, and a market governed by productwarranty legislation. Many of the functions of a vehicle are safetyrelevant, and disciplined and traceable engineering is required.If the innovative capability of a whole market is affected, indi-vidual improvement efforts by companies, however large they maybe, are not sufficient. The whole value-creation network needs to beaddressed. Many automotive companies have their own strategicimprovement initiatives, such as Bosch,12 with significant positive108 PART ONE ABOUT CMMI FOR DEVELOPMENT9. Stockholm Syndrome, Wikipedia, July 2010.10. S. Ferber, H.-J. Kugler, Robert Bosch GmbH, and KUGLER MAAG CIE GmbH, “Embed-ded Software Rules,” White Paper, 2006.11. H. Heinecke, “Innovation Development and Community Sources. The Survival Strategy,”International SPICE Days, June 2010, Stuttgart.12. T. Wagner, Robert Bosch GmbH, “Bringing Software on the Road,” SEPG 2004, Orlando,Florida, March 2004.Wow! eBook <WoweBook.Com>
  • 135. effect.13 However, industry-wide initiatives are also needed. Theautomotive industry association (Verband deutscher Automobilin-dustrie, VDA)14 issued guidelines, and a software initiative (HIS)was formed by the OEMs.15 The automotive OEMs focus on theengineering quality of the development process at supplier organi-sations.Development projects at suppliers are appraised with respectto process maturity, and the results allow the OEM in question tomanage risks better, to develop joint improvement actions, and toincrease the urgency and importance of process improvement in thesupplier organisation. The model chosen by the HIS is based on“Automotive SPICE”16 an adaptation of ISO 15504, which is—whilst not equivalent—at least compatible with the continuous rep-resentation of CMMI.17CMMI remains the approach of choice for many organisationalimprovement programmes. Results show that the overall strategy“improve a whole industry” does actually work: whilst software inthe early 2000s caused many a driver to resort to walking, theseincidents have decreased while process maturity increased18 andwhile dynaxity climbed significantly. Dr. Weißbrich, Volkswagen,argued that the active and passive safety features of vehicles show astatistically relevant correlation with the significantly reduced roaddeaths in Germany.19 These safety features are realised in software,of course.In the past, the automotive industry has focussed on its tradi-tional V-shaped iterative development processes, with projects andorganisational line function organised in a matrix fashion. Interde-pendence of projects and the fact that project acquisition, launch-ing, and tear down (“close out”) are very dynamic means that stableChapter 5 Using CMMI Models 10913. H.-J. Kugler et al., “Critical Success Factors for Software Process Improvement at BoschGS,” Electronic Systems for Vehicles, 11th International Congress, VDI, Baden-Baden, 2003.14. Verband deutsche Automobilindustrie (German Association of Automotive Industry),VDA Volume 13, Development of Software-Driven Systems – Requirements for Processesand Products, 2004.15. HIS – Herstellerinitiative Software (OEM Software Initiative by Audi, BMW, Daimler,Porsche and Volkswagen), www.automotive-his.de.16. Automotive SPICE, www.automotive-his.de.17. K. Hörmann, “Comparison of CMMI and ISO 15504,” KUGLER MAAG CIE WhitePaper.18. L. Dittmann, Nutzen von SPICE aus der Sicht eines OEMs, Volkswagen AG, IAA Work-shop, Frankfurt, September 2005.19. Weißbrich, “Spicy Cars—the Value of Automotive SPICE to the German AutomotiveIndustry,” International SPICE Days, Stuttgart, June 2010.Wow! eBook <WoweBook.Com>
  • 136. teams are more a wish than a reality. Many companies hoped thatmaturity levels 3 and beyond would provide stability to the organi-sation, and therefore provide a respite from constant change.Dynaxity plays havoc with this. The ability to change, to flexiblyadapt to new context conditions, and still run disciplined and trace-able processes leading to high-quality products is the market differ-entiator today.Model-based development is the mainstay of automotive devel-opment methods,20 but Agile development and Agile project man-agement, Lean and Six Sigma techniques are increasingly usedwithin the context of process improvement programmes, and usedwith good results, as expected.21No doubt the automotive industry will continue with improv-ing industrial practice. It needs to, in the light of what Lero22 callsevolving critical systems.23 The market mechanisms enforce that.Open tool platforms adapted to these needs are beginning to takeshape24 and will strengthen consistent application of good practices.Can the same principles also be applied to different markets orindustry domains—for example, medical devices or even ultra-portable netbooks? The medical devices market may stand a chanceto follow suit, since product warranty legislation applies here too,and since deployment is regulated—and the process plays animportant part in the deployment decision. Importance andurgency must be felt in a market; only then will its value-creationnetwork exhibit a willingness to change. The pressure of commu-nity-based software development on traditional software develop-ment may help,25 provided the rift that exists between manyproponents of CMMI and many of those involved in community-based software can be reconciled. In my opinion, this is just a ques-tion of time, because the evidence of compatibility exists.Maybe this is even a moot argument. Experience with the “soft-ware car” firmly positions software to be the innovation driver. No110 PART ONE ABOUT CMMI FOR DEVELOPMENT20. AUTOSAR, www.autosar.org.21. B. Boehm and R. Turner, “Balancing Agility and Discipline,” Addison-Wesley, 7th print-ing, October 2009.22. Lero, “Research Area: Evolving Critical Systems,” The Irish Software EngineeringResearch Centre, http://www.lero.ie/research/researchareas/evolvingcriticalsystems.html.23. L. Coyle et al., “Evolving Critical Systems,” IEEE Computer, May 2010.24. B. Lange, “Eclipse auf Rädern,” iX 01/2010.25. H.-J. Kugler, “Open Source Teams entwickeln schneller,” Automobil-Elektronik, Dec.2005.Wow! eBook <WoweBook.Com>
  • 137. other “material” has such potential and “weird” (nonNewtonian)properties. Quantum mechanics is the only thing that comesclose.26 Maybe Tom DeMarco was right when he wrote about theend of software engineering:Consistency and predictability are still desirable, but they haven’tever been the most important things. . . . We’ve tortured ourselvesover our inability to finish a software project on time and onbudget. But . . . this never should have been the supreme goal.The more important goal is transformation, creating software thatchanges the world or that transforms a company or how it doesbusiness. We’ve been rather successful at transformation, oftenwhile operating outside our control envelope.27A very valid point, I find. In this case, the two sides have noth-ing to argue. Organisational capability, good processes, and individ-ual competence would still be required to learn and improve inachieving this transformation. Heisenberg’s uncertainty principlemay also prevent us from objectively controlling software and itsdevelopment, because there is no objectivity. But this state does notprevent us from building ecosystems on software platforms thatflourish and change the world.Either way, the future of process improvement, and of theCMMI, looks bright. There is a lot to be done. Let us begin.Chapter 5 Using CMMI Models 11126. H.-J. Kugler, “What Is Software? An Excursion into Software Physics” Workshop,KUGLER MAAG CIE GmbH, July 2008.27. T. DeMarco, “Software Engineering – An Idea Whose Time Has Come and Gone?” View-points, IEEE Software, June/July 2009.Wow! eBook <WoweBook.Com>
  • 138. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 139. CHAPTER 6ESSAYS AND CASE STUDIESFor the third edition of this book, we asked contributors to writeshort case studies and essays instead of one large case study. The casestudies are an excellent mix of experiences involving a variety oforganizations and contexts.Case StudiesThe following three case studies each have a unique perspective onusing CMMI for Development. The first focuses on how to use themodel to achieve maturity level 2 and describes the lessons learnedwhen a process improvement project can change course to achieveits objectives. The second case study follows the experience of anorganization that uses CMMI over a long period of time and the com-petitive advantages it enjoys. The third describes and final case studydescribes how combining the use of CMMI for Development andLean Six Sigma can accelerate and improve process improvement.Switching Tracks: Finding the Right Way to Get to Maturity Level 2by Heather Oppenheimer and Steve BaldassanoWhen your customer contract requires that your “software develop-ment process must be CMMI Level 2,” there’s a right way and awrong way to go about meeting that demand. KNORR Brake triedboth ways and has the scars and the rewards to show for it. This is thestory of how a very small organization first headed down the wrongtrack then changed direction—resulting in a successful maturitylevel 2 appraisal less than nine months later. KNORR Brake Corporationsupplies pneumatic and hydraulic braking systems, air conditioning113Wow! eBook <WoweBook.Com>
  • 140. equipment (HVAC), and door operators, as well as repair, overhaul,and maintenance services, for all types of mass transit rail vehicles,including Metro, Light Rail, High-Speed Trains, Commuter Rail, andMonorail. Key characteristics of KNORR Brake products includehigh reliability, safety, integrated operations and communications,and specialized functionality not available from other vendors.Of about 250 employees, fewer than 30 are involved in systemsand software engineering; the others are employed in the manufac-turing facility. Each software project involves one or two highly expe-rienced electrical engineers who develop customized embeddedsoftware that is integrated with the hardware at the systems level.KNORR Brake has maintained ISO-9001-2000 registration since1994 and must also adhere to IRIS (International Railway IndustryStandard) and follow the quality management standards of its parentcompany, KNORR-Bremse.The Wrong RouteWith such a strong quality management system in place, when a cus-tomer required “CMMI Level 2,” we thought it would be easy, onlyrequiring the addition of a few new artifacts. No one expected anysignificant gaps, but if gaps were found, everyone assumed therewould be an opportunity to fix minor issues and still achieve thelevel. Unfortunately, this misunderstanding resulted in a SCAMPI Aappraisal that was an expensive way to discover that the organizationwas rated “mud-sucking, bottom-dwelling Level 1.” It also cost thegoodwill and enthusiasm of many of the people involved.Based on our assumption that little or no preparation would beneeded, we scheduled our SCAMPI A appraisal almost immediately.Several managers and engineers went to the SEI-authorized Intro-duction to CMMI course so they could learn what small additionsCMMI required them to make to the current quality managementsystem, as well as to meet the requirements for participating asappraisal team members. However, the course examples and modelinformative material were not very relevant to the world of embed-ded software and we were still confused about what the modelrequired. Based on the course information and advice from our leadappraiser, we put in place some new processes and procedures, eventhough none of them provided any value to the business. Peoplewere willing to use these new “CMMI processes,” but consideredthem to be useless overhead.Assuming that all lead appraisers are equivalent, KNORR Brakehired the same lead appraiser who was working with several other114 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 141. subcontractors of the customer. Unfortunately, although he was veryexperienced and knowledgeable, the lead appraiser tried to assessour implementation of CMMI practices as if KNORR Brake was alarge software application development organization—not a group ofvery small teams developing embedded software.Although the customer contract specified that “software develop-ment must be CMMI Level 2,” we assumed that the entire organiza-tion would need to comply with the CMMI standard—as if it wereISO or IRIS. As a result, the entire organization, including systemsengineering and manufacturing as well as software engineering, wasincluded in the scope of the appraisal. The large scope increased theduration and cost of the appraisal and made it more difficult to findthe right evidence of implementation for each practice. At the sametime, the areas the customer really cared about were not appraised.Even though we weren’t trying to improve any processes beyondadding some documents, the staff spent hundreds of unplannedhours just preparing for the appraisal, doing things like collectingartifacts. Based on our understanding of the SCAMPI A requirementsfor “objective evidence,” the team wrongly assumed that each prac-tice required at least two unique pieces of evidence; they copied andstored hundreds of documents in Practice Folders within ProcessArea Directories. Most of the artifacts collected were useless to theappraisal team who ended up looking for all of the evidence againafter being unable to make sense of the information so laboriouslyprovided.The appraisal itself was an agonizing experience. People werenervous about preparation, and then once they were in an interview,they felt like they were on trial. Questions were asked in CMMI-speak rather than in the terminology used in KNORR Brakeprocesses, so the answer was often, “We don’t do that” when a partic-ular CMMI practice was something they really did implement.Because no one in KNORR Brake really understood the CMMImodel, the assumption was that there was nothing open to questionin the lead appraiser’s expectation of how practices should be imple-mented. No one could translate the KNORR Brake processes forembedded software development into CMMI terminology that thelead appraiser would understand. As a result, the organization wasrated maturity level 1, the recommendations for addressing gapsweren’t useful or implementable, and the whole organization felt thatCMMI was a waste of effort.Chapter 6 Essays and Case Studies 115Wow! eBook <WoweBook.Com>
  • 142. Switching to the Right WayBecause the contract still required CMMI Level 2 for Software Devel-opment, senior management decided to learn more about CMMI andtry again. It wasn’t easy because we had to overcome some very nega-tive attitudes toward CMMI and SCAMPI in particular, as well asconsultants, process improvement, and appraisals in general.However, this time, we treated the effort as a project, not as anactivity to be done in the margins. As long as we had to do it, wedecided that we might as well do something useful. We looked at thecontract requirement for CMMI Level 2 as an opportunity for under-standing KNORR Brake written and unwritten processes and thenimproving them as needed to add business value.Senior management demonstrated their commitment by allocat-ing an experienced project manager to manage and facilitate theprocess improvement effort full-time and granting him the authorityand resources necessary to make it happen. This person not only hadquality assurance experience, project management experience, andsome CMMI training, he was highly respected and trusted by every-one based on his technical experience and skill in delivering a product.All of the software engineering staff had time allocated to theprocess improvement program and were involved and engaged inclarifying, understanding, defining, and improving the program life-cycle, operational procedures, work instructions, and the flow anddependencies among them. As an added benefit, the engineers endedup learning a lot from each other, as well as defining processes thatworked.The first step was to look carefully at the contract requirement forCMMI Level 2 to determine exactly where to focus. At the same time,the CMMI Project Manager began to look for a certified leadappraiser to serve as a consultant; someone who would understandthe needs and context of a very small organization that does embed-ded software and who could coach us in interpreting the CMMImodel for implementation in that context. The initial phase of theprocess improvement project included working with the selectedconsultant to review the contract language to ensure that we reallyunderstood what was required, and then to confirm that understand-ing with the customer. This narrowed the scope of the effort to thesoftware engineering group processes, rather than trying to changethe whole enterprise. This approach made the process improvementproject more manageable and increased the likelihood of success.On any journey, whether it’s an actual journey by rail or ametaphorical journey of process improvement, it’s important to start116 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 143. by understanding where you are and where you want to go. Weworked with the new consultant on an in-depth current state analy-sis to understand the overall KNORR Brake software engineeringprocess architecture, map “what software engineers do and how theydo it” to the CMMI model practices to identify possible gaps, andthen decide what to do to address those gaps.CMMI was used as a guide, but all implementation decisionswere based on the KNORR Brake process context and culture. Ahighly interactive version of the SCAMPI B methodology that didn’trequire the organization to prepare evidence ahead of time was usedfor the current state analysis to reduce adverse impact on currentproduct development activities without impacting the quality andusefulness of the appraisal results, to increase the learning opportu-nities during the appraisal, and to be able to tell the customer aboutprocess improvement progress in terms of CMMI and their contractrequirements.Over the next several months, the CMMI Project Manager mettwice a week for two-hour sessions (lunch provided!) with membersof the software engineering group to understand, clarify, and enhancethe processes and procedures related to developing embedded soft-ware. The CMMI Project Manager reported progress regularly at man-agement status meetings and also met weekly by phone for coachingwith the consultant to go over progress, issues, and achievements.The consultant returned twice for a few days each time to providecustomized training and lead hands-on workshop sessions with theteam to cover some specific areas of need related to process architec-ture definition, estimation, risk management, and measurement andanalysis. Although everyone was fully engaged with defining processesand procedures, the CMMI Project Manager was responsible for actu-ally documenting them and for ensuring that the KNORR Brake doc-ument manager formatted them appropriately and submitted them tothe corporate repository correctly.Our initial focus was to define and document the work flow intothe KNORR V-Model (a view of the project lifecycle). When theeffort started, program management had monitored only customerdocument deliverables and three other software engineering tasks:design, code, and test. No one other than software engineers couldunderstand why the software engineering effort and duration estimateswere so high, when there appeared to be so little work to do. After wefinished, all of the key activities, dependencies, and deliverables werecaptured in the V-Model; as a result, program management and seniorChapter 6 Essays and Case Studies 117Wow! eBook <WoweBook.Com>
  • 144. management now had a much better understanding of the softwareengineering work. CMMI practices in the Requirements Manage-ment, Project Planning, Project Monitoring and Control, and Mea-surement and Analysis processes areas provided guidance for ourimplementation of the KNORR V-Model.The KNORR V-Model provided the foundation for an improvedand more useful work breakdown structure (WBS), which in turnwas used as a starting point for identifying and estimating the factorsthat impact how much effort each task or deliverable would require.Although the CMMI model informative material and formal trainingprovided many examples of these factors, such as number of func-tions, source lines of code, and numbers of pages, it turned out thatthe examples given were not the primary factors affecting effort andschedule estimates in KNORR embedded development.Engineers knew what factors impacted their effort, but had nevercaptured or shared this tacit knowledge. For example, the amount ofwork required for customer-deliverable documents is affected by thenumber of circuit boards and the number of revisions a particularcustomer is likely to require, rather than the number of pages in adocument. With some initial coaching from the consultant, the teamwas able to determine what factors did make a difference, and thenuse Wide Band Delphi techniques to estimate typical effort ranges fortasks, depending on the values of those factors and historical effortdata for similar activities.The typical effort ranges were used in the updated project plansand as input to new bids and projects. As a result, KNORR Brake wasable to more accurately estimate the cost of new software engineeringwork, and provide customers with a more accurate prediction ofdelivery dates. CMMI practices in the Project Planning, Project Mon-itoring and Control, and Measurement and Analysis process areashelped us implement the new WBS.After the KNORR V-Model was established, the software projectattributes identified, and the WBS completed, the Program Manage-ment Schedule was updated to reflect the actual activities, so it wasmuch easier to predict how long a project would take and monitorprogress during the project. An additional benefit was that the rest ofthe organization gained a much better appreciation of the value thesoftware engineering team was providing to the business. Under-standing the real project attributes and WBS made a huge improve-ment in managing our software engineering resources across projectsand provided valuable input when bidding new projects.118 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 145. Some KNORR Brake customers required a Software RequirementsTraceability Matrix (SRTM) as a deliverable, but the SRTM was oftencreated after all the work was completed and used to document whatexisted, rather than a means to manage the work. However, one soft-ware engineer had discovered that it was a useful tool, and sharedthat experience with the other team members during the weeklymeetings. The KNORR V-Model was then used to update the struc-ture for the SRTM so that it helps ensure requirements coverage andassessment of the impact of changes throughout a project.KNORR Brake already had a process for capturing requirementschanges that were charged to the customer. However, if a changeseemed small or the program manager decided to give it to the cus-tomer without charge, it wasn’t recorded, and the impact on projectschedules, effort, and cost was not assessed. We enhanced and insti-tutionalized the Project Change Request (PCR) process with a newPCR Procedure that requires systems and software engineers to eval-uate all changes to determine impact on the schedule, cost, and/orscope and identify any risks related to the change.We quickly saw the value in the new procedure because severalrequests that would have been assumed to be small turned into rev-enue-producing changes, whereas others did not generate a customercharge, but still required replanning of the project resources becausethey affected the effort and schedule. In conjunction with theKNORR V-Model and the new WBS, CMMI practices in the Require-ments Management, Project Planning, Project Monitoring and Con-trol, and Configuration Management process areas helped guide thechanges made in the SRTM and the new PCR change request tem-plate and procedure.All of the process and procedure changes interacted synergisti-cally, each supporting and enhancing the others. All either clarifiedor enhanced the way work was already being done; none added use-less overhead. Because the changes were a natural extension of thecurrent processes, it was easy to institutionalize them within theKNORR Quality Management System.After the process changes were established and as they werebecoming institutionalized, the organization began planning for theSCAMPI A appraisal. Working with the consultant, the CMMI Proj-ect Manager defined a set of questions to use when interviewingpotential lead appraisers to determine whether the candidate wouldbe capable of understanding how CMMI practices can be imple-mented in a very small organization that creates embedded software.The lead appraiser needed to be able to adapt to the KNORR BrakeChapter 6 Essays and Case Studies 119Wow! eBook <WoweBook.Com>
  • 146. organizational and process culture, rather than expecting KNORRBrake to do things in a particular way. Because KNORR Brake wantedto have the appraisal before the end of the calendar year, a time thatmany other organizations are also trying to schedule appraisals, theselection process began in the late summer to increase the likelihoodthat the lead appraiser chosen would be available when needed.Each new process advancement and tool improvement wasmerged into our existing Quality Management System by writingnew work instructions and/or operational procedures and storingthem in an online repository we call REX (Rail Excellence). Thisallows both existing and new employees to easily find the appropri-ate procedures and templates within the context of the process mapsthat clearly define the development and design lifecycles.Preparing evidence for the SCAMPI A appraisal turned out to besimple. Because the CMMI Project Manager knew which KNORRBrake processes implemented which CMMI practices, it was just amatter of pointing to the actual work products once they were cre-ated. Most of the artifacts selected for evidence had sections thatwere appropriate for multiple CMMI process areas and practices. Theconsultant reviewed the evidence with the program manager to makesure the work products selected were appropriate and complete, andthat there were clear explanations of the context so that the appraisalteam would understand why those particular artifacts were selected.It didn’t matter which projects were eventually chosen by the leadappraiser to represent the organization, because the work productlinks pointed to directory structures that included all projects.The appraisal was interactive and cooperative rather than con-frontational. Work outputs were projected on a screen and the leadappraiser asked participants to explain their work for the entireappraisal team to review. If questions or concerns were raised, theywere answered immediately rather than waiting for a separate valida-tion session. Because the appraisal focused on KNORR Brakeprocesses and evaluated CMMI model implementation within thatcontext, rather than focusing on CMMI itself, no one felt threatenedand the information was complete and accurate.The appraisal was finished in less than four days and KNORRBrake software engineering achieved their goal of being rated matu-rity level 2. Although achieving that rating was certainly importantfor contractual reasons, perhaps more significantly, staff and manage-ment learned that CMMI practices could add value without addingoverhead. Members of other functional groups and product lineswere asking, “Why do only the software engineers get to do CMMI?We want to do it too!”120 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 147. Moving Forward (The Journey Continues . . .)Based on the successful SCAMPI A appraisal with the KNORR BrakeSoftware Development Group and the noticeable value added by thenew processes and procedures, the company decided to continue theprocess improvement effort. The CMMI Project Manager was pro-moted to a newly formed position as Manager, Business ProcessImprovement with a mandate from senior staff to make improve-ments throughout KNORR business and engineering processes. Cur-rently, KNORR has four process improvement teams in action.One team is extending the Brakes software engineering processimprovement work into the domain of HVAC software engineering.The team has already completed tailoring the KNORR V-Model life-cycle and WBS for developing embedded code in the HVAC domain.Project schedules have been updated accordingly with milestonesbased on a more realistic view of the work required. The HVAC teamimproved on the Brakes software engineering process with the imple-mentation of a new template for identifying the key project attributesthat allows for multiple variations. With this new tool, the HVACSoftware Engineer can more accurately characterize the project type,which is a key factor in estimation of effort and schedule.We are also extending the process improvement work into sys-tems engineering in both the Brakes and HVAC domains. This teamis reviewing the systems engineering lifecycle and mapping CMMIpractices to the systems engineering process. We are looking at thematurity level 2 process areas, as well as key maturity level 3 processareas where the organization is already strong or where there areissues that need to be addressed in the near term.Due to the successful process improvement effort completed bythe Brakes software engineering group and because the team approachis working extremely well with the newly formed cross-domain soft-ware and systems engineering teams, senior management supportedformation of a HVAC New Product Design Team that will use CMMIML2 and ML3 practices in designing new HVAC equipment.After the systems and software engineering design lifecycles werewell understood, we realized that the proposal process needed to beintegrated into the overall product lifecycle. A proposal team hascompleted mapping the entire proposal process and clarifying how itfeeds into the systems and software design lifecycle when proposalsare awarded. The effort and documentation within the proposalprocess has proved extremely valuable by providing the frameworkfor future bids as well as helping us predict the resource and timeallocation needed for bid preparation itself. In addition, when theChapter 6 Essays and Case Studies 121Wow! eBook <WoweBook.Com>
  • 148. contract is awarded, the product and customer details from the bidprocess are directly transferable into estimates of project size, tasks,and deliverables, thereby saving planning time and effort.At the end of the year, we will conduct a SCAMPI A that includessystems engineering and software engineering processes for bothBrakes and HVAC. We will still use some assistance from an outsideconsultant to validate our assumptions and decisions, but now thatwe are able to understand how to apply the CMMI model within theKNORR context, we need much less direct guidance. Based on ourexperience with process improvement in Brakes software engineer-ing, we predict a high likelihood of success, which will put KNORRat a competitive advantage in our market domain.Lessons LearnedAs a result of travelling first down the wrong track and then downthe right one, we have learned some key lessons, which we will applyas we continue on our journey of process improvement:1. Question assumptions and trust your instincts. Don’t assume thatyou have to do something because CMMI or some expert “requires”it. If it doesn’t seem to make any business sense, it probably isn’t agood implementation for your current organizational context.2. When trying to meet contract requirements, use the contract lan-guage to help specify organization and model scope for a formalappraisal. Understanding the contract requirements focuses theimprovement effort and helps achieve immediate value.3. Especially if you have had a previous negative experience withprocess improvement, demonstrate value early and often. When staffand managers see that a change makes their own work easier ormore effective, they are more likely to be willing to embrace furtherchanges.4. Process improvement using CMMI is not something that can bedone in the margins. It requires dedicated effort by a respected andtrusted project manager as well as involvement and engagementfrom everyone at every level in the organization.5. The CMMI model provides value only if it is used as a guide forprocess improvement, not as a checkbox exercise. Process improve-ment is not a matter of documenting what “should” be done andforcing everyone to comply, whether or not it provides any businessvalue. Changing the paradigm from “getting by for certification” to“clarifying and improving our processes and using the CMMI modelto help” validates what is already being done, makes any changes“stick,” and ensures that those changes add business value.122 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 149. 6. All CMMI goals and practices are useful and do not add unnecessaryoverhead—as long as you interpret them and implement themwithin your own business and technical context. Within your orga-nizational context, each process improvement will often implementseveral CMMI practices, and synergy among the improvementsincreases the benefit of each.7. A consultant who understands the organizational context can pro-vide guidance in areas where the organization doesn’t have expertiseand can help the program stay on track. However, process changesneed to come from inside the organization for the changes to beinstitutionalized. Be sure to choose a consultant who will coachrather than prescribe.8. Choosing a lead appraiser who understands the business contextensures that the appraisal will be valid. If the lead appraiser doesn’treally understand the business context and there is no one to helptranslate between CMMI-ese and the organization’s processes andterminology, there’s a high likelihood that the appraisal results willbe invalid due to miscommunication and you will not achieve yourgoal.9. When process improvement activities bring clear business value toone part of the organization, other parts of the organization will askto get on board too. Success breeds success.After we switched to the right track for our process improvementjourney using CMMI, we have had an enjoyable trip, were able toarrive on schedule, and are looking forward to travelling to the nextdestination!Using CMMI as a Basis for Competitive Advantage at ABBby Aldo DagninoABB is a multinational organization and market leader in power andautomation technologies that enable utilities and industries toimprove performance while reducing environmental impact. Thevast majority of ABB’s products consist of complex systems that haveboth hardware and software components (e.g., robot systems,SCADA systems, relays, control systems, substation automation sys-tems). Some products are purely software (e.g., control systems, sub-station automation, SCADA systems), whereas others are purelyhardware (e.g., power transformers, circuit breakers).Chapter 6 Essays and Case Studies 123Wow! eBook <WoweBook.Com>
  • 150. The primary customers of ABB are commercial organizations thatare important players in sectors such as utilities, petro-chemicals,pharmaceuticals, automotive, manufacturing, chemical, and oil andgas. Although ABB’s customers do not require their suppliers todemonstrate CMMI maturity levels, the company has been utilizingCMMI for almost ten years. CMMI is used for continuous processimprovement of the corporation’s product development processes.ABB recognized that CMMI provides a good framework for processimprovement because it contains industry best practices for thedevelopment of complex systems. Following CMMI’s principles hashelped and continues to help ABB product development businessunits (BUs) to be leaders in their respective market segments.Process improvement has been an important element in the his-tory of ABB and can be viewed as a two-stage process. During thefirst stage, continuous process improvement was promoted by a cor-porate process organization. The second stage of process improve-ment was spawned as a result of the positive results observed in stageone and because members of the corporate process improvementorganization from stage one moved to several development BUs andbecame the members primarily responsible for the BUs’ processimprovement teams.Adopting CMMIThe official journey for ABB in continuous process improvement ofproduct development began in 1999 when the Software CMM (SW-CMM) based initiative was launched and BUs that developed soft-ware products began voluntary participation in the initiative. Thename given to this initiative was the ABB Software Process Initiativeor ASPI. There were few pilot process improvement projects that“signed up” as participants in the initiative. ASPI was a global andcentralized program and a Corporate Software Engineering ProcessGroup (CSEPG) was created to move the initiative forward.The CSEPG worked in a geographically dispersed fashion withteams in countries where the major software development groups ofthe corporation were located. The primary objectives of the CSEPGwere to develop a group of continuous improvement experts withdeep knowledge of the CMM model and to develop the basic meth-ods and tools to be employed at each development BU for improve-ment activities.Soon after the initial pilot projects began, it became clear that asABB’s products have a combination of hardware and software compo-nents, SW-CMM did not cover practices that fully embraced both124 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 151. types of components. For this reason, adopting CMMI as the frame-work for continuous process improvement was a natural option.Hence, the CSEPG became a Corporate Engineering Process Group(CEPG). The strategy for the CEPG was to develop deep expertise inCMMI and to promote and increase awareness of the value of CMMIamong product development units. The objective was for membersof the CEPG to work closely with the product development BUs astrainers, mentors, and coaches to the BU’s process improvementteam. In this way, the first stage of the continuous process improve-ment initiative at ABB began.As the first pilot projects were completed, the number of productdevelopment BUs in the corporation interested in CMMI increasedby an order of magnitude. Additionally, the experience of the CEPGteam working with the initial pilots resulted in a need to develop keyrobust methods and tools that enabled working more systematicallywith a larger number of product development BUs. As few develop-ment BUs needed to demonstrate a maturity level, the approachtaken was to instead demonstrate the economic benefits from mak-ing changes to the development processes using CMMI.Standard Tools and MethodsThus, standardized internal methods and tools needed to be devel-oped to ensure consistency when engaging multiple product devel-opment units. Furthermore, the use of a continuous improvementframework was identified as an important asset. Because develop-ment units did not need to demonstrate maturity level, the continu-ous process improvement activity became cyclic. Cycles weretypically one year long and corresponded to the budgeting cycles ofthe organization. The IDEAL model was selected as a continuousprocess improvement cycle framework.The tools and methods developed by the global CEPG team mem-bers and then employed during its engagements with product devel-opment units in their geographic area of responsibility includedprimarily the following:• A tool to assess the readiness of an organization to implement a con-tinuous process improvement initiative• An internal appraisal methodology, including training and tools• A methodology to translate the appraisal results into a prioritizedprocess improvement work breakdown structure• Methods and templates for developing a process improvement plan tomanage the improvement activities in the cycleChapter 6 Essays and Case Studies 125Wow! eBook <WoweBook.Com>
  • 152. • A method for measuring the economic benefits associated with thechanges made as a result of the process improvement activity• A data repository that summarized a set of improvement measures foreach product development BU engaged• A repository of lessons learned, good practices, and general knowl-edge gained in the interactions with product development unitsA brief description of these tools and methods and an explanationof their usefulness to implement CMMI are described in the remain-der of this case study.An organization that decides to implement a CMMI continuousprocess improvement program needs to establish the “right” infra-structure, dedicate human and financial resources, have supportfrom senior management, have a competent change agent, train theorganization’s members in CMMI, and in general be “ready” for theinitiative. A readiness assessment tool and method were developedand are used to quantitatively and qualitatively measure the readi-ness of an organization to conduct a continuous process improve-ment program using CMMI.The readiness assessment is conducted at the beginning of eachprocess improvement cycle and reevaluation is conducted within thecycle as needed. The results of readiness assessments have been usedto ensure that senior management, change agents, and the organiza-tion are fully committed to the CMMI initiative. When deviationsoccur, the results of a reassessment show potential areas that need tobe addressed to move the CMMI initiative forward.The use of an internally developed CMMI appraisal methodologyand tools has been essential to evaluate and diagnose ABB develop-ment BUs against CMMI best practices. This internal appraisalmethodology is based on Version 1.1 of the Appraisal Requirementsfor CMMI (ARC 1.1) and for many years has been used to appraiseproduct development BUs.The ABB internal appraisal methodology uses both Class B andClass C internal CMMI appraisals. Class B internal CMMI appraisalshave been employed primarily when a development organization beginsa continuous process improvement cycle and after the improvementsmade have been institutionalized in the BU. Class C internal CMMIappraisals are used in between Class B appraisals to evaluate one ortwo CMMI process areas (PAs).All members of ABB’s internal appraisal teams must take the SEI-taught Introduction to CMMI-DEV course as well as the ABB appraisaltraining course. To lead a CMMI internal appraisal, the appraisal126 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 153. leader must have participated in at least three internal Class Bappraisals and must have taken the SEI-taught Intermediate Conceptsof CMMI course. It is also an important and valued requirement thatat least one member of the product development BU must participatein the appraisal, because ultimately the development BU will beresponsible to move the process improvement project forward.The results of an internal CMMI appraisal consist of a final pres-entation that defines the strengths and weaknesses of the organizationwith respect to CMMI PAs. The final presentation is consolidated bythe appraisal team and is delivered by the internal appraisal leader tothe participating organization at the end of the appraisal. A seconddeliverable generated after completing the internal appraisal is adetailed observations document in which observations made by theappraisal team are detailed at the practice level for each PA includedin the appraisal activity.After the appraisal is completed, the observations document isused to generate a work breakdown structure that serves as a basisfor the generation of the improvement plan. At this stage, the partic-ular product development BU’s annual/biannual objectives play acentral role in the selection and prioritization of PAs that will beincluded in the improvement cycle.Those PAs that directly contribute to the achievement of theannual/biannual development BU’s objectives are selected. For exam-ple, a development BU may have as part of its business objectives toreduce the cost of poor quality (COPQ) by 15%. At the same time,the results of the appraisal may show that the BU’s process, whencompared to the Requirements Development (RD) PA, has manyweaknesses that seem to contribute to poor documentation and cap-ture of requirements and hence to a high degree of rework, whichraises the COPQ. Under these circumstances, a WBS (work break-down structure) that addresses what improvement is needed relativeto the RD PA is then generated using the observations document.The generation of the process improvement WBS is a difficult task tocarry out by the BU’s process improvement team and thus the CEPGcoach usually works closely with the improvement team to fullydevelop the WBS.After the WBS for process improvement has been completed, theprocess improvement plan (PIP) is developed. The development ofthe PIP follows closely the practices that the CMMI-DEV recom-mends in the PP (Project Planning) and PMC (Project Monitoringand Control) process areas, and it serves the purpose of properlymanaging the process improvement project throughout the cycle.Chapter 6 Essays and Case Studies 127Wow! eBook <WoweBook.Com>
  • 154. The CEPG coach works closely with the process improvement proj-ect leader in the development BU to define the PIP, but the develop-ment BU ultimately “owns” the process improvement plan.An important aspect of the improvement cycle is defining how tomeasure the impact of CMMI process improvement activities. Asexplained previously, each development BU defines annual/biannualbusiness objectives and a subset of the objectives is expected to beaffected by process improvement activities. A methodology thatmeasures key performance indicators (KPIs) before the improve-ments have taken place and after improvements have been institu-tionalized was developed by the CEPG.An important aspect of this methodology is the consistency ofhow the KPIs are measured and at what points in time. Of course,this aspect also has a “rewards and recognition” component that isincorporated to provide incentives to the organization for a continu-ous process improvement methodology. An interesting result to notein terms of the benefit/cost ratio of several process improvementprojects is that ratios in the range of 3:1 to 5:1 have typically beenobserved. These results mean that for every dollar spent in a processimprovement project, the return is typically three to five dollars interms of cost savings, new market opportunities created, or revenuesgenerated by the development BU.A database that provided KPIs on the process improvement activ-ities of each product development BU was created and maintained byCEPG members. Typical KPIs included the name of the developmentBU, how many improvement cycles it had conducted, the types ofappraisals conducted, and benefit measures. This database was updatedas improvement activities were conducted at each participatingdevelopment BU.A CMMI knowledge base was also created and is organized sothat it provides a graphic perspective of improvement against CMMIPAs. The objective of this knowledge base is to store and make avail-able to all the corporation good practices implemented by the devel-opment BUs engaged in a continuous process improvement program,including artifacts such as templates, lessons learned, answers to fre-quently asked questions, and any other type of information that canbe useful to development BUs.The First StageDuring the first stage of our continuous process improvement initia-tive, the previously mentioned tools, methods, and infrastructurewere created and employed by the CEPG and participating develop-128 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 155. ment BUs. The first stage of the initiative was characterized by thefollowing important elements:1. A clear business case had to be defined and aligned with the full setof objectives of the development BU carrying out the improvementproject.2. The CEPG was then in a better position to “sell” continuous processimprovement to the development BUs.3. The commitment of a Development BU to continuous processimprovement highly depended on the local senior management’sbackground and level of knowledge in software engineering concepts.4. There was a need to continuously monitor the level of commitmentof each development BU to their improvement initiative.5. There was little need for synchronization of improvement activities,solutions, and tool usage among development units carrying out theimprovement initiative.The Second StageLater, several strategic changes were made to the infrastructure usedto support continuous process improvement at ABB: the majority ofCEPG members were assigned to development BUs and were giventhe responsibility for that BU’s improvement initiative. Concurrently,there was also a realignment in the perspective of senior managementto make the continuous process improvement initiative more global.The target of global process improvement is to significantly improvethe global reach of corporate product development practices and usecommon methods and tools where possible.TodayThe global initiative is now firmly grounded in all ABB divisions. Thedivisions directly own and sustain their improvements. CMMI con-tinues to be the primary framework used for continuous processimprovement but the focus is on ensuring attention to lower levelpractices and standard methods and tools that can be used and cus-tomized by all product development units. Internal CMMI appraisalscontinue to be conducted on a periodic basis.In summary, ABB has been engaged in a 10-year journey to con-tinually improve its product development processes. The outcomeshave continued to be good results, economic benefits, improvedmorale, and the recognition that the CMMI has been a valuable toolall along the way. Adjustments in the journey were required due toChapter 6 Essays and Case Studies 129Wow! eBook <WoweBook.Com>
  • 156. changes brought about by increased globalization of markets and theneed to increase the uniformity of process solutions, but the benefitscontinue.Leveraging CMMI and LSS to Accelerate the ProcessImprovement Journeyby Kileen Harrison and Anne PremAlthough Capability Maturity Model Integration (CMMI) and LeanSix Sigma (LSS) are often viewed as competing initiatives, contend-ing for the same process improvement funding and priorities, CMMIand LSS are actually complementary. Implementing these method-ologies in tandem can result in a synergistic effect that acceleratesand enhances the benefits of process improvement.The Synergistic EffectOne consideration for how CMMI and LSS relate is to associateCMMI with providing the “what” and LSS as supplying the “how.”CMMI identifies “what” activities are expected, but does not specifytechniques on how to accomplish those activities. Whereas, LSSidentifies “how” activities can be optimized, including specifyingtools and techniques. For example, the CMMI model can be lever-aged to conduct a gap analysis on an organization’s business practicesto determine what opportunities for improvement exist. Then, LSScan be applied to provide the organization with tools and techniquesfor achieving the necessary improvements. Because of their comple-mentary nature, leveraging the two models together can lay a solidfoundation for performance-driven improvement that accelerates anoverall improvement journey.Applying the two initiatives together encourages a balancebetween a focus on process comprehensiveness through CMMI and afocus on business efficiency through LSS. For example, in a typicalimplementation of CMMI at the managed and defined levels, thefocus is on process definition to include all of the necessary ele-ments. Then, improvement and greater efficiency is achievedthrough process maturity, which is generally associated with advanc-ing through the levels in the model over time. In contrast, LSS isfocused on efficiency and greater effectiveness from the onset of theimprovement journey. To realize the benefits of this complementarynature, Space and Naval Warfare Systems Command (SPAWAR)130 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 157. Headquarters Organizational Process Management Office (OPMO)created an approach that utilizes both initiatives, targeting discretebusiness unit challenges within the organization.Background ContextSPAWAR is one of the Department of Navy (DoN) major acquisitioncommands. The SPAWAR Command specifically procures higher-endUnited States Navy (USN) information technology products andservices for the USN fleet and other armed forces. Headquartered inSan Diego, Team SPAWAR includes SPAWAR Headquarters, two addi-tional SPAWAR Systems Centers (SSCs), three Program ExecutiveOffices (PEOs), one Joint Program Executive Office (JPEO), and oneliaison office located in Washington, D.C. In total, the organizationconsists of more than 12,000 employees and contractors deployedglobally and near the fleet.Since 2005, SPAWAR Headquarters’ OPMO, supported by BoozAllen Hamilton, has been integral in establishing a successful LSSprogram across Team SPAWAR. Although the two SPAWAR SystemCenters, focused on engineering, have been engaged with both LSSand CMMI for years and successfully achieved CMMI ratingsthrough formal appraisals, SPAWAR Headquarters’ OPMO, a service-focused business unit, began incorporating CMMI in 2008. At thattime, OPMO identified a need to integrate CMMI as a processimprovement methodology to complement the existing LSS programand the other process improvement tools and techniques they man-age and provide throughout Team SPAWAR.The ChallengeInstilling a culture of process improvement and making positiveprogress is challenging in any organization and SPAWAR is no excep-tion. The ability to gain and maintain process improvement buy-infrom stakeholders within the organization presents an immediatehurdle. Additionally, the government’s focus to do more with lesswhile continuing to meet mission objectives provides an additionalhurdle. These challenges, coupled with the desire to see tangibleresults, led to the formation of an approach that leverages both LSSand CMMI.The ApproachThe following paragraphs detail OPMO’s approach, including thefour major steps the OPMO CMMI assessment team utilizes:Chapter 6 Essays and Case Studies 131Wow! eBook <WoweBook.Com>
  • 158. 1. Identify Mission Critical Risks2. Select Relevant CMMI Process Areas3. Conduct a CMMI Gap Analysis4. Apply LSS ToolsStep 1: Identify Mission Critical RisksThe OPMO CMMI assessment team initiates the assessment of abusiness unit by leveraging information contained within a SPAWARtool referred to as the Policy, Procedures, Processes, Practices &Instructions (P4I) workbook system. Each business unit withinSPAWAR is required to update the P4I workbook at least annually.This information is used to identify the business unit’s mission, theirassociated policies and procedures, as well as any risk that may criti-cally impact their mission, thereby creating a snapshot baseline ofthe business unit’s as-is state. The assessment team leverages the riskinformation identified in the P4I workbook to identify the businessunit’s possible weaknesses or risk areas. These critical risks aremapped to an associated functional area (e.g., mail processing,records management) to identify a discrete focal area for processimprovement activities.Step 2: Select Relevant CMMI Process AreasAfter the focal area is selected, the assessment team conducts inter-views with the functional subject matter experts and stakeholders togain a better understanding of the as-is process. The team alsoreviews supporting process documentation as well as any other rele-vant assets or tools. Based on this research, the assessment teamselects the CMMI process areas that are most relevant to the focalarea. Due to the cross-functional nature of Team SPAWAR’s business,the team considers all three of the CMMI constellations (CMMI forDevelopment, CMMI for Acquisition, and CMMI for Services) whenselecting the relevant process areas.The team selects the process areas that have the strongest tie tothe specific mission-critical risks identified from the previous step.SPAWAR Headquarters does not currently require attainment of aparticular CMMI maturity or capability level. Therefore, the approachfocuses on identifying and utilizing key actions or “best practices”from the CMMI models that the business unit can implement to mit-igate their mission critical risks and improve operating efficiencies.The improvement actions that result from the best practice assess-ment assist in building or enhancing the business unit’s process132 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 159. framework, which could be leveraged to obtain a CMMI maturity orcapability level, if desired.Step 3: Conduct a CMMI Gap AnalysisNow that the assessment team has reviewed the as-is state andselected the process areas, a detailed gap analysis is conducted. Theteam leverages an evidence matrix to systematically compare the busi-ness unit’s targeted functional area’s as-is processes against the selectedCMMI process areas. As noted previously, because SPAWAR Head-quarters does not have a requirement to meet a maturity or capabilitylevel, the assessment team focuses on selected process areas toaddress mission critical risks, rather than using a full CMMI modeland appraisal methodology.Based on the gap analysis, the assessment team documents thefindings in a detailed CMMI Assessment Report. The report identifiesthe business unit’s opportunities for improvement, the team’s recom-mendations, and associated benefits. Before delivering the finalreport, the assessment team validates the findings and recommenda-tions with key stakeholders and subject matter experts from the busi-ness unit. These validation activities have proven effective in ensuringaccuracy as well as promoting stakeholder buy-in.Step 4: Apply LSS ToolsBecause the CMMI Assessment Reports are detailed and typicallycontain five to six primary process areas that translate into numerousrecommendations for improvement, the business unit typicallyrequires assistance in identifying a “starting point” for addressing theimprovement activities. The assessment team helps the business unitto prioritize these activities by using LSS tools, such as the AnalyticalHierarchy Process (AHP) and a scoring matrix. Applying these toolsprovides a quantitative basis to a task (in this case, prioritizing activ-ities) that can be qualitative in nature.The AHP is a mathematical decision making technique that lever-ages weighted criteria. Specifically, the business unit identifies fourto six criteria that are relevant to their business objectives, such asrisk or level of effort. These criteria are compared head-to-head todetermine a weight that represents the level of importance of eachcriterion. Finally, these weights are input into a scoring matrix toobjectively prioritize opportunities for improvement. Leveraging theuse of the AHP and scoring matrix provides the opportunity toinvolve the business unit in prioritization and ultimately promotesChapter 6 Essays and Case Studies 133Wow! eBook <WoweBook.Com>
  • 160. stakeholder buy-in. This objective methodology also helps build con-fidence that the most business-critical improvement areas areaddressed first.After a prioritized list of improvements is defined, the top priori-ties are reviewed to consider the best course of action. A Plan ofAction and Milestones is developed, which may include the kickoffof a LSS RIE (Rapid Improvement Event), LSS DMAIC (Define,Measure, Analyze, Improve, Control), or simply a “Just Do It.” Theas-is process documentation as well as the findings identified fromthe CMMI gap analysis activities are required inputs to the follow-onLSS events.Tying It All TogetherThe assessment team has worked with several different businessunits. The team and business unit stakeholders have experiencedvaluable results from the implementation of the CMMI and LSSapproach. One specific business unit that the assessment teamworked with is SPAWAR’s Administrative Services & Support. Theirbusiness objectives are to support Team SPAWAR through the estab-lishment of policy, guidance, and oversight for administrative func-tions including official mail, records management, directives, andcorrespondence administration.During the initial analysis activities, the team identified two func-tional areas that were associated with the business unit’s mission crit-ical risks: 1) Official Mail and 2) Records Management. BecauseAdministrative Services & Support’s focus is providing these servicesto SPAWAR, the assessment team selected the CMMI-SVC constella-tion. In the CMMI-SVC constellation, one of the process areasdeemed relevant to the Records Management functional area wasConfiguration Management. After completing the gap analysis, theassessment team identified various opportunities for improvementand recommendations in regard to Administrative Services & Sup-port’s Configuration Management activities.A sampling of recommendations includes the following:• Create and maintain one all-inclusive configuration item list of allrecords managed along with key characteristics (e.g., owner, signa-ture authority, required reviewers, expiration date, update frequency).• Clearly define the purpose and role of each records management tooland document a process for tool use.• Identify the authoritative source for managing all records and con-duct periodic audits to ensure record integrity is maintained.134 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 161. After the final CMMI Assessment Report for Records Manage-ment was delivered, the business unit and assessment team priori-tized the opportunities for improvement using the AHP and scoringmatrix in accordance with Step 4 of the approach. Based on this pri-oritized list, the Administrative Services & Support business unitcreated a LSS Rapid Improvement Plan that included the followingactivities:• Streamline the official document review process.• Streamline the official document routing process throughout theCommand.• Define a standard configuration management process and associatedbusiness rules for use of existing tools to reduce version redundancyand to identify an authoritative source for official documents.Similarly for Official Mail, in response to the highest priority rec-ommendations for improvement, Step 4 identified the need for a LSSRIE to improve mail handling processes. The LSS RIE resulted in aresolution of duplicative responsibility for mail sorting between anin-house resource and service provider. This resolution eliminated90% of the in-house resource’s workload, which allowed for realign-ment of the individual’s time to focus on reducing backlog in otherwork areas.In addition to this specific example of savings realized within theAdministrative Services & Support business unit, a few furtherexamples of benefits experienced by other business units include thefollowing:• Recommendations from a CMMI Assessment Report resulted in thecreation of process documentation that will assist with upcomingstaff transition activities, including a staff member’s retirement.• Content from the detailed CMMI Assessment Report and the priori-tized list of improvement activities were leveraged as critical inputs toa business unit’s annual strategic planning session.• Recommendations from a CMMI Assessment Report are planned tobe leveraged to improve quality of contractor deliverables and associ-ated communications.Lessons Learned and Critical Success FactorsThe assessment team has conducted multiple assessments and gainedvaluable lessons learned feedback as well as knowledge of criticalChapter 6 Essays and Case Studies 135Wow! eBook <WoweBook.Com>
  • 162. success factors. Two of the most critical challenges that the teamfaced were the following:1. Business unit acceptance of ownership for improvement actions2. Resource availability issues due to major initiatives competing forresources (e.g., Navy Enterprise Resource Planning (ERP)implementation)The assessment team deployed several techniques to overcomethe challenge of business unit ownership. After the assessment wascomplete, the business unit was responsible to charter and initiateLSS improvement events. However, these activities sometimesrequired gentle and persistent encouragement from the assessmentteam to maintain forward progress. In response, the team found thatconducting an offsite session was an effective way to build momen-tum for the improvement activities by allowing individuals to havefocused time away from their day-to-day responsibilities.Additionally, the team found that the use of a RASCI (Responsi-ble, Accountable, Support, Consulted, Informed) chart helped thebusiness unit understand the alignment of resources to roles and pro-vided clear ownership associated with each of the process improve-ment activities. To mitigate the impact of resource availability issues,the assessment team discovered that communication with seniorleadership and managing a realistic schedule were the most criticalfactors contributing to success. The assessment team kept seniorleadership informed throughout the assessment activities; their sup-port and direction were integral to the success of the project.Clear communication of the CMMI assessment goals was anothercritical success factor the team recognized. Due to resource con-straints and competing priorities, SPAWAR Headquarters determinedupfront that the approach would focus on leveraging CMMI bestpractices and not focus on the achievement of a particular capabilityor maturity level. By communicating this message early, the assess-ment team was able to pacify fears and address resistance associatedwith concern over the level of effort required to reach a particularCMMI maturity or capability level. The assessment team emphasizedCMMI “best practices” from the onset of the project to appropriatelycommunicate the scope and focus of the project to the participants.In conclusion, the sum of CMMI plus LSS does not merely equalthe combined benefits of two process improvement approaches;instead, it equals a synergistic result that improves process efficiencyand effectiveness faster. A significant factor in achieving maximum136 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 163. benefits of this approach is having participants trained in the appro-priate elements of both models and associated nuances. Getting theright resources involved and implementing an approach that lever-ages both CMMI and LSS can accelerate the realization of processimprovement benefits.EssaysThe following essays cover a variety of experiences. The first severalessays provide advice for both new and experienced users of CMMIfor Development. The fourth essay provides practical advice for hir-ing a consultant or lead appraiser. The fifth and final essay providesan essay to share with those who are not “sold” on CMMI from abeliever that once was skeptical of CMMI’s value.Getting Started in Process Improvement: Tips and Pitfallsby Judah MogilenskySo your organization has decided to embark on a process improve-ment journey. First of all, congratulations on your decision! Perhapsyour journey has been triggered by some project disaster you neverwant to repeat, or perhaps you have realized that taking the next stepup in project size and complexity will only lead to success if yourprocesses are strong enough. In any case, you are probably wonder-ing how to get started.Here’s a bad way to start, one that I call “having a process lobot-omy.” You forget any aspect of process you were doing up to now, andyou say, “We have to build everything new, from scratch.” I’ve neverseen this work. A much better approach is to recognize that any levelof project success you have enjoyed up to now has been based in parton whatever processes, however loose and informal, you have inplace. One good strategy is to have a few key people from each cur-rent project simply write down, in any form, what they are doingtoday. Gather these descriptions, noting similarities and differences.Then, convene a meeting of key project people to review the descrip-tions, identify “best practices” and “lessons learned.” (Best practiceswork; we always want projects to do these. Lessons learned are badthings; we never want projects to do these.) The results of this meet-ing will be your first documented process description. Your journeyChapter 6 Essays and Case Studies 137Wow! eBook <WoweBook.Com>
  • 164. will focus on refining this description, adding to it as gaps are identi-fied, and getting people to follow it consistently.“Well,” you say, “we’ve got very little process in place. There’salmost nothing in the CMMI-DEV model that we are doing consis-tently. Where should we start?” My suggestion is that if you reallyhave almost nothing in place, start with Configuration Management.Every process you undertake, including the writing of your processdescriptions, will produce documents, drawings, or some other arti-facts. You need to be able to keep track of these, know where theyare, know what changes have been made to them, and know what thecurrent versions are. Configuration Management helps you manageyour artifacts.Another good activity to start with is peer reviews. You will beproducing descriptions of your processes so that people can followthem consistently and so that you can deliberately and visiblyimprove them. It’s really helpful to have a peer review process docu-mented at a very early stage so that you can use it to peer review therest of your process descriptions. And later, you will find that per-forming peer reviews on the products of your projects will be reallyuseful too.What is the most important factor contributing to success in aprocess improvement journey? Anyone with experience will give youthe same answer: the strength of your sponsorship. The sponsor isthe person in the organization with the power and authority to directthat process improvement actions be taken and to provide theresources (funding and people) needed to carry out those actions.However, the strength of sponsorship is not defined just by providinga budget and saying, “Go do it.” Rather, sponsors, whether they real-ize it or not, are constantly sending three types of messages to theirorganizations: expressed (what they say), demonstrated (what theydo), and reinforced (what they reward).Weak sponsors are those who say they want process improve-ment—even loudly and publicly—but their own actions and thebehaviors that they reward (e.g., badly estimated projects that getinto deep trouble but then are saved at the end by late-night heroicefforts) show that they really do not care very much about processimprovement. The organization’s people will always, in case of con-flict, believe the demonstrated and reinforced messages before theexpressed messages.Therefore, one key role of the process group (i.e., the peoplecharged with developing and deploying processes) is to provide feed-back to the sponsor about the messages that are being sent and whether138 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 165. they are consistent. This role usually requires some up-front agree-ment, because upward feedback is not common in most organizations.What is the next most important success factor? It is an atmos-phere that encourages and fosters open and honest feedback from theprocess users. The only way to tell if processes are working well andhelping people is to get comments and feedback from those people.To keep the flow of feedback going, it is vital that the feedbackreceived be acknowledged, valued, and acted on, especially the feed-back that says “this is not working for us.” Attempts to dismiss orignore complaints will not cause them to go away, but will only drivethe complaints underground where they will be less visible and moredamaging.What are some of the pitfalls to watch out for? There are two thatseem to come up frequently: one is loss of sponsor interest, and theother is something that I call “pathological box-checking.” The sen-ior executives who generally serve as sponsors tend to live in a verybusy, pressure-filled world with short time horizons. Process improve-ment is a long-term journey with rewards that develop slowly. It isvery helpful to set up some regular opportunity, no less often thanquarterly, to meet with your sponsor to review progress, celebratevictories, identify obstacles, and provide the upward feedback men-tioned earlier. It is also very helpful to build and regularly updateyour business case, showing the benefits (e.g., cost savings, time sav-ings, better milestone performance, improved delivered quality) ofthe process improvement effort. Remember, the worse things arewhen you start, the easier it is to show improvement.The other pitfall comes about when the objective of achievingsome maturity level rating in an appraisal is seen as the primary orga-nizational goal, and anything that interferes with this goal, or puts itat risk, is seen as an obstacle to overcome. This “pathological box-checking” is different from true process improvement in that trueprocess improvement puts the primary emphasis on measurable projectperformance, measurable business performance, customer satisfac-tion, employee satisfaction, and continuous improvement. Pathologi-cal box-checking, on the other hand, views maturity level ratings asthe ultimate objectives and seeks to achieve them even if the result isnegative impacts on project performance, business performance, cus-tomer and employee satisfaction, and continuous improvement.Some of the indicators that an organization has gone over to this“dark side” are the following:Chapter 6 Essays and Case Studies 139Wow! eBook <WoweBook.Com>
  • 166. • Maturity level targets and associated dates are widely publicized anddiscussed, but there is little or no corresponding publicity and discus-sion devoted to project or business performance targets and theirassociated dates.• A lot of time and energy is devoted to determining the “minimumacceptable” process implementation that will result in a rating of“satisfied,” regardless of the process actually needed by projects orthe organization. In severe cases, organizational advocates (perhapseven lawyers) will loudly demand that the lead appraiser point out“where in the model does it explicitly say that I have to do something.”• Because the focus is on achieving maturity level targets as quickly aspossible, there is “no time” for broad participation, review, or pilotingof new processes. Instead, the processes are developed by a smallgroup, or even imported from outside, and imposed on groups andprojects with little regard for suitability or applicability. Objections tothese processes are viewed as “resistance to be overcome.” Feedbackis discouraged; again, there is “no time” to update or revise processesin response to user experiences.• After a formal appraisal, or perhaps even an informal appraisal, hasbeen conducted and a particular process is rated as “satisfied,”changes to that process are effectively (though not explicitly) prohib-ited. (“If we change it, the lead appraiser might not rate it the sameanymore.”) In this way, the stated model objective of continuousprocess improvement is essentially abandoned.• A final symptom, and perhaps the most serious one, is that effort andenergy are devoted to building a “false façade” of documents to pre-sent as evidence to a lead appraiser, documents that have little ornothing to do with the actual work being done. The sad thing is that,had an effort like this been put into genuine process improvementinstead, the organization would see actual business benefits that“box-checking” will never achieve.So this brings us to the final question, namely, “How will I knowwhen I have been successful?” Formal appraisals leading to officialmaturity level ratings (or capability level profiles) can be useful,especially if there is a need to show process progress to higher levelsof management or to customers. Even an informal appraisal can pro-vide very useful feedback, and can help make sure that the improve-ment effort has not missed something important.However, the real measure of process improvement success is theimpact on the business and the impact on its workers. In terms ofbusiness impact, look for bottom-line measured improvements in140 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 167. cost and schedule predictability, in project efficiency, and in deliveredquality. In terms of impact on workers, look for less pressure, lessovertime, more opportunity for people to have real lives outside ofwork. (One organization expressed it as “reduced late-night pizzaorders.”) For me, the beauty of process improvement has alwaysbeen that there is no trade-off between project performance anddeveloper quality of life. The only way to be truly successful is tomeasurably improve both at the same time.Avoiding Typical Process Improvement Pitfallsby Pat O’TooleWhen it comes to “process,” we commonly encounter three types ofpeople: process zealots, process agnostics, and process atheists. Thezealots see “process” as the path to engineering enlightenment—andtypically, the only path. The agnostics typically don’t know, and cer-tainly don’t care, whether “process” is a good or a bad thing—just aslong as it doesn’t get in their way. The process atheists, on the otherhand, perceive that the “p word” borders on vulgarity, believing thatprocess hampers creativity, stifles productivity, and ultimately rotsthe brain—but other than that, process is generally okay for others tofollow.One would expect that SCAMPI Lead Appraisers—or as somemight call us, “Lead Oppressors”—fall squarely in the process zealotcamp. However, after having seen too many organizations inadver-tently harm themselves through the misimplementation of CMMI-based processes, I find myself leaning toward agnostic. In this article,I will provide some insight into what I perceive to be the two mostcommon process improvement pitfalls, as well as steps your organi-zation can take to avoid them.The Alignment Principle: Defining the Word “Improvement”In my opinion, the greatest single point of failure for most improve-ment programs is the organization’s inability or unwillingness todefine the word “improvement” within their own unique businesscontext. In too many organizations, improvement is defined as“achieving Maturity Level X.” (The fact that the organization capital-izes “Maturity Level” may indicate that they are paying it unduehomage.)Chapter 6 Essays and Case Studies 141Wow! eBook <WoweBook.Com>
  • 168. Unfortunately, this misperception elevates the implementation ofCMMI-suggested practices to the level of business strategy—a role itwas never intended and is ill prepared to fulfill. A better approach isto have senior management establish a comprehensive business strat-egy and then employ CMMI as one of many tactics that enable theorganization to achieve it.A critical component of this preferred approach is the AlignmentPrinciple. Wouldn’t it be wonderful if the business strategy, projectobjectives, and improvement initiatives were all aligned? By articu-lating an organizational Alignment Principle, senior managementhelps to synchronize these three elements.An organization can use CMMI to help it become the high-qualityproducer of goods and services in their selected market segment.Alternatively, CMMI might be used to help the organization tobecome the low-cost producer, or the quickest to market, or the mosttechnically innovative, or the most environmentally friendly, or . . .Although the model can be used to help an organization achieveany of these strategic positions, the processes employed for each arelikely to be vastly different. For example, high quality producersmight have checks and balances all along the development life cycleto detect and eliminate defects as close as possible to the point wherethey were introduced, whereas the quick-to-market leaders wouldtypically have the thinnest layer of process that keeps the projectfrom spiraling out of control.Therefore, knowing the strategic position that management is try-ing to achieve for the business is a critical prerequisite to establishingand maintaining processes that will help the organization achieve it.Left to their own devices, an Engineering Process Group (EPG) willbuild “CMMI-compliant processes.” However, given proper directionand motivation from senior management, those same processes willbe honed to meet the organization’s strategic business objectives.After all, as long as the EPG is going to the trouble of establishing aprocess infrastructure to achieve maturity level X, wouldn’t it be niceif they actually helped the organization accomplish its strategic mis-sion while doing so? (For some, this question borders on insightfulrather than rhetorical.)It seems fairly obvious that if your firm manufactures pace mak-ers, “quality” is the attribute to be maximized. When your primarymetric is the “plop factor,” you are usually willing to overrun a bit onschedule and cost to reduce the number of field reported defects—especially those reported by the relatives of your former customers.142 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 169. But you’d be surprised by how few executives can articulate aclear strategy and how little time they invest trying to do so. Myfavorite consulting engagement of all time stemmed from my firstpresentation at a major industry conference. After the talk, I was col-lared by an executive from a 300-person company who asked if Iwould be willing to facilitate a session in which his company wouldestablish their Alignment Principle. He suggested a three-day offsitemeeting in which his boss, the CEO, and the top nine executives inthe organization would participate.After I agreed to help him out, he brought up one little problem—the CEO doesn’t listen to consultants! Unfazed, I informed him that Ihave a way to overcome such an issue—I simply triple my consultingrate. I’ve determined that if you charge enough money even thebiggest of bigwigs has to listen!To start the session, I spent 15 minutes explaining the basic con-cepts of the Alignment Principle. I then handed each of the 10 atten-dees a blank index card and asked them to write a single word on thecard—”Faster,” “Better,” “Cheaper,” or some other word that bestdescribes the most important attribute for the organization’s productsand services.I collected the cards and was dismayed to find 3 cards read“Faster,” 3 “Better,” 3 “Cheaper,” and the last card—the one from theCEO (OK, I kept hers separate) —read “Innovative.” After sharingthe results with the group, and finding myself somewhat uncertain asto how to proceed, I suggested that we refill our coffee cups.During the break, the CEO asked if we could speak privately.When we were alone she informed me that my services were nolonger required. She said that the exercise pointed out that her Lead-ership Team obviously did not understand the direction in which shewas trying to take the company. Because she had them offsite forthree full days, she would invest the time in rectifying this situation.Rather than having a session facilitated by “one of you consultants,”she felt that it was necessary for her to demonstrate leadership bytaking ownership of the meeting’s successful resolution.As she bid me farewell she concluded with “. . . and please submityour invoice for the full three days; I will make sure that you are paidpromptly.” Nine days of pay for about a half hour of work—it don’tget no better than that! But I digress . . .Suppose your senior management, like that of the pace-makercompany, has just informed you that quality as defined by customer-reported defects is the single most important competitive dimension inthe minds of your customers. It’s time to craft the Alignment Principle:Chapter 6 Essays and Case Studies 143Wow! eBook <WoweBook.Com>
  • 170. “Achieve an annual, sustainable X% reduction in field reported defectswithout degrading current levels of cost, schedule, and feature variance.”Now the projects know what is most important to senior manage-ment, and the EPG knows what it means to help the projects“improve.” It’s not that cost, schedule, and functionality aren’timportant; it’s just that they are not deemed as critical as customer-perceived quality. And now the EPG can build a process that helpsmove the organization in that strategic direction.Avoiding Reverse Exploitation: Focusing on PerformanceAfter you’ve addressed Pitfall #1—lack of alignment—you’ll find thatyou’ve simply promoted Pitfall #2—focusing on “implementing themodel.”The mantra of process agnostics and atheists is “process = admin-istrivia,” and in some misguided organizations, they’re right! Onemight gain insight into the real problem in such organizations by dis-tinguishing among three related concepts: process, process docu-mentation, and process model.The process is the way that work is actually being performed ontoday’s projects. It is nothing more or less than the day-to-day activi-ties carried out by the developers, testers, project managers, and soon as they do their jobs. To say that you are “process adverse” is tocontend that all project activity should stop and, unless you’re likeWally from Dilbert, this is not a position that most people wouldadvocate.The process documentation is the infrastructure being provided tothe projects to help them perform their work in a consistent manner.It’s the stuff sitting on the proverbial shelf just waiting to beemployed by the projects—process descriptions, procedures, guide-lines, templates, forms, metrics, checklists, tailoring guidelines, goodcase examples, and so on. It should provide the projects with a robustset of materials that enables them to conduct their work in the mosteffective and efficient manner (well, at least in theory!).Finally, the process model, in the current case, the CMMI model, isa collection of good practices that can be exploited by the organiza-tion to heighten the probability of achieving success—where successis defined by the Alignment Principle and project-specific customerobjectives. Please note the direction of this exploitation—the organi-zation should exploit the model and not, as too often happens, theother way around.144 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 171. How does one avoid reverse exploitation? Let me make threesuggestions.• Recognize that the current projects are enjoying some level of suc-cess. Some of them have actually completed and shipped products,right? Some of their customers are reasonably pleased with the workthat the projects performed on their behalf, aren’t they? Responding“yes” to either question implies that the existing processes (i.e., exist-ing project activities) are working fairly well. The organizationshould not abandon everything they are currently doing to imple-ment some goofy model just because they are trying to achieve somearbitrary “Maturity Level” (note the caps). Rather, they should deter-mine how best to integrate some of the model’s more value-addedpractices into their existing processes and process documentation toenhance project performance.For some organizations, a “find-the-pain, fix-the-pain” approachmay be best to kick-start the improvement effort. This approach usesthe model like a medical reference guide for addressing chronic proj-ect pain. Applying a bit of process aspirin makes a lot more sensethan hitting people over the head with a 500+ page book like this andtelling them, “Trust me. This is really good for you!”• To avoid religious warfare among the process zealots, agnostics, andatheists, abandon the term “process improvement” in favor of theterm “performance improvement.” It’s hard for even the most radicalprocess atheist to argue that improving project performance is a badthing.• The EPG (retitled from Engineering Process Group to EngineeringPerformance Group), should change its focus to align with the newname. Rather than obsessing on higher maturity or capability levels—appropriately spelled with lowercase letters—the EPG should focuson helping the projects achieve ever-higher levels of success. Focus-ing on project performance may not be the quickest path to maturitylevel X, but it is a sure-fire way to overcome project resistance andactually build momentum and, dare I say, excitement for the improve-ment initiative.SummaryNow that you’ve addressed pitfalls #1 and #2, you’ll find that you’venow promoted pitfalls #3, #4, #5, . . . Truth be told, there is anunlimited number of pitfalls to avoid or overcome as you traverse theongoing path of performance improvement (most of which, unfortu-nately, are of your own making).Chapter 6 Essays and Case Studies 145Wow! eBook <WoweBook.Com>
  • 172. Someone could write a rather voluminous book describing waysthat you could improve project performance. Hold on a second—they already did and you’re holding it! Although reading and under-standing the model itself is a good start, you also need to recognizethat writing process descriptions, procedures, templates, and so on isthe easy part; doing so in a way that provides value, and getting peo-ple to change their behavior as they adopt these new process ele-ments is the really tough part. Just because you build it does notmean they will come!You are strongly encouraged to learn and steal shamelessly fromthose that have gone before, and are even more strongly encouragedto contribute your experience to the growing body of knowledge forthose that are yet to come. Enjoy the journey; the rewards are worthit—provided you don’t mess it up!Ten Missing Links to CMMI Successby Hillel GlazerStarting out with CMMI can be particularly daunting to individualsand organizations who don’t know what they don’t know aboutCMMI. Often, they set out not knowing they’re missing a few bits ofinformation that could make their journeys less arduous and possi-bly enjoyable. Absent these bits, people find themselves struggling toincorporate CMMI into their work. Between bouts of bashing theirheads against the wall, they often find themselves blaming CMMIitself (or some personification of CMMI such as their consultant orlead appraiser), believing there’s something clearly “wrong” with themodel. Hint: It’s not the model.Whether it’s good or bad luck, or some other characteristic ofnature, I have had the privilege of working with many companiesjust starting out with CMMI for the first time. These companies(large or small, traditional or Agile) don’t know what to expect andthey don’t really understand what using CMMI is all about.If you are just starting out with CMMI, consider yourselves lucky.You don’t have as many bad habits or history to undo. Those experi-enced with CMMI might find themselves reaching for theExcedrin—realizing, for the first time, the “missing links” to theirCMMI challenges. Below, the rather unorthodox approach to usingCMMI has resulted in lasting, positive effects.146 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 173. I must acknowledge my thorough appreciation for the competi-tive nature of organizations vying for attention and business fromcustomers expecting to see some sort of CMMI “rating” (e.g., “Matu-rity Level 3”). This is reality. It’s a destructive and counterproductivereality because it can cause organizations to pursue CMMI ratings atthe expense of people, productivity, and profit. How silly is that? Thepurpose of incorporating CMMI into your work is to provide a sys-tematic mechanism to improve performance. Increasing overhead,decimating morale and lowering productivity are not “performanceimprovements.” Consider this your first missing link.Missing Link #1:CMMI improves performance. Find aspects of your development opera-tion that can stand to improve in terms of time, cost, and quality, andCMMI will make more sense.Given that CMMI is a framework to improve performance, itstands to reason that success with CMMI comes more easily to thoseorganizations who want to improve, can identify aspects of theiroperation they’d like to improve, and have the culture and leadershipto make appropriate changes to facilitate such improvements. Organ-izations resistant to change (even beneficial changes), who have aculture of blame and mistrust, and whose idea of “measures” startsand ends with top-line sales, are going to find it difficult to use or seeany benefit from CMMI. The right culture and leadership will causethe organization’s behaviors to align well with CMMI goals. Organi-zations with the “right” culture and leadership find themselvesachieving CMMI ratings without having to think about it.Missing Link #2:CMMI alone will not make things much better. For CMMI to work well,it needs: (1) a culture of learning, empowerment, and trust, and (2) lead-ership with the courage, vision, and direction to eliminate the fear oftenaccompanying changes.CMMI is unlike any other body of work out there. It’s different inhow it’s supposed to be used, in how we determine how well it’s beenused. What makes for success with other bodies of work does notnecessarily work well with CMMI.In many parts of our work and personal lives, when we see a vir-tuous thing to do, we often find ways to adopt it into our daily lives.At first, it takes a conscious effort to get it going; then, if we like it,after awhile it becomes second nature. In fact, we’ll naturally findChapter 6 Essays and Case Studies 147Wow! eBook <WoweBook.Com>
  • 174. ways to keep doing it and improving what it is that we’re doing. Inmany ways, CMMI is a lot like this, but in some important waysCMMI is different.Many organizations misconstrue CMMI practices as achieve-ments in and of themselves rather than enablers of long-term results.In other words, they make the purpose of incorporating CMMI prac-tices the presence or absence of the practices rather than the businessbenefits of the practices. Using personal health as an analogy, it’s likesaying, “Hey! Look at me! I’m eating lettuce! Ignore the cup of bluecheese dressing. I’m eating lettuce!”Missing Link #3Don’t make it about CMMI. Your efforts with CMMI are to help youimprove your business. CMMI practices are not the ends; they’re themeans to the ends.CMMI is full of practices. Practices are not processes. Practicesare activities that improve processes wherever, whenever, and how-ever they may appear in your organization in reality. In fact, it’s prob-ably just best to stop thinking about processes entirely. Processesconfuse people. Just think about your work. That leaves us with ask-ing questions like, “What can we do to make our work better?” Youcan’t actually build anything by following CMMI. There simply is notenough stuff in it that you can actually follow along to run youroperation. You need to have some sort of work flow that works foryou first, and then use CMMI practices to improve it.Missing Link #4Know your work. Know how you get stuff done. Then, look into CMMIfor ideas on where and how to improve how you get stuff done. That’swhat CMMI’s practices are for—not to define your work, but to refine it.Speaking of practices, there’s frequently much confusion over thecoincidental similarity in the names of CMMI process areas to vari-ous aspects of how work commonly gets done. The names by whichyou refer to activities in your work flow may also be words used inCMMI. These activities may be specific tasks, supporting work, oreven steps in your development lifecycle. This coincidence does notmake everything in CMMI part of your lifecycle. That many activitiesyou do are already in CMMI is testament to the fact that the CMMI isfull of smart things to do (and yet there are companies out there thatdon’t do them). However, the converse is not true. If something is inCMMI that you don’t think you do, it does not mean that you must148 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 175. work them into similarly named parts of your work. More impor-tantly, each practice is an opportunity to leverage activities towardimprovement. That they exist in CMMI is more about the role suchactivities play in improvement, not in defining how work is beingdone.Missing Link #5Don’t confuse the names of CMMI process areas with processes you mightbe using. What separates your conduct of a practice from its appearancein CMMI is a question of whether you’re leveraging that practice toimprove your work.Do not pass go. Do not collect $200. Do not even begin to workwith CMMI until you completely understand the role and limitationsof models, how models are used, and the sort of model that CMMI is.All models share certain inalienable characteristics. Foremost is thatthey’re all fake. They’re not the real thing. They’re mere representa-tions of reality, which does not make them real. A horse might have5m2 of surface area, but to model the horse we’d probably just repre-sent her as a sphere, cube, or box with 5m2 of surface area— depend-ing on the application we’re planning to use her in. Horses aren’tspheres, but for many models, spheres are good enough.Good models help us understand complex ideas, test them, andavoid cost and/or danger compared to trying these ideas in the realworld. Models are also used to build other things, like object modelsin software. CMMI is a model for building process performanceimprovement systems. As such, the model isn’t the improvement sys-tem, it’s just a list of characteristics that you use when building yourimprovement system. To describe these characteristics, the modelincludes examples and other narrative content to inform us of what’smeant by the terse summary of characteristics. Then, when bench-marking against CMMI (e.g., in a SCAMPI), what’s being investigatedis how many of these characteristics your improvement system hascompared to the ones listed in the model. The names of the modelcharacteristics in CMMI are goals and practices.Missing Link #6CMMI is a model for building improvement systems. Goals and practicesin CMMI are the characteristics that help us know whether our system isconsistent with the model, and all the “informative” material helps usunderstand what’s meant by the goals and practices. Think: Thousands ofwords in lieu of pictures.Chapter 6 Essays and Case Studies 149Wow! eBook <WoweBook.Com>
  • 176. Earlier I alluded to an experience many of us have shared: thenotion of working on bringing some virtuous behavior into our lives,then growing with it until it becomes second nature. CMMI is aboutimproving performance, and we’d eventually like improving per-formance to be second nature to our work. CMMI provides a system-atic way of doing just that, called generic practices. Generic practicesare CMMI’s way of helping organizations systematically makeimprovement practices part of everyday work.At first, you need awareness of the practice(s) and with thisawareness usually comes some level of accountability. Typically, wemake sure someone knows what needs to get done; much like start-ing a health program by “just doing it.” Then, when “just doing it”doesn’t cut it, we need to think about it; we’ll start to plan ahead,think things through, set aside time and resources, put in checks andbalances, get others involved, and get more organized. In otherwords, we “manage” it; same with the practices in CMMI. As we geteven more refined, we’ll come up with better definitions for ourselvesso we can compare how we’re doing to some prior experience. Youknow the saying, “that which is measured is improved”? It’s true.Missing Link #7Generic practices are CMMI’s way of helping you make performanceimprovement practices second nature. They’re not intended to be separateand unique activities and they’re not the same as what you do to makeyour products. They’re what you do to ensure that the way you wantthings done shows up every day as “business as usual.”OK, so this next “missing link” may be a bit controversial, but it’salways worked for me and my clients. When you recognize and applythis thinking, you can avoid all sorts of heartburn. CMMI is easiest touse for experts. In fact, if you think of CMMI’s “maturity levels” asfollows, it might actually start to make sense:Put a project management professional and a configuration spe-cialist to work together on a project, and they’ll naturally generatepractices of maturity level 2. Add an organizational change profes-sional and an experienced engineer to these two, and much (ifnot all) of maturity level 3 will show up for the team. Add a processmodeler and a statistical expert to this high-powered team and itshouldn’t be surprising to see maturity level 4 and 5 behaviors appear.150 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 177. Missing Link #8Pursue the internal capabilities of project management, engineering, andother described experts and you’ll discover the origins of many of theinnate features of CMMI. Until you’ve grown those capabilities, youmight want some help.Many failures en route to realizing benefits with CMMI can betied to not seeing the complete picture of the organization’sprocesses, how they work together, and how they operate on all proj-ect, product, and supporting activities simultaneously and over time.They see very narrow, shallow, and temporary views of theirprocesses, and they often fail to connect their processes to organiza-tional norms, culture, behaviors, or business performance. To com-plete the picture, define an architecture for your processes, includinga taxonomy that characterizes the type of work you do and the typesof process components (e.g., process descriptions, procedures, guide-lines, measures, templates) that you will use to add discipline to yourprocess improvement journey. How much sense does it make to bead hoc in how you pursue improvements?Missing Link #9A process architecture and common taxonomy are needed so that you cancommunicate consistently about your processes, and so that you experienceyour process as a solution to how you get stuff done. Your processes don’thappen in a vacuum or in a different dimension of reality by other people.Treat your process solution using systems thinking and all that it entails.Understand the origin of CMMI. Specifically, that CMMI has itsroots in Lean, TQM, and high performance cultures. CMMI is a sys-tematic, measurable guide to installing the many attributes of theseroots. The existence of a guide against which measurable progresscan be made does not obviate the validity of the basics. Creating sucha guide is not easy, and following it might be tricky, but that doesn’tmean you need to be overwhelmed by it. In fact, if you go back to thebasic Values, Principles, and Practices of Lean, TQM, and high perform-ance cultures, there’s almost nothing in CMMI that will thwart you.Missing Link #10Start with the basics. Get grounded—firmly—in what Lean, TQM, andhigh-performance cultures are all about. Become experts in Lean SystemsThinking, TQM, empowered organizations, and value. CMMI will follow.I hope these missing links will help you find and complete otherlinks of your own. If I were pressed for a summary of these missingChapter 6 Essays and Case Studies 151Wow! eBook <WoweBook.Com>
  • 178. links it would be this: Recognize the psychology and the engineeringin performance improvement. Take them both seriously and you’ll befine. Take either lightly and you’ll face an uphill struggle.Good luck on your CMMI journey.Adopting CMMI: Hiring a CMMI Consultant or Lead Appraiserby Rawdon Young, Will Hayes, Kevin Schaaff,and Alexander StallMany organizations embarking on process improvement initiativesdiscover that anyone can be called a consultant. There is typically notest, no accrediting organization, or governing body to guide consul-tants’ actions—a person can simply open a business and start provid-ing services.Many organizations have learned the hard way about the widerange of expertise available. There are differing levels of competence,specialization, and experience. A consultant that is competent in onediscipline (e.g., software engineering) or domain (e.g., accounting)may have relatively little to offer in another discipline (e.g., hardwareengineering) or domain (e.g., embedded). The experience of individ-uals offering consulting services must be carefully considered beforeinviting one of them to help steer the improvement program of anorganization. A bad choice can be very costly, have long-term effectson the viability of the program, and affect the credibility of the lead-ership in an organization.In this essay, we identify some areas to emphasize when consider-ing prospective consultants and lead appraisers. Our intent is to helpmaximize the chances that you will hire a professional who can helpyou achieve your performance goals as well as your goals for processimprovement. This essay is based on our own personal experiencesas process improvement professionals, as well as observations madeduring the conduct of quality activities for the CMMI Appraisal Pro-gram at the SEI.Experience Drives Success“You can’t teach experience.”—Coaching adageExperience is perhaps the single most important characteristic ofeffective CMMI consultants and lead appraisers, and the one thattypically distinguishes a particular professional from his or her col-152 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 179. leagues and competitors. The content of CMMI constellations andappraisal methods can be gained from careful study of the modeldocuments and through training. However, a real understanding ofhow they are beneficially applied, and the value that an organizationcan gain from using them comes from understanding organizations,typically as a result of actually having done that type of work.But what is experience? By itself, a count of the number of yearssomeone has done something is not sufficient. When looking for anoutside expert to help you achieve your performance goals, we havefound that the breadth of an individual’s experience is usually morehelpful. Has the professional gained experience by working in orwith different organizations, perhaps in different roles? Or, has all ofhis or her experience been in the same organization, or the same typeof work? Stated simply: “Does the person have X years of experience or1 year of experience X times?”With broad experience, the consultant has a better understandingof how different kinds of organizations work. This greater repertoireaids in diagnosing issues as well as determining a variety of potentialsolutions. Insight about the drivers within an organization—theunderlying pattern of incentives and disincentives—helps in derivingcustom solutions to problems. Drawing on a breadth of experience,the consultant or lead appraiser is able to see a greater variety of pos-sibilities and can foresee a variety of plausible patterns of futureaction in the organization.Reliance on a narrower range of experience can lead to force-fitting a specific solution because it has worked so well in the past; itmight even be used as a selling point for the consultant’s business.We have encountered many professionals with “the solution.” Veryoften, “the solution” is based on the techniques they have seenimplemented several times within a single organization. Because theyhave only seen it done in a very narrow context, the approach tendsto be less flexible.Many of these professionals have worked hard to develop “thecomplete solution” with templates, tools, and training prepackaged andready to be delivered to the next client. Tailoring this type of solutionis often difficult and can result in experimentation that translatesinto significant effort and risk to the process improvement objectives.Lead appraisers with narrower experience often struggle with imple-mentations that are unusual or different from what they have seen inthe past. Because of this, appraisal teams can arrive at findings thatunderstate the true achievement of the organization, or miss weak-nesses that represent significant barriers to achieving performanceChapter 6 Essays and Case Studies 153Wow! eBook <WoweBook.Com>
  • 180. goals. In the extreme case, a team may identify something as a weak-ness because it is different than what the lead appraiser has seen inthe past, or different than “what the model says.”Remember though that there is a tradeoff of breadth versus depth.As the aphorism goes, “A specialist knows more and more about lessand less until he knows everything about nothing and a generalist issomeone who knows less and less about more and more until heknows nothing about everything.”How Do We Find the Professional We Need?The following is advice you should consider when selecting leadappraisers or consultants to help you determine if they have the req-uisite mix of breadth and depth of experience.You are looking for both breadth and depth of experience.Breadth comes from working with a variety of different systems,domains, platforms, services, acquisition types, and so on. With thisbreadth of experience, professionals will have seen a variety of solu-tions in a variety of situations and thus the tool box of solutions (forconsultants) or capability of interpretation (for lead appraisers) theybring to help you is greater than one of less breadth. Depth of experi-ence comes from working hands-on through the entire lifecycle. Forexample, have they done requirements, design, build, test, and deliv-ery of engineering products and managed projects that did the same?In other words, have they done those things you are hiring them tohelp you improve or to evaluate against CMMI?You are looking for someone who understands the work yourorganization does. It is possible that you will not always be able tohire a consultant who has experience in what your organizationdoes. In these situations, you should hire someone that understandsyour business. Do prospective lead appraisers or consultants under-stand the kind of work you do? Do they understand the language ofyour business, and not just process improvement or appraisal lan-guage? In other words, if you are an accounting company, can theconsultant or lead appraiser speak cogently and coherently aboutaccounting services? If you develop products using Agile methods,does the consultant or lead appraiser understand the concepts ofagility? A good consultant or lead appraiser doesn’t necessarily haveto be a CPA, a Scrum Master, or a certified expert in your specificdomain. However, if you find yourself teaching them an entirely newlanguage or explaining the nature of the competitive market inwhich the company operates, you should consider the possibilitythat they do not understand your business context and may have adifficult time developing an effective solution for your organization.154 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 181. You are looking for someone who balances process improvementand model compliance. When talking to prospective consultants orlead appraisers, try to get an understanding of how they balanceprocess improvement and model compliance. Do they recognize thatthe process implemented should reflect the work actually beingdone, and that it should provide positive value to either the per-former of the process or to the larger project or organization? Dothey understand that changing an organization can be very difficultand time consuming? How can they help you institutionalize theprocess and not backslide? Key areas of discussion could be buildingvisible and active senior management support, instilling ownershipof the process in those required to follow it, identifying conse-quences for not following the process, identifying rewards forimproving the process (not for simply following the process), remov-ing excuses for not following the process, and documentingprocesses to the level of granularity you need to ensure they are con-sistently followed.Beware of consultants and lead appraisers who overemphasizecompliance with the model or the standard. A template of “the stan-dard process” that requires little input from projects and staff, a sin-gle documented process for all types of projects, or the developmentof work products simply because “the model says you have to” arenot conducive to obtaining value. Worse, they can actually have anegative impact on the success of the organization both in terms ofimprovement and business objectives. George Box has a quote thatsummarizes this point nicely, “All models are wrong, some modelsare useful.” Consultants that are unable to help you see the valueproposition from the business perspective, or lead appraisers unableto explain the business consequences of a weakness and can only relyon the model, may have insufficient grounding in your context.On follow-up questions with candidates, try to determine how flex-ible they are in their process improvement philosophy. Will they insiston remaking your organization to reflect their solution, or are theywilling to change their solution to meet the needs of your business?You are looking for someone who will provide some suggestedguidance on how to evaluate your processes effectively. At somepoint, an organization that undertakes process improvement willprobably want (or require) some level of evaluation of how well theyhave done, whether it be a formal benchmark like a SCAMPI A, or aless formal evaluation of strengths and weaknesses. Lead appraisersor consultants should at least have some approach to these events.Do they view appraisal results as the end goal or as a way to indicateChapter 6 Essays and Case Studies 155Wow! eBook <WoweBook.Com>
  • 182. where you can improve? Is their emphasis on improving the per-formance of the organization or do they focus solely on achievingappraisal results? For lead appraisers, particularly, the ability toexplain, with appropriate linkage to business drivers, why an appraisalis valuable to an organization indicates that they have an understand-ing of how organizations can use appraisals to drive improvements,and not just produce numbers for use in proposals. Similarly, theability to recognize that not all implementations are identical—sometimes even in the same organization—can mean the differencebetween a successful, value-added appraisal and a simple exercise toproduce a rating number.You are looking for someone who will provide more than just a“level.” None of this is to say that achieving a maturity or capabilitylevel is not a worthy goal, but if “Maturity Level x” is the only goal ofthe consultant you are considering hiring, be aware of the potentialimpact. You may well achieve the goal (almost any organization canbe forced to change behavior for a short time), but your performanceprobably won’t increase and may in fact decrease. It is also likely thatthe changes won’t be institutionalized (i.e., they won’t become thehabit of the organization) and they will quickly disappear as theorganization reverts to its old behaviors after the appraisal.You are looking for someone who understands the realities ofprocess improvement. Finally, it is usually worthwhile to ask prospec-tive lead appraisers or consultants some questions regarding theirexperiences related to developing, implementing, and following pro-cesses. These questions can provide insight into how well theyunderstand the realities of process improvement. Consider using thefollowing questions:• Describe situations in the past where you have actually developedprocesses for an organization.• Were those processes ever appraised? If so, with what results?• Have you ever worked in an organization that followed the processesyou helped to develop? Have you followed these processes?Conclusion—Your Mileage May VaryOf course, no one can guarantee that an organization will trulyimprove or always derive value from the use of model-basedimprovement simply because it hired a particular external profes-sional to help along the way. Many other factors affect processimprovement initiatives, such as senior management support, theallocation of organizational resources, and the willingness of the156 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 183. leadership in the organization to accept changes—all must beaddressed to have a successful improvement effort. However, theright external expert can greatly facilitate the solutions to these com-plex issues and enhance the likelihood of success.When seeking to engage an external professional, always remem-ber these two things:1. It’s not just knowing the content of the model or the method; it’sknowing how to apply them to a real organization in its context thatresults in real, valuable process improvement.2. Past application and experience in multiple contexts helps increaseassurance that a consultant or lead appraiser can help you imple-ment a solution that is effective in your situation. A lot of people cando it right once in a specific context, but no two organizations areever the same; the ability to see the issues from a variety of pastexperiences is important.Model content and method structure can be taught and repre-sented in diplomas and certifications, but you can’t teach experience.If the only way consultants or lead appraisers can explain their serv-ice is by quoting phrases or content from the model or method, pro-ceed with caution. At the end of the day, it’s your organization andnot theirs that is trying to improve, and process improvement isabout competitive advantage, not “checking boxes.” If you chooseyour process consultant or lead appraiser wisely, set measurableobjectives, fix real problems relevant to the business of the organiza-tion, and demonstrate added value, your process improvement pro-gram will be sustained and your efforts will be successful.From Doubter to Believer: My Journey to CMMIby Joseph MorinIt was an honor to receive the invitation to contribute an essay forinclusion in this third edition of the CMMI for Development book. Itwas also somewhat ironic considering that I had mostly avoidedinvolvement with the Process Program1 during my tenure at the SEIChapter 6 Essays and Case Studies 1571. The Process Program (now called the Software Engineering Process Management program)is the SEI group that serves as the steward of CMMI and that focuses its work on helpingorganizations improve their processes as a way of reaching their business objectives.Wow! eBook <WoweBook.Com>
  • 184. in the late 80s and early 90s. On the other hand, it now seems appro-priate because I have become an outspoken process advocate andenthusiastic contributor to the evolution of the models and appraisalmethods over the 16 years since Integrated System Diagnostics wasspun off from the SEI as one of its original transition partners.2 Iguess it is true that converts to an idea become its most enthusiasticpromoters.Like many from my generation, involvement in computer scienceand software engineering was ancillary to my original career objec-tives. After graduating from Caltech in 1973 with a degree in Astron-omy and Physics, I had the enviable opportunity to work as part ofthe research group responsible for the first three small astronomysatellites.The mission was to identify and study sources of X-Ray emissionscoming from objects in space. To do that, we needed to develop systemsand software for the real-time command, control, and communicationof the satellites and the on-board instrument packages. The groundbased part of these systems utilized computers from Digital Equip-ment and Data General requiring a mastery of their unique operatingsystems, assembly languages, and communications interfaces.We also needed to develop back-end data reduction and analysissystems to extract and understand the scientific data coming fromthe instruments. These systems involved programming in Fortranand PL/I and becoming an expert in the JCL needed to manipulatethe IBM 360/195 at Goddard Space Flight Center as a single usermachine from Friday evenings through Monday mornings.Those were exciting times from the research perspective. Weidentified many more X-Ray sources than we had anticipated and ourwork in understanding them led to the first experimental support forthe existence of black holes. That said, and much to my surprise, Ifound myself drawn more and more to the challenges of developing,operating, and maintaining the systems and software than to thoseassociated with the science.When the opportunity presented itself to join some of my oldclassmates at Intermetrics, a Cambridge, Massachusetts startupfounded by the developers of the guidance, navigation, and controlsoftware for NASA’s Apollo spacecraft, I enthusiastically made thecareer change. As had been the case in my field, computers and soft-ware were becoming increasingly important in many mission and158 PART ONE ABOUT CMMI FOR DEVELOPMENT2. An SEI transition partner is an organization that licenses SEI products to deliver services toclients.Wow! eBook <WoweBook.Com>
  • 185. life-critical systems. Computers and software were also becomingincreasingly complex.Improved methods, tools, and techniques for software develop-ment and maintenance were a need recognized by policy makers atthe highest levels of the U.S. government as well as by developers “inthe trenches.” Intermetrics contributed to meeting that need throughthe development of programming languages, compilers, and supportsoftware environments for NASA, the U.S. Navy, GM’s automotiveelectronics division, several telecommunications companies, and anumber of computer manufacturers.As we developed systems for these customers, it seemed only nat-ural that we should try to apply best practices to our own work. Weadopted the principles and best practices advocated by Fred Brooksand Harlan Mills. We applied some of the empirical techniques com-ing out of Victor Basili’s group at the University of Maryland and usedTerry Snyder’s Rate Charting technique to track our progress andcommunicate with management, customers, and other stakeholders.We actively participated in the R&D and industry standards com-munities to identify, pilot, and deploy innovative technologies in theperformance of our work. It was through this latter activity that I wasafforded the privilege of meeting and interacting with a number ofthe people who would later emerge as key players in the foundingand evolution of the SEI and later the CMMI Product Suite. At thetime, these colleagues were brought together through the DoD Soft-ware Initiative program, which included the development of the Adaprogramming language and lifecycle support environments that weredesigned to enforce engineering discipline.Some years passed before I joined the SEI and had the opportu-nity to reunite with these respected colleagues. My career haddiverged into other niches of computer science and my managementresponsibilities increased, working in several more startup compa-nies and doing some independent management and marketing con-sulting for other companies or their venture capital investors. Thetechnological aspect of the work remained fascinating, but the newcareer direction for me was the challenge that executive managementfaces in meeting business or mission objectives.I had seen many good ideas and technologies fall by the waysideor undergo a meteoric rise and fall as a fad. To be successful, organi-zations need to understand the market and accommodate the wantsand needs of stakeholders, including those with competing ideas ortechnology. Sound plans for piloting and rollout are as important assound plans for development of systems and software.Chapter 6 Essays and Case Studies 159Wow! eBook <WoweBook.Com>
  • 186. Clear communication of achievable expectations within pre-dictable schedule and cost constraints is critical for investors, seniormanagers, developers, and customers alike. Appropriate training andresources are required to allow personnel to effectively accomplishtheir roles. Objective measures of quality, progress, and success needto be defined, collected, analyzed, and communicated in ways thatenable timely corrective actions and provide a factual basis for keybusiness decisions. All of those factors and others need to be bal-anced and coordinated to achieve the business objective.When I received an invitation to join the SEI and work on theseissues as part of the Institute’s technology transition mission, Ieagerly accepted. Groups within the Institute were generating manypromising technical ideas. Priscilla Fowler, John Maher, and CecilMartin were assembling a body of knowledge for successfully manag-ing change in the transition and adoption of innovative technology.I was thoroughly enjoying applying that body of knowledge inhelping the SEI move its ideas into practice with early adopters, par-ticularly in the area of domain-specific system architectures. I wasaware of the work in the Process Program but had a lingering preju-dice that “real” developers and seasoned managers did not need to betaught what seemed to be common sense presented in broad brushterms.That viewpoint changed dramatically when I was recruited to bethe executive manager in establishing ISD as an SEI spinoff to com-mercialize the SCE appraisal method. Before I knew it, I was drawninto my first rounds of CBA-IPI assessments and SCE evaluations,predecessors of today’s SCAMPI appraisals.I quickly developed a new appreciation of the model and of thevariations in practice implementations across diverse organizations. Irealized that my earlier perceptions were woefully misguided. Theoverall state of the practice was not characterized by the relativelysmall groups of “heroes” working to implement a clearly sharedvision in the startups or R&D centers with which I was most familiar.What had appeared to be common sense was indeed its own exten-sive body of knowledge that needed to be codified and deployed inthe same fashion as the technologies it enabled.Working with organizations to help them improve their processeshas not always been a smooth or easy endeavor. The CMMI ProductDevelopment Team deserves special recognition for persevering inthe evolution of the model. They have had to reconcile and harmo-nize myriad viewpoints on what best practice is and how to describeit without being prescriptive. They have weathered uncertainties in160 PART ONE ABOUT CMMI FOR DEVELOPMENTWow! eBook <WoweBook.Com>
  • 187. funding, aggressive schedules, and changes in emphasis directed bycommittee.They have overcome those and other challenges and obstacles toproduce a work that can benefit us all. I can attest to those benefitsfirst hand in small organizations applying Agile and Six Sigma tech-niques in attaining maturity level 5 capability and in large bureaucraticones more slowly improving predictability and performance as theyimplement managed and defined processes across the organization.I encourage you to realize the benefits in your own organization.And for those of you with doubts like me in my earlier days, Iencourage you to take a fresh look at what you can gain from thiswork. I believe that you will find, as I have, that the model capturesmuch of your hard earned knowledge in a way that allows you toeffectively communicate and apply that knowledge in improving theperformance of your organization.Chapter 6 Essays and Case Studies 161Wow! eBook <WoweBook.Com>
  • 188. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 189. PART TWOGenericGoalsandGenericPractices,andtheProcessAreasWow! eBook <WoweBook.Com>
  • 190. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 191. GENERIC GOALS AND GENERIC PRACTICESOverviewThis section describes in detail all the generic goals and generic prac-tices of CMMI—model components that directly address processinstitutionalization. As you address each process area, refer to thissection for the details of all generic practices.Generic practice elaborations appear after generic practices toprovide guidance on how the generic practice can be applieduniquely to process areas.Process InstitutionalizationInstitutionalization is an important concept in process improvement.When mentioned in the generic goal and generic practice descrip-tions, institutionalization implies that the process is ingrained in theway the work is performed and there is commitment and consistencyto performing (i.e., executing) the process.An institutionalized process is more likely to be retained duringtimes of stress. When the requirements and objectives for the processchange, however, the implementation of the process may also need tochange to ensure that it remains effective. The generic practicesdescribe activities that address these aspects of institutionalization.The degree of institutionalization is embodied in the generic goalsand expressed in the names of the processes associated with eachgoal as indicated in Table 7.1.165GGS&GPSTable 7.1 Generic Goals and Process NamesGeneric Goal Progression of ProcessesGG 1 Performed processGG 2 Managed processGG 3 Defined processWow! eBook <WoweBook.Com>
  • 192. The progression of process institutionalization is characterized inthe following descriptions of each process.Performed ProcessA performed process is a process that accomplishes the work neces-sary to satisfy the specific goals of a process area.Managed ProcessA managed process is a performed process that is planned and executedin accordance with policy; employs skilled people having adequateresources to produce controlled outputs; involves relevant stakehold-ers; is monitored, controlled, and reviewed; and is evaluated foradherence to its process description.The process can be instantiated by a project, group, or organiza-tional function. Management of the process is concerned with insti-tutionalization and the achievement of other specific objectivesestablished for the process, such as cost, schedule, and quality objec-tives. The control provided by a managed process helps to ensurethat the established process is retained during times of stress.The requirements and objectives for the process are establishedby the organization. The status of the work products and services arevisible to management at defined points (e.g., at major milestones,on completion of major tasks). Commitments are established amongthose who perform the work and the relevant stakeholders and arerevised as necessary. Work products are reviewed with relevant stake-holders and are controlled. The work products and services satisfytheir specified requirements.A critical distinction between a performed process and a managedprocess is the extent to which the process is managed. A managedprocess is planned (the plan can be part of a more encompassingplan) and the execution of the process is managed against the plan.Corrective actions are taken when the actual results and execu-tion deviate significantly from the plan. A managed process achievesthe objectives of the plan and is institutionalized for consistentexecution.Defined ProcessA defined process is a managed process that is tailored from the organiza-tion’s set of standard processes according to the organization’s tailor-ing guidelines; has a maintained process description; and contributesprocess related experiences to the organizational process assets.166 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 193. Organizational process assets are artifacts that relate to describ-ing, implementing, and improving processes. These artifacts areassets because they are developed or acquired to meet the businessobjectives of the organization and they represent investments by theorganization that are expected to provide current and future businessvalue.The organization’s set of standard processes, which are the basisof the defined process, are established and improved over time. Stan-dard processes describe the fundamental process elements that areexpected in the defined processes. Standard processes also describethe relationships (e.g., the ordering, the interfaces) among theseprocess elements. The organization-level infrastructure to supportcurrent and future use of the organization’s set of standard processesis established and improved over time. (See the definition of “stan-dard process” in the glossary.)A project’s defined process provides a basis for planning, perform-ing, and improving the project’s tasks and activities. A project canhave more than one defined process (e.g., one for developing theproduct and another for testing the product).A defined process clearly states the following:• Purpose• Inputs• Entry criteria• Activities• Roles• Measures• Verification steps• Outputs• Exit criteriaA critical distinction between a managed process and a definedprocess is the scope of application of the process descriptions, stan-dards, and procedures. For a managed process, the process descrip-tions, standards, and procedures are applicable to a particularproject, group, or organizational function. As a result, the managedprocesses of two projects in one organization can be different.Another critical distinction is that a defined process is described inmore detail and is performed more rigorously than a managedprocess. This distinction means that improvement information is eas-ier to understand, analyze, and use. Finally, management of thedefined process is based on the additional insight provided by anGeneric Goals and Generic Practices 167GGS&GPSWow! eBook <WoweBook.Com>
  • 194. understanding of the interrelationships of the process activities anddetailed measures of the process, its work products, and its services.Relationships Among ProcessesThe generic goals evolve so that each goal provides a foundation forthe next. Therefore, the following conclusions can be made:• A managed process is a performed process.• A defined process is a managed process.Thus, applied sequentially and in order, the generic goals describea process that is increasingly institutionalized from a performedprocess to a defined process.Achieving GG 1 for a process area is equivalent to saying youachieve the specific goals of the process area.Achieving GG 2 for a process area is equivalent to saying youmanage the execution of processes associated with the process area.There is a policy that indicates you will perform the process. There isa plan for performing it. There are resources provided, responsibili-ties assigned, training on how to perform it, selected work productsfrom performing the process are controlled, and so on. In otherwords, the process is planned and monitored just like any project orsupport activity.Achieving GG 3 for a process area is equivalent to saying that anorganizational standard process exists that can be tailored to result inthe process you will use. Tailoring might result in making nochanges to the standard process. In other words, the process usedand the standard process can be identical. Using the standard process“as is” is tailoring because the choice is made that no modification isrequired.Each process area describes multiple activities, some of which arerepeatedly performed. You may need to tailor the way one of theseactivities is performed to account for new capabilities or circum-stances. For example, you may have a standard for developing orobtaining organizational training that does not consider web-basedtraining. When preparing to develop or obtain a web-based course,you may need to tailor the standard process to account for the partic-ular challenges and benefits of web-based training.Generic Goals and Generic PracticesThis section describes all of the generic goals and generic practices,as well as their associated subpractices, notes, examples, and refer-168 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 195. ences. The generic goals are organized in numerical order, GG 1through GG 3. The generic practices are also organized in numericalorder under the generic goal they support.GG 1 ACHIEVE SPECIFIC GOALSThe specific goals of the process area are supported by the process by trans-forming identifiable input work products into identifiable output workproducts.GP 1.1 PERFORM SPECIFIC PRACTICESPerform the specific practices of the process area to develop work productsand provide services to achieve the specific goals of the process area.The purpose of this generic practice is to produce the work productsand deliver the services that are expected by performing (i.e., execut-ing) the process. These practices can be done informally without fol-lowing a documented process description or plan. The rigor withwhich these practices are performed depends on the individualsmanaging and performing the work and can vary considerably.GG 2 INSTITUTIONALIZE A MANAGED PROCESSThe process is institutionalized as a managed process.GP 2.1 ESTABLISH AN ORGANIZATIONAL POLICYEstablish and maintain an organizational policy for planning and performingthe process.The purpose of this generic practice is to define the organizationalexpectations for the process and make these expectations visible tothose members of the organization who are affected. In general, sen-ior management is responsible for establishing and communicatingguiding principles, direction, and expectations for the organization.Not all direction from senior management will bear the label “pol-icy.” The existence of appropriate organizational direction is theexpectation of this generic practice, regardless of what it is called orhow it is imparted.CAR ElaborationThis policy establishes organizational expectations for identifyingand systematically addressing causal analysis of selected outcomes.GP 2.1 Policy 169GGS&GPSWow! eBook <WoweBook.Com>
  • 196. CM ElaborationThis policy establishes organizational expectations for establishingand maintaining baselines, tracking and controlling changes to workproducts (under configuration management), and establishing andmaintaining integrity of the baselines.DAR ElaborationThis policy establishes organizational expectations for selectivelyanalyzing possible decisions using a formal evaluation process thatevaluates identified alternatives against established criteria. The pol-icy should also provide guidance on which decisions require a formalevaluation process.IPM ElaborationThis policy establishes organizational expectations for establishingand maintaining the project’s defined process from project startupthrough the life of the project, using the project’s defined process inmanaging the project, and coordinating and collaborating with rele-vant stakeholders.MA ElaborationThis policy establishes organizational expectations for aligning mea-surement objectives and activities with identified information needsand project, organizational, or business objectives and for providingmeasurement results.OPD ElaborationThis policy establishes organizational expectations for establishingand maintaining a set of standard processes for use by the organiza-tion, making organizational process assets available across the organ-ization, and establishing rules and guidelines for teams.OPF ElaborationThis policy establishes organizational expectations for determiningprocess improvement opportunities for the processes being used andfor planning, implementing, and deploying process improvementsacross the organization.OPM ElaborationThis policy establishes organizational expectations for analyzing theorganization’s business performance using statistical and other quan-titative techniques to determine performance shortfalls, and identify-170 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 197. ing and deploying process and technology improvements that con-tribute to meeting quality and process performance objectives.OPP ElaborationThis policy establishes organizational expectations for establishingand maintaining process performance baselines and process perform-ance models for the organization’s set of standard processes.OT ElaborationThis policy establishes organizational expectations for identifyingthe strategic training needs of the organization and providing thattraining.PI ElaborationThis policy establishes organizational expectations for developingproduct integration strategies, procedures, and an environment;ensuring interface compatibility among product components; assem-bling the product components; and delivering the product and prod-uct components.PMC ElaborationThis policy establishes organizational expectations for monitoringproject progress and performance against the project plan and man-aging corrective action to closure when actual or results deviate sig-nificantly from the plan.PP ElaborationThis policy establishes organizational expectations for estimating theplanning parameters, making internal and external commitments,and developing the plan for managing the project.PPQA ElaborationThis policy establishes organizational expectations for objectivelyevaluating whether processes and associated work products adhereto applicable process descriptions, standards, and procedures; andensuring that noncompliance is addressed.This policy also establishes organizational expectations forprocess and product quality assurance being in place for all projects.Process and product quality assurance must possess sufficient inde-pendence from project management to provide objectivity in identi-fying and reporting noncompliance issues.GP 2.1 Policy 171GGS&GPSWow! eBook <WoweBook.Com>
  • 198. QPM ElaborationThis policy establishes organizational expectations for using statisti-cal and other quantitative techniques and historical data when:establishing quality and process performance objectives, composingthe project’s defined process, selecting subprocess attributes criticalto understanding process performance, monitoring subprocess andproject performance, and performing root cause analysis to addressprocess performance deficiencies. In particular, this policy estab-lishes organizational expectations for use of process performancemeasures, baselines, and models.RD ElaborationThis policy establishes organizational expectations for collectingstakeholder needs, formulating product and product componentrequirements, and analyzing and validating those requirements.REQM ElaborationThis policy establishes organizational expectations for managingrequirements and identifying inconsistencies between the require-ments and the project plans and work products.RSKM ElaborationThis policy establishes organizational expectations for defining a riskmanagement strategy and identifying, analyzing, and mitigatingrisks.SAM ElaborationThis policy establishes organizational expectations for establishing,maintaining, and satisfying supplier agreements.TS ElaborationThis policy establishes organizational expectations for addressing theiterative cycle in which product or product component solutions areselected, designs are developed, and designs are implemented.VAL ElaborationThis policy establishes organizational expectations for selectingproducts and product components for validation; for selecting vali-dation methods; and for establishing and maintaining validation pro-cedures, criteria, and environments that ensure the products andproduct components satisfy end user needs in their intended operat-ing environment.172 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 199. VER ElaborationThis policy establishes organizational expectations for establishingand maintaining verification methods, procedures, criteria, and theverification environment, as well as for performing peer reviews andverifying selected work products.GP 2.2 PLAN THE PROCESSEstablish and maintain the plan for performing the process.The purpose of this generic practice is to determine what is neededto perform the process and to achieve the established objectives, toprepare a plan for performing the process, to prepare a processdescription, and to get agreement on the plan from relevant stake-holders.The practical implications of applying a generic practice vary foreach process area.For example, the planning described by this generic practice as applied tothe Project Monitoring and Control process area can be carried out in fullby the processes associated with the Project Planning process area. How-ever, this generic practice, when applied to the Project Planning processarea, sets an expectation that the project planning process itself beplanned.Therefore, this generic practice can either reinforce expectationsset elsewhere in CMMI or set new expectations that should beaddressed.Refer to the Project Planning process area for more information about establish-ing and maintaining plans that define project activities.Establishing a plan includes documenting the plan and a processdescription. Maintaining the plan includes updating it to reflect cor-rective actions or changes in requirements or objectives.The plan for performing the process typically includes the following:• Process description• Standards and requirements for the work products and services of theprocess• Specific objectives for the execution of the process and its results (e.g.,quality, time scale, cycle time, use of resources)ContinuesGP 2.2 Plan 173GGS&GPSWow! eBook <WoweBook.Com>
  • 200. Continued• Dependencies among the activities, work products, and services of theprocess• Resources (e.g., funding, people, tools) needed to perform the process• Assignment of responsibility and authority• Training needed for performing and supporting the process• Work products to be controlled and the level of control to be applied• Measurement requirements to provide insight into the execution of theprocess, its work products, and its services• Involvement of relevant stakeholders• Activities for monitoring and controlling the process• Objective evaluation activities of the process• Management review activities for the process and the work productsSubpractices1. Define and document the plan for performing the process.This plan can be a stand-alone document, embedded in a more com-prehensive document, or distributed among multiple documents. Inthe case of the plan being distributed among multiple documents,ensure that a coherent picture of who does what is preserved. Docu-ments can be hardcopy or softcopy.2. Define and document the process description.The process description, which includes relevant standards and pro-cedures, can be included as part of the plan for performing theprocess or can be included in the plan by reference.3. Review the plan with relevant stakeholders and get their agreement.This review of the plan includes reviewing that the planned processsatisfies the applicable policies, plans, requirements, and standards toprovide assurance to relevant stakeholders.4. Revise the plan as necessary.CAR ElaborationThis plan for performing the causal analysis and resolution processcan be included in (or referenced by) the project plan, which isdescribed in the Project Planning process area. This plan differs fromthe action proposals and associated action plans described in severalspecific practices in this process area. The plan called for in thisgeneric practice would address the project’s overall causal analysisand resolution process (perhaps tailored from a standard processmaintained by the organization). In contrast, the process action pro-posals and associated action items address the activities needed toaddress a specific root cause under study.174 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 201. CM ElaborationThis plan for performing the configuration management process canbe included in (or referenced by) the project plan, which is describedin the Project Planning process area.DAR ElaborationThis plan for performing the decision analysis and resolution processcan be included in (or referenced by) the project plan, which isdescribed in the Project Planning process area.IPM ElaborationThis plan for the integrated project management process unites theplanning for the project planning and monitor and control processes.The planning for performing the planning related practices in Inte-grated Project Management is addressed as part of planning theproject planning process. This plan for performing the monitor-and-control related practices in Integrated Project Management can beincluded in (or referenced by) the project plan, which is described inthe Project Planning process area.MA ElaborationThis plan for performing the measurement and analysis process canbe included in (or referenced by) the project plan, which is describedin the Project Planning process area.OPD ElaborationThis plan for performing the organizational process definitionprocess can be part of (or referenced by) the organization’s processimprovement plan.OPF ElaborationThis plan for performing the organizational process focus process,which is often called “the process improvement plan,” differs fromthe process action plans described in specific practices in this processarea. The plan called for in this generic practice addresses the com-prehensive planning for all of the specific practices in this processarea, from establishing organizational process needs through incor-porating process related experiences into organizational process assets.OPM ElaborationThis plan for performing the organizational performance managementprocess differs from the deployment plans described in a specific prac-tice in this process area. The plan called for in this generic practiceGP 2.2 Plan 175GGS&GPSWow! eBook <WoweBook.Com>
  • 202. addresses the comprehensive planning for all of the specific practicesin this process area, from maintaining business objectives to evaluat-ing improvement effects. In contrast, the deployment plans called forin the specific practice would address the planning needed for thedeployment of selected improvements.OPP ElaborationThis plan for performing the organizational process performanceprocess can be included in (or referenced by) the organization’sprocess improvement plan, which is described in the OrganizationalProcess Focus process area. Or it may be documented in a separateplan that describes only the plan for the organizational process per-formance process.OT ElaborationThis plan for performing the organizational training process differsfrom the tactical plan for organizational training described in a spe-cific practice in this process area. The plan called for in this genericpractice addresses the comprehensive planning for all of the specificpractices in this process area, from establishing strategic trainingneeds through assessing the effectiveness of organizational training.In contrast, the organizational training tactical plan called for in thespecific practice of this process area addresses the periodic planningfor the delivery of training offerings.PI ElaborationThis plan for performing the product integration process addressesthe comprehensive planning for all of the specific practices in thisprocess area, from the preparation for product integration all the waythrough to the delivery of the final product.This plan for performing the product integration process can bepart of (or referenced by) the project plan as described in the ProjectPlanning process area.PMC ElaborationThis plan for performing the project monitoring and control processcan be part of (or referenced by) the project plan, as described in theProject Planning process area.PP ElaborationRefer to Table 7.2 in Generic Goals and Generic Practices for more informationabout the relationship between generic practice 2.2 and the Project Planningprocess area.176 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 203. PPQA ElaborationThis plan for performing the process and product quality assuranceprocess can be included in (or referenced by) the project plan, whichis described in the Project Planning process area.QPM ElaborationThis plan for performing the quantitative project managementprocess can be included in (or referenced by) the project plan, whichis described in the Project Planning process area.RD ElaborationThis plan for performing the requirements development process canbe part of (or referenced by) the project plan as described in the Proj-ect Planning process area.REQM ElaborationThis plan for performing the requirements management process canbe part of (or referenced by) the project plan as described in the Proj-ect Planning process area.RSKM ElaborationThis plan for performing the risk management process can beincluded in (or referenced by) the project plan, which is described inthe Project Planning process area. The plan called for in this genericpractice addresses the comprehensive planning for all of the specificpractices in this process area. In particular, this plan provides theoverall approach for risk mitigation, but is distinct from mitigationplans (including contingency plans) for specific risks. In contrast,the risk mitigation plans called for in the specific practices of thisprocess area addresses more focused items such as the levels thattrigger risk handling activities.SAM ElaborationPortions of this plan for performing the supplier agreement manage-ment process can be part of (or referenced by) the project plan asdescribed in the Project Planning process area. Often, however, someportions of the plan reside outside of the project with a group such ascontract management.TS ElaborationThis plan for performing the technical solution process can be part of(or referenced by) the project plan as described in the Project Plan-ning process area.GP 2.2 Plan 177GGS&GPSWow! eBook <WoweBook.Com>
  • 204. 178 PART TWO THE PROCESS AREASVAL ElaborationThis plan for performing the validation process can be included in(or referenced by) the project plan, which is described in the ProjectPlanning process area.VER ElaborationThis plan for performing the verification process can be included in(or referenced by) the project plan, which is described in the ProjectPlanning process area.GP 2.3 PROVIDE RESOURCESProvide adequate resources for performing the process, developing the workproducts, and providing the services of the process.The purpose of this generic practice is to ensure that the resourcesnecessary to perform the process as defined by the plan are availablewhen they are needed. Resources include adequate funding, appro-priate physical facilities, skilled people, and appropriate tools.The interpretation of the term “adequate” depends on many fac-tors and can change over time. Inadequate resources may beaddressed by increasing resources or by removing requirements, con-straints, and commitments.CAR ElaborationExamples of resources provided include the following:• Database management systems• Process modeling tools• Statistical analysis packagesCM ElaborationExamples of resources provided include the following:• Configuration management tools• Data management tools• Archiving and reproduction tools• Database management systemsWow! eBook <WoweBook.Com>
  • 205. GP 2.3 Resources 179GGS&GPSDAR ElaborationExamples of resources provided include the following:• Simulators and modeling tools• Prototyping tools• Tools for conducting surveysIPM ElaborationExamples of resources provided include the following:• Problem tracking and trouble reporting packages• Groupware• Video conferencing• Integrated decision database• Integrated product support environmentsMA ElaborationStaff with appropriate expertise provide support for measurementand analysis activities. A measurement group with such a role mayexist.Examples of resources provided include the following:• Statistical packages• Packages that support data collection over networksOPD ElaborationA process group typically manages organizational process definitionactivities. This group typically is staffed by a core of professionalswhose primary responsibility is coordinating organizational processimprovement.This group is supported by process owners and people with expertise invarious disciplines such as the following:• Project management• The appropriate engineering disciplines• Configuration management• Quality assuranceWow! eBook <WoweBook.Com>
  • 206. 180 PART TWO THE PROCESS AREASExamples of resources provided include the following:• Database management systems• Process modeling tools• Web page builders and browsersOPF ElaborationExamples of resources provided include the following:• Database management systems• Process improvement tools• Web page builders and browsers• Groupware• Quality improvement tools (e.g., cause-and-effect diagrams, affinity dia-grams, Pareto charts)OPM ElaborationExamples of resources provided include the following:• Simulation packages• Prototyping tools• Statistical packages• Dynamic systems modeling• Subscriptions to online technology databases and publications• Process modeling toolsOPP ElaborationSpecial expertise in statistical and other quantitative techniques maybe needed to establish process performance baselines for the organi-zation’s set of standard processes.Examples of resources provided include the following:• Database management systems• System dynamics models• Process modeling tools• Statistical analysis packages• Problem tracking packagesWow! eBook <WoweBook.Com>
  • 207. GP 2.3 Resources 181GGS&GPSOT ElaborationExamples of resources provided include the following:• Subject matter experts• Curriculum designers• Instructional designers• Instructors• Training administratorsSpecial facilities may be required for training. When necessary,the facilities required for the activities in the Organizational Trainingprocess area are developed or purchased.Examples of resources provided include the following:• Instruments for analyzing training needs• Workstations to be used for training• Instructional design tools• Packages for developing presentation materialsPI ElaborationProduct component interface coordination can be accomplished withan Interface Control Working Group consisting of people who repre-sent external and internal interfaces. Such groups can be used toelicit needs for interface requirements development.Special facilities may be required for assembling and deliveringthe product. When necessary, the facilities required for the activitiesin the Product Integration process area are developed or purchased.Examples of resources provided include the following:• Prototyping tools• Analysis tools• Simulation tools• Interface management tools• Assembly tools (e.g., compilers, make files, joining tools, jigs, fixtures)Wow! eBook <WoweBook.Com>
  • 208. 182 PART TWO THE PROCESS AREASPMC ElaborationExamples of resources provided include the following:• Cost tracking systems• Effort reporting systems• Action item tracking systems• Project management and scheduling programsPP ElaborationSpecial expertise, equipment, and facilities in project planning maybe required.Special expertise in project planning can include the following:• Experienced estimators• Schedulers• Technical experts in applicable areas (e.g., product domain, technology)Examples of resources provided include the following:• Spreadsheet programs• Estimating models• Project planning and scheduling packagesPPQA ElaborationExamples of resources provided include the following:• Evaluation tools• Noncompliance tracking toolsQPM ElaborationSpecial expertise in statistics and its use in analyzing process per-formance may be needed to define the analytic techniques used inquantitative management. Special expertise in statistics can also beneeded for analyzing and interpreting the measures resulting fromstatistical analyses; however, teams need sufficient expertise to sup-port a basic understanding of their process performance as they per-form their daily work.Wow! eBook <WoweBook.Com>
  • 209. GP 2.3 Resources 183GGS&GPSExamples of resources provided include the following:• Statistical analysis packages• Statistical process and quality control packages• Scripts and tools that assist teams in analyzing their own process per-formance with minimal need for additional expert assistanceRD ElaborationSpecial expertise in the application domain, methods for elicitingstakeholder needs, and methods and tools for specifying and analyz-ing customer, product, and product component requirements may berequired.Examples of resources provided include the following:• Requirements specification tools• Simulators and modeling tools• Prototyping tools• Scenario definition and management tools• Requirements tracking toolsREQM ElaborationExamples of resources provided include the following:• Requirements tracking tools• Traceability toolsRSKM ElaborationExamples of resources provided include the following:• Risk management databases• Risk mitigation tools• Prototyping tools• Modeling and simulation toolsSAM ElaborationExamples of resources provided include the following:• Preferred supplier lists• Requirements tracking tools• Project management and scheduling programsWow! eBook <WoweBook.Com>
  • 210. TS ElaborationSpecial facilities may be required for developing, designing, andimplementing solutions to requirements. When necessary, the facili-ties required for the activities in the Technical Solution process areaare developed or purchased.Examples of resources provided include the following:• Design specification tools• Simulators and modeling tools• Prototyping tools• Scenario definition and management tools• Requirements tracking tools• Interactive documentation toolsVAL ElaborationSpecial facilities may be required for validating the product or prod-uct components. When necessary, the facilities required for valida-tion are developed or purchased.Examples of resources provided include the following:• Test management tools• Test case generators• Test coverage analyzers• Simulators• Load, stress, and performance testing toolsVER ElaborationSpecial facilities may be required for verifying selected work prod-ucts. When necessary, the facilities required for the activities in theVerification process area are developed or purchased.Certain verification methods can require special tools, equipment,facilities, and training (e.g., peer reviews can require meeting roomsand trained moderators; certain verification tests can require specialtest equipment and people skilled in the use of the equipment).Examples of resources provided include the following:• Test management tools• Test case generators• Test coverage analyzers• Simulators184 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 211. GP 2.4 Responsibility 185GGS&GPSGP 2.4 ASSIGN RESPONSIBILITYAssign responsibility and authority for performing the process, developing thework products, and providing the services of the process.The purpose of this generic practice is to ensure that there is accounta-bility for performing the process and achieving the specified resultsthroughout the life of the process. The people assigned must havethe appropriate authority to perform the assigned responsibilities.Responsibility can be assigned using detailed job descriptions orin living documents, such as the plan for performing the process.Dynamic assignment of responsibility is another legitimate way toimplement this generic practice, as long as the assignment andacceptance of responsibility are ensured throughout the life of theprocess.Subpractices1. Assign overall responsibility and authority for performing theprocess.2. Assign responsibility and authority for performing the specific tasksof the process.3. Confirm that the people assigned to the responsibilities and authori-ties understand and accept them.OPF ElaborationTwo groups are typically established and assigned responsibility forprocess improvement: (1) a management steering committee for processimprovement to provide senior management sponsorship, and (2) aprocess group to facilitate and manage the process improvementactivities.PPQA ElaborationResponsibility is assigned to those who can perform process andproduct quality assurance evaluations with sufficient independenceand objectivity to guard against subjectivity or bias.TS ElaborationAppointing a lead or chief architect that oversees the technical solu-tion and has authority over design decisions helps to maintain con-sistency in product design and evolution.Wow! eBook <WoweBook.Com>
  • 212. 186 PART TWO THE PROCESS AREASGP 2.5 TRAIN PEOPLETrain the people performing or supporting the process as needed.The purpose of this generic practice is to ensure that people have thenecessary skills and expertise to perform or support the process.Appropriate training is provided to those who will be performingthe work. Overview training is provided to orient people who inter-act with those who perform the work.Examples of methods for providing training include self study; self-directed training; self-paced, programmed instruction; formalized on-the-job training; mentoring; and formal and classroom training.Training supports the successful execution of the process byestablishing a common understanding of the process and by impart-ing the skills and knowledge needed to perform the process.Refer to the Organizational Training process area for more information aboutdeveloping skills and knowledge of people so they can perform their roles effec-tively and efficiently.CAR ElaborationExamples of training topics include the following:• Quality management methods (e.g., root cause analysis)CM ElaborationExamples of training topics include the following:• Roles, responsibilities, and authority of the configuration managementstaff• Configuration management standards, procedures, and methods• Configuration library systemDAR ElaborationExamples of training topics include the following:• Formal decision analysis• Methods for evaluating alternative solutions against criteriaWow! eBook <WoweBook.Com>
  • 213. GP 2.5 Training 187GGS&GPSIPM ElaborationExamples of training topics include the following:• Tailoring the organization’s set of standard processes to meet the needsof the project• Managing the project based on the project’s defined process• Using the organization’s measurement repository• Using the organizational process assets• Integrated management• Intergroup coordination• Group problem solvingMA ElaborationExamples of training topics include the following:• Statistical techniques• Data collection, analysis, and reporting processes• Development of goal related measurements (e.g., Goal Question Metric)OPD ElaborationExamples of training topics include the following:• CMMI and other process and process improvement reference models• Planning, managing, and monitoring processes• Process modeling and definition• Developing a tailorable standard process• Developing work environment standards• ErgonomicsOPF ElaborationExamples of training topics include the following:• CMMI and other process improvement reference models• Planning and managing process improvement• Tools, methods, and analysis techniques• Process modeling• Facilitation techniques• Change managementWow! eBook <WoweBook.Com>
  • 214. 188 PART TWO THE PROCESS AREASOPM ElaborationExamples of training topics include the following:• Cost benefit analysis• Planning, designing, and conducting pilots• Technology transition• Change managementOPP ElaborationExamples of training topics include the following:• Process and process improvement modeling• Statistical and other quantitative methods (e.g., estimating models, Paretoanalysis, control charts)OT ElaborationExamples of training topics include the following:• Knowledge and skills needs analysis• Instructional design• Instructional techniques (e.g., train the trainer)• Refresher training on subject matterPI ElaborationExamples of training topics include the following:• Application domain• Product integration procedures and criteria• Organization’s facilities for integration and assembly• Assembly methods• Packaging standardsPMC ElaborationExamples of training topics include the following:• Monitoring and control of projects• Risk management• Data managementWow! eBook <WoweBook.Com>
  • 215. PP ElaborationExamples of training topics include the following:• Estimating• Budgeting• Negotiating• Identifying and analyzing risks• Managing data• Planning• SchedulingPPQA ElaborationExamples of training topics include the following:• Application domain• Customer relations• Process descriptions, standards, procedures, and methods for the project• Quality assurance objectives, process descriptions, standards, proce-dures, methods, and toolsQPM ElaborationExamples of training topics include the following:• Basic quantitative (including statistical) analyses that help in analyzingprocess performance, using historical data, and identifying when correc-tive action is warranted• Process modeling and analysis• Process measurement data selection, definition, and collectionRD ElaborationExamples of training topics include the following:• Application domain• Requirements definition and analysis• Requirements elicitation• Requirements specification and modeling• Requirements trackingGP 2.5 Training 189GGS&GPSWow! eBook <WoweBook.Com>
  • 216. REQM ElaborationExamples of training topics include the following:• Application domain• Requirements definition, analysis, review, and management• Requirements management tools• Configuration management• Negotiation and conflict resolutionRSKM ElaborationExamples of training topics include the following:• Risk management concepts and activities (e.g., risk identification, evalua-tion, monitoring, mitigation)• Measure selection for risk mitigationSAM ElaborationExamples of training topics include the following:• Regulations and business practices related to negotiating and workingwith suppliers• Acquisition planning and preparation• Commercial off-the-shelf product acquisition• Supplier evaluation and selection• Negotiation and conflict resolution• Supplier management• Testing and transition of acquired products• Receiving, storing, using, and maintaining acquired productsTS ElaborationExamples of training topics include the following:• Application domain of the product and product components• Design methods• Architecture methods• Interface design• Unit testing techniques• Standards (e.g., product, safety, human factors, environmental)190 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 217. VAL ElaborationExamples of training topics include the following:• Application domain• Validation principles, standards, and methods• Intended-use environmentVER ElaborationExamples of training topics include the following:• Application or service domain• Verification principles, standards, and methods (e.g., analysis, demon-stration, inspection, test)• Verification tools and facilities• Peer review preparation and procedures• Meeting facilitationGP 2.6 CONTROL WORK PRODUCTSPlace selected work products of the process under appropriate levels ofcontrol.The purpose of this generic practice is to establish and maintain theintegrity of the selected work products of the process (or theirdescriptions) throughout their useful life.The selected work products are specifically identified in the planfor performing the process, along with a specification of the appro-priate level of control.Different levels of control are appropriate for different work prod-ucts and for different points in time. For some work products, it maybe sufficient to maintain version control so that the version of thework product in use at a given time, past or present, is known andchanges are incorporated in a controlled manner. Version control isusually under the sole control of the work product owner (which canbe an individual, group, or team).Sometimes, it can be critical that work products be placed underformal or baseline configuration management. This type of controlincludes defining and establishing baselines at predetermined points.These baselines are formally reviewed and approved, and serve as thebasis for further development of the designated work products.GP 2.6 Work Products 191GGS&GPSWow! eBook <WoweBook.Com>
  • 218. Refer to the Configuration Management process area for more informationabout establishing and maintaining the integrity of work products using config-uration identification, configuration control, configuration status accounting,and configuration audits.Additional levels of control between version control and formalconfiguration management are possible. An identified work productcan be under various levels of control at different points in time.CAR ElaborationExamples of work products placed under control include the following:• Action proposals• Action plans• Causal analysis and resolution recordsCM ElaborationExamples of work products placed under control include the following:• Access lists• Change status reports• Change request database• CCB meeting minutes• Archived baselinesDAR ElaborationExamples of work products placed under control include the following:• Guidelines for when to apply a formal evaluation process• Evaluation reports containing recommended solutionsIPM ElaborationExamples of work products placed under control include the following:• The project’s defined process• Project plans• Other plans that affect the project• Integrated plans• Actual process and product measurements collected from the project• Project’s shared vision• Team structure• Team charters192 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 219. MA ElaborationExamples of work products placed under control include the following:• Measurement objectives• Specifications of base and derived measures• Data collection and storage procedures• Base and derived measurement data sets• Analysis results and draft reports• Data analysis toolsOPD ElaborationExamples of work products placed under control include the following:• Organization’s set of standard processes• Descriptions of lifecycle models• Tailoring guidelines for the organization’s set of standard processes• Definitions of the common set of product and process measures• Organization’s measurement data• Rules and guidelines for structuring and forming teamsOPF ElaborationExamples of work products placed under control include the following:• Process improvement proposals• Organization’s approved process action plans• Training materials used for deploying organizational process assets• Guidelines for deploying the organization’s set of standard processes onnew projects• Plans for the organization’s process appraisalsOPM ElaborationExamples of work products placed under control include the following:• Documented lessons learned from improvement validation• Deployment plans• Revised improvement measures, objectives, priorities• Updated process documentation and training materialGP 2.6 Work Products 193GGS&GPSWow! eBook <WoweBook.Com>
  • 220. OPP ElaborationExamples of work products placed under control include the following:• Organization’s quality and process performance objectives• Definitions of the selected measures of process performance• Baseline data on the organization’s process performance• Process performance modelsOT ElaborationExamples of work products placed under control include the following:• Organizational training tactical plan• Training records• Training materials and supporting artifacts• Instructor evaluation formsPI ElaborationExamples of work products placed under control include the following:• Acceptance documents for the received product components• Evaluated assembled product and product components• Product integration strategy• Product integration procedures and criteria• Updated interface description or agreementPMC ElaborationExamples of work products placed under control include the following:• Project schedules with status• Project measurement data and analysis• Earned value reportsPP ElaborationExamples of work products placed under control include the following:• Work breakdown structure• Project plan• Data management plan• Stakeholder involvement plan194 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 221. PPQA ElaborationExamples of work products placed under control include the following:• Noncompliance reports• Evaluation logs and reportsQPM ElaborationExamples of work products placed under control include the following:• Subprocesses to be included in the project’s defined process• Operational definitions of the measures, their collection points in thesubprocesses, and how the integrity of the measures will be determined• Collected measurementsRD ElaborationExamples of work products placed under control include the following:• Customer functional and quality attribute requirements• Definition of required functionality and quality attributes• Product and product component requirements• Interface requirementsREQM ElaborationExamples of work products placed under control include the following:• Requirements• Requirements traceability matrixRSKM ElaborationExamples of work products placed under control include the following:• Risk management strategy• Identified risk items• Risk mitigation plansGP 2.6 Work Products 195GGS&GPSWow! eBook <WoweBook.Com>
  • 222. SAM ElaborationExamples of work products placed under control include the following:• Statements of work• Supplier agreements• Memoranda of agreement• Subcontracts• Preferred supplier listsTS ElaborationExamples of work products placed under control include the following:• Product, product component, and interface designs• Technical data packages• Interface design documents• Criteria for design and product component reuse• Implementeddesigns(e.g.,softwarecode,fabricatedproductcomponents)• User, installation, operation, and maintenance documentationVAL ElaborationExamples of work products placed under control include the following:• Lists of products and product components selected for validation• Validation methods, procedures, and criteria• Validation reportsVER ElaborationExamples of work products placed under control include the following:• Verification procedures and criteria• Peer review training material• Peer review data• Verification reportsGP 2.7 IDENTIFY AND INVOLVE RELEVANT STAKEHOLDERSIdentify and involve the relevant stakeholders of the process as planned.The purpose of this generic practice is to establish and maintain theexpected involvement of relevant stakeholders during the executionof the process.196 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 223. Involve relevant stakeholders as described in an appropriate planfor stakeholder involvement. Involve stakeholders appropriately inactivities such as the following:• Planning• Decisions• Commitments• Communications• Coordination• Reviews• Appraisals• Requirements definitions• Resolution of problems and issuesRefer to the Project Planning process area for more information about planningstakeholder involvement.The objective of planning stakeholder involvement is to ensurethat interactions necessary to the process are accomplished, whilenot allowing excessive numbers of affected groups and individuals toimpede process execution.Examples of stakeholders that might serve as relevant stakeholders forspecific tasks, depending on context, include individuals, teams, manage-ment, customers, suppliers, end users, operations and support staff, otherprojects, and government regulators.Subpractices1. Identify stakeholders relevant to this process and their appropriateinvolvement.Relevant stakeholders are identified among the suppliers of inputs to,the users of outputs from, and the performers of the activities in theprocess. Once the relevant stakeholders are identified, the appropriatelevel of their involvement in process activities is planned.2. Share these identifications with project planners or other planners asappropriate.3. Involve relevant stakeholders as planned.GP 2.7 Stakeholders 197GGS&GPSWow! eBook <WoweBook.Com>
  • 224. CAR ElaborationExamples of activities for stakeholder involvement include the following:• Conducting causal analysis• Assessing action proposalsCM ElaborationExamples of activities for stakeholder involvement include the following:• Establishing baselines• Reviewing configuration management system reports and resolvingissues• Assessing the impact of changes for configuration items• Performing configuration audits• Reviewing results of configuration management auditsDAR ElaborationExamples of activities for stakeholder involvement include the following:• Establishing guidelines for which issues are subject to a formal evalua-tion process• Defining the issue to be addressed• Establishing evaluation criteria• Identifying and evaluating alternatives• Selecting evaluation methods• Selecting solutionsIPM ElaborationExamples of activities for stakeholder involvement include the following:• Resolving issues about the tailoring of organizational process assets• Resolving issues among the project plan and other plans that affect theproject• Reviewing project progress and performance to align with current andprojected needs, objectives, and requirements• Creating the project’s shared vision• Defining the team structure for the project• Populating teams198 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 225. MA ElaborationExamples of activities for stakeholder involvement include the following:• Establishing measurement objectives and procedures• Assessing measurement data• Providing meaningful feedback to those who are responsible for provid-ing the raw data on which the analysis and results dependOPD ElaborationExamples of activities for stakeholder involvement include the following:• Reviewing the organization’s set of standard processes• Reviewing the organization’s lifecycle models• Resolving issues related to the tailoring guidelines• Assessing definitions of the common set of process and productmeasures• Reviewing work environment standards• Establishing and maintaining empowerment mechanisms• Establishing and maintaining organizational rules and guidelines forstructuring and forming teamsOPF ElaborationExamples of activities for stakeholder involvement include the following:• Coordinating and collaborating on process improvement activitieswith process owners, those who are or will be performing the process,and support organizations (e.g., training staff, quality assurancerepresentatives)• Establishing the organizational process needs and objectives• Appraising the organization’s processes• Implementing process action plans• Coordinating and collaborating on the execution of pilots to test selectedimprovements• Deploying organizational process assets and changes to organizationalprocess assets• Communicating the plans, status, activities, and results related to plan-ning, implementing, and deploying process improvementsGP 2.7 Stakeholders 199GGS&GPSWow! eBook <WoweBook.Com>
  • 226. OPM ElaborationExamples of activities for stakeholder involvement include the following:• Reviewing improvement proposals that could contribute to meeting busi-ness objectives• Providing feedback to the organization on the readiness, status, andresults of the improvement deployment activitiesThe feedback typically involves the following:• Informing the people who submit improvement proposals about the dis-position of their proposals• Regularly communicating the results of comparing business performanceagainst the business objectives• Regularly informing relevant stakeholders about the plans and status forselecting and deploying improvements• Preparing and distributing a summary of improvement selection anddeployment activitiesOPP ElaborationExamples of activities for stakeholder involvement include the following:• Establishing the organization’s quality and process performance objec-tives and their priorities• Reviewing and resolving issues on the organization’s process perform-ance baselines• Reviewing and resolving issues on the organization’s process perform-ance modelsOT ElaborationExamples of activities for stakeholder involvement include the following:• Establishing a collaborative environment for discussion of training needsand training effectiveness to ensure that the organization’s training needsare met• Identifying training needs• Reviewing the organizational training tactical plan• Assessing training effectiveness200 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 227. PI ElaborationExamples of activities for stakeholder involvement include the following:• Establishing the product integration strategy• Reviewing interface descriptions for completeness• Establishing the product integration procedures and criteria• Assembling and delivering the product and product components• Communicating the results after evaluation• Communicating new, effective product integration processes to giveaffected people the opportunity to improve their process performancePMC ElaborationExamples of activities for stakeholder involvement include the following:• Assessing the project against the plan• Reviewing commitments and resolving issues• Reviewing project risks• Reviewing data management activities• Reviewing project progress• Managing corrective actions to closurePP ElaborationExamples of activities for stakeholder involvement include the following:• Establishing estimates• Reviewing and resolving issues on the completeness and correctness ofthe project risks• Reviewing data management plans• Establishing project plans• Reviewing project plans and resolving issues on work and resourceissuesPPQA ElaborationExamples of activities for stakeholder involvement include the following:• Establishing criteria for the objective evaluations of processes and workproducts• Evaluating processes and work products• Resolving noncompliance issues• Tracking noncompliance issues to closureGP 2.7 Stakeholders 201GGS&GPSWow! eBook <WoweBook.Com>
  • 228. QPM ElaborationExamples of activities for stakeholder involvement include the following:• Establishing project objectives• Resolving issues among the project’s quality and process performanceobjectives• Selecting analytic techniques to be used• Evaluating the process performance of selected subprocesses• Identifying and managing the risks in achieving the project’s quality andprocess performance objectives• Identifying what corrective action should be takenRD ElaborationExamples of activities for stakeholder involvement include the following:• Reviewing the adequacy of requirements in meeting needs, expectations,constraints, and interfaces• Establishing operational concepts and operational, sustainment, anddevelopment scenarios• Assessing the adequacy of requirements• Prioritizing customer requirements• Establishing product and product component functional and qualityattribute requirements• Assessing product cost, schedule, and riskREQM ElaborationExamples of activities for stakeholder involvement include the following:• Resolving issues on the understanding of requirements• Assessing the impact of requirements changes• Communicating bidirectional traceability• Identifying inconsistencies among requirements, project plans, and workproductsRSKM ElaborationExamples of activities for stakeholder involvement include the following:• Establishing a collaborative environment for free and open discussion ofrisk• Reviewing the risk management strategy and risk mitigation plans• Participating in risk identification, analysis, and mitigation activities• Communicating and reporting risk management status202 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 229. SAM ElaborationExamples of activities for stakeholder involvement include the following:• Establishing criteria for evaluation of potential suppliers• Reviewing potential suppliers• Establishing supplier agreements• Resolving issues with suppliers• Reviewing supplier performanceTS ElaborationExamples of activities for stakeholder involvement include the following:• Developing alternative solutions and selection criteria• Obtaining approval on external interface specifications and designdescriptions• Developing the technical data package• Assessing the make, buy, or reuse alternatives for product components• Implementing the designVAL ElaborationExamples of activities for stakeholder involvement include the following:• Selecting the products and product components to be validated• Establishing the validation methods, procedures, and criteria• Reviewing results of product and product component validation andresolving issues• Resolving issues with the customers or end usersIssues with the customers or end users are resolved particularly whenthere are significant deviations from their baseline needs. Examples ofresolutions include the following:• Waivers on the contract or agreement (what, when, and for whichproducts)• Additional in-depth studies, trials, tests, or evaluations• Possible changes in the contracts or agreementsGP 2.7 Stakeholders 203GGS&GPSWow! eBook <WoweBook.Com>
  • 230. VER ElaborationExamples of activities for stakeholder involvement include the following:• Selecting work products and methods for verification• Establishing verification procedures and criteria• Conducting peer reviews• Assessing verification results and identifying corrective actionGP 2.8 MONITOR AND CONTROL THE PROCESSMonitor and control the process against the plan for performing the processand take appropriate corrective action.The purpose of this generic practice is to perform the direct day-to-day monitoring and controlling of the process. Appropriate visibilityinto the process is maintained so that appropriate corrective actioncan be taken when necessary. Monitoring and controlling the processcan involve measuring appropriate attributes of the process or workproducts produced by the process.Refer to the Measurement and Analysis process area for more information aboutdeveloping and sustaining a measurement capability used to support manage-ment information needs.Refer to the Project Monitoring and Control process area for more informationabout providing an understanding of the project’s progress so that appropriatecorrective actions can be taken when the project’s performance deviates signifi-cantly from the plan.Subpractices1. Evaluate actual progress and performance against the plan for per-forming the process.The evaluations are of the process, its work products, and its services.2. Review accomplishments and results of the process against the planfor performing the process.3. Review activities, status, and results of the process with the immedi-ate level of management responsible for the process and identifyissues.These reviews are intended to provide the immediate level of manage-ment with appropriate visibility into the process based on the day-to-day monitoring and controlling of the process, and are supplementedby periodic and event-driven reviews with higher level managementas described in GP 2.10.204 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 231. GP 2.8 Monitor and Control 205GGS&GPS4. Identify and evaluate the effects of significant deviations from theplan for performing the process.5. Identify problems in the plan for performing the process and in theexecution of the process.6. Take corrective action when requirements and objectives are notbeing satisfied, when issues are identified, or when progress differssignificantly from the plan for performing the process.Inherent risks should be considered before any corrective action istaken.Corrective action can include the following:• Taking remedial action to repair defective work products or services• Changing the plan for performing the process• Adjusting resources, including people, tools, and other resources• Negotiating changes to the established commitments• Securing change to the requirements and objectives that must besatisfied• Terminating the effort7. Track corrective action to closure.CAR ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of outcomes analyzed• Change in quality or process performance per instance of the causalanalysis and resolution process• Schedule of activities for implementing a selected action proposalCM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of changes to configuration items• Number of configuration audits conducted• Schedule of CCB or audit activitiesWow! eBook <WoweBook.Com>
  • 232. DAR ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Cost-to-benefit ratio of using formal evaluation processes• Schedule for the execution of a trade studyIPM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of changes to the project’s defined process• Schedule and effort to tailor the organization’s set of standard processes• Interface coordination issue trends (i.e., number identified and numberclosed)• Schedule for project tailoring activities• Project’s shared vision usage and effectiveness• Team structure usage and effectiveness• Team charters usage and effectivenessMA ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Percentage of projects using progress and performance measures• Percentage of measurement objectives addressed• Schedule for collection and review of measurement dataOPD ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Percentage of projects using the process architectures and process ele-ments of the organization’s set of standard processes• Defect density of each process element of the organization’s set of stan-dard processes• Schedule for development of a process or process change206 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 233. OPF ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of process improvement proposals submitted, accepted, orimplemented• CMMI maturity level or capability level earned• Schedule for deployment of an organizational process asset• Percentage of projects using the current organization’s set of standardprocesses (or tailored version of the current set)• Issue trends associated with implementing the organization’s set of stan-dard processes (i.e., number of issues identified, number closed)• Progress toward achievement of process needs and objectivesOPM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Change in quality and process performance related to businessobjectives• Schedule for implementing and validating an improvement• Schedule for activities to deploy a selected improvementOPP ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Trends in the organization’s process performance with respect tochanges in work products and task attributes (e.g., size growth, effort,schedule, quality)• Schedule for collecting and reviewing measures to be used for establish-ing a process performance baselineOT ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of training courses delivered (e.g., planned versus actual)• Post-training evaluation ratings• Training program quality survey ratings• Schedule for delivery of training• Schedule for development of a courseGP 2.8 Monitor and Control 207GGS&GPSWow! eBook <WoweBook.Com>
  • 234. PI ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Product component integration profile (e.g., product component assem-blies planned and performed, number of exceptions found)• Integration evaluation problem report trends (e.g., number written andnumber closed)• Integration evaluation problem report aging (i.e., how long each problemreport has been open)• Schedule for conduct of specific integration activitiesPMC ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of open and closed corrective actions• Schedule with status for monthly financial data collection, analysis, andreporting• Number and types of reviews performed• Review schedule (planned versus actual and slipped target dates)• Schedule for collection and analysis of monitoring dataPP ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of revisions to the plan• Cost, schedule, and effort variance per plan revision• Schedule for development and maintenance of program plansPPQA ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Variance of objective process evaluations planned and performed• Variance of objective work product evaluations planned and performed• Schedule for objective evaluations208 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 235. QPM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Profile of subprocess attributes whose process performance provideinsight about the risk to, or are key contributors to, achieving projectobjectives (e.g., number selected for monitoring through statistical tech-niques, number currently being monitored, number whose process per-formance is stable)• Number of special causes of variation identified• Schedule of data collection, analysis, and reporting activities in a mea-surement and analysis cycle as it relates to quantitative managementactivitiesRD ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Cost, schedule, and effort expended for rework• Defect density of requirements specifications• Schedule for activities to develop a set of requirementsREQM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Requirements volatility (percentage of requirements changed)• Schedule for coordination of requirements• Schedule for analysis of a proposed requirements changeRSKM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of risks identified, managed, tracked, and controlled• Risk exposure and changes to the risk exposure for each assessed risk,and as a summary percentage of management reserve• Change activity for risk mitigation plans (e.g., processes, schedule,funding)ContinuesGP 2.8 Monitor and Control 209GGS&GPSWow! eBook <WoweBook.Com>
  • 236. Continued• Occurrence of unanticipated risks• Risk categorization volatility• Comparison of estimated versus actual risk mitigation effort and impact• Schedule for risk analysis activities• Schedule of actions for a specific mitigationSAM ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of changes made to the requirements for the supplier• Cost and schedule variance in accordance with the supplier agreement• Schedule for selecting a supplier and establishing an agreementTS ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Cost, schedule, and effort expended for rework• Percentage of requirements addressed in the product or product compo-nent design• Size and complexity of the product, product components, interfaces, anddocumentation• Defect density of technical solutions work products• Schedule for design activitiesVAL ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Number of validation activities completed (planned versus actual)• Validation problem report trends (e.g., number written, number closed)• Validation problem report aging (i.e., how long each problem report hasbeen open)• Schedule for a specific validation activity210 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 237. GP 2.9 Objectively Evaluate 211GGS&GPSVER ElaborationExamples of measures and work products used in monitoring and control-ling include the following:• Verification profile (e.g., the number of verifications planned and per-formed, and the defects found; or defects categorized by verificationmethod or type)• Number of defects detected by defect category• Verification problem report trends (e.g., number written, number closed)• Verification problem report status (i.e., how long each problem report hasbeen open)• Schedule for a specific verification activity• Peer review effectivenessGP 2.9 OBJECTIVELY EVALUATE ADHERENCEObjectively evaluate adherence of the process and selected work productsagainst the process description, standards, and procedures, and address non-compliance.The purpose of this generic practice is to provide credible assurancethat the process and selected work products are implemented asplanned and adhere to the process description, standards, and proce-dures. (See the definition of “objectively evaluate” in the glossary.)Refer to the Process and Product Quality Assurance process area for more infor-mation about objectively evaluating processes and work products.People not directly responsible for managing or performing theactivities of the process typically evaluate adherence. In many cases,adherence is evaluated by people in the organization, but external tothe process or project, or by people external to the organization. As aresult, credible assurance of adherence can be provided even duringtimes when the process is under stress (e.g., when the effort isbehind schedule, when the effort is over budget).CAR ElaborationExamples of activities reviewed include the following:• Determining causes of outcomes• Evaluating results of action plansExamples of work products reviewed include the following:• Action proposals selected for implementation• Causal analysis and resolution recordsWow! eBook <WoweBook.Com>
  • 238. CM ElaborationExamples of activities reviewed include the following:• Establishing baselines• Tracking and controlling changes• Establishing and maintaining the integrity of baselinesExamples of work products reviewed include the following:• Archives of baselines• Change request databaseDAR ElaborationExamples of activities reviewed include the following:• Evaluating alternatives using established criteria and methodsExamples of work products reviewed include the following:• Guidelines for when to apply a formal evaluation process• Evaluation reports containing recommended solutionsIPM ElaborationExamples of activities reviewed include the following:• Establishing, maintaining, and using the project’s defined process• Coordinating and collaborating with relevant stakeholders• Using the project’s shared vision• Organizing teamsExamples of work products reviewed include the following:• Project’s defined process• Project plans• Other plans that affect the project• Work environment standards• Shared vision statements• Team structure• Team charters212 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 239. MA ElaborationExamples of activities reviewed include the following:• Aligning measurement and analysis activities• Providing measurement resultsExamples of work products reviewed include the following:• Specifications of base and derived measures• Data collection and storage procedures• Analysis results and draft reportsOPD ElaborationExamples of activities reviewed include the following:• Establishing organizational process assets• Determining rules and guidelines for structuring and forming teamsExamples of work products reviewed include the following:• Organization’s set of standard processes• Descriptions of lifecycle models• Tailoring guidelines for the organization’s set of standard processes• Organization’s measurement data• Empowerment rules and guidelines for people and teams• Organizational process documentationOPF ElaborationExamples of activities reviewed include the following:• Determining process improvement opportunities• Planning and coordinating process improvement activities• Deploying the organization’s set of standard processes on projects attheir startupExamples of work products reviewed include the following:• Process improvement plans• Process action plans• Process deployment plans• Plans for the organization’s process appraisalsGP 2.9 Objectively Evaluate 213GGS&GPSWow! eBook <WoweBook.Com>
  • 240. OPM ElaborationExamples of activities reviewed include the following:• Analyzing process performance data to determine the organization’sability to meet identified business objectives• Selecting improvements using quantitative analysis• Deploying improvements• Measuring effectiveness of the deployed improvements using statisticaland other quantitative techniquesExamples of work products reviewed include the following:• Improvement proposals• Deployment plans• Revised improvement measures, objectives, priorities, and deploymentplans• Updated process documentation and training materialOPP ElaborationExamples of activities reviewed include the following:• Establishing process performance baselines and modelsExamples of work products reviewed include the following:• Process performance baselines• Organization’s quality and process performance objectives• Definitions of the selected measures of process performanceOT ElaborationExamples of activities reviewed include the following:• Identifying training needs and making training available• Providing necessary trainingExamples of work products reviewed include the following:• Organizational training tactical plan• Training materials and supporting artifacts• Instructor evaluation forms214 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 241. PI ElaborationExamples of activities reviewed include the following:• Establishing and maintaining a product integration strategy• Ensuring interface compatibility• Assembling product components and delivering the productExamples of work products reviewed include the following:• Product integration strategy• Product integration procedures and criteria• Acceptance documents for the received product components• Assembled product and product componentsPMC ElaborationExamples of activities reviewed include the following:• Monitoring project progress and performance against the project plan• Managing corrective actions to closureExamples of work products reviewed include the following:• Records of project progress and performance• Project review resultsPP ElaborationExamples of activities reviewed include the following:• Establishing estimates• Developing the project plan• Obtaining commitments to the project planExamples of work products reviewed include the following:• WBS• Project plan• Data management plan• Stakeholder involvement planGP 2.9 Objectively Evaluate 215GGS&GPSWow! eBook <WoweBook.Com>
  • 242. PPQA ElaborationExamples of activities reviewed include the following:• Objectively evaluating processes and work products• Tracking and communicating noncompliance issuesExamples of work products reviewed include the following:• Noncompliance reports• Evaluation logs and reportsQPM ElaborationExamples of activities reviewed include the following:• Managing the project using quality and process performance objectives• Managing selected subprocesses using statistical and other quantitativetechniquesExamples of work products reviewed include the following:• Compositions of the project’s defined process• Operational definitions of the measures• Process performance analyses reports• Collected measurementsRD ElaborationExamples of activities reviewed include the following:• Collecting stakeholder needs• Formulating product and product component functional and qualityattribute requirements• Formulating architectural requirements that specify how product compo-nents are organized and designed to achieve particular end-to-end func-tional and quality attribute requirements• Analyzing and validating product and product component requirementsExamples of work products reviewed include the following:• Product requirements• Product component requirements• Interface requirements• Definition of required functionality and quality attributes• Architecturally significant quality attribute requirements216 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 243. REQM ElaborationExamples of activities reviewed include the following:• Managing requirements• Ensuring alignment among project plans, work products, andrequirementsExamples of work products reviewed include the following:• Requirements• Requirements traceability matrixRSKM ElaborationExamples of activities reviewed include the following:• Establishing and maintaining a risk management strategy• Identifying and analyzing risks• Mitigating risksExamples of work products reviewed include the following:• Risk management strategy• Risk mitigation plansSAM ElaborationExamples of activities reviewed include the following:• Establishing and maintaining supplier agreements• Satisfying supplier agreementsExamples of work products reviewed include the following:• Plan for supplier agreement management• Supplier agreementsTS ElaborationExamples of activities reviewed include the following:• Selecting product component solutions• Developing product and product component designs• Implementing product component designsGP 2.9 Objectively Evaluate 217GGS&GPSWow! eBook <WoweBook.Com>
  • 244. Examples of work products reviewed include the following:• Technical data packages• Product, product component, and interface designs• Implemented designs (e.g., software code, fabricated productcomponents)• User, installation, operation, and maintenance documentationVAL ElaborationExamples of activities reviewed include the following:• Selecting the products and product components to be validated• Establishing and maintaining validation methods, procedures, andcriteria• Validating products or product componentsExamples of work products reviewed include the following:• Validation methods• Validation procedures• Validation criteriaVER ElaborationExamples of activities reviewed include the following:• Selecting work products for verification• Establishing and maintaining verification procedures and criteria• Performing peer reviews• Verifying selected work productsExamples of work products reviewed include the following:• Verification procedures and criteria• Peer review checklists• Verification reportsGP 2.10 REVIEW STATUS WITH HIGHER LEVEL MANAGEMENTReview the activities, status, and results of the process with higher level man-agement and resolve issues.The purpose of this generic practice is to provide higher level man-agement with the appropriate visibility into the process.218 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 245. Higher level management includes those levels of management inthe organization above the immediate level of management responsi-ble for the process. In particular, higher level management caninclude senior management. These reviews are for managers whoprovide the policy and overall guidance for the process and not forthose who perform the direct day-to-day monitoring and controllingof the process.Different managers have different needs for information about theprocess. These reviews help ensure that informed decisions on theplanning and performing of the process can be made. Therefore,these reviews are expected to be both periodic and event driven.OPF ElaborationThese reviews are typically in the form of a briefing presented to themanagement steering committee by the process group and theprocess action teams.Examples of presentation topics include the following:• Status of improvements being developed by process action teams• Results of pilots• Results of deployments• Schedule status for achieving significant milestones (e.g., readiness for anappraisal, progress toward achieving a targeted organizational maturitylevel or capability level profile)OPM ElaborationThese reviews are typically in the form of a briefing presented tohigher level management by those responsible for performanceimprovement.Examples of presentation topics include the following:• Improvement areas identified from analysis of current performancecompared to business objectives• Results of process improvement elicitation and analysis activities• Results from validation activities (e.g., pilots) compared to expectedbenefits• Performance data after deployment of improvements• Deployment cost, schedule, and risk• Risks of not achieving business objectivesGP 2.10 Higher Level Management 219GGS&GPSWow! eBook <WoweBook.Com>
  • 246. REQM ElaborationProposed changes to commitments to be made external to the organ-ization are reviewed with higher level management to ensure that allcommitments can be accomplished.RSKM ElaborationReviews of the project risk status are held on a periodic and eventdriven basis, with appropriate levels of management, to provide visi-bility into the potential for project risk exposure and appropriate cor-rective action.Typically, these reviews include a summary of the most criticalrisks, key risk parameters (such as likelihood and consequence of therisks), and the status of risk mitigation efforts.GG 3 INSTITUTIONALIZE A DEFINED PROCESSThe process is institutionalized as a defined process.GP 3.1 ESTABLISH A DEFINED PROCESSEstablish and maintain the description of a defined process.The purpose of this generic practice is to establish and maintain adescription of the process that is tailored from the organization’s setof standard processes to address the needs of a specific instantiation.The organization should have standard processes that cover theprocess area, as well as have guidelines for tailoring these standardprocesses to meet the needs of a project or organizational function.With a defined process, variability in how the processes are per-formed across the organization is reduced and process assets, data,and learning can be effectively shared.Refer to the Integrated Project Management process area for more informationabout establishing the project’s defined process.Refer to the Organizational Process Definition process area for more informa-tion about establishing standard processes and establishing tailoring criteriaand guidelines.The descriptions of the defined processes provide the basis forplanning, performing, and managing the activities, work products,and services associated with the process.Subpractices1. Select from the organization’s set of standard processes thoseprocesses that cover the process area and best meet the needs of theproject or organizational function.220 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 247. 2. Establish the defined process by tailoring the selected processesaccording to the organization’s tailoring guidelines.3. Ensure that the organization’s process objectives are appropriatelyaddressed in the defined process.4. Document the defined process and the records of the tailoring.5. Revise the description of the defined process as necessary.GP 3.2 COLLECT PROCESS RELATED EXPERIENCESCollect process related experiences derived from planning and performing theprocess to support the future use and improvement of the organization’sprocesses and process assets.The purpose of this generic practice is to collect process relatedexperiences, including information and artifacts derived from plan-ning and performing the process. Examples of process related experi-ences include work products, measures, measurement results,lessons learned, and process improvement suggestions. The informa-tion and artifacts are collected so that they can be included in theorganizational process assets and made available to those who are (orwho will be) planning and performing the same or similar processes.The information and artifacts are stored in the organization’s mea-surement repository and the organization’s process asset library.Examples of relevant information include the effort expended for the vari-ous activities, defects injected or removed in a particular activity, and les-sons learned.Refer to the Integrated Project Management process area for more informationabout contributing to organizational process assets.Refer to the Organizational Process Definition process area for more informa-tion about establishing organizational process assets.Subpractices1. Store process and product measures in the organization’s measure-ment repository.The process and product measures are primarily those measures thatare defined in the common set of measures for the organization’s setof standard processes.2. Submit documentation for inclusion in the organization’s processasset library.GP 3.2 Experiences 221GGS&GPSWow! eBook <WoweBook.Com>
  • 248. 3. Document lessons learned from the process for inclusion in theorganization’s process asset library.4. Propose improvements to the organizational process assets.CAR ElaborationExamples of process related experiences include the following:• Action proposals• Number of action plans that are open and for how long• Action plan status reportsCM ElaborationExamples of process related experiences include the following:• Trends in the status of configuration items• Configuration audit results• Change request aging reportsDAR ElaborationExamples process related experiences include the following:• Number of alternatives considered• Evaluation results• Recommended solutions to address significant issuesIPM ElaborationExamples of process related experiences include the following:• Project’s defined process• Number of tailoring options exercised by the project to create its definedprocess• Interface coordination issue trends (i.e., number identified, numberclosed)• Number of times the process asset library is accessed for assets related toproject planning by project members• Records of expenses related to holding face-to-face meetings versusholding meetings using collaborative equipment such as teleconferenc-ing and videoconferencing• Project shared vision• Team charters222 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 249. MA ElaborationExamples of process related experiences include the following:• Data currency status• Results of data integrity tests• Data analysis reportsOPD ElaborationExamples of process related experiences include the following:• Submission of lessons learned to the organization’s process asset library• Submission of measurement data to the organization’s measurementrepository• Status of the change requests submitted to modify the organization’sstandard process• Record of non-standard tailoring requestsOPF ElaborationExamples of process related experiences include the following:• Criteria used to prioritize candidate process improvements• Appraisal findings that address strengths and weaknesses of the organi-zation’s processes• Status of improvement activities against the schedule• Records of tailoring the organization’s set of standard processes andimplementing them on identified projectsOPM ElaborationExamples of process related experiences include the following:• Lessons learned captured from analysis of process performance datacompared to business objectives• Documented measures of the costs and benefits resulting from imple-menting and deploying improvements• Report of a comparison of similar development processes to identify thepotential for improving efficiencyGP 3.2 Experiences 223GGS&GPSWow! eBook <WoweBook.Com>
  • 250. OPP ElaborationExamples of process related experiences include the following:• Process performance baselines• Percentage of measurement data that is rejected because of inconsisten-cies with the process performance measurement definitionsOT ElaborationExamples of process related experiences include the following:• Results of training effectiveness surveys• Training program performance assessment results• Course evaluations• Training requirements from an advisory groupPI ElaborationExamples of process related experiences include the following:• Records of the receipt of product components, exception reports, confir-mation of configuration status, and results of readiness checking• Percentage of total development effort spent in product integration(actual to date plus estimate to complete)• Defects found in the product and test environment during productintegration• Problem reports resulting from product integrationPMC ElaborationExamples of process related experiences include the following:• Records of significant deviations• Criteria for what constitutes a deviation• Corrective action resultsPP ElaborationExamples of process related experiences include the following:• Project data library structure• Project attribute estimates• Risk impacts and probability of occurrence224 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 251. PPQA ElaborationExamples of process related experiences include the following:• Evaluation logs• Quality trends• Noncompliance reports• Status reports of corrective actions• Cost of quality reports for the projectQPM ElaborationExamples of process related experiences include the following:• Records of quantitative management data from the project, includingresults from the periodic review of the process performance of the sub-processes selected for management against established interim objec-tives of the project• Suggested improvements to process performance modelsRD ElaborationExamples of process related experiences include the following:• List of the requirements for a product that are found to be ambiguous• Number of requirements introduced at each phase of the projectlifecycle• Lessons learned from the requirements allocation processREQM ElaborationExamples of process related experiences include the following:• Requirements traceability matrix• Number of unfunded requirements changes after baselining• Lessons learned in resolving ambiguous requirementsRSKM ElaborationExamples of process related experiences include the following:• Risk parameters• Risk categories• Risk status reportsGP 3.2 Experiences 225GGS&GPSWow! eBook <WoweBook.Com>
  • 252. SAM ElaborationExamples of process related experiences include the following:• Results of supplier reviews• Trade studies used to select suppliers• Revision history of supplier agreements• Supplier performance reportsTS ElaborationExamples of process related experiences include the following:• Results of the make, buy, or reuse analysis• Design defect density• Results of applying new methods and toolsVAL ElaborationExamples of process related experiences include the following:• Product component prototype• Percentage of time the validation environment is available• Number of product defects found through validation per developmentphase• Validation analysis reportVER ElaborationExamples of process related experiences include the following:• Peer review records that include conduct time and average preparationtime• Number of product defects found through verification per developmentphase• Verification and analysis reportApplying Generic PracticesGeneric practices are components that can be applied to all processareas. Think of generic practices as reminders. They serve the pur-pose of reminding you to do things right and are expected modelcomponents.226 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 253. For example, consider the generic practice, “Establish and main-tain the plan for performing the process” (GP 2.2). When applied tothe Project Planning process area, this generic practice reminds youto plan the activities involved in creating the plan for the project.When applied to the Organizational Training process area, this samegeneric practice reminds you to plan the activities involved in devel-oping the skills and knowledge of people in the organization.Process Areas that Support Generic PracticesWhile generic goals and generic practices are the model componentsthat directly address the institutionalization of a process across theorganization, many process areas likewise address institutionaliza-tion by supporting the implementation of the generic practices.Knowing these relationships will help you effectively implement thegeneric practices.Such process areas contain one or more specific practices thatwhen implemented can also fully implement a generic practice orgenerate a work product that is used in the implementation of ageneric practice.An example is the Configuration Management process area andGP 2.6, “Place selected work products of the process under appropri-ate levels of control.” To implement the generic practice for one ormore process areas, you might choose to implement the Configura-tion Management process area, all or in part, to implement thegeneric practice.Another example is the Organizational Process Definition processarea and GP 3.1, “Establish and maintain the description of a definedprocess.” To implement this generic practice for one or more processareas, you should first implement the Organizational Process Defini-tion process area, all or in part, to establish the organizationalprocess assets that are needed to implement the generic practice.Table 7.2 describes (1) the process areas that support the imple-mentation of generic practices and (2) the recursive relationshipsbetween generic practices and their closely related process areas.Both types of relationships are important to remember duringprocess improvement to take advantage of the natural synergies thatexist between the generic practices and their related process areas.Given the dependencies that generic practices have on theseprocess areas, and given the more holistic view that many of theseprocess areas provide, these process areas are often implementedearly, in whole or in part, before or concurrent with implementingthe associated generic practices.Process Areas that Support Generic Practices 227GGS&GPSWow! eBook <WoweBook.Com>
  • 254. 228 PART TWO THE PROCESS AREASTABLE 7.2 Generic Practice and Process Area RelationshipsRoles of Process Areas in How the Generic PracticeImplementation of the Recursively Applies to ItsGeneric Practice Generic Practice Related Process Area(s)1GP 2.2 Project Planning: The project GP 2.2 applied to the projectPlan the Process planning process can implement planning process can beGP 2.2 in full for all project-related characterized as “plan the plan”process areas (except for Project and covers planning projectPlanning itself). planning activities.GP 2.3 Project Planning: The part of theProvide Resources project planning process thatimplements Project Planning SP 2.4,GP 2.4 “PlantheProject’sResources,”supportsAssign Responsibility theimplementationofGP2.3andGP2.4for all project-related process areas(except perhaps initially for ProjectPlanning itself) by identifying neededprocesses, roles, and responsibilitiestoensuretheproperstaffing,facilities,equipment, and other assets neededby the project are secured.GP 2.5 Organizational Training: GP 2.5 applied to theTrain People Theorganizationaltrainingprocess organizational training processsupportstheimplementationofGP2.5 covers training for performingas applied to all process areas by the organizational trainingmaking the training that addresses activities, which addresses thestrategicororganization-widetraining skills required to manage, create,needs available to those who will and accomplish the training.perform or support the process.Project Planning: The part of theproject planning process thatimplements Project Planning SP 2.5,“PlanNeededKnowledgeandSkills,”and the organizational trainingprocess, supports the implementationofGP2.5infullforallproject-relatedprocess areas.GP 2.6 ConfigurationManagement: GP2.6appliedtotheconfigurationControl Work Theconfigurationmanagement managementprocesscoversProducts processcanimplementGP2.6infull changeandversioncontrolfortheforallproject-relatedprocessareas workproductsproducedbyaswellassomeoftheorganizational configurationmanagementprocessareas. activities.1. When the relationship between a generic practice and a process area is less direct, the risk of con-fusion is reduced; therefore, we do not describe all recursive relationships in the table (e.g., forgeneric practices 2.3, 2.4, and 2.10).Wow! eBook <WoweBook.Com>
  • 255. Process Areas that Support Generic Practices 229GGS&GPSTABLE 7.2 Generic Practice and Process Area Relationships (Continued)Roles of Process Areas in How the Generic PracticeImplementation of the Recursively Applies to ItsGeneric Practice Generic Practice Related Process Area(s)1GP2.7 ProjectPlanning:Thepartofthe GP2.7appliedtotheprojectIdentifyandInvolve projectplanningprocessthat planningprocesscoverstheRelevantStakeholders implementsProjectPlanningSP2.6, involvementofrelevant“PlanStakeholderinvolvement,” stakeholdersinprojectplanningcanimplementthestakeholder activities.identificationpart(firsttwosubpractices)ofGP2.7infullfor GP2.7appliedtotheprojectallproject-relatedprocessareas. monitoringandcontrolprocesscoverstheinvolvementofrelevantProjectMonitoringandControl: stakeholdersinprojectmonitoringThepartoftheprojectmonitoring andcontrolactivities.andcontrolprocessthatimplementsProjectMonitoringandControlSP1.5, GP2.7appliedtotheintegrated“MonitorStakeholderInvolvement,” projectmanagementprocesscanaidinimplementingthethird coverstheinvolvementofrelevantsubpracticeofGP2.7forall stakeholdersinintegratedprojectproject-relatedprocessareas. managementactivities.IntegratedProjectManagement:ThepartoftheintegratedprojectmanagementprocessthatimplementsIntegratedProjectManagementSP2.1,“ManageStakeholderInvolvement,”canaidinimplementingthethirdsubpracticeofGP2.7forallproject-relatedprocessareas.GP 2.8 Project Monitoring and Control: GP 2.8 applied to the projectMonitor and Control The project monitoring and control monitoring and control processthe Process process can implement GP 2.8 in full covers the monitoring andfor all project-related process areas. controlling of the project’s monitorand control activities.Measurement and Analysis: For allprocesses, not just project-relatedprocesses, the Measurement andAnalysis process area providesgeneral guidance about measuring,analyzing, and recording informationthat can be used in establishingmeasures for monitoring actualperformance of the process.GP2.9 ProcessandProductQuality GP2.9appliedtotheprocessandObjectively Assurance:Theprocessandproduct productqualityassuranceprocessEvaluateAdherence qualityassuranceprocesscan coverstheobjectiveevaluationofimplementGP2.9infullforallprocess qualityassuranceactivitiesandareas(exceptperhapsforProcessand selectedworkproductsProductQualityAssuranceitself).ContinuesWow! eBook <WoweBook.Com>
  • 256. 230 PART TWO THE PROCESS AREASTABLE 7.2 Generic Practice and Process Area Relationships (Continued)Roles of Process Areas in How the Generic PracticeImplementation of the Recursively Applies to ItsGeneric Practice Generic Practice Related Process Area(s)1GP 2.10 Project Monitoring and Control:Review Status with The part of the project monitoringHigher Level and control process that implementsManagement Project Monitoring and Control SP 1.6,“Conduct Progress Reviews,” andSP 1.7, “Conduct Milestone Reviews,”supports the implementation ofGP 2.10 for all project-related processareas, perhaps in full, depending onhigher level management involvementin these reviews.GP 3.1 IntegratedProjectManagement: GP3.1appliedtotheintegratedEstablishaDefined Thepartoftheintegratedproject projectmanagementprocessProcess managementprocessthatimplements coversestablishingdefinedIntegratedProjectManagementSP1.1, processesforintegratedproject“EstablishtheProject’sDefined managementactivities.Process,”canimplementGP3.1infullforallproject-relatedprocessareas.OrganizationalProcessDefinition:For allprocesses,notjustproject-relatedprocesses,theorganizationalprocessdefinitionprocessestablishestheorganizationalprocessassetsneededtoimplementGP3.1.GP 3.2 IntegratedProjectManagement: GP3.2appliedtotheintegratedCollect Process Thepartoftheintegratedproject projectmanagementprocessRelatedExperiences managementprocessthatimplements coverscollectingprocessrelatedIntegratedProjectManagementSP1.7, experiencesderivedfromplanning“ContributetotheOrganizational andperformingintegratedProcessAssets,”canimplementGP3.2 projectmanagementactivities.inpartorfullforallproject-relatedprocessareas.OrganizationalProcessFocus:ThepartoftheorganizationalprocessfocusprocessthatimplementsOrganizationalProcessFocusSP3.4,“IncorporateExperiencesintotheOrganizationalProcessAssets,”canimplementGP3.2inpartorfullforallprocessareas.Organizational Process Definition:For all processes, the organizationalprocess definition process establishesthe organizational process assetsneeded to implement GP 3.2.Wow! eBook <WoweBook.Com>
  • 257. There are also a few situations where the result of applying ageneric practice to a particular process area would seem to make awhole process area redundant, but, in fact, it does not. It can be natu-ral to think that applying GP 3.1, “Establish a Defined Process,” tothe Project Planning and Project Monitoring and Control processareas gives the same effect as the first specific goal of Integrated Proj-ect Management, “Use the Project’s Defined Process.”Although it is true that there is some overlap, the application ofthe generic practice to these two process areas provides definedprocesses covering project planning and project monitoring and con-trol activities. These defined processes do not necessarily cover sup-port activities (e.g., configuration management), other projectmanagement processes (e.g., integrated project management), orother processes. In contrast, the project’s defined process, providedby the Integrated Project Management process area, covers all appro-priate processes.Process Areas that Support Generic Practices 231GGS&GPSWow! eBook <WoweBook.Com>
  • 258. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 259. CAUSAL ANALYSIS AND RESOLUTIONA Support Process Area at Maturity Level 5PurposeThe purpose of Causal Analysis and Resolution (CAR) is to identifycauses of selected outcomes and take action to improve processperformance.Introductory NotesCausal analysis and resolution improves quality and productivity bypreventing the introduction of defects or problems and by identifyingand appropriately incorporating the causes of superior processperformance.The Causal Analysis and Resolution process area involves the fol-lowing activities:• Identifying and analyzing causes of selected outcomes. The selectedoutcomes can represent defects and problems that can be preventedfrom happening in the future or successes that can be implemented inprojects or the organization.• Taking actions to complete the following:• Remove causes and prevent the recurrence of those types of defectsand problems in the future• Proactively analyze data to identify potential problems and preventthem from occurring• Incorporate the causes of successes into the process to improvefuture process performanceReliance on detecting defects and problems after they have beenintroduced is not cost effective. It is more effective to prevent defectsand problems by integrating Causal Analysis and Resolution activi-ties into each phase of the project.233CARTI PCAR helps you establish a dis-ciplined approach to analyzingthe causes of outcomes, bothpositive and negative, of yourprocesses. You can analyzedefects or defect trends, prob-lems such as schedule over-runs or inter-organizationalconflicts, as well as positiveoutcomes that you want toreplicate elsewhere.H I NTIntegrating CAR activities intoeach project phase will help(1) prevent many defects frombeing introduced and (2) facili-tate repetition of those condi-tions that enable superiorperformance, thus improvingthelikelihoodofprojectsuccess.Wow! eBook <WoweBook.Com>
  • 260. Since similar outcomes may have been previously encountered inother projects or in earlier phases or tasks of the current project,Causal Analysis and Resolution activities are mechanisms for com-municating lessons learned among projects.Types of outcomes encountered are analyzed to identify trends.Based on an understanding of the defined process and how it isimplemented, root causes of these outcomes and future implicationsof them are determined.Since it is impractical to perform causal analysis on all outcomes,targets are selected by tradeoffs on estimated investments and esti-mated returns of quality, productivity, and cycle time.Measurement and analysis processes should already be in place.Existing defined measures can be used, though in some instancesnew measurement definitions, redefinitions, or clarified definitionsmay be needed to analyze the effects of a process change.Refer to the Measurement and Analysis process area for more information aboutaligning measurement and analysis activities and providing measurementresults.Causal Analysis and Resolution activities provide a mechanismfor projects to evaluate their processes at the local level and look forimprovements that can be implemented.When improvements are judged to be effective, the information issubmitted to the organizational level for potential deployment in theorganizational processes.The specific practices of this process area apply to a process thatis selected for quantitative management. Use of the specific practicesof this process area can add value in other situations, but the resultsmay not provide the same degree of impact to the organization’s qual-ity and process performance objectives.Related Process AreasRefer to the Measurement and Analysis process area for more information aboutaligning measurement and analysis activities and providing measurementresults.Refer to the Organizational Performance Management process area for moreinformation about selecting and implementing improvements for deployment.Refer to the Quantitative Project Management process area for more informa-tion about quantitatively managing the project to achieve the project’s estab-lished quality and process performance objectives.234 PART TWO THE PROCESS AREASH I NTYou also can apply causalanalysis to outcomes of con-cern to senior management.H I NTIt is impossible to analyze alloutcomes; instead, focus onoutcomes that have the largestrisk or present the greatestopportunity.TI PSuccessful implementation ofCAR requires significant man-agement commitment andprocess maturity to ensure thatprocess data is accurately andconsistently recorded, causalanalysis meetings are ade-quately supported, and CARactivities are consistently per-formed across the organization.X- R E FCausal analysis is mentionedelsewhere in CMMI: in an IPMSP 1.5 subpractice to addresscauses of selected issues thatcan affect project objectives;in the notes of OPM SP 1.3Identify Potential Areas forImprovement; in QPM SP 2.3Perform Root Cause Analysis;and as an example workproduct in VER SP 3.2 Ana-lyze Verification Results.Wow! eBook <WoweBook.Com>
  • 261. Specific Goal and Practice SummarySG 1 Determine Causes of Selected OutcomesSP 1.1 Select Outcomes for AnalysisSP 1.2 Analyze CausesSG 2 Address Causes of Selected OutcomesSP 2.1 Implement Action ProposalsSP 2.2 Evaluate the Effect of Implemented ActionsSP 2.3 Record Causal Analysis DataSpecific Practices by GoalSG 1 DETERMINE CAUSES OF SELECTED OUTCOMESRoot causes of selected outcomes are systematically determined.A root cause is an initiating element in a causal chain which leads toan outcome of interest.SP 1.1 SELECT OUTCOMES FOR ANALYSISSelect outcomes for analysis.This activity could be triggered by an event (reactive) or could beplanned periodically, such as at the beginning of a new phase or task(proactive).Example Work Products1. Data to be used in the initial analysis2. Initial analysis results data3. Outcomes selected for further analysisSubpractices1. Gather relevant data.Examples of relevant data include the following:• Defects reported by customers or end users• Defects found in peer reviews or testing• Productivity measures that are higher than expected• Project management problem reports requiring corrective action• Process capability problems• Earned value measurements by process (e.g., cost performance index)• Resource throughput, utilization, or response time measurements• Service fulfillment or service satisfaction problemsCausal Analysis and Resolution 235CARH I NTLet your data help you deter-mine which outcomes, ifaddressed, will realize the mostbenefit to your organization.Process Performance Baselines(PPBs) and Models (PPMs) mayhelp in this determination.Wow! eBook <WoweBook.Com>
  • 262. 236 PART TWO THE PROCESS AREASTI PIt is ineffective to look at everyoutcome. Therefore, youshould establish criteria to helpyou prioritize and categorizeoutcomes.TI PAn example method for analyz-ing and categorizing defects isOrthogonal Defect Classifica-tion (see Wikipedia), whichprovides standard taxonomiesfor classifying defects and theirresolution.H I NTTo identify actions that addressan outcome, you need tounderstand its root causes.TI PAn action proposal typicallydocuments the outcome to beinvestigated, its causes, andspecific actions that, whentaken, will either mitigate thecauses to prevent the outcomefrom reoccurring or increasethe likelihood that conditionsconducive to superior perform-ance will occur.X- R E FAction proposals are priori-tized, selected, and imple-mented in SG 2.2. Determine which outcomes to analyze further.When determining which outcomes to analyze further, consider theirsource, impact, frequency of occurrence, similarity, the cost of analy-sis, the time and resources needed, safety considerations, etc.Examples of methods for selecting outcomes include the following:• Pareto analysis• Histograms• Box and whisker plots for attributes• Failure mode and effects analysis (FMEA)• Process capability analysis3. Formally define the scope of the analysis, including a clear defini-tion of the improvement needed or expected, stakeholders affected,target affected, etc.Refer to the Decision Analysis and Resolution process area for more infor-mation about analyzing possible decisions using a formal evaluationprocess that evaluates identified alternatives against established criteria.SP 1.2 ANALYZE CAUSESPerform causal analysis of selected outcomes and propose actions to addressthem.The purpose of this analysis is to define actions that will addressselected outcomes by analyzing relevant outcome data and produc-ing action proposals for implementation.Example Work Products1. Root cause analysis results2. Action proposalSubpractices1. Conduct causal analysis with those who are responsible for perform-ing the task.Causal analysis is performed, typically in meetings, with those whounderstand the selected outcome under study. Those who have thebest understanding of the selected outcome are typically those whoare responsible for performing the task. The analysis is most effectivewhen applied to real time data, as close as possible to the event whichtriggered the outcome.Wow! eBook <WoweBook.Com>
  • 263. Causal Analysis and Resolution 237CARTI PThere are secondary benefitsto causal analysis meetings.Participants develop an appre-ciation for how upstream activ-ities affect downstreamactivities, as well as a sense ofresponsibility and accountabil-ity for outcomes that might oth-erwise remain unanalyzed.Examples of when to perform causal analysis include the following:• When a stable subprocess does not meet its specified quality andprocess performance objectives, or when a subprocess needs to bestabilized• During the task, if and when problems warrant a causal analysis meeting• When a work product exhibits an unexpected deviation from itsrequirements• When more defects than anticipated escape from earlier phases to thecurrent phase• When process performance exceeds expectations• At the start of a new phase or taskRefer to the Quantitative Project Management process area for moreinformation about performing root cause analysis.2. Analyze selected outcomes to determine their root causes.Analysis of process performance baselines and models can aid in theidentification of potential root causes.Depending on the type and number of outcomes, it can be beneficialto look at the outcomes in several ways to ensure all potential rootcauses are investigated. Consider looking at individual outcomes aswell as grouping the outcomes.Examples of methods to determine root causes include the following:• Cause-and-effect (fishbone) diagrams• Check sheets3. Combine selected outcomes into groups based on their root causes.In some cases, outcomes can be influenced by multiple root causes.Examples of cause groups or categories include the following:• Inadequate training and skills• Breakdown of communication• Not accounting for all details of a task• Making mistakes in manual procedures (e.g., keyboard entry)• Process deficiencyWhere appropriate, look for trends or symptoms in or acrossgroupings.4. Create an action proposal that documents actions to be taken to pre-vent the future occurrence of similar outcomes or to incorporatebest practices into processes.TI PIn their book Managing theUnexpected: Assuring High Per-formance in an Age of Complex-ity, Weick and Sutcliffe identify“mindfulness” qualities impor-tant in high-reliability organiza-tions including preoccupationwith failure and reluctance tosimplify. These imply attentionto detail when communicatingabout an individual situationas well as seeking to under-stand possible systemic causesto a range of apparently unre-lated small problems.H I NTYou develop cause-and-effectdiagrams using iterative brain-storming (i.e., the “Five Whys”).This process may terminatewhen it reaches root causesoutside the experience of thegroup or outside the control ofits management.Wow! eBook <WoweBook.Com>
  • 264. 238 PART TWO THE PROCESS AREASTI PIn his book The Checklist Mani-festo: How to Get ThingsRight,Atul Gawande describes therole that properly designedchecklists can play in prevent-ing common problems. Herelates his experiences indesigning such checklists andthe impact they have had insignificantly reducing compli-cations and fatalities fromsurgery.Process performance models can support cost benefit analysis ofaction proposals through prediction of impacts and return oninvestment.Examples of proposed preventative actions include changes to thefollowing:• The process in question• Training• Tools• Methods• Work productsExamples of incorporating best practices include the following:• Creating activity checklists, which reinforce training or communicationsrelated to common problems and techniques for preventing them• Changing a process so that error-prone steps do not occur• Automating all or part of a process• Reordering process activities• Adding process steps, such as task kickoff meetings to review commonproblems as well as actions to prevent themAn action proposal usually documents the following:• Originator of the action proposal• Description of the outcome to be addressed• Description of the cause• Cause category• Phase identified• Description of the action• Time, cost, and other resources required to implement the actionproposal• Expected benefits from implementing the action proposal• Estimated cost of not fixing the problem• Action proposal categorySG 2 ADDRESS CAUSES OF SELECTED OUTCOMESRoot causes of selected outcomes are systematically addressed.Projects operating according to a well-defined process systematicallyanalyze where improvements are needed and implement processchanges to address root causes of selected outcomes.TI PThe focus of this goal is imple-menting process changes thataddress root causes of selectedoutcomes, both positive andnegative.Wow! eBook <WoweBook.Com>
  • 265. SP 2.1 IMPLEMENT ACTION PROPOSALSImplement selected action proposals developed in causal analysis.Action proposals describe tasks necessary to address root causes ofanalyzed outcomes to prevent or reduce the occurrence or recurrenceof negative outcomes, or incorporate realized successes. Action plansare developed and implemented for selected action proposals. Onlychanges that prove to be of value should be considered for broadimplementation.Example Work Products1. Action proposals selected for implementation2. Action plansSubpractices1. Analyze action proposals and determine their priorities.Criteria for prioritizing action proposals include the following:• Implications of not addressing the outcome• Cost to implement process improvements to address the outcome• Expected impact on qualityProcess performance models can be used to help identify interactionsamong multiple action proposals.2. Select action proposals to be implemented.Refer to the Decision Analysis and Resolution process area for more infor-mation about analyzing possible decisions using a formal evaluationprocess that evaluates identified alternatives against established criteria.3. Create action plans for implementing the selected action proposals.Examples of information provided in an action plan include the following:• Person responsible for implementation• Detailed description of the improvement• Description of the affected areas• People who are to be kept informed of status• Schedule• Cost expended• Next date that status will be reviewed• Rationale for key decisions• Description of implementation actionsCausal Analysis and Resolution 239CARWow! eBook <WoweBook.Com>
  • 266. 4. Implement action plans.To implement action plans, the following tasks should be performed:• Make assignments.• Coordinate the people doing the work.• Review the results.• Track action items to closure.Experiments may be conducted for particularly complex changes.Examples of experiments include the following:• Using a temporarily modified process• Using a new toolActions may be assigned to members of the causal analysis team,members of the project team, or other members of the organization.5. Look for similar causes that may exist in other processes and workproducts and take action as appropriate.SP 2.2 EVALUATE THE EFFECT OF IMPLEMENTED ACTIONSEvaluate the effect of implemented actions on process performance.Refer to the Quantitative Project Management process area for more informa-tion about selecting measures and analytic techniques.Once the changed process is deployed across the project, the effect ofchanges is evaluated to verify that the process change has improvedprocess performance.Example Work Products1. Analysis of process performance and change in process performanceSubpractices1. Measure and analyze the change in process performance of the proj-ect’s affected processes or subprocesses.This subpractice determines whether the selected change has posi-tively influenced process performance and by how much.An example of a change in the process performance of the project’sdefined design process would be a change in the predicted ability of thedesign to meet the quality and process performance objectives.Another example would be a change in the defect density of the designdocumentation, as statistically measured through peer reviews before andafter the improvement has been made. On a statistical process controlchart, this change in process performance would be represented by animprovement in the mean, a reduction in variation, or both.240 PART TWO THE PROCESS AREASX- R E FFor more information ondesigning experiments tounderstand the impact of cer-tain changes, consult goodreferences on Six Sigma andExperimental Design.H I NTWhen a resolution has moregeneral applicability, don’t doc-ument it in a “lessons learned”document; document it in animprovement proposal.X- R E FFor more information onimprovements proposals andsuggestions, see OPF SP 2.4and OPM SP 2.1.H I NTUse the measures associatedwith a process or subprocess(perhaps supplemented byother measures) to evaluatethe effect of changes.Wow! eBook <WoweBook.Com>
  • 267. Statistical and other quantitative techniques (e.g., hypothesis testing)can be used to compare the before and after baselines to assess thestatistical significance of the change.2. Determine the impact of the change on achieving the project’s qual-ity and process performance objectives.This subpractice determines whether the selected change has posi-tively influenced the ability of the project to meet its quality andprocess performance objectives by understanding how changes in theprocess performance data have affected the objectives. Process per-formance models can aid in the evaluation through prediction ofimpacts and return on investment.3. Determine and document appropriate actions if the process or sub-process improvements did not result in expected project benefits.SP 2.3 RECORD CAUSAL ANALYSIS DATARecord causal analysis and resolution data for use across projects and theorganization.Example Work Products1. Causal analysis and resolution records2. Organizational improvement proposalsSubpractices1. Record causal analysis data and make the data available so that otherprojects can make appropriate process changes and achieve similarresults.Record the following:• Data on outcomes that were analyzed• Rationale for decisions• Action proposals from causal analysis meetings• Action plans resulting from action proposals• Cost of analysis and resolution activities• Measures of changes to the process performance of the definedprocess resulting from resolutions2. Submit process improvement proposals for the organization whenthe implemented actions are effective for the project as appropriate.When improvements are judged to be effective, the information canbe submitted to the organizational level for potential inclusion in theorganizational processes.Refer to the Organizational Performance Management process area formore information about selecting improvements.Causal Analysis and Resolution 241CARH I NTCollect data to know that youare improving project perform-ance relative to your objec-tives, to know that you haveprevented selected problemsfrom reoccurring (or haveenabled conditions conduciveto superior performance torecur), and to provide suffi-cient context for organizationalevaluation of improvementproposals for possible deploy-ment across the organization(OPM SP 2.2).Wow! eBook <WoweBook.Com>
  • 268. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 269. CONFIGURATION MANAGEMENTA Support Process Area at Maturity Level 2PurposeThe purpose of Configuration Management (CM) is to establish andmaintain the integrity of work products using configuration identifi-cation, configuration control, configuration status accounting, andconfiguration audits.Introductory NotesThe Configuration Management process area involves the followingactivities:• Identifying the configuration of selected work products that composebaselines at given points in time• Controlling changes to configuration items• Building or providing specifications to build work products from theconfiguration management system• Maintaining the integrity of baselines• Providing accurate status and current configuration data to develop-ers, end users, and customersThe work products placed under configuration managementinclude the products that are delivered to the customer, designatedinternal work products, acquired products, tools, and other itemsused in creating and describing these work products. (See the defini-tion of “configuration management” in the glossary.)243CMTI PBecause this is a supportprocess area, it is up to theproject and organization todecide which work productsare subject to CM, and the levelof control needed.H I NTCM should capture enoughinformation to identify andmaintain the configuration itemafter those who have devel-oped it have gone.Wow! eBook <WoweBook.Com>
  • 270. Examples of work products that can be placed under configuration man-agement include the following:• Hardware and equipment• Drawings• Product specifications• Tool configurations• Code and libraries• Compilers• Test tools and test scripts• Installation logs• Product data files• Product technical publications• Plans• User stories• Iteration backlogs• Process descriptions• Requirements• Architecture documentation and design data• Product line plans, processes, and core assetsAcquired products may need to be placed under configurationmanagement by both the supplier and the project. Provisions forconducting configuration management should be established in sup-plier agreements. Methods to ensure that data are complete and con-sistent should be established and maintained.Refer to the Supplier Agreement Management process area for more informationabout establishing supplier agreements.Configuration management of work products can be performed atseveral levels of granularity. Configuration items can be decomposedinto configuration components and configuration units. Only theterm “configuration item” is used in this process area. Therefore, inthese practices, “configuration item” may be interpreted as “configu-ration component” or “configuration unit” as appropriate. (See thedefinition of “configuration item” in the glossary.)Baselines provide a stable basis for the continuing evolution ofconfiguration items.An example of a baseline is an approved description of a product thatincludes internally consistent versions of requirements, requirementtraceability matrices, design, discipline-specific items, and end-userdocumentation.244 PART TWO THE PROCESS AREASTI POther items may include repairmanuals and test results thatprovide additional insight intothe work product.H I NTTypically, you determine thelevels of granularity duringplanning. Select the configura-tion items to define for CMbased on technical and busi-ness needs.Wow! eBook <WoweBook.Com>
  • 271. Baselines are added to the configuration management system asthey are developed. Changes to baselines and the release of workproducts built from the configuration management system are sys-tematically controlled and monitored via the configuration control,change management, and configuration auditing functions of config-uration management.This process area applies not only to configuration managementon projects but also to configuration management of organizationalwork products such as standards, procedures, reuse libraries, andother shared supporting assets.Configuration management is focused on the rigorous control ofthe managerial and technical aspects of work products, including thedelivered product or service.This process area covers the practices for performing the configu-ration management function and is applicable to all work productsthat are placed under configuration management.For product lines, configuration management involves additionalconsiderations due to the sharing of core assets across the productsin the product line and across multiple versions of core assets andproducts. (See the definition of “product line” in the glossary.)In Agile environments, configuration management (CM) is importantbecause of the need to support frequent change, frequent builds (typicallydaily), multiple baselines, and multiple CM supported workspaces (e.g., forindividuals, teams, and even for pair-programming). Agile teams may getbogged down if the organization doesn’t: 1) automate CM (e.g., buildscripts, status accounting, integrity checking) and 2) implement CM as asingle set of standard services. At its start, an Agile team should identify theindividual who will be responsible to ensure CM is implemented correctly.At the start of each iteration, CM support needs are re-confirmed. CM iscarefully integrated into the rhythms of each team with a focus on mini-mizing team distraction to get the job done. (See “Interpreting CMMI WhenUsing Agile Approaches” in Part I.)Related Process AreasRefer to the Project Monitoring and Control process area for more informationabout monitoring the project against the plan and managing corrective action toclosure.Refer to the Project Planning process area for more information about develop-ing a project plan.Configuration Management 245CMH I NTReview and approve baselinesbefore they are added to (orpromoted within) the CMsystem.TI PAnything important enough toensure its integrity can be sub-ject to CM practices.Wow! eBook <WoweBook.Com>
  • 272. 246 PART TWO THE PROCESS AREASSpecific Goal and Practice SummarySG 1 Establish BaselinesSP 1.1 Identify Configuration ItemsSP 1.2 Establish a Configuration Management SystemSP 1.3 Create or Release BaselinesSG 2 Track and Control ChangesSP 2.1 Track Change RequestsSP 2.2 Control Configuration ItemsSG 3 Establish IntegritySP 3.1 Establish Configuration Management RecordsSP 3.2 Perform Configuration AuditsSpecific Practices by GoalSG 1 ESTABLISH BASELINESBaselines of identified work products are established.Specific practices to establish baselines are covered by this specificgoal. The specific practices under the Track and Control Changesspecific goal serve to maintain the baselines. The specific practices ofthe Establish Integrity specific goal document and audit the integrityof the baselines.SP 1.1 IDENTIFY CONFIGURATION ITEMSIdentify configuration items, components, and related work products to beplaced under configuration management.Configuration identification is the selection and specification of thefollowing:• Products delivered to the customer• Designated internal work products• Acquired products• Tools and other capital assets of the project’s work environment• Other items used in creating and describing these work productsConfiguration items can include hardware, equipment, and tangi-ble assets as well as software and documentation. Documentationcan include requirements specifications and interface documents.Other documents that serve to identify the configuration of the prod-uct or service, such as test results, may also be included.Wow! eBook <WoweBook.Com>
  • 273. A “configuration item” is an entity designated for configurationmanagement, which may consist of multiple related work productsthat form a baseline. This logical grouping provides ease of identifi-cation and controlled access. The selection of work products for con-figuration management should be based on criteria establishedduring planning.Example Work Products1. Identified configuration itemsSubpractices1. Select configuration items and work products that compose thembased on documented criteria.Example criteria for selecting configuration items at the appropriate workproduct level include the following:• Work products that can be used by two or more groups• Work products that are expected to change over time either because oferrors or changes in requirements• Work products that are dependent on each other (i.e., a change in onemandates a change in the others)• Work products critical to project successExamples of work products that may be part of a configuration iteminclude the following:• Design• Test plans and procedures• Test results• Interface descriptions• Drawings• Source code• User stories or story cards• The declared business case, logic, or value• Tools (e.g., compilers)• Process descriptions• Requirements2. Assign unique identifiers to configuration items.3. Specify the important characteristics of each configuration item.Configuration Management 247CMTI PAn example of a group ofrelated work products is aproduct component and itsrequirements, design, test case,verification procedure, andverification report.H I NTWhen developing your projectplan, document what is impor-tant for you to control. This partof the plan provides guidancefor the project team whenidentifying configuration items.H I NTUse criteria to select configura-tion items to ensure that theselection is consistent andthorough.H I NTIf you use a CM tool, it willsometimes assign unique iden-tifiers to configuration itemsfor you.Wow! eBook <WoweBook.Com>
  • 274. 248 PART TWO THE PROCESS AREASTI PSpecifying when a configura-tion item must be placed underCM sets expectations amongteam members and establishesclear objectives for controllingthe project’s work products.TI PMost organizations use anautomated tool for CM.Because of the many aspects toconsider, it is difficult to main-tain a manual CM process.H I NTMany turnkey systems areavailable to help you with CM.Before you purchase one, iden-tify your needs and comparethem to the system’s features.Example characteristics of configuration items include author, document orfile type, programming language for software code files, minimum mar-ketable features, and the purpose the configuration item serves.4. Specify when each configuration item is placed under configurationmanagement.Example criteria for determining when to place work products under con-figuration management include the following:• When the work product is ready for test• Stage of the project lifecycle• Degree of control desired on the work product• Cost and schedule limitations• Stakeholder requirements5. Identify the owner responsible for each configuration item.6. Specify relationships among configuration items.Incorporating the types of relationships (e.g., parent-child, depen-dency) that exist among configuration items into the configurationmanagement structure (e.g., configuration management database)assists in managing the effects and impacts of changes.SP 1.2 ESTABLISH A CONFIGURATION MANAGEMENT SYSTEMEstablish and maintain a configuration management and change managementsystem for controlling work products.A configuration management system includes the storage media, pro-cedures, and tools for accessing the system. A configuration manage-ment system can consist of multiple subsystems with differentimplementations that are appropriate for each configuration manage-ment environment.A change management system includes the storage media, proce-dures, and tools for recording and accessing change requests.Example Work Products1. Configuration management system with controlled work products2. Configuration management system access control procedures3. Change request databaseWow! eBook <WoweBook.Com>
  • 275. Subpractices1. Establish a mechanism to manage multiple levels of control.The level of control is typically selected based on project objectives,risk, and resources. Control levels can vary in relation to the projectlifecycle, type of system under development, and specific projectrequirements.Example levels of control include the following:• Uncontrolled: Anyone can make changes.• Work-in-progress: Authors control changes.• Released: A designated authority authorizes and controls changes andrelevant stakeholders are notified when changes are made.Levels of control can range from informal control that simply trackschanges made when configuration items are being developed to for-mal configuration control using baselines that can only be changed aspart of a formal configuration management process.2. Provide access control to ensure authorized access to the configura-tion management system.3. Store and retrieve configuration items in a configuration manage-ment system.4. Share and transfer configuration items between control levels in theconfiguration management system.5. Store and recover archived versions of configuration items.6. Store, update, and retrieve configuration management records.7. Create configuration management reports from the configurationmanagement system.8. Preserve the contents of the configuration management system.Examples of preservation functions of the configuration management sys-tem include the following:• Backup and restoration of configuration management files• Archive of configuration management files• Recovery from configuration management errors9. Revise the configuration management structure as necessary.Configuration Management 249CMTI PNot all configuration itemsrequire the same level of con-trol. Some may require morecontrol as they move throughthe project lifecycle.TI PA formal CM process is typi-cally change-request basedand requires extensive trackingand review of all changes.H I NTYou must find the balance ofensuring all that need access toconfiguration items have it, butthat the need for access is gen-uine and confirmed.H I NTReview the CM system regu-larly to ensure that it is meetingthe needs of the projects itserves.Wow! eBook <WoweBook.Com>
  • 276. SP 1.3 CREATE OR RELEASE BASELINESCreate or release baselines for internal use and for delivery to the customer.A baseline is represented by the assignment of an identifier to a con-figuration item or a collection of configuration items and associatedentities at a distinct point in time. As a product or service evolves,multiple baselines can be used to control development and testing.(See the definition of “baseline” in the glossary.)Hardware products as well as software and documentation shouldalso be included in baselines for infrastructure related configurations(e.g., software, hardware) and in preparation for system tests thatinclude interfacing hardware and software.One common set of baselines includes the system level require-ments, system element level design requirements, and the productdefinition at the end of development/beginning of production. Thesebaselines are typically referred to respectively as the “functional base-line,” “allocated baseline,” and “product baseline.”A software baseline can be a set of requirements, design, sourcecode files and the associated executable code, build files, and userdocumentation (associated entities) that have been assigned a uniqueidentifier.Example Work Products1. Baselines2. Description of baselinesSubpractices1. Obtain authorization from the CCB before creating or releasing base-lines of configuration items.2. Create or release baselines only from configuration items in the con-figuration management system.3. Document the set of configuration items that are contained in abaseline.4. Make the current set of baselines readily available.SG 2 TRACK AND CONTROL CHANGESChanges to the work products under configuration management are trackedand controlled.The specific practices under this specific goal serve to maintain base-lines after they are established by specific practices under the Estab-lish Baselines specific goal.250 PART TWO THE PROCESS AREASTI PCCB authorization should beformal and documented insome way.TI PIf the baselines released orused do not come from the CMsystem, the system is not serv-ing its purpose and there is ahigh risk of losing baselineintegrity.TI PIf the project or organizationuses multiple baselines, it iseven more critical to ensurethat everyone is using the cor-rect baseline.H I NTTo ensure that project mem-bers use the CM system, makesure the system is easy to use.TI PThis goal is typically imple-mented by establishing achange request system andforming a CCB whose primaryrole is to review and approvebaseline changes.Wow! eBook <WoweBook.Com>
  • 277. SP 2.1 TRACK CHANGE REQUESTSTrack change requests for configuration items.Change requests address not only new or changed requirements butalso failures and defects in work products.Change requests are analyzed to determine the impact that thechange will have on the work product, related work products, thebudget, and the schedule.Example Work Products1. Change requestsSubpractices1. Initiate and record change requests in the change request database.2. Analyze the impact of changes and fixes proposed in changerequests.Changes are evaluated through activities that ensure that they areconsistent with all technical and project requirements.Changes are evaluated for their impact beyond immediate project orcontract requirements. Changes to an item used in multiple productscan resolve an immediate issue while causing a problem in otherapplications.Changes are evaluated for their impact on release plans.3. Categorize and prioritize change requests.Emergency requests are identified and referred to an emergencyauthority if appropriate.Changes are allocated to future baselines.4. Review change requests to be addressed in the next baseline withrelevant stakeholders and get their agreement.Conduct the change request review with appropriate participants.Record the disposition of each change request and the rationale forthe decision, including success criteria, a brief action plan if appropri-ate, and needs met or unmet by the change. Perform the actionsrequired in the disposition and report results to relevant stakeholders.5. Track the status of change requests to closure.Change requests brought into the system should be handled in anefficient and timely manner. Once a change request has beenprocessed, it is critical to close the request with the appropriateapproved action as soon as it is practical. Actions left open result inlarger than necessary status lists, which in turn result in added costsand confusion.Configuration Management 251CMTI PChange requests are formallysubmitted descriptions ofdesired modifications to workproducts. If change requestsare not documented consis-tently, they are difficult to ana-lyze and track.TI PA change request system isusually used after an initialbaseline is created. A changerequest system allows you totrack every change that is madeto work products.TI PA database provides a flexibleenvironment for storing andtracking change requests.TI POrganizing your changerequests enables you to ana-lyze the relationships amongthem and the order in whichthese requests should beimplemented.H I NTTrack change requests to clo-sure to ensure that if a changerequest is not addressed, it wasnot lost or missed.Wow! eBook <WoweBook.Com>
  • 278. 252 PART TWO THE PROCESS AREASTI PA revision history usually con-tains not only what waschanged, but also who madethe changes, and when andwhy they were made.SP 2.2 CONTROL CONFIGURATION ITEMSControl changes to configuration items.Control is maintained over the configuration of the work productbaseline. This control includes tracking the configuration of eachconfiguration item, approving a new configuration if necessary, andupdating the baseline.Example Work Products1. Revision history of configuration items2. Archives of baselinesSubpractices1. Control changes to configuration items throughout the life of theproduct or service.2. Obtain appropriate authorization before changed configurationitems are entered into the configuration management system.For example, authorization can come from the CCB, the project manager,product owner, or the customer.3. Check in and check out configuration items in the configurationmanagement system for incorporation of changes in a manner thatmaintains the correctness and integrity of configuration items.Examples of check-in and check-out steps include the following:• Confirming that the revisions are authorized• Updating the configuration items• Archiving the replaced baseline and retrieving the new baseline• Commenting on the changes made to the item• Tying changes to related work products such as requirements, user sto-ries, and tests4. Perform reviews to ensure that changes have not caused unintendedeffects on the baselines (e.g., ensure that changes have not compro-mised the safety or security of the system).5. Record changes to configuration items and reasons for changes asappropriate.If a proposed change to the work product is accepted, a schedule isidentified for incorporating the change into the work product andother affected areas.TI PThe life of the product is typi-cally longer than the life of thedevelopment project that cre-ated it. The responsibility forconfiguration items maychange over time.H I NTDefine authorization proce-dures so that it is clear how toreceive authorization to enteran updated configuration iteminto the CM system.TI PAn important part of check inand check out is ensuring thatonly one copy of a configura-tion item is authorized forupdate at one time.Wow! eBook <WoweBook.Com>
  • 279. Configuration control mechanisms can be tailored to categoriesof changes. For example, the approval considerations could beless stringent for component changes that do not affect othercomponents.Changed configuration items are released after review and approvalof configuration changes. Changes are not official until they arereleased.SG 3 ESTABLISH INTEGRITYIntegrity of baselines is established and maintained.The integrity of baselines, established by processes associated withthe Establish Baselines specific goal, and maintained by processesassociated with the Track and Control Changes specific goal, isaddressed by the specific practices under this specific goal.SP 3.1 ESTABLISH CONFIGURATION MANAGEMENT RECORDSEstablish and maintain records describing configuration items.Example Work Products1. Revision history of configuration items2. Change log3. Change request records4. Status of configuration items5. Differences between baselinesSubpractices1. Record configuration management actions in sufficient detail so thecontent and status of each configuration item is known and previousversions can be recovered.2. Ensure that relevant stakeholders have access to and knowledge ofthe configuration status of configuration items.Examples of activities for communicating configuration status include thefollowing:• Providing access permissions to authorized end users• Making baseline copies readily available to authorized end users• Automatically alerting relevant stakeholders when items are checked inor out or changed, or of decisions made regarding change requests3. Specify the latest version of baselines.Configuration Management 253CMTI PWithout descriptions of theconfiguration items, it is diffi-cult and time consuming tounderstand the status of theseitems relative to the projectplan.Wow! eBook <WoweBook.Com>
  • 280. 254 PART TWO THE PROCESS AREASTI PVersion control is an importantpart of CM. There are differentways to identify versions. Astandard way is using sequen-tial numbering.H I NTWhen describing the differ-ences between baselines, youshould be detailed enough sothat users of the baselines candifferentiate them easily.4. Identify the version of configuration items that constitute a particu-lar baseline.5. Describe differences between successive baselines.6. Revise the status and history (i.e., changes, other actions) of eachconfiguration item as necessary.SP 3.2 PERFORM CONFIGURATION AUDITSPerform configuration audits to maintain the integrity of configurationbaselines.Configuration audits confirm that the resulting baselines and documen-tation conform to a specified standard or requirement. Configurationitem related records can exist in multiple databases or configurationmanagement systems. In such instances, configuration audits shouldextend to these other databases as appropriate to ensure accuracy,consistency, and completeness of configuration item information.(See the definition of “configuration audit” in the glossary.)Examples of audit types include the following:• Functional configuration audits (FCAs): Audits conducted to verify thatthe development of a configuration item has been completed satisfacto-rily, that the item has achieved the functional and quality attribute char-acteristics specified in the functional or allocated baseline, and that itsoperational and support documents are complete and satisfactory.• Physical configuration audits (PCAs): Audits conducted to verify that aconfiguration item, as built, conforms to the technical documentation thatdefines and describes it.• Configuration management audits: Audits conducted to confirm that con-figuration management records and configuration items are complete,consistent, and accurate.Example Work Products1. Configuration audit results2. Action itemsSubpractices1. Assess the integrity of baselines.2. Confirm that configuration management records correctly identifyconfiguration items.3. Review the structure and integrity of items in the configurationmanagement system.TI PAudits provide an objectiveway to know that what is sup-posed to be controlled is con-trolled and can be retrieved.Retrieval of accurate informa-tion is one of CM’s manybenefits.TI PIntegrity includes accuracy,consistency, and completeness.Wow! eBook <WoweBook.Com>
  • 281. 4. Confirm the completeness, correctness, and consistency of items inthe configuration management system.Completeness, correctness, and consistency of the configuration man-agement system’s content are based on requirements as stated in theplan and the disposition of approved change requests.5. Confirm compliance with applicable configuration managementstandards and procedures.6. Track action items from the audit to closure.Configuration Management 255CMTI PAn audit is effective only whenall action items from the auditare addressed.Wow! eBook <WoweBook.Com>
  • 282. This page intentionally left blankWow! eBook <WoweBook.Com>
  • 283. DECISION ANALYSIS AND RESOLUTIONA Support Process Area at Maturity Level 3PurposeThe purpose of Decision Analysis and Resolution (DAR) is to analyzepossible decisions using a formal evaluation process that evaluatesidentified alternatives against established criteria.Introductory NotesThe Decision Analysis and Resolution process area involves estab-lishing guidelines to determine which issues should be subject to aformal evaluation process and applying formal evaluation processesto these issues.A formal evaluation process is a structured approach to evaluatingalternative solutions against established criteria to determine a rec-ommended solution.A formal evaluation process involves the following actions:• Establishing the criteria for evaluating alternatives• Identifying alternative solutions• Selecting methods for evaluating alternatives• Evaluating alternative solutions using established criteria andmethods• Selecting recommended solutions from alternatives based on evalua-tion criteriaRather than using the phrase “alternative solutions to addressissues” each time, in this process area, one of two shorter phrases areused: “alternative solutions” or “alternatives.”A formal evaluation process reduces the subjective nature of adecision and provides a higher probability of selecting a solution thatmeets multiple demands of relevant stakeholders.257DARTI PDAR provides organizationswith a criterion-basedapproach to making importantdecisions objectively.H I NTInitially, use this process onlyfor decisions that will have amajor impact on the project.After you are accustomed tousing a formal evaluationprocess, you may find value inusing it for selected day-to-daydecisions.TI PDAR takes the blame out ofdecision making. A bad deci-sion is made when all the nec-essary information that mightimpact the decision was notconsidered and relevant stake-holders were not consulted.Wow! eBook <WoweBook.Com>
  • 284. While the primary application of this process area is to technicalconcerns, formal evaluation processes can be applied to many non-technical issues, particularly when a project is being planned. Issuesthat have multiple alternative solutions and evaluation criteria lendthemselves to a formal evaluation process.Trade studies of equipment or software are typical examples of formalevaluation processes.During planning, specific issues requiring a formal evaluationprocess are identified. Typical issues include selection among archi-tectural or design alternatives, use of reusable or commercial off-the-shelf (COTS) components, supplier selection, engineering supportenvironments or associated tools, test environments, delivery alter-natives, and logistics and production. A formal evaluation processcan also be used to address a make-or-buy decision, the developmentof manufacturing processes, the selection of distribution locations,and other decisions.Guidelines are created for deciding when to use formal evaluationprocesses to address unplanned issues. Guidelines often suggestusing formal evaluation processes when issues are associated withmedium-to-high-impact risks or when issues affect the ability toachieve project objectives.Defining an issue well helps to define the scope of alternatives tobe considered. The right scope (i.e., not too broad, not too narrow)will aid in making an appropriate decision for resolving the definedissue.Formal evaluation processes can vary in formality, type of criteria,and methods employed. Less formal decisions can be analyzed in afew hours, use few criteria (e.g., effectiveness, cost to implement),and result in a one- or two-page report. More formal decisions canrequire separate plans, months of effort, meetings to develop andapprove criteria, simulations, prototypes, piloting, and extensivedocumentation.Both numeric and non-numeric criteria can be used in a formalevaluation process. Numeric criteria use weights to reflect the rela-tive importance of criteria. Non-numeric criteria use a subjectiveranking scale (e.g., high, medium, low). More formal decisions canrequire a full trade study.A formal evaluation process identifies and evaluates alternativesolutions. The eventual selection of a solution can involve iterativeactivities of identification and evaluation. Portions of identified alter-258 PART TWO THE PROCESS AREASTI PExamples of nontechnicalissues include addingresources and determiningdelivery approaches for atraining class.X- R E FMany of the technical issuesthat may benefit from a for-mal evaluation process areaddressed in TS, PI, VER,and VAL.TI PTools such as the Analytic Hier-archy Process (AHP), QualityFunction Deployment (QFD),the Pugh Method, the DelphiMethod, prioritization matrices,cause-and-effect diagrams,decision trees, weighted crite-ria spreadsheets, and simula-tions exist to help withweighted decision making.Wow! eBook <WoweBook.Com>
  • 285. natives can be combined, emerging technologies can change alterna-tives, and the business situation of suppliers can change during theevaluation period.A recommended alternative is accompanied by documentation ofselected methods, criteria, alternatives, and rationale for the recom-mendation. The documentation is distributed to relevant stakehold-ers; it provides a record of the formal evaluation process andrationale, which are useful to other projects that encounter a similarissue.While some of the decisions made throughout the life of the proj-ect involve the use of a formal evaluation process, others do not. Asmentioned earlier, guidelines should be established to determinewhich issues should be subject to a formal evaluation process.Related Process AreasRefer to the Integrated Project Management process area for more informationabout establishing the project’s defined process.Refer to the Risk Management process area for more information about identi-fying and analyzing risks and mitigating risks.Specific Goal and Practice SummarySG 1 Evaluate AlternativesSP 1.1 Establish Guidelines for Decision AnalysisSP 1.2 Establish Evaluation CriteriaSP 1.3 Identify Alternative SolutionsSP 1.4 Select Evaluation MethodsSP 1.5 Evaluate Alternative SolutionsSP 1.6 Select SolutionsSpecific Practices by GoalSG 1 EVALUATE ALTERNATIVESDecisions are based on an evaluation of alternatives using establishedcriteria.Issues requiring a formal evaluation process can be identified at anytime. The objective should be to identify issues as early as possible tomaximize the time available to resolve them.Decision Analysis and Resolution 259DARWow! eBook <WoweBook.Com>
  • 286. SP 1.1 ESTABLISH GUIDELINES FOR DECISION ANALYSISEstablish and maintain guidelines to determine which issues are subject to aformal evaluation process.Not every decision is significant enough to require a formal evalua-tion process. The choice between the trivial and the truly importantis unclear without explicit guidance. Whether a decision is signifi-cant or not is dependent on the project and circumstances and isdetermined by established guidelines.Typical guidelines for determining when to require a formal evaluationprocess include the following:• A decision is directly related to issues that are medium-to-high-impactrisk.• A decision is related to changing work products under configurationmanagement.• A decision would cause schedule delays over a certain percentage oramount of time.• A decision affects the ability of the project to achieve its objectives.• The costs of the formal evaluation process are reasonable when com-pared to the decision’s impact.• A legal obligation exists during a solicitation.• When competing quality attribute requirements would result in signifi-cantly different alternative architectures.Refer to the Risk Management process area for more information about evaluat-ing, categorizing, and prioritizing risks.Examples of activities for which you may use a formal evaluation processinclude the following:• Making decisions involving the procurement of material when 20 percentof the material parts constitute 80 percent of the total material costs• Making design-implementation decisions when technical performancefailure can cause a catastrophic failure (e.g., safety-of-flight item)• Making decisions with the potential to significantly reduce design risk,engineering changes, cycle time, response time, and production costs(e.g., to use lithography models to assess form and fit capability beforereleasing engineering drawings and production builds)260 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 287. Decision Analysis and Resolution 261DARH I NTMake sure the guidelines areaccessible and understood byeveryone in the organization(or project).TI PIn some cases, all criteria maybe roughly equal and rankingmay not be necessary.TI PDocumentation helps to pro-vide an understanding ofwhich criteria were consideredand how they were ranked.Example Work Products1. Guidelines for when to apply a formal evaluation processSubpractices1. Establish guidelines for when to use a formal evaluation process.2. Incorporate the use of guidelines into the defined process asappropriate.Refer to the Integrated Project Management process area for more infor-mation about establishing the project’s defined process.SP 1.2 ESTABLISH EVALUATION CRITERIAEstablish and maintain criteria for evaluating alternatives and the relativeranking of these criteria.Evaluation criteria provide the basis for evaluating alternative solu-tions. Criteria are ranked so that the highest ranked criteria exert themost influence on the evaluation.This process area is referenced by many other process areas in themodel, and many contexts in which a formal evaluation process canbe used. Therefore, in some situations you may find that criteria havealready been defined as part of another process. This specific practicedoes not suggest that a second development of criteria be conducted.A well-defined statement of the issue to be addressed and thedecision to be made focuses the analysis to be performed. Such astatement also aids in defining evaluation criteria that minimize thepossibility that decisions will be second guessed or that the reasonfor making the decision will be forgotten. Decisions based on criteriathat are explicitly defined and established remove barriers to stake-holder buy-in.Example Work Products1. Documented evaluation criteria2. Rankings of criteria importanceSubpractices1. Define the criteria for evaluating alternative solutions.Criteria should be traceable to requirements, scenarios, business caseassumptions, business objectives, or other documented sources.Wow! eBook <WoweBook.Com>
  • 288. 262 PART TWO THE PROCESS AREASTI PAn example of a non-numericscale is one that ranks criteriabased on low, medium, or highimportance.Types of criteria to consider include the following:• Technology limitations• Environmental impact• Risks• Business value• Impact on priorities• Total ownership and lifecycle costs2. Define the range and scale for ranking the evaluation criteria.Scales of relative importance for evaluation criteria can be establishedwith non-numeric values or with formulas that relate the evaluationparameter to a numeric weight.3. Rank the criteria.The criteria are ranked according to the defined range and scale toreflect the needs, objectives, and priorities of the relevant stakeholders.4. Assess the criteria and their relative importance.5. Evolve the evaluation criteria to improve their validity.6. Document the rationale for the selection and rejection of evaluationcriteria.Documentation of selection criteria and rationale may be needed tojustify solutions or for future reference and use.SP 1.3 IDENTIFY ALTERNATIVE SOLUTIONSIdentify alternative solutions to address issues.A wider range of alternatives can surface by soliciting as many stake-holders as practical for input. Input from stakeholders with diverseskills and backgrounds can help teams identify and address assump-tions, constraints, and biases. Brainstorming sessions can stimulateinnovative alternatives through rapid interaction and feedback.Sufficient candidate solutions may not be furnished for analysis.As the analysis proceeds, other alternatives should be added to thelist of potential candidate solutions. The generation and considera-tion of multiple alternatives early in a decision analysis and resolu-tion process increases the likelihood that an acceptable decision willbe made and that consequences of the decision will be understood.Example Work Products1. Identified alternativesH I NTYou can use many brainstorm-ing techniques to identify alter-native solutions. However, youshould establish a few rulesbefore your brainstorming ses-sion to ensure that the widestpossible range of alternatives isconsidered.Wow! eBook <WoweBook.Com>
  • 289. Subpractices1. Perform a literature search.A literature search can uncover what others have done both insideand outside the organization. Such a search can provide a deeperunderstanding of the problem, alternatives to consider, barriers toimplementation, existing trade studies, and lessons learned from sim-ilar decisions.2. Identify alternatives for consideration in addition to the alternativesthat may be provided with the issue.Evaluation criteria are an effective starting point for identifying alter-natives. Evaluation criteria identify priorities of relevant stakeholdersand the importance of technical, logistical, or other challenges.Combining key attributes of existing alternatives can generate addi-tional and sometimes stronger alternatives.Solicit alternatives from relevant stakeholders. Brainstorming ses-sions, interviews, and working groups can be used effectively touncover alternatives.3. Document proposed alternatives.SP 1.4 SELECT EVALUATION METHODSSelect evaluation methods.Methods for evaluating alternative solutions against established cri-teria can range from simulations to the use of probabilistic modelsand decision theory. These methods should be carefully selected. Thelevel of detail of a method should be commensurate with cost, sched-ule, performance, and risk impacts.While many problems may require only one evaluation method,some problems may require multiple methods. For example, simula-tions may augment a trade study to determine which design alterna-tive best meets a given criterion.Example Work Products1. Selected evaluation methodsSubpractices1. Select methods based on the purpose for analyzing a decision and onthe availability of the information used to support the method.For example, the methods used for evaluating a solution when require-ments are weakly defined may be different from the methods used whenthe requirements are well defined.Decision Analysis and Resolution 263DARTI PDifferent evaluation methodsrequire different investmentsof resources and training.TI PSelecting solutions alsoinvolves risk assessment.Wow! eBook <WoweBook.Com>
  • 290. Typical evaluation methods include the following:• Testing• Modeling and simulation• Engineering studies• Manufacturing studies• Cost studies• Business opportunity studies• Surveys• Extrapolations based on field experience and prototypes• End-user review and comment• Judgment provided by an expert or group of experts (e.g., Delphi method)2. Select evaluation methods based on their ability to focus on theissues at hand without being overly influenced by side issues.Results of simulations can be skewed by random activities in thesolution that are not directly related to the issues at hand.3. Determine the measures needed to support the evaluation method.Consider the impact on cost, schedule, performance, and risks.SP 1.5 EVALUATE ALTERNATIVE SOLUTIONSEvaluate alternative solutions using established criteria and methods.Evaluating alternative solutions involves analysis, discussion, andreview. Iterative cycles of analysis are sometimes necessary. Support-ing analyses, experimentation, prototyping, piloting, or simulationsmay be needed to substantiate scoring and conclusions.Often, the relative importance of criteria is imprecise and the totaleffect on a solution is not apparent until after the analysis is per-formed. In cases where the resulting scores differ by relatively smallamounts, the best selection among alternative solutions may not beclear. Challenges to criteria and assumptions should be encouraged.Example Work Products1. Evaluation resultsSubpractices1. Evaluate proposed alternative solutions using the established evalua-tion criteria and selected methods.2. Evaluate assumptions related to the evaluation criteria and the evi-dence that supports the assumptions.264 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 291. 3. Evaluate whether uncertainty in the values for alternative solutionsaffects the evaluation and address these uncertainties as appropriate.For instance, if the score varies between two values, is the differencesignificant enough to make a difference in the final solution set? Doesthe variation in score represent a high-impact risk? To address theseconcerns, simulations may be run, further studies may be performed,or evaluation criteria may be modified, among other things.4. Perform simulations, modeling, prototypes, and pilots as necessaryto exercise the evaluation criteria, methods, and alternative solutions.Untested criteria, their relative importance, and supporting data orfunctions can cause the validity of solutions to be questioned. Criteriaand their relative priorities and scales can be tested with trial runsagainst a set of alternatives. These trial runs of a select set of criteriaallow for the evaluation of the cumulative impact of criteria on asolution. If trials reveal problems, different criteria or alternativesmight be considered to avoid biases.5. Consider new alternative solutions, criteria, or methods if proposedalternatives do not test well; repeat evaluations until alternatives dotest well.6. Document the results of the evaluation.Document the rationale for the addition of new alternatives or meth-ods and changes to criteria, as well as the results of interim evalua-tions.SP 1.6 SELECT SOLUTIONSSelect solutions from alternatives based on evaluation criteria.Selecting solutions involves weighing results from the evaluation ofalternatives. Risks associated with the implementation of solutionsshould be assessed.Example Work Products1. Recommended solutions to address significant issuesSubpractices1. Assess the risks associated with implementing the recommendedsolution.Refer to the Risk Management process area for more information aboutidentifying and analyzing risks and mitigating risks.Decisions must often be made with incomplete information. Therecan be substantial risk associated with the decision because of havingincomplete information.Decision Analysis and Resolution 265DARWow! eBook <WoweBook.Com>
  • 292. When decisions must be made according to a specific schedule, timeand resources may not be available for gathering complete informa-tion. Consequently, risky decisions made with incomplete informa-tion can require re-analysis later. Identified risks should bemonitored.2. Document and communicate to relevant stakeholders the results andrationale for the recommended solution.It is important to record both why a solution is selected and whyanother solution was rejected.266 PART TWO THE PROCESS AREASWow! eBook <WoweBook.Com>
  • 293. 267IPMINTEGRATED PROJECT MANAGEMENTA Project Management Process Area at Maturity Level 3PurposeThe purpose of Integrated Project Management (IPM) is to establishand manage the project and the involvement of relevant stakeholdersaccording to an integrated and defined process that is tailored fromthe organization’s set of standard processes.Introductory NotesIntegrated Project Management involves the following activities:• Establishing the project’s defined process at project startup by tailor-ing the organization’s set of standard processes• Managing the project using the project’s defined process• Establishing the work environment for the project based on the orga-nization’s work environment standards• Establishing teams that are tasked to accomplish project objectives• Using and contributing to organizational process assets• Enabling relevant stakeholders’ concerns to be identified, considered,and, when appropriate, addressed during the project• Ensuring that relevant stakeholders (1) perform their tasks in a coor-dinated and timely manner; (2) address project requirements, plans,objectives, problems, and risks; (3) fulfill their commitments; and (4)identify, track, and resolve coordination issuesThe integrated and defined process that is tailored from the orga-nization’s set of standard processes is called the project’s definedprocess. (See the definition of “project” in the glossary.)Managing the project’s effort, cost, schedule, staffing, risks, andother factors is tied to the tasks of the project’s defined process. Theimplementation and management of the project’s defined process aretypically described in the project plan. Certain activities may beTI PIn the CMMI for ServicesModel, this process area iscalled Integrated WorkManagement.TI PIPM matures the project man-agement activities described inPP and PMC so that theyaddress the organizationalrequirements for projectsdescribed in OPF and OPD.TI PUsing IPM to guide projectmanagement activities enablesproject plans to be consistentwith project activities becausethey are both derived fromstandard processes created bythe organization. Further, planstend to be more reliable andare developed more quickly,and new projects learn morequickly.Wow! eBook <WoweBook.Com>
  • 294. 268 PART TWO THE PROCESS AREASTI PIt is also easier to shareresources (e.g., training andsoftware tools) and to “loadbalance” staff across projects.TI PA proactive approach to inte-grating plans and coordinatingwith relevant stakeholders out-side the project is a key activity.covered in other plans that affect the project, such as the qualityassurance plan, risk management strategy, and the configurationmanagement plan.Since the defined process for each project is tailored from theorganization’s set of standard processes, variability among projects istypically reduced and projects can easily share process assets, data,and lessons learned.This process area also addresses the coordination of all activities associ-ated with the project such as the following:• Development activities (e.g., requirements development, design,verification)• Service activities (e.g., delivery, help desk, operations, customer contact)• Acquisition activities (e.g., solicitation, agreement monitoring, transitionto operations)• Support activities (e.g., configuration management, documentation, mar-keting, training)The working interfaces and interactions among relevant stake-holders internal and external to the project are planned and managedto ensure the quality and integrity of the overall endeavor. Relevantstakeholders participate as appropriate in defining the project’sdefined process and the project plan. Reviews and exchanges are reg-ularly conducted with relevant stakeholders to ensure that coordina-tion issues receive appropriate attention and everyone involved withthe project is appropriately aware of status, plans, and activities. (Seethe definition of “relevant stakeholder” in the glossary.) In definingthe project’s defined process, formal interfaces are created as neces-sary to ensure that appropriate coordination and collaborationoccurs.This process area applies in any organizational structure, includ-ing projects that are structured as line organizations, matrix organi-zations, or teams. The terminology should be appropriatelyinterpreted for the organizational structure in place.Related Process AreasRefer to the Verification process area for more information about performingpeer reviews.Refer to the Measurement and Analysis process area for more information aboutaligning measurement and analysis activities and providing measurementresults.Wow! eBook <WoweBook.Com>
  • 295. Refer to the Organizational Process Definition process area for more informa-tion about establishing and maintaining a usable set of organizational processassets, work environment standards, and rules and guidelines for teams.Refer to the Project Monitoring and Control process area for more informationabout monitoring the project against the plan.Refer to the Project Planning process area for more information about develop-ing a project plan.Specific Goal and Practice SummarySG 1 Use the Project’s Defined ProcessSP 1.1 Establish the Project’s Defined ProcessSP 1.2 Use Organizational Process Assets for Planning Project ActivitiesSP 1.3 Establish the Project’s Work EnvironmentSP 1.4 Integrate PlansSP 1.5 Manage the Project Using Integrated PlansSP 1.6 Establish TeamsSP 1.7 Contribute to Organizational Process AssetsSG 2 Coordinate and Collaborate with Relevant StakeholdersSP 2.1 Manage Stakeholder InvolvementSP 2.2 Manage DependenciesSP 2.3 Resolve Coordination IssuesSpecific Practices by GoalSG 1 USE THE PROJECT’S DEFINED PROCESSThe project is conducted using a defined process tailored from the organiza-tion’s set of standard processes.The project’s defined process includes those processes from the orga-nization’s set of standard processes that address all processes neces-sary to acquire, develop, maintain, or deliver the product.The product related lifecycle processes, such as manufacturingand support processes, are developed concurrently with the product.SP 1.1 ESTABLISH THE PROJECT’S DEFINED PROCESSEstablish and maintain the project’s defined process from project startupthrough the life of the project.Refer to the Organizational Process Definition process area for more informa-tion about establishing organizational process assets and establishing the orga-nization’s measurement repository.Refer to the Organizational Process Focus process area for more informationabout deploying organizational process assets and deploying standard processes.Integrated Project Management 269IPMTI PIn Version 1.3, the IPPD materialhas been removed and SP 1.6was added to address teams.TI PAll projects that use IPM havethe organization’s set of stan-dard processes as a basis tobegin planning all projectactivities.Wow! eBook <WoweBook.Com>
  • 296. 270 PART TWO THE PROCESS AREASTI PIPM depends strongly on OPD.It is impossible to implementthe specific practices in IPMwithout having in place theorganizational infrastructuredescribed in OPD.The project’s defined process consists of defined processes that forman integrated, coherent lifecycle for the project.The project’s defined process should satisfy the project’s contrac-tual requirements, operational needs, opportunities, and constraints.It is designed to provide a best fit for project needs.A project’s defined process is based on the following factors:• Stakeholder requirements• Commitments• Organizational process needs and objectives• The organization’s set of standard processes and tailoring guidelines• The operational environment• The business environmentEstablishing the project’s defined process at project startup helpsto ensure that project staff and relevant stakeholders implement a setof activities needed to efficiently establish an initial set of require-ments and plans for the project. As the project progresses, thedescription of the project’s defined process is elaborated and revisedto better meet project requirements and the organization’s processneeds and objectives. Also, as the organization’s set of standardprocesses changes, the project’s defined process may need to berevised.Example Work Products1. The project’s defined processSubpractices1. Select a lifecycle model from the ones available in organizationalprocess assets.Examples of project characteristics that could affect the selection oflifecycle models include the following:• Size or complexity of the project• Project strategy• Experience and familiarity of staff with implementing the process• Constraints such as cycle time and acceptable defect levels• Availability of customers to answer questions and provide feedback onincrements• Clarity of requirements• Customer expectationsWow! eBook <WoweBook.Com>
  • 297. Integrated Project Management 271IPMTI PThe organization’s set of stan-dard processes are tailored toaddress the project’s specificneeds and situation. For exam-ple, are stringent quality, safety,or security requirements inplace? Is the risk of deliveringthe wrong product high? Arewe working with a new cus-tomer, product line, or line ofbusiness? Are there stringentschedule constraints?H I NTMaintain the process assetlibrary to keep it current, orelse it could become the dump-ing ground for all project infor-ma