CMMI - Level 3 Maturity

CMMI - The Defined Organization

Requirements Development

Technical Solution

Product Integration

Integrated Project Management for IPPD

Risk Management

Integrated Teaming

Integrated Supplier Management

Decision Analysis & Resolution

Organizational Environment for Integration

REQD: Requirements Development

Purpose

To produce and analyze customer, product, and product-component requirements.

This process area describes three types of requirements: customer requirements, product requirements, and product-component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).

Requirements are the basis for design. The development of requirements includes:

Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
Collection and coordination of stakeholder needs
Development of the life-cycle requirements of the product
Establishment of the customer requirements
Establishment of initial product and product-component requirements consistent with customer requirements

This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.

Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product-component requirements are derived from the selected design solutions.

Requirements are identified and refined throughout the phases of the product life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s life cycle are analyzed for impact on derived and allocated requirements.

The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product-component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product-component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.

Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include:

Analysis of needs and requirements for each product life-cycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability
Development of an operational concept
Definition of the required functionality

The definition of functionality, also referred to as “functional analysis,” is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining the services. The definition of functions, their logical groupings, and their association with requirements is referred to as a “functional architecture.”

Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of:

Constraints of various types
Technological limitations
Cost and cost drivers
Time constraints and schedule drivers
Risks
Consideration of issues implied but not explicitly stated by the customer or end user
Factors introduced by the developer’s unique business considerations, regulations, and laws

