NEWS AT SEI
This article was originally published in News at SEI on: May 1, 2008
The idea for this column was suggested by Anand Paropkari and, I am ashamed to say, he made that suggestion an embarrassingly long time ago. In any event, his point was a good one. He said: "Most IT managers think that CMM and CMMI are not for them. Their perception is that the models are developed for IT vendors or DoD contractors."
I hear this all too often: "We are different." These folks seem to be saying that what worked for somebody else will not work for them. If we take this argument to its extreme, nobody could ever learn from anyone else, and we would all be stuck in whatever rat trap we happened to fall into. Then we would all have to learn by ourselves how to solve our own problems. If our forebears had all followed that strategy, we would never have progressed out of the stone age. Of course everybody is different as is every organization. But, at least in the software business, we share a great many common problems.
The fundamental question is whether your boss wants to improve the way the work is done. If he or she does, you probably will not have much trouble making the case for exploring an improvement effort. Then the problem would be to figure out how to get the boss' attention, what kind of improvement method to propose, and how to make the case.
More likely, however, your boss' saying "We're different" is just a way of saying "Don't bother me, I'm busy." When your boss is not interested in process improvement, there are two likely reasons. He or she is either a plodder or is too preoccupied with the current crises to think about anything else.
By plodder, I don't mean someone who is lazy but rather a manager who is comfortable with the way things currently work and doesn't want to be bothered with some new improvement effort. Such people will usually give an excuse like "we tried that and it didn't work" or cite an example of an improvement effort that failed. A more sophisticated management response is to ask for a return-on-investment analysis. Since such studies typically take a lot of effort and are easy to shoot down, such requests are guaranteed to indefinitely postpone further talk of improvement.
A good example of the plodder case was the director of a laboratory where I worked many years ago. After I had explained my improvement proposal, he asked how long it would take to recoup the investment. I explained that, realistically, it would take from five to 10 years. He then answered: "But I retire in five years." I thanked him for his time, rolled up my presentation flip charts, and started looking for another job. With bosses like this, you only have two choices: outwait them or leave. I left.
The other case is much more likely. It is that your boss is so enmeshed in the current crises that he or she doesn't have the time or energy to think about anything else. This is the most common case, and it is the one most of us need to think about, either as workers trying to convince busy bosses to make changes or as bosses who are too busy to think about anything but surviving. In either case, if you handle the situation properly, you have a good chance of actually making some improvements.
The way to deal with a busy boss is built into the Capability Maturity Model Integration CMMI) model and the improvement methods such as the Personal Software Process (PSP) and Team Software Process (TSP) that grew out of it. The best way to appreciate the CMMI strategy is to realize that the move from Level 1 to Level 2 is actually a move from crisis-driven management to plan-driven management. That is a fundamental change. It will show immediate and lasting benefits and should be top priority for any busy boss.
The great power of plan-driven management was driven home to me many years ago. I worked at IBM, and the company had announced and was starting to ship a new line of hardware products. Unfortunately, the software to support these products was late, and the schedule had slipped three times. At that point, the company fired the director of programming and gave me the job. I now had nearly 4,000 programmers working for me in 15 laboratories in the United States and Europe. They were all working to develop parts of this system, and everyone was late. The customers were irate, the marketing force was in turmoil, and everybody demanded delivery dates from me RIGHT NOW! This indeed was a crisis.
When I arrived in my new office the first day, I quickly made two decisions. First, I wanted no mail unless it came from my boss, his boss, the senior VP, or the chairman. My predecessor had spent most of every day and night just reading and answering his 3-foot stack of daily mail, and my large and overworked office staff spent all of its time just producing a 20-page mail summary. Clearly, reading and answering mail had not prevented and would not solve the current crisis.
The second thing I needed to do was to find out what was going on in the development groups. To do this, I scheduled trips to the three largest development laboratories. I found the same story at every one. Nobody had any plans and they didn't even have a prioritized list of what they had to do. Everybody was just banging out and testing code as fast as they could. I then asked the management team at each location how they would do the job if they did it in the best way they knew. They all agreed that they would establish clear priorities lists, nail down the requirements, and develop plans.
When I asked them why they didn't do that, they all said the same thing: "We don't have the time." This was clearly nonsense! The best way to do the job had to be the fastest and cheapest way. These folks, as smart and competent as they were, were clearly in panic mode and flailing.
The problem was that all of these managers had an enormous list of things that they had to do. But to ship code, the only things that were essential were coding and testing. So they spent their time coding and testing, and they were then so busy that they didn't have time to do any of the other things that they knew they "had to do." While everyone believed that planning was important, it wasn't an essential prerequisite to shipping code and therefore was considered optional.
It took me a little while to realize that, even though I had only been in the job for a couple of weeks, I was responsible for this whole crisis. I then went to the senior VP and told him I was going to stop everything. He turned pale. However, after I explained what I planned to do and why, he agreed. Since all that the developers could do was respond to crises, I had to turn planning into a crisis. I then sent a directive to all of the laboratories. Henceforth, no one could ship a program or announce a program, and I would not even fund a program until I had plans on my desk. They had 60 days to produce their plans and to review them with me personally. This made planning a crisis.
At the same time, I gave a talk to each of the four marketing regions to explain to the sales force what we were doing. I said that we had cancelled all of the software schedules and that we were busily developing plans for the work. When we had the plans in 60 days, we would announce new schedules. Furthermore, these would be schedules that they could believe. Several salesmen later told me that, for the first time, they were able to explain what was going on to our customers and that, while the lack of dates was a problem, they could start selling again.
In the plan reviews, I found lots of holes. Some plans weren't synchronized with planned release schedules, others left out quality assurance or documentation, and a few even left out integration and final testing. I didn't cut a single schedule, but I did add a 90-day cushion to all of the release end dates. As I explained to the development managers, they might be embarrassed if they missed a release date; but I could get fired.
While we gradually ate up the 90-day schedule cushion, we did not miss a single delivery date for more than two years. The change in the organization was dramatic. This group that had never before met a schedule was now consistently delivering on or ahead of plan. People now had time to think, product quality improved dramatically, and many of the developers and managers were even getting home for dinner with their families. Now, instead of being bums, the programmers were treated like the true heroes they were.
Now that you are convinced that crisis management is a black hole, how do you convince your manager? There are three general ways to attack this problem. The first is by direction. To do this, however, you have to go over your boss' head and get higher management to issue a directive. While this will almost certainly work, it is generally very risky unless your father is company president or your uncle is a majority stockholder.
The second approach is through logic. If you work directly for the executive who has the power to resolve this problem, and if you are on good enough terms to have such a discussion, this is probably a good next step.
The third approach, however, is almost always effective. That is to identify those elements of the recurring crises that are under your personal control. Then figure out how to establish plans to resolve the crises before they blow up. You might even involve some co-workers in doing this with you and cover as many of the crisis causes as you can identify and control. Then, after you have established and used these plans long enough to demonstrate their effectiveness, go to your boss and explain what you did and why it worked. Assuming that your boss finds what you did helpful, that would provide the opening for broadening your efforts to include more of your boss' territory and, ultimately, even to start looking at a more comprehensive improvement strategy.
After getting your boss' attention, you need to have a concrete plan of action. The key to any improvement plan is to start with a modest initial effort but to also ensure that this effort will produce tangible positive results. For example, you could either look at a small part of CMMI such as product planning or start with two or three TSP projects [Chrissis 07, Humphrey 02]. Regardless of the approach you take, it is important to have management's agreement.
While you can often accomplish a lot by yourself, any CMMI improvement effort must have reasonably broad coverage to make a measurable improvement in the organization's performance. For broad coverage, you need senior management support. Similarly, while initial TSP introduction can generally be confined to a small part of the organization, you will need senior management support here as well. This is both because the professional guidance to launch even a small TSP effort costs money and also because TSP introduction calls for a change in management style. However, management style is set by senior managers, so they must be involved.
All process improvement programs generally encounter a hidden trap. The problem is that crisis management is an all-consuming activity. Everybody is working hard, people are staying late, a lot is going on, and there is a great feeling of accomplishment. This is the typical reaction of people who confuse speed with progress. Highly professional and efficient work, however, is almost invisible. The product just gets delivered on schedule and works. What is the big deal?
What this means is that, after you take the first improvement step and it is successful, most of the causes for your crises will now be prevented and the immediate rationale for the improvement effort will have gone. If you haven't built the case for the next improvement step before you reach this point, the entire improvement effort will almost certainly be truncated and you will be back where you were at the beginning.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Bob Cannon, Harry Levinson, and Bill Peterson.
Chrissis, Mary Beth; Konrad, Mike; & Shrum, Sandy. CMMI: Guidelines for Process Integration and Process Improvement. 2nd ed. Reading, MA: Addison Wesley, 2007.
Humphrey, W.S. Winning with Software: an Executive Strategy. Reading, MA: Addison-Wesley, 2002.
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and 11 books. His most recent books are Winning with Software: An Executive Strategy (2002), PSP: A Self-Improvement Process for Software Engineers (2005), TSP, Leading a Development Team (2006), and TSP: Coaching Development Teams (2006). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago. In a White House ceremony in 2005, President George W. Bush awarded him the National Medal of Technology.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.