Implementing the Capability Maturity Model

Citation

Narasimhan, K. (2002), "Implementing the Capability Maturity Model", The TQM Magazine, Vol. 14 No. 2, pp. 133-135. https://doi.org/10.1108/tqmm.2002.14.2.133.1

James R. Persse is a telecommunications consultant with Light Touch Systems, Inc. He specializes in systems design and engineering and software process management.

The capability maturity model (CMM) of the Software Engineering Institute (SEI) is currently the leading quality improvement standard in North America for software development. Many companies in the USA “insist on dealing with only those IT shops that can demonstrate a level of quality management”. Such a requirement has been necessitated by problems faced by the introduction of software with deficiencies that needed to be fixed later. Even Microsoft seems to have succumbed to this trend with their latest Windows XP.

The book comprises 16 chapters grouped into four parts. In Chapter 1, which forms Part 1, an overview of the CMM as a process improvement framework is given. James points out that the software process improvement is all about risk reduction and is a means to an end, and briefly describes the five levels of the framework and the key process areas (KPAs) for each level. The five levels are labeled as:

1. 1.

   (1) initial;

2. 2.

   (2) repeatable;

3. 3.

   (3) defined;

4. 4.

   (4) managed; and

5. 5.

   (5) optimizing.

Organizations operating at level 5 (only about 2 per cent of IT shops according to SEI) are focused on proactive continuous process improvement by identifying weaknesses, anticipating problems, and strengthening the process.

In Part 2, comprising six chapters, the six KPAs for achieving the repeatable level (level 2) are covered in detail. How to move from level 2 to level 3 forms the core of the next seven chapters, which form Part 3. In the final part, with two chapters, some ideas for implementing CMM in a smooth manner and the assessment process are dealt with.

In Chapter 2, James provides an overview of level 2’s six KPAs and the five key practice areas required in each of the KPAs. The six KPAs covered are:

1. 1.

   (1) requirements management;

2. 2.

   (2) software project planning;

3. 3.

   (3) software project tracking and oversight;

4. 4.

   (4) software configuration management;

5. 5.

   (5) software quality assurance; and

6. 6.

   (6) software subcontract management.

The five key practice areas are:

1. 1.

   (1) commitment to perform;

2. 2.

   (2) ability to perform;

3. 3.

   (3) activities performed;

4. 4.

   (4) measurement and analysis; and

5. 5.

   (5) verifying implementation.

Chapters 3 to 6 are devoted to discussing respectively the following four basic management areas: Creating level 2 structures, processes, training program, and policies. For each of the management areas aspects that need to be evaluated are first listed, then examined in some depth. The chapters conclude with a tabulation of the KPAs and the artifacts required as evidence of program compliance. Also, a brief summary of points covered in the chapter and a table of key practices discussed are also provided. In Chapter 7, attention is focussed on subcontract management, which may be required only in some organizations to blend harmoniously outside efforts with inside efforts.

The next seven chapters (8 to 14) form Part 3 and deal with recommendations for upgrading from level 2 program, into operating under level 3 guidelines. In Chapter 8, James revisits level 2 aspects before giving an overview of the concepts and structures that go into a level 3 program. The seven KPAs of this defined level are:

1. 1.

   (1) organizations process focus;

2. 2.

   (2) organization process definition;

3. 3.

   (3) training program;

4. 4.

   (4) integrated software management;

5. 5.

   (5) software product engineering;

6. 6.

   (6) intergroup coordination; and

7. 7.

   (7) peer review.

The five key practice areas at this level are:

1. 1.

   (1) commitment to perform;

2. 2.

   (2) ability to perform;

3. 3.

   (3) activities performed;

4. 4.

   (4) measurement and analysis; and

5. 5.

   (5) verifying implementation.

In the summary to the chapter James informs the reader the approach used to cover the topics in the next six chapters.

Chapter 9 is devoted to aspects important in aligning the whole organization in a common direction for software process improvement. James emphasizes in this section that the organization process focus (OPF) cannot be really separated from an organization’s standard software development process termed the standard software process set (SSPS), the thing that OPF is charged to manage. In Chapter 10, the focus is on defining how the SSPS process will be used and managed across all software development efforts. The four KPAs dealt with in detail are:

1. 1.

   (1) key structure;

2. 2.

   (2) process;

3. 3.

   (3) training; and

4. 4.

   (4) policy.

Creating level 3 structures forms the core of Chapter 11. The KPAs considered in this chapter are training program, integrated software management, software product engineering, intergroup coordination, and peer review. James points out that implementing recommendations on these aspects will lead to about 20 per cent program compliance. In Chapter 12, the focus is on creating level 3 processes using the five KPAs covered in Chapter 11.

The theme of Chapter 12 is setting up a level 3 training program and the courses that could be adopted to meet CMM recommendations for this KPA. James has included a useful six‐page table of 30 potential courses, what each course is about, who the members of the training group should be, when should the training be provided, etc. Also discussed are the pros and cons of delivering training in‐house or outsourcing. Chapter 14 is a short one dealing with critical policy issues in complying with level 3 requirements. In Chapter 15, James covers 11 key success factors that are critical to implementing the CMM in a smooth manner. For each of the 11 factors he lists the person responsible, the resources and the time required for implementation. The final chapter is devoted to explaining the assessment process and the 20 steps involved. An annotated level 2 pre‐assessment questionnaire (27 pages) and samples of level 2 policies (14 pages) are provided in appendices. Unlike other books by practitioners, this book has a useful list of references.

This is a specialist’s book that would be of interest to a select few managing software companies, as well as academic institutions running degree courses in computing.