Capability Maturity Model Integration (CMMI) v1.

2
Interpretation

IBM India Pvt Ltd 1

Agenda

 Introduction to the CMMI for Development v1.2

 Model Institutionalization
 Introduction to the 22 process areas.
 Implementation perspective : Understanding the work-products, that at a
minimum, would be expected to achieve satisfaction of the Process Area
Goals.

2 January 2007
Overview
The CMMI v1.2 consists of best practices that address development and maintenance
activities,
applied to both products and services.

Addresses practices that cover the full product lifecycle from conception through delivery
and maintenance.

There are two representations available in the CMMI

 Staged representation
 Continuous Representation

The disciplines explicitly covered in the model are Hardware engineering, Systems
engineering, and Software Engineering

Model name updated to CMMI for Development (CMMI-DEV) to reflect the new CMMI
architecture

CMMI for Development + IPPD Additions covers the use of integrated teams for
development and maintenance activities.

2007 Models : CMMI for Acquisition (CMMI-ACQ) and CMMI for Services (CMMI-SVC)
3 January 2007
Overview (Continued)

 There are 5 Maturity Levels and 22 Process Areas (PA) in the Staged Representation

1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

 Each PA has 1 to 4 Specific Goals and associated Specific Practices.

 Each PA addresses the needs for institutionalization through Generic Goals and associated
Generic Practices.
bb
 For Maturity Level 3 and above, two Generic Goals are applicable. Each of the Generic practices
needs to be
implemented differently for every Process Area.

Either the specific practices as described or an acceptable alternative needs to be implemented, for
the Specific
Goals to be satisfied.

4 January 2007
Staged Representation Structure

Maturity Level

Process Area 1 Process Area 2 Process Area N

Specific Goals Generic Goals

Specific Practices Generic Practices

5 January 2007
CMMI Maturity Levels and Process Areas Optimizing (5)
Causal Analysis & Resolution
Organizational Innovation & Deployment

Quantitatively Managed (4)

Organizational Process Performance
Quantitative Project Management

Defined (3)
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Decision Analysis & Resolution
Risk Management
Integrated Project Management
Organizational Training
Organization Process Definition
Organization Process Focus

Managed (2)
Measurement & Analysis
Configuration Management
Process & Product Quality Assurance
Supplier Agreement Management
Project Monitoring & Control
Project Planning
Requirements Management

Initial (1)
6 January 2007
Maturity Levels

7
Level 1: Initial

Atmaturity level 1:
 Processes are usually ad hoc and chaotic
 The organization usually does not provide a stable environment.
 Success in these organizations depends on the competence and heroics of the people in
the organization and not on the use of proven processes.
 In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce
products and services that work; however, they frequently exceed the budget and
schedule of their projects.
 Maturity level 1 organizations are characterized by a tendency to over commit, abandon
processes in the time of crisis, and not be able to repeat their past successes.
 There are no specific best practices are associated with Maturity Level 1.

8 January 2007
Level 2: Managed

At maturity level 2:
 The projects of the organization have ensured that requirements are managed and
that processes are planned, performed, measured, and controlled.
 The process discipline reflected by maturity level 2 helps to ensure that existing
practices are retained during times of stress.
 When these practices are in place, projects are performed and managed according
to their documented plans.
 Requirements, processes, work products, and services are managed.
 The status of the work products and the delivery of services are visible to
management at defined points (for example, at major milestones and at the
completion of major tasks).
 Commitments are established among relevant stakeholders and are revised as
needed.
 Work products are reviewed with stakeholders and are controlled.
 The work products and services satisfy their specified requirements, standards, and
objectives

9 January 2007
Level 3: Defined

At maturity level 3:
 Processes are well characterized and understood, and are described in standards,
procedures, tools, and methods.
 The organization’s set of standard processes, which is the basis for maturity level 3, is
established and improved over time.
 These standard processes are used to establish consistency across the organization.
 The standards, process descriptions, and procedures for a project are tailored from
the organization’s set of standard processes to suit a particular project or
organizational unit.
 Processes are managed more proactively using an understanding of the
interrelationships of the process activities and detailed measures of the process, its
work products, and its services.

10 January 2007
Level 4 :
Quantitatively Managed

At maturity level 4:
 Processes are controlled using statistical and other quantitative techniques.
 Quantitative objectives for quality and process performance are established and used
as criteria in managing processes.
 Quantitative objectives are based on the needs of the customer, end users,
organization, and process implementers.
 Quality and process performance are understood in statistical terms and are
managed throughout the life of the processes.
 Detailed measures of process performance are collected and statistically analyzed.
 Special causes of process variation are identified and, where appropriate, the
sources of special causes are corrected to prevent future occurrences.
 Quality and process performance measures are incorporated into the organization’s
measurement repository to support fact-based decision making in the future.

11 January 2007
Level 5 : Optimizing

At maturity level 5:
 Processes are continually improved based on a quantitative understanding of the
common causes of variation inherent in processes.
 Focuses on continually improving process performance through both incremental
and innovative technological improvements.
 The effects of deployed process improvements are measured and evaluated
against the quantitative process performance objectives.
 Process improvements to address common causes of process variation and
measurably improve the organization’s processes are identified, evaluated, and
deployed.
 Improvements are selected based on a quantitative understanding of their
expected contribution to achieving the organization’s process performance
objectives versus the cost and impact to the organization.
 The organization’s ability to rapidly respond to changes and opportunities is
enhanced by finding ways to accelerate and share learning.

12 January 2007
Generic Goals and Practices

13
Generic Goals and Practices

 Generic goals and practices enable the organization to institutionalize best

practices.

 The generic practices (GPs) are applicable to every process area. They address
the institutionalization requirements for that process area.

 While the practices are generic, the organization implements each of the GPs for
each of the process areas differently.

 The Generic practices are organized under 2 Generic goals :

 GG2 : Institutionalize a Managed process
 GG3 : Institutionalize a Defined Process

As per the structure of CMMI, Generic Goals start with GG2 i.e. there is no GG1

 All Generic practices relating to GG2 are numbered as GP 2.n and Generic practices
relating to GG3 are numbered as GP 3.n

14 January 2007
Generic Goals and Practices (Continued)
GG2 Institutionalize a Managed Process
• GP 2.1 Establish an Organizational Policy
• GP 2.2 Plan the Process
• GP 2.3 Provide Resources
• GP 2.4 Assign Responsibility
• GP 2.5 Train People
• GP 2.6 Manage Configurations
• GP 2.7 Identify and Involve Relevant Stakeholders
• GP 2.8 Monitor and Control the Process
• GP 2.9 Objectively Evaluate Adherence
• GP 2.10 Review Status with Higher Level Management

GG3 Institutionalize a Defined Process

• GP 3.1 Establish a Defined Process

• GP 3.2 Collect Improvement Information

15 January 2007
Typical Work-products expected for Goal Satisfaction

The presentation will now discuss the work-products expected to satisfy the
Generic and Specific Goals.

The work-products expected to satisfy Generic Goals are discussed

before the Specific Goals as Generic Practices need to be implemented
for every Process Area.

Click here for additional details on the purpose of the GPs

16 January 2007
Typical work-products for Generic Goals

 GP 2.1 Establish an Organizational Policy

 Implemented at Org level and covered in documents such as the Quality Manual.

 GP 2.2 Plan the Process

• Approved Project Plan and related Auxiliary plans/Group Plans covering the respective Process Areas

 GP 2.3 Provide Resources

• HW, SW and people resources for executing the respective process identified. Example:
Critical Computer Resources & Tools Section in the Project Plan and People resources listed in the Staffing Plan.

 GP 2.4 Assign Responsibility

• Staffing plan specifying the resources and their Role assigned for executing the respective process
• Roles & Responsibility section specifying the responsibility/accountability for the respective process as applicable.

 GP 2.5 Train People

• Training Tracker and training related records in the project specifying the training for the respective process as
applicable.

 GP 2.6 Manage Configurations

• Document Control & Configuration Management Plan detailing how the work-products for the respective process
would be controlled (as applicable). Actual evidence of applicable work-products under Doc Control/CM.

17 January 2007
Typical work-products for Generic Goals (continued)

 GP 2.7 Identify and Involve Relevant Stakeholders

• Project interfaces with other groups identified and tracked

 GP 2.8 Monitor and Control the Process

• Status reports/Metrics for tracking progress of the respective process.

 GP 2.9 Objectively Evaluate Adherence

• Process Reviews, Audit & Appraisal results associated with the respective process.

 GP 2.10 Review Status with Higher Level Management

• Status reports, P3 CTR meeting presentations.

 GP 3.1 Establish a Defined Process

 Process Adherence section specifying process adherence ‘as-is’ or as a tailored process
for the respective process.
 In the case of customer mandated process, tailoring should be evident in Process
Adherence section.

 GP 3.2 Collect Improvement Information

• Best Practices /Assets associated with the respective process submitted to Org
Repositories. Eg. ICM or other organizational repositories.

