Process Improvement Essentials: CMMI, Six SIGMA, and ISO 9001

6.9. Support Process Areas

The following sections detail the Process Areas specific to support.

6.9.1. Configuration Management

The role of Configuration Management in CMMI covers two areas: technical configuration management and change control. Configuration Management is a discipline designed to ensure the integrity of the work products that impact project success. In the realm of systems and software development, this most often includes configuration management of source code, code compilers, and key technical documentation. But in mature organizations, this usually expands to include other items as well. Often you'll find that it's beneficial to configuration-manage such products as the requirements specification, system designs, test plans, and even such management items as the Project Plan. The scope of Configuration Management naturally depends upon the scope of your project. But whether you elect basic or comprehensive configuration management, the practices remain the same.

The other focus is change control. As change is a natural component of any project, it is important that the organization set into place some form of change management. A basic change-control program typically includes such elements as a change-control process (for introducing and assessing change requests), some manner of change-management system, and a change-management body such as a change-control board.

Both these facetsversion control of configured items and change managementserve as support arms for project management. They provide for the incorporation and coordination of change over a project's progression across time.

6.9.1.1. Three specific goals

CMMI presents three goals for Configuration Management:

1. Establish baselines of selected work products. Here, the configuration manager ensures that some form of Configuration Management system exists for the project and then works with project management to identify which work products produced by the project team will be placed under Configuration Management control. From this planning activity, the configuration manager can then create and release baselines of these products for use by the team.

2. Track and control proposed and adopted changes to the work products. Here, the configuration manager (and perhaps a change-control board) employs some manner of change-control system to track change requests as they come into a project and to monitor change actions that are approved for incorporation. The configuration manager is also responsible for managing how those approved change items are integrated into product baselines.

3. Establish and report on the integrity of the work products. This goal is in place to ensure that items under configuration control are regularly monitored for integrity. This usually includes conducting configuration library audits and issuing regular audit reports to the team.

6.9.1.2. Core Configuration Management actions

The configuration manager monitors and controls a defined set of project work products through a Configuration Management system by creating baselines, tracking changes, and periodically reporting on the integrity of designated work products.

Applies to Support:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-13 illustrates the Configuration Management PA.

6.9.2. Process and Product Quality Assurance

The PPQA Process Area in CMMI is the model's core compliance component. Process and Product Quality Assurance is in many ways kin to Configuration Management. Its function is to ensure the integrity of a project's work products and processes from a standards viewpoint. A PPQA analyst^[*] assigned to a project monitors two operational areas. First, the analyst is responsible for work product compliance. Key here is confirming that selected work products produced during the various phases of a project are created in accordance with established formats, content guides, and scope projections. Second, the analyst is responsible for process compliance. This involves the work activities on a project. The goal here is to confirm that the major work activities for a project are conducted in compliance with published process standards.

^[*] I call this role an analyst. That's just my term. This can be a full-time role, a part-time role, or a role shared by multiple members of your teams.

The chief tool of PPQA is the audit. Through the use of a PPQA Plan, the PPQA analyst identifies certain milestone points in the project where product and process audits should take place. The audits are then conducted against a checklist of compliance items, and the results of the audit are distributed to project managers, identified team members, and executive management.

As noted earlier, this PA is also related to Verification. But it differs in one key way. Verification contains a peer-review process conducted by team members reporting to project management. PPQA is an activity typically managed by a function that reports to executive management in addition to project management. The main job of the PPQA analyst is to provide objective evidence that project teams within the organization at large are conducting project activities according to established processes.

6.9.2.1. Two specific goals

Two goals are defined for Process and Product Quality Assurance:

1. Objectively evaluate processes and work products. This goal is in place to ensure that each project team is provided with objective criteria that can be applied to evaluate process compliance and work product suitability. The key is to remove as much subjectivity as possible so that performance expectations and suitability standards are clear to everyone and can be consistently evaluated.

2. Provide objective insight into the efficiency and effectiveness of project processes. This goal provides the documentation and measurement component for this Process Area. Here, the PPQA analyst communicates and tracks noncompliance items to make sure they are remedied in an acceptable manner, and also records measures of these events and audits in general to provide a basis for future process improvement.

6.9.2.2. Core Process and Product Quality Assurance actions

A Process and Product Quality Assurance analyst, using objective criteria, works with the project team to audit activities and work products to make sure that they are being conducted in a manner compliant with published processes, procedures, and standards.

Applies to Support:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-14 illustrates the Process and Product Quality Assurance PA.

6.9.3. Measurement and Analysis

The Measurement and Analysis Process Area presents the foundation for quantitative analysis (and process growth) within project management and across the organization as a whole. As it is introduced here, this Process Area need not be thought of as a full-blown metrics program. Measurement and Analysis may begin small and then lead to a fuller metrics approach to process improvement and program management. Here, each project (coordinated mainly through Project Management, Configuration Management, and Process and Product Quality Assurance) defines a set of measurements that will be collected at various points during the life of a project. These measurements are then incorporated into an M&A plan that specifies how the data will be collected, who will collect it, where the data will be stored, and how it will be used.

