Transitioning from the ISO 9000 Standards to the SEI -CMM Model - a Practical Roadmap For

Transitioning from the ISO 9000 Standards to the SEI -CMM Model - A Practical Roadmap for Continuous Improvement

1Introduction

2Challenges to process compliance in a diverse development environment

3Approaching the Challenges

3.1Institutionalizing the process mindset

3.2Improving the Software Engineering Processes

4Key Motivators for Process Improvement Efforts

5Gaps Identified between ISO 9001 and CMM Level IV

5.1Level 2 KPAs

5.2Level 3 KPAs

5.3Level 4 KPAs

1Introduction

The Software Engineering Institute's Capability Maturity Model is fast becoming the Industry standard for Organizations providing Information Technology (IT) products and services.There are many authoritative reports available (Paulk 93, Paulk 94) which map the similarities and differences between the CMM and ISO 9001 models.

This paper is based on the real-life experiences of an IT service provider with more than five hundred employees catering to multiple Global customers straddling diverse business domains. The Division taken up for discussion is organized as vertical Lines of Business, each catering to a specific technology area- e.g. Automotive Software, Telecom, Client server etc. The various constituents had a chequered history regarding process focus with one of the groups being certified as possessing ISO 9001-compliant systems, while others followed ISO 9001-compliant processes without being formally certified. When the decision to comply with the requirements of the CMM Model was taken by the Apex Management, the challenge facing the Quality Team and subsequently the Software Engineering Process Group (SEPG) was to propel the groups with varying levels of process "maturiry " to a common, higher level of process rigor.

The challenges that were converted into opportunities and the mechanisms evolved to accelerate the Quality journey have been captured in this paper to provide an insight and hopefully help other Organizations traversing the same path to higher levels of the CMM.

2Challenges to process compliance in a diverse development environment

The challenges faced by a software development organization with demanding schedule and delivery objectives are common irrespective of the domain or technology platform. These may commonly include

• Ownership for Quality activities and process improvements are laid at the door of the Quality Department. This is also true for a ISO 9001 certified group where the Quality team essentially drives the process effort. In CMM parlance this situation shows the absence of an "institutionalized" process.
• Quality-related activities are often limited to the mandatory processes defined by the QMS and improvement efforts are isolated phenomena
• The developers consider process related activities as an overhead and a "necessary evil" to be performed once the "real" work of development is complete
• The Project Managers face a virtual "oxymoron" of on-time, high-quality delivery

3Approaching the Challenges

The Process Improvement effort was mounted through a two-pronged approach comprising Institutionalizing the process mindset and improving the Software Engineering Processes simultaneously.

3.1Institutionalizing the process mindset

• Senior Management exhibited direct and visible commitment to the Quality journey
• A massive Organization-wide training and reorientation effort was initiated to involve and align employees at all levels with the Organizational goals
• Ownership of "Quality " was shouldered by Development Managers at all levels across the Organization with the Quality Team being the facilitators for the journey.
• Information sharing methods were formalized to ensure that best practices are shared rapidly and implemented consistently.

3.2Improving the Software Engineering Processes

• The ISO 9001certified group took up process improvement steps that went "beyond the expected levels" in terms of strengthening metrics, requirement management and SQA

• It was decided to leverage on practices used in this group to identify gaps with respect to CMM level IV requirements.
• Dedicated groups were identified for enhancing the usage of automated tools for Testing, Configuration Management etc. that would help accelerate the evolution to a higher level of process maturity.
• The use of Process Automation tools helped institutionalize a strong and tightly controlled process especially in areas like Configuration Management and Testing. This would help in two ways - firstly, the process can be implemented only in one and the correct way ; and manual reporting can be avoided because of the built-in features present in several commercially available tools
• A major mindset change was encouraged when testing by an independent SQA team was initiated
• One of the development team members (in each project) was designated the Project Quality Advisor and was responsible for ensuring process adherence and process improvements within the project group.
• Technical Working Groups were setup with members from different domain areas who could contribute to the Organizational Process Definition and provide inputs for tailoring the process. This helped foster interaction between developers spanning several technical area and helped nurture a sense of "ownership" over the process improvement initiative.

4Key Motivators for Process Improvement Efforts

