cmmi dev gap analysis workbook

Project Name Here 04/08/2023

Summary Worksheet CMMI-SE/SW v1.1 Level 2 of 162

Systems Ltd, Mumbai CMMI Managed - Level 2RM PP PMC SAM M&A PPQA CM

Specific Goal 1 % Complete 40% 25% 0% 0% 0% 67%Specific Goal 2 % Complete 57% 0% 0% 0% 0%Specific Goal 3 % Complete 100% 50%Generic Goal 2 % Complete 30% 20% 10% 0% 50% 30% Color EVGeneric Goal 3 % Complete 0% 50% 50% 50% 50% 0% red 0-14Specific Practices 5 14 10 8 4 7 yellow 15-64Generic Practices 12 12 12 12 12 12 green 65-89

Current Status 23% 50% 15% 13% 25% 29% blue 90-100

Systems Ltd, Mumbai CMMI Defined - Level 3RD TS PI VER VAL OPF OPD OT IPM RKM DAR

Specific Goal 1 % Complete 100% 33% 0% 0% 67% 33% 40% 50% 0% 33% 0%Specific Goal 2 % Complete 0% 25% 0% 0% 50% 0% 100% 0% 0%Specific Goal 3 % Complete 0% 100% 50% 0% 50% 0% 0%Specific Goal 4 % Complete 0%Generic Goal 3 % Complete 0% 50% 25% 0% 58% 0% 0% 67% 0% 0% 0%Specific Practices 10 9 9 8 5 9 6 7 14 7 6Generic Practices 12 12 12 12 12 12 12 12 12 12 12

Current Status 25% 52% 19% 0% 58% 21% 20% 72% 0% 8% 0%

Process Areas (PA) Activities Legend

PA Specific and General Practices 0 or 1

Specific Goal 1 % Complete %



Generic Goal % Complete %

Generic Goal % Complete %

Specific Practices - General Practices Integer Number of specific or generic practices applicable to the process area.

Date/%

Note: These percentages are artificial indicators as to whether or not the project is satisfying the goals of a Process Area. This does not mean in an of itself that a project is "Level 2."

Enter 0 or 1 in the column specified for the SP or GP on each individual process area worksheet. Numbers roll into this summary worksheet in the form of % complete.

Percentage of completion is calculated using the following formula: (SUM of SP scoring for goal DIVIDED by number of practices to meet goal)

Percentage of completion is calculated using the following formula: (SUM of SP scoring for goal DIVIDED by number of practices to meet goal) - IF APPLICABLE

Percentage of completion is calculated using the following formula: (SUM of SP scoring for goal DIVIDED by number of practices to meet goal) - IF APPLICABLE

Percentage of completion is calculated using the following formula: (SUM of GP scoring for goal DIVIDED by number of practices to meet goal)

Percentage of completion is calculated using the following formula: (SUM of GP scoring for goal DIVIDED by number of practices to meet goal)

Current Date - Current Status Previous Date - Previous Status

Summarization of AVERAGE of Specific Goal 1, 2, 3 and both Generic Goals percentage of completion; historical data under previous.


Requirements Management Worksheet CMMI-SE/SW v1.1 Level 2 of 162

Goal or Practice Statement Amplifying Information SEI PII Direct Artifacts Project Artifacts

SG 1 Requirements are managed and inconsistencies with project plans and work products are identified. 40.0%

SP1.1 1

SP1.2 1

Requirements Management (RM)

Goals and Practices

Common Features

SEI PII Indirect Artifacts

Organization Suggested Artifacts

Points Earned (0 or 1)

Develop an understanding with the requirements providers on the meaning of the requirements.

1. Establish criteria for distinguishing appropriate requirements providers; 2. Establish objective criteria for the acceptance of requirements; Lack of acceptance criteria often results in inadequate verification, costly rework, or customer rejection; 3. Analyze requirements to ensure that the established criteria are met; 4. Reach an understanding of the requirements with the requirements provider so the project participants can commit to them.

Requirements documents or database.

A list or characterization of requirements providers authorized to provide direction; Defined criteria for evaluation and acceptance of requirements. Evidence of clarification reviews with requirements providers (e.g., analysis reports, minutes, clarifications, review logs, requirements updates) resulting in identified requirements issues; Action items issued to track resolution of requirements issues.

Obtain commitment to the requirements from the project participants.

1. Assess the impact of requirements on existing commitments; The impact on the project participants should be evaluated when the requirements change or at the start of a new requirement; 2. Negotiate and record commitments. Changes to existing commitments should be negotiated before project participants commit to the requirement or requirement change.

The impact on the project participants should be evaluated when the requirements change or at the start of a new requirement.

[No typical work products are specified in model]· Requirements impact assessments.· Requirements change request logs, with recorded commitment (e.g., signature) and estimates of impact. · Requirements database reports, with attributes for review/commitment status.· Evidence of internal requirements reviews being held (e.g., minutes, checklists, logs, metrics, etc.). · Communication of requirements to project stakeholders, and involvement in establishing commitment.



SP1.3 0

SP1.4 0

SP1.5 0

GG 2 The process is institutionalized as a managed process. 30.0%

Manage changes to the requirements as they evolve during the project.

1. Capture all requirements and requirements changes that are given to or generated by the project; 2. Maintain the requirements change history with the rationale for the changes; Maintaining the change history helps track requirements volatility. 3. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders; 4. Make the requirements and change data available to the project.

Requirements change request logs, with recorded commitment (e.g., signature) and estimates of impact.

· Requirements reports with attributes indicating current state (e.g., approval, source, rationale, revision history, impact).· Change requests, notices, or proposals. (see model for typical content)· Version control of baselined and documented requirements revisions. · Evidence of requirements change reviews during which requirements changes are evaluated with relevant stakeholders, including impact assessment.· Measures of requirements effectiveness (e.g., volatility).· Revisions to work products resulting from changed requirements.

Maintain bidirectional traceability among the requirements and the project plans and work products.

1. Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented; 2. Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes, and work products; 3. Maintain horizontal traceability from function to function and across interfaces; 4. Generate the requirements traceability matrix.

Reports or database indicating traceability of requirements to/from project plans and work products, at each applicable level of system decomposition.

· Criteria and completed checklists and minutes for review of requirements traceability.· Requirements tracking logs.· Revision and maintenance of requirements traceability across the life cycle.· Listings of allocated requirements included in reviews of project plans and work products across the lifecycle.· Requirements mappings used to support impact assessments.

Identify inconsistencies between the project plans and work products and the requirements.

1. Review the project's plans, activities, and work products for consistency with the requirements and the changes made to them; 2. Identify the source of the inconsistency and the rationale; 3. Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline; 4. Initiate corrective actions.

Documentation of identified requirements inconsistencies including sources, conditions, rationales.

Corrective action requirements. Corrective action requests initiated as a result of inconsistencies between requirements and plans/work products · Completed checklists, forms, logs, action items, or minutes substantiating reviews of requirements consistency.



GP2.1 CO 1 0

GP2.2 AB 1 0

GP2.3 AB 2 0

Establish and maintain an organizational policy for planning and performing the requirements management process.

This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.

· Organizational policy. · Version, date, or revision history indicating maintenance of the policies over time.

· Repository of policies (e.g., intranet web access) making them visible and accessible to the organization. · Mapping of policies to CMMI process areas. · Organizational process architecture, e.g., linkage of policies, processes, procedures. · Signature of policies by authorized senior manager. · Configuration control and status data for organizational policies. · Audit results for implementation of the policies.

Establish and maintain the plan for performing the requirements management process.

Typically, this plan for performing the requirements management process is a part of the project plan as described in the Project Planning process area.

· Documented requirements and objectives for the process (e.g., quality, cost, schedule). · Documented plan for performing the process. · Revisions to the requirements, objectives, and plans, as necessary.

· Documented process descriptions, including standards and procedures; this may be included as part of the plan or by reference. · Schedules and resources (funding, people, tools) established for performing the process. · Measures tracking and controlling progress of the plan. · Evidence of review and agreement to the plan by relevant stakeholders (e.g., signature, approval, meeting minutes). Evidence that the plan for the process is implemented and followed.

Provide adequate resources for performing the requirements management process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Requirements tracking tools, Traceability tools.

There are no direct work product PII types mapped to GP2.3, but assessment teams should anticipate · Documented process descriptions and plans (strategic or tactical) for performing the process, which include a characterization of resources needed. · Evidence that adequate resources (funding, facilities, skilled people, tools, etc.) are actually provided as needed.

· Staffing profiles and labor reports showing effort spent on performing the process. · Documented skill prerequisites for filling process roles and responsibilities, and evidence that assigned staff meet these criteria. · Development environment (hardware, software, licenses, tools, etc.). · Analyses, reports, or metrics tracking availability of resources vs. plan.



GP2.4 AB 3 No elaboration provided by the SEI. 1

GP2.5 AB 4 0

GP2.6 DI 1 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process.

There are no direct work products for GP2.4.

· Documentation assigning responsibility for process activities, work products, or services; e.g., job descriptions, or plans for performing the process. · Task descriptions and activities for defined roles. · Acceptance of responsibility by those assigned; this might be documented in many ways (e.g., signature, commitment, agreement, appearance on an org chart, web page contacts, etc.).

Train the people performing or supporting the requirements management process as needed.

Examples of training include: Application domain; Requirements definition, analysis, review, and management; Requirements management tools; Configuration management; Negotiation and conflict resolution.

· Training courses, materials, and methods. · Training records (e.g., attendance, course descriptions, evaluation forms).

· Qualifications and criteria defined for process tasks and assignments. · Training waiver criteria and approvals. · Skills matrix or database.· Training plans, and delivery of training according to the plan. · Training effectiveness data (e.g., surveys, exams, feedback forms).

Place designated work products of the requirements management process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Requirements, Requirements traceability matrix.

Work products identified for configuration management, and the level of configuration management to be applied.

· Configuration management life cycle for identified work products, i.e., the point at which products are placed under various levels of control, change control authority, etc. · Baselines established for control of work product development or release. · Configuration management processes, populated repository, and tools. · Change control documentation for revisions to designated work products; e.g., approved change requests, CCB minutes and reports.



GP2.7 DI 2 1

GP2.8 DI 3 0

GP2.9 VE 1 0

Identify and involve the relevant stakeholders of the requirements management process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include: Resolving issues on the understanding of the requirements, Assessing the impact of requirements changes, Communicating the bidirectional traceability, Identifying inconsistencies among project plans, work products, and requirements.

List of stakeholders and corresponding level of involvement in activities associated with the process.

· Evidence of stakeholder involvement as described in the plan (e.g., signatures, approvals, agreements, attendance lists, memos, minutes, reports, working groups). · Communications documented with stakeholders. · Documented interfaces and dependencies with identified stakeholders. · Action items to resolve stakeholder issues.

Monitor and control the requirements management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Requirements volatility (percentage of requirements changed).

(No direct generic work products).

· Measures of actual performance against plan. · Progress tracking reports, e.g. status reports, financials, graphs, analyses. · Evidence of reviews held with immediate level of management (e.g. briefings, reports, presentations, milestones). · Issues and corrective actions for deviations from plan (e.g., action items, variance reports, change requests). · Revisions to plans and commitments (e.g., replanned schedule, costs, resources).

Objectively evaluate adherence of the requirements management process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Managing requirements; Identifying inconsistencies among project plans, work products, and requirements. Examples of work products reviewed include the following: Requirements; Requirements traceability matrix.

· Noncompliance issues resulting from objective evaluation of adherence to processes, objectives, and standards. · Results of process and product evaluations.

· Identification of processes, work products, and services to be objectively evaluated. · Records of evaluations or audits being performed as planned (e.g., reports, checklists). · Criteria against which processes and work products are evaluated. · Assignment of responsibility for performing objective evaluations. · Revised plans, work products, or standards reflecting corrective action resulting from objective evaluations.



GP2.10 VE 2 0

GG 3 The process is institutionalized as a defined process. 0.0%

GP3.1 No elaboration provided by the SEI. 0

GP3.2 No elaboration provided by the SEI. 0

Review the activities, status, and results of the requirements management process with higher level management and resolve issues.

Proposed changes to commitments to be made external to the organization are reviewed with higher level management to ensure that all commitments can be accomplished.

Materials and results from reviews held with senior management, on both a periodic and event-driven basis.

· Status reports and briefings provided to higher-level management. · Action items and corrective action resulting from management reviews. · Metrics and analyses summarizing project status.

Establish and maintain the description of a defined requirements management process.

(No direct generic work products suggested).

(No indirect generic work products suggested).

Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements management process to support the future use and improvement of the organization’s processes and process assets.




Project Planning Worksheet CMMI-SE/SW v1.1 Level 2 of 162

Project Planning (PP)


SG 1 Estimates of project planning parameters are established and maintained. 25.0%

SP1.1 not consistent 0

Goals and Practices

Common Features


Catalytic Suggested Artifacts


Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

1. Develop a WBS based on the product architecture. The WBS provides a scheme for organizing the project’s work around the products that the work supports. The WBS should permit the identification of the following items: Identified risks and their mitigation tasks, Tasks for deliverables and supporting activities, Tasks for skill and knowledge acquisition, Tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans, Tasks for integration and management of non-developmental items; 2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule; 3. Identify work products (or components of work products) that will be externally acquired; 4. Identify work products that will be reused.

Top-level WBS revision history.

Task descriptions · Product requirements, product roadmaps · Organizational standard WBS template· Identification of work products (or components of work products) that will externally acquired.



Goal or Practice Statement Amplifying Information SEI PII Direct Artifacts Project ArtifactsGoals and Practices

Common Features




SP1.2 not consistent 0

SP1.3 0

SP1.4 1

SG 2 A project plan is established and maintained as the basis for managing the project. 57.1%

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 may also be based on inputs such as connectivity, complexity, and structure. 1. Determine the technical approach for the project (SEP); 2. Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements; 3. Estimate the attributes of the work products and tasks; 4. Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project.

· Estimates of the attributes of the work products and tasks (e.g., size) · Estimates, as appropriate, of labor, machinery, materials, and methods that will be required by the project. · Estimates revision history.

Technical approach; size and complexity of tasks and work products; estimating models. · Estimating tools, algorithms, and procedures · Operational definitions (e.g., procedure/criteria) for establishing and documenting the estimates of the attributes of the work products and tasks. · Bases of Estimates (BOEs) · Use of validated models. · Use of models that are calibrated with historical data.

Define the project life-cycle phases upon which to scope the planning effort.

The determination of a project’s life-cycle 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.

· Relationships, interdependencies and sequencing of project phases

· List of major milestones, events, or decision gates · Risks and factors influencing life cycle selection (e.g., resources, schedules, deliverables).

Estimate the project effort and cost for the work products and tasks based on estimation rationale.

1. Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost; 2. Include supporting infrastructure needs when estimating effort and cost (e.g. critical computer resources and/or facilities); 3. Estimate effort and cost using models and/or historical data.

Project effort estimates; Project cost estimates; · Documented assumptions, constraints, and rationale affecting project estimates, and identify risks. · Bases of Estimates (BOEs).

Estimation rationale · Historical data or repository from previously executed projects. · Estimating methods (e.g., Delphi), models, tools, algorithms, and procedures · Support needs (e.g., facilities and equipment resources).




Common Features




SP2.1 1

SP2.2 1

SP2.3 0

SP2.4 1

Establish and maintain the project’s budget and schedule.

1. Identify major milestones; 2. Identify schedule assumptions; 3. Identify constraints; 4. Identify task dependencies; 5. Define the budget and schedule; 6. Establish corrective action criteria.

Project schedules; Schedule dependencies; Project budget; Revision history for schedule and budget.

· Staffing profile · Identified major milestones · Scheduling assumptions and constraints · Task dependencies · Criteria for corrective action based on deviation from project plan · Comparisons of actual project performance results to estimates (for replanning).

Identify and analyze project risks.

1. Identify risks; 2. Document the risks; 3. Review and obtain agreement with relevant stakeholders on the completeness and correctness of the documented risks; 4. Revise the risks as appropriate.

Identified risks · List of current project risks · Revision history of risks; Risk impacts and probability of occurrence; Risk priorities.

· Records of stakeholder involvement in risk identification activities · Criteria to be used to identify and analyze project risks.

Plan for the management of project data.

1. Establish requirements and procedures to ensure privacy and security of the data.; 2. Establish a mechanism to archive data and to access archived data; 3. Determine the project data to be identified, collected, and distributed.

Data management plan; Master list of managed data.

Data content and format description; Data requirements lists for acquirers and for suppliers; Privacy requirements; Security requirements; Security procedures; Mechanism for data retrieval, reproduction, and distribution; Schedule for collection of project data; Listing of project data to be collected · Project data management repository and access mechanisms · Project data identified, collected and distributed.

Plan for necessary resources to perform the project.

1. Determine process requirements. 2. Determine staffing requirements. 3. Determine facilities, equipment, and component requirements.

WBS work packages; WBS task dictionary; Staffing requirements based on project size and scope · Staffing plans and profiles; Critical facilities/equipment list · Facilities plan · Process/workflow definitions and diagrams.

Program administration requirements list: Budget reviews · Long lead-time items identified early.




Common Features




SP2.5 0

SP2.6 Stakeholder involvement plan. 0

Plan for knowledge and skills needed to perform the project.

1. Identify the knowledge and skills needed to perform the project. 2. Assess the knowledge and skills available. 3. Select mechanisms for providing needed knowledge and skills. 4. Incorporate selected mechanisms in the project plan.

Inventory of skill needs; Staffing and new hire plans · Plans for providing needed knowledge and skills (e.g., training plan).

Databases (e.g., skills and training).

Plan the involvement with identified stakeholders.

Stakeholders are identified from all phases of the project life cycle 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. A two-dimensional matrix with stakeholders along one axis and project activities along the other axis is a convenient format for accomplishing this identification. Relevance of the stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection of the project phase activity axis and the stakeholder axis.

· List of relevant stakeholders for the project · Schedule for stakeholder interaction · Roles and responsibilities for stakeholders · Defined criteria (e.g., procedure) used to plan the involvement with identified stakeholders.




Common Features




SP2.7 1

SG 3 Commitments to the project plan are established and maintained. 100.0%

SP3.1 1

Establish and maintain the overall project plan content.

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: project life-cycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations.

Overall project plan · Project plan revision history.

· Issues and conflicts identified across subordinate plans · IMP, IMS, SEMP, SDP (see model).

Review all plans that affect the project to understand project commitments.

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.

Record of the reviews of plans that affect the project · Review and signature cycle of the set of plans describing project scope, objectives, roles, and relationships.

· Project plan · Integrated work plans · Evidence of project plan coordination meetings and correspondence.




Common Features




SP3.2 1

SP3.3 1


Reconcile the project plan to reflect available and estimated resources.

To obtain commitment from relevant stakeholders, it is important to reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules.

Renegotiated budgets; Revised schedules; Revised requirements list; Renegotiated stakeholder agreements.

Revised methods and corresponding estimating parameters (e.g., better tools, use of off-the-shelf components) · Project change requests · Project plan revision history.

Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

1. Identify needed support and negotiate commitments with relevant stakeholders. 2. Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories. 3. Review internal commitments with senior management as appropriate. 4. Review external commitments with senior management as appropriate. 5. Identify commitments on interfaces between elements in the project, and with other projects and organizational units, so they can be monitored.