18 January 2007
Level 2 Managed

Level 2 which is the Managed Level has 7 Process Areas as mentioned below:

 Requirements Management (REQM)

 Project Planning (PP)
 Project Monitoring and Control (PMC)
 Supplier Agreement Management (SAM)
 Measurement and Analysis (MA)
 Process and Product Quality Assurance (PPQA)
 Configuration Management (CM)

19 January 2007
Requirements Management (REQM) – An Overview

Purpose :
The purpose of Requirements Management is to manage the requirements of
the project's products and product components and to identify inconsistencies
between those requirements and the project's plans and work products

REQM involves :
 Identifying designated ‘Requirements Providers’ to prevent scope creep
 Using criteria for accepting requirements
 Arriving at a shared and compatible understanding on the meaning of the
requirements with the Requirements providers
 Tracking Requirements changes
 Implementing bi-directional Traceability Matrix
 Identifying inconsistencies between baselined requirements and plans

20 January 2007
Requirements Management

Goal 1: Requirements are managed and inconsistencies with project plans and
work products are identified.

 SP 1.1 Obtain an Understanding of Requirements

 SP 1.2 Obtain Commitment to Requirements
 SP 1.3 Manage Requirements Changes
 SP 1.4 Maintain Bi-directional Traceability of Requirements
 SP 1.5 Identify Inconsistencies between Project Work and
Requirements

21 January 2007
Requirements Management

Goal 1: Requirements are managed and inconsistencies with project plans and
work products are identified.

 Reviewed and approved DOU to be in place.

 Reviewed and approved Software requirements document as applicable
 Bi-directional traceability established from Customer requirements to work-products.
The traceability is to be established across the defined life-cycle phases as
appropriate to the scope of the project.
 Any Change to the above documents should be managed as specified in the
Document Control/CM Procedures
 Task plans / Project plans/SPP should be based on the DOU/software requirements.
Any change in DOU should also be reflected as appropriate in the plans.

22 January 2007
 Weak Areas - Requirement Management

SP 1.1 - Obtain an understanding of Requirements

Improvement Areas:
PTD and other artifacts to explicitly mention on the mechanism to obtain understanding to requirements.
SP1.2 - Obtain commitment to Requirements
Improvement Areas:
Evidence of approvals/commitments to be maintained.
SP1.3 - Manage Requirements changes
Improvement Areas:
In few cases, change management documentation and approval records to be effectively
maintained.
SP 1.4 - Maintain Bidirectional Traceability of Requirements
Improvement Areas:
Some accounts should have a mechanism to ensure traceability end to end and maintain it
effectively.
SP1.5 - Identify Inconsistencies between project work and Requirements
Improvement Areas:
Review records, details of interactions, minutes of meeting, issues/action logs to be
maintained in case of some accounts.

23 January 2007
Project Planning (PP) – An overview
Purpose:
The purpose of Project Planning is to establish and maintain plans that define
project activities

PP starts with the requirements that define the project. It defines the activities that need to be
performed and controlled to address the commitments to the customer.
PP Involves an iterative process of:
Determining scope, WBS and estimating size and effort
Establishing schedules
Identifying and evaluating risks
Planning Stakeholder involvement
Negotiating commitments with Stakeholders

PP also supports/ensures that:

 Project team members by providing visibility of upcoming activities
 Projects are planned in accordance with a standard procedure
 Project scope is clearly stated
 Identification of individual project tasks
 Estimates of project effort, cost, size and timelines
 Identification of risks so mitigation strategies can be put in place
 Stakeholders are appropriately involved
24 January 2007
 Project Planning
Goal 1: Estimates of project planning parameters are established and maintained.
 SP 1.1 Estimate the Scope of the Project
 SP 1.2 Establish Estimates of Work Product and Task Attributes
 SP 1.3 Define Project Life Cycle
 SP 1.4 Determine Estimates of Effort and Cost

Goal 2: A project plan is established and maintained as the basis for managing the project.
 SP 2.1 Establish the Budget and Schedule
 SP 2.2 Identify Project Risks
 SP 2.3 Plan for Data Management
 SP 2.4 Plan for Project Resources
 SP 2.5 Plan for Needed Knowledge and Skills
 SP 2.6 Plan Stakeholder Involvement
 SP 2.7 Establish the Project Plan

Goal 3: Commitments to the project plan are established and maintained.

 SP 3.1 Review Plans that Affect the Project

 SP 3.2 Reconcile Work and Resource Levels
 SP 3.3 Obtain Plan Commitment

25 January 2007
 Project Planning
Goal 1: Estimates of project planning parameters are established and maintained.
 Estimation worksheets / Complexity Definition Forms and associated Review
 Estimation for headcount/staffing based on parameters such as Service Request (SR) volumes /
Backlog Index
 All assumptions and dependencies in estimation/CDF to be recorded.
 Estimation worksheets/CDF to be under document control

Goal 2: A project plan is established and maintained as the basis for managing the project.
 Project’s Data Management Plan to be included as a Section in the PMSS
 Project plans and Auxiliary plans/different plans within the PMSS to be approved and released.
 Project plans to be placed under document control

Goal 3: Commitments to the project plan are established and maintained.

 Project plan/SPP/PMSS as per template.

 Mails/MOMs towards agreement by affected parties (RDM, IS, Architecture/Testing groups, other IBM
entities,…)

26 January 2007
Weak Area – Project Planning

SP1.1 - Establish a top-level work breakdown structure (WBS) to estimate the scope of the
project.
Improvement Areas :
 Standard WBS not available for most of the Maintenance Projects.
SP1.2- Establish and maintain estimates of the attributes of the work products and tasks.

Improvement Areas :
 Maintenance projects with minor enhancements do not have a defined estimation
process.
 In many projects estimation is provided by the client.
 Developing an Estimation Model.
 Low usage of OPAL template for Estimates( using ENG 105a *Estimating Form )

SP1.3 - Define the project life-cycle phases upon which to scope the planning effort.
Improvement Areas : None

27 January 2007
Weak Areas- Project Planning

SP1.4 - Estimate the project effort and cost for the work products and tasks based on
estimation rationale
Improvement Areas:
 Project effort and cost estimates.
 Formalizing Estimation approvals from stakeholders.
SP 2.1 - Establish and maintain the project's budget and schedule.
Improvement Areas:
 Tracking of Budget for many projects are not done by offshore team.
 Many Projects track Project schedule in Excel sheets in place of using standard WBS available in
RPM.
 Labor and Non Labor budget details to be consolidated
SP2.2 - Identify and analyze project risks.
Improvement Areas:
 Risk management plan to cover Risk analysis, categorization and prioritization
 Risk Tracking not effective.
 Usage of risk identification tool (GS Risk, Risk identification checklist) not strong

28 January 2007
Weak Areas : Project Planning

SP2.3 - Plan for the management of project data.

Improvement Areas
Project data management needs to be more effective in planning and implementation.
SP2.4 - Plan for necessary resources to perform the project.
Improvement Areas:
None
SP2.5- Plan for knowledge and skills needed to perform the project.
Improvement Areas:
Tracking of trainings based on skill improvements need more focus.
SP2.6 - Plan the involvement of identified stakeholders.
Improvement Areas:
Decision making in Project management areas need to be well documented.
SP 2.7 - Establish and maintain the overall project plan content.
Improvement Areas:
No project plan from end to end project perspective only schedule for same

29 January 2007
Weak Area- Project Planning

SP3.1 - Review all plans that affect the project to understand project commitments.
Improvement Areas:
Obtaining Formal commitments in case of rescheduling.
Periodic review and approval of PMSS, DP plans.
Documenting Review and approval records of PMSS and auxiliary Plans.

SP3.2 - Reconcile the project plan to reflect available and estimated resources.
Improvement Areas :
Updating Project schedule in case of Re-Planning

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

Improvement Areas :
None

30 January 2007
Project Monitoring & Control (PMC) – An Overview

Purpose
The purpose of Project Monitoring and Control is to provide an
understanding of the project’s progress so that appropriate corrective
actions can be taken when the project’s performance deviates significantly
from the plan
PMC Provides :
 Visibility into project activities for management, staff, and other stakeholders
 Information that enables management to make appropriate decisions
 Processes to help the project make midcourse adjustments since inevitably all things
do not go as planned
 Communicates progress of project activities to stakeholders

31 January 2007
Project Monitoring & Control

Goal 1: Actual performance and progress of the project are monitored against the
project plan.
 SP 1.1 Monitor Project Planning Parameters
 SP 1.2 Monitor Commitments
 SP 1.3 Monitor Project Risks
 SP 1.4 Monitor Data Management
 SP 1.5 Monitor Stakeholder Involvement
 SP 1.6 Conduct Progress Reviews
 SP 1.7 Conduct Milestone Reviews

Goal 2: Corrective actions are managed to closure when the project's

performance or results deviate significantly from the plan.
 SP 2.1 Analyze Issues
 SP 2.2 Take Corrective Action
 SP 2.3 Manage Corrective Action

