Chapter 4: CMMI
(B) What is CMMI and What’s the Advantage of Implementing it in an Organization?
CMMI stands for Capability Maturity Model Integration. It is a process improvement approach that provides companies with the essential elements of an effective process. CMMI can serve as a good guide for process improvement across a project, organization, or division.
CMMI was formed by using multiple previous CMM processes. The following are the areas which CMMI addresses:
-
Systems engineering: This covers development of total systems. System engineers concentrate on converting customer needs to product solutions and supports them throughout the product lifecycle.
-
Software engineering: Software engineers concentrate on the application of systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.
-
Integrated Product and Process Development (IPPD): Integrated Product and Process Development (IPPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations, and requirements. This section mostly concentrates on the integration part of the project for different processes. For instance, it’s possible that your project is using services of some other third party component. In such situations the integration is a big task itself, and if approached in a systematic manner, can be handled with ease.
-
Software acquisition: Many times an organization has to acquire products from other organizations. Acquisition is itself a big step for any organization and if not handled in a proper manner means a disaster is sure to happen. The following figure shows the areas involved in CMMI.
(I) What’s the Difference between Implementation and Institutionalization?
Both of these concepts are important while implementing a process in any organization. Any new process implemented has to go through these two phases.
Implementation: It is just performing a task within a process area. A task is performed according to a process but actions performed to complete the process are not ingrained in the organization. That means the process involved is done according to the individual point of view. When an organization starts to implement any process it first starts at this phase, i.e., implementation, and then when this process looks good it is raised to the organization level so that it can be implemented across organizations.
Institutionalization: Institutionalization is the output of implementing the process again and again. The difference between implementation and institutionalization is in implementation if the person who implemented the process leaves the company the process is not followed, but if the process is institutionalized then even if the person leaves the organization, the process is still followed.
(I) What are Different Models in CMMI?
OR
(I) Can You Explain Staged and Continuous Models in CMMI?
There are two models in CMMI. The first is “staged” in which the maturity level organizes the process areas. The second is “continuous” in which the capability level organizes the process area.
The following figure shows how process areas are grouped in both models.
Let’s try to understand both the models in more detail. Before we move ahead let’s discuss the basic structure of the CMMI process, goal, and practices. A process area, as said previously, is a group of practices or activities performed to achieve a specific objective. Every process area has specific as well as generic goals that should be satisfied to achieve that objective. To achieve those goals we need to follow certain practices. So again to achieve those specific goals we have specific practices and to achieve generic goals we have generic practices.
In one of our previous questions we talked about implementation and institutionalization. Implementation can be related to a specific practice while institutionalization can be related to generics practices. This is the common basic structure in both models: Process area à Specific/Generic goals à Specific/Generic practice.
Now let’s try to understand model structures with both types of representations. In a staged representation, we revolve around the maturity level as shown in the following figure. All processes have to be at one maturity level, while in a continuous representation we try to achieve capability levels in those practices. The following diagram shows how continuous representation revolves around capability. Continuous representation is used when the organization wants to mature and perform in one specific process area only. Let’s say for instance in a non-IT organization we want to only improve the supplier agreement process. So that particular organization will only concentrate on the SAM and try to achieve a good capability level in that process area.
(I) Can You Explain the Different Maturity Levels in a Staged Representation?
There are five maturity levels in a staged representation as shown in the following figure.
Maturity Level 1 (Initial): In this level everything is adhoc. Development is completely chaotic with budget and schedules often exceeded. In this scenario we can never predict quality.
Maturity Level 2 (Managed): In the managed level basic project management is in place. But the basic project management and practices are followed only in the project level.
Maturity Level 3 (Defined): To reach this level the organization should have already achieved level 2. In the previous level the good practices and process were only done at the project level. But in this level all these good practices and processes are brought to the organization level. There are set and standard practices defined at the organization level which every project should follow. Maturity Level 3 moves ahead with defining a strong, meaningful, organizational approach to developing products. An important distinction between Maturity Levels 2 and 3 is that at Level 3, processes are described in more detail and more rigorously than at Level 2 and are at an organization level.
Maturity Level 4 (Quantitively measured): To start with, this level of organization should have already achieved Level 2 and Level 3. In this level, more statistics come into the picture. Organization controls the project by statistical and other quantitative techniques. Product quality, process performance, and service quality are understood in statistical terms and are managed throughout the life of the processes. Maturity Level 4 concentrates on using metrics to make decisions and to truly measure whether progress is happening and the product is becoming better. The main difference between Levels 3 and 4 are that at Level 3, processes are qualitatively predictable. At Level 4, processes are quantitatively predictable. Level 4 addresses causes of process variation and takes corrective action.
Maturity Level 5 (Optimized): The organization has achieved goals of maturity levels 2, 3, and 4. In this level, processes are continually improved based on an understanding of common causes of variation within the processes. This is like the final level; everyone on the team is a productive member, defects are minimized, and products are delivered on time and within the budget boundary.
The following figure shows, in detail, all the maturity levels in a pictorial fashion.
(I) Can You Explain Capability Levels in a Continuous Representation?
The continuous model is the same as the staged model only that the arrangement is a bit different. The continuous representation/model concentrates on the action or task to be completed within a process area. It focuses on maturing the organizations ability to perform, control, and improve the performance in that specific performance area.
Capability Level 0: Incomplete
This level means that any generic or specific practice of capability level 1 is not performed.
Capability Level 1: Performed
The capability level 1 process is expected to perform all capability level 1 specific and generic practices for that process area. In this level performance may not be stable and probably does not meet objectives such as quality, cost, and schedule, but still the task can be done.
Capability Level 2: Managed
Capability level 2 is a managed process planned properly, performed, monitored, and controlled to achieve a given purpose. Because the process is managed we achieve other objectives, such as cost, schedule, and quality. Because you are managing, certain metrics are consistently collected and applied to your management approach.
Capability Level 3: Defined
The defined process is a managed process that is tailored from an organization standard. Tailoring is done by justification and documentation guidelines. For instance your organization may have a standard that we should get an invoice from every supplier. But if the supplier is not able to supply the invoice then he should sign an agreement in place of the invoice. So here the invoice standard is not followed but the deviation is under control.
Capability Level 4: Quantitatively Managed
The quantitatively managed process is a defined process which is controlled through statistical and quantitative information. So from defect tracking to project schedules all are statistically tracked and measured for that process.
Capability Level 5: Optimizing
The optimizing process is a quantitatively managed process where we increase process performance through incremental and innovative improvements.
Continuous representation is the same as staged only that information is arranged in a different fashion. The biggest difference is one concentrates on a specific process while the other brings a group of processes to a certain maturity level.
(I) Which Model Should We Use and Under What Scenarios?
Staging defines an organization process implementation sequence. So staging is a sequence of targeted process areas that describe a path of process improvement the organization will take. For instance, you cannot do your project planning (Level 2) if you have not done requirements management (Level 2). While in the continuous model you select certain process areas even if they’re linked with other process areas and mature there.
So when your organization should only concentrate on specific process areas you will likely go for the continuous model. But if you want your organization to have a specific plan and to achieve not only the specific process but also any interlinked process within that process area you should go for the continuous model.
(A) How Many Process Areas are Present in CMMI and What Classification Do They Fall in?
All 25 process areas in CMMI are classified into four major sections.
Process Management
This process areas contain all project tasks related to defining, planning, executing, implementing, monitoring, controlling, measuring, and making better processes.
Project Management
Project management process areas cover the project management activities related to planning, monitoring, and controlling the project.
Engineering
Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering or mechanical engineering) can use them for process improvement.
Support
Support process areas address processes that are used in the context of performing other processes. In general, the support process areas address processes that are targeted toward the project and may address processes that apply more generally to the organization. For example, process and product quality assurance can be used with all the process areas to provide an objective evaluation of the processes and work products described in all the process areas.
The following diagram shows the classification and representation of the process areas.
The following table defines all the abbreviations of the process areas.
(B) Can You Define All the Levels in CMMI?
Level 1 and Level 2
These levels are the biggest steps for any organization because the organization moves from a immature position to a more mature organization. Level 1 is an adhoc process in which people have created a personal process to accomplish a certain task. With this approach there is a lot of redundant work and people do not share their information. This leads to heroes’ in the project, so when people move out of the organization the knowledge also moves out, and the organization suffers.
In maturity level 2 individuals share their lessons and best practices, which leads to devising preliminary processes at the project and in some cases it also moves to the organization level. In level 2 we focus on project management issues that affect day to day routines. It has seven process areas as shown in the figure below.
So in the short difference between level 1 and level 2 is related to immature and mature organizations.
Level 2 to Level 3
Now that in Level 2 good practices are observed at the project level, it is time to move these good practices to the organization level so that every one can benefit from the same. So the biggest difference between Level 2 and Level 3 is good practices from the projects that are bubbled up to organization level. The organization approach of doing business is documented. To perform Maturity level 3, first Maturity 2 must be achieved with the 14 processes as shown in the given figure.
Level 3 to Level 4
Maturity level 4 is all about numbers and statistics. All aspects of the project are managed by numbers. All decisions are made by numbers. Product quality and process are measured by numbers. So in Level 3 we say this is of good quality; in Level 4 we say this is of good quality because the defect ratio is less than 1 %. So there are two process areas in Level 4 as shown below. In order to move to Level 4, you should have achieved all the PA’s of Level 3 and also the two process areas below.
Level 4 to Level 5
Level 5 is all about improvement as compared to Level 4. Level 5 concentrates on improving quality of organization process by identifying variation, by looking at root causes of the conditions and incorporating improvements for improve process. Below are the two process areas in Level 5 as shown in figure below. In order to get level 5 all level 4 PA’s should be satisfied. So the basic difference between level 4 and level 5 is in Level 4 we have already achieved a good level of quality, and in level 5 we are trying to improve the quality.
(I) What Different Sources are Needed to Verify Authenticity for CMMI Implementation?
There are three different sources from which an appraiser can verify that an organization followed the process or not.
Instruments: An instrument is a survey or questionnaire provided to the organization, project, or individuals before starting the assessment so that beforehand the appraiser knows some basic details of the project.
Interview: An interview is a formal meeting between one or more members of the organization in which they are asked some questions and the appraiser makes some judgments based on those interviews. During the interview the member represents some process area or role which he performs. For instance, the appraiser may interview a tester or programmer asking him indirectly what metrics he has submitted to his project manager. By this the appraiser gets a fair idea of CMMI implementation in that organization.
Documents: A document is a written work or product which serves as evidence that a process is followed. It can be hard copy, Word document, email, or any type of written official proof.
The following figure is the pictorial view of the sources used to verify how compliant the organization is with CMMI.
(I) Can You Explain the SCAMPI Process?
OR
(I) How is Appraisal Done in CMMI?
SCAMPI stands for Standard CMMI Appraisal Method for Process Improvement. SCAMPI is an assessment process used to get CMMI certified for an organization. There are three classes of CMMI appraisal methods: Class A, Class B, and Class C. Class A is the most aggressive, while Class B is less aggressive, and Class C is the least aggressive.
Let’s discuss these appraisal methods in more detail.
Class A: This is the only method that can provide a rating and get you a CMMI certificate. It requires all three sources of data instruments, interviews, and documents.
Class B: This class requires only two sources of data (interviews and either documents or instruments). But please note you do not get rated with Class B appraisals. Class B is just a warm-up to see if an organization is ready for Class A. With less verification the appraisal takes less time. In this class data sufficiency and draft presentations are optional.
Class C: This class requires only one source of data (interviews, instruments, or documents). Team consensus, validation, observation, data sufficiency, and draft presentation are optional.
The following table shows the characteristic features with proper comparison.
(I) Which Appraisal Method Class is Best?
Normally, organizations use a mix of the classes to achieve process improvement. The following are some of the strategies which an organization uses:
First Strategy
Use Class B to initiate a process improvement plan. After that apply Class C to check readiness for Class B or Class A. The following diagram shows this strategy.
Second Strategy
Class C appraisal is used on a subset of an organization. From this we get an aggregation of weakness across the organization. From this we can prepare a process improvement plan. We can then apply a Class B appraisal to see if we are ready for Class A appraisal. The following diagram shows the strategy.
Third Strategy
Class A is used to initiate an organization level process. The process improvement plan is based on an identified weakness. Class B appraisal should be performed after six months to see the readiness for the second Class A appraisal rating. The following diagram shows this strategy.
(I) Can You Explain the Importance of PII in SCAMPI?
Using PII (Practice Implementation Indicators) we find information about the organization. PII gives us a compliance matrix showing how practices are performed in an organization. PII basically consists of three types of information: direct work products, indirect work products, and affirmations. Direct work products and indirect work products come from documents while affirmations come from interviews. The following table shows sample PII information for the SAM process and for one of the key process areas.
Once the PII documents are filed we can rate whether the organization is compliant or not. Below are the steps to be followed during the SCAMPI:
-
Gather documentation.
-
Conduct interviews.
-
Discover and document strengths and weaknesses.
-
Communicate/present findings.
(A) Can You Explain Implementation of CMMI in One of the Key Process Areas?
Note This question will be asked to judge whether you have actually implemented CMMI in a proper fashion in your oganization. To answer this question, we will be using SAM as the process area. But you can answer with whatever process area you have implemented in your organization.
For the following SAM process there are the two SG1 and SG2 practices which need to be implemented to satisfy the process area. SAM helps us to define our agreement with the supplier while procuring products in the company. Let’s see, in the next step, how we have mapped our existing process with the SAM practices defined in CMMI.
SAM is a process adopted by the company. If anyone wants to demand any product he has to first raise demand for the item by using the demand form which is defined by the company. Depending on demand the supervisor defines which acquisition type the demand is. For instance, is it a production acquisition type, office material acquisition type, or another type. Once the acquisition type is decided the organization places an advertisement in the newspaper to ask suppliers for quotes. Once all quotations are received depending on cost, quality, and other factors the final supplier is decided. The supplier is then called to the office and he has to sign an agreement with the organization for the delivery of the product. Once the agreement is signed the supplier sends a sample product which is analyzed by the organization practically. Finally, the product is accepted and the supplier is then asked to send the complete delivery of all products. The product is accepted in the organization by issuing the supplier a proper invoice. The invoice document says that the product is accepted by the organization officially. When the product is installed in the organization then either someone from the supplier side comes for the demo or a help brochure is shipped with the product.
The above explanation is from the perspective of the how the organization manages its transactions with the supplier. Now let’s try to map how the above process fits in the CMMI model. In the above diagram the circled descriptions are process areas of CMMI.
CMMI process
Organization process
Determine acquisition type
In the above process the demand form decides what the acquisition type of the product is.
Select suppliers
Looking at the quotation the supplier is reviewed and the selection is done.
Establish supplier agreements
In the above process we have a step when we sign an agreement with the supplier which establishes all the terms and conditions for the supplier agreement.
Review product
One of the steps of the process is that the supplier has to send a sample which is reviewed by the organization.
Execute supplier agreements
The supplier agreement is executed by accepting the invoice.
Accept acquired product
The invoice is the proof of acceptance of the product.
Transition products
In the above process the transition of the product either happens through help brochures or when thdemo person visits.
(B) What are All the Process Areas and Goals and Practices?
OR
(A) Can You Explain All the Process Areas?
Note |
No one is going to ask such a question, but they would like to know at least the purpose of each KPA. Second, they would like to know what you did to attain compatibility in these process areas. For instance, you say that you did an organizational process. They would like to know how you did it. You can justify it by saying that you made standard documents for coding standards which was then followed at the organization level for reference. Normally everyone follows a process; only they do not realize it. So try to map the KPA to the process that you followed. |
Each process area is defined by a set of goals and practices. There are two categories of goals and practices: generic and specific. Generic goals and practices are a part of every process area. Specific goals and practices are specific to a given process area. A process area is satisfied when company processes cover all of the generic and specific goals and practices for that process area.
Generic goals and practices are a part of every process area. They include the following:
GG 1 |
Achieve Specific Goals |
GP 1.1 |
Perform Base Practices |
GG 2 |
Institutionalize a Managed Process |
GP 2.1 |
Establish an Organizational Policy |
GP 2.2 |
Plan the Process |
GP 2.3 |
Provide Resources |
GP 2.4 |
Assign Responsibility |
GP 2.5 |
Train People |
GP 2.6 |
Manage Configurations |
GP 2.7 |
Identify and Involve Relevant Stakeholders |
GP 2.8 |
Monitor and Control the Process |
GP 2.9 |
Objectively Evaluate Adherence |
GP 2.10 |
Review Status with Higher Level Management |
GG 3 |
Institutionalize a Defined Process |
GP 3.1 |
Establish a Defined Process |
GP 3.2 |
Collect Improvement Information |
GG 4 |
Institutionalize a Quantitatively Managed Process |
GP 4.1 |
Establish Quantitative Objectives for the Process |
GP 4.2 |
Stabilize Sub process Performance |
GG 5 |
Institutionalize an Optimizing Process |
GP 5.1 |
Ensure Continuous Process Improvement |
GP 5.2 |
Correct Root Causes of Problems |
Process Areas
The CMMI contains 25 key process areas indicating the aspects of product development that are to be covered by company processes.
Purpose
The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and other problems and take action to prevent them from occurring in the future.
Specific Practices by Goal
SG 1 |
Determine Causes of Defects |
SP 1.1-1 |
Select Defect Data for Analysis |
SP 1.2-1 |
Analyze Causes |
SG 2 |
Address Causes of Defects |
SP 2.1-1 |
Implement the Action Proposals |
SP 2.2-1 |
Evaluate the Effect of Changes |
SP 2.3-1 |
Record Data |
Purpose
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.
Specific Practices by Goal
SG 1 |
Establish Baselines |
SP 1.1-1 |
Identify Configuration Items |
SP 1.2-1 |
Establish a Configuration Management System |
SP 1.3-1 |
Create or Release Baselines |
SG 2 |
Track and Control Changes |
SP 2.1-1 |
Track Change Requests |
SP 2.2-1 |
Control Configuration Items |
SG 3 |
Establish Integrity |
SP 3.1-1 |
Establish Configuration Management Records |
SP 3.2-1 |
Perform Configuration Audits |
Purpose
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-1 |
Establish Guidelines for Decision Analysis |
SP 1.2-1 |
Establish Evaluation Criteria |
SP 1.3-1 |
Identify Alternative Solutions |
SP 1.4-1 |
Select Evaluation Methods |
SP 1.5-1 |
Evaluate Alternatives |
SP 1.6-1 |
Select Solutions |
Purpose
The purpose of Integrated Project Management (IPM) is 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.
Specific Practices by Goal
SG 1 |
Use the Project’s Defined Process |
SP 1.1-1 |
Establish the Project’s Defined Process |
SP 1.2-1 |
Use Organizational Process Assets for Planning Project Activities |
SP 1.3-1 |
Integrate Plans |
SP 1.4-1 |
Manage the Project Using the Integrated Plans |
SP 1.5-1 |
Contribute to the Organizational Process Assets |
SG 2 |
Coordinate and Collaborate with Relevant Stakeholders |
SP 2.1-1 |
Manage Stakeholder Involvement |
SP 2.2-1 |
Manage Dependencies |
SP 2.3-1 |
Resolve Coordination Issues |
SG 3 |
Use the Project’s Shared Vision for IPPD |
SP 3.1-1 |
Define a Project’s Shared Vision for IPPD |
SP 3.2-1 |
Establish the Project’s Shared Vision |
SG 4 |
Organize Integrated Teams for IPPD |
SP 4.1-1 |
Determine Integrated Team Structure for the Project |
SP 4.2-1 |
Develop a Preliminary Distribution of Requirements to Integrated Teams |
SP 4.3-1 |
Establish Integrated Teams |
Purpose
The purpose of Integrated Supplier Management (ISM) is 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.
Specific Practices by Goal
SG 1 |
Analyze and Select Sources of Products |
SP 1.1-1 |
Analyze Potential Sources of Products |
SP 1.2-1 |
Evaluate and Determine Sources of Products |
SG 2 |
Coordinate Work with Suppliers |
SP 2.1-1 |
Monitor Selected Supplier Processes |
SP 2.2-1 |
Evaluate Selected Supplier Work Products |
SP 2.3-1 |
Revise the Supplier Agreement or Relationship |
Purpose
The purpose of Integrated Teaming (IT) is to form and sustain an integrated team for the development of work products.
Specific Practices by Goal
SG 1 |
Establish Team Composition |
SP 1.1-1 |
Identify Team Tasks |
SP 1.2-1 |
Identify Needed Knowledge and Skills |
SP 1.3-1 |
Assign Appropriate Team Members |
SG 2 |
Govern Team Operation |
SP 2.1-1 |
Establish a Shared Vision |
SP 2.2-1 |
Establish a Team Charter |
SP 2.3-1 |
Define Roles and Responsibilities |
SP 2.4-1 |
Establish Operating Procedures |
SP 2.5-1 |
Collaborate among Interfacing Teams |
Purpose
The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.
Specific Practices by Goal
SG 1 |
Align Measurement and Analysis Activities |
SP 1.1-1 |
Establish Measurement Objectives |
SP 1.2-1 |
Specify Measures |
SP 1.3-1 |
Specify Data Collection and Storage Procedures |
SP 1.4-1 |
Specify Analysis Procedures |
SG 2 |
Provide Measurement Results |
SP 2.1-1 |
Collect Measurement Data |
SP 2.2-1 |
Analyze Measurement Data |
SP 2.3-1 |
Store Data and Results |
SP 2.4-1 |
Communicate Results |
Purpose
The purpose of Organizational Environment for Integration (OEI) is to provide an Integrated Product and Process Development (IPPD) infrastructure and manage people for integration.
Specific Practices by Goal
SG 1 |
Provide IPPD Infrastructure |
SP 1.1-1 |
Establish the Organization’s Shared Vision |
SP 1.2-1 |
Establish an Integrated Work Environment |
SP 1.3-1 |
Identify IPPD-Unique Skill Requirements |
SG 2 |
Manage People for Integration |
SP 2.1-1 |
Establish Leadership Mechanisms |
SP 2.2-1 |
Establish Incentives for Integration |
SP 2.3-1 |
Establish Mechanisms to Balance Team and Home Organization Responsibilities |
Organizational Innovation and Deployment (OID)
A Process Management process area at Maturity Level 5.
Purpose
The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. The improvements support the organization’s quality and process-performance objectives as derived from the organization’s business objectives.
Specific Practices by Goal
SG 1 |
Select Improvements |
SP 1.1-1 |
Collect and Analyze Improvement Proposals |
SP 1.2-1 |
Identify and Analyze Innovations |
SP 1.3-1 |
Pilot Improvements |
SP 1.4-1 |
Select Improvements for Deployment |
SG 2 |
Deploy Improvements |
SP 2.1-1 |
Plan the Deployment Areas |
SP 2.2-1 |
Manage the Deployment |
SP 2.3-1 |
Measure Improvement Effects |
Purpose
The purpose of the Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets.
Specific Practices by Goal
SG 1 |
Establish Organizational Process Assets |
SP 1.1-1 |
Establish Standard Processes |
SP 1.2-1 |
Establish Life-Cycle Model Descriptions |
SP 1.3-1 |
Establish Tailoring Criteria and Guidelines |
SP 1.4-1 |
Establish the Organization’s Measurement Repository |
SP 1.5-1 |
Establish the Organization’s Process Asset Library |
Purpose
The purpose of Organizational Process Focus (OPF) is to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.
Specific Practices by Goal
SG 1 |
Determine Process Improvement Opportunities |
SP 1.1-1 |
Establish Organizational Process Needs |
SP 1.2-1 |
Appraise the Organization’s Processes |
SP 1.3-1 |
Identify the Organization’s Process Improvements |
SG 2 |
Plan and Implement Process Improvement Activities |
SP 2.1-1 |
Establish Process Action Plans |
SP 2.2-1 |
Implement Process Action Plans |
SP 2.3-1 |
Deploy Organizational Process Assets |
SP 2.4-1 |
Incorporate Process-Related Experiences into the Organizational Process Assets |
Purpose
The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization’s projects.
Specific Practices by Goal
SG 1 |
Establish Performance Baselines and Models |
SP 1.1-1 |
Select Processes |
SP 1.2-1 |
Establish Process Performance Measures |
SP 1.3-1 |
Establish Quality and Process Performance Objectives |
SP 1.4-1 |
Establish Process Performance Baselines |
SP 1.5-1 |
Establish Process Performance Models |
Purpose
The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so that they can perform their roles effectively and efficiently.
Specific Practices by Goal
SG 1 |
Establish an Organizational Training Capability |
SP 1.1-1 |
Establish the Strategic Training Needs |
SP 1.2-1 |
Determine Which Training Needs Are the Responsibility of the Organization |
SP 1.3-1 |
Establish an Organizational Training Tactical Plan |
SP 1.4-1 |
Establish Training Capability |
SG 2 |
Provide Necessary Training |
SP 2.1-1 |
Deliver Training |
SP 2.2-1 |
Establish Training Records |
SP 2.3-1 |
Assess Training Effectiveness |
Purpose
The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product is integrated, functions properly, and delivers the product.
Specific Practices by Goal
SG 1 |
Prepare for Product Integration |
SP 1.1-1 |
Determine Integration Sequence |
SP 1.2-1 |
Establish the Product Integration Environment |
SP 1.3-1 |
Establish Product Integration Procedures and Criteria |
SG 2 |
Ensure Interface Compatibility |
SP 2.1-1 |
Review Interface Descriptions for Completeness |
SP 2.2-1 |
Manage Interfaces |
SG 3 |
Assemble Product Components and Deliver the Product |
SP 3.1-1 |
Confirm Readiness of Product Components for Integration |
SP 3.2-1 |
Assemble Product Components |
SP 3.3-1 |
Evaluate Assembled Product Components |
SP 3.4-1 |
Package and Deliver the Product or Product Component |
Purpose
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.
Specific Practices by Goals
SG 1 |
Monitor Project Against the Plan |
SP 1.1-1 |
Monitor Project Planning Parameters |
SP 1.2-1 |
Monitor Commitments |
SP 1.3-1 |
Monitor Project Risks |
SP 1.4-1 |
Monitor Data Management |
SP 1.5-1 |
Monitor Stakeholder Involvement |
SP 1.6-1 |
Conduct Progress Reviews |
SP 1.7-1 |
Conduct Milestone Reviews |
SG 2 |
Manage Corrective Action to Closure |
SP 2.1-1 |
Analyze Issues |
SP 2.2-1 |
Take Corrective Action |
SP 2.3-1 |
Manage Corrective Action |
Purpose
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
Specific Practices by Goal
SG 1 |
Establish Estimates |
SP 1.1-1 |
Estimate the Scope of the Project |
SP 1.2-1 |
Establish Estimates of Work Product and Task Attributes |
SP 1.3-1 |
Define Project Life Cycle |
SP 1.4-1 |
Determine Estimates of Effort and Cost |
SG 2 |
Develop a Project Plan |
SP 2.1-1 |
Establish the Budget and Schedule |
SP 2.2-1 |
Identify Project Risks |
SP 2.3-1 |
Plan for Data Management |
SP 2.4-1 |
Plan for Project Resources |
SP 2.5-1 |
Plan for Needed Knowledge and Skills |
SP 2.6-1 |
Plan Stakeholder Involvement |
SP 2.7-1 |
Establish the Project Plan |
SG 3 |
Obtain Commitment to the Plan |
SP 3.1-1 |
Review Plans that Affect the Project |
SP 3.2-1 |
Reconcile Work and Resource Levels |
SP 3.3-1 |
Obtain Plan Commitment |
Purpose
The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.
Specific Practices by Goal
SG 1 |
Objectively Evaluate Processes and Work Products |
SP 1.1-1 |
Objectively Evaluate Processes |
SP 1.2-1 |
Objectively Evaluate Work Products and Services |
SG 2 |
Provide Objective Insight |
SP 2.1-1 |
Communicate and Ensure Resolution of Noncompliance Issues |
SP 2.2-1 |
Establish Records |
Purpose
The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.
Specific Practices by Goal
SG 1 |
Quantitatively Manage the Project |
SP 1.1-1 |
Establish the Project’s Objectives |
SP 1.2-1 |
Compose the Defined Processes |
SP 1.3-1 |
Select the Sub processes that Will Be Statistically Managed |
SP 1.4-1 |
Manage Project Performance |
SG 2 |
Statistically Manage Sub-process Performance |
SP 2.1-1 |
Select Measures and Analytic Techniques |
SP 2.2-1 |
Apply Statistical Methods to Understand Variation |
SP 2.3-1 |
Monitor Performance of the Selected Sub-processes |
SP 2.4-1 |
Record Statistical Management Data |
Purpose
The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product-component requirements.
Specific Practices by Goal
SG 1 |
Develop Customer Requirements |
SP 1.1-1 |
Collect Stakeholder Needs |
SP 1.1-2 |
Elicit Needs |
SP 1.2-1 |
Develop the Customer Requirements |
SG 2 |
Develop Product Requirements |
SP 2.1-1 |
Establish Product and Product-Component Requirements |
SP 2.2-1 |
Allocate Product-Component Requirements |
SP 2.3-1 |
Identify Interface Requirements |
SG 3 |
Analyze and Validate Requirements |
SP 3.1-1 |
Establish Operational Concepts and Scenarios |
SP 3.2-1 |
Establish a Definition of Required Functionality |
SP 3.3-1 |
Analyze Requirements |
SP 3.4-3 |
Analyze Requirements to Achieve Balance |
SP 3.5-1 |
Validate Requirements |
SP 3.5-2 |
Validate Requirements with Comprehensive Methods |
Purpose
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.
Specific Practices by Goal
SG 1 |
Manage Requirements |
SP 1.1-1 |
Obtain an Understanding of Requirements |
SP 1.2-2 |
Obtain Commitment to Requirements |
SP 1.3-1 |
Manage Requirements Changes |
SP 1.4-2 |
Maintain Bidirectional Traceability of Requirements |
SP 1.5-1 |
Identify Inconsistencies between Project Work and Requirements |
Purpose
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.
Specific Practices by Goal
SG 1 |
Prepare for Risk Management |
SP 1.1-1 |
Determine Risk Sources and Categories |
SP 1.2-1 |
Define Risk Parameters |
SP 1.3-1 |
Establish a Risk Management Strategy |
SG 2 |
Identify and Analyze Risks |
SP 2.1-1 |
Identify Risks |
SP 2.2-1 |
Evaluate, Categorize, and Prioritize Risks |
SG 3 |
Mitigate Risks |
SP 3.1-1 |
Develop Risk Mitigation Plans |
SP 3.2-1 |
Implement Risk Mitigation Plans |
Purpose
The purpose of the Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers for which there exists a formal agreement.
Specific Practices by Goal
SG 1 |
Establish Supplier Agreements |
SP 1.1-1 |
Determine Acquisition Type |
SP 1.2-1 |
Select Suppliers |
SP 1.3-1 |
Establish Supplier Agreements |
SG 2 |
Satisfy Supplier Agreements |
SP 2.1-1 |
Review COTS Products |
SP 2.2-1 |
Execute the Supplier Agreement |
SP 2.3-1 |
Accept the Acquired Product |
SP 2.4-1 |
Transition Products |
Purpose
The purpose of the Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes either alone or in appropriate combinations.
Specific Practices by Goal
SG 1 |
Select Product-Component Solutions |
SP 1.1-1 |
Develop Alternative Solutions and Selection Criteria |
SP 1.1-2 |
Develop Detailed Alternative Solutions and Selection Criteria |
SP 1.2-2 |
Evolve Operational Concepts and Scenarios |
SP 1.3-1 |
Select Product-Component Solutions |
SG 2 |
Develop the Design |
SP 2.1-1 |
Design the Product or Product Component |
SP 2.2-3 |
Establish a Technical Data Package |
SP 2.3-1 |
Establish Interface Descriptions |
SP 2.3-3 |
Design Interfaces Using Criteria |
SP 2.4-3 |
Perform Make, Buy, or Reuse Analyses |
SG 3 |
Implement the Product Design |
SP 3.1-1 |
Implement the Design |
SP 3.2-1 |
Develop Product Support |
Purpose
The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.
Specific Practices by Goal
SG 1 |
Prepare for Validation |
SP 1.1-1 |
Select Products for Validation |
SP 1.2-2 |
Establish the Validation Environment |
SP 1.3-3 |
Establish Validation Procedures and Criteria |
SG 2 |
Validate Product or Product Components |
SP 2.1-1 |
Perform Validation |
SP 2.2-1 |
Analyze Validation Results |
Purpose
The purpose of Verification (VER) is to ensure that a selected work product meets their specified requirements.
Specific Practices by Goal
SG 1 |
Prepare for Verification |
SP 1.1-1 |
Select Work Products for Verification |
SP 1.2-2 |
Establish the Verification Environment |
SP 1.3-3 |
Establish Verification Procedures and Criteria |
SG 2 |
Perform Peer Reviews |
SP 2.1-1 |
Prepare for Peer Reviews |
SP 2.2-1 |
Conduct Peer Reviews |
SP 2.3-2 |
Analyze Peer Review Data |
SG 3 |
Verify Selected Work Products |
SP 3.1-1 |
Perform Verification |
SP 3.2-2 |
Analyze Verification Results and Identify Corrective Action. |