Resources

Research

White Papers

The IBIS Manual
A Short Course in IBIS Methodology

Introduction

The purpose of this manual is to explain the rules of the IBIS method, to convey a sense of the power, simplicity, and ease of use of the method and, most importantly, to give the reader confidence that he or she can use the IBIS method to sharpen and organize the exploration of virtually any topic. For anyone serious about mastering IBIS we strongly recommend taking GDSS's Creating Collaborative Meetings course, which teaches the practical skills of working with IBIS in meetings and other high-stakes situations.

IBIS (pronounced "eye-bis") stands for Issue-Based Information System, and was developed by Horst Rittel and colleagues during the early 1970's. IBIS was developed to provide a simple yet formal structure for the discussion and exploration of "wicked" problems. Problems that are wicked, as opposed to tame, do not yield to the traditional "scientific" approach to problem solving, which is to gather data, analyze the data, formulate a solution and implement the solution. With a wicked problem your understanding of the problem is evolving as you work on a solution. One sure sign of a wicked problem is that there is no clear agreement about what the "real problem" is (see the section "How to Tell if a Problem is Wicked"). Wicked problems cannot be solved in the traditional sense, because one runs out of resources (time, money, energy, people, etc.) before a perfect solution can be implemented.

This was the environment IBIS was developed to work within. It is an environment of multiple parties with differing views about the problem, differing values and beliefs, little in the way of "hard data," and time pressure for a resolution. The method is powerful because it supports dialogue among the stakeholders in the problem, and it is only through such dialog that the necessary shared models can emerge. It works because it is simple enough that it does not get in the way of the discourse, yet it provides a simple framework in which the key logical elements of the discourse can be understood and shared.

IBIS was never strictly defined by its inventors -- it was an evolving standard for them. One of the greatest drawbacks of the IBIS method historically was that it was relatively easy for an IBIS discussion to overwhelm any manual system for keeping track of all the issues and their logical relationships. QuestMap™ was developed after 10 years of research and testing as a computer-based tool that would support IBIS discussions regardless of the number of people or the duration of the discussion. As part of this research and field testing the IBIS method itself was refined; the method as presented here is the result of that experience.

*This paper is written to help QuestMap users who are collaborating electronically over the LAN. However, most of the ideas apply as well when using QuestMap face-to-face to facilitate a meeting,

As you work with IBIS and QuestMap you will come to appreciate that they make explicit a dimension of communication which normally remains obscured: the moves in a conversation which open the conversation up versus those which close a conversation down. Indeed, one of the most significant benefits of QuestMap is the extent to which using it can, over time, lead users to more skillful and creative teamwork and communication. It does this by demonstrating the power of asking questions which open conversations up and invite thoughtful and creative participation by all. Using IBIS and QuestMap also reveals the extent to which important conversations can be "closed down" by statements which on the surface appear fine and normal. The secret is in focusing on the asking of questions, and in how these questions are framed.

IBIS Fundamentals

The key to the power of IBIS is that it is issue-based, but this is also one of the hardest things about it to master. Being issue-based means that whenever there is any misunderstanding or disagreement, the first move is to frame the misunderstanding or disagreement as an issue, or, more precisely, as a question. The creation of the question turns the "argument" into an inquiry -- a dialogue in which the underlying goal is to open up to new possibilities and the mood becomes one of partnership. While this may seem simple and straightforward, in practice finding the best question to ask is an art form.

The Answer Reflex

Why is it that framing conversations in terms of questions is so difficult to master? One reason we have found is that Western society and the educational system seem to have rather thoroughly trained us to always know and say the right answer, and to avoid the vague and weak position of simply asking an open-ended question in a discussion. In other words, the result of years of practice is that most people have a very effective "Answer Reflex," which is the source of the commonly heard discussions of the "Yes, it is!" - "No, it isn't!" variety.

In a discussion, the original question is quickly overwhelmed by a flurry of countermanding ideas -- proposals, answers, or solutions of some kind -- and tightly bound to those ideas are their justifications. Each justification in turn gives rise to new ideas, each of which has its own justification (see Figure 1). A well-functioning Answer Reflex assures that no one asks "What is the question here?"




Figure 1: The Answer Reflex

This is not to say that people don't frequently ask questions. Indeed, to be a skillful politician or rhetoritician is to make effective use of the interrogative form. However, "rhetorical" questions (e.g. "Do we want another four years of inflation in this country?" or "Are you always this dense?") neither open the dialogue nor foster a mood of inquiry -- they are simply a kind of position or assertion with a question mark on the end, and are very much a part of the Answer Reflex.

Buckminster Fuller described the Answer Reflex as the "Mistake Mystique": the tendency to avoid both the risk of being wrong and the vulnerability of not knowing by always "knowing the right answer." He pointed out that while this may have been a good strategy for success in our educational system, it has done enormous damage to our ability as a nation to think powerfully and creatively about the complex problems that now face us.