32 January 2007
Project Monitoring & Control

Goal 1: Actual performance and progress of the project are monitored against the
project plan.
 Project status reporting as per the frequency defined in the plan
 Status updated on the project tracking tool (eg RPM)
 Status Report template, approved by SQA if tailored.

Goal 2: Corrective actions are managed to closure when the project's

performance or results deviate significantly from the plan.
 Project status report / project Tracking Tool covering all the deviation from plans
and corrective actions taken
 Issues with Data Management (if any) to be included

33 January 2007
Supplier Agreement Management (SAM)- An Overview

Purpose :
The purpose of SAM is to manage the acquisition of products from suppliers for
which there exists a formal agreement.

Agreement may be a contract, a license, or a memorandum of understanding.

Acquisition Type may be for COTS products, custom development, provision of services
Products acquired from supplier are to be integrated with overall product being delivered
to the customer
However SAM can also be used for acquisition of critical items not delivered to the
customer

SAM Helps in:

 Selecting suppliers based on defined criteria
 Establishing and maintaining agreements with suppliers
 Monitoring key supplier processes and work-products
 Accepting delivery of acquired products

34 January 2007
Project Monitoring and control – Weak Areas

SP1.1 - Monitor the actual values of the project planning parameters against the
project plan.
Improvement Areas:
Conducting P3CTRs on a periodic basis.
Updates irregular and not all planning parameters addressed

SP1.2 - Monitor commitments against those identified in the project plan.

Improvement Areas:
Effective documentation of minutes and closing identified Actions.
PL to PM status report not all data available

SP1.3 - Monitor risks against those identified in the project plan.

Improvement Areas:
Maintaining Risk Log, issue log periodically.
Identifying and monitoring of Project specific Risks.

35 January 2007
Project Monitoring and control – Weak Areas

SP1.4 - Monitor the management of project data against the project plan.
Improvement Areas:
Developing and effective implementation of Data Management for the Project.
SP1.5 - Monitor stakeholder involvement against the project plan.
Improvement Areas:
Formalize stakeholder commitments in terms of obtaining approvals and recording meeting minutes.
Monitoring closing of actions identified against relevant Stakeholders

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

Improvement Areas:
Consistency in implementing P3CTR.
Completeness and Effectiveness of PL-PM Reports.
Consistency in Status reporting
SP 1.7 - Review the accomplishments and results of the project at selected project
milestones.
Improvement Areas:
Consistency in reviewing accomplishments Status Reports.

36 January 2007
Project Monitoring and control – Weak areas

SP2.1- Collect and analyze the issues and determine the corrective actions
necessary to address the issues.
Improvement Areas:
Periodic monitoring DP activities in RADAR Tool and implementing corrective actions.
Consistency in tracking of Issues.
SP2.2 - Take corrective action on identified issues.
Improvement Areas:
Effectiveness of corrective action verification
SP2.3 - Manage corrective actions to closure
Improvement Areas:
Monitor closure of corrective actions on a periodic basis.
Corrective action segregated into Correction , Corrective action and preventive action for an effective
RCA to be done

37 January 2007
Supplier Agreement Management

Goal 1: Agreements with the suppliers are established and maintained.

 SP 1.1 Determine Acquisition Type

 SP 1.2 Select Suppliers
 SP 1.3 Establish Supplier Agreements

Goal 2: Agreements with the suppliers are satisfied by both the project and the
supplier.

 SP 2.1 Execute the Supplier Agreement

 SP 2.2 Monitor Selected Supplier Processes
 SP 2.3 Evaluate Selected Supplier Work-products
 SP 2.4 Accept the Acquired Product
 SP 2.5 Transition Products

38 January 2007
Supplier Agreement Management

Goal 1: Agreements with the suppliers are established and maintained.

 Project should clearly document all applicable commitments pertaining to HW/SW resources
to be procured (thru Procurement interface) in the Project Plan/DOU. Appropriate Tool entry to
be available in case of procurement.

Goal 2: Agreements with the suppliers are satisfied by both the project and the
supplier.

 Status reports should show status of applicable agreements and actions plans in case
agreements with IS pertaining to HW/SW resources are not met.
 Evidence of monitoring selected supplier processes and evaluating selected work-products
 Evidence of training and deployment of the identified HW/SW resource in the project.

39 January 2007
Measurement & Analysis (MA) – An Overview

Purpose:
The purpose of Measurement and Analysis is to develop and sustain a
measurement capability that is used to support management information
needs

MA provides :
 Visibility into the process and projects’ cost, quality and performance by:
 Specifying the objectives of measurement and analysis such that they are aligned with the
organization’s information needs
 Selecting, implementing and specifying metrics, data collection and storage mechanisms,
analysis techniques, and reporting procedures
 Providing objective results that may be used in making informed decisions, and taking
appropriate corrective actions in a timely manner

 Key for program management and engineering management to see the current status of
progress in meeting requirements by customer, business performance and financial goals

40 January 2007
Measurement & Analysis

Goal 1: Measurement objectives and activities are aligned with identified

information needs and objectives.

 SP 1.1 Establish Measurement Objectives

 SP 1.2 Specify Measures
 SP 1.3 Specify Data Collection and Storage Procedures
 SP 1.4 Specify Analysis Procedures

Goal 2: Measurement results that address identified information needs and

objectives are provided.

 SP 2.1 Collect Measurement Data

 SP 2.2 Analyze Measurement Data
 SP 2.3 Store Data and Results
 SP 2.4 Communicate Results

41 January 2007
Measurement & Analysis

Goal 1: Measurement objectives and activities are aligned with identified

information needs and objectives.

 Quality Plan/Goals and objectives section in the Quality Plan with prioritized Quality
goals, with analysis to be performed on metrics clearly documented.
 Metrics data storage repository/tool used at project level to be specified in the Quality
plan and usage demonstrated

Goal 2: Measurement results that address identified information needs and

objectives are provided.

 Project should be able to demonstrate metrics data analysis used to track achievement
of the project goals that are defined in the Quality plan
 Data analysis and associated inferences to be available in the project specific Metrics
tool/SDMS.

42 January 2007
Measurement and Analysis – Weak Areas

 SP 1.1 - Establish and maintain measurement objectives that are derived from identified
information needs and objectives.
Improvement Areas :
 Quality plans to be revisited and revised wrt current scope of the project. Identification of
relevant metrics is essential.
 Customer defined goals have to be mentioned in the QP, Tailoring sections.
SP1.2 - Specify measures to address the measurement objectives.
Improvement Areas:
 Prioritization of metrics to be done inline with the customer objectives.
 Project specific goals to be mentioned in Tailoring section and aligned in metrics repository
SP1.3 - Specify how measurement data will be obtained and stored.
Improvement Areas:
 Accuracy of the data
 Usage of appropriate tools for Effort, schedule, defects and tickets.
SP 1.4 - Specify how measurement data will be analyzed and reported.
Improvement Areas:
 Awareness on the usage of statistical tools and techniques.

43 January 2007
Measurement and Analysis

 SP2.1- Obtain specified measurement data.

Improvement Areas
 Tracking and logging of schedule ,effort, defects and tickets to be improved.
 Accuracy of the data that gets logged/tracked
 SP2.2- Analyze and interpret measurement data.
Improvement Areas:
 Metrics analysis is done but inference is not drawn for many projects.
 Analysis to be done for all the identified sub processes at the project level.
 Actual benefits have not been realized out of the RCAs/ LAMs conducted in many cases
 SP2.3 - Manage and store measurement data, measurement specifications, and analysis
results.
Improvement Areas:
 Accuracy of the data.
 SP 2.4 - Report results of measurement and analysis activities to all relevant
stakeholders.
Improvement Areas:
 Project metrics efficiency to be reported in project status reports and CTR MOMs.

44 January 2007
Configuration Management (CM) – An Overview

Purpose:
The purpose of Configuration Management is to establish and maintain the
integrity of work products using configuration identification, configuration
control, configuration status accounting, and configuration audits

CM helps in :
 Preventing a chaotic work environment with uncontrolled changes
 Providing current information regarding configuration status
 Minimizing rework caused by updating wrong version
 Providing consistent baselines for internal use and customer delivery

45 January 2007
Configuration Management

Goal 1: Baselines of identified work products are established

 SP 1.1 Identify Configuration Items

 SP 1.2 Establish a Configuration Management System
 SP 1.3 Create or Release Baselines.

Goal 2: Changes to the work products under configuration management are

tracked and controlled

 SP 2.1 Track Change Requests

 SP 2.2 Control Configuration Items

Goal 3: Integrity of baselines is established and maintained

 SP 3.1 Establish Configuration Management Records

 SP 3.2 Perform Configuration Audits

46 January 2007
Configuration Management

Goal 1: Baselines of identified work products are established.

 Configuration Items identified in CM Plan. Baselines appropriate to project scope and
context are established.

