RSP&&A;; Web Site: Commentary

The Continuing Challenge of SPI

A modified version of the following article will appear in the "Manager" column of IEEE Software in September, 1996.

I've been involved in software process improvement (SPI) consulting for almost 25 years - long before the SEI CMM even existed, software process became corporate chic and then uncool, and process agility evolved into the watchword. Along the way, I've noticed a significant change in people's perception of the worth of software engineering practices. But remarkably, there has been very little change in the way in which companies approach SPI.

When I visit a new client, the conversation typically sounds something like this:

A middle level manager, hosting my visit, looks at me earnestly and states, "We're a SEI CMM level 1 organization, and our management is demanding the we reach level 2 within the next year and level 3 within the next two years. We need to know how to get there from here."

"Specifically what are you trying to accomplish? What are your objectives?" I ask.

"Well, to reach level 2 a.s.a.p.," responds the manager who has been chartered with SPI responsibiity.

I smile and discuss what the real objective should be - to produce high quality computer software that meets customer's needs in a timely manner. The manager, of course, agrees with this (it's hard to argue against quality and timeliness) and then bends the conversation back to "key process areas" and how to achieve them.

"I'm not sure that our organization has a culture that will adapt well to the SEI CMM," the manager frets. "We know where we need to go, we just don't feel sure that we can get there."

The manager pauses for a moment staring out the window in thought. He looks back at me and states, "You know, I'm not convinced myself that everything in the CMM is appropriate for us."

For all of the debate about content and appropriateness, the SEI has developed a well-defined capability maturity model for the software process. Unfortunately, it represents a destination, not a road map.

Organizations that take the SPI journey are looking for themagic route - a single one-size-fits-all strategy that will guarantee higher process maturity levels. In reality there are dozens of possible routes that will get the organization to its goal. Some are like freeways, relatively straight and wide, enabling an organization to reach the goal quickly. Others are like country roads, bending and narrow, often mismarked, and sometimes dead-ends. The journey is slower and sometimes more frustrating, but if the manager is patient, the goal can still be achieved.

The problem isn't SPI strategy. That can be easily developed. The problem is the environment in which the strategy must be implemented. At the risk of sounding cynical, here are the realities of SPI as I see them from the trenches:

1. Management wants software process improvement "now," but
a. doesn't commit the resources to get it done in a timely manner
b. rarely establishes measurable goals
c. doesn't prioritize goals if they are established
d. all of the above

2. Even if management does commit the resources, the people who must champion the effort tend to
a. focus on the wrong things
b. focus on too many things
c. don't maintain focus for long enough to get much accomplished
d. all of the above

3. Even if the people who must champion the effort establish a reasonable SPI focus, the people who they ask to help in getting the SPI effort underway:
a. don't understand all the fuss about SPI and have little interest in it
b. are too busy with project work to do any meaningful SPI work
c. can't convince their managers to release them from project responsibility, even if they have interest in SPI
d. all of the above

4. Even if the people who will do most of the SPI work are given the time to do this work, they are:
a. generally ignorant of good software engineering practice
b. unable to learn enough about good software engineering practice to make informed decisions when they try to establish key process areas
c. have poor or non-existant software engineering library skills
d. all of the above

5. Even if everyone is available, committed, and reasonably knowledgeable, SPI is conducted by committee, with predictably poor results.

Phew! Sorry to vent, but that's what it's like, more times than not. Now for the big question: what to do about it?

I wish that there was a magic formula that makes all environmental problems that impact SPI just go away. But there isn't. However, there are a few things that you can do to make the environment as SPI friendly as possible:

1. You'll have to help make everyone involved smarter about software engineering and SPI. Decisions that are made from ignorance almost never lead to good results.

2. You'll have to manage expectations&emdash;both your own and those harbored by senior management. SPI efforts often lose momentum because unrealistic goals are set and hidden agendas abound.

3. You'll have to create a realistic plan — one that recognizes that resources will be scare and some people will be less than wildly enthusiastic about SPI work.