The Power of IBIS

The power of IBIS (and QuestMap) is that it moves the asking of questions into a central role in the dialogue process (see Figure 2). In IBIS, ideas are always defined relative to some question. This makes it somewhat more difficult for discussions to devolve to the "Yes, it is!" - "No, it isn't!" cycle, and it creates a discipline of care and rigor about being relevant. Since comments are more naturally addressed to an explicit statement of the question, it becomes more obvious when a discussion has the character of a "Yes, A!" - "No, not B!" cycle, in which two people are vociferously stating non-opposing propositions. (Here, "A" represents a statement like "The product must have quality" and "not B" represents a statement like "The product must not cost a lot.")



Figure 2: The Answer Reflex is broken by interposing Questions.

While IBIS has the same elements as the Answer Reflex, it puts a different priority on them. All discussions start with a question. Possible answers (called "Ideas") are clearly stated in response. Justifications (called "Arguments") are added to the ideas and can be either supporting or objecting to the idea (see Figure 3). As the arrows pointing back toward "Question" suggest, both Ideas and Arguments can easily give rise to new, deeper Questions.



Figure 3: The IBIS Model.

It has been our experience over the years that knowing about the IBIS method is very different from practicing it naturally. The old habits die hard, particularly in the heat of meetings and conversations in which critical decisions are being made. Having a high quality dialogue sometimes seems less important than having the "right answer" be accepted by the group. But most of us would acknowledge that the habits of dialogue (based on the Answer Reflex) that we bring to these meetings are perhaps at the very source of the pervasive frustration about the amount of time spent in meetings and the lack of real effectiveness in them.

Sometimes you have to work slower in order to work faster. It is common in sports and the arts to slow down the performance of an activity in order to observe and improve it. Effective team dialogue is such an activity. The intent of this manual is in part to encourage the reader toward a lifelong pursuit of excellence in communication and teamwork, and in part a first lesson in the "language" of issue-based dialogue, which, like any language, can only be mastered through practice. Fortunately, you will have in QuestMap an environment for the discipline of dialogue, and a virtual "land" where everyone speaks the IBIS language.

The Heart of IBIS: Questions, Ideas, and Arguments

The heart of IBIS is the matrix of Questions, Ideas, and Arguments that combine together to create a conversation.

• Question -- states a question;
• Idea -- proposes a possible resolution for the question; and
• Argument -- states an opinion or judgment that either supports or objects to one or more Ideas.

All conversations in IBIS start with a root Question. This will generally be something like "What should be our strategic plan for the next 5 years?" or "How can we increase customer 'delight' in our products and services?".

The response to a Question is one or more Ideas which provide a brief, neutral proposal for resolution of the Question. Ideas are linked to their Questions with "responds to" links. Ideas present a challenge to new users because of the great tendency, described above as the Answer Reflex, to bundle the justification for the Idea into the proposal itself. For example, "We should provide a toll free Customer Support Number because it is more inviting for customers to use." This is a critical error because the justification (the "because" part) has a natural and important place in the IBIS structure as a supporting Argument node. To combine it in the idea, however, makes it difficult to add other argument nodes to the idea and to thoroughly explore its pros and cons.

An Argument is a statement or opinion which either supports or objects to one or more Ideas. Arguments are the place -- indeed, the only place -- in the IBIS method for opinion, clever rhetoric, and hand waving. Of course, it is preferable to have Arguments which provide factual assertions bearing on the advantages or disadvantages of an Idea. The IBIS method considerably raises the quality of dialogue within a group or project team simply by concentrating opinions into Argument nodes. For example, the old trick of "truth by repetition" -- saying one's point over and over until everyone else accedes -- is disarmed, because once an Argument has been posted it becomes silly and obvious to repeat its contents. Arguments are linked to their Ideas with links (see Figure 4) called "supports" (for pros) and "objects to" (for cons).



A text version of the above:

1. Question: "What system should we buy?"
     1.1 Idea: "X"
         1.1.1 Con (Objects to): Doesn't fit w/ existing tools
     1.2 Idea: "Y"
         1.2.1 Pro (Supports): State-of-the-art Technology

Figure 4. A simple IBIS map and its text version

The question in Figure 4 deals with the choice of a new computer system. Two possible solutions have been offered so far, X and Y. X has the objection that it doesn't fit with existing tools, and Y is supported by the claim that it is state-of-the-art technology. Notation: the icons represent IBIS nodes (e.g. the "?" stands for "Question"); since Ideas can only respond to Questions, the links from the Ideas to the Questions are understood to be responds to links; the minus sign ("-") above the upper Argument link indicates an objects to link type; and the plus sign ("+") indicates a supports link.

