The CMM is a development methodology that's designed to help projects make use of reusable processes. There's some pain involved in making the switch, but the benefits to development staff and the organization make it worthwhile.
Our IT development process isn't terrible, but it's probably not great either. Our company is trying to become more efficient and reduce costs. My manager asked me to look into the Capability Maturity Model. The model looks reasonable, but I also know it will cause a lot of pain to our organization if we adopt it. Do you have an opinion on whether this is an area we should be considering?
You probably hit on the initial dilemma of companies that are looking at the Capability Maturity Model (CMM): They know that it's probably good medicine, but they wonder about the associated pain.
The CMM describes a continuum of characteristics based on how well your company or organization follows common and repeatable processes to get your work done. CMMs have been developed for software acquisition, people, and software. For the purposes of this column, I’ll focus on the Capability Maturity Model for Software (SW-CMM).
How it came to be
The CMM was developed by Watts Humphrey and the Software Engineering Institute (SEI)—part of Carnegie Mellon University—in the 1980s. The work was funded by the Department of Defense (DoD), which was originally looking for ways to compare and measure the various contractors that were developing software for the DoD.
Although the SEI continues to enhance and expand the scope and breadth of various CMM models, the primary focus for most companies continues to be software development. Perhaps the biggest reason for looking at software development is that the process uses a fair amount of creativity, which can lead to unpredictable results. However, much (but not all) of the software development process can be standardized using a common set of processes. Common processes can be set up for the project management side, for example. In addition, you can use common processes and techniques for much of the analysis, design, and testing processes. Moving up the CMM levels allows an organization to standardize its software development processes in areas that can be successfully repeated from project to project.
Organizations that use the CMM for software development describe their level of standardization against CMM benchmarks using a scale of 1 to 5. The low end of the scale describes companies that aren't using repeatable processes; much of their work is chaotic and ad hoc. The high end describes companies that use defined and repeatable processes, collect metrics to help them continuously improve their processes, and look for creative ways to do things better on an ongoing basis.
The five-stage CMM model
There are slightly different interpretations of the CMM model. Some companies have also identified their own proprietary versions of the CMM process. In general, these are the five defined stages:
- Ad hoc/crises: Your organization has few common processes. The success of your projects depends on the strengths and skills of your people. The organization provides little in the way of a supporting environment to help make all projects successful. (Most companies are at this level, although I've heard some companies say half-jokingly that they were at a 0 or -1 level.)
- Standard project management: Your organization has implemented standard project management processes. You're trying to establish a baseline foundation on which to improve further in the future. Most companies that start down the CMM path are trying to reach this level.
- Standard software development: You're trying to achieve standardization in your development processes similar to what you did for project management in level 2. This includes common and repeatable software development processes, deliverables, tools, etc.
- Managed feedback: You collect metrics on all aspects of your project management and development processes. You have a repository of metrics and key findings on historical projects that can be leveraged in new projects.
- Optimizing/continuous improvement: You have a closed loop of process execution, measurement, and continuous improvement. You continuously use measurement, feedback, and creativity to optimize your processes.
CMM can work
I recently spoke to a manager whose organization had successfully transitioned to CMM level 2 and was preparing to move to level 3. She said that the move to CMM 2 took several years, since they not only had to define and use a common set of processes but also had to overcome the initial resistance of the staff. She said that because the CMM framework requires an investment of time and training up front, it took a while to get the staff on board.
However, now the staff is seeing the results of their investment. Work seems to be progressing more quickly and accurately, and projects are running more smoothly. She noted that now that the staff is seeing the benefit of the changes, they think they can get to CMM level 3 more quickly, since much of the initial cultural resistance to the CMM model has already been overcome.
Is CMM right for you?
Your question was really about whether going down a CMM path was right for your company. It may not be surprising to hear me say that I think it is a good thing.
As you probably know, I am a “process guy.” Just as I believe there are real benefits to reusing common program components, I think there is also value in reusing common processes. Why should every project manager in your company struggle over knowing how to define a project and how detailed the work plan should be? Why should project managers struggle to understand how to effectively manage scope, risks, and quality? These are not new concepts, even within your own company. These should be defined well on an organizational level and then reused by all project managers.
You can use the CMM model as your guide as you try to implement common processes. You don’t have to start at level 1 and jump to level 5 in one year. The CMM scale is a journey. Most companies only want to start by moving to step 2. But even that short jump is not without pain.
In many respects, implementing common project management processes is the most difficult part of the journey. In many organizations, this is the first time people will be asked to follow a common set of processes, and many won’t like it. If you can successfully get to level 2, you should have already established the paradigm shift that will make the transition to level 3 a little easier.
It's worth the work
Many companies are seeing that they can drive business value by implementing good, reusable processes throughout their organizations. The CMM provides a framework that companies can use to measure themselves on a standard 1 to 5 scale. Most companies today are at level 1 and would love to get as high as level 2. Most managers and organizations realize that they should have common and repeatable processes. However, pain will definitely be involved.
There's pain involved with all culture change initiatives when you ask people to change how they do their jobs. In my opinion, the pain is worth the gain, if your company can stay focused for the time it will take the culture change to take effect.