Book Review
Department Editor: Warren Keuffel, wkeuffel@computer.org

Practical Software Process Improvement

Robert C. Larrabee

Making Process Improvement Work: A Concise Action Guide for Software Managers and Practitioners by Neil S. Potter and Mary E. Sakry, Addison-Wesley, 2002, ISBN 0-201-77577-8, 192 pp., US$29.99.

Making Process Improvement Work: A Concise Action Guide for Software Managers and Practitioners is what it claims to be. It's concise, and it addresses the target audience.

Experienced consultants in the field of software process, Neil S. Potter and Mary E. Sakry demonstrate their expertise in the book's content and organization. To paraphrase, the book's three chapter titles are "Plan for Improvement," "Execute This Plan," and "Check the Execution." How much simpler could it be? Certainly you'd expect a process improvement book to follow the PDCA (Plan, Do, Check, Act) cycle.

Strategic, pragmatic, and empirical

Process improvement (PI), like exercise after age 50, is painful. We nonetheless do each for long-term benefits (otherwise, why waste the time and money?). The authors capture this idea nicely. Business rules drive improvement efforts, whose effectiveness, in turn, is measured against those same business rules.

The authors are both Capability Maturity Model for Software lead assessors who have extensive experience in model-based process improvement and understand business context. Their book shows that these normative PI models can support specific strategic objectives. Many books describe how one enterprise succeeded in process improvement; Making Process Improvement Work provides a much-needed, generic, empirical, how-to template.

A return to fundamentals

This book is for workers in software process improvement, not academicians. And it's equally valuable for experienced managers at the start of a PI initiative. Those who want the short version of quality (via PI), in the proper context of business value, will find Making Process Improvement Work a worthwhile guide. So much of the post-modern quality movement seems to have lost its focus in the better-faster-cheaper confusion, and it's gratifying to see a return to fundamentals.

I especially liked the authors' appendices, which map real-world business problems (for example, "too many features for the six-to-nine-month development cycle" or "difficult to find defects early") to aspects of SW-CMM and Capability Maturity Model Integration. This is the first time I've seen such a traceability matrix, and I expect consultants would find it useful (not to mention a canonical, persuasive reference for clients).