Goal 2: Changes to the work products under configuration management are tracked and
controlled.
 Change requests with impact analysis recorded and tracked to closure.
 Revision history maintained for work-products under CM/Document Control. CM registers
and baselines indicating control over revisions to work-products.
 Doc Control/Change Control implemented for Work-products

Goal 3: Integrity of baselines is established and maintained.

 Control over the Configuration Items (CIs) identified in the CM plan to be evidenced as per
the CM system in place (manual or CM tool/SDMS)
 Physical presence of the CI /Doc Control Work-products to be demonstrated
 CM Audit reports/Configuration baseline audit reports to be evidenced.

47 January 2007
Configuration Management – Weak Areas

SP1.1- Identify the configuration items, components, and related work products that will be placed
under configuration management.
Improvement Areas:
CM Procedure and baseline procedure of project can be documented in detail in CM plan
CIs are not identified in CM plan.
Review records missing.
SP1.2 - Establish and maintain a configuration management and change management system for
controlling work products.
Improvement Areas:
Baseline register not maintained.
Back and Media control plan to be maintained
MLD not updated for CMP.
SP 1.3 - Create or release baselines for internal use and for delivery to the customer.
Improvement Areas:
CM audit not done.
Baseline register to be updated frequently

48 January 2007
Configuration Management – Weak Areas

SP2.1 - Track change requests for the configuration items.

Improvement Areas:
Change Mgmt process should be followed
SP2.2 - Control changes to the configuration items
Improvement Areas:
Change Mgmt process should be followed
SP3.1 - Establish and maintain records describing configuration items.
Improvement Areas:
CM tool should be used.
SP3.2- Perform configuration audits to maintain integrity of the configuration baselines.
Improvement Areas:.
CM audit report should be created. CM checklist not updated.
When code is promoted to production SCCb approval needed.
There is overlap in SCCB Group Members and SCM Group Members. As per process,
SOD needs to be ensured in these groups

49 January 2007
Product & Process Quality Assurance (PPQA) – An Overview

Purpose :
The purpose of Process and Product Quality Assurance is to provide staff
and management with objective insight into processes and associated
work products

Objective evaluation :
• “Independent group” from outside the project or within the project
• Using established criteria

PPQA helps :
• By providing visibility on how well projects have implemented the process they have
planned

PPQA vs Verification :
 PPQA ensures that planned processes are implemented
 Verification ensures that the specified requirements are satisfied.

50 January 2007
Product & Process Quality Assurance

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

 SP 1.1 Objectively Evaluate Processes

 SP 1.2 Objectively Evaluate Work Products and Services

Goal 2: Noncompliance issues are objectively tracked and communicated, and

resolution is ensured.

 SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues

 SP 2.2 Establish Records

51 January 2007
Product & Process Quality Assurance

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

 Process review reports/SQA Monthly process review report

 Project NCs if any

Goal 2: Noncompliance issues are objectively tracked and communicated, and

resolution is ensured.

 Process Review NC Closure

 Internal Audit/Appraisal NC Closure

52 January 2007
Level 3

Level 3 which is the Defined Level has 11 Process Areas as mentioned below:

 Requirements Development (RD)

 Technical Solution (TS)
 Product Integration (PI)
 Verification (VER)
 Validation (VAL)
 Organizational Process Focus (OPF)
 Organizational Process Definition (OPD)
 Organizational Training (OT)
 Integrated Project Management (IPM)
 Risk Management (RSKM)
 Decision Analysis and Resolution (DAR)

53 January 2007
Requirements Development (RD) – An Overview

Purpose:
The purpose of Requirements Development is to produce and analyze
customer, product, and product-component requirements

The primary scope of this process includes :

 Elicitation of customer needs, expectations and constraints to establish customer
requirements
 Establishment of initial product and product-component requirements
 Analysis and validation of requirements from all perspectives

54 January 2007
Requirements Development

Goal 1: Stakeholder needs, expectations, constraints, and interfaces are collected and
translated into customer requirements.

 SP 1.1 Elicit Needs

 SP 1.2 Develop the Customer Requirements

Goal 2: Customer requirements are refined and elaborated to develop product and product-
component requirements.

 SP 2.1 Establish Product and Product-Component Requirements

 SP 2.2 Allocate Product-Component Requirements
 SP 2.3 Identify Interface Requirements

Goal 3: The requirements are analyzed and validated, and a definition of required
functionality is developed.

 SP 3.1 Establish Operational Concepts and Scenarios

 SP 3.2 Establish a Definition of Required Functionality
 SP 3.3 Analyze Requirements
 SP 3.4 Analyze Requirements to Achieve Balance
 SP 3.5 Validate Requirements with Comprehensive Methods

55 January 2007
Requirements Development

Goal 1: Stakeholder needs, expectations, constraints, and interfaces are collected and
translated into customer requirements.

 Reviewed and approved Contractual documents e.g. SoW, DoU or RFP as

applicable specifying customer requirements.
Goal 2: Customer requirements are refined and elaborated to develop product and product-
component requirements.

 Component level Requirements/Objects/Development Requests and their interfaces are

established & documented.
 Change /Service Requests/PMRs/Tickets in case of Maintenance & Support type Projects

Goal 3: The requirements are analyzed and validated, and a definition of required
functionality is developed.

 Requirements with respect to end-user operating scenarios to be documented as appropriate

 Customer communication relating to clarifications sought or issues identified regarding the
requirements.
 Base-lined SRS/FS document for Development & Enhancement type Projects
 Change/Service Requests/Tickets and associated Problem Management Report or its
equivalent in case of Maintenance & Support type Projects

56 January 2007
Requirement Development – Weak Areas

SP1.1 - To obtain stakeholder needs, expectations, constraints, and interfaces for the
project.
Improvement Areas
Requirements with respect to end-user operating scenarios to be documented as
appropriate
Customer communication relating to clarifications sought or issues identified regarding the
requirements to be strengthened
SP 1.2 - Develop the Customer Requirements.
Improvement Areas
Business requirement analysis / review to be implemented/ strengthened.
SP2.1 - To establish product and product-component requirements,.
Improvement Areas
Linkage of DOU to operational aspects of requirements development is needed.
SP2.2 -To allocate product component requirements.
Improvement Areas
Component level Requirements/Objects/Development Requests and their interfaces are
established & documented

57 January 2007
Requirement development – Weak Areas

SP2.3 - To Identify interface requirements

Improvement Areas
Interface Specification/User Interface Conceptual Model details to be addressed.
SP3.1 - To establish operational concepts and Scenarios.
Improvement Areas
For Dev. Project, SRS/Use Case Model and for SWE Project, SPDP vigorously followed
SP3.2- To establish a Definition of Required Functionality.
Improvement Areas;
This SP needs examination and greater education to practitioners and also strengthened Revision
history or CR's details w.r.t. requirements
SP3.3 - Analyze Requirements.
Improvement Areas
Use of Requirements Verification Checklist to be strengthened.
SP3.4 - To analyze Requirements to Achieve Balance.
Improvement Areas
Assumption, Issues and Risks to be captured.
Requirement related review comments properly captured in the WPI Form/customer mandated tool.
SP3.5 - Validate Requirements with Comprehensive Methods.
Improvement Areas
Business Requirements/System Requirements Review Results with customer needs lo of improvement
and also needs greater education to practitioners how to review BR/SR results with customer.

58 January 2007
Technical Solution (TS) – An Overview

Purpose:
The purpose of Technical Solution is to design, develop, and implement
solutions to requirements. Solutions, designs, and implementations
encompass products, product components, and product-related life-cycle
processes either singly or in combinations as appropriate

TS Involves:
 Evaluating alternatives and selecting solutions that potentially satisfy a set of
allocated requirements
 Developing detailed designs for the selected solution
 Implementing the design as a product or product component

Scope of TS :
 High Level design, low level design, Coding and Unit test

59 January 2007
Technical Solution

Goal 1 : Product or product component solutions are selected from alternative solutions

 SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria

 SP 1.2 Select Product-Component Solutions

Goal 2 : Product or product component designs are developed

 SP 2.1 Design the Product or Product Component

 SP 2.2 Establish a Technical Data Package
 SP 2.3 Design Interfaces Using Criteria
 SP 2.4 Perform Make, Buy, or Reuse Analyses

Goal 3 : Product components, and associated support documentation, are

implemented from their designs

 SP 3.1 Implement the Design

 SP 3.2 Develop Product Support Documentation

60 January 2007
Technical Solution

Goal 1 : Product or product component solutions are selected from alternative

solutions

 Design/Resolution Alternatives are evaluated against a documented criteria

and rationale for selecting the preferred alternative is documented in the
Design Doc/TS/relevant work-product

Goal 2 : Product or product component designs are developed

 Software Design Doc/Tech Spec and Program Specs/FS or TS as applicable

Goal 3 : Product components, and associated support documentation, are

implemented from their designs

 Coding and Unit test phase/bug fix completion

 Established Coding Methods and standards used
 End-user documentation/User documentation as applicable