Home About us Products Product Models SE Resources Commentary Contact us
Web site and all contents © 2006, R.S. Pressman & Associates, Inc.
All rights reserved.

Free website templates


	*The Continuing Challenge of SPI* A modified version of the following article will appear in the "Manager" column of IEEE Software* in September, 1996.* I've been involved in software process improvement (SPI) consulting for almost 25 years - long before the SEI CMM even existed, software process became corporate chic and then uncool, and process agility evolved into the watchword. Along the way, I've noticed a significant change in people's perception of the worth of software engineering practices. But remarkably, there has been very little change in the way in which companies approach SPI. When I visit a new client, the conversation typically sounds something like this: A middle level manager, hosting my visit, looks at me earnestly and states, "We're a SEI CMM level 1 organization, and our management is demanding the we reach level 2 within the next year and level 3 within the next two years. We need to know how to get there from here." "Specifically what are you trying to accomplish? What are your objectives?" I ask. "Well, to reach level 2 a.s.a.p.," responds the manager who has been chartered with SPI responsibiity. I smile and discuss what the real objective should be - to produce high quality computer software that meets customer's needs in a timely manner. The manager, of course, agrees with this (it's hard to argue against quality and timeliness) and then bends the conversation back to "key process areas" and how to achieve them. "I'm not sure that our organization has a culture that will adapt well to the SEI CMM," the manager frets. "We know where we need to go, we just don't feel sure that we can get there." The manager pauses for a moment staring out the window in thought. He looks back at me and states, "You know, I'm not convinced myself that everything in the CMM is appropriate for us." For all of the debate about content and appropriateness, the SEI has developed a well-defined capability maturity model for the software process. Unfortunately, it represents a destination, not a road map. Organizations that take the SPI journey are looking for themagic route - a single one-size-fits-all strategy that will guarantee higher process maturity levels. In reality there are dozens of possible routes that will get the organization to its goal. Some are like freeways, relatively straight and wide, enabling an organization to reach the goal quickly. Others are like country roads, bending and narrow, often mismarked, and sometimes dead-ends. The journey is slower and sometimes more frustrating, but if the manager is patient, the goal can still be achieved. The problem isn't SPI strategy. That can be easily developed. The problem is the environment in which the strategy must be implemented. At the risk of sounding cynical, here are the realities of SPI as I see them from the trenches: 1. Management wants software process improvement "now," but a. doesn't commit the resources to get it done in a timely manner b. rarely establishes measurable goals c. doesn't prioritize goals if they are established d. all of the above 2. Even if management does commit the resources, the people who must champion the effort tend to a. focus on the wrong things b. focus on too many things c. don't maintain focus for long enough to get much accomplished d. all of the above 3. Even if the people who must champion the effort establish a reasonable SPI focus, the people who they ask to help in getting the SPI effort underway: a. don't understand all the fuss about SPI and have little interest in it b. are too busy with project work to do any meaningful SPI work c. can't convince their managers to release them from project responsibility, even if they have interest in SPI d. all of the above 4. Even if the people who will do most of the SPI work are given the time to do this work, they are: a. generally ignorant of good software engineering practice b. unable to learn enough about good software engineering practice to make informed decisions when they try to establish key process areas c. have poor or non-existant software engineering library skills d. all of the above 5. Even if everyone is available, committed, and reasonably knowledgeable, SPI is conducted by committee, with predictably poor results. Phew! Sorry to vent, but that's what it's like, more times than not. Now for the big question: what to do about it? I wish that there was a magic formula that makes all environmental problems that impact SPI just go away. But there isn't. However, there are a few things that you can do to make the environment as SPI friendly as possible: 1. You'll have to help make everyone involved smarter about software engineering and SPI. Decisions that are made from ignorance almost never lead to good results. 2. You'll have to manage expectations&emdash;both your own and those harbored by senior management. SPI efforts often lose momentum because unrealistic goals are set and hidden agendas abound. 3. You'll have to create a realistic plan — one that recognizes that resources will be scare and some people will be less than wildly enthusiastic about SPI work.