CMMI AND PROCESS IMPLEMENTATION MYTHS

Over the years , I ve collected some examples of ideas people have about CMM, CMMI, or process improvement. Take a few minutes to read through them. Think about each of the statements and how much truth or how much falsehood each represents. Then read the following sections to see if you, too, have been a victim of the process improvement myths:

• CMM or CMMI gives organizations requirements for developing successful processes.

• Having higher maturity levels ensures a software or systems organization will be successful.

• Before implementing CMM or CMMI, organizations are usually in total chaos.

• The primary and best reason for process improvement is to achieve maturity levels.

• CMM or CMMI will fix all your software development problems.

• Model-based process improvement doesn t affect what I do.

• Implementing process improvement based on CMMI is rocket science and only a few geniuses understand it.

So, before you can start your process improvement efforts using facts or natural, common sense approaches, let s first address some of the beliefs that could have you start off down the wrong track and waste a lot of your time.

Myth or Methodology: CMM or CMMI Gives Organizations Requirements for Developing Successful Processes

Pure fiction . SW-CMM and CMMI are models which provide organizations with guidelines for improving the software and systems engineering process. Neither SEI nor either of the models requires anyone to do anything (unless your organization happens to be a vendor, supplier, or subcontractor to SEI).

Furthermore, the practices defined in CMMI are not prescriptive; they help an organization determine what it takes to increase their process capability and organizational maturity, but by no means prescribe how to go about doing so.

This myth, if left to fester in an organization such that it becomes pervasive (institutionalized), can drive counterproductive behaviors. This misconception is what often leads managers to want to implement CMM or CMMI as opposed to improve their software or system delivery processes. This belief is one of the bases for people trying to achieve maturity levels instead of solving their business problems or achieving business goals.

Myth or Methodology: Having Higher Maturity Levels Ensures a Software Development Organization Will Be Successful

No, it does not. There is empirical data ^[42] which suggests that organizations at higher capability maturity levels have realized business benefits from their process improvement journey, but it s pretty hard to prove in organizations in which the only measurement collected is progress against achieving maturity levels.

There is also empirical data that suggests organizations can exhibit low systems delivery capability (e.g., cost and schedule overruns, poor product quality) even when they have been appraised at higher maturity levels. ^[43]

There are two reasons this belief is wrong. First, if an organization s only goal is maturity levels, that is exactly and only what it will get. (Actually, by luck, it may get other benefits, but it won t know what it doesn t measure.) If the organization s goal is to implement CMMI and get a maturity level, it is not very likely that the organization will bother to collect any measurements which would suggest the realization of business benefits such as performance improvement. If, on the other hand, the organization s goal is to use CMMI as a tool to fix problems, improve processes, and achieve business results, it is likely that it has planned its process improvement work to achieve those results, and will collect measurements to validate the investment in process improvement.

Myth or Methodology: Before Implementing CMM or CMMI, Organizations Are Usually in Total Chaos

If you haven t read Chapter 1 ” News Flash! There Is a Level One!, then consider doing so. This belief is sometimes fact, but usually fiction. Have you ever heard someone in your organization use the phrase, mudsucking Level 1? This is not only unnecessarily demeaning, its implications are usually not true.

To believe in this fiction is to not understand how CMM or CMMI evolved and to believe that there were no successful software or systems development organizations in the world before these models were published. Remember, CMM and CMMI are models that are abstractions of the best practices which evolved in software or systems organizations. The best practices and the successes preceded the model, not the other way around. In the postmodern business world, it would be unrealistic to think that any software or systems delivery organization would survive even one fiscal quarter without at least some structure, norms, and successful engineering and management practices in place. You can easily spot the organizations that are in total chaos; they don t live very long.

Myth or Methodology: The Primary and Best Reason for Process Improvement Is to Achieve Maturity Levels

This one should be obviously untrue, yet I m sure you ve seen behaviors that would suggest that it is fact. What is more likely to be true, based on my experiences, is that senior managers, higher up than you in the organizational chart, will personally benefit in the way of bonuses by making you and the organization achieve maturity levels. As a result of those personal motivations, achieving maturity levels becomes high priority for success.

As with most sustainable business ventures , the best reasons for an organization to throw hundreds of thousands or millions of dollars at process improvement is to eventually realize business benefits such as measurable defect prevention, schedule predictability, cost reduction, productivity improvement, employee satisfaction improvement, or competitive advantage. The eventual business benefits should exceed the investment.

If your organization is in the outsourcing business (e.g., SAIC, CSC, Keane), you ll often be told that in order for the company to continue winning contracts, it needs to achieve certain CMM or CMMI maturity levels. You ll hear that maturity levels give the company a distinct competitive advantage over its competition. This is true, but only in the short term; it is not a long- term sustainable reason for process improvement.

