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.
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
Keeper are patterns which may contribute to a DesignByCommittee
situation, since not all team members are empowered to contribute fully.
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