Where the Integrated Project Management (IPM) process area is mentioned in this chapter, it will refer to IPM for IPPD. Interactions of the IPM for IPPD process area with the Integrated Teaming (IT) and Organizational Environment for Integration (OEI) are covered.

Pocess areas this way to address the manner in which they interact and have an effect on one another regardless of their defined group. For example, the Decision Analysis and Resolution process area provides specific practices addressing formal evaluation that are used in the Technical Solution process area for selecting a technical solution from alternative solutions. Technical Solution is an Engineering process area and Decision Analysis and Resolution is a Support process area.

The Engineering process areas were written in a general engineering terminology so any technical discipline involved in the product development process (e.g., software engineering, mechanical engineering) can use them for process improvement. The Process Management, Project Management, and Support process areas also

To apply CMMI properly, the interactions that exist among CMMI model components need to be understood.

Process Management

Basic Process Management Process Areas

Figure 1 illustrates the interactions among the basic Process Management process areas and with other process area categories.

Organizational Process Focus

• helps the organization to plan and implement organizational process improvement based on an understanding of the current strengths and weaknesses of processes and process assets. Candidate process improvements are obtained through process-improvement proposals, measurement of the processes, lessons learned in implementing the processes, and results of process appraisal and product evaluation activities.

• establishes and maintains the set of standard processes and other assets based on the process needs and objectives of the organization. These other assets include descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. Projects tailor the organization’s set of standard processes to create their defined processes. The other assets support tailoring as well as implementation of the defined processes. Experiences and work products from performing these defined processes, including measurement data, process descriptions, process artifacts, and lessons learned, are incorporated as appropriate into the organization’s set of standard processes and other assets.

Organizational Training

• Identifies the strategic training needs of the organization as well as the tactical training needs that are common across projects and support groups. In particular, training is developed or obtained that develops the skills required to perform the organization’s set of standard processes. The main components of training include a managed training-development program, documented plans, personnel with appropriate knowledge, and mechanisms for measuring the effectiveness of the training program.

Organizational Process Definition

• Establishes and maintains the organization’s set of standard processes and other assets based on the process needs and objectives of the organization. These other assets include descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. Projects tailor the organization’s set of standard processes to create their defined processes. The other assets support tailoring as well as implementation of the defined processes. Experiences and work products from performing these defined processes, including measurement data, process descriptions, process artifacts, and lessons learned, are incorporated as appropriate into the organization’s set of standard processes and other assets.

Advanced Process Management Process Areas

Each of the advanced Process Management process areas is strongly dependent on the ability to develop and deploy process and supporting assets. The basic Process Management process areas provide this ability. ^[Note].

Organizational Process Performance

• derives quantitative objectives for quality and process performance from the organization’s business objectives. The organization provides projects and support groups with common measures, process performance baselines, and process performance models. These additional organizational support assets support quantitative project management and statistical management of critical sub-processes for both projects and support groups. The organization analyzes the process performance data collected from these defined processes to develop a quantitative understanding of product quality, service quality, and process performance of the set of standard processes.

Organizational Innovation and Deployment

• selects and deploys proposed incremental and innovative improvements that improve the organization’s ability to meet its quality and process performance objectives. The identification of promising incremental and innovative improvements should involve the participation of an empowered workforce aligned with the business values and objectives of the organization. The selection of improvements to deploy is based on a quantitative understanding of the potential benefits and costs from deploying candidate improvements, and the available funding for such deployment.

Project Management

Basic Project Management Process Areas

Project Planning

• includes developing the project plan, involving stakeholders appropriately, obtaining commitment to the plan, and maintaining the plan. When using an IPPD approach, stakeholders represent not just the technical expertise for product and process development, but also the business implications of the product and process development.
• Planning begins with requirements that define the product and project (“What to Build” in the figure). The project plan covers the various project management and engineering activities that will be performed by the project. The project will review other plans that affect the project from various relevant stakeholders and establish commitments with those relevant stakeholders for their contributions to the project. For example, these plans cover process appraisals, product evaluations, configuration management, and measurement and analysis.

Project Monitoring and Control

• includes monitoring activities and taking corrective action. The project plan specifies the appropriate level of project monitoring, the frequency of progress reviews, and the measures used to monitor progress. Progress is primarily determined by comparing progress to the plan. When actual status deviates significantly from the expected values, corrective actions are taken as appropriate. These actions may include re-planning.