Documented commitments; Documented commitment by those implementing the plan. · Documented commitments by those responsible for providing resources.

Documented requests for commitments; Commitment review meeting minutes · Identification and documentation of issues · Identified commitments on interfaces between elements in the project, with other projects, and organizational units.




Common Features




GP2.1 CO 1 0

GP2.2 AB 1 1

Establish and maintain an organizational policy for planning and performing the project planning process.

This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.



Establish and maintain the plan for performing the project planning process.

This plan for performing the project planning process differs from the project plan described in specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from estimating the scope of the project all the way to obtaining commitment for the project plan. In other words, this generic practice calls for one to “plan the plan.” In contrast, the project plan called for in the specific practices would address planning for the project effort itself in a comprehensive manner.






Common Features




GP2.3 AB 2 1

GP2.4 AB 3 0

GP2.5 AB 4 0

Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.

Special expertise, equipment, and facilities in project planning may be required. Special expertise in project planning may include the following: Experienced estimators; Schedulers; Technical experts in applicable areas (e.g., product domain and technology). Examples of other resources provided include the following tools: Spreadsheet programs; Estimating models; Project planning and scheduling packages.


· [Tools: spreadsheet programs; estimating models; project planning and scheduling packages] · [Staff: experienced estimators; schedulers; technical experts in application domain and technologies] · Tools: historical project performance database; data analysis and graphing tools; risk database; office automation tools; desktop publishing tools.

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the project planning process.

No elaboration provided by the SEI. There are no direct work products for GP2.4.


Train the people performing or supporting the project planning process as needed.

Examples of training topics include the following: Estimating; Budgeting; Negotiating; Risk identification and analysis; Data management; Planning; Scheduling.






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 0

Place designated work products of the project planning process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Work breakdown structure; Project plan; Data management plan; Stakeholder involvement plan.



Identify and involve the relevant stakeholders of the project planning process as planned.

Examples of activities for stakeholder involvement include the following: Establishing estimates; Reviewing and resolving issues on the completeness and correctness of the project risks; Reviewing data management plans; Establishing project plans; Reviewing project plans and resolving issues on work and resource issues.






Common Features




GP2.8 DI 3 0

GP2.9 VE 1 0

GP2.10 VE 2 0


GP3.1 1

Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of revisions to the plan; Cost, schedule, and effort variance per plan revision.



Objectively evaluate adherence of the project planning process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing estimates; Developing a project plan; Obtaining commitments to the project plan. Examples of work products reviewed include the following: WBS; Project plan; Data management plan; Stakeholder involvement plan.



Review the activities, status, and results of the project planning process with higher level management and resolve issues.

No elaboration provided by the SEI.



Establish and maintain the description of a defined project planning process.

No elaboration provided by the SEI. (No direct generic work products suggested).





Common Features




GP3.2 0

Collect work products, measures, measurement results, and improvement information derived from planning and performing the project planning process to support the future use and improvement of the organization’s processes and process assets.




Project Monitoring and Control Worksheet CMMI-SE/SW v1.1 Level 2 of 162


SG 1 Actual performance and progress of the project are monitored against the project plan. 0.0%

SP1.1 0

SP1.2 0

SP1.3 0

Project Monitoring and Control (PMC)

Goals and Practices

Common Features




Monitor the actual values of the project planning parameters against the project plan.

1. Monitor progress against the schedule. 2. Monitor the project's cost and expended effort. 3. Monitor the attributes of the work products and tasks.4. Monitor resources provided and used. 5. Monitor the knowledge and skills of project personnel. 6. Document the significant deviations in the project planning parameters.

Records of project performance; Records of significant deviations against plan; Performance actual values vs. plan (e.g., schedule, cost, effort, work product attributes, resources, knowledge and skills) · Comparisons of actual Project Project performance results to estimates (for replanning).

· Earned value management metrics · Variance reports · Status reports · Relevant project management/milestone progress review materials · Identified major milestones · Project or organizational repository for performance measurements · Indications knowledge and skills of project personnel are monitored.

Monitor commitments against those identified in the project plan.

1. Regularly review commitments (both external and internal); 2. Identify commitments that have not been satisfied or which are at significant risk of not being satisfied; 3. Document the results of the commitment reviews.

Records of commitment reviews: Status reports or tracking minutes · PPQA audit reports of performance against cost, schedule, and technical commitments documented in approved plans · Reports against cost account and earned value plans · Project review records, project meeting minutes, and project presentations packages showing planned activities are performed per commitments made).

· Project plans, and commitments tracking system · Reviews of documented commitments and revisions as necessary (e.g., presentations).

Monitor risks against those identified in the project plan.

1. Periodically review the documentation of the risks in the context of the project’s current status and circumstances; 2. Revise the documentation of the risks, as additional information becomes available, to incorporate changes; 3. Communicate risk status to relevant stakeholders.

Records of Project risk Monitoring: Periodic review and revision of risk status (e.g., probability, priority, severity) · Communications of risk status to relevant stakeholders.

Defined criteria (e.g., procedure) used to monitor risks against those identified in the Project plan.




Common Features




SP1.4 0

SP1.5 0

SP1.6 0

Monitor the management of project data against the project plan.

1. Periodically review data management activities against their description in the project plan; 2. Identify and document significant issues and their impacts; 3. Document the results of data management activity reviews.

Records of data management: Data management reports (e.g., inventory, delivery schedules and status) · Reviews/inventories/master lists or audits of project data repository status · Results of data management reviews.

Master list of managed data; Data management plan.

Monitor stakeholder involvement against the project plan.

1. Periodically review the status of stakeholder involvement; 2. Identify and document significant issues and their impacts; 3. Document the results of the stakeholder involvement status reviews.

Records of stakeholder involvement: Project team stakeholder reviews (presentation materials, minutes, action items and action item status) · Stakeholder issues and status.

· Stakeholder meeting and communications schedules · Distribution lists for communication of issues · Stakeholder correspondence with issues indicated · Mechanisms/tools for monitoring and resolving stakeholder issues (e.g., files and spreadsheets)

Periodically review the project's progress, performance, and issues.

1. Regularly communicate status on assigned activities and work products to relevant stakeholders; 2. Review the results of collecting and analyzing measures for controlling the project; 3. Identify and document significant issues and deviations from the plan; 4. Document change requests and problems identified in any of the work products and processes; 5. Document the results of the reviews; 6. Track change requests and problem reports to closure.

Documented Project review results: Project review packages · Project review minutes and action items · Reviews of project monitoring measurements and analysis.

· Collection and analyses of project performance measures (schedules, effort, deviations from plan) · Records of communications of project status to relevant stakeholders · Records of issues, change requests, problem reports for work products and processes · Defined criteria (e.g., procedure) used for periodically reviewing the Project’s progress, performance, and issues (including work products, processes, schedules/intervals, and checklists/standards for conducting reviews).




Common Features




SP1.7 0

SG 2 Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan. 0.0%

SP2.1 0

SP2.2 0

Review the accomplishments and results of the project at selected project milestones.

1. Conduct reviews at meaningful points in the project's schedule, such as the completion of selected stages, with relevant stakeholders; 2. Review the commitments, plan, status, and risks of the project; 3. Identify and document significant issues and their impacts; 4. Document the results of the review, action items, and decisions; 5. Track action items to closure.

Documented milestone review results: Milestone review packages · Milestone review minutes and action items · Documented issues from the reviews.

· Milestone progress performance indicators · Defined criteria (e.g., procedure) used to review the accomplishments and results of the Project at selected Project milestones (including definitions of milestones) · Standards/formats/checklists supporting milestone reviews.

Collect and analyze the issues and determine the corrective actions necessary to address the issues.

1. Gather issues for analysis; 2. Analyze issues to determine need for corrective action.

List of issues needing corrective actions: List of issues needing corrective actions · Documented analysis of issues needing corrective action.

Examples of issues to be gathered include: Issues discovered through performing verification and validation activities; Significant deviations in the project planning parameters from the estimates in the project plan; Commitments (either internal or external) that have not been satisfied; Significant changes in risk status; Data access, collection, privacy, or security issues; Stakeholder representation or involvement issues.

Take corrective action on identified issues.

1. Determine and document the appropriate actions needed to address the identified issues; 2. Review and get agreement with relevant stakeholders on the actions to be taken; 2. Negotiate changes to internal and external commitments.

Corrective action plan: Revision to project plans and work products (SOW, estimates, requirements, estimates, commitments, resources, processes, risks) incorporating the corrective actions.

Defined criteria (e.g., procedure) used to develop the corrective action plan and take corrective action on identified issues.




Common Features




SP2.3 0

GG 2 The process is institutionalized as a managed process. 10%

GP2.1 CO 1 0

GP2.2 AB 1 0

Manage corrective actions to closure.

1. Monitor corrective actions for completion; 2. Analyze results of corrective actions to determine the effectiveness of the corrective actions; 3. Determine and document appropriate actions to correct deviations from planned results for corrective actions.

Corrective action results: Evidence that resources have been applied and schedules have been followed to take the planned corrective actions on identified issues · Corrective action status, tracking reports, or metrics (e.g. quantity open / closed, trending).

· Review and meeting minutes associated with corrective actions · Corrective action effectiveness analysis · Closed corrective action requests.

Establish and maintain an organizational policy for planning and performing the project monitoring and control process.

This policy establishes organizational expectations for monitoring performance against the project plan and managing corrective action to closure when actual performance or results deviate significantly from the plan.



EEstablish and maintain the plan for performing the project monitoring and control process.

This plan for performing the project monitoring and control process is typically a part of the project plan, as described in the Project Planning process area.






Common Features




GP2.3 AB 2 1

GP2.4 AB 3 0

GP2.5 AB 4 0

Provide adequate resources for performing the project monitoring and control process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Cost tracking systems; Effort reporting systems; Action-item-tracking systems; Project management and scheduling programs.


· [Tools: cost tracking systems; effort reporting systems; action item tracking systems; project management and scheduling programs] · Tools: problem tracking packages; measurement collection, analysis, and reporting tools; risk database; office automation tools · Tools: project planning and scheduling tools; estimating models; spreadsheet programs; historical project performance database.

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the project monitoring and control process.



Train the people performing or supporting the project monitoring and control process as needed.

Examples of training topics include the following: Monitoring and control of projects; Risk management; Data management.






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 0

Place designated work products of the project monitoring and control process under appropriate levels of configuration management.




Identify and involve the relevant stakeholders of the project monitoring and control process as planned.

Examples of activities for stakeholder involvement include the following: Assessing the project against the plan; Reviewing commitments and resolving issues; Reviewing project risks; Reviewing data management activities; Reviewing project progress; Managing corrective actions to closure.






Common Features




GP2.8 DI 3 0

GP2.9 VE 1 0

GP2.10 VE 2 0

Monitor and control the project monitoring and control process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of open and closed corrective actions; Project milestone dates (e.g., planned versus actual and slipped milestones); Number and types of reviews performed; Review schedule (planned versus actual and slipped target dates).



Objectively evaluate adherence of the project monitoring and control process against its process description, standards, and procedures, and address noncompliance.

Examples of activities and work products reviewed include the following: Monitoring project performance against the project plan; Managing corrective actions to closure; Records of project performance; Project review results.



Review the activities, status, and results of the project monitoring and control process with higher level management and resolve issues.







Common Features





GP3.1 1

GP3.2 0

Establish and maintain the description of a defined project monitoring and control process.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the project monitoring and control process to support the future use and improvement of the organization’s processes and process assets.




Supplier Agreement Management Worksheet CMMI-SE/SW v1.1 Level 2 of 162


SG 1 Agreements with the suppliers are established and maintained. 66.7%

SP1.1 0

SP1.2 1

SP1.3 1

SG 2 Agreements with the suppliers are satisfied by both the project and the supplier. 50.0%

Supplier Agreement Management (SAM)

Goals and Practices

Common Features


Process Description at Organizational level

Information Content in the Organizational Process referred

Organization's Suggested Artifacts


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. Examples of types of acquisition include COTS, contractual agreement, in-house vendors, product from customer, or combinations.

List of the acquisition types that will be used for all products and product components to be acquired.

· Make/buy analysis or trade study with product acquisition options · Management authorization to proceed with acquisition of a product or service · System architecture/design documentation identifying products or components to be acquired (e.g., non-developmental items).

Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria.

1. Establish and document criteria for evaluating potential suppliers. 2. Identify potential suppliers and distribute solicitation material and requirements to them. 3. Evaluate proposals according to evaluation criteria. 4. Evaluate risks associated with each proposed supplier. 5. Evaluate proposed suppliers' ability to perform the work. 6. Select the supplier.

Rationale for selection of suppliers; Evaluation criteria; Supplier evaluation results.

List of candidate suppliers; Preferred supplier list; Advantages and disadvantages of candidate suppliers; Solicitation materials and requirements: Requirements allocation to the product to be acquired · Procurement documentation (e.g., tech spec, SOW, interfaces, solicitation, proposals, etc.) · Supplier surveys · Analysis of acquisition risks and best value supplier · Source selection decision.

Establish and maintain formal agreements with the supplier.

1. Revise the requirements to be fulfilled by the supplier to reflect negotiations with the supplier when necessary. 2. Document what the project will provide to the supplier. 3. Document the supplier agreement. 4. Ensure all parties to the agreement understand and agree to all requirements before implementing the agreement. 5. Revise the supplier agreement as necessary. 6. Revise the project’s plans and commitments as necessary to reflect the supplier agreement.

Documented formal supplier agreement, with approved revisions as necessary; Statements of Work; Contracts; Memoranda of agreement; Licensing agreement.

· Negotiated contractual terms, conditions, and constraints (e.g., deliverables, requirements, schedule, budget, standards, facilities, acceptance criteria) · Defined parameters, criteria, and objectives for evaluating supplier performance · Acquirer plans to monitor supplier progress and product quality (e.g., quality plans, IV&V plans) · Integration of supplier products and schedules into acquirer plans (e.g., milestones, interfaces, dependencies, environment, testing, etc.) · Acquirer impact assessment and revision to project plans, as necessary · Supplier Work Breakdown Structure · Issues or action items relating to definition or revision of the supplier agreement.




Common Features






SP2.1 0

SP2.2 1

Review candidate COTS products to ensure they satisfy the specified requirements that are covered under a supplier agreement.

1. Develop criteria for evaluating COTS products. 2. Evaluate candidate COTS products against the associated requirements and criteria. 3. Evaluate the impact of candidate COTS products on the project's plans and commitments. 4. Assess the suppliers' performance and ability to deliver. 5. Identify risks associated with the selected COTS product and the supplier agreement. 6. Select the COTS product to be acquired. 7. Plan for the maintenance of the COTS product.

Reviews of COTS products; Identification of selected COTS products with rationale for selection.

Trade studies; Price lists; Evaluation criteria; Supplier performance reports: Negotiated licenses or agreements for purchase of COTS products · Requirements allocation to COTS products or components · Checklists, criteria, risk assessments, or trade studies for evaluation and selection of COTS products.

Perform activities with the supplier as specified in the supplier agreement.

1. Monitor supplier progress and performance (schedule, effort, cost, and technical performance) as defined in the supplier agreement. 2. Monitor selected supplier processes and take corrective action when necessary. 3. Conduct reviews with the supplier as specified in the supplier agreement. 4. Conduct technical reviews with the supplier as defined in the supplier agreement. 5. Conduct management reviews with the supplier as defined in the supplier agreement. 6. Use the results of reviews to improve the supplier's performance and to establish and nurture long-term relationships with preferred suppliers. 7. Monitor risks involving the supplier and take corrective action as necessary. 8. Revise the supplier agreement and project plans and schedules as necessary.

No single work product here; all products specified in the supplier agreement must be considered in assessing this practice. Supplier progress reports and performance measures; Supplier review materials and reports; Documentation of work product and document deliveries.

Action items tracked to closure · Audits, corrective action requests, and plans to improve supplier performance · Supporting evidence of supplier technical and management reviews (agenda, minutes, etc.).




Common Features






SP2.3 Acceptance test results. 1

SP2.4 0


GP2.1 CO 1 0

Ensure that the supplier agreement is satisfied before accepting the acquired product.

1. Define the acceptance procedures. 2. Review and obtain agreement with relevant stakeholders on the acceptance procedures before the acceptance review or test. 3. Verify that the acquired products satisfy their requirements. 4. Confirm that the nontechnical commitments associated with the acquired work product are satisfied. 5. Document the results of the acceptance review or test. 6. Establish and obtain supplier agreement on an action plan for any acquired work products that do not pass their acceptance review or test. 7. Identify, document, and track action items to closure.

Acceptance test procedures; Discrepancy reports or corrective action plans · Configuration audit results · Traceability reports indicating coverage of requirements for the acquired product by acceptance test procedures. · Verification of functional performance, configuration, and adherence to defined requirements and commitments · Closure or termination of supplier agreement.

Transition the acquired products from the supplier to the project.

1. Ensure that there are appropriate facilities to receive, store, use, and maintain the acquired products. 3. Ensure that appropriate training is provided for those involved in receiving, storing, using, and maintaining the acquired products. 3. Ensure that storing, distributing, and using the acquired products are performed according to the terms and conditions specified in the supplier agreement or license. Transition plans · Records reflecting implementation of transition plans.

Training reports; Support and maintenancereports · CM reports indicating control, auditing, and maintenance of acquired products · Records indicating integration of the acquired product into the project · Vendor maintenance agreements.

Establish and maintain an organizational policy for planning and performing the supplier agreement management process.

This policy establishes organizational expectations for establishing, maintaining, and satisfying supplier agreements.






Common Features






GP2.2 AB 1 0

GP2.3 AB 2 1

GP2.4 AB 3 1

Establish and maintain the plan for performing the supplier agreement management process.

Typically, portions of this plan for performing the supplier agreement management process are a part of the project plan as described in the Project Planning process area. Often, however, some portions of the plan reside outside of the project with an independent group, such as contract management.



Provide adequate resources for performing the supplier agreement management process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Preferred supplier lists; Requirements tracking programs; Project management and scheduling programs.


Tools: preferred supplier lists; requirements tracking programs; project management and scheduling programs · Facilities: secure repositories for limited access to source selection data · Tools: research and reference libraries of vendors and COTS products; supplier database; COTS product licenses; action item database · Staff: domain experts in applications and technologies being acquired.

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the supplier agreement management process.






Common Features






GP2.5 AB 4 0

GP2.6 DI 1 0

GP2.7 DI 2 1

GP2.8 DI 3 0

Train the people performing or supporting the supplier agreement management process as needed.

Examples of training topics include the following: Regulations and business practices related to negotiating and working with suppliers; Acquisition planning and preparation; COTS products acquisition; Supplier evaluation and selection; Negotiation and conflict resolution; Supplier management; Testing and transitioning of acquired products; Receiving, storing, using, and maintaining acquired products.



Place designated work products of the supplier agreement management process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Statements of work; Supplier agreements; Memoranda of agreement; Subcontracts; Preferred supplier lists.



Identify and involve the relevant stakeholders of the supplier agreement management process as planned.

Examples of activities for stakeholder involvement include the following: Establishing criteria for evaluation of potential suppliers; Reviewing potential suppliers; Establishing supplier agreements; Resolving issues with suppliers; Reviewing supplier performance.



Monitor and control the supplier agreement management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of changes made to the requirements for the supplier; Cost and schedule variance per supplier agreement.






Common Features






GP2.9 VE 1 0

