1 introduction to the software engineering institute’s (sei) capability maturity model (cmm)...

1

Introduction to the

Software Engineering Institute’s (SEI)

Capability Maturity Model (CMM)

“Improving what you build means

improving how you build”

2

AgendaAgenda

• Some interesting “Facts & Figures”• The Software Engineering Institute (SEI)• What Capability Maturity Model (CMM) for

Software means?• Structure of CMM• The Five Maturity Levels of CMM• Understanding the Five Maturity Levels• How Mahindra Satyam achieved SEI-CMM level 5

3

Cobb’s Paradox

“We know why projects fail, we know how to prevent their failure....so why do they still

fail?”

Martin Cobb

Treasury Board of Canada Secretariat

Ottawa, Canada

4

• For every 100 IT projects started, 94 are “restarted”

• Average IT project cost overrun is 178% in large

companies

• Average IT project time overrun is 230% in large

companies

• 42% of original features proposed of IT projects in large

companies actually get ported in the final product

The Need for Better Planning and ManagingThe Need for Better Planning and Managing

5

The reasons projects succeed:– User Involvement

– Executive Management Support (Active interest)

– Clear Statement of Requirements

– Proper Planning

– Realistic Expectations

– Smaller Project Milestones (Visibility)

– Competent Staff

– Ownership

– Clear Vision and Objectives

– Risk Planning, Identification and Mitigation

Project Success ProfilesProject Success Profiles

6

• 31.1 % of all projects were canceled before they are completed.

• 52.7% of projects cost 189% of their original estimates

• The cost for IT projects in American Companies and in the government that were canceled before implementation in 1995 is estimated at $81 billion dollars.

• The cost of overruns for the same period (in addition to canceled projects) is estimated at $59 billion.

Industry IT Project Facts: 1995Industry IT Project Facts: 1995

7

• Lost opportunities cost is not measurable, but could be in the trillions of dollars. Remember Denver; the cost of not having the baggage system working was costing the City of Denver $1.1 million dollars a day.

• Only 9% of projects in large companies come in on budget and on schedule.

More Industry Project FactsMore Industry Project Facts

8

SUCCESS CRITERIA POINTS

– User Involvement 19– Executive Management Support 16– Clear Statement of Requirements 15– Proper Planning 11– Realistic Expectations 10– Smaller Project Involvement 09– Competent Staff 08– Ownership 06– Clear Vision and Objectives 03– Hard-Working and Focused Staff 03

100

Industry Project Success CriteriaIndustry Project Success Criteria

9

• SEI, formed in 1984, began an examination of organizations that were recognized for producing high quality software products that were delivered on-time and within budget.

• Approximately 87 organizations were identified and examined, some of which were excluded from the study.

• The processes used by the remaining organizations were examined and the most common practices were then cataloged as the Key Practices and grouped into Key Process Areas (KPAs).

• The KPAs were grouped into levels of capability. The maturity levels were derived from TQM literature and applied to software.

Evolution of the CMMEvolution of the CMM

10

A Mature ProcessA Mature Process

• Consistent With The Way Work Actually Gets Done

• Defined, Documented, And Continuously Improving

• Supported Visibly By Management And Others• Well Controlled - Process Fidelity Is Audited And

Enforced• Requires Constructive Use Of Product And

Process Measurement• Means Disciplined Use Of Technology

11

Institutionalized ProcessInstitutionalized Process

“That Is The Way We Do Things Around Here”• The Organization Builds An Infrastructure That

Contains Effective, Usable, And Consistently Applied Processes

• The Organizational Culture Must Convey The Process

• Management Must Nurture The Culture - If No One Cares, Everyone Forgets

• Culture Is Conveyed With Role Models And Rewards

12

Risk

Significant Reductionin Development Risk

CMM Level......1..... .....2..... .....3..... .....4..... .....5.....

Productivity

34% Decrease in Cost to Develop

CMM Level......1..... .....2..... .....3..... .....4..... .....5.....

Quality

52% Decrease in Product Errors

CMM Level......1..... .....2..... .....3..... .....4..... .....5.....

Time to Market

15% Decrease in Time to Deliver

CMM Level......1..... .....2..... .....3..... .....4..... .....5.....

