Large-Scale Work–Part IV: The Management System



Watts S. Humphrey

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 fourth column in a series on large-scale development work. The first column briefly summarized the issues of large-scale system development and discussed the problems of organization size, particularly how, as organizations grow, they become less efficient. The second column dealt with project problems and particularly with the management decision process. Often, the most serious problems in large projects concern the way decisions are made. In the third column, I focused on the people and teams that make up the project staff and the issues involved in maximizing their performance.

In this column, I address the problems of applying democratic management principles to large projects. As has been seen in politics, autocratic management is not effective for running large and complex modern countries. Autocratic management is also ineffective for running large and complex industrial organizations and is even less effective for managing large-scale development work.

Moving from an autocratic to a democratic management system is not a trivial process, however. Not only are management actions required, but both the developers and their management must be actively involved in establishing and retaining democratic management principles. This column explores democratic principles and the need for problem ownership, particularly in large systems-development programs.

Why Democratic Practices are Needed

The power of the democratic form of management derives from a few basic principles. The two most significant for this discussion concern the wisdom of groups and ownership. First, the combined wisdom of groups is vastly better than that of any individual for making complex judgments and producing accurate estimates. While basic design concepts should be produced by one or at most a very few individuals, the major concerns for large development programs are with the myriad smaller-scale but complex decisions that must be made throughout the development process [Brooks 00]. Examples of some systemwide technical decisions are the following:

  • power levels and standards
  • weight distribution among components
  • memory-size allowances
  • message standards and protocols
  • error and recovery standards and controls
  • sub-system functional allocation
  • system and component performance targets

In large organizations, these and many other technical questions often become management concerns, but they are rarely best settled by the managers. The challenge is to somehow ensure that technical decisions are made by the most knowledgeable technical people and not by the managers. This, however, raises the problem I discussed in Large-Scale Work—Part II where a design problem had become so politically charged that I, as a senior executive, was forced to make an important technical decision.

To make sure that technical decisions are made before some director or vice president has to produce an arbitrary solution, the developers should somehow be convinced to work out these decisions at a technical level. However, the individuals involved may be in different groups, they may not even know each other, and they might not have the close working relationships needed to informally resolve complex systemwide technical problems. Even worse, many of the more senior managers are often technical people who are dying for the chance to make a technical decision.

So the first reason for a democratic, or at least a local, decision-making process is so that the technical decisions are made by the technical people who are best informed about the subject. When properly led, a small group of the most knowledgeable people working together will invariably arrive at a better conclusion than any senior manager could possibly produce. Of course, with larger projects, these democratic principles must be coupled with some communications and a coordination process to get the right people to work together to make the decisions.

Importance of Ownership and Shared Vision

The second reason that democracies are so powerful concerns ownership and shared vision. To appreciate why ownership is so important, ask yourself when was the last time you washed a rental car. It is not that you value a clean car any more when you own it, but that it should not be your responsibility to wash a rental car. It belongs to someone else, and someone else should wash it.

When people think that they own even a small part of their country, or business, or project, they behave differently. One of the great tragedies of modern democracies is that many citizens do not have a sense of ownership. This problem was made evident to me some years ago when I got home from work late on a cold, rainy election night and didn’t want to go back out. Finally, I decided that I had to vote. I arrived at the polling place just as officials were locking the doors. They opened them just for me. I cast the last ballot in town.

At the time, a small group was trying to defeat the local school budget. The group believed that the town was spending too much money on education. I had seven children in the schools and knew that the budget was already very tight. The next day, everyone learned that the vote on the school budget was an exact tie. Had I not voted, it would have been defeated, and the entire school system would have had to go on an austerity budget. When the election was rerun, almost everybody voted, and the budget passed by a wide margin.

A shared vision is needed to ensure that the combined energy and motivation of the development group is coherently focused. When a group has a common vision, the members’ energies produce a powerful combined impact.

In a big country, business, or project, it is hard to believe that we can each make a difference, but we can. The key is not to wait for some special authority, but to act like an owner. If something is wrong, take action, and do what it takes to get it fixed.

Problem Ownership on Large Projects

On large projects, problems come up all the time—some function doesn’t do what was expected, a test facility isn’t available in time, an approval is delayed, or a requirement is not clear—and most of them are readily solved with little effect. However, almost every one of these problems requires changes to plans, and a few of these changes can significantly add to the project’s workload, particularly if they are not handled effectively.

For any project to be successful, every issue must be handled promptly and properly. Tasks must be redefined, resources redirected, and plans updated and adjusted. Sometimes management must be informed, and occasionally, commitments must be renegotiated. On a large project, who does this? Since every one of these problems and changes is unexpected, they weren’t assigned to anyone, and they aren’t anyone’s job. That is, nobody but the project manager owns them. And what is worse, the project manager usually doesn’t know anything about most of these problems and won’t even find out about them until they become serious. At some point, each problem will have to be solved for a developer to do his or her assigned job. Then management must get involved, and only then will the problem be solved.

On most projects, things aren’t really quite this bad. Developers are responsible people, and when they see problems, they don't just ignore them; they tell somebody. Unfortunately, however, that somebody may not recognize the importance of the problem, may think somebody else is handling it, or may be too busy to do anything immediately and then forget about it. While the developer may think that everything required has been done, a true owner would pursue the matter until the problem was resolved.

Unless every single member of the project team feels responsible for the success of the project and acts like a true owner, some problems will be ignored or forgotten until it is too late to fix them without major project disruption. Successful projects require an environment in which somebody can be counted on to pick up every single problem and insist that it be addressed. This may require the developer to go personally to several levels of management before being comfortable that the problem is being properly addressed or can be safely deferred. That is ownership.

Without a broad and general feeling of ownership, every big project is a likely disaster. With ownership, most problems can be recognized and addressed early enough to be fixed without major program impact.

Why Lack of Ownership Is a Problem

Since the ownership problem seems so obvious and the solution so simple, you might wonder why there is a problem at all. Why don’t people just act like owners? Consider the case of litter. When you see litter in public, do you pick it up? Few people do, but in a democracy, we are all part owners of every public space.

There are two reasons that development people do not act like owners. First, the management system looks autocratic. It is not that managers are tyrants, but that they sit at the apex of large hierarchical structures and issue orders and directions. Since this is exactly what tyrants do, the troops consider their more senior managers to be tyrants. The one thing that most people suspect about tyrants is that they shoot the bearers of bad news. Since none of us wants to get shot, and since we regularly read about the problems of whistle-blowers and outspoken malcontents, most of us are reluctant to speak out.

The second ownership problem concerns the natural reluctance of developers to overstep their assigned responsibilities. They have a lot of work to do, and they are uneasy that, if they spend time on anything that is not assigned, they may be criticized for doing something that is “not their job.” So, while ownership is a great concept, it must be developed and nurtured. It will not happen by itself.

In the next column, I discuss the various ways to develop a feeling of project ownership for both teams and the team members. Future columns will then discuss self-directed teams, managing self-directed teams, and scaling up.


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 David Carrington, Julia Mullaney, Harry Levinson, and Jim Smith.

In Closing, an Invitation to Readers

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 most 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


[Brooks 00]
Frederick P. Brooks, Touring Award Lecture, SIGGRAPH, 2000.

About the Author

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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.