The Human Side of Process Improvement

My guess is that somewhere along the way you've heard about the idea of "software process improvement." I work in this field, and I've been privileged to watch dozens of software groups, in many different industries and countries, grow in process maturity as they follow the guidance of the Capability Maturity Model for Software (known as the "CMM" for short).

I've observed that the adoption of new technical and management practices is not the only type of change going on. There's a second type of change that's not described directly in the CMM at all, and the people who work in process improvement often tend to ignore its importance. This second type of change is in the interactions among people: how they give information to each other, how they receive information and listen, what assumptions they make about others, and how they act on those assumptions.

In this article, I want to explore the relationship between these two kinds of change. We'll see that these changes in interpersonal activity can often make the difference between effective and ineffective management and technical practices. As we talk about this "human" side of process improvement, we'll look at some things you can start doing now to help address this frequently neglected aspect of organizational change.

Models as Catalysts for Maturity
The CMM model, developed and published through the Software Engineering Institute (SEI) at Carnegie Mellon University under the sponsorship of the U.S. Department of Defense, is best known for defining five maturity levels. Level 1, the lowest or Initial level, is the default level at which organizations start before they've worked on their processes very much. (We sometimes refer to it, affectionately, as the "bottom-feeding, mud-sucking" level.) At the other end, Level 5 is the highest level, called Optimizing. At this level, organizations are systematically performing process improvement that is continual and data driven.

Greater process maturity and improved performance aren't solely dependent on using CMM; a software organization can move in this direction with any of several models (e.g., TickIT, Bootstrap, ISO 15504). Or a software organization can undertake process improvement without reference to any model, by performing serious phase-end and project-end retrospective reviews, incorporating best practices and lessons learned into phase and project kick-off meetings, and conducting a rigorous measurement program.

Whatever process improvement path is taken, the essential dynamics of organizational change are the same. The results can include fewer project cancellations, greatly increased project predictability, reduced costs, quicker development times, and fewer defects reported by customers. (Not all at the same time, of course; the benefits you get depend on where you put your emphasis and effort.)

Changes in Thinking Support Changes in Action
But the technical and management process improvements-in such areas as estimating and planning projects, tracking project progress, performing rigorous software configuration management, and instituting peer reviews-are only part of the picture.

To make those changes fully effective, your organization's interpersonal behaviors and underlying beliefs about people must be consistent with these changes, instead of working against them. It's this second kind of change that will determine whether the technical and management practices will achieve their intended outcomes. A couple of examples will serve to illustrate this point.

Truth telling   The CMM contains a number of Key Process Areas (KPAs)-specific process topics addressed as a group improves its processes. One of the practices in the KPA called Software Project Tracking and Oversight describes the software engineering group as conducting "periodic internal reviews to track technical progress, plans, performance, and issues against the software development plan." Imagine such a review meeting in which the first person to