Re: [ba-ohs-talk] IBIS question
The Compendium approach has sought to extend the usefulness of IBIS, in
part by providing an alternative set of structures and templates to use in
the types of situations Johannes describes. One of the fundamental premises
of Compendium is that "modeling" types of approaches (structured frameworks
derived from engineering and other analytical disciplines) can interweave
with IBIS in all sorts of useful ways. These are explored and illustrated
in a number of papers that can be found on the <a href =
http://www.compendiuminstitute.org/library/papers.htm>Compendium
Institute</a> site. (01)
Coming up with the best representation for the scenario below would depend
on a set of situational factors, such as the composition of the group, the
amount of time they have, the skills and backgrounds, the downstream
audience, etc. What (in general) a Compendium practitioner would prescribe,
though, would be a set of templates that decompose the problem and solution
into component parts that could be represented (and referred to)
separately. For example, a "timing" model would show the sequence of
Alternative 1 and Alternative 2. The rationale for the timing can be
modeled (using IBIS) on that 'map'. The nature and pieces, though, of
Alternative 1 and 2 themselves would be modeled separately in "task" or
"object" models, as would the "customers", "ROI" calculations and
assumptions, etc. What makes this all work is the transclusive linking of
the nodes representing Alternative 1 and 2 in all these different contexts;
at a glance (or right-click) the user can see all the different dimensions
of the problem and how the alternatives play into those dimensions. (02)
This is easier to see in practice than in the above explanation, of course. (03)
Al (04)
Johannes Ernst <jernst@r-objects.com>@bootstrap.org on 01/28/2002 01:00:57
AM (05)
Please respond to ba-ohs-talk@bootstrap.org (06)
Sent by: owner-ba-ohs-talk@bootstrap.org (07)
To: ba-ohs-talk@bootstrap.org
cc: (08)
Subject: [ba-ohs-talk] IBIS question (09)
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. (010)
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. (011)
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 (012)
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. (013)
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. (014)
So my question: is anyone aware of any work that extends base IBIS to
help with this scenario? (015)
I appreciate it. Cheers, (016)
Johannes Ernst
R-Objects Inc. (017)