61 January 2007
Technical Solution – Weak Areas

SP1.1- Develop alternative solutions and selection criteria

Improvement Areas
Alternative solutions need to be developed where ever it is applicable
Solution selection criteria/mechanism should be used
SP1.2- Select the product-component solutions that best satisfy the criteria
established.
Improvement Areas:
Uses of proper Review Log to record all review defects
Uses of Requirement Trace ability Matrix
SP2.1 - Develop a design for the product or product component.
Improvement Areas:
Proper review of Technical document
Uses of review log to record all design related defects
SP2.2- Establish and maintain a technical data package.
Improvement Areas:
Client Review records needs to be captured

62 January 2007
Technical Solution – Weak Areas

SP2.3 -Design product-component interfaces in terms of established criteria.

Improvement Areas:
Proper updating of Requirement Traceability Matrix
Mandate Review Process Capturing all review defects
SP2.4 - Evaluate whether the product components should be developed, purchased, or
reused based on established criteria.
Improvement Areas:
Alternative decision for developing or reusing of components/Module needs to
strengthen
SP3.1 - Implement the designs of the product components
Improvement Areas:
Proper uses/Awareness of code review checklist
Proper logging of all Coding und unit testing defects
SP3.2 - Develop and maintain the end-use documentation
Improvement Areas:
User manual, help file needs to be reviewed before releasing

63 January 2007
Product Integration (PI) – An Overview

Purpose:
The purpose of Product Integration is to assemble the product from the
product components, ensure that the product, as integrated, functions
properly, and deliver the product

PI Involves:
 Achieving complete product integration through assembly of product components
according to a defined integration sequence and procedure
 Incremental process of integrating product components, evaluating inter-operability and
then assembling more product components
 Management of external and internal interfaces to ensure compatibility among the
interfaces

Impact of PI :
 Can have significant influence on getting system interfaces “ right”
 Improves the probability that the integrated product will pass product validation

64 January 2007
Product Integration

Goal 1: Preparation for product integration is conducted.

 SP 1.1 Determine Integration Sequence

 SP 1.2 Establish the Product Integration Environment
 SP 1.3 Establish Product Integration Procedures and Criteria

Goal 2: The product-component interfaces, both internal and external, are

compatible.
 SP 2.1 Review Interface Descriptions for Completeness
 SP 2.2 Manage Interfaces

Goal 3: Verified product components are assembled and the integrated, verified,
and validated product is delivered.

 SP 3.1 Confirm Readiness of Product Components for Integration

 SP 3.2 Assemble Product Components
 SP 3.3 Evaluate Assembled Product Components
 SP 3.4 Package and Deliver the Product or Product Component

65 January 2007
Product Integration

Goal 1: Preparation for product integration is conducted.

 Defined integration sequence

• In case there were more than one integration option, then documentation to
show that all options were evaluated and that the best integration option was
arrived at.
 Build Plan and Build Procedures to be included or referenced in the PMMS/CM
Plan
 Integration Environment updated in the Test Plan/Technical Environment Plan

Goal 2: The product-component interfaces, both internal and external, are

compatible.

 Reviewed, approved and base-lined SDD/Technical Specification (TS) document

for Development & Enhancement type Projects, which lists internal and external
interfaces
 Formal control on changes to SDD/TS
 Test/Review records in the case of Maintenance Projects

66 January 2007
Product Integration (Continued)

Goal 3: Verified product components are assembled and the integrated, verified,
and validated product is delivered.

 Criteria to start and end Build phase is met (Checklist for Software Build used as
applicable)
 Successful completion of Integration Testing/Unit Testing/Regression test/Scenario
Test as applicable
 Product certification as applicable
 Release notes/delivery mail for DERs/objects/Service Requests as applicable

67 January 2007
Product Integration – Weak Areas

SP 1.1 – Determine Integration Sequence

Improvement Areas :
Non availability of PI plan on projects
Clarity in applicability of PI in projects
SP 1.2 – Establish the Product Integration Environment
Improvement Areas :
Availability of a separate build environment. In general, Dev environment is used to create build.
SP 1.3 – Establish and maintain procedures and criteria for integration of the product
components.
Improvement Areas :
Clarity on product integration exit criteria, and PI verification and validation activities. Use of work
product inspection checklist etc. may be required.
SP 2.1 – Review Interface Descriptions for Completeness
Improvement Areas :
Maintenance projects need clarity on what comprises an interface and how are the details maintained.
SP 2.2 – Manage Interfaces
Improvement Areas :
Usually out of scope for GD team. Needs thorough analysis, project facilitation / awareness sessions and
renewed deployment . PA awareness is a weak area.

68 January 2007
Product Integration – Weak Areas

SP 3.1 – Confirm Readiness of Product Components for Integration-

Improvement Areas :
Pre-build readiness review not evident in most projects.
Use of build readiness checklists
SP3.2- Assemble Product Components
Improvement Areas
Clarity on end to end packaging from Geo+GD perspective may enhance compliance

SP 3.3 – Evaluate Assembled Product Components-

Improvement Areas
Sanity check on assembled package.
SP3.4- Package and Deliver the Product or Product Component

Improvement Areas
Actual deployment of builds not evidenced

69 January 2007
Verification (VER) – An Overview

Purpose:
The purpose of Verification is to ensure that selected work products meet
their specified requirements

 Verification starts early with verification of requirements

 Peer Reviews mandated among the Verification methods
 Verification can be performed on product and on intermediate work products
against all selected requirements

VER Supports In:

 Early identification of design errors and omissions
 Early identification of program risks and errors
 Provides a measure of requirement compliance
 Reduced costs
 Improved delivery schedule
70 January 2007
Verification

Goal 1: Preparation for verification is conducted.

 SP 1.1 Select Work Products for Verification

 SP 1.2 Establish the Verification Environment
 SP 1.3 Establish Verification Procedures and Criteria

Goal 2: Peer reviews are performed on selected work products.

 SP 2.1 Prepare for Peer Reviews

 SP 2.2 Conduct Peer Reviews
 SP 2.3 Analyze Peer Review Data

Goal 3: Selected work products are verified against their specified requirements.

 SP 3.1 Perform Verification

 SP 3.2 Analyze Verification Results

71 January 2007
Verification

Goal 1: Preparation for verification is conducted.

 V&V section of the Quality plan identifying work-products to be reviewed/tested

 Evidence of planned and scheduled reviews indicating work-products/object deliverables that
are to be reviewed
 Evidence of Test Plans and various types of tests planned for the project

Goal 2: Peer reviews are performed on selected work products.

 Evidence of Peer reviews conducted on work-products as planned. These may include:

• Review schedules for various work products
• Review defects with resolution details.

Goal 3: Selected work products are verified against their specified requirements.

 Evidence of Test logs/executed UTP for tests conducted

 Defect log of tests conducted with resolution details

72 January 2007
Verification – Weak Areas

SP1.1 - Select the work products to be verified and the verification methods
that will be used for each .
Improvement Areas
The process of verification may be defined in more details
SP1.2- Establish and maintain the environment needed to support
verification .
Improvement Areas:
Test Plan should be mandatory for all the projects (if in scope)
SP1.3- Establish and maintain verification procedures and criteria for the
selected work products
Improvement Areas:
Availability of test plan and test strategy document
SP2.1 - Prepare for peer reviews of selected work products .
Improvement Areas
In some project detail level plan/schedule not available

73 January 2007
Verification – Weak Areas

SP2.2- Conduct peer reviews on selected work products and identify issues
resulting from the peer review.
Improvement Areas:
In some cases review records are not properly maintained
SP2.3 - Analyze data about preparation, conduct, and results of the peer
reviews
Improvement Areas:
Analysis of review data and RCA

74 January 2007
Validation (VAL) – An Overview

Purpose :
The purpose of Validation is to demonstrate that a product or product
component fulfills its intended use when placed in its intended
environment

VAL vs Ver
 Validation demonstrates that the product as built (or will be built) satisfies it’s
intended use
 Verification demonstrates that the work-product satisfies its specified
requirements
 Validation can be performed early on identified work-products
 On occasion, both Ver & Val may address the same activity

75 January 2007
Validation

Goal 1: Preparation for validation is conducted.

 SP 1.1 Select Products for Validation

 SP 1.2 Establish the Validation Environment
 SP 1.3 Establish Validation Procedures and Criteria

Goal 2: The product or product components are validated to ensure

that they are suitable for use in their intended operating environment.

 SP 2.1 Perform Validation

 SP 2.2 Analyze Validation Results

76 January 2007
Validation

Goal 1: Preparation for validation is conducted.

 V&V section of the Quality plan identifying the final test/review activities to be
performed prior to releasing the work-product/fix
 System/Acceptance Test Plan/pre-release test plans as applicable for the
project

Goal 2: The product or product components are validated to ensure

that they are suitable for use in their intended operating environment.

 Evidence of validation tests conducted with resolution details

77 January 2007
Validation – Weak Areas

