"A process area is not a process" - what does THAT mean?

[Dear Readers, our good friend Pat O’Toole, CMMI expert and seasoned consultant, is collaborating with us on a new monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. Today, Pat addresses a commonly asked question about CMMI process areas - "A process area is not a process? What does THAT mean?" Take it away, Pat! ~ the CMMI Appraiser]

Thanks, Jeff! Perhaps a bit of historical background might give you a better understanding of what this statement is intended to convey. When the Software Engineering Institute (SEI) first decided to construct the “CMM for Software,” one of the CMMI-DEV’s three predecessor models, they elicited proposed content from high quality software development organizations by convening a meeting in Pittsburgh and inviting representatives from a select group of 15-20 companies. Each representative was instructed to come prepared to discuss those practices executed on the projects and within the organization that made them “world class.”

At this meeting, each of these good practices was written on an index card and pinned on the wall for all to see (the Post-It Note equivalent of the day). The group then went through an affinity diagramming exercise, clustering like practices together in related groups. After several rounds of segmentation, these groupings eventually became the 18 key process areas of the CMM for Software, and later evolved into the 22 process areas of the CMMI-DEV.

Had it been a different group of companies, or even different representatives from the same companies, these good practices may have been grouped differently. The key process areas were simply a way to organize the identified set of 316 practices, rather than a way to perform the work. So the CMMI is simply a taxonomy of good engineering, project management, and support practices. The process areas catalogue the model’s contents; the way the practices are actually performed may be quite different.

Take Measurement and Analysis, for example. The first practice, SP 1.1 – Establish Measurement Objectives, may be performed by senior and middle management through the annual strategic and tactical planning sessions. The other practices that support goal 1, SP 1.2 – SP 1.4 – which essentially establish an infrastructure for measuring things in a repeatable way – may be performed by some organizational Metrics Group that is responsible for generating Metric Specifications for standard measures. The actual capture and consumption of measures as suggested by the four practices that support specific goal 2, however, may be performed by various:

• Project teams (e.g., project size, effort, cost and scheduled measures)
• Product teams (e.g. customer satisfaction, defect density, and mean time to failure measures)
• Process teams (e.g., trying to understand the average time it takes for a submitted requirement change request to be analyzed and dispositioned by the Change Control Board), and
• Organizational groups (e.g. Human Resources focusing on annual turnover measures and interview-to-hire ratios)

These are perfectly legitimate ways to perform the practices suggested by the Measurement and Analysis process area, but the process steps that actually support the performance of the various CMMI MA practices within a given organization may be scattered throughout various organizational and project processes – and that’s OK!

For organizations that conduct small, low complexity projects, most of the practices associated with the project management process areas (PP, PMC, SAM, IPM and RSKM) may reside in a single Project Management Process. Alternatively for extremely large and complex projects, the project may execute several processes that, collectively, cover the first specific goal of the Project Planning process area.

So cataloguing practices for a process model like the CMMI, and organizing them to perform actual work may be significantly different. Remember that you only do appraisals every three years or so, but you work on projects every single day, so organize your processes to optimize the work performed on projects, and not that performed by appraisal teams!

Like this blog? Forward to your nearest engineering or software exec!

“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton. Patrick O'Toole is Principal Consultant at PACT and Owner, PACT. Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, ScrumMaster, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff pioneered agileCMMI, the leading methodology for incremental and iterative process improvement. He has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Please contact the authors at pact.otoole@att.net and jeff@broadsword.com to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!

Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation , software process improvement and running a successful CMMI program.

To download eBooks about CMMI, visit Jeff’s Author Page on Amazon.