Beyond IBIS

So far we have discussed the basic structure of a Question, its Idea, and their Arguments. This basic form is sometimes called a "QIA" for short. Of course, the real power of IBIS and QuestMap begins to show when an IBIS discussion gets large, and when there are many interrelated QIA's in the map. In order to provide for the various kinds of relationships that are used in a conversation, and for the need for additional types of conversational elements, QuestMap includes node and link types that go beyond the basic QIA structure.

Advanced Links

Among QIA nodes QuestMap provides additional link type to enable full dialogue capabilities. The link types are as follows:

Specializes. The specializes link means that one node is a special case of another node of the same type. Thus, if the first Question were "How should we design the new car?" (in an automotive design organization), a second Question which asked "How should we design the new car's engine?" would have a specializes link to the first, because it deals with a part of or a subcase of it. Similarly, an Idea can specialize another Idea. If the Question were "What components should the car have?", one responding Idea might be "The drive chain", and it might have the sub-Ideas "Engine", "Transmission", and "Wheels" (see Figure 5).



Figure 5: An Idea with three sub-Ideas that specialize it.

Challenges. A challenges link is used when a Question challenges some part of the content of another IBIS node (a Question, Idea, or Argument). It could be an explicit claim in an Argument that someone wishes to dispute. For example (see Figure 6), if there were an Argument that objected to a certain Idea, saying "The cost of this item will be more than budgeted," someone else, who knew about a special discount that was available, might challenge that Argument with a new Question asking "Will it cost too much?", an Idea saying "No", and an Argument supporting "No" by claiming "For the next 30 days there is a special discount that will put this item's cost within budget."



Figure 6: A Question can be used to challenge the claim being made in an Argument.

Challenging some Question, Idea, or Argument with a new Question is one of the most powerful features of the IBIS method, because is prevents the "Yes, it is ... No, it isn't ..." disagreement cycle from ever getting started. Instead, by raising a question, a spirit of inquiry is brought to the disagreement .

Expands-on. This link is used when a Question further develops an Idea in another Question or an Idea or Argument. The second Question thus "expands on" the idea by exploring it in more detail. For example, if one Idea on a particular Question offered the "Hire more people," then someone might create a Question which expands on that Idea by asking "How many people should we hire?."

Other Node Types

Just as with the need for additional link types to flesh out the basic QIA structure, QuestMap provides additional node types as well. The node types are as follows:

	Note Nodes. A Note node is like an electronic "Post-it" -- it can say anything, be placed anywhere, and be linked to anything. For example, a Note node called "Introduction," placed in the upper left corner of a map view, is a good place to provide any context setting and background information for the view.
	Reference Nodes. Reference nodes form electronic links to documents which are not in QuestMap. Any document (or spreadsheet, fax image, etc.) which can be accessed from Windows can be directly represented as a QuestMap Reference node. A typical use of a Reference would be linking an on-line reference document to an Argument which made a claim based on data in the document.
	Decision Nodes. Decision nodes capture the resolution of a Question into a decision. The Decision node is linked to the Question node that has been resolved, and contains text explaining what the decision is, how it was made, etc. Decision nodes can also capture the set of IBIS nodes in the discussion of the Question that reflect the "line of reasoning" that led to the decision.
	QuestMap Mail Message Nodes. Mail Message nodes are generally only seen in a user's QuestMap Mail Box. Each node represents a message. Because of the flexibility of QuestMap it is possible to cut (or copy) a mail message from one's mailbox to some other view. This is useful when a discussion that started as a mail exchange is moved to a map view for a full IBIS conversation on the subject. Mail Message nodes, like Note and Reference nodes, can be linked to other node types.
	View Nodes. View nodes contain the QIA and other nodes that make up a QuestMap conversation. When a view node is "open" you see it as a window on your screen. However, view nodes also exist in the icon state and are themselves contained in other view nodes. In its icon state a view node can be linked into a conversation just like any other node. This gives you the ability to "remember" exactly what was said in one conversation while in the midst of another conversation.

Resolution

The original work on the IBIS method did not address the process of resolving questions -- making and implementing decisions. Horst Rittel considered issue resolution to be a very organization-specific process, and felt that IBIS should stay focused on helping organizations to fully explore and communicate about the complex problems they faced.

In our own research, we have found that the process of resolution, of "making decisions," is one of the most complex and interesting phenomena in organizational life. There is an ideal of decisions as being made based on gathering and assessing all of the challenging data. Also, "good" decisions are regarded as final. Often, however, decisions are (implicitly or explicitly) tentative: they are subject to being "undecided" or re-decided if new information comes in or conditions change. Of course, it is widely recognized that the rationale for decisions is quite commonly forgotten, thus causing an organization to put significant resources into remembering why something was done, or even reinventing the solution.