Benefits of Using CMM ModelBenefits of Using CMM Model

13

• Models are simplifications of the real world

• Models are not comprehensive

• Interpretation and tailoring must be aligned to business objectives

• Judgment is necessary to use models correctly and with insight

RisksRisks of Model-Based Improvements? of Model-Based Improvements?

14

ISO• Prescriptive

• Standard - Organizations must comply

• Identifies what “must” be done and by whom

• Looks at process existence, execution not at “goodness”

• Requires process improvement activities

• Focused on Quality Management System

CMM• Descriptive

• Model - Must be tailored to organization’s business environment

• Describes successful software development practices

• Expects processes to “make sense” to organization

• Focused process improvement of business practices

• Requires tailoring of process to project needs

How ISO and the CMM DifferHow ISO and the CMM Differ

15

• The CMM is a model. A reasonable interpretation of the CMM practices and professional judgment in application is necessary.

• The CMM was written to address the process for large, complex software efforts.

• Early efforts in tailoring the CMM indicate that in excess of 90% of key practices are applicable as written when interpreted in the context of the specific applications for both large and small organizations.

Common Sense IssuesCommon Sense Issues

16

Structure of CMMStructure of CMM

Maturity Levels

Key Practices

contain

contain

Key Process Areas

Implementation or

Institutionalization

Goals

Process Capability

describe

achieve

indicate

organized by

Common Features

address

Infrastructure or Activities

17

Maturity LevelsMaturity Levels

• Well-defined Evolutionary Plateaus On The Path To Becoming A Mature Software Organization

• Each Level Is A Layer In The Foundation For Continuous Process Improvement

• Achieving Each Level Establishes A Different Component Of The Software Process

• Maturity Levels Are Described In Terms Of 18 Key Process Areas

18

Maturity Levels Provide Orderly Path Maturity Levels Provide Orderly Path for SPIfor SPI

• Process capability is built in stages – This does not imply a ladder - some processes are ineffective

when others are not stable

• Each level provides a foundation for improvements at the next level– engineering process is easily sacrificed without management

discipline

– detailed measures are inconsistent without a defined process

– effect of process innovation is obscure in a noisy process

19

The Five Maturity LevelsThe Five Maturity Levels

Initial (1)

Repeatable (2)

Defined (3)

Managed (4)

Optimizing (5)

Disciplined process

Standard, consistent process

Predictable process

Continuously improving process

Process unpredictable andpoorly controlled

Projects can repeat previouslymastered tasks

Process characterized,fairly well understood

Process measuredand controlled

Focus on ProcessImprovement

20

GoalsGoals

• Goals Summarize The Key Practices Of The Key Process Areas

• They Are Considered Important For Enhancing Process Capability For That Level Of Maturity

• They Can Be Used To Guide Organizations And Appraisal Teams In Assessing Alternative Ways To Implement Key Process Areas

• Each Key Process Maps To One Or More Goals

21

Goals - an exampleGoals - an example

Software Project Planning

• Software estimates are documented for use in planning and tracking the software project

• Software project activities and commitments are planned and documented

• Affected groups and individuals agree to their commitments related to the software project.

22

Common FeaturesCommon Features

The common features across all the Five Maturity Levels:

• Commitment to Perform• Ability to Perform• Activities to Perform• Measurement and Analysis• Verification of Implementation

............Address Institutionalization and Implementation

23

Commitment to PerformCommitment to Perform

• Describes The Actions The Organization Must Take To Ensure That The Process Is Established And Will Endure

• Typically Include

– Policies– Leadership

24

Commitment to Perform - an exampleCommitment to Perform - an example


• A project manager is designated to be responsible for negotiating commitments and developing the project's software development plan.

• The project follows a written organizational policy for planning a software project.

25

Ability to PerformAbility to Perform

• Describes the Preconditions that must Exist in the Project or Organization to Implement the Software Process Competently

• Typically Includes– Function– Resources– Delegation– Training– Orientation

26

Ability to Perform - an exampleAbility to Perform - an example


• A documented and approved statement of work exists for the software project

• Responsibilities for developing the software development plan are assigned

• Adequate resources and funding are provided for planning the software project

