Making Business Sense of CMMI Level 4

For some reason, the mystique of CMMI Level 4 seems to be wrapped around control charts—one of the methods used for statistical analysis of data. While use of control charts is almost always present in statistical analysis of software processes, Ed Weller all too often sees the reason for using statistical methods—and the reasoning behind the superficial analysis—lost in the concern for "building control charts to show that Company X is CMMI Level 4." Ed Weller offers valuable insight on CMMI Level 4 and what it really signifies.

At a conference discussion on high-maturity processes that I attended, the most frequently asked question was "How many control charts do I need to be Level 4?" Perhaps a better question would have been "How can we use control charts to improve our business performance?" An even better question is, "How can Level 4 improve our business?"

Readers unfamiliar with the CMMI® should scan other articles on or reference material at Software Engineering Institute. I will not talk about the techniques of various statistical methods; those desiring an in-depth explanation of statistical methods should look to books or articles that explain these topics in detail. The focus of this article will be to understand why statistical methods are useful, how to use them, and some of the common pitfalls I have seen in organizations that overlook the key question "How does this benefit our business?"

The phrase "business objectives" is used thirteen times in the CMMI Level 4 process area descriptions, providing clear direction for implementing Level 4. In a nutshell, Level 4 is about developing performance baselines—improvement objectives that are quantitative (numerical) improvements of the performance baseline measurements, analysis techniques that measure process performance (control), and the prediction of project results against estimates.

The term "quantitative project management" is one of the process areas at Level 4. In the most basic definition, it means that you can accurately estimate using past performance baselines; make commitments for cost, schedule, and quality with narrow variation from the desired values; and manage using techniques that provide early warning of deviation with the opportunity to take preventive or proactive action to keep on track.

Many companies first run into trouble when attempting to implement Level 4 because they have not established baselines for performance. For instance, what is the estimating accuracy for effort or schedule? If you do not know the current values, how can you set an objective for a 20 or 50 percent improvement in estimating accuracy? If you do not understand the current process and results for estimation, how can you change and improve estimating?

If you are working on projects with fixed-price contracts, the inability to estimate accurately will cause you to lose money (underestimating) or lose business (overestimating). If you develop software to sell or support internal operations, poor estimating will lead to committing to the wrong projects. This applies especially when there is large variation in accuracy between two projects; you will commit to a project with equal benefit and higher eventual costs, or fail to invest in the right project because it is overestimated. Reducing variation benefits the business, and industry reports show instances of cost/effort variation below 5 percent in high-maturity organizations (see Performance Results of CMMI-Based Process Improvement).

Understanding the real aspects/attributes of process performance versus building control charts purporting to show stable processes is another misapplication of Level 4 methods. A control chart showing that you have a stable process is meaningless unless it contains a useful and valid relationship to the work being performed.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.