Thus it is more useful to consider resolution to be an on-going process, and to consider the conversations and information that lead to the decision -- the rationale -- to be as important to remember as the decision itself. This is what QuestMap does.

In QuestMap there are three components of the problem definition and solution process:

• Divergence: a conversation in which participants freely and creatively explore the problem, raising new questions and bringing in many different points of view;
• Convergence: a more focused conversation in which users make sure they understand each other and all of the proposals, and in which consensus begins to build;
• Decision: a conversation in which a solution to the whole set of questions is synthesized and the decisions recorded (this is often a face-to-face meeting).

Ideally, a problem or project spends most of its time in the Divergence phase. (While QuestMap is a powerful tool for all three aspects, it is the only technology available for this phase.) Somewhat less time is needed for Convergence to emerge, and Decision requires very little time at all (especially if the other two phases have been done well). To support Convergence, we have developed a convention for indicating the emergence of consensus among a group. If someone feels that there is a particularly strong Idea that resolves a Question, and there is no further information or pros and cons to be added, she can endorse the Idea in the following way. Create an Argument which supports the Idea, label the Argument "Endorsed", and put just her name (or initials) in the Subject field. An "endorsement Argument" should support only one Idea, and there should be only one such Argument node for any Idea (see Figure 7). Thus, if someone else feels they would also like to endorse the solution offered in the Idea, they simply edit the endorsement Argument and add their name (or initials) to the Subject field. This is a kind of voting (technically called "multi-voting") which makes the Convergence process explicit and visible in the map.



Figure 7: An Argument used to endorse Idea Y.

Another step in convergence is the elimination of ideas. Indeed, sometimes one makes a decision by eliminating all of the options until there is only one left. In IBIS this is called "retiring" an Idea, and it is shown by putting the label in parentheses. Thus to show that you had retired the option "X" in Figure 7 you would change its label to "(X)".

In IBIS, indicating which Idea under a Question has been selected as the decision can be done with a Decision Node, or by marking the label with an asterisk (e.g. "X" becomes "*X"). See appendix A for some guidelines on decision making.

Subtleties of IBIS

The IBIS method is deceptively simple. It would seem that with 5 minutes of study one could jump into a complex problem and start framing Questions, Ideas, and Arguments. After all, it's really just questions and answers, pros and cons, right? What can be so hard about that? The only hard thing, really, is that IBIS is a "conversational model" which differs somewhat from the conversational model in which we are all already lifelong "experts" -- the Answer Reflex described above -- so one must unlearn this comfortable and familiar model in order to be fluent in IBIS.

In particular, there are two mistakes that most IBIS beginners make. The first is putting more than one point into a node. The value of IBIS diminishes quickly if there is more than one question in a Question node (e.g. "How should complaints be handled, and who should handle them?"), or more than one proposal in an Idea node (e.g. "Get a new advertising firm and downsize the marketing department.") The problem is not that it is hard to create such nodes -- QuestMap does not monitor the quality of the text users enter. The problem is that it is very difficult for other users to respond to them properly. If there are several questions within a Question, which one is any given Idea addressing? If an Idea has multiple proposals, an Argument might object to one and support the other at the same time -- what kind of link would you use for that?

The second common mistake is putting a point into the wrong kind of node. For example, putting a Question in an Idea, or using a Question node for a general announcement. Again, the problem here is that a few such mistakes can literally grind an IBIS discussion to a halt. Such methodological rule violations sometimes seem insignificant to users in the thick of a discussion ("Everyone can see what I wrote -- what the heck difference does it make what kind of node it's in?!?"). But the rules of IBIS are not arbitrary. They provide a framework in which all of the players can keep contributing their ideas, examining their own assumptions, and seeking together to find the real issues. As a user of QuestMap you will not only be learning the rules of the game, you will also be called upon to be a referee and coach for the other users on the team. This will assure that methodological errors do not derail the conversation process.

Once you have become adept at the IBIS method you will find that most conversations can be seen to consist mostly of Questions, Ideas, and Arguments. Usually the Questions are implicit, and the Ideas and Arguments are bundled pretty tightly together, but there is little else being said besides the core IBIS trilogy. This is actually a remarkable statement! We are saying that even the most sophisticated planning, analysis, and design conversations, no matter how complex the subject, are conducted by an exchange of Questions, Ideas, and Arguments. For this reason we sometimes refer to these three conversational items as the "Bohr model of the rhetorical atom."

In the first part of this century Niels Bohr proposed that all matter was composed of atoms, and that atoms had a fine structure consisting of three fundamental particles: electrons, protons, and neutrons. All of the elements in the newly emerging atomic table could be accounted for in terms of their subatomic configuration of these three particles. Similarly, we have found that the "elements" of planning, design, and analytical discussions are made up of the three "particles" of the IBIS method. This is why there is no limit to the problems that can be tackled using IBIS and QuestMap.