A hierarchy of logical entities (functions and sub-functions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, associated processes, or services.

Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.

Specific Goals

Goal	Supporting Practices	Sub Practices
REQD-1: Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders (e.g., customers, end users, suppliers, builders, and testers) are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements. Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since stakeholder needs, expectations, constraints, and limitations should be clearly identified and understood, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, a surrogate for the end user or customer is frequently involved to represent their needs and help resolve conflicts. The customer relations or marketing part of the organization as well as members of the development team from disciplines such as human engineering or support can be used as surrogates. Environmental, legal, and other constraints should be considered when creating and resolving the set of customer requirements.	Collect Stakeholder Needs	[SP]
	Elicit Needs	[SP]
	Develop the Customer Requirements	[SP]
REQD-2: Develop Product Requirements Customer requirements are refined and elaborated to develop product and product-component requirements. Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product-component requirements.” Product and product-component requirements address the needs associated with each product life-cycle phase. Derived requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined. The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements established.	Establish Product and Product-Component Requirements	[SP]
	Allocate Product-Component Requirements	[SP]
	Identify Interface Requirements	[SP]
REQD-3: Analyze and Validate Requirements The requirements are analyzed and validated, and a definition of required functionality is developed. The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment. Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders' needs, expectations, constraints, and interfaces. Considerations such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for timecritical sequencing of functions. The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept. Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment.	Establish Operational Concepts and Scenarios	[SP]
	Establish a Definition of Required Functionality	[SP]
	Analyze Requirements	[SP]
	Analyze Requirements to Achieve Balance	[SP]
	Validate Requirements	[SP]
	Validate Requirements with Comprehensive Methods	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component requirements, and analyzing and validating those requirements.
Plan the Process: Typically, this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product-component requirements may be required. Examples of other resources provided include:
- Requirements specification tools
- Simulators and modeling tools
- Prototyping tools
- Scenario definition and management tools
- Requirements tracking tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.
Train People: Examples of training topics include:
- Application domain
- Requirements definition and analysis
- Requirements elicitation
- Requirements specification and modeling
- Requirements tracking
Manage Configurations: Examples of work products placed under configuration management include:
- Customer requirements
- Functional architecture
- Product and product-component requirements
- Interface requirements
Identify and Involve Relevant Stakeholders: Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include:
- Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
- Establishing operational concepts and scenarios
- Assessing the adequacy of requirements
- Establishing product and product-component requirements
- Assessing product cost, schedule, and risk
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Cost, schedule, and effort expended for rework
- Defect density of requirements specifications
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Collecting stakeholder needs
- Formulating product and product-component requirements
- Analyzing and validating product and product-component requirements
Examples of work products reviewed include:
- Product requirements
- Product-component requirements
- Interface requirements
- Functional architecture
Review Status with Higher Level Management: Review the activities, status, and results of the requirements development process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined requirements development process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the requirements development process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the requirements development process to achieve the established quantitative quality and processperformance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the requirements development process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the requirements development process.

TS: Technical Solution

Purpose

To design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combinations as appropriate.

The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, product-related life-cycle process, and service. The process area focuses on :

Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated requirements
Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
Implementing the designs as a product or product component Typically, these activities interactively support each other. Some level of design, at times fairly detailed, may be needed to select solutions.

Product-component prototypes may be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements.

Technical Solution specific practices apply not only to the product and product components but also to services and product-related life-cycle processes. The product-related life-cycle processes are developed in concert with the product or product component. Such development may include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.

Processes associated with the Technical Solution process area receive the product and product-component requirements from the requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.

For a maintenance or sustainment organization, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.

Specific Goals

Goal	Supporting Practices	Sub Practices
TS-1: Select Product-Component Solutions Product or product-component solutions are selected from alternative solutions. Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural features that provide a foundation for product improvement and evolution are considered. Use of commercial off-the-shelf (COTS) product components are considered relative to cost, schedule, performance, and risk. COTS alternatives may be used with or without modification. Sometimes such items may require modifications to aspects such as interfaces or a customization of some of the features to better achieve product requirements. More...	Develop Alternative Solutions and Selection Criteria	[SP]
	Develop Detailed Alternative Solutions and Selection Criteria	[SP]
	Evolve Operational Concepts and Scenarios	[SP]
	Select Product-Component Solutions	[SP]
TS-2: Develop the Design Product or product-component designs are developed. Product or product-component designs must provide the appropriate content not only for implementation, but also for other phases of the product life cycle such as modification, reprocurement, maintenance, sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during development and in subsequent phases of the product life cycle. A complete design description is documented in a technical data package that includes a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis for achieving a high degree of definition and completeness in design documentation.	Design the Product or Product Component	[SP]
	Establish a Technical Data Package	[SP]
	Establish Interface Descriptions	[SP]
	Design Interfaces Using Criteria	[SP]
	Perform Make, Buy, or Reuse Analyses	[SP]
TS-3: Implement the Product Design Product components, and associated support documentation, are implemented from their designs. Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components before sending them to product integration and development of enduser documentation.	Implement the Design	[SP]
	Develop Product Support Documentation	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for addressing the iterative cycle in which product-component solutions are selected, product and product-component designs are developed, and the product-component designs are implemented.
Plan the Process: Typically, this plan for performing the technical solution process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Special facilities may be required for developing, designing, and implementing solutions to requirements. When necessary, the facilities required for the activities in the Technical Solution process area are developed or purchased. Examples of other resources provided include the following tools: [PA160.EL104]
- Design specification tools
- Simulators and modeling tools
- Prototyping tools
- Scenario definition and management tools
- Requirements tracking tools
- Interactive documentation tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the technical solution process.
Train People: Examples of training topics include:
- Application domain of the product and product components
- Design methods
- Interface design
- Unit testing techniques
- Standards (e.g., product, safety, human factors, environmental)
Manage Configurations: Examples of work products placed under configuration management include:
- Product, product component, process, service, and interface designs
- Technical data packages
- Interface design documents
- Criteria for design and product-component reuse
- Implemented designs (e.g., software code, fabricated product components)
- User, installation, operation, and maintenance documentation
Identify and Involve Relevant Stakeholders: Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: [PA160.EL114]
- Developing alternative solutions and selection criteria
- Evolving operational concept and scenarios
- Obtaining approval on external interface specifications and design descriptions
- Developing the technical data package
- Assessing the make, buy, or reuse alternatives for product components
- Implementing the design
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Cost, schedule, and effort expended for rework
- Percentage of requirements addressed in the product or product-component design
- Size and complexity of the product, product components, interfaces, and documentation
- Defect density of technical solutions work products
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting product-component solutions
- Developing product and product-component designs
- Implementing product-component designs
Examples of work products reviewed include:
- Technical data packages
- Product, product-component, and interface designs
- Implemented designs (e.g., software code, fabricated product components)
- User, installation, operation, and maintenance documentation
Review Status with Higher Level Management:Review the activities, status, and results of the technical solution process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined technical solution process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the technical solution process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the technical solution process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the technical solution process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the technical solution process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the technical solution process.

PI: Product Integration

Purpose

To assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.

This process area addresses the integration of product components into more complex product components or into complete products. The term “integration” is used in this sense throughout this process area and is not to be confused with integration of people or activities that may be described elsewhere in the model.

The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures.

A critical aspect of product integration is the management of internal and external interfaces of the products and product components to ensure compatibility among the interfaces. Attention should be paid to interface management throughout the project.

Product integration is more than just a one-time assembly of the product components at the conclusion of design and fabrication. Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components. This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic incremental functionality until the final product is achieved. In each successive build, prototypes (virtual, rapid, or physical) are constructed, evaluated, improved, and reconstructed based upon knowledge gained in the evaluation process. The degree of virtual vs. physical prototyping required depends on the functionality of the design tools, the complexity of the product, and its associated risk. There is a high probability that the product, integrated in this manner, will pass product verification and validation. For some products, the last integration phase will occur when the product is deployed at its intended operational site.

Specific Goals

Goal	Supporting Practices	Sub Practices
PI-1: Prepare for Product Integration Preparation for product integration is conducted. Preparing for integration of product components involves establishing and maintaining an integration sequence, the environment for performing the integration, and integration procedures. The specific practices of the Prepare for Product Integration specific goal build on each other in the following way. The first specific practice determines the sequence for product and product-component integration. The second determines the environment that will be used to carry out the product and product-component integration. The third develops procedures and criteria for product and product-component integration. Preparation for integration starts early in the project and the integration sequence is developed concurrently with the practices in the Technical Solution process area.	Determine Integration Sequence	[SP]
	Establish the Product Integration Environment	[SP]
	Establish Product Integration Procedures and Criteria	[SP]
PI-2: Ensure Interface Compatibility The product-component interfaces, both internal and external, are compatible. Many product integration problems arise from unknown or uncontrolled aspects of both internal and external interfaces. Effective management of product-component interface requirements, specifications, and designs helps ensure that implemented interfaces will be complete and compatible.	Review Interface Descriptions for Completeness	[SP]
	Manage Interfaces	[SP]
PI-3: Assemble Product Components and Deliver the Product Verified product components are assembled and the integrated, verified, and validated product is delivered. Integration of product components proceeds according to the product integration sequence and available procedures. Before integration, each product component should be confirmed to be compliant with its interface requirements. Product components are assembled into larger, more complex product components. These assembled product components are checked for correct interoperation. This process continues until product integration is complete. If, during this process, problems are identified, the problem should be documented and a corrective action process initiated. Ensure that the assembly of the product components into larger and more complex product components is conducted according to the product integration sequence and available procedures. The timely receipt of needed product components and the involvement of the right people contribute to the successful integration of the product components that compose the product.	Confirm Readiness of Product Components for Integration	[SP]
	Assemble Product Components	[SP]
	Evaluate Assembled Product Components	[SP]
	Package and Deliver the Product or Product Component	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for developing product integration sequences, procedures, and an environment, ensuring interface compatibility among product components, assembling the product components, and delivering the product and product components.
Plan the Process: This plan for performing the product integration process addresses the comprehensive planning for all of the specific practices in this process area, from the preparation for product integration all the way through to the delivery of the final product.
Provide Resources: Product-component interface coordination may be accomplished with an Interface Control Working Group consisting of people who represent external and internal interfaces. Such groups can be used to elicit needs for interface requirements development. Special facilities may be required for assembling and delivering the product. When necessary, the facilities required for the activities in the Product Integration process area are developed or purchased.
Examples of other resources provided include:
- Prototyping tools
- Analysis tools
- Simulation tools
- Interface management tools
- Assembly tools (e.g., compilers, make files, joining tools, jigs and fixtures)
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the product integration process.
Train People: Examples of training topics include:
- Application domain
- Product integration procedures and criteria
- Organization's facilities for integration and assembly
- Assembly methods
- Packaging standards
Manage Configurations: Examples of work products placed under configuration management include:
- Acceptance documents for the received product components
- Evaluated assembled product and product components
- Product integration sequence
- Product integration procedures and criteria
- Updated interface description or agreement
Identify and Involve Relevant Stakeholders: Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include:
- Reviewing interface descriptions for completeness
- Establishing the product integration sequence
- Establishing the product integration procedures and criteria
- Assembling and delivering the product and product components
- Communicating the results after evaluation
- Communicating new, effective product integration processes to give affected people the opportunity to improve their performance.
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Product-component integration profile (e.g., product-component assemblies planned and performed, and number of exceptions found)
- Integration evaluation problem report trends (e.g., number written and number closed)
- Integration evaluation problem report aging (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Establishing and maintaining a product integration sequence
- Ensuring interface compatibility
- Assembling product components and delivering the product
Examples of work products reviewed include:
- Product integration sequence
- Product integration procedures and criteria
- Acceptance documents for the received product components
- Assembled product and product components
Review Status with Higher Level Management:Review the activities, status, and results of the product integration process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined product integration process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the product integration process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the product integration process that address quality and process performance based on customer needs and business objectives.
Stabilize Sub-process Performance: Stabilize the performance of one or more sub-processes to determine the ability of the product integration process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the product integration process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the product integration process.

VER: Verification

Purpose

To ensure that selected work products meet their specified requirements.

Verification of work products substantially increases the likelihood that the product will meet the customer, product, and product-component requirements.

The Verification process area involves the following:

verification preparation,
verification performance, and
identification of corrective action.

Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product-component requirements.

Verification is inherently an incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.

The specific practices of this process area build upon each other in the following way:

the Select Work Products for Verification specific practice enables the identification of the work products to be verified, the methods to be used to perform the verification, and the requirements to be satisfied by each selected work product.
the Establish the Verification Environment specific practice enables the determination of the environment that will be used to carry out the verification.
The Establish Verification Procedures and Criteria specific practice then enables the development of verification procedures and criteria that are aligned with the selected work products, requirements, methods, and characteristics of the verification environment.
The Perform Verification specific practice conducts the verification according to the available methods, procedures, and criteria.

The Verification and Validation process areas are similar, but they address different issues. Validation demonstrates that the product, as provided (or as it will be provided), will fulfill its intended use, whereas verification addresses whether the work product properly reflects the specified requirements. In other words, verification ensures that “you built it right;” whereas, validation ensures that “you built the right thing.”

Peer reviews are an important part of verification and are a proven mechanism for effective defect removal. An important corollary is to develop a better understanding of the work products and the processes that produced them so defects can be prevented and process improvement opportunities can be identified. ^[Note]

Specific Goals

Goal	Supporting Practices	Sub Practices
VER-1: Prepare for Verification Preparation for verification is conducted. Up-front preparation is necessary to ensure that verification provisions are embedded in product and product-component requirements, designs, developmental plans, and schedules. Verification includes selection, inspection, testing, analyses, and demonstration of work products. Methods of verification include, but are not limited to, inspections, peer reviews, audits, walkthroughs, analyses, simulations, testing, and demonstrations. Preparation also entails the definition of support tools, test equipment and software, simulations, prototypes, and facilities.	Select Work Products for Verification	[SP]
	Establish the Verification Environment	[SP]
	Establish Verification Procedures and Criteria	[SP]
VER-2: Perform Peer Reviews Peer reviews are performed on selected work products. Peer reviews involve a methodical examination of work products by the producers' peers to identify defects for removal and to recommend other changes that are needed. The peer review is an important and effective engineering method implemented via inspections, structured walkthroughs, or a number of other collegial review methods. Peer reviews are primarily applied to work products developed by the projects, but they can also be applied to other work products such as documentation and training work products that are typically developed by support groups.	Prepare for Peer Reviews	[SP]
	Conduct Peer Reviews	[SP]
	Analyze Peer Review Data	[SP]
VER-3: Verify Selected Work Products Selected work products are verified against their specified requirements.	Perform Verification	[SP]
	Analyze Verification Results and Identify Corrective Action	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for establishing and maintaining verification methods, procedures, criteria, verification environment, performing peer reviews, and verifying selected work products.
Plan the Process: Typically, this plan for performing the verification process is included in (or referenced by) the project plan, which is described in the Project Planning process area.
Provide Resources: Special facilities may be required for verifying selected work products. When necessary, the facilities required for the activities in the Verification process area are developed or purchased. Certain verification methods may require special tools, equipment, facilities, and training (e.g., peer reviews may require meeting rooms and trained moderators; certain verification tests may require special test equipment and people skilled in the use of the equipment). Examples of other resources provided include:
- Test management tools
- Test-case generators
- Test-coverage analyzers
- Simulators
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the verification process.
Train People: Examples of training topics include:
- Application domain
- Verification principles, standards, and methods (e.g., analysis, demonstration, inspection, test)
- Verification tools and facilities
- Peer review preparation and procedures
- Meeting facilitation
Manage Configurations: Examples of work products placed under configuration management include:
- Verification procedures and criteria
- Peer review training material
- Peer review data
- Verification reports
Identify and Involve Relevant Stakeholders: Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include:
- Selecting work products and methods for verification
- Establishing verification procedures and criteria
- Conducting peer reviews
- Assessing verification results and identifying corrective action
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Verification profile (e.g., the number of verifications planned and performed, and the defects found; perhaps categorized by verification method or type)
- Number of defects detected by defect category
- Verification problem report trends (e.g., number written and number closed)
- Verification problem report status (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting work products for verification
- Establishing and maintaining verification procedures and criteria
- Performing peer reviews
- Verifying selected work products
Examples of work products reviewed include:
- Verification procedures and criteria
- Peer review checklists
- Verification reports
Review Status with Higher Level Management: Review the activities, status, and results of the verification process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined verification process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the verification process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the verification process that address quality and process performance based on customer needs and business objectives.
Stabilize Sub-process Performance: Stabilize the performance of one or more sub-processes to determine the ability of the verification process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the verification process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the verification process.

VAL: Validation

Purpose

To demonstrate that a product or product component fulfills its intended use when placed in its intended environment. [

Validation activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to work products as well as to the product and product components. The work products (e.g., requirements, designs, prototypes) should be selected on the basis of which are the best predictors of how well the product and product component will satisfy user needs.

The validation environment should represent the intended environment for the product and product components as well as represent the intended environment suitable for validation activities with work products.

Validation demonstrates that the product, as provided, will fulfill its intended use; whereas, verification addresses whether the work product properly reflects the specified requirements. In other words, verification ensures that “you built it right;” whereas, validation ensures that “you built the right thing". Validation activities use approaches similar to verification (e.g., test, analysis, inspection, demonstration, or simulation). Often, the end users are involved in the validation activities. Both validation and verification activities often run concurrently and may use portions of the same environment.

Where possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment may be used or only part of it. However, validation issues can be discovered early in the life of the project using work products.

When validation issues are identified, they are referred to the processes associated with the Requirements Development, Technical Solution, or Project Monitoring and Control process areas for resolution.

The specific practices of this process area build on each other in the following way. The Select Products for Validation specific practice enables the identification of the product or product component to be validated and the methods to be used to perform the validation. The Establish the Validation Environment specific practice enables the determination of the environment that will be used to carry out the validation. The Establish Validation Procedures and Criteria specific practice enables the development of validation procedures and criteria that are aligned with the characteristics of selected products, customer constraints on validation, methods, and the validation environment. The Perform Validation specific practice enables the performance of validation according to the methods, procedures, and criteria.

Specific Goals

Goal	Supporting Practices	Sub Practices
VAL-1: Prepare for Validation Preparation for validation is conducted. Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria. The items selected for validation may include only the product or it may include appropriate levels of the product components that are used to build the product. Any product or product component may be subject to validation, including replacement, maintenance, and training products, to name a few. The environment required to validate the product or product component is prepared. The environment may be purchased or may be specified, designed, and built. The environments used for product integration and verification may be considered in collaboration with the validation environment to reduce cost and improve efficiency or productivity.	Select Products for Validation	[SP]
	Establish the Validation Environment	[SP]
	Establish Validation Procedures and Criteria	[SP]
VAL-2: Validate Product or Product Components The product or product components are validated to ensure that they are suitable for use in their intended operating environment. The validation methods, procedures, and criteria are used to validate the selected products and product components and any associated maintenance, training, and support services using the appropriate validation environment.	Perform Validation	[SP]
	Analyze Validation Results	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for selecting products and product components for validation; for selecting validation methods; and for establishing and maintaining validation procedures, criteria, and environments that ensure the products and product components satisfy user needs in their intended operating environment.
Plan the Process: Typically, this plan for performing the validation process is included in (or referenced by) the project plan, which is described in the Project Planning process area.
Provide Resources: Special facilities may be required for validating the product or product components. When necessary, the facilities required for validation are developed or purchased.Examples of other resources provided include:
- Test management tools
- Test-case generators
- Test-coverage analyzers
- Simulators
- Load, stress, and performance tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the validation process.
Train People: Examples of training topics include:
- Application domain
- Validation principles, standards, and methods
- Intended-use environment
Manage Configurations: Examples of work products placed under configuration management include:
- Lists of products and product components selected for validation
- Validation methods, procedures, and criteria
- Validation reports
Identify and Involve Relevant Stakeholders: Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include:
- Selecting the products and product components to be validated
- Establishing the validation methods, procedures, and criteria
- Reviewing results of product and product-component validation and resolving issues
- Resolving issues with the customers or end users
Issues with the customers or end users are resolved particularly when there are significant deviations from their baseline needs for:
- Waivers on the contract or agreement (what, when, and for which products, services, or manufactured products)
- Additional in-depth studies, trials, tests, or evaluations
- Possible changes in the contracts or agreements
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Number of validation activities completed (planned versus actual)
- Validation problem report trends (e.g., number written and number closed)
- Validation problem report aging (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting the products and product components to be validated
- Establishing and maintaining validation methods, procedures, and criteria
- Validating products or product components
Examples of work products reviewed include:
- Validation methods, procedures, and criteria
Review Status with Higher Level Management: Review the activities, status, and results of the validation process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined validation process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the validation process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the validation process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the validation process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement:Ensure continuous improvement of the validation process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the validation process.

OPF: Organizational Process Focus

Purpose

To plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the processes and process assets.

The organization's processes include the organization's set of standard processes and the defined processes that are tailored from them. The organizational process assets are used to establish, maintain, implement, and improve the defined processes.

Candidate improvements to the organizational process assets are obtained from various sources, including measurement of the processes, lessons learned in implementing the processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations' processes, and recommendations from other improvement initiatives in the organization.

Process improvement occurs within the context of the organization’s needs and is used to address the organization's objectives. The organization encourages participation in process-improvement activities by those who will perform the process. The responsibility for facilitating and managing the organization's process-improvement activities, including coordinating the participation of others, is typically assigned to a process group. The organization provides the long-term commitment and resources required to sponsor this group.

Careful planning is required to ensure that process-improvement efforts across the organization are adequately managed and implemented. The planning for process-improvement results in a process-improvement plan. The process-improvement plan will address appraisal planning, process action planning, pilot planning, and deployment planning. Appraisal plans describe the appraisal timeline and schedule, the scope of the appraisal, the resources required to perform the appraisal, the reference model against which the appraisal will be performed, and the logistics for the appraisal. Process action plans usually result from appraisals and document how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented. In cases in which it is determined that the improvement described in the process action plan should be tested on a small group before deploying it across the organization, a pilot plan is generated. Finally, when the improvement is to be deployed, a deployment plan is used. This plan describes when and how the improvement will be deployed across the organization.

Specific Goals

Goal	Supporting Practices	Sub Practices
OPF-1: Determine Process-Improvement Opportunities Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.	Establish and maintain the description of the process needs and objectives for the organization.	[SP]
	Appraise the processes of the organization periodically and as needed to maintain an understanding of their strengths and weaknesses.	[SP]
	Identify improvements to the organization's processes and process assets.	[SP]
OPF-2: Plan and Implement Process-Improvement Activities Improvements are planned and implemented, organizational process assets are deployed, and process-related experiences are incorporated into the organizational process assets. Establishing and maintaining process action plans typically involves the following roles: Management steering committees to set strategies and oversee process-improvement activities Process group staff to facilitate and manage the process-improvement activities Process action teams to define and implement the improvement Process owners to manage the deployment Practitioners to perform the process This involvement helps to obtain buy-in on the process improvements and increases the likelihood of effective deployment.	Establish process action plans to address improvements to the organization's processes and process assets.	[SP]
	Implement process action plans across the organization. assets.	[SP]
	Deploy organizational process assets across the organization. ^[Note]	[SP]
	Incorporate process-related work products, measures, and improvement information derived from planning and performing the process into the organizational process assets. ^[Note]	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for determining process-improvement opportunities for the processes being used and for planning and implementing process-improvement activities across the organization.
Plan the Process: The plan for performing the organizational process focus process, which is often called “the process-improvement plan,” differs from the process action plans described in specific practices in this process area. The plan called for in this generic practice addresses the comprehensive planning for all of the specific practices in this process area, from the establishment of organizational process needs all the way through to the incorporation of process-related experiences into the organizational process assets.
Provide Resources: Examples of resources provided include:
- Database management systems
- Process-improvement tools
- Web page builders and browsers
- Groupware
- Quality-improvement tools (e.g., quality-improvement tools, cause-and-effect diagrams, affinity diagrams, Pareto charts)
Assign Responsibility: Two groups are typically established and assigned responsibility for process improvement: (1) a management steering committee for process improvement to provide senior-management sponsorship; and (2) a process group to facilitate and manage the process-improvement activities.
Train People: Examples of training topics include:
- CMMI and other process and process-improvement reference models
- Planning and managing process improvement
- Tools, methods, and analysis techniques
- Process modeling
- Facilitation techniques
- Change management
Manage Configurations: Examples of work products placed under configuration management include :
- Process-improvement proposals
- Organization’s approved process action plans
- Training materials for deploying organizational process assets
- Plans for the organization’s process appraisals
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Coordinating and collaborating on process-improvement activities with process owners, those that are or will be performing the process, and support organizations (e.g., training staff and quality assurance representatives)
- Establishing the organizational process needs and objectives
- Appraising the organization’s processes
- Implementing process action plans
- Coordinating and collaborating on the execution of pilots to test selected improvements
- Deploying organizational process assets and changes to organizational process assets
- Communicating the plans, status, activities, and results related to the implementation of process-improvement activities
Monitor and Control the Process: Examples of measures used in monitoring and controlling include :
- Number of process-improvement proposals submitted, accepted, or implemented
- CMMI maturity level or capability level
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Determining process-improvement opportunities
- Planning and coordinating process-improvement activities
Examples of work products reviewed include:
- Process-improvement plans
- Process action plans
- Plans for the organization’s process appraisals
Review Status with Higher Level Management: These reviews are typically in the form of a briefing presented to the management steering committee by the process group and the process action teams. Examples of presentation topics include:
- Status of improvements being developed by process action teams
- Results of pilots
- Results of deployments
- Schedule status for achieving significant milestones (e.g., readiness for an appraisal, or progress towards achieving a targeted organizational maturity level or capability level profile)

Defined

Establish Defined Process: Establish and maintain the description of a defined organizational process focus process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process focus process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

None

Optimizing

None

OPD: Organizational Process Definition

Purpose

To establish and maintain a usable set of organizational process assets.

Organizational process assets enable consistent process performance across the organization and provide a basis for cumulative, long-term benefits to the organization.

The organization's process asset library is a collection of items maintained by the organization for use by the people and projects of the organization. This collection of items includes descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. The process asset library supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.

The organization's set of standard processes is tailored by projects to create their defined processes. The other organizational process assets are used to support tailoring as well as the implementation of the defined processes.

A standard process is composed of other processes or process elements. A process element is the fundamental (e.g., atomic) unit of process definition and describes the activities and tasks to consistently perform work. Process architecture provides rules for connecting the process elements of a standard process. The organization's set of standard processes may include multiple process architectures.

Specific Goals

Goal	Supporting Practices	Sub Practices
OPD-1: Establish Organizational Process Assets A set of organizational process assets is established and maintained. Standard processes may be defined at multiple levels in an enterprise and they may be related in a hierarchical manner. For example, an enterprise may have a set of standard processes that is tailored by individual organizations (e.g., a division or site) in the enterprise to establish their set of standard processes. The set of standard processes may also be tailored for each business areas or product lines. Thus “the organization's set of standard processes” can refer to the standard processes established at the organization level and standard processes that may be established at lower levels ^[Note]. Multiple standard processes may be needed to address the needs of different application domains, life-cycle models, methodologies, and tools. The set of standard processes contains process elements (e.g., a work product size-estimating element) that may be interconnected according to one or more process architectures that describe the relationships among these process elements. Processes may be composed of other processes or process elements.	Establish and maintain a set of standard processes.	[SP]
	Establish and maintain descriptions of approved life-cycle models. ^[Note]	[SP]
	Establish and maintain tailoring criteria and guidelines for the set of standard processes.	[SP] [Tailoring Criteria]
	Establish and maintain the measurement repository. ^[Note].	[SP]
	Establish and maintain the process asset library. ^[Note].	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: Establish and maintain an organizational policy for planning and performing the organizational process definition process. This policy establishes organizational expectations for establishing and maintaining a set of standard processes for use by the organization and making organizational process assets available across the organization.
Plan the Process: Typically, this plan for performing the organizational process definition process is a part of the process-improvement plan.
Provide Resources: A process group typically manages the organizational process definition activities. This group is typically staffed by a core of professionals whose primary responsibility is coordinating organizational process improvement. This group is supported by process owners and people with expertise in various disciplines such as:
- Project management
- The appropriate engineering disciplines
- Configuration management
- Quality assurance
Examples of other resources provided include:
- Database management systems
- Process modeling tools
- Web page builders and browsers
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational process definition process.
Train People: Examples of training topics include:
- CMMI and other process and process-improvement reference models
- Planning, managing, and monitoring processes
- Process modeling and definition
- Developing a tailorable standard process
Manage Configurations: Examples of work products placed under configuration management include:
- set of standard processes
- Descriptions of the life-cycle models
- Tailoring guidelines for the set of standard processes
- Definitions of the common set of product and process measures
- measurement data
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Reviewing the set of standard processes
- Reviewing life-cycle models
- Resolving issues on the tailoring guidelines
- Assessing the definitions of the common set of process and product measures
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Percentage of projects using the process architectures and process elements of the set of standard processes
- Defect density of each process element of the set of standard processes
Objectively Evaluate Adherence: Examples of activities reviewed include Establishing organizational process assets. Examples of work products reviewed include:
- set of standard processes
- Descriptions of the life-cycle models
- Tailoring guidelines for the set of standard processes
- measurement data
Review Status with Higher Level Management: Review the activities, status, and results of the organizational process definition process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined organizational process definition process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process definition process to support the future use and improvement of the processes and process assets.

Quantitatively Managed

None

Optimizing

None

OT: Organizational Training

Purpose

To establish and to develop the skills and knowledge of people so they can perform their roles effectively and efficiently.

Organizational Training includes training to support the strategic business objectives and to meet the tactical training needs that are common across projects and support groups. Specific training needs identified by individual projects and support groups are handled at the project and support group level and are outside the scope of Organizational Training^[Note].

An organizational training program involves:

Identifying the training needed by the organization
Obtaining and providing training to address those needs
Establishing and maintaining training capability
Establishing and maintaining training records
Assessing training effectiveness

The identification of process training needs is primarily based on the skills that are required to perform the organization's set of standard processes. These skills and knowledge may be:

Technical skills pertain to the ability to use the equipment, tools, materials, data, and processes required by a project or process.
Organizational skills pertain to behavior within and according to the employee's organization structure, role and responsibilities, and general operating principles and methods. ^[Note]
Contextual skills are the self-management, communication, and interpersonal abilities needed to successfully perform in the organizational and social context of the project and support groups.

Effective training requires assessment of needs, planning, instructional design, and appropriate training media (e.g., workbooks, computer software), as well as a repository of training process data. As an organizational process, the main components of training include a managed training-development program, documented plans, personnel with appropriate mastery of specific disciplines and other areas of knowledge, and mechanisms for measuring the effectiveness of the training program.

Certain skills may be effectively and efficiently imparted through vehicles other than in-class training experiences (e.g., informal mentoring). Other skills require more formalized training vehicles, such as in a classroom, by Web-based training, through guided self study, or via a formalized on-the-job training program. The formal or informal training vehicles employed for each situation should be based on an assessment of the need for training and the performance gap to be addressed. The term “training” used throughout this process area is used broadly to include all of these learning options.

Success in training can be measured in terms of the availability of opportunities to acquire the skills and knowledge needed to perform new and ongoing enterprise activities.

Specific Goals

Goal	Supporting Practices	Sub Practices
OT-1: Establish an Organizational Training Capability The organization identifies the training required to develop the skills and knowledge necessary to perform enterprise activities. Once the needs are identified, a training program addressing those needs is developed.	Establish and maintain the strategic training needs of the organization. ^[Note]	[SP]
	Determine which training needs are the responsibility of the organization and which will be left to the individual project or support group.	[SP]
	Establish and maintain an organizational training tactical plan.	[SP]
	Establish and maintain training capability to address organizational training needs.	[SP]
OT-2: Provide Necessary Training Training necessary for individuals to perform their roles effectively is provided. In selecting people to be trained consider: Background of the target population of training participants Prerequisite background to receive training Skills and abilities needed by people to perform their roles Need for cross-discipline technical-management training for all disciplines, including project management Need for managers to have training in appropriate organizational processes Need for training in the basic principles of discipline-specific engineering to support personnel in quality management, configuration management, and other related support functions Need to provide competency development for critical functional areas	Deliver the training following the training tactical plan.	[SP]
	Establish and maintain records of the organizational training.	[SP]
	Assess the effectiveness of the training program.	[SP]

Institutionalizing as a Defined Process

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for determining process-improvement opportunities for the processes being used and for planning and implementing process-improvement activities across the organization.
Plan the Process:
Provide Resources:
Assign Responsibility:
Train People:
Manage Configurations:
Identify and Involve Relevant Stakeholders:
Monitor and Control the Process:
Objectively Evaluate Adherence:
Review Status with Higher Level Management:

Defined

Establish Defined Process: Establish and maintain the description of a defined organizational training process.
Collect Improvement Information:

Quantitatively Managed

Establish and maintain quantitative objectives for the organizational training process that address quality and process performance based on customer needs and business objectives.
Stabilize the performance of one or more sub-processes to determine the ability of the organizational training process to achieve the established quantitative quality and process performance objectives.

Optimizing

Ensure continuous improvement of the organizational training process in fulfilling the relevant business objectives of the organization.
Identify and correct the root causes of defects and other problems in the organizational training process.

IPM: Integrated Project Management for IPPD

Purpose

To establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes.

For Integrated Product and Process Development, Integrated Project Management also covers the establishment of a shared vision for the project and a team structure for integrated teams that will carry out the objectives of the project.

Integrated Project Management involves:

Establishing the project's defined process by tailoring the organization's set of standard processes
Managing the project using the project’s defined process
Using and contributing to the organizational process assets
Enabling relevant stakeholders’ concerns to be identified, considered, and, when appropriate, addressed during the development of the product
Ensuring that the relevant stakeholders perform their tasks in a coordinated and timely manner (1) to address product and product component requirements, plans, objectives, issues, and risks; (2) to fulfill their commitments; and (3) to identify, track, and resolve issues

The integrated and defined process that is tailored from the set of standard processes is called the project’s defined process.

Managing the project’s effort, cost, schedule, staffing, risks, and other factors is tied to the tasks of the project's defined process. The implementation and management of the project's defined process are typically described in the project plan. Certain activities may be covered in other plans that affect the project, such as the quality assurance plan, risk management strategy, and the configuration management plan.

Since the defined process for each project is tailored from the organization's set of standard processes, variability among projects is typically reduced and projects can more easily share process assets, data, and lessons learned.

This process area also addresses the coordination of all activities associated with the project including:

Technical activities such as requirements development, design, and verification
Support activities such as configuration management, documentation, marketing, and training

The working interfaces and interactions among relevant stakeholders internal and external to the project are planned and managed to ensure the quality and integrity of the entire product. Relevant stakeholders participate, as appropriate, in defining the project’s defined process and the project plan. Reviews and exchanges are regularly conducted with the relevant stakeholders and coordination issues receive appropriate attention. Reviews and exchanges are regularly conducted with the relevant stakeholders to ensure that coordination issues receive appropriate attention and everyone involved with the project is appropriately aware of the status, plans, and activities. In defining the project’s defined process, formal interfaces are created as necessary to ensure that appropriate coordination and collaboration occurs.

This process area applies in any organizational structure, including projects that are structured as line organizations, matrix organizations, or integrated teams. Terminology should be interpreted for the organizational structure in place.

Specific Goals

Goal	Supporting Practices	Sub Practices
IPM-1: Use the Project’s Defined Process The project is conducted using a defined process that is tailored from the organization's set of standard processes. The project's defined process must include those processes from the organization's set of standard processes that address all processes necessary to develop and maintain the product. The product-related life-cycle processes, such as the manufacturing and support processes, are developed concurrently with the product.	Establish the Project’s Defined Process	[SP]
	Use Organizational Process Assets for Planning Project Activities	[SP]
	Integrate Plans	[SP]
	Manage the Project Using the Integrated Plans	[SP]
	Contribute to the Organizational Process Assets	[SP]
IPM-2: Coordinate and Collaborate with Relevant Stakeholders Coordination and collaboration of the project with relevant stakeholders is conducted.	Manage Stakeholder Involvement	[SP]
	Manage Dependencies	[SP]
	Resolve Coordination Issues	[SP]
IPM-3: Use the Project's Shared Vision for IPPD The project is conducted using the project’s shared vision. Creating a shared vision requires that all people in the project have an opportunity to speak and be heard about what really matters to them. The project’s shared vision captures the project’s guiding principles, including mission, objectives, expected behavior, and values. The project’s guiding principles should be consistent with those of the organization. The implementation of the project’s shared vision in work can become part of the project’s process for doing that work. As a result, it is subject to the same requirements for measurement, review, and corrective action as other processes. The value of a shared vision is that people understand and can adopt its principles to guide their actions and decisions. Shared visions tend to focus on an end state while leaving room for personal and team innovation, creativity, and enthusiasm. The activities of the individuals, teams, and project are aligned with the shared vision (i.e., the activities contribute to the achievement of the objectives expressed in the shared vision).	Define Project’s Shared-Vision Context	[SP]
	Establish the Project’s Shared Vision	[SP]
IPM-4: Organize Integrated Teams for IPPD The integrated teams needed to execute the project are identified, defined, structured, and tasked. The integrated team structure partitions responsibilities, requirements, and resources to teams so that the right expertise and abilities are available to produce the assigned products. The integrated teams are organized to facilitate communications between teams and to honor interfaces between product components. Organizing integrated teams to realize IPPD requires care and deliberation. As the project evolves, integrated team structures are reevaluated for continued applicability. Teams in the structure must be appropriately integrated with each other. The interface between two integrated teams should be specified when one team has responsibility for a work product that has an interface requirement referring to a work product of the other team. An interface between teams should be specified when one team produces a work product that will be used by another. An interface should exist when two teams share responsibility for a general requirement of the product. Each of these types of interfaces between integrated teams may require a different type of collaboration as appropriate.	Determine Integrated Team Structure for the Project	[SP]
	Develop a Preliminary Distribution of Requirements to Integrated Teams	[SP]
	Establish Integrated Teams	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for using the project's defined process and coordinating and collaborating with relevant stakeholders.
Plan the Process: Typically, this plan for performing the integrated project management process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Examples of resources provided include the following tools:
- Problem-tracking and trouble-reporting packages
- Groupware
- Video conferencing
- Integrated decision database
- Integrated product support environments
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the integrated project management process.
Train People: Examples of training topics include:
- Tailoring the organization’s set of standard processes to meet the needs of the project
- Procedures for managing the project based on the project’s defined process
- Using the organization’s measurement repository
- Using the organizational process assets
- Integrated management
- Intergroup coordination
- Group problem solving
Manage Configurations: Examples of work products placed under configuration management include:
- The project’s defined process
- Project plans
- Other plans that affect the project
- Integrated plans
- Actual process and product measures collected from the project
Identify and Involve Relevant Stakeholders: EThis generic practice is different from managing stakeholder involvement for the project, which is covered by specific practices within this process area. Examples of activities for stakeholder involvement include:
- Resolving issues about the tailoring of the organizational process assets
- Resolving issues among the project plan and the other plans that affect the project
- Reviewing project performance to align with current and projected needs, objectives, and requirements
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Number of changes to the project's defined process
- Schedule and effort to tailor the organization’s set of standard processes
- Interface coordination issue trends (i.e., number identified and number closed)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Establishing, maintaining, and using the project’s defined process
- Coordinating and collaborating with relevant stakeholders
Review Status with Higher Level Management: Review the activities, status, and results of the integrated project management process with higher level management and resolve issues.

Defined

Establish Defined Process: This generic practice is different from the Establish the Project’s Defined Process specific practice in this process area. This generic practice establishes and maintains a defined integrated project management process. The Establish the Project’s Defined Process specific practice defines the project’s defined process, which includes all processes that affect the project.
Collect Improvement Information: This generic practice is different from the Contribute to the Organizational Process Assets specific practice in this process area. This generic practice collects improvement information about the integrated project management processes. The Contribute to the Organizational Process Assets specific practice collects information from processes in the project’s defined process.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the integrated project management process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the integrated project management process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the integrated project management process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the integrated project management process.

RM: Risk Management

Purpose

To identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Risk management is a continuous, forward-looking process that is an important part of business and technical management processes. Risk management should address issues that could endanger achievement of critical objectives. A continuous risk management approach is applied to effectively anticipate and mitigate the risks that have critical impact on the project.

Effective risk management includes early and aggressive risk identification through the collaboration and involvement of relevant stakeholders, as described in the stakeholder involvement plan addressed in the Project Planning process area. Strong leadership across all relevant stakeholders is needed to establish an environment for the free and open disclosure and discussion of risk.

While technical issues are a primary concern both early on and throughout all project phases, risk management must consider both internal and external sources for cost, schedule, and technical risk. Early and aggressive detection of risk is important because it is typically easier, less costly, and less disruptive to make changes and correct work efforts during the earlier, rather than the later, phases of the project.

Risk management can be divided into three parts: defining a risk management strategy; identifying and analyzing risks; and handling identified risks, including the implementation of risk mitigation plans when needed.

As represented in the Project Planning and Project Monitoring and Control process areas, organizations may initially focus simply on risk identification for awareness, and react to the realization of these risks as they occur. The Risk Management process area describes an evolution of these specific practices to systematically plan, anticipate, and mitigate risks to proactively minimize their impact on the project.

Although the primary emphasis of the Risk Management process area is on the project, the concepts may also be applied to manage organizational risks.

Specific Goals

Goal	Supporting Practices	Sub Practices
RM-1: Prepare for Risk Management Preparation is conducted by establishing and maintaining a strategy for identifying, analyzing, and mitigating risks. This is typically documented in a risk management plan. The risk management strategy addresses the specific actions and management approach used to apply and control the risk management program. This includes identifying the sources of risk, the scheme used to categorize risks, and the parameters used to evaluate, bound, and control risks for effective handling.	Determine Risk Sources and Categories	[SP]
	Define Risk Parameters	[SP]
	Establish a Risk Management Strategy	[SP]
RM-2: Identify and Analyze Risks Risks are identified and analyzed to determine their relative importance. The degree of risk impacts the resources assigned to handle an identified risk and the determination of when appropriate management attention is required. Analyzing risks entails identifying risks from the internal and external sources identified and then evaluating each identified risk to determine its likelihood and consequences. Categorization of the risk, based on an evaluation against the established risk categories and criteria developed for the risk management strategy, provides the information needed for risk handling. Related risks may be grouped for efficient handling and effective use of risk management resources.	Identify Risks	[SP]
	Evaluate, Categorize, and Prioritize Risks	[SP]
RM-3: Mitigate Risks Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives. The steps in handling risks include developing risk-handling options, monitoring risks, and performing risk-handling activities when defined thresholds are exceeded. Risk mitigation plans are developed and implemented for selected risks to proactively reduce the potential impact of risk occurrence. This may also include contingency plans to deal with the impact of selected risks that may occur despite attempts to mitigate them. The risk parameters used to trigger risk-handling activities are defined by the risk management strategy.	Develop Risk Mitigation Plans	[SP]
	Implement Risk Mitigation Plans	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for defining a risk management strategy and identifying, analyzing, and mitigating risks.
Plan the Process: Typically, this plan for performing the risk management process is included in (or referenced by) the project plan, which is described in the Project Planning process area. The plan for performing the risk management process differs from both the risk management strategy and the risk mitigation plans described in the specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from determining risk sources and categories all the way through to the implementation of risk mitigation plans. In contrast, the risk management strategy called for in one specific practice would address the project-specific risk strategy for things such as risk sources, thresholds, tools, and techniques, and would monitor time intervals. The risk mitigation plans called for in another specific practice would address more focused items such as the levels that trigger risk-handling activities.
Provide Resources: Examples of resources provided include:
- Risk management databases
- Risk mitigation tools
- Prototyping tools
- Modeling and simulation
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the risk management process.
Train People: Examples of training topics include:
- Risk management concepts and activities (e.g., risk identification, evaluation, monitoring, mitigation)
- Measure selection for risk mitigation
Manage Configurations: Examples of work products placed under configuration management include:
- Risk management strategy
- Identified risk items
- Risk mitigation plans
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Establishing a collaborative environment for free and open discussion of risk
- Reviewing the risk management strategy and risk mitigation plans
- Participating in risk identification, analysis, and mitigation activities
- Communicating and reporting risk management status
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Number of risks identified, managed, tracked, and controlled
- Risk exposure and changes to the risk exposure for each assessed risk, and as a summary percentage of management reserve
- Change activity for the risk mitigation plans (e.g., processes, schedule, funding)
- Occurrence of unanticipated risks
- Risk categorization volatility
- Comparison of estimated vs. actual risk mitigation effort and impact
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Establishing and maintaining a risk management strategy
- Identifying and analyzing risks
- Mitigating risks
Examples of work products reviewed include:
- Risk management strategy
- Risk mitigation plans
Review Status with Higher Level Management: Reviews of the project risk status are held on a periodic and eventdriven basis with appropriate levels of management, to provide visibility into the potential for project risk exposure and appropriate corrective action. Typically, these reviews will include a summary of the most critical risks, key risk parameters (such as likelihood and consequence of these risks), and the status of risk mitigation efforts.

Defined

Establish Defined Process: Establish and maintain the description of a defined risk management process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the risk management process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process:Establish and maintain quantitative objectives for the risk management process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the risk management process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the risk management process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the risk management process.

IT: Integrated Teaming

Purpose

To form and sustain an integrated team for the development of work products.

Integrated team members:

provide the needed skills and expertise to accomplish the team’s tasks
provide the advocacy and representation necessary to address all essential phases of the product’s life cycle
collaborate internally and externally with other teams and relevant stakeholders as appropriate
share a common understanding of the team’s tasks and objectives
conduct themselves in accordance with established operating principles and ground rules

An integrated team (also known as an “Integrated Product Team” or IPT) is composed of relevant stakeholders who generate and implement decisions for the work product being developed. The members of the integrated team are collectively responsible for delivering the work product.

The integrated team receives its assignment from its sponsor. The sponsor of an integrated team is a person or a group (e.g., project manager or even another integrated team) who can assign work tasks and provide resources.

The following characteristics distinguish an integrated team in an Integrated Product and Process Development (IPPD) environment from other forms of specialty work or task groups:

Team members include empowered representatives from both technical and business functional organizations involved with the product. Within defined boundaries, these representatives have decision-making authority and the responsibility to act for their respective organizations.
Team members may include customers, suppliers, and other stakeholders outside of the organization as appropriate to the product being developed.
An integrated team consists of people skilled in the functions that need to be performed to develop required work products. Some of them may represent a functional organization. These people have a dual responsibility to focus on the product while maintaining their connections with the functional organization that can assist the development with additional expertise and advice.
An integrated team focuses on the product life cycle to the extent required by the project. Team members share and integrate considerations, expectations, and requirements of the product lifecycle phases.
An integrated team understands its role in the structure of teams for the overall project.

Clearly defined and commonly understood objectives, tasks, responsibilities, authority, and context (of vertical and horizontal interfaces) provide a strong basis for implementing integrated teams.

Specific Goals

Goal	Supporting Practices	Sub Practices
IT-1: Establish Team Composition A team composition that provides the knowledge and skills required to deliver the team’s product is established and maintained. One of the main attributes of an integrated team is to be self managed and empowered. Team membership is intended to be composed of people who can plan, execute, and implement decisions for all phases of the life cycle of the work product being acquired or developed. Team member selection and skill mix should be based on the assigned work product and the objectives that are important to the different phases of that product’s life cycle. Integrated teams should be cross functional and involve relevant stakeholders.	Identify Team Tasks	[SP]
	Identify Needed Knowledge and Skills	[SP]
	Assign Appropriate Team Members	[SP]
IT-2: Govern Team Operation Operation of the integrated team is governed according to established principles. An integrated team operates in a disciplined way that brings about effectiveness and productivity in meeting its objectives. Established operating principles help both the team leader and team members to manage group dynamics and to ensure successful interplay among the multiple functions within the team.	Establish a Shared Vision	[SP]
	Establish a Team Charter	[SP]
	Define Roles and Responsibilities	[SP]
	Establish Operating Procedures	[SP]
	Collaborate among Interfacing Teams	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for establishing and maintaining team composition and governing team operation.
Plan the Process: Typically, this plan for performing the integrated teaming process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Examples of special equipment and facilities include:
- Team war rooms (for regular strategy development and communication meetings)
Examples of other resources provided include:
- Interactive electronic communication and data presentation tools (groupware)
- Team-building tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the integrated teaming process.
Train People: Examples of training topics include:
- Use of integrated work environments
- Interpersonal skills
- Communication skills
- Team building
- Collaborative problem solving and decision making
Manage Configurations: Examples of work products placed under configuration management include:
- List of team members
- List of the level of effort and resources, including access to staff, to perform each team function
- Work task formal commitment lists
- Team shared-vision statement
- Team charter
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
Monitor and Control the Process: Examples of measures used in monitoring and controlling:
- Performance according to plans, commitments, and procedures for the integrated team, and deviations from expectations
- Ability to achieve team objectives
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Defined roles and responsibilities
- Communication activities within and among integrated teams
Examples of work products reviewed include:
- Descriptions of roles and responsibilities
- Descriptions of product ownership boundaries and team interfaces
Review Status with Higher Level Management: Review the activities, status, and results of the integrated teaming process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined integrated teaming process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the integrated teaming process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the integrated teaming process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the integrated teaming process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the integrated teaming process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the integrated teaming process.

ISM: Integrated Supplier Management

Purpose

To proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship.

Integrated Supplier Management involves monitoring the new products available on the market, evaluating sources of products that might help satisfy project requirements, and using this information to select suppliers. Integrated Supplier Management also involves maintaining a cooperative project-supplier relationship, monitoring selected supplier processes, evaluating selected work products, and making appropriate adjustments in the supplier relationship and agreement.

Integrated Supplier Management involves the following activities:

Identifying, analyzing, and selecting potential sources of products
Evaluating and determining the sources to be used for acquiring products
Monitoring and analyzing selected supplier processes
Evaluating selected supplier work products
Revising the supplier agreement or relationship as appropriate

The Integrated Supplier Management process area builds on the concepts established in the Supplier Agreement Management process area by adding practices that emphasize a cooperative relationship with suppliers. Integrated Supplier Management is designed for situations in which projects use suppliers to perform functions that are critical to the success of the project. Analyzing sources and monitoring selected supplier processes and work products before delivery of the product to the project are two such functions described in this process area.

The practices in Supplier Agreement Management, such as Select Suppliers, Establish Supplier Agreements, and Execute the Supplier Agreement, are critically tied to Integrated Supplier Management. Appropriate references are provided in both process areas to emphasize these relationships.

Integrated Supplier Management emphasizes relationships with suppliers that are collaborative and coordinated. Projects evaluate the supplier’s performance and the quality of the work products for compliance with the requirements in the supplier agreement. Integrated Supplier Management is not required for projects using off-the-shelf items that are generally available and that are not modified in any way. There, the use of Supplier Agreement Management is sufficient.

The term “source” refers to a potential supplier or suppliers before selection.

The supplier agreement establishes the mechanism to allow the project to oversee supplier processes and work products and to evaluate any products being acquired. It also provides the vehicle for mutual understanding between the project and the supplier.

The specific practices of this process area can be implemented either within each project, by a separate group in the organization that supports multiple projects (e.g., contract management), or some combination of the two.

Specific Goals

Goal	Supporting Practices	Sub Practices
ISM-1: Analyze and Select Sources of Products Potential sources of products that best fit the needs of the project are identified, analyzed, and selected. The specific practices associated with this specific goal enhance the approach to selecting suppliers described in the Supplier Agreement Management process area by proactively identifying potential sources of products that satisfy the project’s requirements and by using this information when selecting suppliers. The specific practices associated with this specific goal augment those that help achieve the Establish Supplier Agreements specific goal of the Supplier Agreement Management process area and contribute to making the supplier selection decisions described in that process area.	Analyze Potential Sources of Products	[SP]
	Evaluate and Determine Sources of Products	[SP]
ISM-2: Coordinate Work with Suppliers Work is coordinated with suppliers to ensure the supplier agreement is executed appropriately. The relationship that exists among the project, supplier, customer, and end user requires special emphasis. Achieving project success increasingly demands closely aligned, if not integrated, processes across organizational boundaries. The specific practices associated with this specific goal augment those that help achieve the Satisfy Supplier Agreements specific goal of the Supplier Agreement Management process area.	Monitor Selected Supplier Processes	[SP]
	Evaluate Selected Supplier Work Products	[SP]
	Revise the Supplier Agreement or Relationship	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for identifying, analyzing, and selecting suppliers; and for monitoring supplier processes, work products, and performance. This policy also establishes organizational expectations for analyzing and managing risks relevant to potential sources and the projectsupplier relationship.
Plan the Process: Typically, this plan for performing the integrated supplier management process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Special expertise may be required including:
- Ability to evaluate potential sources and select suppliers
- Knowledge of supplier management, including appraising a supplier's planning documents, processes, work products, and services
- Knowledge of risk management
- Knowledge of the domain of the product being acquired
- Knowledge of current engineering processes, work products, verification methods, technology, costing methodologies, and tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the integrated supplier management process.
Train People: Examples of training topics include:
- Identifying potential sources for candidate products to be acquired
- Acquisition feasibility and product life-cycle costs analysis
- Evaluating supplier work products
- Monitoring supplier processes
Manage Configurations: Examples of work products placed under configuration management include:
- Results of the acquisition feasibility and product life-cycle costs analysis
- Supplier agreements
- Discrepancy reports
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Resolving issues about the improvements to supplier agreements
- Resolving issues about the meaning of the requirements to be fulfilled by the supplied products
- Resolving issues about the reporting of performance data and handling of discrepancies
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Effort expended to manage the evaluation of sources and selection of suppliers
- Number of changes to the requirements in the supplier agreement
- Number of documented commitments between the project and the supplier
- Interface coordination issue trends (i.e., number identified and number closed)
- Quality measures of the supplied products
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Managing the evaluation of sources and selection of suppliers according to the project’s defined process
- Collecting data and providing appropriate data to the organization’s measurement repository
- Using the organization’s measurement repository to support management activities
- Ensuring that appropriate project subgroups participate in technical activities
- Identifying, negotiating, and tracking critical dependencies and commitments among the functions involved with the integrated supplier management process
- Handling agreement-coordination issues
Review Status with Higher Level Management: Review the activities, status, and results of the integrated supplier management process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined integrated supplier management process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the integrated supplier management process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the integrated supplier management process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the integrated supplier management process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the supplier agreement management process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the supplier agreement management process.

DAR: Decision Analysis & Resolution

Purpose

To analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

The Decision Analysis and Resolution process area involves establishing guidelines to determine which issues should be subjected to a formal evaluation process and then applying formal evaluation processes to these issues.

A formal evaluation process is a structured approach to evaluating alternative solutions against established criteria to determine a recommended solution to address an issue. A formal evaluation process involves the following:

Establishing the criteria for evaluating alternatives
Identifying alternative solutions
Selecting methods for evaluating alternatives
Evaluating the alternative solutions using the established criteria and methods
Selecting recommended solutions from the alternatives based on the evaluation criteria

A formal evaluation process reduces the subjective nature of the decision and has a higher probability of selecting a solution that meets the multiple demands of the relevant stakeholders.

While the primary application of this process area is for selected technical concerns, formal evaluation processes can also be applied to many nontechnical issues, particularly when a project is being planned. Issues that have multiple alternative solutions and evaluation criteria lend themselves to a formal evaluation process.

During planning, specific issues requiring a formal evaluation process are identified. Typical issues include selection among architectural or design alternatives, use of reusable or commercial off-the-shelf (COTS) components, supplier selection, engineering support environments or associated tools, test environments, and logistics and production. A formal evaluation process can also be used to address a make-or-buy decision, the development of manufacturing processes, the selection of distribution locations, and other decisions.

Guidelines are created for deciding when to use formal evaluation processes to address unplanned issues. Guidelines often suggest using formal evaluation processes when issues are associated with medium to high risks or when issues affect the ability to achieve project objectives.

Formal evaluation processes can vary in formality, type of criteria, and methods employed. Less formal decisions can be analyzed in a few hours, use only a few criteria (e.g., effectiveness and cost to implement), and result in a one- or two-page report. More formal decisions may require separate plans, months of effort, meetings to develop and approve criteria, simulations, prototypes, piloting, and extensive documentation.

Both numeric and non-numeric criteria can be used in a formal evaluation process. Numeric criteria use weights to reflect the relative importance of the criteria. Non-numeric criteria use a more subjective ranking scale (e.g., high, medium, low). More formal decisions may require a full trade study.

A formal evaluation process identifies and evaluates alternative solutions. The eventual selection of a solution may involve iterative activities of identification and evaluation. Portions of identified alternatives may be combined, emerging technologies may change alternatives, and the business situation for vendors may change during the evaluation period.

A recommended alternative is accompanied by documentation of the selected methods, criteria, alternatives, and rationale for the recommendation. The documentation is distributed to the relevant stakeholders; it provides a record of the formal evaluation process and rationale that is useful to other projects that encounter a similar issue.

Specific Goals

Goal	Supporting Practices	Sub Practices
DAR-1: Evaluate Alternatives Decisions are based on an evaluation of alternatives using established criteria. Issues requiring a formal evaluation process may be identified during any phase of a product or project life cycle. The objective should be to identify issues as early as possible to maximize the time available to resolve the issue.	Establish Guidelines for Decision Analysis	[SP]
	Establish Evaluation Criteria	[SP]
	Identify Alternative Solutions	[SP]
	Select Evaluation Methods	[SP]
	Evaluate Alternatives	[SP]
	Select Solutions	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for selectively analyzing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. The policy should also provide guidance on which decisions require a formal evaluation process.
Plan the Process: Typically, this plan for performing the decision analysis and resolution process is included in (or is referenced by) the project plan, which is described in the Project Planning process area.
Provide Resources: Examples of resources provided include :
- Simulators and modeling tools
- Prototyping tools
- Tools for conducting surveys
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the decision analysis and resolution process.
Train People: Examples of training topics include:
- Formal decision analysis
- Methods for evaluating alternative solutions against criteria
Manage Configurations: Examples of work products placed under configuration management include:
- Guidelines for when to apply a formal evaluation process
- Evaluation reports containing recommended solutions
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Establishing guidelines for which issues are subject to a formal evaluation process
- Establishing evaluation criteria
- Identifying and evaluating alternatives
- Selecting evaluation methods
- Selecting solutions
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Cost-to-benefit ratio of using formal evaluation processes
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Evaluating alternatives using established criteria and methods
Examples of work products reviewed include:
- Guidelines for when to apply a formal evaluation process
- Evaluation reports containing recommended solutions
Review Status with Higher Level Management: Review the activities, status, and results of the decision analysis and resolution process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined decision analysis and resolution process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the decision analysis and resolution process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the decision analysis and resolution process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the decision analysis and resolution process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the decision analysis and resolution process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the decision analysis and resolution process.

OEI: Organizational Environment for Integration

Purpose

To provide an Integrated Product and Process Development (IPPD) infrastructure and manage people for integration.

Successful integration of business and technical elements in projects is dependent upon substantive and proactive organizational processes and guidelines. The organization is an integrated system capable of providing and sustaining the people, products, and processes necessary for the effective and efficient execution of its projects. The organization must raise performance expectations from all projects while providing mechanisms that stimulate both team and individual excellence.

Important characteristics of effective environments for integration include people trained to exploit the collaborative environment; a workplace that provides resources to maximize the productivity of people and facilitate integrated teams; and organization’s set of standard processes and organizational process assets that culturally enable an IPPD environment that promotes and rewards team as well as individual excellence.

Specific Goals

Goal	Supporting Practices	Sub Practices
OEI-1: Provide IPPD Infrastructure An infrastructure that maximizes the productivity of people and affects the collaboration necessary for integration is provided. An organizational infrastructure that supports and promotes IPPD concepts is critical if IPPD is to be successfully sustained over the long term. An IPPD infrastructure includes: An organization's shared vision that promotes IPPD concepts such as concurrent development and integrated teaming A work environment that enables efficient and effective collaboration and integration People trained to collaborate, integrate, and lead others, as necessary	Establish the Organization’s Shared Vision	[SP]
	Establish an Integrated Work Environment	[SP]
	Identify IPPD-Unique Skill Requirements	[SP]
OEI-2: Manage People for Integration People are managed to nurture the integrative and collaborative behaviors of an IPPD environment.. In an IPPD environment, special attention needs to be paid to aspects of organizational leadership and management. Nurturing integration necessitates focus on the objectives, values, and behaviors that are needed to affect integrated teamwork. The organization establishes the IPPD guidelines and processes that become part of the organization’s set of standard processes and the project’s defined process. The organization’s standard processes enable, promote, and reinforce the integrative behaviors expected from projects, integrated teams, and people. For all IPPD processes and guidelines, people are recognized not as the tools or means to the end, but as part of a mutually be In stimulating the integration needed, team-related incentives may be appropriate for people who work together. However, the value of individual excellence should not be overlooked. A balanced approach that addresses both individual performance as well as team performance would help maintain high standards of both team and individual achievement. Expectations from projects, integrated teams, and people are typically communicated in the form of policies, operating procedures, guidelines, and other organizational process assets.	Establish Leadership Mechanisms	[SP]
	Establish Incentives for Integration	[SP]
	Establish Mechanisms to Balance Team and Home Organization Responsibilities	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for providing an IPPD infrastructure and managing people for integration.
Plan the Process: This plan for performing the organizational environment for integration process may be included in or referenced by the project plan, which is described in the Project Planning process area, or it may be documented in a separate plan that describes only the plan for the organizational environment for integration process.
Provide Resources: Examples of special equipment and facilities include:
- Manufacturing and production facilities
- Prototyping or production equipment
- Work space
- Office equipment and supplies
- Raw or stock input materials
- Transportation resources
- “Hotlines” and “help desks”
- Information brokerage services
- Support staff and/or services
Examples of other tool resources provided include:
- Communications systems, tools, and resources
- Computing resources and software productivity tools
- Engineering or simulation tools
- Proprietary engineering tools
- Information-technology capabilities
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational environment for integration process.
Train People: Examples of training topics include:
- Work environment development
- Ergonomics
- Leadership policies for IPPD
- Managing people for integration and collaboration
Manage Configurations: Examples of work products placed under configuration management include:
- Organizational guidelines that determine the degree of empowerment of individuals and integrated teams
- Organizational process documentation for issue resolution
- Organization’s shared vision
Identify and Involve Relevant Stakeholders: Examples of activities for stakeholder involvement include:
- Establishing and maintaining the organization’s shared vision
- Establishing and maintaining the integrated work environment
- Establishing IPPD skill needs
- Establishing and maintaining IPPD leadership mechanisms
- Establishing and maintaining organizational policies for the management of people in an IPPD environment
Monitor and Control the Process: Examples of measures used in monitoring and controlling include Parameters for key operating characteristics of the work environment.
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Establishing the shared vision for the organization
- Developing guidelines for the degree of empowerment provided to people and teams
- Establishing and maintaining an issue-resolution process
Examples of work products reviewed include:
- Organization’s shared vision
- Organizational guidelines that determine the degree of empowerment of individuals and integrated teams
- Organizational process documentation for issue resolution
- Compensation policies and procedures
Review Status with Higher Level Management: Review the activities, status, and results of the organizational environment for integration process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined organizational environment for integration process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational environment for integration process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the organizational environment for integration process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the organizational environment for integration process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the organizational environment for integration process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the organizational environment for integration process.

<——— Back: Managed Organization

Next: Quantitatively Managed ———>

CMMI - The Defined Organization

REQD: Requirements Development

Purpose

Specific Goals

REQD-1: Develop Customer Requirements

REQD-2: Develop Product Requirements

REQD-3: Analyze and Validate Requirements

Defined

Quantitatively Managed

Optimizing

TS: Technical Solution

Purpose

Specific Goals

TS-1: Select Product-Component Solutions

TS-2: Develop the Design

TS-3: Implement the Product Design

Defined

Quantitatively Managed

Optimizing

PI: Product Integration

Purpose

Specific Goals

PI-1: Prepare for Product Integration

PI-2: Ensure Interface Compatibility

PI-3: Assemble Product Components and Deliver the Product

Defined

Quantitatively Managed

Optimizing

VER: Verification

Purpose

Specific Goals

VER-1: Prepare for Verification

VER-2: Perform Peer Reviews

VER-3: Verify Selected Work Products

Defined

Quantitatively Managed

Optimizing

VAL: Validation

Purpose

Specific Goals

VAL-1: Prepare for Validation

VAL-2: Validate Product or Product Components

Defined

Quantitatively Managed

Optimizing

OPF: Organizational Process Focus

Purpose

Specific Goals

OPF-1: Determine Process-Improvement Opportunities

OPF-2: Plan and Implement Process-Improvement Activities

Defined

Quantitatively Managed

Optimizing

Purpose

Specific Goals

OPD-1: Establish Organizational Process Assets

Defined

Quantitatively Managed

Optimizing

Purpose

Specific Goals

OT-1: Establish an Organizational Training Capability

OT-2: Provide Necessary Training

Institutionalizing as a Defined Process

Defined

Quantitatively Managed

Optimizing

Purpose

Specific Goals

IPM-1: Use the Project’s Defined Process

IPM-2: Coordinate and Collaborate with Relevant Stakeholders

IPM-3: Use the Project's Shared Vision for IPPD

IPM-4: Organize Integrated Teams for IPPD

Defined

Quantitatively Managed

Optimizing

RM: Risk Management

Purpose

Specific Goals

RM-1: Prepare for Risk Management