GP2.10 VE 2 0


GP3.1 1

GP3.2 0

Objectively evaluate adherence of the supplier agreement management process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing and maintaining supplier agreements; Satisfying supplier agreements. Examples of work products reviewed include the following: Plan for Supplier Agreement Management; Supplier agreements.



Review the activities, status, and results of the supplier agreement management process with higher level management and resolve issues.




Establish and maintain the description of a defined supplier agreement management process.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the supplier agreement management process to support the future use and improvement of the organization’s processes and process assets.




Measurement and Analysis Worksheet CMMI-SE/SW v1.1 Level 2 of 162


SG 1 Measurement objectives and activities are aligned with identified information needs and objectives. 0.0%

SP1.1 0

SP1.2 0

SP1.3 0

Measurement and Analysis (M&A)

Goals and Practices

Common Features




Establish and maintain measurement objectives that are derived from identified information needs and objectives.

1. Document information needs and objectives. 2. Prioritize information needs and objectives. 3. Document, review, and update measurement objectives. 4. Provide feedback for refining and clarifying information needs and objectives as necessary. 5. Maintain traceability of the measurement objectives to the identified information needs and objectives.

Documented measurement objectives; Revisions to measurement objectives.

· Alignment between business goals, measurement objectives/goals, information needs/objectives (questions) · Identified information needs and objectives · Documented sources of information needs (see model, e.g., strategic plans, process improvement plans, management interviews) · Reviews of measurement objectives with affected stakeholders (e.g., management, providers, users).

Specify measures to address the measurement objectives.

1. Identify candidate measures based on documented measurement objectives. 2. Identify existing measures that already address the measurement objectives. 3. Specify operational definitions for the measures. 4. Prioritize, review, and update measures.

Documented specifications of base and derived measures.

· Linkage between measures and project/organization measurement objectives and information needs · Algorithms, templates, checklists, procedures, ways of consistently collecting and recording measures for the product, project and process attributes identified · Evidence of review of proposed specifications with stakeholders and other end users · List of prioritized measures.

Specify how measurement data will be obtained and stored.

1. Identify existing sources of data that are generated from current work products, processes, or transactions. 2. Identify measures for which data are needed, but are not currently available. 3. Specify how to collect and store the data for each required measure. 4. Create data collection mechanisms and process guidance. 5. Support automatic collection of the data where appropriate and feasible. 6. Prioritize, review, and update data collection and storage procedures. 7. Update measures and measurement objectives as necessary.

Documented data collection and storage procedures: Explicit data collection descriptions, including who (responsibilities), how (procedures and tools), when (frequency), where (repository).

Data collection tools: Data collection mechanisms and supporting tools (automatic or manual) · Raw data collected, time tagged, and stored · Analysis reports and trending indicating completeness of collected data · Measurement repository · Reports of invalid or discarded data.




Common Features




SP1.3 0

SP1.4 0

SG 2 Measurement results that address identified information needs and objectives are provided. 0%

Specify how measurement data will be obtained and stored.

1. Identify existing sources of data that are generated from current work products, processes, or transactions. 2. Identify measures for which data are needed, but are not currently available. 3. Specify how to collect and store the data for each required measure. 4. Create data collection mechanisms and process guidance. 5. Support automatic collection of the data where appropriate and feasible. 6. Prioritize, review, and update data collection and storage procedures. 7. Update measures and measurement objectives as necessary.

Documented data collection and storage procedures: Explicit data collection descriptions, including who (responsibilities), how (procedures and tools), when (frequency), where (repository).

Data collection tools: Data collection mechanisms and supporting tools (automatic or manual) · Raw data collected, time tagged, and stored · Analysis reports and trending indicating completeness of collected data · Measurement repository · Reports of invalid or discarded data.

Specify how measurement data will be analyzed and reported.

1. Specify and prioritize the analyses that will be conducted and the reports that will be prepared. 2. Select appropriate data analysis methods and tools. 3. Specify administrative procedures for analyzing the data and communicating the results. 4. Review and update the proposed content and format of the specified analyses and reports. 5. Update measures and measurement objectives as necessary. 6. Specify criteria for evaluating the utility of the analysis results, and of the conduct of the measurement and analysis activities.

Documented analysis specification and procedures: Explicit analysis descriptions, including who (responsibilities), how (procedures and tools), when (frequency), where (repository), and how the results will be used.

Data analysis tools: Results of data analyses (e.g., graphs, reports) · Alignment of data analyses with measurement objectives (e.g., traceability to information needs and decision making) · Evidence of evaluations or meetings held to review measurement analyses (minutes, action items, etc.) · Criteria for evaluating the utility of measurement and analysis data · Revisions to measures and measurement objectives.




Common Features




SP2.1 0

SP2.2 0

SP2.3 0

SP2.4 0


Obtain specified measurement data.

1. Obtain the data for base measures. 2. Generate the data for derived measures. 3. Perform data integrity checks as close to the source of the data as possible.

Base and derived measurement data sets · Raw data collected, time tagged, and stored in accordance with defined data collection procedures · Derived measures calculated from collected base measures.

Results of data integrity tests · Measurement repository populated with the specified measures · Analysis reports and trending indicating completeness of collected data · Results of integrity checks (e.g., tools, forms, reviews); reports of invalid or discarded data.

Analyze and interpret measurement data.

1. Conduct initial analyses, interpret the results, and draw preliminary conclusions. 2. Conduct additional measurement and analysis as necessary, and prepare results for presentation. 3. Review the initial results with relevant stakeholders. 4. Refine criteria for future analyses.

Analysis results and draft reports: Analysis results (e.g., graphs, reports) and conclusions (preliminary or final).

Representations for analysis results (e.g., tables, charts, histograms) · Evidence of evaluations or meetings held to review measurement analyses (briefings, minutes, action items, etc.) · Follow-up analyses performed to address areas of concern, if necessary · Revisions of criteria for future analysis.

Manage and store measurement data, measurement specifications, and analysis results.

1. Review the data to ensure their completeness, integrity, accuracy, and currency; 2. Make the stored contents available for use only by appropriate groups and personnel; 3. Prevent the stored information from being used inappropriately.

Stored data inventory · Measurement repository with historical data and results.

Contextual information for understanding and interpreting the measures, and assessing them for reasonableness and applicability · Measurement repository, with access restriction to the stored data.

Report results of measurement and analysis activities to all relevant stakeholders.

1. Keep relevant stakeholders apprised of measurement results on a timely basis. 2. Assist relevant stakeholders in understanding the results.

Delivered reports and related analysis results.

Contextual data or guidance to aid in interpretation of analysis results · Presentations of data analyses and reports · Measurement indicator templates · Distribution lists or web pages for communicating measurement results · Alignment maintained between measures, analyses, and business objectives.




Common Features




GP2.1 CO 1 0

GP2.2 AB 1 0

Establish and maintain an organizational policy for planning and performing the measurement and analysis process.

This policy establishes organizational expectations for aligning measurement objectives and activities with identified information needs and objectives and for providing measurement results.



Establish and maintain the plan for performing the measurement and analysis process.

Typically, this plan for performing the measurement and analysis process is included in (or referenced by) the project plan, which is described in the Project Planning process area.






Common Features




GP2.3 AB 2 0

GP2.4 AB 3 0

GP2.5 AB 4 0

Provide adequate resources for performing the measurement and analysis process, developing the work products, and providing the services of the process.

Examples of other resources provided include the following: Statistical packages; Packages that support data collection over networks.


Additional information not provided in PII.

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the measurement and analysis process.



Train the people performing or supporting the measurement and analysis process as needed.

Examples of training topics include the following: Statistical techniques; Data collection, analysis, and reporting processes; Development of goal-related measurements (e.g., Goal Question Metric).






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 0

Place designated work products of the measurement and analysis process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Specifications of base and derived measures; Data collection and storage procedures; Base and derived measurement data sets; Analysis results and draft reports; Data analysis tools.



Identify and involve the relevant stakeholders of the measurement and analysis process as planned.

Examples of activities for stakeholder involvement include the following: Establishing measurement objectives and procedures; Assessing measurement data; Providing meaningful feedback to those responsible for providing the raw data on which the analysis and results depend.






Common Features




GP2.8 DI 3 0

GP2.9 VE 1 0

GP2.10 VE 2 0


Monitor and control the measurement and analysis process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Percentage of projects using progress and performance measures; Percentage of measurement objectives addressed.



Objectively evaluate adherence of the measurement and analysis process against its process description, standards, and procedures, and address noncompliance.

Examples of activities and work products reviewed include the following: Aligning measurement and analysis activities; Providing measurement results; Specifications of base and derived measures; Data collection and storage procedures; Analysis results and draft reports.



Review the activities, status, and results of the measurement and analysis process with higher level management and resolve issues.







Common Features




GP3.1 1

GP3.2 0

Establish and maintain the description of a defined measurement and analysis process.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the measurement and analysis process to support the future use and improvement of the organization’s processes and process assets.




Process and Product Quality Assurance Worksheet CMMI-SE/SW v1.1 Level 2 of 162


SG 1 0.0%

SP1.1 0

SP1.2 0

PROCESS AND PRODUCT QUALITY ASSURANCE

(PPQA)

Goals and Practices

Common Features




Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures.

1. Promote an environment (created as part of project management) that encourages employee participation in identifying and reporting quality issues. 2. Establish and maintain clearly stated criteria for the evaluations. 3. Use the stated criteria to evaluate performed processes for adherence to process descriptions, standards, and procedures. 4. Identify each noncompliance found during the evaluation. 5. Identify lessons learned that could improve processes for future products and services.

Audit reports; Noncompliance reports.

Corrective actions: Quality assurance plan, identifying the processes subject to evaluation, and procedures for performing evaluations · Applicable process descriptions, standards, and procedures · Action items for noncompliance issues, tracked to closure · Criteria and checklists used for work product evaluations (e.g. what, when, how, who) · Schedule for performing process evaluations (planned, actual) at selected milestones throughout the product development life cycle · Org chart or description identifying responsibility, objectivity, and reporting chain of the QA function · Quality assurance records, reports, or database · Records of reviews or events indicating QA involvement (e.g. attendance lists, signature).

Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures.

1. Select work products to be evaluated, based on documented sampling criteria if sampling is used. 2. Establish and maintain clearly stated criteria for the evaluation of work products. 3. Use the stated criteria during the evaluations of work products. 4. Evaluate work products before they are delivered to the customer. 5. Evaluate work products at selected milestones in their development. 6. Perform in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures. 7. Identify each case of noncompliance found during the evaluations. 8. Identify lessons learned that could improve processes for future products and services.


Corrective actions: Quality assurance plan, identifying the work products and services subject to evaluation, and procedures for performing evaluations · Action items for noncompliance issues, tracked to closure · Criteria and checklists used for work product evaluations (e.g. what, when, how, who); may include sampling criteria · Schedule for performing work product evaluations (planned, actual) at selected milestones throughout the product development life cycle · Org chart or description identifying responsibility, objectivity, and reporting chain of the QA function · Quality assurance records, reports, or database · Records of reviews or events indicating QA involvement (e.g. attendance lists, signature)




Common Features




SP1.2 0

SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured. 0.0%

Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures.

1. Select work products to be evaluated, based on documented sampling criteria if sampling is used. 2. Establish and maintain clearly stated criteria for the evaluation of work products. 3. Use the stated criteria during the evaluations of work products. 4. Evaluate work products before they are delivered to the customer. 5. Evaluate work products at selected milestones in their development. 6. Perform in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures. 7. Identify each case of noncompliance found during the evaluations. 8. Identify lessons learned that could improve processes for future products and services.


Corrective actions: Quality assurance plan, identifying the work products and services subject to evaluation, and procedures for performing evaluations · Action items for noncompliance issues, tracked to closure · Criteria and checklists used for work product evaluations (e.g. what, when, how, who); may include sampling criteria · Schedule for performing work product evaluations (planned, actual) at selected milestones throughout the product development life cycle · Org chart or description identifying responsibility, objectivity, and reporting chain of the QA function · Quality assurance records, reports, or database · Records of reviews or events indicating QA involvement (e.g. attendance lists, signature)




Common Features




SP2.1 0

SP2.2 0


Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers.

1. Resolve each noncompliance with the appropriate members of the staff where possible. 2. Document noncompliance issues when they cannot be resolved within the project. 3. Escalate noncompliance issues that cannot be resolved within the project to the appropriate level of management designated to receive and act on noncompliance issues; 4. Analyze the noncompliance issues to see if there are any quality trends that can be identified and addressed; 5. Ensure that relevant stakeholders are aware of the results of evaluations and the quality trends in a timely manner; 6. Periodically review open noncompliance issues and trends with the manager designated to receive and act on noncompliance issues; 7. Track noncompliance issues to resolution.

Corrective action reports; Audit reports.

Quality trends: Action items for noncompliance issues, tracked to closure · Revised work products, standards and procedures, or waivers issued to resolve noncompliance issues · Reports or briefings communicating noncompliance issues to relevant stakeholders · Evidence of reviews held periodically to receive and act upon noncompliance issues · Quality metrics and trend analyses · Tracking system or database for noncompliance issues.

Establish and maintain records of the quality assurance activities.

1. Record process and product quality assurance activities in sufficient detail such that status and results are known; 2. Revise the status and history of the quality assurance activities as necessary.

Audit logs; Quality assurance reports; Records of quality assurance activities.

Status of corrective actions; Quality trends: · Noncompliance actions, reports, logs, or database · Completed evaluation checklists · Schedule for performing process and product evaluations (planned, actual) · Records of reviews or events indicating QA involvement (e.g. attendance lists, signature) · Metrics or analyses used for quality assurance of processes and work products.




Common Features




GP2.1 CO 1 1

GP2.2 AB 1 1

Establish and maintain an organizational policy for planning and performing the process and product quality assurance process.

This policy establishes organizational expectations for objectively evaluating whether processes and associated work products adhere to the applicable process descriptions, standards, and procedures, and ensuring that noncompliance is addressed. This policy also establishes organizational expectations for process and product quality assurance being in place for all projects. Process and product quality assurance must possess sufficient independence from project management to provide objectivity in identifying and reporting noncompliance issues.



Establish and maintain the plan for performing the process and product quality assurance process.

This plan for performing the process and product quality assurance process may be included in (or referenced by) the project plan, which is described in the Project Planning process area.






Common Features




GP2.3 AB 2 1

GP2.4 AB 3 1

GP2.5 AB 4 0

Provide adequate resources for performing the process and product quality assurance process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Evaluation tools; Noncompliance tracking tool.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process and product quality assurance process.

To guard against subjectivity or bias, ensure that those people assigned responsibility and authority for process and product quality assurance can perform their evaluations with sufficient independence and objectivity.



Train the people performing or supporting the process and product quality assurance process as needed.

Examples of training topics include the following: Application domain; Customer relations; Process descriptions, standards, procedures, and methods for the project; Quality assurance objectives, process descriptions, standards, procedures, methods, and tools.






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 0

Place designated work products of the process and product quality assurance process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Noncompliance reports; Evaluation logs and reports.



Identify and involve the relevant stakeholders of the process and product quality assurance process as planned.

Examples of activities for stakeholder involvement include the following: Establishing criteria for the objective evaluations of processes and work products; Evaluating processes and work products; Resolving noncompliance issues; Tracking noncompliance issues to closure.






Common Features




GP2.8 DI 3 0

GP2.9 VE 1 0

GP2.10 VE 2 1


Monitor and control the process and product quality assurance process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Variance of objective process evaluations planned and performed; Variance of objective work product evaluations planned and performed.



Objectively evaluate adherence of the process and product quality assurance process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Objectively evaluating processes and work products; Tracking and communicating noncompliance issues. Examples of work products reviewed include the following: Noncompliance reports; Evaluation logs and reports.



Review the activities, status, and results of the process and product quality assurance process with higher level management and resolve issues.







Common Features




GP3.1 1

GP3.2 0

Establish and maintain the description of a defined process and product quality assurance process.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the process and product quality assurance process to support the future use and improvement of the organization’s processes and process assets.




Configuration Management Worksheet CMMI-SE/SW v1.1 Level 2 of 162


SG 1 Baselines of identified work products are established. 66.7%

SP1.1 0

SP1.2 1

Configuration Management (CM)

Goals and Practices

Common Features




Identify the configuration items, components, and related work products that will be placed under configuration management.

1. Select the configuration items and the work products that compose them based on documented criteria. 2. Assign unique identifiers to configuration items. 3. Specify the important characteristics of each configuration item. 4. Specify when each configuration item is placed under configuration management. 5. Identify the owner responsible for each configuration item.

Identified configuration items · Configuration management lifecycle for controlled items (e.g., owner, point at which placed under control, degree of control, change approval).

Configuration management plan · Configuration item identifiers, attributes and characteristics · Documented criteria for selecting configuration items.

Establish and maintain a configuration management and change management system for controlling work products.

1. Establish a mechanism to manage multiple control levels of configuration management. 2. Store and retrieve configuration items in the configuration management system. 3. Share and transfer configuration items between control levels within the configuration management system. 4. Store and recover archived versions of configuration items. 5. Store, update, and retrieve configuration management records. 6. Create configuration management reports from the configuration management system. 7. Preserve the contents of the configuration management system. 8. Revise the configuration management structure as necessary.

Configuration management system with controlled work products; Change request database; Configuration management and change management procedures.

Configuration management system access control procedures · CM library records and reports (e.g. baseline contents, level of controlled items, audit reports) · Change management database reports· CM plan, describing tools and mechanisms for storage, retrieval, multiple levels of control · Records of the revision of the configuration management structure, as necessary · CM backup and archive media.




Common Features




SP1.3 1

SG 2 Changes to the work products under configuration management are tracked and controlled. 0.0%

SP2.1 0

Create or release baselines for internal use and for delivery to the customer.

1. Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items. 2. Create or release baselines only from configuration items in the configuration management system. 3. Document the set of configuration items that are contained in a baseline. 4. Make the current set of baselines readily available.

Baselines; Descriptions of baselines · Baseline identifiers with defined and controlled contents (configuration items).

Configuration management records and reports · CCB meeting minutes · Change documentation and version control associated with a baseline · Baseline generation/release procedures, scripts, transmittal documents · CM tool or repository demo (e.g., baselines, items, nodes, branches).

Changes to the work products under configuration management are tracked and controlled.

1. Initiate and record change requests in the change request database. 2. Analyze the impact of changes and fixes proposed in the change requests. 3. Review change requests that will be addressed in the next baseline with those who will be affected by the changes and get their agreement. 4. Track the status of change requests to closure.

Change requests · Change request tracking products (e.g., reports, logs, closure status, metrics) · Recorded evaluation and disposition of change requests (e.g., review, authorization, approval of changes).

Change request impact analyses · Change request lifecycle or workflow descriptions · CCB/stakeholder review records (e.g., logs, meeting minutes) · Configuration item revision history.




Common Features




SP2.2 0

SG 3 Integrity of baselines is established and maintained. 50.0%

Control changes to the configuration items.

1. Control changes to configuration items throughout the life of the product. 2. Obtain appropriate authorization before changed configuration items are entered into the configuration management system. 3. Check in and check out configuration items from the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items. 4. Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that the changes have not compromised the safety and/or security of the system). 5. Record changes to configuration items and the reasons for the changes as appropriate.

Revision history of configuration items · Revised configuration items and baselines incorporating approved changes (e.g., CCB approval).