Using IBIS in QuestMap

QuestMap implements and enhances IBIS to take advantage of the graphical user interface and the hypertext concept of information processing. This section highlights and explains a few of the "Rules of the Road" when you use IBIS as adapted in QuestMap.

Some Notes on Style

QuestMap is a kind of "word processor" for group conversations and information sharing. Thus, QuestMap and IBIS can be used in a wide variety of ways -- indeed, with very different styles, conventions, and practices -- but it is up to the group to make sure that the content is interesting, coherent, and relevant. Moreover, unlike one's personal word processor, QuestMap's usefulness depends critically on the group developing a set of shared conventions and practices. Therefore, we would like to recommend some initial practices which, though they may seem minor, will help to reduce the amount of "friction" in the early phases of the group's evolution of its own practices and culture.

Capitalization. It is best if standard capitalization is used in all nodes. Notice the difference in mood between "all lower case", "First letter capitalized", and "ALL CAPITALS". In general, the latter has extra emphasis, almost as if the writer is shouting in print. Capitalize the first letter only, as with normal prose.

Spelling. It may seem either trivial or insulting (or both!) to suggest that correct spelling is important, but there are some special reasons to be careful about spelling in QuestMap. First, the search mechanism cannot find misspelled items. As the database becomes large it will become increasingly important be able to search for all occurrences of specific terms. If you accidentally misspelled "environment" in a node, then someone looking for discussions about the environment is not going to find your comments.

Second, poor spelling reflects hurried and thoughtless writing. Imagine your impression upon receiving a thank you note from a colleague which says "Thanx vry much for the lovly gift!" Similarly, what will be the impact on persuasiveness in an Argument if key terms are misspelled?

Node labels. IBIS conversations are conducted in QuestMap by a group of users collaboratively constructing a map of the problem by creating nodes and links. Each node icon has a Label attached to it. Node Labels that are well done allow both the author and other users to quickly review a conversation. Labels should summarize the Detail as succinctly as possible. Thus if the Detail is "How can we improve our department's customer service?," some possible Labels are:

• How to improve service? Good.
• Better customer service? Also good.
• Improve customer service? Also good.
• Customer service? OK, but ambiguous.
• How can we? Poor.
• Improve? Poor -- too brief.
• Our department's customer service? Too long.

For beginning users, it is generally advisable to start by writing the Subject of a node, and then go back and give it a Label. With practice one can often start with the Label (but even experts have to occasionally go back and "tune" a node Label to make it clear and concise).

Detail Fields. The Detail field of a QuestMap node is the place for a one or two sentence statement of the node Label. It is best to write this as a well-formed, if short, paragraph. One of the most common errors of beginning users is the tendency to have long rambling Subject/Detail fields. These long texts are usually an indication that the author has included information that would be much better placed in separate nodes. (On the other hand, it is important to include enough background information in these fields to make them intelligible -- where the fine line between too long and not long enough gets drawn in practice is a matter of style and convention.)

Link direction. Links are a kind of graphical "punctuation" that tell other users how to interpret the statements contained in the IBIS nodes. QuestMap conversations unfold from left to right, just as English writing goes from left to right and scientific diagrams show time increasing to the right. Thus QuestMap maps start with a Question on the left, then one or more Ideas on the right of it, followed further to the right by the Arguments. New Questions, Note nodes, and Reference nodes go even further to the right. However, the links in IBIS maps always point to the left This is because the links are created by dragging the mouse from right to left -- from the new node back to the old one.

This may sound confusing, but with a few minutes practice it becomes second nature. The reason we emphasize it is that, sometimes, when new users discover the great freedom that QuestMap allows in the placement and layout of nodes, they experiment with more "artistic" layouts. This poses a problem for other users, who are expecting a conventional left to right layout. In addition, certain QuestMap commands (e.g. Arrange and Print Text) are designed to read map views from left to right.

Another aspect of the importance of linking nodes from right to left has to do with avoiding the possibility of creating an incorrect link. Consider a simple example. If there is a Question on the left and an Idea to the right of it, QuestMap assures that a link from the Idea to the Question (to the left) can only be a "Responds-to" link (see Figure 8). If you forget and try to draw the link from right to left, the QuestMap menu will ask you to select either a Challenges link (meaning that the Question comes after and challenges the Idea), or an Expands-on link (meaning that the Question comes after and expands on the Idea). Fortunately, the menu also offers one other option: a "Help" menu entry, which if selected suggests you try the Responds-to link.



Figure 8. Link Direction Effects Link Type

Some Guidelines For Effective Dialogues

