What are different characteristics of Capability Maturity Model (CMM)?

Capability maturity model or CMM as it is often abbreviated. It is a development model developed after a prolonged study of the data collected from various organizations from all over the world.

Characteristics of Capability Maturity Model
1.The development of this model was funded by the USDD (United States department of defence).

2.The capability maturity model became the foundation for the development of software engineering institute or SEI as it is popularly known as.

3.The term “maturity” emphasises process optimization and level of formality.

4.Processes are optimized from ad-hoc practices to steps that have been formally defined.

5.Nowadays this model is being used effectively for management of result metrics.

6.Capability maturity model has proved to be great help in active optimization of the processes.

7.This model allows improvement in the development processes of an organization.

8.It is an effective and good approach towards improvement of any organization’s development processes.

9.This model is securely based upon the frame work of process maturity which was developed in 1989.

10.Initially it was used for objective assessment of the processes carried out by the contractors of the government to keep a track on the project.

11.CMM is not only used in the field of software engineering but, it is also applied to organizational processes of a business.

12.It is used in other fields like:
- Software development
- System engineering
- Software maintenance
- Project management
- System acquisition
- Risk management
- Information technology
- Human capital management and
- Services

Where is Capability Maturity Model used?

Capability maturity model is being extensively used in various organizations like in commerce, government offices, software development organizations and industry.

What was the need for Capability Maturity Model?
- In the 20th century the use of computers was wide spread.

- Computerized processes were thought to be less costly, effective and flexible way to carry out tasks.

- As more and more organizations started adopting computerized processing systems, the demand for software development eventually rose.

- As a result CMM was developed, of course with lots of failures.

- The computers were a new technology at that time and so there was a lot of pressure on developers to deliver quality products within a stipulated period of time.

- The US military was in havoc that because all their projects were running out of budget and time.

- So in order to know the reason behind all this, they funded the study at SEI. Active study started at SEI.

- It was watts Humphrey who actually came up with the actual idea of CMM.

- He based his approach on the evolution of software development practices.

- He concentrated on all the processes as one instead of concentrating on just one software development process.

- Since then the CMM has become popular among various organizations and is used as a powerful tool for improving overall performance of the business.

Though CMM proved to be a very effective tool for business but many times it caused problems in software development.

- CMM didn’t allow use of multiple software development practices. It was superseded by CMMI.

- These days still the capability maturity model is being used as the model with the capability of handling general processes when it comes to public domain.

Some Important Facts About CMM
1.CMM is still maintaining its position as a model of maturity of process.

2.CMM provides a place to start the development.

3.It uses a common language and the development is based upon a shared vision.

4.It effectively develops a frame work for actions according to their priority.

5.For an organization it defines the ways for improvement.

6.It is used an aid for better and effective understanding.

CMM has 5 aspects:
- Maturity level
- Key process area
- Goal
- Features
- Practices.

Supplier Agreement Management (SAM) Process Area in CMMi

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers. It is a Project Management process area at Maturity Level 2.
The Supplier Agreement Management process area involves the following:
- Determining the type of acquisition that will be used for the products to be acquired.
- Selecting suppliers.
- Establishing and maintaining agreements with suppliers.
- Executing the supplier agreement.
- Monitoring selected supplier processes.
- Evaluating selected supplier work products.
- Accepting delivery of acquired products.
- Transitioning acquired products to the project.

Suppliers may take many forms depending on business needs, including in-house vendors (i.e., vendors that are in the same organization but are external to the project), fabrication capabilities and laboratories, and commercial vendors. A formal agreement is established to manage the relationship between the organization and the supplier. A formal agreement is any legal agreement between the organization (representing the project) and the supplier.

Specific Practices by Goal

SG 1 Establish Supplier Agreements
Agreements with the suppliers are established and maintained.
- SP 1.1 Determine Acquisition Type.
Determine the type of acquisition for each product or product component to be acquired. There are many different types of acquisition that can be used to acquire products and product components that will be used by the project.
- SP 1.2 Select Suppliers.
Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria. Criteria should be established to address factors that are important to the project.Examples of factors include geographical location of the supplier, supplier’s performance records on similar work, engineering capabilities, staff and facilities available to perform the work and prior experience in similar applications.
- SP 1.3 Establish Supplier Agreements.
When integrated teams are formed, team membership should be negotiated with suppliers and incorporated into the agreement. The agreement should identify any integrated decision making, reporting requirements (business and technical), and trade studies requiring supplier involvement.

