| Some comments about IBIS The statements I am referring to (in the blog) may be predominantly applicable to one or several of the mapping programs now on the market under the IBIS label. My comments on the one hand go back to the original concepts and applications of IBIS that I worked on with Rittel, and on the other hand to the evolution of the idea resulting from my own research into the related problems of assessment (evaluation) of arguments in the design discourse. Terms such as ‘minimalist notation’, ‘force-fitting’ and the notion of IBIS as a tool for creating knowledge’, triggered my I urge to revive the reminder that IBIS -- Issue Based Information Systems -- were conceived as just that: information systems recording and documenting information generated in and for the design discourse. This means that it would have to accommodate any other conceptual frames of reference (however non-minimalist) -- and Rittel was adamant in holding up this ability to contain all previous and alternative vocabularies as a key criterion for evaluating any theoretical framework. So all such constructs, in his view, could be represented as ‘topics’ (ideas) , ‘questions’ (which become issues when they are controversial, i. e. when people hold significantly different positions as to their answers) and ‘answers’ and ‘arguments’. So the mimimalist aspect here lies just in the concept for organizing the collection of contributions to the discourse -- from tis point of view, a library or data bank using the concept ‘document’ as the key label for the things is organizes and contains is even more mimimalist. For both, the minimalist label does not begin to describe the content of the items stored. Any IBIS, just like any documentation system or library, by necessity must use some kind of format or encoding -- the first level of course being the language in which a discourse is recorded. The ‘code' of IBIS was an attempt to organize the collection in a manner more clearly related to the content of the discourse, understood, as indicated, as an exchange of questions, issues, answers and arguments. Problems arise, I agree, when the format is then used to govern the process or work of designing itself. Here, the prevailing acceptance of the need to arrive at a decision in a collective or group in which opposing positions are held leads to a reliance on parliamentary procedure in organizing the process -- which is arguably not the best format for either the creative aspects of designers’ work in seeking to understand the problems, developing solutions, preferably innovative solutions, and then juggling, fitting, coordinating the components of the solution ideas into coherent overall plans: the parliamentary procedure is more appropriate for arriving at a decision about complete plan proposals once all that detail work has been completed. When changes (amendments) must be made to the plan, things become procedurally difficult. This does not mean that certain aspects of the IBIS approach cannot be valuable additions ot the process (not just its documentation), even the creative process. For example, the constant reminder (that Rittel suggested should be repeated at every turn of the process and on every page) of the question “Wrong question?” (“Are we stuck in fruitless discussion of an inappropriate problem understanding?”) Or, the automatic generation of all the potential issues that can be raised about some topic -- the ‘issue family’ of factual, deontic, explanatory or conceptual, factual-instrumental or ‘how - to’ questions -- can nudge participants into exploring different points of view and solution possibilities. The fact that the IBIS format also is more conducive to elicit pertinent information from people affected by the plan proposals (but not part of the ‘creative team’ that seems to be the predominant concern in the discussion here) -- in other words: citizen participation -- is another aspect leading to temptations to impose the format onto the process. In this, the visualization of the problem and discourse -- the mapping efforts -- can be extremely valuable in helping all participants and contributors gain and keep an overview of the process. (One might disagree about whether a graphical network of issues and arguemnts already constitutes true 'imaging' visualization, though...) The key problems however, are not yet adequately addressed yet. One such problem is that the parliamentary procedure is expected to arrive at a decision by means of a vote. This is a decision tool that, for all the admirable underlying rationale (first we talk, each side presenting its best arguments, then we decide) does not guarantee that the decision will actually be based on the merit of the arguments brought forth in the discussion. None of the systems 'on the market' today, to my knowledge, are addressing the underlying task and challenge of this: the systematic and transparent evaluation of the arguments contributed to the discussion. As long as this aspect is left out, there will be an inexplicable hiatus between all the argumentation and mapping, and the framing of the decision. And, as parliamentary procedure itself has demonstrated, party allegiance as well as preconceived positions and hidden agenda issues can determine decisions in blatant disregard of any argument -- so if we already know the outcome, the argumentation itself becomes a nuisance, to be expediently dealt with by all kinds of clever and devious means. Is anybody listening to filibusters? And will this apply to mapping as well? I have been working on an approach for doing just that: evaluation the arguments we use in design discourse, and exploring the way including this in the process may change the process. It too, it will be argued, will apply more to the process of working towards a decision on complete plan proposals than to the work of a ‘knowledge creating’ design team involved in their development and preparation of presentation. It remains to be seen whether the expectation of subjecting the plan to such a deliberative evaluation rather than a majority vote will also change the way a design team goes about its work. This point brings up a related aspect that is missing from the discussion here: the question of the incentives or rewards involved in the process. As long as there is no deliberative argument evaluation mechanism, the incentives for anybody involved will remain the current, traditional ones: 'expediency' (working fast), ‘coming up with something new’, (not necessarily better), winning the votes (necessary for a majority decision), which all too means compromises below the surface of overt argumentation, slick presentation, etc. There is no real incentive for contributing relevant, meritorious arguments or information -- because there is no mechanism for evaluating it. This distorts and constrains both the ‘creative’ design development work and the collective decision-making process. These aspects are explored in my book ‘The Fog Island Argument’; I am waiting for one of the IBIS and mapping groups to pick up on these crucial ingredients of deliberative decision-making in design, planning and (political) policy-making. Thorbjoern Mann --- On Fri, 7/24/09, Jeff Conklin <jeff@...> wrote:
|
Yahoo! Groups TipsDid you know...Want to share photos of your group with the world? Add a group photo to Flickr. |
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
|
|||||||||||||||||||||||||||||||||
Offline 
Send Email