The main objective of this Process Area is to create a metrics repositorya central database for measurement storage. In the short term, this data can be analyzed as a way to measure variance, as an early indicator of project trends, and as a numeric mechanism to compare projects. In the long term, the repository will serve as a base for establishing quantitative project management measurements and for studying causal analysis with a view toward defect resolution and prevention.

6.9.3.1. Two specific goals

CMMI defines two goals for Measurement and Analysis:

1. Align defined measures and analyses with project activities. In other words, make sure that what you want to measure is in harmony with the activity occurring on the project. This involves defining the measures to collect over the course of a project and specifying how the measures are to be calculated and collected, how they are to be stored, and how they are to be analyzed.

2. Provide measurement results. This goal defines how the collected measures are to be compiled and reported both to the project team and executive management. This can include such facets as reporting regularity and responsibility, report formatting, communication avenues, and data retention policies.

6.9.3.2. Core Measurement and Analysis actions

Measurements are identified, defined, and collected for key activities and project phases. Once collected, they are used by project management and executive management to interpret project progress and as a mechanism to quantify project and process improvement as a whole.

Applies to Support:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-15 illustrates the Measurement and Analysis PA.

6.9.4. Decision Analysis and Resolution

The purpose of Decision Analysis and Resolution is to give teams a path to follow when making major decisions with the potential to impact the course of a project over its life cycle. Such decision making is common to all projects. At issue here is the manner in which decisions are arrived at. In organizations that lack sufficient or mature processes, projects are usually managed by intuition, by the "gut feeling" of the project manager. In this case, the better the project manager, the better the decisions being made. But this approach does not add much stability to an organization's operational capability.

A better approach is to provide a team with decision-making guidelines that promote analysis and the evaluation of alternatives. This approach is not designed to eliminate intuition or experience in project management. Its aim is to augment those qualities within a more regulated framework, one that sets methods for establishing alternatives, weighing the viability of alternatives, and selecting alternatives appropriate to the decision at hand.

6.9.4.1. One specific goal

CMMI has one goal defined for Decision Analysis and Resolution:

1. Evaluate alternatives before making a decision. This goal is based on a series of activities undertaken to guide the decision-making process. First, the organization establishes guidelines for decision analysis. This typically includes categorizing the major types of decisions addressed over the course of a project (decisions like budget changes, schedule adjustments, resource allocations, etc.). Next, these decision types are defined through a set of evaluation criteria, criteria that help establish the scope and impact of the decision on the project. Based on this, the team can explore alternatives that address these criteria, with each alternative being ranked by the suitability. Through this effort, a specific decision can be made that is best suited to the situation at hand.

6.9.4.2. Core Decision Analysis and Resolution actions

The organization provides project teams with a method for evaluating and weighing alternatives as part of the decision-making process.

Applies to Support:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-16 illustrates the Decision Analysis and Resolution PA.

6.9.5. Causal Analysis and Resolution

Causal Analysis and Resolution addresses the issue of defect analysis and prevention. The purpose here is to investigate the potential causes for the occurrence of defects (in processes and products) and then design solutions to remove these causes from current and future project work. This Process Area requires several things of the organization. First, the organization must be adept at defect tracking. This typically involves some formalized process for product inspection (see the Verification Process Area, under "Engineering Process Areas"), as well as procedures for thorough process analysis and in-depth product testing. These procedures should provide the organization with a repository of defect data, sources, and frequencies. Next, the organization should have a method in place (with appropriate resources) to select and investigate a set of priority defects. These defects are analyzed to determine possible causes, and from these possible causes, corrective-action options are defined. Further production investigation is undertaken to verify defect causes, and then appropriate actions are selected to remove the causes.

Causal Analysis and Resolution is an ongoing process in an organization. It can be applied to all manner of work products and activities. And it represents a core focus of any advanced process improvement program.

6.9.5.1. Two specific goals

Two goals are defined in CMMI for Causal Analysis and Resolution:

1. Determine the causes of defects. This goal establishes practices to pinpoint focal points for defect prevention: in code, in work products, in processes. This includes examining defect data sets to decide which analyses will prove most beneficial to the organization. Using these defect sets, an appointed team then investigates potential causes further, identifying the highest-profile or most likely causes.

2. Address the identified causes of the defects. This activity takes action from the first goal. Here, the team decides how to remove the causes from the production process. This usually involves a choice among possible actions. The team should evaluate which choice holds the most promise for the situation at hand. Once this is decided, the team implements the corrective actions and monitors the result of this adaptation. If the change has proved effective, the team can focus on other defect areas; if not, further action may be called for.

Throughout this process, the team records its findings in a repository for future process improvement information.

6.9.5.2. Core Causal Analysis and Resolution actions

The organization examines sets of defect data to determine likely causes, modifies processes to test potential solutions, and then records the validity and effectiveness of these solutions.

Applies to Support:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-17 illustrates the Causal Analysis and Resolution PA.