This section explores some simple "rules" for stating Questions effectively, even powerfully. The rules are not absolute, but they reflect years of observing the kinds of questions that lead to high quality dialogues and, conversely, the kinds of questions that can derail or stop a conversation.

Rule 1: The Simplicity Rule

The statement of a Question should be simple and concise. It should not contain possible answers. It should avoid the words "and", "or", or "not". The question should not be restated nor developed in the Detail field. (Detail is for occasions when unarguable background, or the definition of a term, is needed).

Using IBIS makes a conversation more precise, but to gain this benefit one must be careful not to lump several ideas into one node, even if they seem very similar. In practice, this means that what at first seems like a single Question sometimes ends up being two or three related Questions. Don't hesitate to create several Questions as a way of understanding a problem. They can always be folded together later on, and in a shared conversation space this is much easier to do than breaking an overloaded Question apart after people have started responding to it.

Example 1.1:
Instead of:
1. Question: What should we do about X and who should do it?
[Contains 2 questions.]

Use:
1. Question: What should we do about X?
     1.1 Idea: Appoint someone to study it.
         2. Question: Who should do it? (Expands-on Idea 1.1)

Repair procedure:
Create separate question nodes.

In examples such as this one, our notation will always make Questions top level items in the outline, so that they start at the left margin and have simple integer numbers (e.g. 1, 2, 3, etc.). If a Question has an important relationship with some other item, that relationship will be expressed in parentheses, as was done with "Expands-on Idea 1.1" in example 1.1.

Rule 2: The Open Question Rule

The statement of a Question should be open, so that any number of possible solutions can be offered as Ideas. In particular, avoid "Yes/No" Questions, and Questions that follow the pattern "Should we do X or Y?". One of the benefits of QuestMap and IBIS is to expose unconsidered possibilities, but this benefit is eliminated if the Question is not asked in an open-ended way. Our experience has been that Yes/No and multiple choice questions nearly always close a conversation down.

Example 1.2:
Instead of:
1. Question: Isn't X too expensive? [Implies the answer.]

Use:
1. Question: Is X too expensive? [OK] or

1. Question: What is the cost of X? [Best]

Repair procedure:
State the question in a neutral way (without the "not").

Yes/No questions are a special case of multiple choice questions in which there is only one choice and it must either be confirmed or denied. In general Yes/No questions begin with either "should" or some form of "be" or "does". Here are some examples of Yes/No type questions:

• Should we do X? (or ... have X?, ... be X?)
• Does X happen?
• Do we want to do X?
• Can X be done?
• Is X the case? (or ... best?, ... correct?, ... optimal?)
• Does X matter?
• Is X the same as Y?
• Do we know X?

Now, it would be an overstatement to say that Yes/No questions should never be posed. There are infrequent cases where this is a valid form. The point of this rule is that the occasions when this form is needed are far fewer that the occasions when it naturally springs to mind. Recall that one function of the Answer Reflex is control. What better way for someone to control a dialogue than to restrict the range of options to those that suit them?

Example 2.1:
Instead of:
1. Question: Should we do X to solve problem Y?

Use:
1. Question: How should we solve problem Y?
      1.1 Idea: Do X.

Repair procedure:
Move the built-in solution ("X") into an Idea and reframe the Question so the Idea responds to it.

For those cases where a Yes/No question is appropriate, avoid the use of "maybe" and "don't know" kinds of Ideas, since these are not real answers to the question and will invite further IBIS problems.

Multiple choice questions are also framed in a closed way, that is, they contain several "answers" but they look like a question (see also Rule 3 -- The Embedded Solution Rule). These are a little easier to spot, because they contain a whole list of solutions. Multiple choice questions are also easier to reframe into open ended questions. In general, questions that begin with the "wh" words ("what", "where", "when", "who", and "why") create the opportunity for the most open type of response. Questions starting with "how" are also nearly always open.

Example 2.2:
Instead of:
1. Question: Should we do X or Y?

Use:
1. Question: What should we do?
     1.1 Idea: Do X.
         1.2 Idea: Do Y.

Repair procedure:
Reframe the question using a "wh" word and move the possible solutions into Ideas.

Indeed, there is often a pattern to IBIS Questions in design or planning conversations. The root Question asks, in some way, "What is the overall problem?" (or "goal" or "desired result", etc.) and the Ideas which respond to that Question offer possible formulations of the problem. For each of these Ideas, it is appropriate to ask, in some way, "How can this problem be solved?". The Ideas which respond to this second Question offer solutions, and of course there will be arguments for and against these solutions. Each of these solutions can be regarded as a new problem, to be explored with "wh" questions such as "What is needed for X?", "What capabilities should X have?", "What should X do?", etc.