Supplier Agreement Management

• addresses the need of the project to effectively acquire those portions of work that are produced by suppliers. Once a product component is identified and the supplier who will produce it is selected, a supplier agreement is established and maintained that will be used to manage the supplier. The supplier’s progress and performance are monitored. Acceptance reviews and tests are conducted on the supplier-produced product component.

Advanced Project Management Process Areas

Integrated Project Management

• Both versions of the Integrated Project Management process area (IPM and IPM for IPPD) establish and maintain the project’s defined process that is tailored from the organization’s set of standard processes. The project is managed using the project’s defined process. The project uses and contributes to the organization’s process assets.
• The project ensures that the relevant stakeholders associated with the project coordinate their efforts in a timely manner. It does this by providing for the management of stakeholder involvement; the identification, negotiation, and tracking of critical dependencies; and the resolution of coordination issues within the project with relevant stakeholders.

Integrated Project Management for IPPD

• This area also creates the shared vision for the project. This shared vision should align both horizontally and vertically with both the organization’s and integrated team’s shared visions, created in the Organizational Environment for Integration and Integrated Teaming process areas, respectively. These shared visions collectively support the coordination and collaboration among stakeholders. Finally, the Integrated Project Management for IPPD process area implements an integrated team structure to perform the work of the project in developing a product. This team structure is typically based on the decomposition of the product itself, much like a work breakdown structure. This activity is accomplished in conjunction with the Integrated Teaming process area.

Risk Management

• Although risk identification and monitoring are covered in the Project Planning and Project Monitoring and Control process areas, the Risk Management process area takes a more continuing, forward-looking approach to managing risks with activities that include identification of risk parameters, risk assessments, and risk handling.

Quantitative Project Management

• Applies quantitative and statistical techniques to manage process performance and product quality. Quality and process-performance objectives for the project are based on those established by the organization. The project’s defined process comprises, in part, process elements and sub-processes whose process performance can be predicted. At a minimum, the process variation experienced by sub-processes that is critical to achieving the project’s quality and process-performance objectives is understood. Corrective action is taken when special causes of process variation are identified.

Integrated Teaming

• The specific practices in the Integrated Teaming process area provide for the formation and sustainment of each integrated team. Part of sustaining the team is developing the integrated team’s shared vision, which must align with the project’s and organization’s shared visions, developed in the Integrated Project Management for IPPD and Organizational Environment for Integration process areas, respectively. The specific practices in the Organizational Environment for Integration and Integrated Teaming process areas then set the environment for enabling integrated teamwork. In addition, the Integrated Teaming process area interacts with other Project Management processes by supplying team commitments, work plans, and other information that forms the basis for managing the project and supporting risk management.

Integrated Supplier Management

• Proactively identifies sources of products that may be used to satisfy project requirements and monitors selected supplier work products and processes while maintaining a cooperative project-supplier relationship. The specific practices of the Integrated Supplier Management process area cover selecting potential sources of products, evaluating those sources to select suppliers, monitoring selected supplier processes and work products, and revising the supplier agreement or relationship as appropriate. The Integrated Supplier Management process area works closely with the Supplier Agreement Management process area during the supplier selection process. Integrated Supplier Management also shares monitoring information with the Engineering and Support process areas in the form of technical solution, product integration, and validation data as well as process and product quality assurance and configuration management data.

Engineering

The Engineering process areas integrate software-engineering and systems-engineering processes into a product-oriented process improvement scenario. Improving product development processes targets essential business objectives, rather than specific disciplines. This approach to processes effectively avoids the tendency toward an organizational “stovepipe” mentality.

The technical foundation for IPPD is grounded in a robust systems engineering approach that encompasses development in the context of the phases of the product’s life, such as that provided in the Engineering process areas of the CMMI-SE/SW model. Thus, the implementation of IPPD provides amplifications to specific practices in the Engineering process areas that emphasize concurrent development

The Engineering process areas apply to the development of any product or service in the engineering development domain (e.g., software products, hardware products, services, or processes).

Requirements Development

• Identifies customer needs and translates these needs into product requirements. The set of product requirements is analyzed to produce a high-level conceptual solution. This set of requirements is then allocated to a set of product component requirements. Other requirements that help define the product are derived and allocated to product components. This set of product and product-component requirements clearly describes the product's performance, design features, verification requirements, etc. in terms the developer understands and uses.
• Supplies requirements to the Technical Solution process area, where the requirements are converted into the product architecture, product-component design, and the product component itself (e.g., coding, fabrication). Requirements are also supplied to the Product Integration process area, where product components are combined and interfaces are ensured to meet the interface requirements supplied by Requirements Development.

