CMMI has 4 categories of process areas in staged representation, those categories are:

  • process management
  • project management
  • engineering
  • support

All the CMMI process areas are categorized in these 4 categories. We can take example - process/activity "software implementation/coding". Apparently this activity is controlled by procedures from different process areas from all the 4 categories (e.g. by 'Technical solution', 'Organizational Process Focus', 'Project planning', 'Configuration management'), actually - one can attribute almost any process area to this activity.

How one is supposed to live and work with this? E.g. how one can describe and depict all the process interdependencies for one such activity "coding"? Does every procedure should refer to almost every activity in the company so that each activity is covered by 4-dimensional grid of CMMI PA categories or even worse by 24-dimensional grid of CMMI process activities (from all the 5 maturity levels)? Or maybe different process areas refer to different abstraction levels of the same activity? I am totally confused...

I need to write quality manyal for CMMI compliant (and agile) organization but no idea how to tackle this grid or network of interdependencies. Sole coding is much more simpler.

1 Answer 1


You're right that there are relationships between the process areas. For example, the activities that occur in Project Planning inform Project Monitoring and Control as to what needs to be monitored and controlled, and based on the monitoring, replanning may be done in accordance with Project Planning. There are also relationships between the Categories. For example, the Project Management process areas feed the Requirements Development and Requirements Management process areas, which inform Technical Solution as to what needs to be designed and implemented, and the outputs of Technical Solution are verified in accordance with Verification.

There's an entire chapter of CMMI-DEV 1.3 devoted to relationships among the process areas.

However, all activities that you can do on a project can fit neatly into one of the process areas. For example, you mention coding in your question. Coding is part of the Technical Solution process area. However, other things are also part of Technical Solution - writing support documentation (training materials, user's manuals, help), performing make/buy/reuse analysis, select solutions. Some of these are related to other process areas. For example, you Decision Resolution & Analysis (DAR) processes can be used in selecting a solution.

Now, you may realize that some related processes are at different levels. For example, Configuration Management and Requirements Management are at Maturity Level 2, while Technical Solution and Requirements Development are at Maturity Level 3. Clearly, if you are managing the configuration, you must have a solution that you are managing. However, it refers to what processes you need to have defined and have objective evidence of performing. It is expected that you have a defined and consistently implemented process for establishing baselines, tracking and controlling changes, and ensuring the integrity of your product before you have a defined and consistently implemented process for implementing a technical solution.

Something else to consider is that your processes may not may 1:1 with the CMMI Process Areas. Again, looking at Technical Solution, there are three specific goals - select product component solutions, develop the design, and implement the product design. Each of these could be three separate processes in your organization (as defined in Organizational Process Definition). You may be better served by looking at the General Goals and Specific Goals and grouping them appropriately in how you.

I think that Generic Goal 2: Institutionalize a Managed Process is most relevant to you. The first Generic Practice is to Establish an Organizational Policy. Here, the guidance is to simply elaborate on the process areas. There is no rules on how you go about elaborating. I also think that Generic Goal 1: Achieve the Specific Goals is something that you need to consider. You do this by implementing Generic Practice 1.1: Perform Specific Practices.

When designing a process or process framework for CMMI, the goals and practices are far more important than the process areas. These goals and practices are the things that are essential for a successful software project. There are countless ways to achieve them, and it will depend on your organization, your industry, your product, and more.

Also, since you mentioned the agile methods, you may be interested in information about embracing both agile and the CMMI and how the agile methods and CMMI complement each other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.