Thus there is a natural alternation between questions which ask "What should be done?" and those which ask "How should it be done?". Chains of these Questions can be used to explore and analyze a problem at any depth. (Of course, as the IBIS network becomes large it becomes increasingly necessary to have a tool like QuestMap to manage all of these Questions and their interconnections.)

Rule 3: The Embedded Solution Rule

The statement of a Question should not contain elements of any potential solution or answer. This rule formalizes several guidelines mentioned above. If "S" is an element of the Solution of a problem, avoid Questions such as "Should we do S?" or "Is S needed?" which have solution or action S built into them. Instead, abstract out the Problem to be solved (e.g. "P") and ask "How to solve P?" or "How to improve P?". Then, create a responding Idea containing the proposed solution S.

Example 3.1:
Instead of
1. Question: Is there a need for a Public Relations effort?
     1.1 Idea: Yes
         1.2 Idea: No

Use:
1. Question: How can we improve client relations? (or public relations?)
     1.1 Idea: "Public Relations Effort"
         1.2 Idea: "Client Advocate Team"
             1.3 Idea: "Use surveys"

Repair procedure:
Move the built-in solution ("X") into a n Idea and reframe the Question so the Idea responds to it.

This approach has two benefits. First, Arguments for and against the "solution" can be easily provided when it is an Idea. More importantly, if there are other possibilities (such as a Client Advocate Team, or the use of surveys) they can be other responses to the Question, instead of having to be suggested someplace else in the discussion.

The next example (Example 3.2) illustrates that questions which begin with "should" (e.g. "Should we do X?", "Should X be done?", "Should we have an X?", etc.) nearly always contain the solution (the "X") and ask, in essence, "Given X, what should we do?" When you already have an idea or solution in mind (as one often does), it is best to ask a question that allows you to propose your idea as one solution. Thus it is usually preferable to ask a simpler, more open ended question, such as "What should we do?".

Example 3.2:
Instead of
1. Question: 1. Question: Should we do an X project? [Contains an answer, the "X project".]
     1.1 Idea: Yes
         1.2 Idea: No

Use:
1. Question: Question: What project should we do?
     1.1 Idea: X project

Repair procedure:
Change the question to start with a "wh" question word. Then propose the built in solution as an explicit Idea.

The next example (Example 3.3) builds on the previous one to make an additional point. Recall that the Answer Reflex consists of an idea and its justification (see Figure 1). Often the justification (e.g. "because it is cheaper") masks a hidden understanding of the problem (e.g. "costs must be minimized"). It is very good IBIS form to raise a question about what the problem is, thus allowing you to make your understanding of the problem explicit. As Example 3.3 shows, the innocent phrase "to assess client needs" in the first part has been repaired in the second part to make an explicit Question about the problem. In other words, if part of the reason for doing an "X project" is that it helps "assess client needs," then there may be other aspects of client relations which need to be explored.

Example 3.3:
Instead of:
1. Question: Should we do an X project to assess client needs? [Contains an answer and some description and support for that answer.]

Use:
1. Question: What client satisfaction problems do we have?
     1.1 Idea: Unknown Client Needs
         2 Question: How can we assess client needs? (Expands-on Idea 1.1)
             2.1 Idea: X project

Repair procedure:
Reframe the question using a "wh" word to make the discovery of the problem its own question. Then for each problem, use a "how" question to explore possible solutions.

As a side note, one technique for dealing with a "hot idea" is to go ahead and create an unconnected Idea for it. Once you have a well-formed Idea (and perhaps even some supporting arguments), you can go back and create the Question for which the Idea is a response. This technique frees you to capture ideas in a comfortable and familiar manner, but still leads to a well-formed IBIS discussion.

Rule 4: The "Other" Rule

The statement of a Question should not contain the word "other", as in "What other ...?". A Question which asks "What other solution is there?" is usually redundant -- the "other" means that some solutions have already been offered to some other question. Perhaps the "other" Question was added because a previous one contained its solution, violating Rule 3 (The Embedded Solution Rule), and forcing other users to "re-open" the Question with a restatement of the same basic question.

Example 4.1:
Instead of:
1. Question: What systems are available?
     1.1 Idea: X
         1.2 Idea: Y
             1.3 Question: What other systems are available?

Use:
1. Question: What systems are available?
     1.1 Idea: X
         1.2 Idea: Y

Mail Message: "I would like for the group to offer some additional alternatives to this issue by 5 PM Thursday. We will be making our decision at the staff meeting on Friday."

Repair procedure:
Delete the "other" Question and send QuestMap mail to the interested parties enclosing the Question and existing Ideas and urging further work on the problem. A due date is beneficial.

A second situation in which we see "other" questions is when the original Question was open, but someone is dissatisfied with the number or quality of the proposed solutions. In this case, that person should send QuestMap mail to all of the stakeholders of the Question (with the Question and its existing Ideas as "context"), asking for more discussion, and placing a time limit on the conversation (e.g. "Please contribute to this conversation this week. We will be closing QuestMap discussion of this question on Thursday at 12 PM, and making a decision at the 1 PM staff meeting.").

