Ten Things Your Mother Never Told You About the Capability Maturity Model
December 24, 2009 § Leave a comment
Most organizations that start out on the road toward software process improvement (SPI) using the Capability Maturity Model (CMM) for Software have no clue what this endeavor means. Most managers get sold on the idea based on competitive practices within the industry—”keeping up with the Joneses.” This article discusses some common misconceptions about the torturous path to achieving a maturity level.
“What, me change? You’ve got to be kidding!”
Managers think the CMM focuses on changing the way the developers work. What happens is that the CMM forces management to change the way it manages projects. By requiring the development team to collect project data and report it to management, management becomes more aware of the project management process. In some organizations, managers do not want to know in detail what is really happening on their projects. The idea that someone would report to them actual schedule slippages and try to determine a standard deviation becomes incomprehensible. It is not uncommon to shoot the messenger.
What the CMM really provides is the ability to shape your own destiny. By generating procedures to do work, you control your work environment. If management understood that, they probably would not start CMM activities.
“We can’t do this. We have to support our users.”
It is amazing how often supporting the users is used as an excuse to not do CMM work. The CMM absolutely advocates supporting your users. That is why we are in this business. In case we have forgotten—no users, no work. Ultimately, by following CMM guidelines, supporting the user becomes easier because the ground rules have been established.
Change involves not only the developers but also management and the user community. No matter your position, your attitude plays an important role in SPI. For example, the way you do work in your twenties should be different from the way you do work in your forties, or at least it should be based on learning. If you are still doing things the way you always have, you need to re-examine your work and probably your life—and you are probably not the best person to be put in charge of the improvement effort. CMM work is all about change, something such people apparently know nothing about.
Users also need to change. Your users do not have the right to kill you, but that is what they are doing to our aging work force by creating unnecessary stress that contributes to heart attacks, cancers, and other ills. Control is the real issue. People who believe they have some control over their lives tend to be happier and live longer (so say the psychologists). So, to gain control of your project, you must control your users. Why should you accept an “emergency” request at 4 p.m. Friday that will keep you at work all night? Especially when it turns out that that particular user always turns in an “emergency” request at 4 p.m. on Friday and does not need the information until later the following week? Those users need to be trained in becoming pro-active and basically getting their act together. If everything is an emergency, nothing is an emergency. This sounds like an area in need of improvement.
“Standards? We don’t need standards!”
Nowhere in the CMM does it say that standards are required. The CMM does not absolutely require anything. The model is not a step-by-step how-to model—it is a framework, a guideline. It tells you what you need to do but not how to do it. However, the CMM presupposes that you have standards and are trying to follow them. The standards they presuppose you already have are for products like coding standards, templates for a requirements specification, or test case scenarios.
Following standards institutes a basic structure within an organization. So, if you do not have any standards, get some. One place to search is Department of Defense (DoD) military standards, even if you are not a DoD organization. Start searching the Web for military standards as well as for the methods used to implement SPI. They are available, and they are free.
Just do not be anal when you interpret this information (see item 10, “Keep It Simple”). And all standards should be tailored for use in your organization. Do not think that you can use the same standards you used from the place you used to work in your new workplace. They do not fit. They cannot be used. They can be used as a target, but you will need to tailor them.
“Everybody knows what the process is. What’s the big deal?”
Everybody knows what a process is until they try to define it in detail and write procedures that describe how to follow the process. Then, they shift back to documenting who needs to do something rather than on how that something is done. They also fall back on product standards (a form for documenting defects found during peer reviews) instead of process standards (how to perform the peer review, how to detect defects, and how to complete the form). Telling me that “it is the project manager’s responsibility to determine schedule estimates” does not tell me how that manager is supposed to derive those estimates.
“Collaborative and achieving consensus …”
CMM teams usually try to work collaboratively and make decisions by consensus. This concept is great and fosters buy-in and ownership but is extremely time-consuming and expensive. Consensus is not majority rules. Consensus means that everyone can live with the decision—they may not love it, but they can live with it. This way of working takes time. If you are on a tight schedule, (CMM work always is) you may need to stop the philosophizing and touchy-feely stuff and steamroll some folks. You will never get 100 percent buy-in from everyone. Take what you can get, and get those procedures written down.
“The CMM requires that a good process be in place.”
No. It requires that a process be in place that is documented and followed. At first, your process could be awful. That is where the “continuous process improvement” concept comes in. After you hammer out a process, it is piloted, and projects start to use it, refinements will be made until (it is hoped) the process becomes “good.” But to start, get something down on paper and use it. Clean it up as you go.
“We need to model our as-is process in order to create our to-be process.”
Yes, but I find that organizations take up to a year to do this, only to find that their processes are too ad hoc to be used as a baseline of good practices and lessons learned. I suggest doing a software capability evaluation (which is now done for internal software process improvement) or a CMM-based Appraisal for Internal Process Improvement. These assessment methods can quickly determine consistent practices across the organization as well as strengths and weaknesses. Measurable action plans can be generated based on the results. Tracking progress can also be measured. The thing to remember before starting CMM activities is to determine ahead of time how to measure success. Modeling current processes is great—but will you ever see a return on that investment?
“Tie CMM activities to your business objectives.”
Of course. There are some things in the CMM that may not make sense for you. For example, having a separate group to do software quality assurance (SQA) may not work if you only have 10 people in your company. The challenge is to figure out a way to perform quality assurance reviews and oversight in an objective, independent manner. And do not confuse “organization” with “company” or enterprise. An organization achieves a maturity level rating—not one project, not an entire company. Without going into detail, an organization generally consists of three to eight projects reporting to the same person, like a director or a division head—not an entire company (like IBM).
Do not get stupid about “business objectives.” Ultimately, most organizations’ business objectives are to achieve Level X by a certain date. If you are not currently doing SQA and do not want to do SQA (because of the cost and because it is overhead) yet you must achieve the level, do not try to be clever and tailor SQA out of the CMM process. Any certified evaluation team will catch you.
“Better, cheaper, faster.”
This really irks me. When the CMM was written, most organizations had not yet begun the downsizing frenzy. Nowadays, however, organizations have cut their staff to the bare minimum. Management loves the maxim “better, cheaper, faster” and eventually, you will be able to turn out software of better quality, more quickly, and less expensively—but not at first! The average time to obtain your return on investment is three to five years.
SPI is expensive. Most organizations either hire outside consultants to start the journey or build it from the inside. Even if you are not hiring consultants, taking people away from coding, i.e., “real work,” and having them do SPI costs you time, money, and schedule slippage. So management instead assigns SPI work in addition to existing work to an organization with extreme resource constraints, and it fails. You cannot squeeze additional effort from people who are already overworked. And having these people “work weekends, holidays, I don’t care what it takes” violates the CMM principle of establishing and following reasonable plans.
“Keep it simple.”
I like this one. Most organizations start off believing that they can keep their procedures simple—until they try to do it. Writing procedures that are simple and easy to follow, yet are thorough and complete, is extremely difficult. That is why the people on your teams need to be able to write and like to write as well as have a technical background and knowledge of the organization.
Managers in organizations today seem to feel that one person can wear many hats, i.e., a Powerbuilder programmer can also write procedures for how to write a requirements specification. Do you know what happens when you ask that unfortunate “techie” to do that? He breaks out in a cold sweat. Although some people are adaptable and can do many jobs, not everyone can do everything well. Different skill-sets are required for different jobs.
Another problem is that teams often catch the improvement fever. They want to improve everything. The challenge is to stay focused and use the CMM for software as your guide, but do not attack more than you can handle at one time. Remember: SPI is continuous improvement. It is iterative. Do what you can do in the time allotted, then go back and pick out more things once you have been allocated more time to do them.
Although there are other points to ponder when attempting this journey down the CMM path, these are the most frequently found errors made that I have documented. Good luck on your journey.