SG 2 Satisfy Supplier Agreements
Agreements with the suppliers are satisfied by both the project and the supplier.
- SP 2.1 Execute the Supplier Agreement.
Perform activities with the supplier as specified in the supplier agreement. Typical work products are supplier progress reports and performance measures, supplier review materials and reports, action items tracked to closure and documentation of product and document deliveries.
- SP 2.2 Monitor Selected Supplier Processes.
Select, monitor, and analyze processes used by the supplier. The selection must consider the impact of the supplier's processes on the project. On larger projects with significant subcontracts for development of critical components, monitoring of key processes is expected. For most vendor agreements where a product is not being developed or for smaller, less critical components, the selection process may determine that monitoring is not appropriate. Between these extremes, the overall risk should be considered in selecting processes to be monitored.
- SP 2.3 Evaluate Selected Supplier Work Products.
The scope of this specific practice is limited to suppliers providing the project with custom-made products, particularly those that present some risk to the program due to complexity or criticality. The intent of this specific practice is to evaluate selected work products produced by the supplier to help detect issues as early as possible that may affect the supplier's ability to satisfy the requirements of the agreement.
- SP 2.4 Accept the Acquired Product.
Ensure that the supplier agreement is satisfied before accepting the acquired product. Acceptance reviews and tests and configuration audits should be completed before accepting the product as defined in the supplier agreement.
- SP 2.5 Transition Products.
Transition the acquired products from the supplier to the project. Before the acquired product is transferred to the project for integration, appropriate planning and evaluation should occur to ensure a smooth transition.

Risk Management (RSKM) Process Area in CMMi

It is a Project Management process area at Maturity Level 3. The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can 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 management. 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 may have a 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. Risk management must consider both internal and external sources for cost, schedule, and performance risk as well as other risks.

Specific Practices by Goal

SG 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.
- SP 1.1 Determine Risk Sources and Categories.
Identification of risk sources provides a basis for systematically examining changing situations over time to uncover circumstances that impact the ability of the project to meet its objectives. Risk sources are both internal and external to the project.
- SP 1.2 Define Risk Parameters.
Parameters for evaluating, categorizing, and prioritizing risks include risk likelihood (i.e., probability of risk occurrence), risk consequence (i.e., impact and severity of risk occurrence), thresholds to trigger management activities.
- SP 1.3 Establish a Risk Management Strategy.
A comprehensive risk management strategy addresses items such as the following:
. The scope of the risk management effort.
. Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication.
. Project-specific sources of risks.
. How these risks are to be organized, categorized, compared, and consolidated.
. Parameters, including likelihood, consequence, and thresholds, for taking action on identified risks.
. Risk mitigation techniques to be used, such as prototyping, piloting, simulation, alternative designs, or evolutionary development.
. Definition of risk measures to monitor the status of the risks.
. Time intervals for risk monitoring or reassessment.

SG 2 Identify and Analyze Risks
The degree of risk impacts the resources assigned to handle an identified risk and the determination of when appropriate management attention is required.
- SP 2.1 Identify Risks.
The identification of potential issues, hazards, threats, and vulnerabilities that could negatively affect work efforts or plans is the basis for sound and successful risk management.
- SP 2.2 Evaluate, Categorize, and Prioritize Risks.
The evaluation of risks is needed to assign relative importance to each identified risk, and is used in determining when appropriate management attention is required.

SG 3 Mitigate Risks
The steps in handling risks include developing risk-handling options, monitoring risks, and performing risk-handling activities when defined thresholds are exceeded.
- SP 3.1 Develop Risk Mitigation Plans.
A critical component of a risk mitigation plan is to develop alternative courses of action, workarounds, and fallback positions, with a recommended course of action for each critical risk. The risk mitigation plan for a given risk includes techniques and methods used to avoid, reduce, and control the probability of occurrence of the risk, the extent of damage incurred should the risk occur (sometimes called a “contingency plan”), or both.
- SP 3.2 Implement Risk Mitigation Plans.
To effectively control and manage risks during the work effort, follow a proactive program to regularly monitor risks and the status and results of risk-handling actions. The risk management strategy defines the intervals at which the risk status should be revisited.

Requirements Management (REQM) Process Area in CMMi