For the apex management : The apex management normally views all decision through the prism of growth and/or revenue. Any process improvement effort to gain support at this level needs to be presented in terms of Productivity gains and product quality improvements. The successful growth and revenue generation of the ISO 9001 certified group exploded the myth of the Quality-Productivity tradeoff. In addition, the CMM assessment (at least in the Indian context) is becoming a "must have" from the business point of view.

For the Middle Management (including Project Management) : This group is very crucial to the success of any process improvement effort. They are driven by objectives defined by the Apex Management. The visible commitment of the Apex management and an opportunity to "own" the process improvement effort provided the right ambience for this group to participate wholeheartedly in the Quality journey. The success of the project teams on the process front was one of the Key Result Areas for the managers to deliver.

For the Practitioners : This is the group that (prior to proper orientation)n perceives process initiatives as "additional work". Our approach was to prove quantitatively (using data from the team with ISO 9001 certification) the productivity and rework data , that process improvements in fact save time and reduce firefighting. One additional factor that helped was introducing elements of the Personal Software Process that helps overcome the "what's in it for me? " factor.

5Gaps Identified between ISO 9001 and CMM Level IV

The Gap Analysis was performed using a detailed Questionnaire which tracked various activitities at the sub -key practice level . ( Annexure I contains a sample of the Questionnaire used for internal Gap analysis.The entire Questionnaire can be provided on demand) .

Usually, the Gap Analysis is performed by the Quality team (with or without an external Consultant) and the findings are communicated to the rest of the Organization.

In our case the exercise was performed in two steps.

• At the Project/ Group level the Project Managers and senior Team members were asked to answer the Questionnaire. This helped bring the awareness within the team of areas in which corrective actions or other steps were required.
• The Quality team perfromed a "formal" Gap Analysis with an external consultant by mapping the practices of the ISO 9001 certified group with CMM, Level IV requirements.

The formal gap analysis revealed the following major areas for corrective action :

1. The Organizational Policy had to be formally defined and communicated for all KPAs.
2. The Peer Reviews area had to be formalized and implemented consistently.
3. Existing metrics programs had to be synergise into an organizational program.
4. Formal SQA procedures for all project deliverables had to be implemented consistently.

In addition, fine tuning had to be done at the practice levels of some Key Process Areas to ensure compliance to Level IV Requirements

The various areas that require strengthening in an Organization with ISO 9001-compliant processes are listed in the table below. Please note that these have been identified for a team with a customized QMS and may require some customization to suit other ISO 9001-compliant organizations hoping to achieve a CMM Level IV- Compliant process.

5.1Level 2 KPAs

(Note : Software Subcontract Management has been left out since our Organization does not subcontract development work)

KPA / Suggested Areas of Improvement
Requirements Management /

• Role definition to be formalized
• Training in RM Processes and RM Audit
• Senior Management review of Change request
• Guidelines for RM, Impact Analysis, Support Group Involvement

Software Project planning /

• Proposal Review Checklist for all items listed in respective practices
• Support groups to be involved in reviews
• Documented procedures for size, effort and cost estimates and schedule estimation
• Support group plans to be negotiated and agreed to
• Data to be captured on time spent in planning activities
• Guidelines to include assumptions

Software Project Tracking and Oversight /

• Detailed procedures for tracking size, effort, cost, etc
• Event-driven formal project reviews at selected milestones
• Data to be captured on effort spent on tracking activities and changes to Software Development plan

Software Quality Assurance /

• Clear definition on the role of SQA group
• Training for SQA roles
• Documented procedure for SQA Plan
• Audit of Software Work products
• Interaction with Customer SQA to be planned
• Periodic audits of SQA and SEPG function

Software Configuration Management (SCM) /

• SCM policy to be formally stated and mention repository for storing Configuration items
• Documented procedure for preparing the SCM Plan
• Audit of SCM group to be formalized

5.2Level 3 KPAs

KPA / Suggested Areas of Improvement
Organization Process Focus (OPF) /

• Formal policy statement on OPF and tailoring the organizational process for individual projects
• SEPG formation to be authorized by CEO/Steering Committee
• Periodic assessments to be made on the effectiveness of the Organizational process and corrections made as required
• Metrics on CMM time spent, milestones, project compliant status etc. to be collected and sent to Senior Management