Requirements Management

• maintains the requirements. It describes activities for obtaining and controlling requirement changes and ensuring that other relevant plans and data are kept current. It provides traceability of requirements from customer to product, to product component.

• ensures that changes to requirements are reflected in project plans, activities, and work products. This cycle of changes may impact all the other Engineering process areas; thus requirements management is a dynamic and often recursive sequence of events. Establishment and maintenance of the Requirements Management process area is fundamental to a controlled and disciplined engineering design process.

Technical Solution

• develops technical data packages for product components that will be used by the Product Integration process area. The examination of alternative solutions, with the intent of selecting the optimum design based upon established criteria, is expected. These criteria may be significantly different across products, depending on product type, operational environment, performance requirements, support requirements, and cost or delivery schedules. The task of selecting the final solution makes use of the specific practices in the Decision Analysis and Resolution process area.
• relies on the specific practices in the Verification process area to perform design verification and peer reviews during design and prior to final build.

Verification

• ensures that selected work products meet the specified requirements. The process area selects work products and verification methods that will be used to verify work products against specified requirements. Verification is generally an incremental process, starting with product-component verification and usually concluding with verification of fully assembled products.
• addresses peer reviews - a proven method for removing defects early and provide valuable insight into the work products and product components being developed and maintained.

Validation

• incrementally validates products against the customer’s needs. Validation may be performed in the operational environment or a simulated operational environment. Coordination with the customer on the validation requirements is one of the most essential elements of this process area.
• The scope of the Validation process area includes validation of products, product components, selected intermediate work products, and processes. The product, product component, selected intermediate work product, or process may often require re-verification and revalidation. Issues discovered during validation are usually resolved in the Requirements Development or Technical Solution process areas.

Product Integration

• establishes the expected specific practices associated with generating the best possible integration sequence, integrating product components and delivering the product to the customer.
• uses the specific practices of both Verification and Validation in implementing the product integration process. Verification verifies the interfaces and interface requirements between product components prior to product integration. This is an essential event in the integration process. During product integration in the operational environment, the specific practices of the Validation process area are used.

Engineering Process Areas and Recursion

There is no specific practice that forces recursive process application. Rather, the specific practices are written in a fashion that “expects” process application throughout the product architecture. When implementing the specific practices of an Engineering process area, they must be interpreted according to how they meet the needs of the product being delivered. The approach provides a generic set of expectations that can be applied at any level of product detail rather than as enabling recursive behavior of a process. Either description of this approach is appropriate.

There are a number of advantages gained by this approach. For example, the Engineering process areas can be applied to a product that has several layers of product components and ensure that the specific practices will address each layer. Thus, different segments of a very large project can be appraised using the same model.

Support

Basic Support Process Areas

Measurement and Analysis

• supports all process areas by providing specific practices that guide projects and organizations in aligning measurement needs and objectives with a measurement approach that will provide objective results. These results can be used in making informed decisions and taking appropriate corrective actions.

Process and Product Quality Assurance

• supports all process areas by providing specific practices for objectively evaluating performed processes, work products, and services against the applicable process descriptions, standards, and procedures and ensuring that any issues arising from these reviews are addressed. Process and Product Quality Assurance supports the delivery of high quality products and services by providing the project staff and all levels of managers with appropriate visibility into, and feedback on, the processes and associated work products throughout the life of the project.

Configuration Management

• supports all process areas by establishing and maintaining the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. The work products placed under configuration management include the products that are delivered to the customer, designated internal work products, acquired products, tools, and other items that are used in creating and describing these work products. Examples of work products that may be placed under configuration management include plans, process descriptions, requirements, design data, drawings, product specifications, code, compilers, product data files, and product technical publications.

Advanced Support Process Areas

Causal Analysis and Resolution

• the project strives to understand the common causes of variation inherent in processes and remove them from the project’s processes, as well as using this knowledge to continually improve organizational processes. Both the defined processes and the set of standard processes are targets of these improvement activities.

Decision Analysis and Resolution

• supports all the process areas by providing a formal evaluation process that ensures that alternatives are compared and the best one is selected to accomplish the goals of the process areas.

Organizational Environment for Integration