• The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility

27

Activities PerformedActivities Performed

• Describes the Roles and Procedures Necessary to Implement a Key Process Area

• Typically Includes

– Establishing Plans and Procedures– Performing the Work– Tracking It– Taking Corrective Actions as Necessary

28

Activities Performed - an exampleActivities Performed - an example

Software Project Planning (some key practices)

• Software project planning is initiated in the early stages of, and in parallel with, the overall project planning

• The project's software development plan is developed according to a documented procedure

• Estimates for the software project's effort and costs are derived according to a documented procedure

• Software planning data are recorded

29

Measurement And AnalysisMeasurement And Analysis

• Describes the Need to Measure the Process and Analyse the Measurements

• Typically Includes Examples of the Measurements that could be taken to determine the Status and Effectiveness of the Activities Performed Common Feature

30

MeasurementMeasurement and Analysis - an and Analysis - an exampleexample


• Measurements are made and used to determine the status of the software planning activities

31

Verifying ImplementationVerifying Implementation

• Describes the Steps to Ensure that the Activities are Performed in Compliance with the Process that has been Established

• Typically Includes Reviews and Audits by

– Senior Management– Project Management– Software Quality Assurance

32

Verifying Implementation - an Verifying Implementation - an exampleexample


• The activities for software project planning are reviewed with senior management on a periodic basis

• The activities for software project planning are reviewed with the project manager on both a periodic and event-driven basis

• The software quality assurance group reviews and/or audits the activities and work products for software project planning and reports the results

33

Key PracticesKey Practices

• State the Fundamental Policies, Procedures, and Activities for a Key Process Area

• Describe “What” is to be Done, but they should not be Interpreted as Mandating “How”

34

Understanding the Five Maturity LevelsUnderstanding the Five Maturity Levels

• the concept of that Maturity Level

• how that Maturity Level is an improvement over the earlier Level

• the Key Process Areas of that Level

• the purpose of each Key Process Area at that Level

35


• Level 1 - Initial Maturity Level

• Level 2 - Repeatable Maturity Level

• Level 3 - Defined Maturity Level

• Level 4 - Managed Maturity Level

• Level 5 - Optimizing Maturity Level

36

Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)

• Performance driven by competence and heroics of the people doing the work

• High quality and exceptional performance possible so long as the best people can be hired

• During a crisis, projects typically abandon planned procedures and revert to coding and testing

• Unpredictable schedules, budgets, functionality and product quality-for good or ill

• The major problems facing the organization are managerial, not technical

37

Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)

• Requirements flow in

• A software product is (usually) produced by some amorphous process

• The product flows out and (hopefully) works

OutIn

Software Management is a Black Art

38

Key Process Areas for Key Process Areas for Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)

No key process areas for the Maturity Level 1

39







40

Repeatable Maturity Level (Level 2)Repeatable Maturity Level (Level 2)

• Effective software project management is established and institutionalized

• Software project management processes are documented and followed

• Organizational policies guide the projects in establishing management processes

• Successful practices developed on earlier projects can be repeated

• Projects plan and track costs, schedules, size, effort and functionality

41

Repeatable Maturity Level (Level 2)Repeatable Maturity Level (Level 2)

• Process of building software is a series of black boxes with defined checkpoints (milestones)

In Out

Project Management System is in Place

42

• The predominant need is to establish effective software project management

• Software project management processes are documented and followed

• Organizational policies guide the projects in establishing management processes

• Successful practices developed on earlier projects can be repeated

Repeatable Maturity LevelRepeatable Maturity Level

43

Key Process Areas forKey Process Areas forRepeatable Level (Level 2)Repeatable Level (Level 2)

• Software Configuration Management

• Software Quality Assurance

• Software Subcontract Management

• Software Project Tracking and Oversight

• Software Project Planning

• Requirements Management

44

Requirements ManagementRequirements Management

• Establish a common understanding between the customer and the software project of the customer's requirements

• Involves establishing and maintaining an agreement with the customer on the requirements

45

Software Project PlanningSoftware Project Planning

• Establish reasonable plans for performing the software engineering and for managing the project

• Involves developing estimates for the work, establishing the necessary commitments, and defining the plan

