Relationships between CMMI Specific Process Areas and Generic Goals

This is an article I wrote back in 2006, reposted here because it still has some points that someone might find useful...

One of the most common areas of confusion when looking at the CMMI is the relationship between the "Process Areas" and the "Generic Goals and Practices".

At a glance, people seem to think that in order to increase the "maturity level" (not to be confused with capability level) of your organisation, you concentrate on the process areas and specific practices for whatever maturity level you're aiming for - and that by focussing on those areas you will achieve the ML badge you've been striving for.

• If when you read the specific process areas you apply all generic practices for them as well as the specific ones, you may well be on the right track. But do you understand why?
• If you just focus on improving the engineering side of things, I can assure you that you are completely missing the point.

And so begins my attempt to explain why, without the use of diagrams or technical jargon...

Process Areas vs. Generic Goals

1. Process Areas are basically lists of the key things you need to do to make sure you do a specific thing properly, grouped under a title that describes the specific thing you're doing;
2. Generic Goals are the key things that you should really be doing whenever you doanything.

These structured lists of things were drawn up based on "industry best practice", so you're likely to find pretty much the same kinds of things in most half-decent management and engineering or development methodologies.

Process Area Example

One thing you'll notice is that some of the points (or "Specific Practices") that make up these Process Areas are, for want of a better expression, a bit noddy. They are totally and utterly obvious. Not only that, but if you are managing a project or developing a piece of software, you are most likely doing it already.

Example: RD, Requirements Development, SP 2.1-1 Collect Stakeholder Needs.

i.e. when capturing requirements (developing an understanding of requirements), you need to first work out what people want.

If you you're not doing this already, I would guess that you are either unemployed or nearing the end of your contract (whether you like it or not).

Generic Goals example

Generic Goals are again common sense.

Example: GP 2.5 Train People.

i.e. for a project to be truly successful, make sure that the people working on your project have the skills required to perform their jobs correctly - and if they don't, provide them with training to make sure that they do.

The big difference here is that Generic Goals should be applied to all Process Areas. Even so, this is still common sense when you think about it. The person responsible for gathering the stakeholder needs when developing requirements for the Process Area example above, really needs to know how to gather requirements to be any good at actually doing that. If they don't have a clue, they will need training, or will end up doing a bad job.

But wait, there's more...

That's the basic relationship between the two - but when you look at the CMMI more carefully you'll start to see that there's a huge amount of cross-referencing to help you work out how to use it.

In other words, some of the Process Areas actually tell you the things you need to do to implement the Generic Goals for all the other Process Areas!

I'm not talking about the explicit cross-referencing you find in the model when it says "refer to the XXX process area for information about XXX", I'm talking about implicit overlaps between Process Areas and Generic Goals.

Best demonstrated with some examples

I'm not going to go through every Generic Goal and map it back to a Process Area for you. You need to think about how you apply this to your organisation e.g. the guidelines of the CMMI's PP Project Planning process area may actually be performed across multiple processes in your organisation, in a way that means that you cannot define your own "Project Planning" process as such, but must instead document how a number of your processes work and demonstrate how you are performing all of the activities described in PP Project Planning. If I just map Process Areas to Generic Goals, there is a temptation to just take the CMMI "As-Is". All I can say is, I wouldn't recommend it.

However, I know that the best way to demonstrate the implicit relationships between Process Areas and Generic Goals is with some examples, so here are my favourite two:

GP2.5 Train People
OT Organizational Training defines the key things to consider for the central management of training for the entire organisation. If you manage training centrally and ensure that all projects consider training for everything they need to do, then you're going to satisfy this Generic Goal.

GP2.6 Manage Configurations
CM Configuration Management sets out the industry best practices for managing configurations. Document the way in which your organisation performs Configuration Management, and apply it to everything you do and you'll be performing GP2.6.

The point

The final comment I'd like to make is that the use of the CMMI requires a bit of thought. Don't just focus on specific Process Areas unless you've really thought about their impact on your organisation.

The CMMI emphasises central management, consistency, understanding and accountability. All good things in my books - but not things you can achieve by just by working down the list and doing "what it says". The CMMI provides a well-structured reference model, but it's not a how-to guide.

Look at your organisation's processes, look at those specified in the CMMI. Look at how working on Process Areas in the right way can move you towards satisfying the Generic Goals.