• establishes the approach and environment for the implementation of IPPD. The environment is established by obtaining, adapting, or developing processes that facilitate effective integrated team behavior as well as stakeholder communication and collaboration, creating the organization’s shared vision, and managing people to promote integrative behavior. Specific practices in the Organizational Environment for Integration process area promote both team and individual excellence while enabling and rewarding integration across all business and technical functions in the execution of the projects.

Tailoring a Model for an Organization

Criteria for Tailoring Internal Process Improvement

Given a CMMI’s focus on the essential characteristics of an effective process, most process areas and practices in a model typically would need to be addressed. The wholesale exclusion of fundamental processes or specific practices should be viewed with caution. Organizations and projects implementing less than a full set of process areas, goals, or practices may still achieve significant value from a CMMI model, but, because of the interrelationship of model components, exclusion of a significant number of process areas, goals, or practices may diminish the benefits achieved. In addition, the degree of comparability of appraisal results is directly related to the extent to which a model and appraisal method have been tailored.

Model Tailoring Criteria for Benchmarking

Criteria:

• Focus on a Specific Maturity/Capability Level

  Process areas include required and expected model components and thus may not be excluded other than to omit those that are outside the scope of an appraisal. For example, when an organization uses a staged representation, process areas at maturity levels 4 and 5 may be omitted for an appraisal focused on maturity level 3, whereas all process areas for maturity levels 2 and 3 would typically be selected. When using a continuous representation, process areas outside the scope of the target profile may be omitted, but doing so will compromise the benchmarking opportunities provided by equivalent staging.

• Process Areas Not Performed by the Organization

  Process areas, in some circumstances, may be determined to be “not applicable” if the process area is, in fact, outside of the organization’s scope of work. An example of a process area that might be excluded from an appraisal using a staged representation would be Supplier Agreement Management, a process area that may not be applicable in the absence of suppliers of products and services external to the organization that are critical to the development effort. A maturity level rating could still be determined; however, that maturity level rating must also include mention of the “not applicable” process area. Conversely, when using a continuous representation, process areas may be selected for exclusion if they are not within the organization’s scope of work or of the process-improvement effort. Care must be taken, however, that process areas providing the foundation for other process areas important to the organization are not excluded. Furthermore, even though an organization uses a continuous representation, if it wishes to use equivalent staging it must adhere to the tailoring guidelines practiced by users of the staged representation.

• Insufficient Information to determine Rating

  A process area is designated as “not rated” if it is outside the appraisal scope or if insufficient data is available to satisfy the data-coverage criteria. A maturity level cannot be determined if process areas at that maturity level (or below) are “not rated.”

• Process Area Goals

  Goals are required and thus cannot be excluded from those process areas included in the scope of a process-improvement or appraisal effort. Goals reflect the minimum requirements for satisfying a process area. If a process area is applicable, each of its goals is applicable. Goals work together to support a process area and may not be individually designated as “not applicable.”

• Substituting Practices which Meet Goals

  Specific practices and generic practices are expected to be implemented as typical activities necessary to implement and institutionalize the goals of the process area. However, appropriate alternative practices may be substituted for specific practices and/or generic practices if the alternatives are effective in implementing and institutionalizing the goals.

• Informative Components

  All other model components (subpractices, examples, amplifications, elaborations, and/or references) contained in CMMI models are informative and are provided solely for guidance in implementation.

Smaller Projects

Conversely, in the project plan, the detailed planning of the project, such as the schedule, tasks, and resources, are defined. Often the project plan also contains plans for other supporting functions, such as quality assurance and configuration management. A four-person project might expect to develop a project plan that is only a few pages long.

In small projects, meetings take place more frequently, take less time, and cover more details. The schedule may contain daily activities, and may be monitored in weekly meetings. The schedule may change weekly and be controlled.

In a small team, the customer usually knows the entire team and feels comfortable calling any member of the team to propose or discuss a change. The team must decide up front how to handle these informal calls from the customer. Once team members have decided on an approach, it should be documented and communicated to the customer.

Tailoring Options

• Establishing the appraisal scope, including the organizational entity to be appraised, the CMMI process areas to be investigated, and the level to be appraised
• Selecting the appraisal method
• Selecting the appraisal team members
• Selecting appraisal participants from the appraisal entity to be interviewed
• Establishing appraisal outputs (for example, ratings, instantiation specific findings)
• Establishing appraisal constraints (for example, time spent on site)