Tools developed collaboratively are expected to be more effective and useful since they are products of a number of minds and a variety of experiences. Do you agree?

Sure.

A very powerful paradigm in systems engineering these days is the use of evolutionary methods to come up with good processes, good algorithms, good systems. Applying evolutionary methods to developing tools, I think that the power of many minds may come *not* from when these minds get together and try come up with a single solution, but when they generate a multiplicity of solutions. Each of these solutions would then applied, and then reassessed for their “success”. (Criteria for success have to be carefully drawn up.) Those solutions that fail to pass a minimum level of success are then no longer entertained. All the surviving ideas are allowed to be refined, and the process begins all over again.

The problem with this approach, however, is obvious: it consumes a lot of time and a lot of resources. If this approach could be automated, it might be feasible. But we’re dealing with humans, not computers! ...

LS,
let me briefly comment on the time and resources the approach consumes. It is a valid concern, the more so if we apply the “mapping” approach “project by project” (singly and severally).

Referring to the metaphor of making “walis tingting” on page 30 (chapter 3), development requires many initiatives rooted in the mapped intangible assets (and choice options) of the community (through the KPA framework). Thus the “cost” of the approach must be divided over many projects (each focusing on a solution to a particular problem mess). After repeated and consolidating use (e.g., via local transcripts, and why not, a KPA-structured “community wiki”, the maps and mapping approach become part of the social/cultural “change” capital (for achieving continuous community-based development). By transferring the approach to a community program/portfolio, the benefits could be multiplied, without much extra costs.

A “community wiki” sounds quite interesting. Who said that only projects need to be owned by communities? I think tools and approaches developed with and within communities also offer potentials for greater tool effectiveness and for repeated use by members of communities. Maybe this can be started as part of the pre-project phase, and built upon throughout the project life and thereafter. Succeeding projects can then benefit from it.

Appreciative inquiry methods can be used as the main approach in the pre-project stage. This will put the whole community in a positive state as they map what they already have and will generate the energy needed to identify what they want from externally-funded projects.