Archived baseline · Configuration management records and reports describing the revision status of baselines and configuration items · Impact analyses, reviews, or regression tests to ensure the integrity of baseline revisions · Change request review and tracking products (e.g., checklists, evaluation criteria, reports, logs, closure status, metrics) · Recorded evaluation and disposition of change requests (e.g., review, authorization, approval of changes) · Check-in/check-out procedures from the configuration management system.




Common Features




SP3.1 0

SP3.2 Configuration audit results. 1


Establish and maintain records describing configuration items.

1. Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered. 2. Ensure that relevant stakeholders have access to and knowledge of the configuration status of the configuration items. 3. Specify the latest version of the baselines. 4. Identify the version of configuration items that constitute a particular baseline. 5. Describe the differences between successive baselines. 6. Revise the status and history (i.e., changes and other actions) of each configuration item as necessary.

Records describing content, status, and version of configuration items and baselines · Reports describing configuration item status, available to affected individuals and groups (e.g., CM library reports, baseline access).

Revision history of configuration items; Change log · Change request logs or database; Status of configuration items; Differences between baselines.

Perform configuration audits to maintain integrity of the configuration baselines.

1. Assess the integrity of the baselines. 2. Confirm that the configuration records correctly identify the configuration of the configuration items. 3. Review the structure and integrity of the items in the configuration management system. 4. Confirm the completeness and correctness of the items in the configuration management system. 5. Confirm compliance with applicable configuration management standards and procedures. 6. Track action items from the audit to closure.

Action items for discrepancies determined as a result of configuration audits: Criteria and checklists used to conduct configuration audits · Configuration management system or libraries · Change request logs or database · Records describing content, status, and version of configuration items and baselines · Reports describing status of configuration items · Quality inspection records.




Common Features




GP2.1 CO 1 0

GP2.2 AB 1 0

Establish and maintain the plan for performing the configuration management process.

This policy establishes organizational expectations for establishing and maintaining baselines, tracking and controlling changes to the work products (under configuration management), and establishing and maintaining integrity of the baselines.



Establish and maintain the requirements and objectives, and plans for performing the configuration management process.

This plan for performing the configuration management process can be included in (or referenced by) the project plan, which is described in the Project Planning process area.






Common Features




GP2.3 AB 2 1

GP2.4 AB 3 1

GP2.5 AB 4 0

Provide adequate resources for performing the configuration management process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Configuration management tools; Data management tools; Archiving and reproduction tools; Database programs.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the configuration management process.



Train the people performing or supporting the configuration management process as needed.

Examples of training topics include the following: Roles, responsibilities, and authority of the configuration management staff; Configuration management standards, procedures, and methods; Configuration library system.






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 1

GP2.8 DI 3 0

Place designated work products of the configuration management process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Access lists; Change status reports; Change request database; CCB meeting minutes; Archived baselines.



Identify and involve the relevant stakeholders of the configuration management process as planned.

Examples of activities for stakeholder involvement include the following: Establishing baselines; Reviewing configuration management system reports and resolving issues; Assessing the impact of changes for the configuration items; Performing configuration audits; Reviewing the results of configuration management audits.



Monitor and control the configuration management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of changes to configuration items; Number of configuration audits conducted.






Common Features




GP2.8 DI 3 0

GP2.9 VE 1 0

GP2.10 VE 2 0


GP3.1 0

Monitor and control the configuration management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of changes to configuration items; Number of configuration audits conducted.



Objectively evaluate adherence of the configuration management process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing baselines; Tracking and controlling changes; Establishing and maintaining integrity of baselines. Examples of work products reviewed include the following: Archives of the baselines; Change request database.



Review the activities, status, and results of the configuration management process with higher level management and resolve issues.




Establish and maintain the description of a defined configuration management process.






Common Features




GP3.2 0

Collect work products, measures, measurement results, and improvement information derived from planning and performing the configuration management process to support the future use and improvement of the organization’s processes and process assets.






SG 1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. 100.0%

SP1.1 1

SP1.2 1

Requirements Development (RD)

Goals and Practices

Common Features




Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle.

1. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces. Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product life-cycle activities and their impact on the product. Examples of techniques to elicit needs include demonstrations, working groups, project reviews, questionnaires, interviews, and operational scenarios obtained from end users, prototypes and models, brainstorming, beta testing, extraction from sources such as documents, standards, or specifications, use cases, and reverse engineering (for legacy products).

Artifacts indicating stakeholder needs, expectations, and constraints (implicit and explicit)

Results of requirements collection methods (e.g., Interviews, prototypes, requirements analyses, market surveys, use cases, product domain analysis) · Evidence of customer interaction · Results of requirements reviews to remove conflicts.

Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.

1. Translate the stakeholder needs, expectations, constraints, and interfaces into documented customer requirements. 2. Define constraints for verification and validation. Relevant stakeholders representing all phases of the product’s life cycle should include business as well as technical functions. The various inputs from the customer 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.

Customer Requirements; Requirements for verification process; Requirements for validation process.

Test cases and expected results · Interface definitions · Constraints.




Common Features




SP1.2 1

SG 2 Customer requirements are refined and elaborated to develop product and product-component requirements. 0.0%

SP2.1

Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.

1. Translate the stakeholder needs, expectations, constraints, and interfaces into documented customer requirements. 2. Define constraints for verification and validation. Relevant stakeholders representing all phases of the product’s life cycle should include business as well as technical functions. The various inputs from the customer 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.

Customer Requirements; Requirements for verification process; Requirements for validation process.

Test cases and expected results · Interface definitions · Constraints.

Establish and maintain product and product-component requirements, which are based on the customer requirements.

1. Develop requirements in technical terms necessary for product and product-component design. Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design. 2. Derive requirements that result from design decisions. Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits. 3. Establish and maintain relationships between requirements for consideration during change management and requirements allocation.

Derived requirements; Product requirements; Product component requirements: § Results of methods (e.g., House of quality) used to translate customer needs into technical parameters § Requirements traceability matrix § Revision histories of requirements.

§ Analysis of cost performance tradeoffs of requirements and of lifecycle phases considering business objectives § Performance modeling results.




Common Features




SP2.2

SP2.3 Identify interface requirements. Interface requirements.

SG 3 The requirements are analyzed and validated, and a definition of required functionality is developed. 0.0%

Allocate the requirements for each product component.

1. Allocate requirements to functions. 2. Allocate requirements to product components. 3. Allocate design constraints to product components. 4. Document relationships among allocated requirements. Relationships include dependencies in which a change in one requirement may affect other requirements.

Requirement allocation sheets; Provisional requirement allocations; Derived requirements; Relationships between derived requirements; Specifications.

Design constraints · Indication of allocated requirements traceability · Include allocation of product performance, design constraints, and fit, form, and function.

1. Identify interfaces both external to the product and internal to the product (i.e., between functional partitions or objects). As the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product. Examples include interfaces with test equipment, transportation systems, support systems, and manufacturing facilities. 2. Develop the requirements for the identified interfaces. Requirements for interfaces are defined in terms of origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.

· Architecture documents · Integration test plans.




Common Features




SP3.1 New requirements.Establish and maintain operational concepts and associated scenarios.

1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate. Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints, in which the proposed product is expected to operate. 2. Define the environment the product will operate in, including boundaries and constraints. 3. Review operational concepts and scenarios to refine and discover requirements. The review may be in the form of a walkthrough. 4. Develop a detailed operational concept, as products and product components are selected, that defines the interaction of the product, the end user, and the environment, and that satisfies the operational, maintenance, support, and disposal needs.

Operational concept; Product installation, operational, maintenance and support concepts; Disposal concepts; Scenarios (e.g.use cases, timeline scenarios, and revision histories).




Common Features




SP3.2Establish and maintain a definition of required functionality.

1. Analyze and quantify functionality required by end users. 2. Analyze requirements to identify logical or functional partitions (e.g., subfunctions). 3. Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis. 4. Consider the sequencing of time-critical functions both initially and subsequently during product-component development. 5. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions. 6. Allocate functional and performance requirements to functions and subfunctions.

Functional architecture (Functional requirements)

Activity diagrams and use cases; Object oriented analysis with services identified; Results of analysis of requirements for subfunctions that identify logical or functional partitions of requirements; Traceability of functional requirements that relate to product operation.




Common Features




SP3.3

SP3.4

Analyze requirements to ensure that they are necessary and sufficient.

1. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects. 2. Analyze requirements to determine whether they satisfy the objectives of higher level requirements. 3. Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable. While design determines the feasibility of a particular solution, this subpractice addresses knowing which requirements affect feasibility. 4. Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance. 5. Identify technical performance measures that will be tracked during the development effort. 6. Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.

Requirements defects reports; Key requirements.

Proposed requirements changes to resolve defects; Technical performance measures.

Analyze requirements to balance stakeholder needs and constraints.

1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints. Results of the analyses can be used to reduce the cost of the product and the risk in developing the product. 2. Perform a risk assessment on the requirements and functional architecture. 3. Examine product life-cycle concepts for impacts of requirements on risks.

Assessment of risks related to requirements; Results of requirements analysis indicating impact on cost and schedule.

· Risk mitigation plan · Project Management plan.




Common Features




SP3.5


GP2.1 CO 1 0

Validate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate.

1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment. 2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations, models, scenarios, and storyboards) and by obtaining feedback about them from relevant stakeholders. 3. Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements.

Record of analysis methods and results; Validation methodology.

Requirements traceability matrix · Requirements specification · Requirements changes · Results of techniques to demonstrate requirements functionality (e.g., prototypes, simulations, analyses, scenarios, and storyboards).

Establish and maintain an organizational policy for planning and performing the requirements development process.

This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component requirements, and analyzing and validating those requirements.






Common Features




GP3.1 AB 1 0

GP2.2 AB 2 0

Establish and maintain the description of a defined requirements development process.



Establish and maintain the plan for performing the requirements development process.

Typically, this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.






Common Features




GP2.3 AB 3 0

GP2.4 AB 4 0

GP2.5 AB 5 0

Provide adequate resources for performing the requirements development process, developing the work products, and providing the services of the process.

Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product-component requirements may be required. Examples of other resources provided include the following tools: Requirements specification tools; Simulators and modeling tools; Prototyping tools; Scenario definition and management tools; Requirements tracking tools.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.



Train the people performing or supporting the requirements development process as needed.

Examples of training topics include the following: Application domain; Requirements definition and analysis; Requirements elicitation; Requirements specification and modeling; Requirements tracking.






Common Features




GP2.6 DI 1 0

GP2.7 DI 2 0

Place designated work products of the requirements development process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Customer requirements; Functional architecture; Product and product-component requirements; Interface requirements.



Identify and involve the relevant stakeholders of the requirements development process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces; Establishing operational concepts and scenarios; Assessing the adequacy of requirements; Establishing product and product-component requirements; Assessing product cost, schedule, and risk.






Common Features




GP2.8 DI 3 0

GP3.2 DI 4 0

Monitor and control the requirements development process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Cost, schedule, and effort expended for rework; Defect density of requirements specifications.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP2.9 VE 1 0

GP2.10 VE 2 0

Objectively evaluate adherence of the requirements development process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Collecting stakeholder needs; Formulating product and product-component requirements; Analyzing and validating product and product-component requirements. Examples of work products reviewed include the following: Product requirements; Product-component requirements; Interface requirements; Functional architecture.



Review the activities, status, and results of the requirements development process with higher level management and resolve issues.






Technical Solution (TS)


SG 1 Product or product-component solutions are selected from alternative solutions. 33.3%

SP1.1 0

SP1.2 0

Goals and Practices

Common Features




Develop detailed alternative solutions and selection criteria.

1. Identify screening criteria to select a set of alternative solutions for consideration. 2. Identify technologies currently in use and new product technologies for competitive advantage. 3. Generate alternative solutions. 4. Obtain a complete requirements allocation for each alternative. 5. Develop the criteria for selecting the best alternative solution. Criteria should be included that address design issues for the life of the product, such as provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated. 6. Develop timeline scenarios for product operation and user interaction for each alternative solution.

Alternative solutions; Selection criteria.

Evaluations of new technologies; Checklists for alternative solution screening criteria; Evaluation of solutions and technologies (new or legacy); Requirements allocation for each alternative and their associated cost; Design issues; A process or processes for identifying solution alternatives, selection criteria, and design issues; COTS evaluations.

Evolve the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component.

1. Evolve the operational concepts and scenarios to a degree of detail appropriate for the product component. 2. Evolve the operational environments for the product components. The environments may include thermal, stress, and electromagnetic and other elements that need to be documented.

Product component operational concepts, scenarios, and environments for all pertinent life-cycle processes (operations, support, training, manufacturing, verification, deployment/fielding/delivery/disposal)

Timeline analyses of product component interactions; Event trace diagrams; Use cases for each component; Criteria and checklists used for describing the conditions, operating modes, and operating states of each component; Change requests.




Common Features




SP1.2 0

SP1.3 1

SG 2 Product or product-component designs are developed. 25.0%

Evolve the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component.

1. Evolve the operational concepts and scenarios to a degree of detail appropriate for the product component. 2. Evolve the operational environments for the product components. The environments may include thermal, stress, and electromagnetic and other elements that need to be documented.

Product component operational concepts, scenarios, and environments for all pertinent life-cycle processes (operations, support, training, manufacturing, verification, deployment/fielding/delivery/disposal)

Timeline analyses of product component interactions; Event trace diagrams; Use cases for each component; Criteria and checklists used for describing the conditions, operating modes, and operating states of each component; Change requests.

Select the product-component solutions that best satisfy the criteria established.

1. Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts, operating modes, and operating states. 2. Based on the evaluation of alternatives, assess the adequacy of the selection criteria and update these criteria as necessary. 3. Identify and resolve issues with the alternative solutions and requirements. 4. Select the best set of alternative solutions that satisfy the established selection criteria. 5. Establish the requirements associated with the selected set of alternatives as the set of allocated requirements to those product components. 6. Identify the product-component solutions that will be reused or acquired. 7. Establish and maintain the documentation of the solutions, evaluations, and rationale.

Product component selection decisions and rationale.

Documented relationships between requirements and product components; Initial product component technical data package; Alternative solutions under consideration and selection criteria; Operating concepts, modes, and states; Technical memos; Requirements allocated to product components; Resolution of issues for selection of best alternative solution using the functional requirements as a parameter; Documentation of selected solutions using the allocated requirements and selected product components; Processes and procedures for selection of product component solutions.




Common Features




SP2.1 1Develop a design for the product or product component.

1. Establish and maintain criteria against which the design can be evaluated. 2. Identify, develop, or acquire the design methods appropriate for the product. 3. Ensure that the design adheres to applicable design standards and criteria. 4. Ensure that the design adheres to allocated requirements. 5. Document the design.

Design methods; Organizational and project design standards, activities, and tools.

Criteria for design methods; Criteria for selection of the design method; Design tools; Design process/activities; Guidance for appropriate selection from the approved set of supported design methods; Set of approved design tools, with guidance on their role and usage in the design process; Criteria and completed evaluations (e.g. checklists) of design effectiveness standards; Documented design criteria attributes (modularity, clarity, reliability, accuracy).




Common Features




SP2.2 0

SP2.3 0

Establish and maintain a technical data package.

1. Determine the number of levels of design and the appropriate level of documentation for each design level. 2. Base detailed design descriptions on the allocated product-component requirements, architecture, and higher level designs. 3. Document the design in the technical data package. 4. Document the rationale for key (i.e., significant effect on cost, schedule, or technical performance) decisions made or defined. 5. Revise the technical data package as necessary.

Complete technical data package.

Description and rationale for the design solution decisions chosen for implementation. · Drawings, lists, specifications, standards, performance requirements, QA provisions, packaging details associated with the component. · Documentation or materials from design reviews at which the technical data package or its components were reviewed. · Product component requirements specifications and related processes. · Interface requirements. · Revisions to work products, standards and procedures reflecting iteration in the product implementation or corrective action. · Functional descriptions and usage scenarios (e.g., states, modes, support, training, manufacturing, disposal, verifications). · Verification criteria · Multiple views of the design hierarchy (customer view, functional view, data view, etc.).

Design comprehensive product-component interfaces in terms of established and maintained criteria.

1. Define interface criteria. 2. Apply the criteria to the interface design alternatives. 3. Document the selected interface designs and the rationale for the selection.

Interface specifications; Interface control documents; Interface specification criteria and templates; Updates to interface specification templates; Revision history and descriptions of changes incorporated to controlled interfaces.

Interface requirements – internal and external to the product. · Interface control and design documents. · Interface specification criteria, templates, and checklists.




Common Features




SP2.4 0

SG 3 Product components, and associated support documentation, are implemented from their designs. 100.0%

SP3.1 1

Evaluate whether the product components should be developed, purchased, or reused based on established criteria.

1. Develop criteria for the reuse of product-component designs. 2. Analyze designs to determine if product components should be developed, reused, or purchased. 3. When purchased or non-developmental (COTS, government off the shelf, and reuse) items are selected, plan for their maintenance.

Criteria for design and component reuse; Make or buy analyses.

Supplier agreements · Reuse component libraries, guidance, and criteria for reuse of non-developmental items (NDI). · Evaluation criteria, rationale, and reports for make-buy analyses and product component selection. · Plans for maintenance, support, and transition of COTS/NDI components. · Product acceptance criteria. · Product operational, maintenance and support concepts.

Implement the designs of the product components.

1. Use effective methods to implement the product components. 2. Adhere to applicable standards and criteria. 3. Conduct peer reviews of the selected product components. 4. Perform unit testing of the product component as appropriate. 5. Revise the product component as necessary.

Implemented design · Product component implementation and support data (e.g., source code, documented data and services, fabricated parts, deployed manufacturing processes, facilities, materials).

· Product component construction methods (e.g. coding, fabrication). · Standards, criteria, and checklists for constructed product components. · Results of peer reviews, inspections, or verifications performed on constructed components. · Unit test plans, procedures, results, and acceptance criteria. · Configuration and change control data for revision to product components.




Common Features




SP3.2 1


GP2.1 CO 1 0

Develop and maintain the end-use documentation.

1. Review the requirements, design, product, and test results to ensure that issues affecting the installation, operation, and maintenance documentation are identified and resolved. 2. Use effective methods to develop the installation, operation, and maintenance documentation. 3. Adhere to the applicable documentation standards. 4. Develop preliminary versions of the installation, operation, and maintenance documentation in early phases of the project life cycle for review by the relevant stakeholders. 5. Conduct peer reviews of the installation, operation, and maintenance documentation. 6. Revise the installation, operation, and maintenance documentation as necessary.

Product training materials; User’s manual; Operator’s manual; Maintenance manual; Documentation for installation, operation, use, maintenance and support of product components; Revision history and maintenance of product documentation.

On-line help · Documentation processes, standards, criteria, and checklists. · Help desk support. · Artifacts related to peer review of applicable documentation. · Site installation, training, and maintenance records.

Establish and maintain an organizational policy for planning and performing the technical solution process.

This policy establishes organizational expectations for addressing the iterative cycle in which product-component solutions are selected, product and product-component designs are developed, and the product-component designs are implemented.






Common Features




GP3.1 AB 1 1

GP2.2 AB 2 0

Establish and maintain the description of a defined technical solution process.



Design Prc exists; but needs to be

enhanced to cover DEV activities

Establish and maintain the plan for performing the technical solution process.