The purpose of Requirements Management (REQM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. It is an Engineering process area at Maturity Level 2.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.

REQM vs.RD

- REQM is about managing the set of requirements and keeping it consistent with the project’s plans whereas RD is about developing the requirements in a systematic way.
- REQM is a Maturity Level 2 process area whereas RD is a Maturity Level 3 process area.

Specific Practices by Goal

SG 1 Manage Requirements
The project maintains a current and approved set of requirements over the life of the project by managing all changes to the requirements, maintaining the relationships among the requirements, the project plans, and the work products, identifying inconsistencies among the requirements, the project plans, and the work products and taking corrective action.
- SP 1.1 Obtain an Understanding of Requirements.
The intent of this SP is to establish a criteria for the project to identify appropriate requirements providers, criteria for the evaluationand acceptance of requirements, and ensure through an analysis or reviewprocess that the established criteria are met.
- SP 1.2 Obtain Commitment to Requirements.
Once the understanding of the requirement is established through the SP1.1, this SP deals with agreements and commitmentsamong those who have to carry out the activities necessary to implement the requirements.
- SP 1.3 Manage Requirements Changes.
Once commitments to the requirements are established and plans have been made. The project will transform from planning mode to execution mode. During the project execution phase, changes to requirements may occur for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements.
- SP 1.4 Maintain Bidirectional Traceability of Requirements.
he intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
- SP 1.5 Identify Inconsistencies between Project Work and Requirements.
This SP focuses on maintaining consistency between requirements and project plans. I.e. the project plan should be revised, if changes to the requirements are identified to be impacting the schedule.

Requirements Development (RD) Process Area in CMMi

he purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. An Engineering process area at Maturity Level 3.
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, and maintainability).
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.

Specific Goals and Practices

SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders 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.
- SP 1.1 Elicit Needs.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
- SP 1.2 Develop the Customer Requirements.
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.

SG 2 Develop Product 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 lifecycle phase.
- SP 2.1 Establish Product and Product-Component Requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions.
- SP 2.2 Allocate Product-Component Requirements.
Allocate the requirements for each product component. The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production.
- SP 2.3 Identify Interface Requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.

SG 3 Analyze and Validate Requirements
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.
- SP 3.1 Establish Operational Concepts and Scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario.
- SP 3.2 Establish a Definition of Required Functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
- SP 3.3 Analyze Requirements.
Analyze requirements to ensure that they are necessary and sufficient.
- SP 3.4 Analyze Requirements to Achieve Balance.
Analyze requirements to balance stakeholder needs and constraints. Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
- SP 3.5 Validate Requirements.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

Quantitative Project Management (QPM) Process Area in CMMi

The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives. A Project Management process area at Maturity Level 4.
The Quantitative Project Management process area involves the following:
- Establishing and maintaining the project’s quality and process-performance objectives.
- Identifying suitable subprocesses that compose the project’s defined process based on historical stability and capability data found in process-performance baselines or models.
- Selecting the subprocesses of the project’s defined process to be statistically managed.
- Monitoring the project to determine whether the project’s objectives for quality and process performance are being satisfied, and identifying appropriate corrective action.
- Selecting the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- Establishing and maintaining an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques.
- Monitoring the performance of the selected subprocesses to determine whether they are capable of satisfying their quality and process-performance objectives, and identifying corrective action.
- Recording statistical and quality management data in the organization’s measurement repository.

Specific Goals and Practices

SG 1 Quantitatively Manage the Project

The project is quantitatively managed using quality and process-performance objectives.
- SP 1.1 Establish the Project's Objectives.
When establishing the project’s quality and process-performance objectives, it is often useful to think ahead about which processes from the organization’s set of standard processes will be included in the project’s defined process, and what the historical data indicates regarding their process performance.
- SP 1.2 Compose the Defined Processes.
Select the subprocesses that compose the project’s defined process based on historical stability and capability data. Subprocesses are identified from the process elements in the organization’s set of standard processes and the process artifacts in the organization’s process asset library.
- SP 1.3 Select the Subprocesses that will be statistically managed.
Selecting the subprocesses to be statistically managed is often a concurrent and iterative process of identifying applicable project and organization quality and process-performance objectives, selecting the subprocesses, and identifying the process and product attributes to measure and control.
- SP 1.4 Manage Project Performance.
A prerequisite for such a comparison is that the selected subprocesses of the project’s defined process are being statistically managed and their process capability is understood. The specific practices of specific goal 2 provide detail on statistically managing the selected subprocesses.

