Two Key Challenges To Implementing CMM

By Hillel Glazer



The SW-CMM (Software Capability Maturity Model) is a government-funded set of best practices for software development. By following these practices, government purchasers and software developers alike can gain better insight into and control over software projects, thus improving the product's quality and matching the cost and schedule more closely with estimates. So, in order to develop software for the government, developers are required to implement the CMM best practices. However, the large number of unsuccessful and/or painful CMM implementations has proved this implementation easier said than done.

Let's take a look at two points that often make implementing the CMM a challenge:

1. Unlike many typical government standards, the CMM doesn't tell the user "how" to satisfy the criteria, and

2. Many people who attempt to implement CMM have a hard time separating the development details from the management practices.

The first challenge results from the CMM being a "descriptive" and not a "prescriptive" standard. This means it describes the end result (what to do) but does not prescribe the method of getting there (how to do it). Most government contractors have come to expect that standards lay out not only the performance requirements, but also exactly how to fulfill those requirements. Not so with the CMM.

Think of it as though your doctor tells you to "get into shape" but doesn't give you any idea of how "out of shape" you are, what nutrition or exercise regimen to follow or exactly what is unhealthy about the way you are now. Imagine you've only been shown a picture of what "in shape" looks like, and you're told, "Become like that." Not much help, is it? But that's pretty much how the CMM comes across-especially compared to how it used to be for decades when government standards explicitly directed government contractors in both what to do and how to do it.

The lack of "prescription" in the CMM was on purpose. While it causes a lot of headaches to many organizations implementing CMM, this lack of "how" in the CMM was done to allow each company to create its own approach-based on what works best for it. The CMM is a set of processes, described in terms of general activities. Because of the many ways in which an organization can carry out those activities, each process can (and ought to) be unique to each individual company.

As you'd expect, not every process works for every company. Certainly, processes for developing an e-commerce web site should not be as complex or "weighty" as processes for developing safety critical software running inside nuclear power plants. Processes for software projects in both of these situations should be tuned to their respective development environments, so they wouldn't share too many similarities. After all, these two types of development projects have very different scope, budget, schedule, risks and even testing requirements. Thus, "how to" implement the CMM depends on how each organization manages and develops software.

This leads us to the second point of discussion: development methodology vs. management methodology. As described just above, you'd expect the way in which typical web sites are developed to be different from the way nuclear power plant software is developed. How can CMM work equally well in two such different environments?

Before we can answer that, it is necessary to reiterate that the CMM is a way of managing software, not developing it, the difference is that managing software has to do with business decisions such as estimating, planning, making commitments and controlling the outcome of the software project, whereas developing has to do with the detailed work of designing, coding, commenting and testing the deliverables. Software management practices are what allow the company to be consistent in the way it manages software projects, while specific development practices are better left to each project to determine.

The challenge is that many organizations and consultants fall into a trap: They are deeply accustomed to legacy development practices that were typically used to create large, complex software systems-like nuclear power plant controls and weapon systems. Many of these development practices are inseparable from their associated management methods. Whatever the reason, many CMM practitioners and consultants unwittingly take a "one size fits all" approach when installing CMM practices, regardless of whether they are implementing them on Information Age software or Cold War era software. Such approaches result in processes that impede development productivity, increase overhead and generally get abandoned for these reasons.

So, in answer to the earlier question, CMM can work equally well in very different environments as long as the way in which CMM is implemented is completely a reflection of what works for each particular environment. In other words, if an organization has a way of managing and developing software that fulfills its clients' needs as well as its own business goals, successful CMM implementation must start with those existing business processes. (If the company's existing development and/or management processes are a chaotic mess, then certainly, such basics must be established first before CMM will do any good.)

Finally, while we've established that what works for one company may not work for another, what still needs to be addressed is how to make it work for your company. The steps are simple. Any company can follow these steps with or without a CMM (software process improvement) consultant, although seeing the world the way the CMM sees the world is a little tricky at first.

Whether you want to be assessed to the CMM or just achieve much of the best practices from it, follow these steps: (1) Understand your company's current software management and development processes; (2) Understand the CMM; (3) Perform a gap analysis between your company's existing processes and the CMM's activities; (4) Target whichever CMM/internal process area(s) you feel will have the most immediate (or overt, measurable) impact; and (5)ÊCreate and follow an implementation plan that includes formalizing and piloting your processes in line with what works for your company and the level of process discipline your company can realistically be expected to assume.

While implementing CMM has its challenges, overcoming them is fairly straight-forward. A software process improvement consultant who takes the time to understand your organization can cut much of the guesswork out. Whether a company takes to implementing the full CMM or is looking for just enough process to provide it with insight into and control over its work practices, there is a way to do so without throwing its development environment for a loop. For those companies who do so, the benefits gained brightly outshine the initial challenges.



Hillel Glazer is the principal of Entinex, Inc., a consulting firm specializing in technology management-improving the profitability of technology developers and maximizing the productivity of business IT consumers. He can be reached at 877-ENTINEX, hillel@entinex.com or on the web at www.entinex.com.