Typically, this plan for performing the technical solution process is a part of the project plan as described in the Project Planning process area.






Common Features




GP2.3 AB 3 0

GP2.4 AB 4 1

GP2.5 AB 5 1

Provide adequate resources for performing the technical solution process, developing the work products, and providing the services of the process.

Special facilities may be required for developing, designing, and implementing solutions to requirements. When necessary, the facilities required for the activities in the Technical Solution process area are developed or purchased. Examples of other resources provided include the following tools: Design specification tools; Simulators and modeling tools; Prototyping tools; Scenario definition and management tools; Requirements tracking tools; Interactive documentation tools.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the technical solution process.



Train the people performing or supporting the technical solution process as needed.

Examples of training topics include the following: Application domain of the product and product components; Design methods; Interface design; Unit testing techniques; Standards (e.g., product, safety, human factors, environmental).






Common Features




GP2.6 DI 1 1

GP2.7 DI 2 1

Place designated work products of the technical solution process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Product, product component, process, service, and interface designs; Technical data packages; Interface design documents; Criteria for design and product-component reuse; Implemented designs (e.g., software code, fabricated product components); User, installation, operation, and maintenance documentation.



Identify and involve the relevant stakeholders of the technical solution process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: Developing alternative solutions and selection criteria; Evolving operational concept and scenarios; Obtaining approval on external interface specifications and design descriptions; Developing the technical data package; Assessing the make, buy, or reuse alternatives for product components; Implementing the design.






Common Features




GP2.8 DI 3 1

GP3.2 DI 4 0

Monitor and control the technical solution process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Cost, schedule, and effort expended for rework; Percentage of requirements addressed in the product or product-component design; Size and complexity of the product, product components, interfaces, and documentation; Defect density of technical solutions work products.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the technical solution process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP2.9 VE 1 0

GP2.10 VE 2 0

Objectively evaluate adherence of the technical solution process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Selecting product-component solutions; Developing product and product-component designs; Implementing product-component designs. Examples of work products reviewed include the following: Technical data packages; Product, product-component, and interface designs; Implemented designs (e.g., software code, fabricated product components); User, installation, operation, and maintenance documentation.



Review the activities, status, and results of the technical solution process with higher level management and resolve issues.






Product Integration (PI)


SG 1 Preparation for product integration is conducted. 0.0%

SP1.1 0

SP1.2 0

Goals and Practices

Common Features




Determine the product-component integration sequence.

1. Identify the product components to be integrated. 2. Identify the product integration verifications to be performed using the definition of the interfaces between the product components. 3. Identify alternative product-component integration sequences. This can include defining the specific tools and test equipment to support the product integration. 4. Select the best integration sequence. 5. Periodically review the product integration sequence and revise as needed. Assess the product integration sequence to ensure that variations in production and delivery schedules have not had an adverse impact on the sequence or compromised the factors upon which earlier decisions were made. 6. Record the rationale for decisions made and deferred.

Product integration sequence; Product integration plan.

Rationale for selecting or rejecting integration sequences · List of components to be integrated · Integration schedules and dependencies · Meetings or presentations at which the plans for product integration are reviewed.

Establish and maintain the environment needed to support the integration of the product components.

1. Identify the requirements for the product integration environment. 2. Identify verification criteria and procedures for the product integration environment. 3. Decide whether to make or buy the needed product integration environment. 4. Develop an integration environment if a suitable environment cannot be acquired. For unprecedented, complex projects, the product integration environment can be a major development. As such, it would involve project planning, requirements development, technical solutions, verification, validation, and risk management. 5. Maintain the product integration environment throughout the project. 6. Dispose of those portions of the environment that are no longer useful.

Verified environment for product integration · Descriptions or configuration of the verified environment for product integration, revised and maintained throughout the project.

Support documentation for the product integration environment · Product integration plan · Product integration test bed (e.g., test equipment, simulators, HW equipment, recording devices).




Common Features




SP1.2 0

SP1.3 0

SG 2 The product-component interfaces, both internal and external, are compatible. 0.0%

Establish and maintain the environment needed to support the integration of the product components.

1. Identify the requirements for the product integration environment. 2. Identify verification criteria and procedures for the product integration environment. 3. Decide whether to make or buy the needed product integration environment. 4. Develop an integration environment if a suitable environment cannot be acquired. For unprecedented, complex projects, the product integration environment can be a major development. As such, it would involve project planning, requirements development, technical solutions, verification, validation, and risk management. 5. Maintain the product integration environment throughout the project. 6. Dispose of those portions of the environment that are no longer useful.

Verified environment for product integration · Descriptions or configuration of the verified environment for product integration, revised and maintained throughout the project.

Support documentation for the product integration environment · Product integration plan · Product integration test bed (e.g., test equipment, simulators, HW equipment, recording devices).

Establish and maintain procedures and criteria for integration of the product components.

1. Establish and maintain product integration procedures for the product components. 2. Establish and maintain criteria for product-component integration and evaluation. 3. Establish and maintain criteria for validation and delivery of the integrated product.

Product integration procedures; Product integration criteria; Revision history of integration procedures and criteria, maintained throughout the project.

Criteria and checklists for product-component readiness, integration, and evaluation · Criteria and checklists for validation, and delivery of the integrated product · Product integration inputs, outputs, expected results, and progress criteria · Incremental build/integration plan and procedures · Reviews or presentations of integration plans, procedures, and criteria · Test readiness reviews.




Common Features




SP2.1 0Review interface descriptions for coverage and completeness.

1. Review interface data for completeness and ensure complete coverage of all interfaces. 2. Ensure that product components and interfaces are marked to ensure easy and correct connection to the joining product component. 3. Periodically review the adequacy of interface descriptions.

Reviewed interface descriptions.

Categories of interfaces (e.g., environmental, physical, functional, mechanical); List of interfaces per category; Mapping of the interfaces to the product components and product integration environment · Interface specifications, Interface control documents (ICDs), Interface design documents (IDDs) · Criteria and checklists for interface reviews · Result of interface reviews (e.g., peer reviews, quality assurance inspections, design reviews, interface control working groups, CCBs, action items to resolve interface issues) · Interface connection markings · Traceability matrices between requirements and interfaces.




Common Features




SP2.2 0

SG 3 Verified product components are assembled and the integrated, verified, and validated product is delivered. 50.0%

Manage internal and external interface definitions, designs, and changes for products and product components.

1. Ensure the compatibility of the interfaces throughout the life of the product. 2. Resolve conflict, noncompliance, and change issues. 3. Maintain a repository for interface data accessible to project participants.

List of agreed-to interfaces defined for each pair of product components, when applicable; Updated interface description or agreement · Interface descriptions and relationships among product components · Interface specifications, Interface control documents (ICDs), Interface design documents (IDDs).

Table of relationships between the product components and the external environment (e.g., main power supply, fastening product, computer bus system); Table of relationships between the different product components; Reports from the interface control working group meetings; Action items for updating interfaces; Application Program Interface (API) · Result of interface reviews (e.g., peer reviews, quality assurance inspections, design reviews, interface control working groups, CCBs, action items to resolve interface issues) · Repository of interface data (e.g. interface data base). · Change requests for revision to interfaces.




Common Features




SP3.1 0

SP3.2 1

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.

1. Track the status of all product components as soon as they become available for integration. 2. Ensure that product components are delivered to the product integration environment in accordance with the product integration sequence and available procedures. 3. Confirm the receipt of each properly identified product component. 4. Ensure that each received product component meets its description. 5. Check the configuration status against the expected configuration. 6. Perform pre-check (for example, by a visual inspection and using basic measures) of all the physical interfaces before connecting product components together.

Acceptance documents for received product components · Verified acceptance test results or inspection report for product components· Discrepancies identified in received product components.

Delivery receipts; Checked packing lists; Exception reports; Waivers · Configuration status reports for product components · Product integration plans and procedures · Criteria and checklists for product component readiness, delivery, integration, and evaluation.

Assemble product components according to the product integration sequence and available procedures.

1. Ensure the readiness of the product integration environment. 2. Ensure that the assembly sequence is properly performed. Record all appropriate information (e.g., configuration status, serial numbers of the product components, types, and calibration date of the meters). 3. Revise the product integration sequence and available procedures as appropriate.

Assembled product or product components.

Product integration sequence · Product integration procedures and criteria · Records indicating performance of the product integration sequence and procedures (e.g., integration reports, completed checklists, configuration audits) · Recorded configuration and assembly information (e.g., identification, configuration status, calibration data). · Integration status and schedule reports (e.g., planned vs. actual components integrated) · Revisions to the integration plans or procedures.




Common Features




SP3.3 0

SP3.4 1


Evaluate assembled product components for interface compatibility.

1. Conduct the evaluation of assembled product components following the product integration sequence and available procedures. 2. Record the evaluation results. Example results include the following: Any adaptation required to the integration procedure; Any change to the product configuration (spare parts, new release); Evaluation procedure deviations.

Exception reports; Interface evaluation reports; Product integration summary reports · Discrepancies detected during checkout of product components · Milestones for completion of integration activities.

Evaluation results (e.g. adaptations, configuration, deviations) · Logbook of product component issues or parameters. · Product integration sequence · Product integration procedures and criteria · Regression testing procedures and results.

Package the assembled product or product component and deliver it to the appropriate customer.

1. Review the requirements, design, product, verification results, and documentation to ensure that issues affecting the packaging and delivery of the product are identified and resolved. 2. Use effective methods to package and deliver the assembled product. 3. Satisfy the applicable requirements and standards for packaging and delivering the product. 4. Prepare the operational site for installation of the product. Preparing the operational site may be the responsibility of the customer or end users. 5. Deliver the product and related documentation and confirm receipt. 6. Install the product at the operational site and confirm correct operation.

Packaged product or product components; Delivery documentation.

Packaging procedures · Transportation and delivery procedures · Packing list · Certification for readiness of the operation site · Site installation surveys and procedures.




Common Features




GP2.1 CO 1 0

GP3.1 AB 1 1

Establish and maintain an organizational policy for planning and performing the product integration process.

This policy establishes organizational expectations for developing product integration sequences, procedures, and an environment, ensuring interface compatibility among product components, assembling the product components, and delivering the product and product components.



Establish and maintain the description of a defined product integration process.






Common Features




GP2.2 AB 2 0

GP2.3 AB 3 0

Establish and maintain the plan for performing the product integration process.

This plan for performing the product integration process addresses the comprehensive planning for all of the specific practices in this process area, from the preparation for product integration all the way through to the delivery of the final product.



Provide adequate resources for performing the product integration process, developing the work products, and providing the services of the process.

Product-component interface coordination may be accomplished with an Interface Control Working Group consisting of people who represent external and internal interfaces. Such groups can be used to elicit needs for interface requirements development. Special facilities may be required for assembling and delivering the product. When necessary, the facilities required for the activities in the Product Integration process area are developed or purchased. Examples of other resources provided include the following tools: Prototyping tools; Analysis tools; Simulation tools; Interface management tools; Assembly tools (e.g., compilers, make files, joining tools, jigs and fixtures).






Common Features




GP2.4 AB 4 0

GP2.5 AB 5 0

GP2.6 DI 1 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the product integration process.



Train the people performing or supporting the product integration process as needed.

Examples of training topics include the following: Application domain; Product integration procedures and criteria; Organization's facilities for integration and assembly; Assembly methods; Packaging standards.



Place designated work products of the product integration process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Acceptance documents for the received product components; Evaluated assembled product and product components; Product integration sequence; Product integration procedures and criteria; Updated interface description or agreement.






Common Features




GP2.7 DI 2 1

GP2.8 DI 3 0

Identify and involve the relevant stakeholders of the product integration process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: Reviewing interface descriptions for completeness; Establishing the product integration sequence; Establishing the product integration procedures and criteria; Assembling and delivering the product and product components; Communicating the results after evaluation; Communicating new, effective product integration processes to give affected people the opportunity to improve their performance.



Monitor and control the product integration process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Product-component integration profile (e.g., product-component assemblies planned and performed, and number of exceptions found); Integration evaluation problem report trends (e.g., number written and number closed); Integration evaluation problem report aging (i.e., how long each problem report has been open).






Common Features




GP3.2 DI 4 0

GP2.9 VE 1 0

GP2.10 VE 2 0

Collect work products, measures, measurement results, and improvement information derived from planning and performing the product integration process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the product integration process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing and maintaining a product integration sequence; Ensuring interface compatibility; Assembling product components and delivering the product. Examples of work products reviewed include the following: Product integration sequence; Product integration procedures and criteria; Acceptance documents for the received product components; Assembled product and product components.



Review the activities, status, and results of the product integration process with higher level management and resolve issues.






Verification (VER)


SG 1 Preparation for verification is conducted. 0.0%

SP1.1 0

SP1.2 0

Goals and Practices

Common Features




Select the work products to be verified and the verification methods that will be used for each.

1. Identify work products for verification. 2. Identify the requirements to be satisfied by each selected work product. 3. Identify the verification methods that are available for use. 4. Define the verification methods to be used for each selected work product. 5. Submit for integration with the project plan the identification of work products to be verified, the requirements to be satisfied, and the methods to be used.

Verification strategy · Project verification plan · Revisions to verification strategy and plan · Revision history.

Commercial off the shelf (COTS) verification strategy. · List of approved verification methods and processes (e.g., inspections, peer reviews, analyses, testing) · Requirements verification methods and verification criteria · Verification environment requirements and support tools; Verification procedures; Verification criteria · Verification criteria such as accuracy, precision, throughput, size, etc.

Establish and maintain the environment needed to support verification.

1. Identify verification environment requirements. 2. Identify verification resources that are available for reuse and modification. 3. Identify verification equipment and tools. 4. Acquire verification support equipment and an environment, such as test equipment and software.

Verification support equipment; Verification environment.

· Purchase orders of capital equipment, resource plans including hardware and software (simulators, emulators, data reduction tools, interfaces with other systems, etc.). · Identification of reused and modified resources.




Common Features




SP1.3 0

SG 2 Peer reviews are performed on selected work products. 0.0%

SP2.1 0

Establish and maintain verification procedures and criteria for the selected work products.

1. Generate the set of comprehensive, integrated verification procedures for work products and any commercial off-the-shelf products, as necessary. 2. Develop and refine the verification criteria when necessary. 3. Identify the expected results, any tolerances allowed in observation, and other criteria for satisfying the requirements. 4. Identify any equipment and environmental components needed to support verification.

Verification plan, with detailed activities, schedules, resources.

List of work products and COTS products subject to verification · Verification criteria · Verification procedures · Expected results and tolerances identified · Equipment and environmental components identified.

Prepare for peer reviews of selected work products.

1. Determine what type of peer review will be conducted. 2. Define requirements for collecting data during the peer review. 3. Establish and maintain entry and exit criteria for the peer review. 4. Establish and maintain criteria for requiring another peer review. 5. Establish and maintain checklists to ensure that the work products are reviewed consistently. 6. Develop a detailed peer review schedule, including the dates for peer review training and for when materials for peer reviews will be available. 7. Ensure that the work product satisfies the peer review entry criteria prior to distribution. 8. Distribute the work product to be reviewed and its related information to the participants early enough to enable participants to adequately prepare for the peer review. 9. Assign roles for the peer review as appropriate. 10. Prepare for the peer review by reviewing the work product prior to conducting the peer review.

Peer review schedule; Re-review criteria; Selected work products to be reviewed · Peer review plans, processes, and schedules.

Peer review checklis; Entry and exit criteria for work products; Peer review training material · Description of method chosen for the peer review such as inspections, walkthroughs, etc. · Peer review data package · Peer review process.




Common Features




SP2.2 0

SP2.3 0

SG 3 Selected work products are verified against their specified requirements. 0.0%

SP3.1 0

Conduct peer reviews on selected work products and identify issues resulting from the peer review.

1. Perform the assigned roles in the peer review. 2. Identify and document defects and other issues in the work product. 3. Record the results of the peer review, including the action items. 4. Collect peer review data. 5. Identify action items and communicate the issues to relevant stakeholders. 6. Conduct an additional peer review if the defined criteria indicate the need. 7. Ensure that the exit criteria for the peer review are satisfied.

Peer review results. · Identified defects; Peer review issues. · Action items; Peer review data. · Data summarizing the conduct and results of the peer review.

· Schedules showing peer reviews and re-review. · Peer review data repository · Completed peer review checklists.

Analyze data about preparation, conduct, and results of the peer reviews.

1. Record data related to the preparation, conduct, and results of the peer reviews. 2. Store the data for future reference and analysis. 3. Protect the data to ensure that peer review data are not used inappropriately. Examples of inappropriate use of peer review data include using data to evaluate the performance of people and using data for attribution. 4. Analyze the peer review data.

Peer review data; Data recorded to reflect the conduct of the review (preparation, conduct and results) · Documented peer review analysis results.

Peer review action items; Peer review data repository · Peer review metrics and analysis · List of action items produced during peer reviews.

Perform verification on the selected work products.

1. Perform verification of selected work products against their requirements. 2. Record the results of verification activities. 3. Identify action items resulting from verification of work products. 4. Document the “as-run” verification method and the deviations from the available methods and procedures discovered during its performance.