Here s why. Let s say you re told that the competing outsourcing company is promising its prospective customers that its organizations can achieve CMMI Level 3 in 24 months. So now your company s marketing people, who probably don t know what the acronym CMMI stands for, feel driven to make a better promise, say Level 3 in 18 months. Suddenly, you re hearing all around you the battle cry, 3 in 18. Once the contract is signed, someone will find a way to keep the promise, no matter how unrealistic it may seem. When fulfilling the contract (and thus big money) is at stake, people will do anything, including ” yes ” cheating, to get to those maturity levels.

Now, let s play this out a few years. Your company and the competition keep trying to trump each other in the CMMI maturity levels game. They promise 3 in 12, so you respond with 4 in 18. They promise 4 in 12, so now you re compelled to reach Maturity Level 5 in one year, and so on. At some point in the not too distant future, your company and its competitors are all able to promise the highest CMMI maturity level ” 5 ” in absurdly short periods of time. At that point in time, the maturity levels are no longer a competitive advantage, and they no longer contain the singular, albeit artificial, value they were given. The sales people will stop selling CMMI levels and move onto something else. The whole industry built up around model-based organizational maturity becomes irrelevant. Then, if you re in the process improvement business, you re in the really uncomfortable position of having invested a whole bunch of money into something which cannot show that it paid its own way, because all you were after and all you achieved were maturity levels. At that point in time, if you re part of your organization s process improvement initiative, you might consider updating your resume.

Myth or Methodology: CMM or CMMI Will Fix All Your Software and Systems Engineering Problems

If you think about it long enough (like about one minute), there s really no such thing as a process problem or even a technical problem. Every problem we encounter in software or system development can be traced back to something someone said or didn t say or something someone did or didn t do. In other words, every problem, at its most root cause, is a people problem.

Even the very best procedures will not fix people problems. SW-CMM and CMMI don t even pretend to address people issues such as morale , learning curve, lack of flexibility, fear of change, incompetence , lack of skill, cultural norms, cluelessness, and on and on.

What s more, good procedures are a poor substitute for good leadership. It s really a cop-out to blame the process, because that s much easier to do than figuring out a way to solve people problems.

What CMM and CMMI will do for you is help you understand a way to structure your software and systems engineering procedures so that they can be consistently performed by reasonably competent and motivated people. That is all. If your organization is hurting in ways which are not really related to process, see a doctor, see a counselor, hire a motivational speaker, but don t turn to one of these models for the answer.

Myth or Methodology: Model-Based Process Improvement Doesn t Affect What I Do

If you re a bug exterminator, this statement is probably true, and you re probably not reading this book. If you are involved in anyway in software or systems engineering, systems acquisition, or program and project management, model-based process improvement can have a dramatic impact on you and your work.

Myth or Methodology: CMM and CMMI Is Rocket Science and Only a Few Geniuses Understand It

There are a lot of people who would very much like for you to continue believing this, especially the process consultants charging $2500 dollars a day. Alas, it isn t true. Almost anyone with a high school reading ability and some experience in software or systems development can read and comprehend CMM or CMMI. Most major universities are now teaching these models as core curriculum in computer science tracks, so thousands of college graduates over the last five years have been coming out of school versed in at least the concepts of the model if not its practical implementation.

Applying the model in a sane way in your organization may take a little more comprehension . To apply the model in organizations, it will help to have a varied background in organizational change, sociology, communication, management, and systems engineering.

Here s one of the primary indicators of an organization that has ” for whatever reasons ” artificially elevated the difficulty of work in model-based process improvement: You ll walk into the organization and find out that everyone is unquestioningly doing what the CMMI expert or SEI expert tells them to do. When asked about CMMI, the expert will probably tell you to not worry about CMMI, just do what I say. My advice to you: Run away.

^[42] Some of the best data collected to date on business benefits resulting from software process improvement were documented in a case study performed by The Boeing Company on one of its subsidiaries, BCS Richland. This information was presented by Boeing s John Vu at the 19th Annual International Software Process Engineering Conference in Seattle, WA.

^[43] At the 2002 SEPG Conference in Phoenix, AZ, Tom Laux, then Deputy Secretary for Acquisiton for the Navy, gave a keynote address. The crux of the presentation was that Naval Aviation (NAVAIR) had learned a hard lesson. In the late 1990s, NAVAIR required all contractors to be CMM Level 3. Well, NAVAIR got contractors which had been appraised at CMM Level 3, but many of them were still demonstrating poor systems engineering and delivery performance, they were still overrunning cost and schedule, and delivering defective systems. As a result, NAVAIR changed its policy and began requiring prospective contractors to show or demonstrate systems delivery performance.