NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: April 1, 2005
This is the third column in the series on large-scale development work. The first column briefly summarized the issues of large-scale development work, addressed the problems of organizational size, and described how organizations necessarily become less efficient as they grow. The second column dealt with project issues, particularly with the management-decision process. Often, the most serious problems in large projects concern the way decisions are made. In this column, I continue this discussion with a principal focus on the people and teams that make up the project staff and the issues involved in maximizing their performance.
While I was still at IBM, Peggy, a project manager, came to me for advice on how to handle a disagreement with marketing over her planned product. She had worked in my group a few years before and knew that I had dealt with such problems many times. She wanted my advice on how to proceed. Marketing staff insisted she add some functions that she did not believe were worthwhile. She debated this issue with the marketing representatives, and they were adamant. However, she had also talked to IBM’s GUIDE user group about the issue, as well as to several customers who were members of her user advisory board, and none of them felt that the functions were important enough to warrant delaying the product’s availability. They wanted the product as soon as they could get it, and these added functions would cause a delay of several months.
Marketing still held out. I suggested that Peggy inform marketing that she was proceeding without their approval and that she write a note to her management and copy marketing management explaining her position. I told her that the marketing people would be surprised and that they wouldn’t know what to do. This was not a sufficiently important issue to involve senior management, so if she were firm and had a sound business and technical position, marketing would cave in. That is what she did, and marketing did cave in.
As organizations grow, they become increasingly bureaucratic: staffs and review departments are established to monitor the operating groups. The larger organization also needs larger bureaucratic functions to handle the organization’s routine activities like delivering the mail, handling the payroll, running the facilities, and obtaining and distributing supplies. As the size of these staffs increases, their efficiency and effectiveness become a major concern, and management is likely to establish even more bureaucracy to monitor, measure, and track the growing bureaucracy.
So, bureaucracies grow seemingly without bound. Every new problem causes a reaction that often adds to the bureaucracy and makes organizations less responsive, more rigid, and less efficient than before. Of course, some bureaucracy is essential, and bureaucratic procedures can often be helpful. There are lots of routine things that must be done in any large organization, and neither management nor development groups want to worry about them. With an administrative function to handle them, these routine things become automatic.
Once these functions become automatic, however, they also become rigid and hard to change. Therefore, since development’s job is to develop new things, which invariably requires some degree of change, and since the bureaucracy’s job is to resist change, conflict is inevitable. This means that in large organizations, to get anything done, development groups must know how to overcome bureaucratic resistance. This task is not trivial because, once these bureaucratic groups get power, they tend to use that power in ways that management had not intended.
IBM management did not want the marketing group dictating to the project manager which functions should be included in her product. While marketing should have a voice, and development groups should take advantage of their guidance, product managers must be responsible for the performance of their products. This means that they must have the final say on what goes into their products, how the company’s money is spent, and how their products are introduced and offered.
While Peggy’s experience would seem to put the marketing people in a bad light, this is just an example of a staff group that overreached. There are many other cases in which such groups properly use their sign-off authority and help product managers produce truly superior products. There are also other cases in which staff groups identify real product problems and help to avert real mistakes.
Perhaps the worst case I know of in which a group used bureaucratic procedures to force a technical position happened some years ago when IBM was considering developing a new low-cost digital fax machine. The initial product concept was for a simple machine that would produce high-quality fax output. At the time, there was no comparable machine available. The marketing people kept pushing for additional functions, and the product manager kept caving in. Finally, after many months, the planned product’s costs had grown so much that the product could no longer meet the target price for a low-end machine. By the time the product was replanned for the proper market niche, a competitive machine had been introduced, and the market opportunity was lost.
If this product manager had fought for the original low-end product concept, IBM would have had an attractive new product, well ahead of the competition. So the key question is, “How can a developer operate in a large and increasingly rigid bureaucratic morass?” As the size and power of these bureaucratic groups increase, it seems that everybody is trying to block the developer’s work. Everyone can say “no,” and, seemingly, no one can say “yes.” It’s like “death by a thousand cuts.” If you spend your life fighting the bureaucracy, you won’t have time to do anything else. How can developers get anything done? There are a few guidelines that can help.
First, don’t sweat the small stuff. While none of us likes inefficiency and seemingly-stupid bureaucratic rules and regulations, assume that this stuff is there for a reason, and as long as it doesn’t block your ability to do your job, or if you can get around it without too much pain, learn to ignore it. Somebody else is worrying about organizational efficiency, so concentrate on your job of developing products.
In one example of this problem, Bret had just been made manager of a project to build a new communication device. As he talked to the developers, one of the new engineers complained about the stock room. It never had the right parts in stock, and the engineers often had to wait weeks for the parts they needed. Bret thought that this should be an easy problem to solve, so he talked to the stock-room manager. He found that there were all kinds of outdated rules governing stocking levels, reorder procedures, and purchase authorizations. After several days of digging, he found that, to change the system, he would need the lab director’s approval. He wisely decided not to pursue the matter.
Second, if the bureaucracy gets in the way, try to think of how you could do your job in a way that would not cause those bureaucratic problems. We often have choices in doing our work, and if some simple adjustments will suffice, make the changes and don’t fight over them. Before you go into battle, make sure there is no simple procedural fix that will do the job.
Instead of going to the lab director, Bret discussed the situation with Pete, a seasoned technician. When he told Pete about the problem, Pete asked: “What do you need?” Bret told him, and the next morning, Pete walked into his office with the parts. When Bret asked where he got them, Pete described the “midnight requisition” system that the technicians had developed to get scarce parts. Because the stock room was so antiquated, the technicians on all the projects had gradually accumulated enough private stock of frequently needed parts to meet their projects’ emergency needs. By checking with his buddies, Pete quickly got the parts he needed.
Third, when the bureaucracy really does get in your way, you will have to do battle. When you do, focus on getting your job done. In these fights, remember that the bureaucracy has one strong point—procedures. You are doing battle because what you want to do doesn’t fit their established procedures, and you will always lose battles over procedures. So don’t propose changing procedures or even new ways of interpreting procedures. Your strong points are business oriented: customer responsiveness, product enhancements, or other business needs that you are charged with addressing. As you escalate issues, your position should be, “I don’t understand your procedural problem; all I know is that we have to address this business problem, and I need your help in figuring out how to do that.”
Some weeks later, while testing the first system prototype model, Bret’s team had a disaster and burned out several critical parts. A customer demo was scheduled in a couple of weeks, and the stock room said it would take a month to get the needed parts. Pete’s midnight requisition system couldn’t help but he did locate a supply of the parts on eBay. Since the stock room had no way to buy parts on eBay, however, Bret was stymied. This time, he went to the lab director and got the authorization to buy the parts on eBay.
You may have to keep escalating a bureaucratic problem until you reach an executive who is responsible for both bureaucratic and business issues. But once you do, if you have a clear and convincing business story, that executive will always support you. Then you will get the help you need, and the bureaucrats will be directed to help you.
In the next column, I continue this discussion of large-scale work with a special focus on the politics of organizations and why democratic principles are particularly hard to apply in large development groups.
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, Julia Mullaney, Bill Peterson, and Marsha Pomeroy-Huff.
In this particular series of columns, I discuss some of the development issues related to large-scale projects. Since this is an enormous subject, I cannot hope to be comprehensive, but I do want to address the issues that you feel strongly about. So, if there are aspects of this subject that you feel are particularly important and would like covered, please drop me a note with your comments, questions, or suggestions. Better yet, include a war story or brief anecdote that illustrates your ideas. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
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 several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). 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.
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.