SP1.1- Select products and product components to be validated and the validation
methods that will be used for each .
Improvement Area:
No Gap found.
SP1.2 - Establish and maintain the environment needed to support validation
Improvement Areas
Completeness of Master Test plan
SP1.3 - Establish and maintain procedures and criteria for validation .
Improvement Areas
Correct documentation of Test strategy.
Documentation of SIT, UAT plan.
SP2.1 - Perform validation on the selected products and product components
Improvement Areas
None
SP 2.2 -Analyze the results of the validation activities
Improvement Areas
Analysis of Test data

78 January 2007
Organization Training (OT) – An Overview

Importance of OT:
Organizational Training develops the skills and knowledge of employees so
they can perform their roles effectively and efficiently as follows:

 Identifies “common” training needed by the organization In technical, organizational, or

contextual areas.
 Establishes the capability to provide training
 Obtains and provides the identified training
 Maintains training records
 Assesses the effectiveness of the training

“Training” includes both formal & informal vehicles :

 Classroom
 Web-based Training, CBTs
 Formalized on-the-job Training
 Mentoring

79 January 2007
Organization Training
Goal 1 : A training capability that supports organization’s management and
technical roles is established and maintained.

 SP 1.1 Establish the Strategic Training Needs

 SP 1.2 Determine Which Training Needs Are the Responsibility of the
Organization
 SP 1.3 Establish an Organizational Training Tactical Plan
 SP 1.4 Establish Training Capability
Goal 2: Training necessary for individuals to perform their roles effectively is
provided
 SP 2.1 Deliver Training
 SP 2.2 Establish Training Records
 SP 2.3 Assess Training Effectiveness

80 January 2007
Organization Training
Goal 1 : A training capability that supports organization’s management and
technical roles is established and maintained.
Implemented at the Org level by centralized team (eg CoC in India)
 CoC process with Roles & Responsibilities of CoC group
included
 List of internal faculty/empanelled training vendors available with CoC
 Courseware
 ITS System with training calendar published, Global Campus, Training CBTs
 Training requirements from various groups

Goal 2: Training necessary for individuals to perform their roles effectively is

provided

 Skills needed in project identified in the training plan / Training Plan in PMSS
and Training Tracker.
 Training records /Training tracker showing practitioner wise training records
where training has been completed as per Training plan.
 Training Effectiveness Surveys and resulting actions tracked to closure

81 January 2007
Integrated Project Management (IPM) – An Overview
Purpose:
The purpose of Integrated Project Management is to establish and manage the
project and the involvement of the relevant stakeholders according to an integrated
and defined process that is tailored from the organization's set of standard
processes.

IPM Involves:
 Establishing the project's defined process by tailoring the organization's set of standard
processes
 Managing the project using the project’s defined process
 Using and contributing to the organizational process assets
 Ensuring that the relevant stakeholders perform their tasks in a coordinated and timely
manner:
 to address product and product-component requirements, plans, objectives, issues, and risks;
 to fulfill their commitments; and
 to identify, track, and resolve issues

82 January 2007
Integrated Project Management

Goal 1: The project is conducted using a defined process that is tailored

from the organization's set of standard processes.

 SP 1.1 Establish the Project’s Defined Process

 SP 1.2 Use Organizational Process Assets for Planning Project Activities
 SP 1.3 Establish the Project’s Work Environment
 SP 1.4 Integrate Plans
 SP 1.5 Manage the Project Using the Integrated Plans
 SP 1.6 Contribute to the Organizational Process Assets

Goal 2: Coordination and collaboration of the project with relevant

stakeholders is conducted
 SP 2.1 Manage Stakeholder Involvement
 SP 2.2 Manage Dependencies
 SP 2.3 Resolve Coordination Issues

83 January 2007
Integrated Project Management

Goal 1: The project is conducted using a defined process that is tailored

from the organization's set of standard processes.

 Approved project / quality plan/ auxiliary plans with details on process tailoring as
applicable.
 Assets re-used from other projects to be identified.

Goal 2: Coordination and collaboration of the project with relevant

stakeholders is conducted.

 Approved and released project plan with details on dependencies with other
groups (e.g.. IS/CoC/other IBM entities) as applicable

 Project tracking status reports with issue tracking status /Project monthly or weekly
status report/SDMS issue log showing tracking of issues and dependencies with
stakeholders.

84 January 2007
Risk Management (RSKM) – An Overview

Importance of RSKM:
The purpose of Risk Management is to identify potential problems before
they occur, so that risk-handling activities may be planned and invoked as
needed across the life of the product or project to mitigate adverse
impacts on achieving objectives

Risk Management can be divided into three parts:

 defining a risk management strategy;
 identifying and analyzing risks;
 and handling identified risks, including the implementation of risk mitigation
plans when needed

85 January 2007
Risk Management

Goal 1: Preparation for risk management is conducted

 SP 1.1 Determine Risk Sources and Categories

 SP 1.2 Define Risk Parameters
 SP 1.3 Establish a Risk Management Strategy

Goal 2: Risks are identified and analyzed to determine their relative

importance
 SP 2.1 Identify Risks
 SP 2.2 Evaluate, Categorize, and Prioritize Risks
Goal 3: Risks are handled and mitigated, where appropriate, to reduce
adverse impacts on achieving objectives.
 SP 3.1 Develop Risk Mitigation Plans
 SP 3.2 Implement Risk Mitigation Plans

86 January 2007
Risk Management

Goal 1: Preparation for risk management is conducted.

 A reviewed and approved Risk Management Plan

Goal 2: Risks are identified and analyzed to determine their relative

importance.

 Risks identified, evaluated and prioritized in the Risk Log/Tracker

Goal 3: Risks are handled and mitigated, where appropriate, to reduce

adverse impacts on achieving objectives.

 Risk Tracking sheet showing tracking of action/mitigation plans for risks identified
 Status report on Risk status in the PL to PM and PM to Senior Management report.
 Risk Mitigation ratio for projects, i.e. Risk mitigated/Risk Identified and reported

87 January 2007
Risk Management – Weak Areas

SP1.1 - Determine risk sources and categories.

Improvement Areas
Using Historical data for identifying the Risks and categories.
Usage of GS risk tool for determining Risk sources
SP1.2 - Define the parameters used to analyze and categorize risks, and the parameters
used to control the risk management effort.
Improvement Areas
Defining Risk thresholds.
Using Continuous Risk Management guideline.
SP1.3 - Establish and maintain the strategy to be used for risk management.
Improvement Areas
Defining Risk strategy and effective implementation of the plan.
SP2.1 - Identify and document the risks.
Improvement Areas:
Risks defined in RPM scope elements to be complete and effective in terms of timely
updating of all Risk parameters.
Use of formal methods and tools for identifying Risks.

88 January 2007
Risk Management – Weak Areas

SP2.2 -Evaluate and categorize each identified risk using the defined risk categories and
parameters, and determine its relative priority.
Improvement Areas:
Risk categorization and prioritization effectively.

SP 3.1- Develop a risk mitigation plan for the most important risks to the project, as defined
by risk management strategy.
Improvement Areas:
Achieving effective Risk mitigation planning
SP3.2 - Monitor the status of each risk periodically and implement the risk mitigation plan
as appropriate.
Improvement Areas:
Effective Risk tracking.
Maintaining the identified Risks and the Risks that are tracked to be synchronized.
Achieving effective Risk Mitigation.
PL to PM status report to reflect current risks status

89 January 2007
Decision Analysis & Resolution (DAR) – An Overview

Purpose:
The purpose of Decision Analysis and Resolution is to analyze possible
decisions using a formal evaluation process that evaluates identified
alternatives against established criteria

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

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

90 January 2007
Decision Analysis & Resolution

Goal 1: Decisions are based on an evaluation of alternatives using established

criteria.

 SP 1.1 Establish Guidelines for Decision Analysis

 SP 1.2 Establish Evaluation Criteria
 SP 1.3 Identify Alternative Solutions
 SP 1.4 Select Evaluation Methods
 SP 1.5 Evaluate Alternatives
 SP 1.6 Select Solutions

91 January 2007
Decision Analysis & Resolution

Goal 1: Decisions are based on an evaluation of alternatives using established

criteria.

 Formal decision analysis details recorded on the prescribed DAR template.

 Formal Decisions submitted to the org repository
 Status on Formal Decisions taken, reported from PM to Senior Management

92 January 2007
DAR- Weak Areas

SP1.1- Establish and maintain guidelines to determine which issues are subject
to a formal evaluation process.
Improvement Areas
Very few accounts it is noticed that this criteria is not mentioned clearly as per
Opal key decision procedure.
SP 1.2 – SP 1.6 is Unsat in many accounts.
Key decisions applied informally but not documented.
Awareness of account team on DAR application
SP1.2 - Establish and maintain the criteria for evaluating alternatives, and the
relative ranking of these criteria.
Improvement Areas
Review comments on DAR applied.
MOM for the key decisions made.

93 January 2007
DAR- Weak Areas