SG 2 Statistically Manage Subprocess Performance
The performance of selected subprocesses within the project's defined process is statistically managed. This specific goal describes an activity critical to achieving the Quantitatively Manage the Project specific goal of this process area.
- SP 2.1 Select Measures and Analytic Techniques.
Select the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- SP 2.2 Apply Statistical Methods to Understand Variation.
Establish and maintain an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques. Understanding variation is achieved, in part, by collecting and analyzing process and product measures so that special causes of variation can be identified and addressed to achieve predictable performance.
- SP 2.3 Monitor Performance of the Selected Subprocesses.
Monitor the performance of the selected subprocesses to determine their capability to satisfy their quality and process-performance objectives, and identify corrective action as necessary.
- SP 2.4 Record Statistical Management Data.
Record statistical and quality management data in the organization’s measurement repository.

Process and Product Quality Assurance (PPQA) Process Area in CMMi

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products. A Support Process Area at Maturity Level 2.
The Process and Product Quality Assurance process area involves the following activities :

- Objectively evaluating performed processes, work products, and services against applicable process descriptions, standards, and procedures.
- Identifying and documenting noncompliance issues.
- Providing feedback to project staff and managers on the results of quality assurance activities.
- Ensuring that noncompliance issues are addressed.
The Process and Product Quality Assurance process area supports the delivery of high-quality products and services by providing project staff and managers at all levels with appropriate visibility into, and feedback on, processes and associated work products throughout the life of the project.

Specific Goals and Practices

SG 1 Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.
- SP 1.1 Objectively Evaluate Processes.
Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures. Objectivity in quality assurance evaluations is critical to the success of the project. A description of the quality assurance reporting chain and how it ensures objectivity should be defined.
- SP 1.2 Objectively Evaluate Work Products and Services.
Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures. The intent of this subpractice is to provide criteria, based on business needs, such as the following:
. What will be evaluated during the evaluation of a work product?
. When or how often a work product will be evaluated?
. How the evaluation will be conducted?
. Who must be involved in the evaluation?

SG 2 Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.
- SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues.
Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers. Noncompliance issues are problems identified in evaluations that reflect a lack of adherence to applicable standards, process descriptions, or procedures. The status of noncompliance issues provides an indication of quality trends. Quality issues include noncompliance issues and results of trend analysis.
When local resolution of noncompliance issues cannot be obtained, use established escalation mechanisms to ensure that the appropriate level of management can resolve the issue. Track noncompliance issues to resolution.
- SP 2.2 Establish Records.
Establish and maintain records of the quality assurance activities. Typical Work Products are evaluation logs, quality assurance reports, status reports of corrective actions and reports of quality trends.

Project Planning (PP) Process area in CMMi

A Project Management Process Area at Maturity Level 2. The purpose of Project Planning (PP) is to establish and maintain plans that define project activities. Planning begins with requirements that define the product and project.
Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and re-planning are contained in this process area.

Specific Goals and Practices

SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained. Estimates of planning parameters should have a sound basis to instill confidence that any plans based on these estimates are capable of supporting project objectives.
- SP 1.1 Estimate the Scope of the Project.
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.”
- SP 1.2 Establish Estimates of Work Product and Task Attributes.
Establish and maintain estimates of the attributes of the work products and tasks.
Size is the primary input to many models used to estimate effort, cost, and schedule. The models can also be based on inputs such as connectivity, complexity, and structure.
- SP 1.3 Define Project Life Cycle.
The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These are normally defined to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.
- SP 1.4 Determine Estimates of Effort and Cost.
Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. There may be occasions when the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models.

