[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] IBIS question


Johannes,    (01)

Congratulations on getting IBIS into your Pepper product.  That's very
exciting!    (02)

The example you describe is a common design and problem solving type of
decision.  It turns out that there's some "tacit knowledge" and/or
experience that is required to find the right "texture" for IBIS networks
on real problems.  It's a bit of an art.  (I'm working on a book about it,
but so far my experience is that, like dancing or painting, it's best
taught side-by-side.)    (03)

To take your example, here's how we would deal with this in the Dialog
Mapping workshop.    (04)

First principle: a decision is simply a selected Idea (or several), so the
ideal is to have anything you'd call a decision be represented as one of
the Ideas on the Question.    (05)

Therefor, your first decision option, "Go with Idea 1" is represented by
simply marking Idea 1 as the decision (i.e. with an asterisk, or, in
QuestMap, with a hammer/gavel icon).      (06)

Your third "decision option":    (07)

>3) go with idea 1 for 6 months, redesign product in the meantime, go 
>with idea 2 for 6 months thereafter.    (08)

is not separate from the IBIS structure -- it belongs IN the IBIS
structure.  It would be captured as a third idea, e.g.
 Idea 3:  Buy new computer for customer, and redesign XYZ component in the
product for delivery in 6 months.    (09)

In QuestMap or Mifflin the label might be an abbreviated "Buy computer,
install upgrade in 6 mos" ... a brief summary of the longer, clearer text
in the Detail.  There are fine points about how to spin together the
elements of a complex Idea like this one, but it doesn't change the basic
thinking.    (010)

Another principle: everything that is or could be a tradeoff or rationale
is captured as a Pro or Con.  By definition, a Pro argument for Idea M is
any statement that would help support or justify choosing M as the
answer/decision of its Question (and of course conversely for Cons).  So ...    (011)

>What I'd like to express are things like "our plan of action is 
>alternative 1 because we only have X customers right now, and the ROI 
>for alternative 2 is not good enough given that it's only X 
>customers,     (012)

... simply says that 
"The ROI is too small with only X current customers" is a Con for Idea 2,
and Idea 1 is selected as the decision. Again, you might put the longer,
clearer version in the Detail.  With practice, one begins to see how most
of design-related conversations sorts into the three basic elements of
IBIS, with a little more  syntax for "Decisions", "Retired Ideas", "Notes",
etc.  But IBIS can be much richer than just a logical notation or decision
calculus -- it's really just a notation for telling a story about an open
issue or a decision.  By the way, the word "because" is a good indicator
that there's a Pro or Con coming.      (013)

Finally, for many practical cases time can simply be captured in the text
of argument, thus:    (014)

>... but once X has grown above Y, we will change to 
>alternative 3".     (015)

... becomes a Pro for Idea 3, something like "Cost effective once X has
grown above Y"    (016)

That is, instead of introducing a new syntactic construct or other
complexity to deal with time lines and contingencies, we simply stick with
the basics of IBIS and capture complexities in the text of the Pros and
Cons.  Within IBIS, Pros and Cons are the natural and correct place for all
such complexity, by the way.  Ideas should be neutral, and Questions are
best when simple and open.  Reading about all this makes is sound like a
big pile of rules to remember, but reading about dancing would have very
much the same flavor.    (017)

Anyway, in my experience IBIS is terrific for capturing the reasons for
decisions.  It's true that IBIS doesn't help you make a decision.  As Horst
Rittel often pointed out, decision making is a social process, and is very
context-dependent. In my experience there's no mechanism or trick for
making real decisions, but that's another story.    (018)

Does this make it clearer how you would use IBIS to capture tradeoffs?    (019)

Yours,
Jeff    (020)

PS If you haven't seen it the IBIS manual (at cognexus.org) might be
helpful at this point.    (021)

At 10:00 PM 1/27/02 -0800, you wrote:
>We have incorporated IBIS into our product, Pepper, and it is very 
>useful at "putting all the facts on the table" in order to enable 
>informed decision-making by a person based on those facts.
>
>However, I'm not convinced that it can do much in order to actually 
>help making the decision, and then record the reasons for a decision. 
>Why? Because deciding on anything non-trivial involves lots of pros 
>and cons for lots of ideas, but the decision is never clear-cut. It 
>is always a tradeoff, and I'm not sure how to use IBIS to capture 
>that tradeoff and the conditions under which one would redo the 
>decision.
>
>Simplistic example:
>Question: How can we meet the customer requirement "product needs to 
>run faster"?
>- Idea: Buy a new computer for the customer
>     Pro: product will run faster
>     Con: substantial customer confusion and installation issues
>- Idea: Redesign XYZ component in the product
>     Pro: seamless upgrade for the customer
>     Con: long design cycle
>
>There's no clear "right" idea here -- the obvious alternatives are:
>1) go with idea 1
>2) go with idea 2
>3) go with idea 1 for 6 months, redesign product in the meantime, go 
>with idea 2 for 6 months thereafter.
>
>What I'd like to express are things like "our plan of action is 
>alternative 1 because we only have X customers right now, and the ROI 
>for alternative 2 is not good enough given that it's only X 
>customers, but once X has grown above Y, we will change to 
>alternative 3". IMHO, that would be much more useful because that 
>would capture not just the facts, but also the course of action and 
>the tradeoffs.
>
>So my question: is anyone aware of any work that extends base IBIS to 
>help with this scenario?
>
>I appreciate it. Cheers,
>
>
>Johannes Ernst
>R-Objects Inc.
>
--     (022)

Dr. Jeff Conklin	     <jeff@cognexus.org>
CogNexus Institute ... Collaborative Display, Collective Intelligence
http://cognexus.org	     Phone/Fax: 410-798-4495
304 Arbutus Dr., Edgewater, MD 21037    USA    (023)