SP1.3 - Identify alternative solutions to address issues.

Improvement Areas:
Key decisions applied informally but not documented or key decision record not maintained.

SP1.4 - Select the evaluation methods.

Improvement Areas:
Very few accounts are applied this procedure.
Awareness of account team on key decision procedure application.
Key decisions made informally no key decision record maintained

SP1.5- Evaluate alternative solutions using the established criteria and methods.
Improvement Areas:
Very few accounts are applied it.
Awareness of account team on key decision procedure application.
Key decision record showing alternative solution found in very few cases.

SP 1.5- Select solutions from the alternatives based on the evaluation criteria.
Improvements

Very few Accounts are consistently applying this procedure.

Key decision record showing the alternatives.

94 January 2007
Organization Process Focus (OPF) – An Overview

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

OPF Involves:
Identifying Process Improvements to the organization’s process
Developing and implementing a Process Action plan to implement and deploy
the improvements across the organizations

The organization provides the long-term commitment and resources required to

sponsor a dedicated ‘Process Group’. This group is responsible for managing the
organizations’ PI activities

95 January 2007
Organization Process Focus

Goal 1 : Strengths, weaknesses and improvement opportunities for the

organizations processes are identified periodically and as needed.

 SP 1.1 Establish Organizational Process Needs

 SP 1.2 Appraise the Organization’s Processes
 SP 1.3 Identify the Organization's Process Improvements

Goal 2 : Plan and implement Process-Improvement Activities

 SP 2.1 Establish Process Action Plans
 SP 2.2 Implement Process Action Plans

SG 3 : Deploy Organizational Process Assets and Incorporate Lessons Learned

 SP 3.1 Deploy Organizational Process Assets

 SP 3.2 Deploy Standard Processes
 SP 3.3 Monitor Implementation
 SP 2.4 Incorporate Process-Related Experiences into the Organizational
Process Assets

96 January 2007
Organization Process Focus

Goal 1 : Strengths, weaknesses and improvement opportunities for the

organizations processes are identified periodically and as needed.

Implemented at the Org Level (Quality Group Level)

 Approved Annual Quality Goals & Strategy document
 ISO Surveillance Audit reports from BVQI
 Internal Audit/Appraisal Findings
 Process Improvements selected for implementation

Goal 2 : Plan and implement Process-Improvement Activities.

Implemented at the Org Level (Quality Group Level)
 Process Implementation plans
SG 3 : Deploy Organizational Process Assets and Incorporate Lessons Learned
 Release Notes with Transition Instructions
 Release Notes on Tool Enhancements
 Deployment of Process Tools such as QSC (Quality Self-Certification Tool)
 List of target projects with process deployment status tracked
 Results of Implementation reviews and Monitoring of process implementation

97 January 2007
Organization Process Definition (OPD) – An Overview

Purpose (OPD)
The purpose of Organizational Process Definition is to establish and maintain a
usable set of organizational process assets

OPD Involves establishment of the following at the organizational level:

 Organization’s Standard Processes
 Recommended Life-Cycle Model Descriptions
 Tailoring Criteria and Guidelines
 Measurement Repository
 Process Asset Library
 Work Environment Standards

Organizational process assets enable consistent process performance across the

organization and provide a basis for cumulative, long-term benefits to the organization by
allowing the sharing of best practices and lessons learned across the organization

98 January 2007
Organization Process Definition

Goal 1 : Establish Organizational Process Assets

 SP 1.1 Establish Standard Processes

 SP 1.2 Establish Life-Cycle Model Descriptions
 SP 1.3 Establish Tailoring Criteria and Guidelines
 SP 1.4 Establish the Organization’s Measurement Repository
 SP 1.5 Establish the Organization’s Process Asset Library
 SP 1.6 Establish Work Environment Standards

99 January 2007
Organization Process Definition

Goal 1 : Establish Organizational Process Assets

Implemented at the Org Level (Quality Group Level)

 Organizations’ Published Quality Management System
 Published Tailoring Guidelines
 Recommended set of Software Lifecycles published
 Metrics Repository implemented and used
 Process asset libraries implemented and used
 Organizational Work Environment Standards published for eg on the ORD of
OPAL

100 January 2007

LEVEL 4

Level 4 which is the Quantitatively Managed Level has 2 Process Areas as

mentioned below:

 Organization Process Performance (OPP)

 Quantitative Project Management (QPM)

101 January 2007

Organization Process Performance (OPP) – An Overview

OPP Involves:
The purpose of Organizational Process Performance is to establish and
maintain a quantitative understanding of the performance of the
organization’s set of standard processes in support of quality and process-
performance objectives, and to provide the process performance data,
baselines, and models to quantitatively manage the organization’s projects

OPP provides:
 the process performance baselines, and models
 the quantitative objectives for quality and process performance

102 January 2007

Organization Process Performance

Goal 1: Baselines and models that characterize the expected process

performance of the organization's set of standard processes are established
and maintained.

 SP 1.1 Select Processes

 SP 1.2 Establish Process Performance Measures
 SP 1.3 Establish Quality and Process-Performance Objectives
 SP 1.4 Establish Process Performance Baselines
 SP 1.5 Establish Process Performance Models

103 January 2007

Organization Process Performance

Goal 1: Baselines and models that characterize the expected process

performance of the organization's set of standard processes are established
and maintained.

 Process Performance baselines published for use

 Organizations performance objectives which can be demonstrated to be mapped
to the organizations business objectives, and to the actual performance baselines
 Defect prediction/estimation Models documented in the org processes

104 January 2007

Quantitative Project Management (QPM) – An Overview

Importance of QPM:
The purpose of the Quantitative Project Management process area is to
quantitatively manage the project’s defined process to achieve the project’s
established quality and process-performance objectives

QPM provides:
 Basis for achieving predictability
 Basis for making realistic commitments
 Basis for management by fact
 Basis for addressing systematic improvements

105 January 2007

Quantitative Project Management (QPM) – An Overview

QPM Involves:
 Establishing of quantitative objectives based on organization’s business
objectives and the needs of the customer
 Identifying the sub-processes that are to be brought under statistical
management
 Identifying and addressing special causes of variations for the sub-processes
selected for statistical management
 Managing each of the selected sub-processes, with the objective of bringing
their performance within natural bounds (i.e., making the sub-process
performance statistically stable and predictable based on the selected product
and process attributes)
 Predicting the ability of the process to satisfy established quantitative quality
and process-performance objectives
 Taking appropriate corrective actions when it is determined that the established
quantitative quality and process-performance objectives will not be satisfied

106 January 2007

 Quantitative Project Management

Goal 1: The project is quantitatively managed using quality and process-performance

objectives.

 SP 1.1 Establish the Project’s Objectives

 SP 1.2 Compose the Defined Process
 SP 1.3 Select the Sub-processes that Will Be Statistically Managed
 SP 1.4 Manage Project Performance

Goal 2: The performance of selected sub processes within the project's defined
process is statistically managed.
 SP 2.1 Select Measures and Analytic Techniques
 SP 2.2 Apply Statistical Methods to Understand Variation
 SP 2.3 Monitor Performance of the Selected Sub-processes
 SP 2.4 Record Statistical Management Data

107 January 2007

 Quantitative Project Management

Goal 1: The project is quantitatively managed using quality and process-

performance objectives.

 Prioritization of project objectives/Goals with criteria /rationale

 Set of Sub-processes selected for statistical management & criteria used for
selection to be documented in the Quality Plan – goals and objectives section
 RCA / corrective action, if determined that project’s Quality Goals/Acceptable
limits would not be met
 Use of prediction models

Goal 2: The performance of selected sub processes within the project's defined
process is statistically managed.
 Evidence that selected sub-processes are statistically managed using control
charts
 RCA performed in case of process capability deficiency of the sub-process
 Revision of Quality goals/acceptable limits, control limits and models based on
projects historical data

108 January 2007

QPM- Weak Areas

 SP1.1- Establish and maintain the project's quality and process-performance objectives
Improvement Areas
 Appropriate Defect prevention model is not defined in few projects
 Quality goals are not revised
 Customer defined metrics are not identified during quality planning
 SP1.2 - Select the sub processes that compose the project's defined process based on
historical stability and capability data.
Improvement Areas:
 Sub processes are not identified and tracked
 Goals are not revised based on historical data
 SP1.3 - Select the sub processes of the project's defined process that will be statistically
managed.
Improvement Areas:
 Appropriate Sub process identification not done w.r.t. project scope and context in few
projects
 Metrics / objectives are not prioritized
 Customer defined goals need to be statistically managed
 No Metrics related risks identified which are different from IBM defined metrics
 Few projects have not analyzed the data for year 2009

109 January 2007

QPM- Weak Areas

 SP1.4 -Monitor the project to determine whether the project's objectives for quality and process
performance will be satisfied, and identify corrective action as appropriate.
Improvement Areas:
 Process Performance Model is not monitored
 RCA not done for the goals missed as per plan
 PL to PM report doesn’t include status on process & product quality goal.
 Pending corrective and preventive action items are not closed
 Statistical techniques are not used to analyze data
 Effectiveness of Metrics is not covered in P3 CTR meetings
