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: March 1, 2005
This is the second column in a series on large-scale development work. The first column briefly discussed several important large-scale-project issues and then addressed the problems of organization size. It described how organizations get more complex as they grow and how this complexity saps the energy that the organization has available for productive work. I discussed the reasons for these problems as well as their consequences for development projects. In this column, I continue this discussion with primary focus on the project itself and the principal project-management issues. Large projects generally exist in large organizations, and they are also usually spread across multiple departments and locations. This affects their ability to operate and to produce high-quality products for predictable costs and schedules.
While large-scale projects face a host of problems, the principal topics I will discuss are project management and people management. Technical issues are critically important, and no amount of process, project, and people management can compensate for poor technical work, but this subject is too vast to usefully discuss in a brief column. Therefore, this column focuses on project management, and subsequent columns will deal with the people-management topics in managing large, distributed, multi-organizational projects. The major problems I have seen concern delegation and coordination.
One of the best examples I know of the typical problems of managing large projects is a situation that developed shortly after I took over as IBM’s director of programming. Our two largest locations were in Poughkeepsie, N.Y., and San Jose, Calif. Because the Poughkeepsie group had grown to nearly 1,000 developers and because it still needed many more people to handle its committed work, we had decided to move the data-management mission from Poughkeepsie to San Jose. The problem was that the interface between the Poughkeepsie operating-system work and the San Jose data-management products had not been defined.
We had told the two groups to agree on the interface definition and to come to me if they could not. Unfortunately, the interface definition had become a highly contentious issue with no clearly best answer, and the two groups were unable to agree. One morning, the two laboratory managers with about 30 of their best technical people showed up in my office with two competing proposals. Although I knew less about this subject than anyone else in the room, I ended up designing the interface. I told the groups to either make my definition work or to agree on a better solution and to let me know what they agreed on. They never came back.
This was a management failure. The problem had started many months before when what should have been a technical issue had become highly political. Then the technical experts were essentially forced to defend their managements’ positions rather than carefully considering the pros and cons of the various alternate ways to design the interface. We therefore ended up making a political decision on a technical issue.
While the way I handled this interface problem was clearly a management failure, what was the specific failing, and what should I have done differently? In retrospect, I believe that the problem was caused by differing goals and objectives. The Poughkeepsie manager was the OS/360 project manager while the San Jose manager was a laboratory manager with multiple projects, one of which was the OS/360 data-management work. Therefore, they had no common basis for agreeing on what was the best solution. Rather than making an instant decision, I should have made these two groups resolve the problem properly.
I now believe that the proper approach would have been to start with the goals to be met by the decision. That was a topic where I, as the senior manager, could have made a real contribution. Then, after reaching agreement on the goals to be met by the interface decision, we should have defined the criteria for making the decision. After settling the goal and criteria questions, I should then have sent the groups off to make the decision themselves and asked them to either report their conclusion and rationale to me or to come back if they needed further help.
The basic problem that this story illustrates is that technically trained managers love to make technical decisions, particularly after they have become executives. We all have this image of decisive executives who can be relied on to make almost instant decisions. This gives them a gratifying sense of power and fosters an image of infallibility. There is this myth that indecision is bad and that projects must have clear and precise direction at all times. This is not only wrong, but dangerous, particularly for very large and highly complex systems.
The design of large systems involves many decisions, most of which could be made in several ways with little, if any, effect on overall system performance. However, a few of these decisions are critical. If these critical decisions are not made properly, the consequences could be severe. Unfortunately, these decisions don’t come with a sign that says they are critical. The two examples that come immediately to mind both concern NASA’s handling of two space shuttle decisions: the technical question of O-ring safety for a low-temperature launch and the question of potential damage caused when falling hunks of insulation hit the shuttle wing.
To me, one of the most critical aspects of managing large-scale projects is making sure that decisions are properly made. The executive’s responsibility must be to identify the right people to make the decision, insist that the goals used for making the decision be defined and documented, and require that the criteria for the decision be established. While there are far too many technical decisions in large-scale projects for management to require that they all be made in this way, there are a relatively few times when technical decisions are escalated to senior management. However, whenever they are, these decisions are almost certainly technical issues that have become political.
If the executive does not insist that each of these politically tinged technical decisions is properly made, he or she is likely making a very big and possibly fatal mistake. If ever, this is the one time when the executive should insist that the decision be made in the right way. While these decision situations always come up when there is no time and when everybody, including the executive, is in a rush to get on with the job, this is precisely the time when proper decision making is most important. When executives insist that rush decisions be made in the proper way, they are demonstrating their ability to be technical executives. Therefore, the first two ground rules for the proper management of large-scale projects are the following:
While this might appear to be the end of the story, there is a broader lesson that is even more important. This concerns management development. There are problems at every management level in large organizations. At every level, managers or executives should be most concerned with the way their subordinates operate. The challenge at every level is to delegate and to get those at lower levels to take responsibility for making the decisions that they should make. The managers should insist that their subordinates make all of these decisions and that they make them in the right way.
With few exceptions, the depth of technical knowledge in organizations increases at lower levels of the management hierarchy. This means that when decisions are made with proper goals and sound criteria, they are invariably better decisions when they are made at the lowest possible levels in the organization. So delegation is critical, but with delegation must also come the responsibility to monitor behavior. So, while looking at cost, schedule, and quality performance, executives and managers should also look at the key decisions and how they were made.
It might seem that only senior managers and executives need be concerned with these issues. However, a principal problem for executives in large organizations is the difficulty of getting their technical people to take responsibility and to make sound and timely decisions on their own. The problem, of course, is not just the ability of technical people to take responsibility but also their ability to handle this responsibility responsibly.
In the next column, I discuss how developers and team leaders should act when making technical decisions. I will also outline some principles for team leaders and team members to consider when working on large-scale development projects and some strategies that can help in following these principles.
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.