46

• A software development plan specifies many or all of the following:– the project’s chosen software life cycle model– a list of the products to be developed– criteria for peer reviews – estimates for level of effort (number of people (and skills),

cost, schedules, etc.)– facilities, support tools, and hardware– project risks

What is in a Software Development Plan?What is in a Software Development Plan?

47

Software Project Tracking Software Project Tracking and Oversightand Oversight

• To provide adequate visibility into the actual progress

• Involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on actuals

48

Software Quality AssuranceSoftware Quality Assurance

• To provide management with appropriate visibility into the process being used by the project

• Involves reviewing and auditing the products and activities to verify that they comply with the applicable procedures and providing the project and other managers with the results of these reviews and audits

49

SQA EvolvesSQA Evolves

• Proactive SQA functions as a value-adding member of the project team– SQA starts early in the project

– SQA helps prepare and review procedures, plans and standards

• At higher levels, the CMM provides flexibility for SQA to function pro-actively to drive improvements in the software process and product

50

Barriers to SQABarriers to SQA

• Disbelief in the value of SQA

• Standards and procedures that don’t add value

• Lack of respect of SQA by the software engineering group

• Unqualified SQA staff members

• Shoot the messenger

51

Software Configuration ManagementSoftware Configuration Management

• Establish and maintain the integrity of the products of the project throughout the life cycle

• Involves -– identifying the configuration of the software at given points in

time,

– systematically controlling changes to the configuration,

– maintaining the integrity and traceability of the configuration throughout the life cycle

52

Improvement of Improvement of Level 2Level 2 Over Over Level 1Level 1

• At Level 1, an Organization gets the Job Done

• At Level 2, a Software Project Management System is in Place

• The Organization Sets Expectations Via Policies

• Level 2 Projects Have Disciplined Process

53







54

Defined Maturity Level (Level 3)Defined Maturity Level (Level 3)

• Maturity Level 3 builds on the software project management foundation

• A Software Engineering Process Group (SEPG) exists and is responsible for the organization’s software process activities

• An Organization Standard Software Process (OSSP) is established for both software engineering and project management

• Projects tailor the OSSP to architect the Project’s software process

55

Defined Maturity Level (Level 3)Defined Maturity Level (Level 3)

• Roles and responsibilities in the process are understood

• The process followed for the software product is visible throughout the Project

In Out

Managed according to a Well-Defined Process

56

Key Process Areas forKey Process Areas forDefined Level (Level 3)Defined Level (Level 3)

• Organization Process Focus

• Organization Process Definition

• Training Program

• Integrated Software Management

• Software Product Engineering

• Intergroup Coordination

• Peer Reviews

57

Organization Process FocusOrganization Process Focus

• Establish the organizational responsibility for software process activities that improve the organization's overall software process capability

• Involves developing and maintaining an understanding of the organization's and projects' software processes and coordinating the activities to assess, develop, maintain, and improve these processes

58

Organization Process DefinitionOrganization Process Definition

• Develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization

• Involves developing and maintaining the organization's standard software process, along with related process assets, such as descriptions of software life cycles, process tailoring guidelines and criteria, the organization's software process database, and a library of software process-related documentation

59

Tailoring GuidelinesTailoring Guidelines(or, How to use the Standard Software Process)(or, How to use the Standard Software Process)

• Guidelines for tailoring the organization's standard software process are available to individual projects.

• What can be tailored out? What cannot?

• How much can a process element be modified?

• What parts of a process element should be considered for tailoring?

60

Relation of OPF to OPDRelation of OPF to OPD

• OPF and OPD are tightly coupled

• Organization Process Focus centers on the “who” controls and manages the process

• Organization Process Definition focuses the “what” aspects of the documented process

61

Training ProgramTraining Program

• Develop the skills and knowledge of individuals

• Involves first identifying the training needed by the organization, projects, and individuals, then developing or procuring training to address the identified needs

62

Integrated Software ManagementIntegrated Software Management

• Integrate the software engineering and management activities into a coherent, defined software process

• Involves developing the project's defined software process and managing the project using this process. The project's defined software process is tailored from the OSSP to address the specific characteristics of the project.

