I am trying to find an example of the failure of design by committee, i.e. where everyone's suggestion has equal weight, and the end result is a complete mess that doesn't really satisfy the original requirements.

The example could be from absolutely any field, as long as it is accessible to a general audience.

  • 3
    The standard (and very old) joke is that a camel is a horse designed by committee. Commented Jul 13, 2015 at 0:10

4 Answers 4


Despite the fact that I agree with David that design by committee is sarcasm [and a real phenomenon, I agree with Michael Hogan too :-)], question is about examples (not about "design by committee" term).

So, take a look at this article.

There is a list of projects designed by committee in the "Case Studies" part:

Other examples:

Also, Fred Brooks wrote about some examples in his The Mythical Man-Month:

A little retrospection shows that although many fine, useful software systems have been designed by committees and built by multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers. Consider Unix, APL, Pascal, Modula, the Smalltalk interface, even Fortran; and contrast with Cobol, PL/I, Algol, MVS/370, and MS-DOS

At last, example from "Design by committee" wiki page:

An example of a technical decision said to be a typical result of design by committee is the Asynchronous Transfer Mode (ATM) cell size of 53 bytes. The choice of 53 bytes was political rather than technical. When the CCITT was standardizing ATM, parties from the United States wanted a 64-byte payload. Parties from Europe wanted 32-byte payloads. Most of the European parties eventually came around to the arguments made by the Americans, but France and a few others held out for a shorter cell length of 32 bytes. A 53-byte size (48 bytes plus 5 byte header) was the compromise chosen.

  • Thanks for the great reply. I have seen some of those before, but you found a few that were new to me. Plenty there to be going on with. Commented Jul 13, 2015 at 16:21
  • You're welcome =) I am glad to have helped you. Commented Jul 14, 2015 at 12:16

Design-by-committee is a real phenomenon, especially in government projects where a committee of elected representatives establish and control budget decisions. University of Southern California course SAE 550, "Systems Architecting and the Political Process", is a survey of engineering efforts that have been heavily influenced by design-by-committee.

The course covers a number of case studies from the aerospace industry. For each case study, the initial goals are described, an optimal engineering solution may be described, and the impact of politics on engineering decision-making are explored. The course presents a set of design heuristics that engineers can use to accommodate the realities of design-by-committee in the political process.

It may be worth your time to contact the course instructor to request one or two case studies. The Space Shuttle case study includes fascinating discussion looking at how conflicting Air Force and NASA requirements for the size of mission payloads impacted the Shuttle's cargo bay. Various other factors are considered to explain how the Shuttle went from a reusable, high-frequency launch platform to a low-frequency launch platform.

  • @David, I don't understand your comment. I've answered the original question by linking to a university course that features a set of case studies specifically chosen to address the issue of design-by-committee. Commented Jul 13, 2015 at 7:12
  • Thanks for the link. I think that example is probably too complex for my audience, but as useful one to know about though. Commented Jul 13, 2015 at 16:20
  • @AvrohomYisroel Cool! Commented Jul 13, 2015 at 17:06

I am trying to find an example of the failure of design by committee...

Design by committee is not actually a serious method. It is sarcasm. Typically, that phrase is used to describe a design process that is extremely inefficient and is leading to feature-bloat. It is inefficient because it takes longer than necessary to make decisions. It leads to feature-bloat, because bad decisions are often made by people simply agreeing to accept each others' ideas, regardless of merit.

  • I know it's sarcasm, however I would like an example of a real situation in which it happened, in order to clarify why it's often not a good method of design. Commented Jul 13, 2015 at 15:43

For a design problem that has a real solution space, the local optimum is still an optimum. That means, the result should not be a total mess (ignoring the fact that the committee can mess it up).

However, if the problem at hand requires novel approaches and taking risks, the committee solution could become a handicapped one.

Normally, the trade-off analyses catch the problems and make them apparent to everyone's understanding. And then it's the project manager's (or the chief designer's) job to take the low risk and high-gain solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.