We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Design By Committee

Originally published July 29, 2004

In a recent conversation with my good friend Bob Terdeman, Bob was discussing doing information architecture. Bob said - "the shop is trying to do architecture by committee." We had a good laugh because architecture is not done by a committee. At least it is not done well by a committee. 

In many organizations there is an attempt to do things by committee.  By having a committee, there is an achievement of organizational consensus, and we are all more comfortable with consensus. Everyone has their input and their agenda considered and - at least in theory - everyone is happy with the outcome. Therefore, with a design by committee, there is organizational consensus and happiness.  

But the truth is that when it comes to architecture, architectural design by committee doesn't work.

The major problem with architectural design by committee is that, over time, the process of design degenerates to the point that everyone has the right to say "no, we're not doing this", but no one has the authority to say "yes, this is what we are going to do."  The decision-making process degenerates into a political issue and nothing gets done.

There are also many pitfalls using the design-by-committee approach. What are some of these pitfalls? 

  • Agenda: everyone on the committee has his or her own agenda. This means that the design will ultimately be a compromise. The result will be at best, mediocre.
  • Background: when it comes to architecture, few people have the background to make architectural decisions. Most people on the committee are by education and training, accountants, sales or financial. Trying to create architectural designs by this type of committee would be comparable to allowing a patient who is a bookkeeper to make a decision on how his appendix is to be removed.  People who are not architects should not be making architectural decisions. 
  • Schedule: Meeting everyone's schedule objectives means the project must progress at the speed of the slowest member of the team.
  • Consensus: Have you heard of the expression - "herding cats"?
  • Budget: If too many people are involved, the budget becomes "someone else's money." Letting anyone Make decisions about spending someone else's money is always a prescription for disaster. Our politicians prove this every day.
  • Vision: People may have either a long or short term vision. Design by committee requires that there be one vision, and inevitably, this disparity will cause confrontation and disappointment. And finally,
  • Confusion. With enough people trying to get a complex project done in a complex environment, there will naturally be miscommunication, unrealistic expectations, inefficient effort, etc.  These all lead to confusion, wasted effort and misuse of resources. 

These are some of the reasons why design by committee becomes an impossible situation. There are many more reasons why design by committee can be a bad idea and a prescription for a dysfunctional design process. 

But are committees always an undesirable approach to architecture? 

Having an oversight committee, not a “hands-on” committee for architecture can be a good idea. The oversight committee only sets priorities. The execution of these priorities becomes the responsibility and domain of the architect. The committee stays out of the architect’s way and does not interfere with the day-to-day execution of the plan. 

This brings up another point, according to Bob, "the architect is not trying to win a popularity contest." It is true that the architect of a large, complex architecture must make decisions which do not please everyone. But in making those decisions there is a single, clear path as to where the organization needs to go. As an architect for information systems, you are not doing your job if you do not step on a few toes!

  • Bill InmonBill Inmon

    Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.

    Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Bill Inmon

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!