63

Software Product EngineeringSoftware Product Engineering

• Consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.

• Involves performing the engineering tasks to build and maintain the software using the project's defined software process (which is described in the Integrated Software Management key process area) and appropriate methods and tools

64

Intergroup CoordinationIntergroup Coordination

• Establish a means for the software engineering group to participate actively with the other engineering groups

• Involves the software engineering group's participation with other project engineering groups to address system-level requirements, objectives, and issues.

65

Peer ReviewsPeer Reviews

• Remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented

• Involve a methodical examination of software work products by the producers' peers to identify defects and areas where changes are needed

66


• At Level 2, the Focus is On Projects

• At Level 3, the Emphasis Shifts to the Organization– Best Practices are gathered across the Organization

– Processes are Tailored as Appropriate

• The Organization Supports the Projects by Establishing – Common Processes

– Common Measurements

– Training

67







68

Managed Maturity Level (Level 4)Managed Maturity Level (Level 4)

• The process is measured with well defined and consistent measurements across all projects

• The process operates within quantified bounds. The organization applies the principles of statistical process control to address special causes of variation

• These measurements enable projects to set and control quantitative quality goals for both software products and processes

• Software products are of predictably quality

69

Managed Maturity Level (Level 4)Managed Maturity Level (Level 4)

• Management has an objective basis for making decisions

• Management is able to predict performance within quantified bounds

In Out

Product and Process are Quantitatively Managed

70

Key Process Areas forKey Process Areas forManaged Level (Level 4)Managed Level (Level 4)

• Software Quality Management

• Quantitative Process Management

71

Quantitative Process ManagementQuantitative Process Management

• Control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process

• The focus is on identifying special causes of variation within a measurably stable process and correcting, as appropriate, the circumstances that drove the transient variation to occur

72

Controlling Special Causes of VariationControlling Special Causes of Variation

• An important concern is identifying variations in performance that are not within the normal range of process performance– “extraordinary” events outside the bounds of normal process

capability

Control Chart with Special Causes

73

Software Quality ManagementSoftware Quality Management

• Develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals

• SQM applies a comprehensive measurement program to the software work products described in SPE

74

Satisfactory KnowledgeSatisfactory Knowledge

“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.”

Lord Kelvin

75

At the Managed LevelAt the Managed Level

• Data is collected and analyzed throughout the projects in the organization

• Measurable product quality goals are defined and used

• When performance falls outside expected limits, something is done

• The quality focus is on customer satisfaction

76


• At Level 3, Measurements have been Defined and Collected Systematically

• At Level 4, Decisions are made Based On Data Collected

• Common Measurement

• Data Analysis

77







78

Optimizing Maturity Level (Level 5)Optimizing Maturity Level (Level 5)

• Continuously improve the software process

• Identify and eliminate the chronic causes of poor performance

• Prevent the occurrence of defects

• Innovations using new technologies and methods

79

Optimizing Maturity Level (Level 5)Optimizing Maturity Level (Level 5)

At this Level, Disciplined change is a way of life

In Out

Focus on Continuous Process Improvement

80

• 95% of all dieters regain the weight they have lost . . . and more. . . within one year of a diet

• 60% of those who change their lifestyle to eat less and exercise more maintain their weight loss

Process Improvement is a Lifestyle ChangeProcess Improvement is a Lifestyle Change

81

Key Process Areas forKey Process Areas forOptimizing Level (Level 5)Optimizing Level (Level 5)

• Defect Prevention

• Technology Change Management

• Process Change Management

82

Defect PreventionDefect Prevention

• Identify the causes of defects and prevent them from recurring.

• Process changes of general value are transitioned to other software projects, as is described in PCM

83

Technology Change ManagementTechnology Change Management

• Identify beneficial new technologies (i.e., tools,

methods, and processes) and transfer them into the organization in an orderly manner, as is described in PCM

• The focus of TCM is on performing innovation efficiently in an ever-changing world

84

Technology Transfer CurveTechnology Transfer Curve

TechnologyTransition

Pilot Test

InformationTransition Contact

AwarenessUnderstanding

Commitment

Installation

Adoption

Institutionalization

85

Process Change ManagementProcess Change Management

• Continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development

• PCM takes the incremental improvements of DP and the innovative improvements of TCM and makes them available to the entire organization

86

Change is a ProcessChange is a Process

• Disciplined change is the key to success

• Improvement includes planning

– evaluating improvement proposals and planning actions

– establishing process improvement teams

– conducting pilot programs for process improvement

– updating procedures, training, etc.

• Improvements are transferred into everyday practice across the organization

87


• At Level 4, the Process is Quantitatively Understood

• At Level 5, Continuous Process Improvement is a Way of Life

• In Immature Organizations, No One May Be Responsible for Process Improvement

• Mature Organizations Usually Have 70-80% Participation in Improvement Activities at any given Point In Time

88

Level 5 is not the DestinationLevel 5 is not the Destination

• Level 5 is a foundation for building an ever-improving capability

• Level 5 organizations continuous improvements are:– incremental (Kaizen)– revolutionary (innovation)

• Everyone in a Level 5 organization is involved in improvement

89

Themes in the CMMThemes in the CMM

• Continuous improvement• Defined, documented and used processes• Commitment by senior management• Stable processes• Measured processes• Controlled processes• Processes evolve

90

Continuous ImprovementContinuous Improvement

• Processes must be able to improve if we are to achieve continuous process improvement

• In mature organizations, processes are “living” entities, which are supported and maintained

• Everyone is involved in continuous process improvement

91

Defined, Defined, DocumentedDocumented, and Used, and Used

• Processes are documented

• Processes are practiced as documented

• Only procedures that will be used are written

• “Say what you do; do what you say.” or, for the younger set, “Talk the talk, then walk the talk.”

92

Commitment By Senior Commitment By Senior ManagementManagement

• Policies provide a way of establishing expectations for the behavior of everyone in the organization

• Written organizational policies are in Commitment to Perform

93

Stable ProcessesStable Processes

• Training is a way to establishing normal, consistent ways for performing an activity

• Training helps to ensure that everyone understands the process

• Training and orientation practices are in Ability to Perform

• Organizational training needs are addressed by the Training Program key process area.

94

Measured ProcessesMeasured Processes

• Measurement of both product and process is an integral part of every key process area

• Measures of the processes defined in each key process area are in Measurement and Analysis

• Typically measures are of status and effectiveness of processes

• Measurements necessary to implement the process (such as size estimates in Software Project Planning) are in Activities Performed

95

Controlled ProcessesControlled Processes

• The process must be verified and validated to ensure that it is really practiced

• The CMM emphasizes SQA– Software Quality Assurance key process area

– Verifying Implementation common feature

– The feasibility of alternative ways of verifying and validating the process depends on organizational culture

96

Processes EvolveProcesses Evolve

• Implies that the way people do a job will change (improve) over time

• Frequently includes the use of more powerful tools and methods

• Means that a “cultural shift” is under way because people are changing the way they do things

97

Organizational ContextOrganizational Context

• Each organization must interpret levels of excellence in the context of that organization's business environment

• The CMM works best when practices are interpreted in a way that makes sense for the organization

98

Interpreting the CMM Interpreting the CMM

• The CMM is applicable to different types of organizations

• Key practices have to be interpreted

99

The CMM is a ModelThe CMM is a Model

• A model – is a hypothetical or stylized representation

– is inert

– cannot solve anything

• The management of an organization is responsible for satisfying business objectives. The CMM, as a model, and currently the best software process model in existence, can help an organization improve software processes when it is diligently applied by knowledgeable individuals backed by management commitment

100

ConclusionsConclusions

• Software development and maintenance is difficult even with a disciplined process

• The CMM is one (but not the only) tool for understanding and describing the software process

101

PROCESS IMPROVEMENT, EVEN WITH THE CMM, IS NOT A SIMPLE TASK

103

CMM Level 5CMM Level 5

- A significant achievement for Satyam

104

Presentation OverviewPresentation Overview

• CBA - IPI Assessment

• What does Level 5 mean for Satyam

• What Level 5 does not mean

• What made the difference

• What it means to Satyamites

• Improvement opportunities identified

• … To Summarize

105

CBA-IPI AssessmentCBA-IPI Assessment