SG 2 Develop a Project Plan
A project plan is established and maintained as the basis for managing the project.
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
- SP 2.1 Establish the Budget and Schedule.
The project’s budget and schedule are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed.
- SP 2.2 Identify Project Risks.
Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans that affect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on identified risks. Project planning risk identification and analysis typically include identifying risks, analyzing the risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
and prioritizing risks.
- SP 2.3 Plan for Data Management.
When integrated teams are formed, project data includes data developed and used solely within a particular team as well as data applicable across integrated team boundaries, if there are multiple integrated teams.
- SP 2.4 Plan for Project Resources.
Defining project resources (labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities builds on the initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.
- SP 2.5 Plan for Needed Knowledge and Skills.
Plan for knowledge and skills needed to perform the project. Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources. Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.
- SP 2.6 Plan Stakeholder Involvement.
Stakeholders are identified from all phases of the project lifecycle by identifying the type of people and functions needing representation in the project and describing their relevance and the degree of interaction for specific project activities.
- SP 2.7 Establish the Project Plan.
A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying together in a logical manner.

SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established and maintained. To be effective, plans require commitment by those responsible for implementing and supporting the plan.
- SP 3.1 Review Plans that Affect the Project.
Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control.
- SP 3.2 Reconcile Work and Resource Levels.
When integrated teams are formed, special attention should be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or more projects.
- SP 3.3 Obtain Plan Commitment.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints.

Project Monitoring and Control (PMC) Process Area in CMMi

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. A Project Management Process Area at Maturity Level 2.
A project’s documented plan is the basis for monitoring activities, communicating status, and taking corrective action. Progress is primarily determined by comparing actual work product and task attributes, effort, cost, and schedule to the plan at prescribed milestones or control levels in the project schedule or WBS. Appropriate visibility of progress enables timely corrective action to be taken when performance deviates significantly from the plan. A deviation is significant if, when left unresolved, it precludes the project from meeting its objectives.

Specific Goals and Practices

SG 1 Monitor Project Against Plan
- SP 1.1 Monitor Project Planning Parameters.
Monitor the actual values of the project planning parameters against the project plan. Monitoring typically involves measuring the actual values of project planning parameters, comparing actual values to the estimates in the plan, and identifying significant deviations. Recording actual values of the project planning parameters includes recording associated contextual information to help understand the measures.
- SP 1.2 Monitor Commitments.
Monitor commitments against those identified in the project plan.
- SP 1.3 Monitor Project Risks.
Monitor risks against those identified in the project plan.
- SP 1.4 Monitor Data Management.
Monitor the management of project data against the project plan. Once the plans for the management of project data are made, the management of that data must be monitored to ensure that those plans are accomplished.
- SP 1.5 Monitor Stakeholder Involvement.
Once the stakeholders are identified and the extent of their involvement within the project is specified in project planning, that involvement must be monitored to ensure that the appropriate interactions are occurring.
- SP 1.6 Conduct Progress Reviews.
Periodically review the project's progress, performance, and issues. Progress reviews are reviews on the project to keep stakeholders informed. These project reviews can be informal reviews and may not be specified explicitly in the project plans.
- SP 1.7 Conduct Milestone Reviews.
Review the accomplishments and results of the project at selected project milestones.
Milestone reviews are planned during project planning and are typically formal reviews.

SG 2 Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan. 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.
- SP 2.1 Analyze Issues.
Collect and analyze the issues and determine the corrective actions necessary to address the issues.
- SP 2.2 Take Corrective Action.
Take corrective action on identified issues. Examples of potential actions include modifying the statement of work, modifying requirements, revising estimates and plans, renegotiating commitments, adding resources, changing processes, revising project risks .
- SP 2.3 Manage Corrective Action.
Manage corrective actions to closure. Lessons learned as a result of taking corrective action can be inputs to planning and risk management processes.

Product Integration (PI) Process Area in CMMi

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. An Engineering process area at Maturity Level 3.

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. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.

Specific Practices by Goal

SG 1 Prepare for Product Integration
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.
- SP 1.1 Determine Integration Sequence.
. The product components that are integrated may include those that are a part of the product to be delivered along with test equipment, test software, or other integration items such as fixtures. Once you have analyzed alternative test and assembly integration sequences, select the best integration sequence.

- SP 1.2 Establish the Product Integration Environment.
The environment for product integration can either be acquired or developed. To establish an environment, requirements for the purchase or development of equipment, software, or other resources will need to be developed.

- SP 1.3 Establish Product Integration Procedures and Criteria.
Procedures for the integration of the product components can include such things as the number of incremental iterations to be performed and details of the expected tests and other evaluations to be carried out at each stage.

SG 2 Ensure Interface Compatibility
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.

- SP 2.1 Review Interface Descriptions for Completeness.
The interfaces should include, in addition to product component interfaces, all the interfaces with the product integration environment.

- SP 2.2 Manage Interfaces.
Interface requirements drive the development of the interfaces necessary to integrate product components. Managing product and product component interfaces starts very early in the development of the product. The definitions and designs for interfaces affect not only the product components and external systems, but can also affect the verification and validation environments.

SG 3 Assemble Product Components and Deliver the Product
ntegration 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. 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.

- SP 3.1 Confirm Readiness of Product Components for Integration.
Confirm, prior to assembly, that each product component required to assemble the product has been properly identified, functions according to its description, and that the product component interfaces comply with the interface descriptions.

- SP 3.2 Assemble Product Components.
The assembly activities of this specific practice and the evaluation activities of the next specific practice are conducted iteratively, from the initial product components, through the interim assemblies of product components, to the product as a whole.

- SP 3.3 Evaluate Assembled Product Components.
This evaluation involves examining and testing assembled product components for performance, suitability, or readiness using the available procedures and environment. It is performed as appropriate for different stages of assembly of product components as identified in the product integration sequence and available procedures. The product integration sequence and available procedures may define a more refined integration and evaluation sequence than might be envisioned just by examining the product architecture.

- SP 3.4 Package and Deliver the Product or Product Component.
The packaging requirements for some products can be addressed in their specifications and verification criteria. This is especially important when items are stored and transported by the customer. In such cases, there may be a spectrum of environmental and stress conditions specified for the package.

Organizational Training (OT) Process Area in CMMi

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. Organizational Training includes training to support the organization’s 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.

Specific Practices by Goal

SG 1 Establish an Organizational Training Capability
- SP 1.1 Establish the Strategic Training Needs.
Strategic training needs address long-term objectives to build a capability by filling significant knowledge gaps, introducing new technologies, or implementing major changes in behavior. Strategic planning typically looks two to five years into the future. Examples of sources of strategic training needs include the following:
. Organization’s standard processes.
. Organization’s strategic business plan.
. Organization’s process improvement plan.
. Enterprise-level initiatives.
. Skill assessments.
. Risk analyses.

- SP 1.2 Determine Which Training Needs Are the Responsibility of the Organization.
In addition to strategic training needs, organizational training addresses training requirements that are common across projects and support groups. Projects and support groups have the primary responsibility for identifying and addressing their specific training needs. The organization’s training staff is only responsible for addressing common cross-project and support group training needs.

- SP 1.3 Establish an Organizational Training Tactical Plan.
The organizational training tactical plan is the plan to deliver the training that is the responsibility of the organization and is necessary for individuals to perform their roles effectively. This plan addresses the near-term execution of training and is adjusted periodically in response to changes (e.g., in needs or resources) and to evaluations of effectiveness.

- SP 1.4 Establish Training Capability.
Establish and maintain training capability to address organizational training needs.
Refer to the Decision Analysis and Resolution process area for how to apply decision-making criteria when selecting training approaches and developing training materials.
Examples of training approaches include the following:
. Classroom training.
. Computer-aided instruction.
. Guided self-study.
. Formal apprenticeship and mentoring programs.
. Facilitated videos.
. Chalk talks.
. Brown-bag lunch seminars.
. Structured on-the-job training.

SG 2 Provide Necessary Training
- SP 2.1 Deliver Training.
Training is intended to impart knowledge and skills to people performing various roles within the organization. Some people already possess the knowledge and skills required to perform well in their designated roles. Training can be waived for these people, but care should be taken that training waivers are not abused.

- SP 2.2 Establish Training Records.
Establish and maintain records of the organizational training. The scope of this practice is for the training performed at the organizational level. Establishment and maintenance of training records for project- or support-group-sponsored training is the responsibility of each individual project or support group.

- SP 2.3 Assess Training Effectiveness.
A process should exist to determine the effectiveness of training (i.e., how well the training is meeting the organization’s needs). Measures may be taken to assess the benefit of the training against both the project’s and organization’s objectives. Particular attention should be paid to the need for various training methods, such as training teams as integral work units. When used, performance objectives should be shared with course participants, and should be unambiguous, observable, and verifiable.

Organizational Process Focus (OPF) Process Area in CMMi

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

The organization’s processes include all processes used by the organization and its projects. Candidate improvements to the organization’s processes and process assets are obtained from various sources, including the measurement of processes, lessons learned in implementing 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 in the context of the organization’s needs and is used to address the organization’s objectives.

Specific Practices by Goal

SG 1: Determine Process Improvement Opportunities
Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.
- SP 1.1 Establish Organizational Process Needs
Establish and maintain the description of the process needs and objectives for the organization.
- SP 1.2 Appraise the Organization's Processes
Appraise the organization's processes periodically and as needed to maintain an understanding of their strengths and weaknesses. Process appraisals may be performed for the following reasons :
To identify processes that should be improved

To confirm progress and make the benefits of process improvement visible.

To satisfy the needs of a customer-supplier relationship.
To motivate and facilitate buy-in.
- SP 1.3 Identify the Organization's Process Improvements
Identify improvements to the organization's processes and process assets. Typical Work Products :
Analysis of candidate process improvements.
Identification of improvements for the organization's processes.

SG 2 Plan and Implement Process Improvement Activities
- SP 2.1 Establish Process Action Plans
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 process improvement activities.
Process action teams to define and implement process actions.
Process owners to manage deployment.
Practitioners to perform the process.
- SP 2.2 Implement Process Action Plans

SG 3 Deploy Organizational Process Assets and Incorporate Lessons Learned
- SP 3.1 Deploy Organizational Process Assets.
Deploying organizational process assets or changes to organizational process assets should be performed in an orderly manner. Some organizational process assets or changes to organizational process assets may not be appropriate for use in some parts of the organization.
- SP 3.2 Deploy Standard Processes.
Deploy the organization’s set of standard processes to projects at their startup and deploy changes to them as appropriate throughout the life of each project. It is important that new projects use proven and effective processes to perform critical early activities.
- SP 3.3 Monitor Implementation.
By monitoring implementation, the organization ensures that the organization’s set of standard processes and other process assets are appropriately deployed to all projects. Monitoring implementation also helps the organization develop an understanding of the organizational process assets being used and where they are used within the organization.
- SP 3.4 Incorporate Process-Related Experiences into the Organizational Process Assets.

Organizational Process Definition + IPPD (OPD) Process Area

A Process Management process area at Maturity Level 3. The purpose of Organizational Process Definition + IPPD (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards. For IPPD, Organizational Process Definition + IPPD also covers the establishment of organizational rules and guidelines that enable conducting work using integrated teams.
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 lifecycle models, process tailoring guidelines, process-related documentation, and data. The organization’s 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. The work environment standards are used to guide creation of project work environments.

Specific Practices by Goal

SG 1: Establish Organizational Process Assets
- SP 1.1 Establish Standard Processes.
- SP 1.2 Establish Lifecycle Model Descriptions.
- SP 1.3 Establish Tailoring Criteria and Guidelines.
- SP 1.4 Establish the Organization's Measurement Repository.
- SP 1.5 Establish the Organization's Process Asset Library.
- SP 1.6 Establish Work Environment Standards.

IPPD Addition:
SG 2: Enable IPPD Management
- SP 2.1 Establish Empowerment Mechanisms.
- SP 2.2 Establish Rules and Guidelines for Integrated Teams.
- SP 2.3 Balance Team and Home Organization Responsibilities.

Configuration Management (CM) and Decision Analysis and Resolution (DAR) process area in CMMi

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. It is a support process area at Maturity Level 2.
Configuration management is normally not used or managed within the development process for a Level 1 organization.

Specific Practices by Goal

SG 1 Establish Baselines
- SP 1.1 Identify Configuration Items.
- SP 1.2 Establish a Configuration Management System.
- SP 1.3 Create or Release Baselines.
SG 2 Track and Control Changes
- SP 2.1 Track Change Requests.
- SP 2.2 Control Configuration Items.
SG 3 Establish Integrity
- SP 3.1 Establish Configuration Management Records.
- SP 3.2 Perform Configuration Audits.

Decision Analysis and Resolution (DAR)
It is a support process area at Maturity Level 3. The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

SG 1 Evaluate Alternatives
- SP 1.1 Establish Guidelines for Decision Analysis.
- SP 1.2 Establish Evaluation Criteria.
- SP 1.3 Identify Alternative Solutions.
- SP 1.4 Select Evaluation Methods.
- SP 1.5 Evaluate Alternatives.
- SP 1.6 Select Solutions.

Note : SP stands for Specific Practice and SG stands for Specific Goal.