SP2.1-Select the measures and analytic techniques to be used in statistically managing the selected sub
processes.
Improvement Areas:
 Statistical techniques for managing sub process not defined in QP in most of the projects
 Sub processes identified in QP are not inline with project scope
SP2.2-Establish and maintain an understanding of the variation of the selected sub processes using the
selected measures and analytic techniques
Improvement Areas:
 Most of the Sub processes are not tracked
 Support activities are not tracked statistically
 Actions are not tracked to closure in RADAR Tool

110 January 2007

QPM- Weak Areas

 SP2.3 - Monitor the performance of the selected sub processes to determine

their capability to satisfy their quality and process-performance objectives, and
identify corrective action as necessary
Improvement Areas:
 Capability analysis not done
 Defect prediction models are not used in the projects
 Corrective and preventive actions taken for goal slippages not evidenced
 Corrective and Preventive actions are not closed in RADAR tool

 SP 2.4 - Record statistical and quality management data in the organization's

measurement repository
Improvement Areas:
 Partial projects metrics data submitted into org. repository in few projects

111 January 2007

LEVEL 5

Level 5 which is the Optimizing Level has 2 Process Areas as mentioned below:

 Organizational Innovation and Deployment (OID)

 Causal Analysis and Resolution (CAR)

112 January 2007

Organization Innovation and Deployment (OID) – An Overview

Purpose:
The purpose of Organizational Innovation and Deployment is to select and
deploy incremental and innovative improvements that measurably improve the
organization's processes and technologies. The improvements support the
organization's quality and process-performance objectives as derived from the
organization's business objectives
OID involves:
Selection and deployment of improvement based on quantitative understanding of the organization’s
current performance.

Process and technology improvements are selected from based on the following criteria:
 A quantitative understanding of the organization's current quality and process performance
 The organization's quality and process-performance objectives
 Estimates of the improvement in quality and process performance resulting from deploying the process
and technology improvements
 Estimated costs of deploying process and technology improvements, and the resources and funding
available for such deployment

113 January 2007

Organizational Innovation and Deployment

Goal 1: Process and technology improvements that contribute to

meeting quality and process-performance objectives are selected

 SP 1.1 Collect and Analyze Improvement Proposals

 SP 1.2 Identify and Analyze Innovations
 SP 1.3 Pilot Improvements
 SP 1.4 Select Improvements for Deployment

Goal 2: Measurable improvements to the organization's processes and

technologies are continually and systematically deployed

 SP 2.1 Plan the Deployment

 SP 2.2 Manage the Deployment
 SP 2.3 Measure Improvement Effects

114 January 2007

Organizational Innovation and Deployment

Goal 1: Process and technology improvements that contribute to meeting quality

and process-performance objectives are selected.

 Selection of the improvement to be backed up by evaluation reports which

include the estimated effect on the projects quality objectives/customer sat
objectives
 Proposal Evaluation for new technology/process improvement as applicable.
 Pilot Plan ( if any new process/tools being introduced) and Pilot results summary
report
• Pilot plan to include quantitative criteria for evaluation of results
• Pilot results should indicate expected improvement in the performance
baselines

Goal 2: Measurable improvements to the organization's processes and

technologies are continually and systematically deployed.

 Process/Technology Deployment Plan and results of monitoring the same

 Improvements to the baselines as a result of the deployment

115 January 2007

 Causal Analysis and Resolution (CAR) – An Overview

Purpose:
The purpose of Causal Analysis and Resolution is to identify causes of
defects and other problems and take action to prevent them from occurring in
the future
CAR Involves:
 Identifying and analyzing causes of defects and other problems
 Taking specific actions to remove the causes and prevent the occurrence of those types of
defects and problems in the future
Quantitative Basis:
 Process Capability deficiencies included in the scope of this PA
 Changed process to result in improved process performance/process capability
 Focus is on Common Causes of Defects, i.e on a stable process
CAR Helps In :
 Identifying and removing root causes of defects and preventing their reoccurrence
 Improving productivity and avoiding rework
 Capturing Lessons learned

116 January 2007

Causal Analysis and Resolution

Goal 1: Root causes of defects and other problems are systematically

determined.
 SP 1.1 Select Defect Data for Analysis
 SP 1.2 Analyze Causes

Goal 2: Root causes of defects and other problems are systematically

addressed to prevent their future occurrence.
 SP 2.1 Implement the Action Proposals
 SP 2.2 Evaluate the Effect of Changes
 SP 2.3 Record Data

117 January 2007

Causal Analysis and Resolution

Goal 1: Root causes of defects and other problems are systematically

determined.

 Pareto Analysis performed on in-process defects to select defects for further

analysis

 RCA performed associated with triggers other than Quality Goals/acceptable

limits not met i.e for common causes of defects (For example : process capability
issues)

118 January 2007

Causal Analysis and Resolution

Goal 2: Root causes of defects and other problems are systematically

addressed to prevent their future occurrence.

 Actions identified as a result of the Root Cause Analysis, tracked to closure

 Quantitative evidence that shows that the common causes of defects have been
eliminated/reduced by the corrective and preventive actions taken as per triggers
in DP plan implementation.
 Improved process capability (reduced limits) or process performance (shift in the
mean)
 Trend analysis reports demonstrating defects reduction as a part of Projects
report ( e.g.. monthly status report or referenced metrics views).

119 January 2007

CAR- Weak Areas

 SP1.1- Select the defects and other problems for analysis.

Improvement Areas
 Awareness on CAR tools and the usage.
 Project specific triggers are identified but not relevant to the project
 SP1.2-Perform causal analysis of selected defects and other problems and propose actions to
address them.
Improvement Areas:
 Awareness on the usage of CAR tools and techniques
 SP2.1- Implement the selected action proposals that were developed in causal analysis.
Improvement Areas:
 Actual benefits/ Implementation results to be shown in many projects
 SP 2.2- Evaluate the effect of changes on process performance.
Improvement Areas:
 Awareness on the usage of CAR tools and techniques
 Usage of PPMs
SP 2.3 - Record causal analysis and resolution data for use across the project and organization.
Improvement Areas:
 Actual benefits/Recommendations/Implementation out of RCA/LAM action items to be tracked
 Awareness on DP concepts and CAR techniques.

120 January 2007

CMMI IRR1 Review checklist

121 January 2007

Thank you

122
Additional Details for implementing GPs

 GP 2.2 : Plan the Process:

 A plan covering the activities needed to perform the process and achieve the established objectives, a process
description, and agreement on the plan from relevant stakeholders.

 GP2.3 : Provide Resources

 Tracking to demonstrate that the resources necessary to perform the process as defined by the plan are available
when needed. Resources include adequate funding, appropriate physical facilities, skilled people, and appropriate
tools etc.

 GP 2.5 : Provide Training

 The training provided may be formal (e.g., classroom, CBT) or informal (e.g., structured mentoring), and may vary
according to assigned role (e.g. detailed training for those performing the work, orientation overview provided to
those who interact or support those performing the work).
 The training need not be provided on a PA basis; a single training course could cover multiple processes.
 An approved waiver, stating that an individual possesses the skills and knowledge imparted in the course, is
equivalent to having received training.

 GP 2.7 : Plan Stakeholder Involvement:

 A ‘stakeholder’ is a group or individual that is affected by or in some way accountable for the outcome of an
undertaking. Stakeholders may include project members, suppliers, customers, end users, and others.
 The term ‘relevant stakeholder’ is used to designate a stakeholder that is identified for involvement in specified
activities and is included in the respective Project Plan document.

BACK

123 January 2007

Additional Details for implementing GPs

 GP 2.8 : Monitor and Control the process:

 The purpose of this practice is to perform the direct day-to-day monitoring and controlling of the process.
 Implementation evidences expected are:
 Measures of actual performance against plan , Progress tracking reports, e.g. status reports, Evidence of reviews
of activities, status, and results of the process held with immediate level of management responsible for the
process and identification of issues, Issues and corrective actions for deviations from plan (e.g., action items,
variance reports, change requests etc).

 GP 2.10 : Review Status with Higher Level Management :

 The purpose of this practice is to provide higher-level management with the appropriate visibility into the process
 These reviews are expected to be both periodic and event-driven.

 GP 3.1 : Establish a Defined Process :

 The purpose of this generic practice is to establish and maintain a description of the process that is tailored from
the organization’s set of standard processes to address the needs of a specific instantiation.

 GP 3.2 : Collect Improvement Information :

 The purpose of this generic practice is to collect information and artifacts derived from planning and performing the
process. This generic practice is performed so that the information and artifacts can be included in the
organizational process assets and made available to those who are (or who will be) planning and performing the
same or similar processes.
 Examples of relevant information include the effort expended for the various activities, defects injected or removed
in a particular activity, and lessons learned.

BACK

124 January 2007