Monday, December 3, 2012

What are the CMMI Generic Practices for?

Hey, CMMI Appraiser – why is it that we have to worry so much about these Generic Practices? Seems like a big headache to me - Jim W, Minneapolis, MN

Greetings, Jim! Thank you for submitting the first question to be answered in our new CMMI-TV series! Like this blog, CMMI-TV is a place where we can add value to the engineering and software development community by offering advice on engineering strategy, performance innovation and software process improvement. Below is a video clip with my answer to your question, followed by a synopsis of my response. Enjoy!


The CMMI (Capability Maturity Model Integration), is a model that helps us build better software and run better projects.

The Generic Practices apply to all process areas in the CMMI – which is why they should have been named the Most Important Practices.

Regardless of what type of method, technique or process that you use, the Generic Practices can really help jump start the success of those practices.

The Generic Practices apply to activities that the organization performs, not necessarily the individual projects. The guidance provided by the Generic Practice includes but is not limited to:

  • How long are our Sprints?
  • What kind of retrospectives do we have?
  • What kind of code reviews should we run?
  • Should we comment our code, and how should we comment it?
  • How many Sprints are we going to have?
  • How many phases are we going to have?
  • How many releases are we going to have?
  • What kind of requirements management tools are we going to use?
  • Who is going to be involved?
  • When are they going to be involved?
  • Are we providing training? For example, if I’m going to ask you to do Planning Poker and use it as a way to estimate the size of a project or a particular user story, do I plan to train you on how to use those tools?
  • How is the process working?
  • Are we getting value out of our sprints, phases and the tools that we are using, out of the techniques that we are employing?
  • If we aren’t getting value, why not? And if not, let’s make them better!
  • Are people actually using these processes?
  • If they aren’t, why not?
  • Is management paying attention to all of this data?
  • Are they doing something about it to make the company an even better company?
  • Are we constantly improving the processes?
Like this blog? Forward to your nearest engineering or software exec! 

Don't miss our CMMI Training class coming up in Virginia February 11-14, 2013
Introduction to CMMI-DEV v1.3. Register at

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit for more information about running a successful CMMI and performance improvement program.


Unknown said...

Hey Jim,

I just wanted to provide a practitioner’s viewpoint on generic practices. I am the task and process improvement lead for a series of websites.

The specific practices focus on different aspects of our process improvement approach, but it is the generic practices that ‘hold everything together’. Those bubble / flow charts at the front of the CMMI book where the PAs are tied together? It’s the generic practices that facilitate this connectivity.

You know in sports (I’m dreadful at sports) when a coach tells you to ‘follow through’ on your swing or pitch? The motion and anticipation of the swing is enhanced because of your (anticipatory) good form. Generic practices are the ‘follow through’ for the specific practices.

So! Let’s look at an example and see how the generic practices enhance the specific practices.

Okay: RD – SP 1.1. Elicit stakeholder needs. We can perform this practice by speaking to our customer community and establishing elicitation meetings – but (!) how?

• We need to have a strategy and plan of attack for eliciting customer needs (GP 3.1 and GP 2.2)
• We need to think ahead and schedule our elicitation activities to correspond with our project plans and WBS (GP 2.2)
• Augh! Where are we going to record our meeting and how are we going to invite participants? Through Microsoft Outlook – a resource anticipated in GP 2.3
• We need to get the right requirements folks involved (GP 2.4 and 2.5)
• We need to invite the right people to the meeting (customers, stakeholders, our requirements team, a developer or two for good measure… etc.) (GP 2.7)
• It would be REALLY awkward if (cough) we lost our notes from the customer requirements elicitation meeting – they should be safely stored through the CM process (GP 2.6)
• We did a great job at eliciting requirements. Yay! We should inform our boss that we successfully gathered some requirements and are ready to dig in! (GP 2.10)
• Yikes! Well… in retrospect the requirements we gathered weren’t quite in a format usable to the engineers. And - we didn’t anticipate the customer coming back to us with that many requirements-validation findings… we will do better next time and will amend our processes accordingly! Furthermore, we want other projects to learn from this oversight! (GP 3.2)

Hope this helps!

Shawn Rapjack,
Process Improvement Manager

Anonymous said...

Right on Shawn! The CMMI has many different perspectives. If you're goal is to improve, then the Generic Practices are really important! And even if your goal is to conduct a formal SCAMPI A Appraisal, they're STILL really important (and they'll help you improve without you even knowing it!).