Rule 5: The No Benefits Rule

The statement of a Question should not ask for the benefits or disadvantages of a situation or solution. IBIS provides a specific place for pros and cons -- in Arguments. If the Question asks for pros and cons then they will be stated as Ideas, which will confuse and distort the conversation.

Example 5.1:
Instead of:
1. Question: What are the benefits of switching to X?
     1.1 Idea: Cheaper
         1.2 Idea: Faster

Use:
1. Question: What should we switch to?
     1.1 Idea: X
         1.1.1 Argument: Cheaper (supports Idea 1.1)
             1.1.2 Argument: Faster (supports Idea 1.1)

Repair procedure:
Move the embedded solution into its own Idea, and move any benefit or disadvantage Ideas into Arguments, with the appropriate links.

Special Topics on Using QuestMap

While this manual is largely devoted to the IBIS method, there is a gray area between the IBIS methodology and the QuestMap tool which is most conveniently covered here.

Using QuestMap Mail

There are generally two kinds of electronic communication tools: those that are "undirected," which place each message from a user in the public space for all to view and respond to (e.g. electronic bulletin boards, teleconferencing systems), and those which are "directed," which send each message to a specific user or users (e.g. electronic mail). QuestMap is primarily a system for undirected communication, but not all communication in an organization is best handled in a public forum. Thus QuestMap also provides for directed communications through an internal email system. In addition, QuestMap Mail has some unique features, such as allowing messages to be copied into the public space if needed, and providing a way to reference a public discussion in a private message. The methodological question is: when should you use the private mail channel?

When to Use QuestMap Mail, When Not To

QuestMap is normally used for discourse among members of a team or organization. Each node is created by a member of the group to contribute to the group, by raising a new question, suggesting new ideas, providing new information, and so on. Occasionally, however, it happens that members of the group need a less public way to interact. For example, sometimes there is something to be discussed which is transient in nature, and for which the users don't want to leave a permanent trace in the issue base.

Here are some of the occasions when QuestMap Mail is the appropriate medium:

1. One user, X, thinks that Y has made a methodological error, such as failing to state a question properly. User X might send a mail message with the question node as context to Y asking for a rephrasing. When Y has corrected the mistake he or she sends a reply mail message to X acknowledging the correction.

2. User X creates a new discussion, or adds to an existing one, and wants to call the new addition to the attention of specific people. X sends mail to the people, with the new View, or the new nodes, as the context of the message.

3. User X has an idea which seems too risky or strange to put into the public space. X might send a mail message explaining the idea to some colleagues asking for their reaction. Even better would be for X to create a private Map View in his or her Home View, begin the discussion in this view using IBIS, and email the view to the colleagues for their contribution. If the discussion seems to be productive, X can later copy this new view into the Commons for open public discussion.

4. User X, a manager, notices that a key question is languishing without any discussion. He or she might use email to ask someone on the staff to do some research and seed the discussion with a few well thought out and supported ideas addressing the question.

As some of these examples may suggest, there is a gray area between those topics which are clearly directed and those which are clearly undirected. Sometimes there might be several private discussions about a problem, each ignorant of the others. In the worst case, some members of the group are (privately) taking action on a idea that other members of the group have (privately) already ruled out. This is just the kind of coordination problem that QuestMap is meant to eliminate! Other times a member of the group might criticize another in the public issue base when a more private message would have been more appropriate. There can be no fixed rule about when to use email and when not to -- each group will develop its own conventions. We have found that initially users are timid about putting their ideas up for public discussion, but that this shyness passes as the group learns to trust itself and QuestMap.

How to Tell if a Problem is Wicked

A common concern for users of IBIS and QuestMap is knowing when to take the trouble to use them. The short answer is: Use IBIS and QuestMap when the problem is wicked! The list below will help you get a better idea if you are working on a wicked problem:

• The problem definition seems vague or keeps changing.
• The proposed solution creates a new, related problem.
• There are lots of meetings on the project but not much progress.
• There are a lot of "cooks" in the kitchen.
• The number of stakeholders keep increasing.
• Your career is at stake.
• You can't easily see the solution at the outset.
• There are multiple solutions, but no consensus and no convergence.
• The constraints on the solution keep changing.
• There are lots of political or "organizational" issues.
• The decision was already made, but it's not being followed (i.e. it's not a real decision).

For more help on identifying and working on wicked problems, attend GDSS's Creating Collaborative Meetings course or see the forthcoming book The Information Paradox: Using Team Intelligence to Solve Wicked Problems, by Jeff Conklin, William Weil, and Lansing Bicknell.