Verification results; Verification results such as · Test results· Peer review results; Verification reports · (trouble reports, corrective action reports, presentations, etc.; “As Verified” procedures log.

Demonstrations · Action items identified · Requirements.




Common Features




SP3.2 0


GP2.1 CO 1 0

Analyze the results of all verification activities and identify corrective action.

1. Compare actual results to expected results. 2. Based on the established verification criteria, identify products that have not met their requirements or identify problems with the methods, procedures, criteria, and verification environment. 3. Analyze the verification data on defects. 4. Record all results of the analysis in a report. 5. Use verification results to compare actual measurements and performance to technical performance parameters. 6. Provide information on how defects may be resolved (including verification methods, criteria, and verification environment) and formalize it in a plan.

Analysis report (such as statistics on performances, causal analysis of non-conformances, comparison of the behavior between the product and models, trends, etc.; Corrective actions to verification methods, criteria, and/or infrastructure.

Trouble reports; Method, criteria, and infrastructure change requests.

Establish and maintain an organizational policy for planning and performing the verification process.

This policy establishes organizational expectations for establishing and maintaining verification methods, procedures, criteria, verification environment, performing peer reviews, and verifying selected work products.






Common Features




GP3.1 AB 1 0

GP2.2 AB 2 0

Establish and maintain the description of a defined verification process.



Establish and maintain the plan for performing the verification process.

Typically, this plan for performing the verification process is included in (or referenced by) the project plan, which is described in the Project Planning process area.






Common Features




GP2.3 AB 3 0

GP2.4 AB 4 0

Provide adequate resources for performing the verification process, developing the work products, and providing the services of the process.

Special facilities may be required for verifying selected work products. When necessary, the facilities required for the activities in the Verification process area are developed or purchased. Certain verification methods may require special tools, equipment, facilities, and training (e.g., peer reviews may require meeting rooms and trained moderators; certain verification tests may require special test equipment and people skilled in the use of the equipment). Examples of other resources provided include the following tools: Test management tools; Test-case generators; Test-coverage analyzers; Simulators.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the verification process.






Common Features




GP2.5 AB 5 0

GP2.6 DI 1 0

GP2.7 DI 2 0

Train the people performing or supporting the verification process as needed.

Examples of training topics include the following: Application domain; Verification principles, standards, and methods (e.g., analysis, demonstration, inspection, test); Verification tools and facilities; Peer review preparation and procedures; Meeting facilitation.



Place designated work products of the verification process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Verification procedures and criteria; Peer review training material; Peer review data; Verification reports.



Identify and involve the relevant stakeholders of the verification process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: Selecting work products and methods for verification; Establishing verification procedures and criteria; Conducting peer reviews; Assessing verification results and identifying corrective action.






Common Features




GP2.7 DI 2 0

GP2.8 DI 3 0

GP3.2 DI 4 0

Identify and involve the relevant stakeholders of the verification process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include the following: Selecting work products and methods for verification; Establishing verification procedures and criteria; Conducting peer reviews; Assessing verification results and identifying corrective action.



Monitor and control the verification process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Verification profile (e.g., the number of verifications planned and performed, and the defects found; perhaps categorized by verification method or type); Number of defects detected by defect category; Verification problem report trends (e.g., number written and number closed); Verification problem report status (i.e., how long each problem report has been open).



Collect work products, measures, measurement results, and improvement information derived from planning and performing the verification process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP3.2 DI 4 0

GP2.9 VE 1 0

GP2.10 VE 2 0

Collect work products, measures, measurement results, and improvement information derived from planning and performing the verification process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the verification process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Selecting work products for verification; Establishing and maintaining verification procedures and criteria; Performing peer reviews; Verifying selected work products. Examples of work products reviewed include the following: Verification procedures and criteria; Peer review checklists; Verification reports.



Review the activities, status, and results of the verification process with higher level management and resolve issues.






Validation (VAL)


SG 1 Preparation for validation is conducted. 66.7%

SP1.1 0

SP1.2 1

Goals and Practices

Common Features




Select products and product components to be validated and the validation methods that will be used for each.

1. Identify the key principles, features, and phases for product or product-component validation throughout the life of the project. 2. Determine which categories of user needs (operational, maintenance, training, or support) are to be validated. 3. Select the product and product components to be validated. 4. Select the evaluation methods for product or product-component validation. 5. Review the validation selection, constraints, and methods with relevant stakeholders.

Validation strategy · Revisions to validation strategy.

Requirements defined for a realistic validation environment (includes operation, maintenance, training and support delivered with product) · Evaluation criteria defined. · Stakeholder reviews conducted · Validation plans and procedures.

Establish and maintain the environment needed to support validation.

1. Identify validation environment requirements. 2. Identify customer-supplied products. 3. Identify reuse items. 4. Identify test equipment and tools. 5. Identify validation resources that are available for reuse and modification. 6. Plan the availability of resources in detail.

Validation environment; Revision history.

Purchase orders of capital equipment, resource plans including hardware and software (test tools, simulators, temporary software, recording tools, interfaces with other systems, computing environments, customer-supplied products, etc.). · Resource plan, including reuse of existing resources. · Validation procedures · Validation criteria.

Separate test environement exists




Common Features




SP1.3 1

SG 2 The product or product components are validated to ensure that they are suitable for use in their intended operating environment. 50.0%

SP2.1 1

Establish and maintain procedures and criteria for validation.

1. Review the product requirements to ensure that issues affecting validation of the product or product component are identified and resolved. 2. Document the environment, operational scenario, procedures, inputs, outputs, and criteria for the validation of the selected product or product component. 3. Assess the design as it matures in the context of the validation environment to identify validation issues.

Validation procedures; Validation criteria.

Test and evaluation procedures for maintenance, training, and support; Product requirements · Acceptance test cases · Documented environment, operational scenario, inputs, outputs and expected results. · Design revisions.

Perform validation on the selected products and product components.

To be acceptable to users, a product or product component must perform as expected in its intended operational environment. Validation activities are performed and the resulting data are collected according to the established methods, procedures, and criteria. The as-run validation procedures should be documented and the deviations occurring during the execution should be noted, as appropriate.

Validation reports; Validation results; As-run procedures log.

Validation cross-reference matrix; Operational demonstrations; Documented validation environment · Data collected from performing validation procedures · List of deviations encountered.




Common Features




SP2.2 0


GP2.1 CO 1 1

Analyze the results of the validation activities and identify issues.

1. Compare actual results to expected results. 2. Based on the established validation criteria, identify products and product components that do not perform suitably in their intended operating environments, or identify problems with the methods, criteria, and/or environment. 3. Analyze the validation data for defects. 4. Record the results of the analysis and identify issues. 5. Use validation results to compare actual measurements and performance to intended use or operational need.

Validation deficiency reports; Validation issues · Analysis reports · Validation results.

Procedure change request · Validation evaluation criteria · Comparison of actual vs. expected results (e.g., measurements and performance data).

Establish and maintain an organizational policy for planning and performing the validation process.

This policy establishes organizational expectations for selecting products and product components for validation; for selecting validation methods; and for establishing and maintaining validation procedures, criteria, and environments that ensure the products and product components satisfy user needs in their intended operating environment.






Common Features




GP3.1 AB 1 1

GP2.2 AB 2 0

Establish and maintain the description of a defined validation process.



Establish and maintain the plan for performing the validation process.

Typically, this plan for performing the validation process is included in (or referenced by) the project plan, which is described in the Project Planning process area.






Common Features




GP2.3 AB 3 1

GP2.4 AB 4 1

GP2.5 AB 5 0

Provide adequate resources for performing the validation process, developing the work products, and providing the services of the process.

Special facilities may be required for validating the product or product components. When necessary, the facilities required for validation are developed or purchased. Examples of other resources provided include the following tools: Test management tools; Test-case generators; Test-coverage analyzers; Simulators; Load, stress, and performance tools.



Assign responsibility and authority for performing the process, developing the work products, and providing the services of the validation process.



Train the people performing or supporting the validation process as needed.

Examples of training topics include the following: Application domain; Validation principles, standards, and methods; Intended-use environment.






Common Features




GP2.6 DI 1 1

GP2.7 DI 2 1

Place designated work products of the validation process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Lists of products and product components selected for validation; Validation methods, procedures, and criteria; Validation reports.



Identify and involve the relevant stakeholders of the validation process as planned.

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. Examples of activities for stakeholder involvement include Selecting the products and product components to be validated; Establishing the validation methods, procedures, and criteria; Reviewing results of product and product-component validation and resolving issues; Resolving issues with the customers or end users. Issues with the customers or end users are resolved particularly when there are significant deviations from their baseline needs for the following: Waivers on the contract or agreement (what, when, and for which products, services, or manufactured products); Additional in-depth studies, trials, tests, or evaluations; Possible changes in the contracts or agreements.






Common Features




GP2.8 DI 3 1

GP3.2 DI 4 0

Monitor and control the validation process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of validation activities completed (planned versus actual); Validation problem report trends (e.g., number written and number closed); Validation problem report aging (i.e., how long each problem report has been open).



Collect work products, measures, measurement results, and improvement information derived from planning and performing the validation process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP2.9 VE 1 0

GP2.10 VE 2 0

Objectively evaluate adherence of the validation process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Selecting the products and product components to be validated; Establishing and maintaining validation methods, procedures, and criteria; Validating products or product components. Examples of work products reviewed include the following: Validation methods, procedures, and criteria.



Review the activities, status, and results of the validation process with higher level management and resolve issues.







SG 1 Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed. 33.3%

SP1.1 1

SP1.2 0

Organizational Process Focus (OPF)

Goals and Practices

Common Features




Establish and maintain the description of the process needs and objectives for the organization.

1. Identify the policies, standards, and business objectives that are applicable to the organization's processes. 2. Examine relevant process standards and models for best practices. 3. Determine the organization’s process performance objectives. 4. Define the essential characteristics of the organization’s processes. 5. Document the organization’s process needs and objectives. 6. Revise the organization’s process needs and objectives as needed.

Organization’s process needs and objectives · Revisions to the organization’s process and objectives (e.g., revised objectives, reviews, etc.).

Organizational business needs, objectives, and constraints · Organizational process performance objectives (e.g., time to market, product quality, productivity) · Process and product standards and guidelines (notation, level of detail, etc.) · Characterization of current organization processes.

Appraise the processes of the organization periodically and as needed to maintain an understanding of their strengths and weaknesses.

1. Obtain sponsorship of the process appraisal from senior management. 2. Define the scope of the process appraisal. 3. Determine the method and criteria for process appraisal. 4. Plan, schedule, and prepare for the process appraisal. 5. Conduct the process appraisal. 6. Document and deliver the appraisal’s activities and findings.

Assessment findings that address strengths and weaknesses of the organization's processes

Plans for the organization's process assessments; Improvement recommendations for the organization's processes · Assessment records or reports (plan, scope, participants, interview schedules, list of artifacts examined, etc.) · Process improvement progress records (e.g., metrics, trends, analyses).




Common Features




SP1.3 0

SG 2 Process actions that address improvements to the organization’s processes and process assets are planned and implemented. 0.0%

SP2.1 0

SP2.2 Implement process action plans. 0

SG 3 50.0%

SP3.1 1

Identify improvements to the organization's processes and process assets.

1. Determine candidate process improvements. 2. Prioritize the candidate process improvements. 3. Identify and document the process improvements that will be implemented. 4. Revise the list of planned process improvements to keep it current.

Analysis of candidate process improvements; Identification of improvements for the organization's processes · Prioritized list of planned process improvements.

Measurements and analysis of processes · Reports of process performance · Reviews of lessons learned · Meeting minutes from process improvement related reviews and planning sessions · Documented criteria for prioritization of improvement opportunities · Change request and control process (e.g., CCB) for review and disposition of improvement proposals.

Establish and maintain process action plans to address improvements to the organization's processes and process assets.

The organizational process assets are deployed across the organization and process-related experiences are incorporated into the organizational process assets.

Deploy organizational process assets across the organization.

1. Identify strategies, approaches, and actions to address the identified process improvements. New, unproven, and major changes are piloted before they are incorporated into normal use. 2. Establish process action teams to implement the actions. The teams and people performing the process-improvement actions are called “process action teams.” Process action teams typically include process owners and those who perform the process. 3. Document process action plans. 4. Review and negotiate process action plans with relevant stakeholders. 5. Review process action plans as necessary.

Organization's approved process action plans · Review and revision of the organization’s approved process action plans (e.g., revised objectives, reviews, etc.).

Strategies for implementation of improvements · Documented infrastructure for process improvement with roles and responsibilities (e.g., management, process owners, process group, action teams, practitioners) · Results of stakeholder reviews of process action plans · Revised action plans· Piloting of proposed process improvements.




Common Features




SP3.2 1

SP3.3 0

SP3.4 0


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

1. Make process action plans readily available to relevant stakeholders. 2. Negotiate and document commitments among the process action teams and revise their process action plans as necessary. 3. Track progress and commitments against process action plans. 4. Conduct joint reviews with the process action teams and relevant stakeholders to monitor the progress and results of the process actions. 5. Plan pilots needed to test selected process improvements. 6. Review the activities and work products of process action teams. 7. Identify, document, and track to closure issues in implementing process action plans. 8. Ensure that the results of implementing process action plans satisfy the organization’s process-improvement objectives.

Status and results of implementing process action plans.

Commitments among the various process action teams · Negotiated commitments and revisions to process action plans; Plans for pilots · Process improvement status reviews and briefings (management reviews, technical reviews) · Records of effort and expenditure associated with implementation (e.g., metrics, analyses, progress reports) · Issues identified from implementation of process action plans · Implementation issue identification and resolution records · Alignment of process improvements with organizational objectives.

Monitor the implementation of the organization’s set of standard processes and use of process assets on all projects

Incorporate process-related work products, measures, and improvement information derived from planning and performing the process into the organizational process assets




Common Features




GP2.1 CO 1

GP3.1 AB 1

Establish and maintain an organizational policy for planning and performing the organizational process focus process.

This policy establishes organizational expectations for determining process-improvement opportunities for the processes being used and for planning and implementing process-improvement activities across the organization.



Establish and maintain the description of a defined organizational process focus process.






Common Features




GP2.2 AB 2

GP2.3 AB 3

Establish and maintain the plan for performing the organizational process focus process.

The plan for performing the organizational process focus process, which is often called “the process-improvement plan,” differs from the process action plans described in specific practices in this process area. The plan called for in this generic practice addresses the comprehensive planning for all of the specific practices in this process area, from the establishment of organizational process needs all the way through to the incorporation of process-related experiences into the organizational process assets.



Provide adequate resources for performing the organizational process focus process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Database management systems; Process-improvement tools; Web page builders and browsers; Groupware; Quality-improvement tools (e.g., quality-improvement tools, cause-and-effect diagrams, affinity diagrams, Pareto charts).


[Tools: DBMS; process improvement tools; web page builders and browsers; groupware; quality improvement tools (e.g., cause-and-effect diagrams, affinity diagrams, Pareto charts)]; Budgets, resources, and staff allocated to process assessment, improvement, and deployment of process action plans; People: process group staffing level and percentage relative to the engineering population; organizational steering group responsible for providing long-term commitment and resources; Funding: Percentage of the overhead budget allocated to process improvement; provision of engineering staff for process action teams.




Common Features




GP2.4 AB 4

GP2.5 AB 5

GP2.6 DI 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational process focus process.

Two groups are typically established and assigned responsibility for process improvement: (1) a management steering committee for process improvement to provide senior-management sponsorship; and (2) a process group to facilitate and manage the process-improvement activities.



Train the people performing or supporting the organizational process focus process as needed.

Examples of training topics include the following: CMMI and other process and process-improvement reference models; Planning and managing process improvement; Tools, methods, and analysis techniques; Process modeling; Facilitation techniques; Change management.



Place designated work products of the organizational process focus process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Process-improvement proposals; Organization’s approved process action plans; Training materials for deploying organizational process assets; Plans for the organization’s process appraisals.






Common Features




GP2.7 DI 2

GP2.8 DI 3

Identify and involve the relevant stakeholders of the organizational process focus process as planned.

Examples of activities for stakeholder involvement include the following: Coordinating and collaborating on process-improvement activities with process owners, those that are or will be performing the process, and support organizations (e.g., training staff and quality assurance representatives); Establishing the organizational process needs and objectives; Appraising the organization’s processes; Implementing process action plans; Coordinating and collaborating on the execution of pilots to test selected improvements; Deploying organizational process assets and changes to organizational process assets; Communicating the plans, status, activities, and results related to the implementation of process-improvement activities.



Monitor and control the organizational process focus process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of process-improvement proposals submitted, accepted, or implemented; CMMI maturity level or capability level.






Common Features




GP3.2 DI 4

GP2.9 VE 1

GP2.10 VE 2

Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process focus process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the organizational process focus process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Determining process-improvement opportunities; Planning and coordinating process-improvement activities. Examples of work products reviewed include the following: Process-improvement plans; Process action plans; Plans for the organization’s process appraisals.



Review the activities, status, and results of the organizational process focus process with higher level management and resolve issues.

These reviews are typically in the form of a briefing presented to the management steering committee by the process group and the process action teams. Examples of presentation topics include the following: Status of improvements being developed by process action teams; Results of pilots; Results of deployments; Schedule status for achieving significant milestones (e.g., readiness for an appraisal, or progress towards achieving a targeted organizational maturity level or capability level profile).






SG 1 A set of organizational process assets is established and maintained. 40.0%

SP1.1 1

SP1.2

Organizational Process Definition (OPD)

Goals and Practices

Common Features




Establish and maintain the organization's set of standard processes.

1. Decompose each standard process into constituent process elements to the detail needed to understand and describe the process. 2. Specify the critical attributes of each process element. 3. Specify the relationships of the process elements. 4. Ensure that the organization's set of standard processes adheres to applicable policies; process standards and models; and product standards. 5. Ensure that the organization’s set of standard processes satisfies the process needs and objectives of the organization. 6. Ensure that there is appropriate integration among the processes that are included in the organization’s set of standard processes. 7. Document the organization's set of standard processes. 8. Conduct peer reviews on the organization's set of standard processes. 9. Revise the organization's set of standard processes as necessary.

Organization's set of standard processes · Revisions to the organization’s set of standard processes (e.g., revised processes, reviews, etc.).

Process architectures describing relationships among process elements · Process element attributes (e.g., inputs, outputs, entry/exit criteria, roles, interfaces).· Templates and descriptions for process assets · Process and product standards · Process for development, review, and revision of organizational standard processes and assets · Results of peer reviews of the organization’s set of standard processes.

Establish and maintain descriptions of the life-cycle models approved for use in the organization.

1. Select life-cycle models based on the needs of projects and the organization. 2. Document the descriptions of the life-cycle models. The life-cycle models may be documented as part of the organization's standard process descriptions or they may be documented separately. 3. Conduct peer reviews on the life-cycle models. 4. Revise the descriptions of the life-cycle models as necessary.

Descriptions of life-cycle models · Revisions to the organization’s set of life-cycle process models (e.g., revised models, reviews, etc.).

Descriptions of life-cycle models]· Revisions to the organization’s set of life-cycle process models (e.g., revised models, reviews, etc.)




Common Features




SP1.3

SP1.4 0

Establish and maintain the tailoring criteria and guidelines for the organization's set of standard processes.

1. Specify the selection criteria and procedures for tailoring the organization's set of standard processes. 2. Specify the standards for documenting the defined processes. 3. Specify the procedures for submitting and obtaining approval of waivers from the requirements of the organization's set of standard processes. 4. Document the tailoring guidelines for the organization's set of standard processes. 5. Conduct peer reviews on the tailoring guidelines. 6. Revise the tailoring guidelines as necessary.

Tailoring criteria and guidelines for the organization's set of standard processes · Revisions to the organization’s tailoring criteria and guidelines (e.g., revised guidelines, reviews, etc.).

Project Defined Processes · Guidelines, and standards for documenting the defined processes. · Process compliance review checklists. · Waiver processes, forms, and criteria.

Establish and maintain the organization’s measurement repository.

1. Determine the organization's needs for storing, retrieving, and analyzing measurements. 2. Define a common set of process and product measures for the organization's set of standard processes. 3. Design and implement the measurement repository. 4. Specify the procedures for storing, updating, and retrieving measures. 5. Conduct peer reviews on the definitions of the common set of measures and the procedures for storing and retrieving measures. 6. Enter the specified measures into the repository. 7. Make the contents of the measurement repository available for use by the organization and projects as appropriate. 8. Revise the measurement repository, common set of measures, and procedures as the organization’s needs change.

Definition of the common set of product and process measures for the organization's set of standard processes; Organization's measurement repository (i.e., the repository structure and support environment)' Organizational measurement data · Revisions to the organization’s measurement repository (e.g., revised measures, collected measures, reviews, etc.).

Definition of the common set of product and process measures for the organization's set of standard processes; Organization's measurement repository (i.e., the repository structure and support environment); Organizational measurement data · Revisions to the organization’s measurement repository (e.g., revised measures, collected measures, reviews, etc.).




Common Features




SP1.5 1

SP1.6


GP2.1 CO 1

Establish and maintain the organization's process asset library.

1. Design and implement the organization’s process asset library, including the library structure and support environment. 2. Specify the criteria for including items in the library. The items are selected based primarily on their relationship to the organization's set of standard processes. 3. Specify the procedures for storing and retrieving items. 4. Enter the selected items into the library and catalog them for easy reference and retrieval. 5. Make the items available for use by the projects. 6. Periodically review the use of each item and use the results to maintain the library contents. 7. Revise the organization’s process asset library as necessary.

Organization's library to store the process-related documentation (i.e., the library structure and support environment) · Process Asset Library (PAL) · Revisions to the organization’s library of process-related assets (e.g., revised library and assets, reviews, etc.).

Best examples of process-related documentation items · Collection of best practices; Catalog of process documentation items · Criteria for adding items to library.

Establish and maintain work environment standards

Establish and maintain an organizational policy for planning and performing the organizational process definition process.

This policy establishes organizational expectations for establishing and maintaining a set of standard processes for use by the organization and making organizational process assets available across the organization.






Common Features




GP3.1 AB 1

GP2.2 AB 2

Establish and maintain the description of a defined organizational process definition process.



Establish and maintain the plan for performing the organizational process definition process.

Typically, this plan for performing the organizational process definition process is a part of the organization’s process-improvement plan.






Common Features




GP2.3 AB 3

Provide adequate resources for performing the organizational process definition process, developing the work products, and providing the services of the process.

A process group typically manages the organizational process definition activities. This group is typically staffed by a core of professionals whose primary responsibility is coordinating organizational process improvement. This group is supported by process owners and people with expertise in various disciplines such as the following: Project management; The appropriate engineering disciplines; Configuration management; Quality assurance. Examples of other resources provided include the following tools: Database management systems; Process modeling tools; Web page builders and browsers.


[Tools: DBMS; process improvement tools; web page builders and browsers; groupware; quality improvement tools (e.g., cause-and-effect diagrams, affinity diagrams, Pareto charts)]; Budgets, resources, and staff allocated to process assessment, improvement, and deployment of process action plans; People: process group staffing level and percentage relative to the engineering population; organizational steering group responsible for providing long-term commitment and resources; Funding: Percentage of the overhead budget allocated to process improvement; provision of engineering staff for process action teams; Tools: [DBMS, process modeling tools, web page builders and browsers]; Tools: measurement repository; process asset library; Org chart depicting role and reporting of the process group and process owners, with representation across disciplines.; Intranet containing published process documentation and assets.




Common Features




GP2.4 AB 4

GP2.5 AB 5

GP2.6 DI 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational process definition process.



Train the people performing or supporting the organizational process definition process as needed.

Examples of training topics include the following: CMMI and other process and process-improvement reference models; Planning, managing, and monitoring processes; Process modeling and definition; Developing a tailorable standard process.



Place designated work products of the organizational process definition process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Organization’s set of standard processes; Descriptions of the life-cycle models; Tailoring guidelines for the organization’s set of standard processes; Definitions of the common set of product and process measures; Organization’s measurement data.






Common Features




GP2.7 DI 2

GP2.8 DI 3

Identify and involve the relevant stakeholders of the organizational process definition process as planned.

Examples of activities for stakeholder involvement include the following: Reviewing the organization’s set of standard processes; Reviewing the organization’s life-cycle models; Resolving issues on the tailoring guidelines; Assessing the definitions of the common set of process and product measures.



Monitor and control the organizational process definition process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Percentage of projects using the process architectures and process elements of the organization's set of standard processes; Defect density of each process element of the organization’s set of standard processes.






Common Features




GP3.2 DI 4

GP2.9 VE 1

GP2.10 VE 2

Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process definition process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the organizational process definition process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing organizational process assets; Examples of work products reviewed include the following: Organization’s set of standard processes; Descriptions of the life-cycle models; Tailoring guidelines for the organization’s set of standard processes; Organization’s measurement data.



Review the activities, status, and results of the organizational process definition process with higher level management and resolve issues.






Organizational Training (OT)

Goal or Practice Statement Amplifying Information SEI PII Direct Artifacts Comments

SG 1 A training capability that supports the organization's management and technical roles is established and maintained. 50.0%

SP1.1 1

SP1.2 1

SP1.3 0

Goals and Practices

Common Features




Establish and maintain the strategic training needs of the organization.

1. Analyze the organization's strategic business objectives and process-improvement plan to identify potential future training needs. 2. Document the strategic training needs of the organization. 3. Determine the roles and skills needed to perform the organization's set of standard processes. 4. Document the training needed to perform the roles in the organization's set of standard processes. 5. Revise the organization’s strategic needs and required training as necessary.

Training needs · Review and revision history of the strategic training needs of the organization.

Assessment analysis · Organization’s strategic business plan or process improvement plan. · Identification of roles and skills needed · List of required training courses needed.

Determine which training needs are the responsibility of the organization and which will be left to the individual project or support group

1. Analyze the training needs identified by the various projects and support groups. 2. Negotiate with the various projects and support groups on how their specific training needs will be satisfied. 3. Document the commitments for providing training support to the projects and support groups.

Training commitments · A list of the training to be provided by the organization.

Common project and support group training needs · Documented lists of special training needs required by projects or support groups. · Rationale for acceptance or rejection of training proposals.

Establish and maintain an organizational training tactical plan.

1. Establish plan content. 2. Establish commitments to the plan. 3. Revise plan and commitments as necessary.

Organizational training tactical plan · Adjustments or revision history of the organizational training tactical plan.

§ Lists of training courses, prerequisites, skills, schedules, funding, roles, and responsibilities § Reviews or status reports tracking implementation progress (e.g., schedule and remaining budget) of the organizational training tactical plan.



Goal or Practice Statement Amplifying Information SEI PII Direct Artifacts CommentsGoals and Practices

Common Features




SP1.4 0

SG 2 Training necessary for individuals to perform their roles effectively is provided. 100.0%

SP2.1 1

SP2.2 1

Establish and maintain training capability to address organizational training needs.

1. Select the appropriate approaches to satisfy specific organizational training needs. 2. Determine whether to develop training materials internally or acquire them externally. 3. Develop or obtain training materials. 4. Develop or obtain qualified instructors. 5. Describe the training in the organization's training curriculum. 6. Revise the training materials and supporting artifacts as necessary.

Training materials and supporting artifacts § Analysis and revisions of training materials and resources.

· Organization’s training curriculum and course descriptions · Analysis of whether to acquire training or provide in-house · Criteria for instructor qualifications · Periodic reviews of training capability and resources.

Deliver the training following the organizational training tactical plan.

1. Select the people who will receive the training. 2. Schedule the training, including any resources, as necessary (e.g., facilities and instructors). 3. Conduct the training. 4. Track the delivery of training against the plan.

Delivered training course · Training records (schedule, instructor, attendance).

Training delivery reports or metrics (e.g., planned vs. actual) · Organization’s training plan · Training curriculum, based on assigned role · Prioritized list of pending training attendees.

Establish and maintain records of the organizational training.

1. Keep records of all students who successfully complete each training course or other approved training activity as well as those who are unsuccessful. 2. Keep records of all staff who have been waived from specific training. 3. Keep records of all students who successfully complete their designated required training. 4. Make training records available to the appropriate people for consideration in assignments.

Training records · Attendance records and approved waivers.

Training updates to the organizational repository · Skills matrix · Training repository · Training metrics or reports · Training waiver procedures and criteria.




Common Features




SP2.3 1


GP2.1 CO 1 1

Assess the effectiveness of the organization’s training program.

1. Assess in-progress or completed projects to determine whether staff knowledge is adequate for performing project tasks. 2. Provide a mechanism for assessing the effectiveness of each training course with respect to established organizational, project, or individual learning (or performance) objectives. 3. Obtain student evaluations of how well training activities met their needs.

Training program performance assessments · Reviews, analyses, or reports of organizational training effectiveness and alignment with organization objectives.

Training effectiveness surveys; Instructor evaluation forms; Training examinations § Student evaluation feedback forms (of how well training met their needs) § Metrics or analysis summarizing consolidated training results § Revised course materials, methods, or curriculum as a result of training feedback.

Establish and maintain an organizational policy for planning and performing the organizational training process.

This policy establishes organizational expectations for identifying the strategic training needs of the organization, and providing that training.






Common Features




GP3.1 AB 1 Prc is fine 1

GP2.2 AB 2 0

Establish and maintain the description of a defined organizational training process.



Establish and maintain the plan for performing the organizational training process.

This plan for performing the organizational training process differs from the tactical plan for organizational training described in a specific practice in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from the establishment of strategic training needs all the way through to the assessment of the effectiveness of the organizational training effort. In contrast, the organizational training tactical plan called for in the specific practice would address the periodic planning for the delivery of individual training offerings.






Common Features




GP2.3 AB 3 1

GP2.4 AB 4 1

Provide adequate resources for performing the organizational training process, developing the work products, and providing the services of the process.

Examples of people (full or part time, internal or external), and skills needed include the following: Subject matter experts; Curriculum designers; Instructional designers; Instructors; Training administrators. Special facilities may be required for training. Examples of other resources provided include the following tools: Instruments for analyzing training needs; Workstations to be used for training; Instructional design tools; Packages for developing presentation materials.


Funding: budget allocated to training and development; [Staff (full/part-time, internal/external): subject matter experts; curriculum designers; instruction designers; instructors; training administrators]; [Facilities required for training]; e.g., training rooms, labs, instructional resources; [Tools: training needs analysis tools; workstations; instructional design tools; packages for developing presentation materials]; Tools: training repository; training records database; skills database; collaborative environments; bulletin boards.

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational training process.






Common Features




GP2.5 AB 5 1

GP2.6 DI 1 0

GP2.7 DI 2 1

Train the people performing or supporting the organizational training process as needed.

Examples of training topics include the following: Knowledge and skills needs analysis; Instructional design; Instructional techniques (e.g., train the trainer); Refresher training on subject matter.



Place designated work products of the organizational training process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Organizational training tactical plan; Training records; Training materials and supporting artifacts; Instructor evaluation forms.



Identify and involve the relevant stakeholders of the organizational training process as planned.

Examples of activities for stakeholder involvement include the following: Establishing a collaborative environment for discussion of training needs and training effectiveness to ensure that the organization’s training needs are met; Identifying training needs; Reviewing the organizational training tactical plan; Assessing training effectiveness.






Common Features




GP2.7 DI 2 1

GP2.8 DI 3 1

GP3.2 DI 4 1

Identify and involve the relevant stakeholders of the organizational training process as planned.

Examples of activities for stakeholder involvement include the following: Establishing a collaborative environment for discussion of training needs and training effectiveness to ensure that the organization’s training needs are met; Identifying training needs; Reviewing the organizational training tactical plan; Assessing training effectiveness.



Monitor and control the organizational training process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of training courses delivered (e.g., planned versus actual); Post-training evaluation ratings; Training program quality survey ratings.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational training process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP3.2 DI 4 1

GP2.9 VE 1 0

GP2.10 VE 2 0

Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational training process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the organizational training process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Identifying training needs and making training available; Providing necessary training. Examples of work products reviewed include the following: Organizational training tactical plan; Training materials and supporting artifacts; Instructor evaluation forms.



Review the activities, status, and results of the organizational training process with higher level management and resolve issues.







SG 1 The project is conducted using a defined process that is tailored from the organization's set of standard processes. 0.0%

SP1.1

SP1.2

Integrated Product Management (IPM) for IPPD

Goals and Practices

Common Features




Establish and maintain the project's defined process.

1. Select a life-cycle model from those available from the organizational process assets. 2. Select the standard processes from the organization's set of standard processes that best fit the needs of the project. 3. Tailor the organization's set of standard processes and other organizational process assets according to the tailoring guidelines to produce the project’s defined process. 4. Use other artifacts from the organization's process asset library as appropriate. 5. Document the project's defined process. 6. Conduct peer reviews of the project's defined process. 7. Revise the project's defined process as necessary.

The project's defined process · Revision history for the project’s defined process.

Organizational standard processes. · Defined criteria (e.g., process) that describe how the project’s defined process is to be established and maintained. · Set of organization standard life cycle model descriptions. · Tailoring guidelines for producing the project’s defined process. · Set of typical tailorings for projects, e.g., application domains or lifecycles, such as O&M, R&D. · Organizational asset library/repository. · Organizational measurement database/repository. · Approved waivers to deviations from the organization’s standard process.

Use the organizational process assets and measurement repository for estimating and planning the project’s activities.

1. Base the activities for estimating and planning on the tasks and work products of the project's defined process. 2. Use the organization’s measurement repository in estimating the project’s planning parameters.

Project estimates; Project plans.

Organizational measurement database/repository. · Assumptions and rationale associated with the historical data used for the estimate. · Organizational asset library/repository. · Estimating tools, algorithms, and procedures. · Operational definitions (e.g., process/criteria) for establishing and documenting the estimates of the attributes of the work products and tasks. · Bases of Estimates (BOEs). · Project’s defined process that includes the size and complexity of tasks and work products to be produced. · Estimation planning parameters. · Records of independent estimation evaluations, e.g. Delphi, or multiple estimation techniques.




Common Features




SP1.2

SP1.3

Use the organizational process assets and measurement repository for estimating and planning the project’s activities.

1. Base the activities for estimating and planning on the tasks and work products of the project's defined process. 2. Use the organization’s measurement repository in estimating the project’s planning parameters.

Project estimates; Project plans.

Organizational measurement database/repository. · Assumptions and rationale associated with the historical data used for the estimate. · Organizational asset library/repository. · Estimating tools, algorithms, and procedures. · Operational definitions (e.g., process/criteria) for establishing and documenting the estimates of the attributes of the work products and tasks. · Bases of Estimates (BOEs). · Project’s defined process that includes the size and complexity of tasks and work products to be produced. · Estimation planning parameters. · Records of independent estimation evaluations, e.g. Delphi, or multiple estimation techniques.

Establish the Project's Work Environment




Common Features




SP1.4

Integrate the project plan and the other plans that affect the project to describe the project’s defined process.

1. Integrate other plans that affect the project with the project plan. 2. Incorporate into the project plan the definitions of measures and measurement activities for managing the project. 3. Identify and analyze product and project interface risks. 4. Schedule the tasks in a sequence that accounts for critical development factors and project risks. 5. Incorporate the plans for performing peer reviews on the work products of the project's defined process. 6. Incorporate the training needed to perform the project’s defined process in the project’s training plans. 7. Establish objective entry and exit criteria to authorize the initiation and completion of the tasks described in the work breakdown structure (WBS). 8. Ensure that the project plan is appropriately compatible with the plans of relevant stakeholders. 9. Identify how conflicts will be resolved that arise among relevant stakeholders.

Project plan; Subordinate plans.

Project’s defined process.· List of relevant stakeholders. · Project schedule and schedule dependencies. · Databases (e.g., skills and training). · Training plans or training that is needed to perform the project’ defined process. · Entry and exit criteria for the tasks defined in the WBS.· Documented system-level and project interface risks. · Documented specifications of base and derived measures, and data collection and storage procedures. · Meeting minutes from stakeholder reviews of the project plan. · Stakeholder conflict resolution procedure.




Common Features




SP1.5

SP1.6

SG 2 Coordination and collaboration of the project with relevant stakeholders is conducted. 0.0%

Manage the project using the project plan, the other plans that affect the project, and the project’s defined process.

1. Implement the project’s defined process using the organization's process asset library. 2. Monitor and control the project’s activities and work products using the project’s defined process, project plan, and other plans that affect the project. 3. Obtain and analyze the selected measures to manage the project and support the organization’s needs. 4. Periodically review the adequacy of the environment to meet the project’s needs and to support coordination. 5. Periodically review and align the project’s performance with the current and anticipated needs, objectives, and requirements of the organization, customer, and end users, as appropriate.

Work products created by performing the project's defined process; Collected measures ("actuals") and progress records or reports.

Revised requirements, plans, and commitments; Integrated plans · Project plan and subordinate plans · Projects defined process. · Criteria or checklists used to track and manage transition across the project or product life cycle. Project entries into the organizational measurement database/repository. · Entry and exit criteria and documented completion for the tasks defined in the WBS. · Records of project tracking (e.g., metrics, analyses, variance reports) against the project’s planning parameters using documented / measurable thresholds. · Corrective actions based on discrepancies vs. plan.

Contribute work products, measures, and documented experiences to the organizational process assets.

1. Propose improvements to the organizational process assets. 2. Store process and product measures in the organization’s measurement repository. 3. Submit documentation for possible inclusion in the organization's process asset library. 4. Document lessons learned from the project for inclusion in the organization's process asset library.

Proposed improvements to the organization's process assets; Actual process and product measures collected from the project; Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned) · Project best practices and lessons learned.

Processes, procedures, and criteria for submitting improvements to the organizations process assets. · Organizational measurement database/repository that reflects actual process and product measures from the projects. · Organizational asset library/repository that provides evidence that work products and lessons learned are being populated by the projects. · Records of proposed process improvements and disposition.




Common Features




SP2.1

SP2.2

Manage the involvement of the relevant stakeholders in the project.

1. Coordinate with the relevant stakeholders who should participate in the project’s activities. 2. Ensure that work products that are produced to satisfy commitments meet the requirements of the recipient projects. 3. Develop recommendations and coordinate the actions to resolve misunderstandings and problems with the product and product-component requirements, product and product-component architecture, and product and product-component design.

Agendas and schedules for collaborative activities; Documented issues (e.g. issues with the customer requirements, product and product component requirements, product architecture, and product design); Recommendations on resolving stakeholder issues; Documented defects, issues, and action items arising from stakeholder reviews · Plan for stakeholder involvement.

Documented product and project interface risks · Project plan, identifying relevant stakeholders · Issues and dispositions for resolving stakeholder interfaces and misunderstanding. · Project schedule(s) that identify critical dependencies with relevant stakeholders.· Milestone/stakeholder review meeting minutes. · Organizational chart. · Records of reviews, demonstrations or testing on work products produced by relevant stakeholders or produced for other projects.

Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.

1. Conduct reviews with relevant stakeholders. 2. Identify each critical dependency. 3. Establish need dates and plan dates for each critical dependency based on the project schedule. 4. Review and get agreement on the commitments to address each critical dependency with the people responsible for providing the work product and the people receiving the work product. 5. Document the critical dependencies and commitments. 6. Track the critical dependencies and commitments and take corrective action as appropriate.

Critical dependencies; Commitments to address critical dependencies; Status of critical dependencies.

Agendas and schedules for collaborative activities; Defects, issues, and action items arising from stakeholder reviews · Project plan, identifying relevant stakeholders · Projects defined process for identifying, negotiating, and tracking critical dependencies · Project schedule(s) that identify critical dependencies with relevant stakeholders. · Stakeholder milestone/project status reviews · Updated project plans reflecting and associated artifacts demonstrating negotiating and tracking.




Common Features




SP2.3

SG 3 The project is conducted using the project’s shared vision. 0.0%

SP3.1

SP3.2

SG 4 The integrated teams needed to execute the project are identified, defined, structured, and tasked. 0.0%

Resolve issues with relevant stakeholders.

1. Identify and document issues. 2. Communicate issues to the relevant stakeholders. 3. Resolve issues with the relevant stakeholders. 4. Escalate to the appropriate managers those issues not resolvable with the relevant stakeholders. 5. Track the issues to closure. 6. Communicate with the relevant stakeholders on the status and resolution of the issues.

Documented stakeholder coordination issues; Status of stakeholder issues.

Reviews, reports, or briefings communicating issues to stakeholders. · Issue tracking database with evidence of issues status being tracked and issues being resolved. · Evidence of escalation of issues to managers as needed. Could be through stakeholder meeting minutes with subsequent project status reports documenting issues.

Identify expectations, constraints, interfaces, and operational conditions applicable to the project’s shared vision.

1. Identify expectations, constraints, interfaces, and operational conditions about the organization and project that affect the project’s shared vision. 2. Elicit project members’ perspectives and aspirations for the project. 3. Create a description of the project’s shared-vision context.



Establish and maintain a shared vision for the project.

1. Hold meetings or workshops to create the project’s shared vision. 2. Articulate the project’s shared vision in terms of purpose or mission, vision, values, and objectives. 3. Reach consensus on the project’s shared vision. 4. Establish a strategy to communicate the project’s shared vision both externally and internally. 5. Make presentations suitable for the various audiences that need to be informed about the project’s shared vision. 6. Check that project and individual activities and tasks are aligned with the project’s shared vision.






Common Features




SP4.1

SP4.2

Determine the integrated team structure that will best meet the project objectives and constraints.

1. Determine the risks in the products and product suite. 2. Determine likely resource requirements and availability. 3. Establish work-product-based responsibilities. 4. Consider organizational process assets for opportunities, constraints, and other factors that might influence integrated team structure. 5. Develop an understanding of the organization’s shared vision, the project’s shared vision, and the organization’s standard processes and organizational process assets applicable to teams and team structures. 6. Identify alternative integrated team structures. 7. Evaluate alternatives and select an integrated team structure.



Develop a preliminary distribution of requirements, responsibilities, authorities, tasks, and interfaces to teams in the selected integrated team structure.

1. Assemble requirements and interfaces for integrated teams. 2. Check that the preliminary distribution of requirements and interfaces covers all specified product requirements and other requirements. 3. Define responsibilities and authorities for integrated teams. 4. Designate the sponsor for each integrated team.






Common Features




SP4.3


GP2.1 CO 1

Establish and maintain teams in the integrated team structure.

1. Choose integrated team leaders. 2. Allocate responsibilities and requirements to each integrated team. 3. Allocate resources to each integrated team. 4. Create each integrated team. 5. Integrated team composition and structures are periodically evaluated and modified to best reflect project needs. 6. When a change of team leader or a significant change of membership of the team occurs, review the integrated team composition and its place in the integrated team structure. 7. When a change in team responsibility occurs, review the team composition and its tasking. 8. Manage the overall performance of the teams.



Establish and maintain an organizational policy for planning and performing the integrated project management process.

This policy establishes organizational expectations for using the project's defined process and coordinating and collaborating with relevant stakeholders. This policy also establishes organizational expectations for using Integrated Product and Process Development concepts for carrying out the objectives of the organization.






Common Features




GP3.1 AB 1

GP2.2 AB 2

Establish and maintain the description of a defined integrated project management process.

This generic practice is different from the Establish the Project’s Defined Process specific practice in this process area. This generic practice establishes and maintains a defined integrated project management process. The Establish the Project’s Defined Process specific practice defines the project’s defined process, which includes all processes that affect the project.



Establish and maintain the plan for performing the integrated project management process.

Typically, this plan for performing the integrated project management process is a part of the project plan as described in the Project Planning process area.






Common Features




GP2.3 AB 3

Provide adequate resources for performing the integrated project management process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Problem-tracking and trouble-reporting packages; Groupware; Video conferencing; Integrated decision database; Integrated product support environments.


Tools: preferred supplier lists; requirements tracking programs; project management and scheduling programs; Facilities: secure repositories for limited access to source selection data; Tools: research and reference libraries of vendors and COTS products; supplier database; COTS product licenses; action item database; Staff: domain experts in applications and technologies being acquired; Tools: see PP and PMC GP PIIDs for planning and management tools that might be relevant (e.g. estimation and scheduling tools; analysis tools; cost / effort tracking and reporting systems); [Tools (coordination): problem tracking and trouble reporting packages; file transfer packages; groupware; video; Conferencing; email; integrated decision database; integrated product support environments; Staff: experienced estimators; schedulers; technical experts in application domain and technologies.




Common Features




GP2.4 AB 4

GP2.5 AB 5

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the integrated project management process.



Train the people performing or supporting the integrated project management process as needed.

Examples of training topics include the following: Tailoring the organization’s set of standard processes to meet the needs of the project; Procedures for managing the project based on the project’s defined process; Using the organization’s measurement repository; Using the organizational process assets; Integrated management; Intergroup coordination; Group problem solving; Building the project's shared vision; Team building.






Common Features




GP2.6 DI 1

GP2.7 DI 2

Place designated work products of the integrated project management process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: The project’s defined process; Project plans; Other plans that affect the project; Integrated plans; Actual process and product measures collected from the project; Integrated team structure.



Identify and involve the relevant stakeholders of the integrated project management process as planned.

Examples of activities for stakeholder involvement include: Resolving issues about the tailoring of the organizational process assets; Resolving issues among the project plan and the other plans that affect the project; Reviewing project performance to align with current and projected needs, objectives, and requirements; Creating the project's shared vision; Defining the integrated team structure for the project.






Common Features




GP2.8 DI 3

GP3.2 DI 4

Monitor and control the integrated project management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of changes to the project's defined process; Schedule and effort to tailor the organization’s set of standard processes; Interface coordination issue trends (i.e., number identified and number closed); Project's shared-vision usage and effectiveness; Integrated team-structure usage and effectiveness; Select indicators of shared-vision effectiveness that show (1) that there is unity of purpose within the project, (2) that project members are working together and meeting the project’s objectives, (3) that behaviors and principles have been established and are being used while team members work to achieve objectives, and (4) that the shared vision of the project aligns with the existing visions of the organization and other projects, particularly those with which close interaction is expected.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the integrated project management process to support the future use and improvement of the organization’s processes and process assets.

This generic practice is different from the Contribute to the Organizational Process Assets specific practice in this process area. This generic practice collects improvement information about the integrated project management processes. The Contribute to the Organizational Process Assets specific practice collects information from processes in the project’s defined process.






Common Features




GP2.9 VE 1

GP2.10 VE 2

Objectively evaluate adherence of the integrated project management process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing, maintaining, and using the project’s defined process; Coordinating and collaborating with relevant stakeholders; Using the project's shared vision. Examples of work products reviewed include the following: Project’s defined process; Project plans; Other plans that affect the project; Integrated plans; Shared-vision statements.



Review the activities, status, and results of the integrated project management process with higher level management and resolve issues.






Risk Management (RKM)


SG 1 Preparation for risk management is conducted. 33.3%

SP1.1 1

SP1.2 0

Goals and Practices

Common Features




Determine risk sources and categories.

1. Determine risk sources. 2. Determine risk categories.

Risk sources lists (external and internal); Risk categories list.

Risk taxonomy or hierarchy (e.g., risk classes, elements, attributes). · Risk management plan and procedures. · Risk management tool or database.· Risk categorization guidelines (e.g., source, impact types).

Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort.

1. Define consistent criteria for evaluating and quantifying risk likelihood and severity levels. 2. Define thresholds for each risk category. 3. Define bounds on the extent to which thresholds are applied against or within a category.

Risk evaluation, categorization, and prioritization criteria; Risk management requirements (control and approval levels, reassessment intervals, etc.).

Risk management plan and procedures · Risk management tool or database · Defined ranges and parameters for risk evaluation, categorization, and prioritization, such as risk likelihood (probability), consequence (severity) · Defined thresholds (e.g., control points, scoping boundary conditions, exclusions, triggers) and criteria for taking action.




Common Features




SP1.3

SG 2 Risks are identified and analyzed to determine their relative importance. 0.0%

SP2.1

Establish and maintain the strategy to be used for risk management.

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, simulation, alternative designs, or evolutionary development; Definition of risk measures to monitor the status of the risks; Time intervals for risk monitoring or reassessment.

Project risk managementstrategy · Risk management plan · Revisions to the risk management strategy.

Evidence of reviews of the risk management strategy held with project stakeholders (e.g., signature approval, minutes, action items) · Measures identified for monitoring risk status · Risk management procedures and tools · Description and application of risk mitigation techniques (prototyping, simulation, etc.).

Identify and document the risks.

1. Identify the risks associated with cost, schedule, and performance in all appropriate product life-cycle phases. 2. Review environmental elements that may impact the project. 3. Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered. 4. Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered. 5. Document the context, conditions, and potential consequences of the risk. 6. Identify the relevant stakeholders associated with each risk.

List of identified risks, including the context, conditions, and consequences for occurrence · Revisions to list of identified risks.

Structured risk statements · Risk assessment results or evidence of occurrence · Risk taxonomy-based questionnaire interviews.




Common Features




SP2.2

SG 3 Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives. 0.0%

SP3.1

Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority.

1. Evaluate the identified risks using the defined risk parameters. 2. Categorize and group risks according to the defined risk categories. 3. Prioritize risks for mitigation.

List of risks, with a priority assigned to each risk · Categorization and parameter values of identified risks.

Aggregated and consolidated set of risks, with cause and effect relationships identified between related risks · Project reviews or briefings of risks and risk parameters · Criteria used to quantify risks and assign risk parameters. · Derived measures for identified risks (e.g., risk exposure).

Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.

1. Determine the levels and thresholds that define when a risk becomes unacceptable and triggers the execution of a risk mitigation plan or a contingency plan. 2. Identify the person or group responsible for addressing each risk. 3. Determine the cost-to-benefit ratio of implementing the risk mitigation plan for each risk. 4. Develop an overall risk mitigation plan for the project to orchestrate the implementation of the individual risk mitigation and contingency plans.5. Develop contingency plans for selected critical risks in the event their impacts are realized.

Risk mitigation plans; Contingency plans.

Documented handling options for each identified risk; List of those responsible for tracking and addressing each risk · Risk levels and thresholds defined to trigger deployment of risk mitigation plans. · Risk mitigation cost/benefit tradeoff analyses · Management reserve budget allocation for deployment of risk mitigation plans.




Common Features




SP3.2


GP2.1 CO 1

Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

1. Monitor risk status. 2. Provide a method for tracking open risk-handling action items to closure. 3. Invoke selected risk-handling options when monitored risks exceed the defined thresholds. 4. Establish a schedule or period of performance for each risk-handling activity that includes the start date and anticipated completion date. 5. Provide continued commitment of resources for each plan to allow successful execution of the risk-handling activities. 6. Collect performance measures on the risk-handling activities.

Updated lists of risk status; Updated assessments of risk likelihood, consequence, and thresholds · Implemented risk mitigation actions or contingency plans.

Updated lists of risk-handling options; Updated list of actions taken to handle risks; Risk mitigation plans · Risk status reports, analyses, performance measures, trending. · Evidence of risk management status reviews (periodic and event-driven) · Newly identified risks· Risk handling actions, tracked to closure.

Establish and maintain an organizational policy for planning and performing the risk management process.

This policy establishes organizational expectations for defining a risk management strategy and identifying, analyzing, and mitigating risks.






Common Features




GP3.1 AB 1Establish and maintain the description of a defined risk management process.






Common Features




GP2.2 AB 2

GP2.3 AB 3

Establish and maintain the plan for performing the risk management process.

Typically, this plan for performing the risk management process is included in (or referenced by) the project plan, which is described in the Project Planning process area. The plan for performing the risk management process differs from both the risk management strategy and the risk mitigation plans described in the specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from determining risk sources and categories all the way through to the implementation of risk mitigation plans. In contrast, the risk management strategy called for in one specific practice would address the project-specific risk strategy for things such as risk sources, thresholds, tools, and techniques, and would monitor time intervals. The risk mitigation plans called for in another specific practice would address more focused items such as the levels that trigger risk-handling activities.



Provide adequate resources for performing the risk management process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Risk management databases; Risk mitigation tools; Prototyping tools; Modeling and simulation.


Tools: risk management databases; risk mitigation tools; prototyping tools; modeling and simulation tools; Funding: percentage of management reserve allocated for risk mitigation; Tools: prototyping and simulation tools and environment; risk analysis and reporting tools.




Common Features




GP2.4 AB 4

GP2.5 AB 5

GP2.6 DI 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the risk management process.



Train the people performing or supporting the risk management process as needed.

Examples of training topics include the following: Risk management concepts and activities (e.g., risk identification, evaluation, monitoring, mitigation); Measure selection for risk mitigation.



Place designated work products of the risk management process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Risk management strategy; Identified risk items; Risk mitigation plans.






Common Features




GP2.7 DI 2

GP2.8 DI 3

Identify and involve the relevant stakeholders of the risk management process as planned.

Examples of activities for stakeholder involvement include the following: Establishing a collaborative environment for free and open discussion of risk; Reviewing the risk management strategy and risk mitigation plans; Participating in risk identification, analysis, and mitigation activities; Communicating and reporting risk management status.



Monitor and control the risk management process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Number of risks identified, managed, tracked, and controlled; Risk exposure and changes to the risk exposure for each assessed risk, and as a summary percentage of management reserve; Change activity for the risk mitigation plans (e.g., processes, schedule, funding); Occurrence of unanticipated risks; Risk categorization volatility; Comparison of estimated vs. actual risk mitigation effort and impact.






Common Features




GP3.2 DI 4

GP2.9 VE 1

GP2.10 VE 2

Collect work products, measures, measurement results, and improvement information derived from planning and performing the risk management process to support the future use and improvement of the organization’s processes and process assets.



Objectively evaluate adherence of the risk management process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Establishing and maintaining a risk management strategy; Identifying and analyzing risks; Mitigating risks. Examples of work products reviewed include the following: Risk management strategy; Risk mitigation plans.



Review the activities, status, and results of the risk management process with higher level management and resolve issues.

Reviews of the project risk status are held on a periodic and event-driven basis with appropriate levels of management, to provide visibility into the potential for project risk exposure and appropriate corrective action. Typically, these reviews will include a summary of the most critical risks, key risk parameters (such as likelihood and consequence of these risks), and the status of risk mitigation efforts.






SG 1 Decisions are based on an evaluation of alternatives using established criteria. 0.0%

SP1.1

SP1.2

SP1.3 Identified alternatives.

Decision Analysis and Resolution (DAR)

Goals and Practices

Common Features




Establish and maintain guidelines to determine which issues are subject to a formal evaluation process.

1. Establish guidelines. 2. Incorporate the use of the guidelines into the defined process where appropriate.

Guidelines for when to apply a formal evaluation process.

Criteria or checklists for determining when to apply a formal evaluation process · Process description for conducting formal evaluations and selection of applicable decision-making techniques · Identified set of typical issues subject to a formal evaluation process.

Establish and maintain the criteria for evaluating alternatives, and the relative ranking of these criteria.

1. Define the criteria for evaluating alternative solutions. 2. Define the range and scale for ranking the evaluation criteria. 3. Rank the criteria. 4. Assess the criteria and their relative importance. 5. Evolve the evaluation criteria to improve their validity. 6. Document the rationale for the selection and rejection of evaluation criteria.

Documented evaluation criteria; Rankings of criteria importance.

Traceability of criteria to documented sources (e.g., requirements, assumptions, business objectives) · Guidance for determining and applying evaluation criteria (e.g., ranges, scales, formulas, rationale) · Rationale for selection and rejection of evaluation criteria.

Identify alternative solutions to address issues.

1. Perform a literature search. 2. Identify alternatives for consideration in addition to those that may be provided with the issue. 3. Document the proposed alternatives.

Results of brainstorming sessions, interviews, or other techniques used to identify potential solutions. · Research resources and references (e.g. literature surveys).




Common Features




SP1.4 Select the evaluation methods. Selected evaluation methods.

SP1.5

SP1.6


1. Select the methods based on the purpose for analyzing a decision and on the availability of the information used to support the method. 2. Select evaluation methods based on their ability to focus on the issues at hand without being overly influenced by side issues. 3. Determine the measures needed to support the evaluation method.

List of candidate or preferred evaluation methods. · Guidance on selection of appropriate evaluation methods.

Evaluate alternative solutions using the established criteria and methods.

1. Evaluate the proposed alternative solutions using the established evaluation criteria and selected methods. 2. Evaluate the assumptions related to the evaluation criteria and the evidence that supports the assumptions. 3. Evaluate whether uncertainty in the values for alternative solutions affects the evaluation and address as appropriate. 4. Perform simulations, modeling, prototypes, and pilots as necessary to exercise the evaluation criteria, methods, and alternative solutions. 5. Consider new alternative solutions, criteria, or methods if the proposed alternatives do not test well; repeat the evaluations until alternatives do test well. 6. Document the results of the evaluation.

Conclusions or findings from evaluations.

Evaluated assumptions and constraints for application of evaluation criteria or interpretation of results (e.g., uncertainty, significance) · Completed evaluation forms, checklists, or assigned criteria. · Results of simulations, modeling, prototypes, pilots, life cycle cost analyses, studies, etc., performed on potential solutions.

Select solutions from the alternatives based on the evaluation criteria.

1. Assess the risks associated with implementing the recommended solution. 2. Document the results and rationale for the recommended solution.

Recommended solutions to address significant issues · Documented results and rationale of the decision.

Risk assessment of solutions or execution of the decision-making process · Approval of the final selected solution by stakeholders.




Common Features




GP2.1 CO 1

GP3.1 AB 1

Establish and maintain an organizational policy for planning and performing the decision analysis and resolution process.

This policy establishes organizational expectations for selectively analyzing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. The policy should also provide guidance on which decisions require a formal evaluation process.



Establish and maintain the description of a defined decision analysis and resolution process.






Common Features




GP2.2 AB 2

GP2.3 AB 3

Establish and maintain the plan for performing the decision analysis and resolution process.

Typically, this plan for performing the decision analysis and resolution process is included in (or is referenced by) the project plan, which is described in the Project Planning process area.



Provide adequate resources for performing the decision analysis and resolution process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools: Simulators and modeling tools; Prototyping tools; Tools for conducting surveys.






Common Features




GP2.4 AB 4

GP2.5 AB 5

GP2.6 DI 1

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the decision analysis and resolution process.



Train the people performing or supporting the decision analysis and resolution process as needed.

Examples of training topics include the following: Formal decision analysis; Methods for evaluating alternative solutions against criteria.



Place designated work products of the decision analysis and resolution process under appropriate levels of configuration management.

Examples of work products placed under configuration management include the following: Guidelines for when to apply a formal evaluation process; Evaluation reports containing recommended solutions.






Common Features




GP2.7 DI 2

GP2.8 DI 3

GP3.2 DI 4

Identify and involve the relevant stakeholders of the decision analysis and resolution process as planned.

Examples of activities for stakeholder involvement include the following: Establishing guidelines for which issues are subject to a formal evaluation process; Establishing evaluation criteria; Identifying and evaluating alternatives; Selecting evaluation methods; Selecting solutions.



Monitor and control the decision analysis and resolution process against the plan for performing the process and take appropriate corrective action.

Examples of measures used in monitoring and controlling include the following: Cost-to-benefit ratio of using formal evaluation processes.



Collect work products, measures, measurement results, and improvement information derived from planning and performing the decision analysis and resolution process to support the future use and improvement of the organization’s processes and process assets.






Common Features




GP2.9 VE 1

GP2.10 VE 2

Objectively evaluate adherence of the decision analysis and resolution process against its process description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following: Evaluating alternatives using established criteria and methods. Examples of work products reviewed include the following: Guidelines for when to apply a formal evaluation process; Evaluation reports containing recommended solutions.



Review the activities, status, and results of the decision analysis and resolution process with higher level management and resolve issues.




cmmi dev gap analysis workbook

Documents