Organization Process Definition /

• Guidelines for developing software process assets including change management and configuration control
• Descriptions of life cycles to be documented and maintained under configuration control
• Design of software process database and keeping under configuration control to be formalised
• Audits to ensure usage of standards and controlled access of Process assets

Training program /

• Policy for TP to be drafted with a documented process for developing a Training Plan
• Organization-wide Course Design standards to be developed
• Waiver procedures to be developed
• Skills database to be used as input for resource allocation
• Training activities to be reviewed by Senior management

Integrated Software Management /

• Policy to cover Tailoring and process assets
• Estimation guidelines to include use of Software process assets/database
• Risk Management to be formalized and contingency plans to be developed
• Software Plans and work products to be traceable to Software Requirements so that consistency is ensured
• Metrics to be collectedon both functional and technical Software process engineering activities
• Checklist to be prepared for facilitating QA audits

Intergroup Coordination /

• Policy statements to cover all affected groups
• Team building and other soft skill trainings to be imparted for all Project leaders and above
• Work products from other groups to be reviewed based on developed acceptance criteria
• Metrics to include time spent on Intergroup Coordination activities
• Audits to cover process for negotiating critical dependencies and handling of issues.

Peer Reviews /

• Training to be a pre-requisite for leading a review
• Peer Review process to be strengthened to include development of checklists and tracking corrective actions to closure.

5.3Level 4 KPAs

KPA / Suggested Areas of Improvement
Quantitative Process Management (QPM) /

• Written policy for Quantitative analysis of all Organizational functions
• Projects to have QPM plan as per a documented procedure'
• Milestone tracking and time spent on QPM planned vs actual to be collected
• Audits to cover QPM activities

Software Quality Management (SQM) /

• Documented procedure for develping Software Quality Plan
• Product Quality goals to be defined, monitored and revisedcontinuously
• Also to be reviewed on event driven bases, analyzed and corrective action taken
• Senior management reviews to include SQM reports

S.No / Details / Tasks / Remarks
1. / The project follows a written organizational policy for managing the system requirements allocated to software / Defined procedure for managing system requirements that

• Documents allocated requirements

• Allocated requirements are reviewed by SW Managers and other affected groups

• SW plans, work products and activities are changed to be consistent with changes to allocated requirements

Ability to Perform ( Annexure 1)

Sl
No. / Details / Tasks
Remarks on current practice
1. / For each project, responsibility is established for analyzing system requirements and allocating them to HW/SW and other system components /

• System requirements and their allocation are managed and documented throughout the project's life

• Changes are effected to the System requirements and their allocation

2. / Allocated requirements are documented /

• Non-technical requirements that affect activities in a software project

• Technical requirements

• Acceptance Criteria necessary to validate that the SW products satisfy the allocated requirements

3. / Adequate resources and funding are provided for managing the allocated requirements /

• Individuals with experience and expertise in the application domain and in Software Engineering are assigned to manage the allocated requirements

• Tools to support the activities for managing requirements are made available

4. / Members of the group are trained to perform their requirements management tasks / These include Methods, standards, procedures used by the project as well as the application domain

Activities Performed

S.No / Details / Tasks / Remarks
1 / Requirements reviewed before incorporation /

• Incomplete/ missing allocated requirements are identified

• feasibility, appropriateness, clarity, consistency and testability are verified

• commitments are negotiated with the affected groups

2 / Used as a basis for plans, products and activities / Allocated requirements

• Are managed and controlled
• Are the basis of software development plan
• Are the basis for developing SW requirements

3. / Changes reviewed and incorporated /

• Impact to existing commitments is assessed and changes negotiated

• Changes to commitments given to external customers is reviewed with senior management

• Changes to internal commitments are negotiated with affected groups

• Changes to plans, activities etc. caused by changes in allocated requirements are identified, evaluated, assessed for risk, documented, planned, communicated and tracked to closure

Measurement and Analysis

S.No / Details / Tasks / Remarks
1. / Measurements are made and used to determine the status of the activities for managing allocated requirements / Metrics procedure should state the metrics that are collected from allocated requirements including status, change activity, including no. of changes proposed, approved and incorporated

Page 1 of 11