Process Areas for the Maturity Level 3: Defined

This chapter is designed to help the reader understand the basic tenets of Maturity Level 3 in the staged representation of the CMMI . However, because this chapter consists of summaries of the process areas, anyone wishing to get a better idea of the model, no matter which representation is to be used, can benefit from this chapter. Once again, we are not attempting to teach the CMMI; we simply offer a condensed version of the various areas and key points to consider.

Moving from Level 2 to Level 3

Maturity Level 3 differs from Level 2 in that now an organizational way of doing business has been developed. What that means is that the best practices and lessons learned from the projects have bubbled up to the organizational level to create an organizational identity. There are common, shared approaches for performing daily tasks on each project. For example, estimating the size of a project may be done using the Delphi Technique (basically subject matter experts discussing a series of best-case and worst-case estimates), a standard metric may have been institutionalized (such as using function points instead of lines of code), and a standard tool may be in use to actually calculate the size .

This organizational way of doing business is documented in the Organization's Set of Standard Processes (OSSP). However, should a project need to tailor this OSSP to more adequately fit its needs, then that tailoring request is brought to a decision-making body (usually the Engineering Process Group ” EPG), and if appropriate, the request is granted. An example may be a legacy system that calculates size by lines of code instead of by function point. Rather than reengineer the millions of lines of code in the system in order to use a tool to count function points, and rather than do it manually, the project is simply allowed to continue calculating size by lines of code. The Delphi Technique discussed above is still used, but lines of code is the measurement.

To perform at Maturity Level 3, an organization must have satisfied all the goals for all of the process areas in both Level 2 and Level 3. Sometimes, exceptions can be made. For example, if an organization has no outside agreements, then Supplier Agreement Management at Level 2 and Integrated Supplier Management at Level 3 may not apply. Therefore, those process areas are determined to be N/A. Caution should be exercised however. Entire process areas are generally not allowed to be tailored out of consideration. Practices can be tailored out if replaced by sufficient alternative practices. Remember: the more tailoring done, the less likely an organization is to achieve improvement, and the less likely the organization is to achieve a maturity level through an assessment.

The CMMI makes a point of stating that, at Level 3, the organization has more distinctly defined its processes. We feel that this statement leads the reader to many wrong conclusions. This statement does not mean to wait until Level 3 to define your processes. When defining processes, an organization should always try to define them so that they can be followed ” even at Level 2. Processes are at a high level ” it is their associated procedures that detail how to perform the processes. Review Chapter 16 of this book for more information.

The CMMI states that the following attributes of a process are necessary. We suggest that you follow this " mandate ." However, we also suggest that you add what needs to be added. Some organizations have also combined the inputs and entry criteria into one attribute, and the outputs and exit criteria into another attribute. While purists will object to that, we have seen it work in organizations. And after all ” the beef is in the procedures, not the processes.

The following items are to be included in process definitions:

• Purpose: Purpose of the process

• Inputs: Work products, plans, approval memoranda (usually nouns)

• Entry criteria: What must be triggered before this process can start? (Usually the exit criteria of the previous step or process. Usually stated as a verb.)

• Activities: Tasks that must be performed. These tasks are usually later broken down into the detailed procedures for how to perform the tasks.

• Roles: Who does what (usually by position)

• Measures: What measures does this process produce?

• Verification steps: What reviews are performed to determine that this process is followed and is producing the correct results? (Usually management and quality assurance reviews, but sometimes can include customer, peer, and project team reviews.)

• Outputs: Work products, plans, approved products. (Can be the completed inputs.)

• Exit criteria: How do we know when it is time to stop this process? (Usually expressed in verbs, and usually becomes the entry criteria for the next process step or next process.)

Another distinction is made concerning processes. A managed process is a process that tackles project management efforts, is planned and executed according to a policy, and is monitored and reviewed to ensure adherence to its process description. This is the type of process expected at Maturity Level 2. A defined process builds upon a managed process by creating an organizational process that is then tailored to fit the needs of a particular project, and involves gathering information related to improvement efforts undertaken by the organization, in order to improve both the organization-level process and the project-level process. This is the type of process expected at Maturity Level 3.

There are 14 process areas for Maturity Level 3:

1. Requirements Development

2. Technical Solution

3. Product Integration

4. Verification

5. Validation

6. Organizational Process Focus

7. Organizational Process Definition

8. Organizational Training

9. Integrated Project Management (including for IPPD)

10. Risk Management

11. Integrated Teaming

12. Integrated Supplier Management

13. Decision Analysis and Resolution

14. Organizational Environment for Integration

You will notice that Level 3 has expanded to include engineering process areas and Integrated Product and Process Development (IPPD). IPPD is about forming teams that include subject matter experts from all areas needed to produce the product for the customer. An example might be when building a new jet fighter. This effort would require hundreds or thousands of individuals to work on developing all parts of the plane, including the sophisticated software systems for navigation, landing, communications, and attack; the actual construction of the hardware and fuselage of the plane; safety engineers to test safety-critical parts and functioning; mechanics to ensure that the plane would be easy and quick to repair under emergency and nonemergency conditions; pilots to ensure that the plane could actually be flown; documentation experts to ensure that all necessary documentation and manuals were written correctly; and others. In cases such as this one, rather than try to include comments and ideas from everyone working on the project (that is, to design and deliver a working jet fighter plane), representatives from each area would be assigned to an Integrated Product Team (IPT). This team would develop a shared vision of what the final product should look like and what its final functionality should include. They would also be responsible for ensuring that input from all areas was included in the requirements gathering, design, development, testing, and final delivery of the product.

The Generic Goals for Level 3 are somewhat different from Level 2. The generic goals are listed below. We use the abbreviations GG for Generic Goal and GP for Generic Practice. The Common Features (Commitment to Perform ” CO, Ability to Perform ” AB, Directing Implementation ” DI, and Verifying Implementation ” VE) are also abbreviated.

• GG3: Institutionalize a defined process

  • GP2.1 (CO1): Establish an organizational policy

  • GP3.1 (AB1): Establish a defined process

  • GP2.2 (AB2): Plan the process

  • GP2.3 (AB3): Provide resources

  • GP2.4 (AB4): Assign responsibility

  • GP2.5 (AB5): Train people

  • GP2.6 (DI1): Manage configurations

  • GP2.7 (DI2): Identify and involve relevant stakeholders

  • GP2.8 (DI3): Monitor and control the process

  • GP3.2 (DI4): Collect improvement information

  • GP2.9 (VE1): Objectively evaluate adherence

  • GP2.10 (VE2): Review status with higher-level management

To satisfy the goals for Level 3, the goals for Level 2 must be satisfied as well. This mandate holds true for both the specific goals and the generic goals listed above. So, reviewing the list of generic goals above reveals that the generic goals for Level 2 are still there, plus the addition of one more goal (actually replacing GG2 ” or GG3 subsuming GG2 to use a CMMI phrase) and two more corresponding generic practices (GP3.1 and GP3.2). The Level 3 generic goal is Institutionalize a Defined Process; and the two generic practices that make that goal possible are Establish a Defined Process and Collect Improvement Information. So, the CMMI is asking us to implement these practices for each individual process area.

The following pages discuss each process area for Level 3. We use the abbreviations SG for Specific Goal and SP for corresponding Specific Practices.