(CMM Based Assessment - (CMM Based Assessment - Internal Process Improvements)Internal Process Improvements)

106

Assessment TeamAssessment Team

Assessment Team leader: Assessment Team leader: Richard KnudsonRichard Knudson

P K Sinha

Anu Khendry

Kishore Rao

Subrata Guha

Sumeeta Hari

Pravin Chipde

Vivek Muzumdar (SBU2)

Deepak Thussu (SBU5)

Sudhakar M (SBU1)

Narayanan V (SBU6)

107

Assessment ProjectsAssessment Projects

• SI-PL - Maintenance - SBU1

• CT - Maintenance - SBU5

• EDS GM - Maintenance - SBU6

• CSSP - Development - SBU3

• VPS Phase 1 - Development - SBU3

• S&S UOPS - Year2000 - SBU6

108

FAR GroupsFAR Groups

• Project Leaders (6)

• Middle Managers (14)

• Developers / Testers (10 + 11)

• Support– SEPG (3)– SQA (3)– SLC / Quality Training (2)– SCM (2)

109

Assessment DataAssessment Data

• Effort– 858 person hours

• Duration– 7 days

• Depth– Conducted at sub-practice level for all KPAs– Almost 1200 sub-practices!!

110

Assessment DetailsAssessment Details

• For each of the 316 key practices– Process evidence(s)– Implementation evidence(s)– Verbal evidence(s)– Satisfied by a consensus of ALL the ATM

members

111

CMM Level 5CMM Level 5

... A reality at Mahindra Satyam... A reality at Mahindra Satyam

112

What does Level 5 mean for Mahindra What does Level 5 mean for Mahindra SatyamSatyam

• Our customer expectations will be elevated

• Our process ranks among the top ten companies of the world

• Our process is quantitatively understood, managed and continuously improving

• We can predict our performance with a reasonable level of accuracy

• We identify and eliminate chronic causes of defects and time / effort overruns

113

What level 5 What level 5 does notdoes not mean mean

• We always deliver on time and within estimated effort

• We have no areas of improvement

• We can continue to claim to be a Level 5 company - we need to maintain the level by reassessment once in 18-24 months, as desired by Satyam

114

What made the differenceWhat made the difference

• Defect Prevention

• Technology Change Management

• Process Change Management

… the 3 KPA’s at level 5

115

Defect PreventionDefect Prevention

• A process in place for Causal Analysis and Defect Prevention

• Organization Level Defect Prevention Team

• Organization Level Defect Prevention Plan and activities, as part of SEPG Plan

• Project Level Defect Prevention plans and activities

116

Technology Change ManagementTechnology Change Management

• A process for Technology Transition Management (TTM)

• Organization Level TTM team

• ICC to focus on TTM activities

• Organization / SEPG Level TTM Plans

• Process Evaluation as an input for TTM

• TTM process followed for tools like CCS, BTS, Vision Compass, etc.

117

Process Change ManagementProcess Change Management

• A process for QMS improvements

• Feedback mechanisms for collecting inputs for process improvements (e.g. ICSM)

• Measuring effectiveness of process change via metrics (e.g. Inspections)

• Process followed for defining and piloting the PACE model

• Process Expertise Database

118

What does Level 5 means to Mahindra What does Level 5 means to Mahindra SatyamSatyam

• They know the performance of their project and Satyam quantitatively

• They set improvement goals for the performance and work towards them

• They take decisions based on data e.g.– Tracking progress of projects– Re-planning– Completion of a review contd ...

119

What does Level 5 means to Mahindra What does Level 5 means to Mahindra SatyamitesSatyamites

• They identify causes of defects and prevent them

• They share their project experiences with others and learn from other projects

• They participate actively in process improvements

120

…….. To Summarize.. To Summarize

• We have a bigger challenge to :– deliver a higher quality product – better manage the project– provide predictable results at predictable time

• We should ensure that the appropriate data is given to SEPG to continuously improve

1 introduction to the software engineering institute’s (sei) capability maturity model (cmm)...

Documents

canceled projects

project cost overrun

reasons projects

industry project facts

project time overrun

smaller project involvement

cost of overruns

levels of capability