When a group of people design a system or information resource (like a wiki) for other people to be implemented by other people, and there are more 'designers' than 'doers', it seems almost invariably that time is wasted, the final product is somewhat disappointing or over-complicated, accountability for this blunder is vague or opaque, and frustration abounds.

The committee is the method by which large and complicated tasks get accomplished, especially those which may require diverse set of experts, inputs from several stakeholders, coordination of multiple resources, and careful planning. When this structure malfunctions in the context of designing a system, such as a set of wiki pages or a wiki-based community, you can get DesignByCommittee .

To overcome this anti-pattern, we suggest:

• Ensure the people that will use or have a stake in a system (or wiki) also have a stake in designing and implementing the system. This can be easier with a wiki than a web-page or static document.
• Encourage balanced organization for any design or contributing team, when it comes to 'management' versus 'contributors' and 'conceptual' versus 'procedural' or 'logistical' workers (thinkers vs. doers / production vs. innovation, etc). This is easier for wiki projects when every team member is empowered and expected to make their own changes to the wiki, rather than telling others what to do.
• Ensure tight iterations between planning/design/implementation of your knowledge resource. This is easy when wikis are 'live' and changes are immediate.

• This short satirical video shows a humorous illustration that might be all too familiar to you. It illustrates how a seemingly simple project can become overcomplicated and miss the mark when poorly structured teams are asked to address a 'simple' issue.
  • http://www.snotr.com/video/2326

• ContributorForHire is a pattern which may lead to one group of 'designers' dictating content that the 'designated contributor' must implement which could lead to DesginByCommittee .
• One Way Street or Gate Keeper are patterns which may contribute to a DesignByCommittee situation, since not all team members are empowered to contribute fully.
• BarnRaising is an example of a pattern which encourages all team members to contribute directly to the creation of a new wiki resource, potentially avoiding DesignByCommittee .