Apian logo
Home | SurveyPro | SurveyHost | QuestionWeb | DecisionPad | Purchase/Pricing | Blog |

Making Surveys, Making Decisions

The Apian Blog

General Apian Category

An Effective Decision Communication Tool

One of our early discoveries with DecisionPad was its importance as a decision communication tool.  The design has always emphasized accessibility, transparency and clarity.  Hence the easily understandable tradeoff matrix format with lots of graphical support.  Since changes in one place update everywhere immediately, the system lends itself to “what-if” exploration.

Some decision tools behave as “black boxes”; you put in your ratings and data and get an answer back just like magic.  These are useful for marketing tools like website “product model suggestions” or “better health tips” but they are not effective for serious decisions.  People will not trust an analytical method where the process is hidden and mysterious.

Watching people use DecisionPad, we found that one of the first things they do in examining a model is make a few small changes to see if the results go the direction they expect.  They are able to validate the system by direct interaction.  Since they can see all the ratings, weights and scores, and since changes take effect instantly, this is a fast credibility builder.  It is essential for acceptance by people who did not construct the model.

All of the entries in the DecisionPad matrix are in plain language, no cryptic coding required:  specs are numbers or features, prices are dollars, subjective ratings are agreement or excellence.  That makes it easy for everyone to understand the evaluation and check for areas of controversy.

However that means the matrix is full of apples and oranges!  How to analyze it?  By assigning a “utility” or “usefulness” value to each of the entries using a conversion scale you specify.  Utility numbers can be in whatever range the audience is comfortable with:  -3 to +3, 1 to 10 or 0 to 1000.  The scale is a reusable rule to say what utility number is assigned to “excellent” or “$550”.  These scaling rules are easy to set up and many common ones are preloaded.  They are easily reviewed or graphed – they are as transparent as the matrix itself.

A major aid to clarity in utility analysis is separating the relative importance of criteria (weights) from the utility values across the cells.  Unaided decision discussions can get bogged down when these two issues get muddled together verbally.  DecisionPad shows a column of weights next to the criteria and provides a graphical way to set and review which is easy to relate to.  People can sort the criteria by weight.  Agreement on the order of criteria importance is often the first step to forming a solid recommendation.

Graphs are available for a variety of decision elements, which helps speed understanding.  One of the most useful ones has been matrix views with small graphs in the cells, implemented in the first DecisionPad.  These have grown more elegant as computer displays have improved.   These little graphs are now called “sparklines”, a term coined by Edward Tufte who has written extensively on various interesting uses.  They pack a lot of understanding into a small space.

Notes can be attached to any item as backup and definition.  These become a part of the package and are used to document the thinking.

The net result is that DecisionPad is very approachable.  No scary technology visible, in fact it feels natural and intuitive.  It requires sophisticated technology inside to make that happen of course, but it does not need to be in your face about it.  This makes it useful for meetings, building consensus, creating buy-in to the final decision, and for re-justifying the decision when next year’s budget comes around: the matrix and reports will clearly show why the decision was made in a way everyone can understand.

Hard Times Demand Smart Decisions Implemented Quickly – Part II

In this article, Bill Ray, Apian President, discusses the decision-making environment that influenced his development of the DecisionPad software, how his experiences informed that development, and the sort of problems DecisionPad was originally created to address. Read Part I.

I had only been working a few months with that troubled mid-sized company (previous posting) when it was acquired by a Fortune 100 company.  The acquiring company had a diversified offering but most of its profits came from one highly technical flagship product that was very tricky to produce.  Because of the downside risk of a mistake with that cash cow, the corporate culture was highly cautious and analytical.  To fill a strategic product hole this cautious corporate culture bought a Silicon Valley Wild West company in big trouble.  Fortunately they had deep pockets so the high bleeding rate was affordable though hardly acceptable.

One big decision they had to face was plant closures.  There was too much capacity in the acquired company already plus the buyer was bringing new capacity of its own online.  Plants were spread around the world, each with its own strengths and weaknesses.

Being analyticals our senior management meetings on the closure decision began with a large Lotus spreadsheet of financial analysis such as manufacturing costs, transportation costs, boarder-crossing costs, etc.  Over the year that I watched it the spreadsheet got bigger in a endless series of meetings that always seemed to start over at the beginning.  The spreadsheet was so big that the analyst was a beta user for the new Intel plug-in board products to add RAM to the PCs.

Each meeting would begin with the analyst explaining the spreadsheet, but would soon get off course with questions like “what is your assumption behind that costing”, “what about the quality problems at that plant”, “how about the stability of government policies in that country”, “how do we link development engineering efforts half a world away”, etc.  (Remember this was when a FAX machine was state-of-the-art in business communications.)

In other words the tough critical issues in the decision were soft ones, the assumptions, which were not easily turned into financial numbers that could be directly compared to manufacturing costs.  Even when the long-term result will be measured financially, converting all the a priori issues into finance numbers is difficult at best.  People were able to discuss these issues more clearly in subjective terms.

As soon as the discussion moved away from the spreadsheet we lost the superficially objective numerical framework and moved into the purely unstructured verbal.  We needed a framework that could handle the apples and oranges of the real decision criteria.

DecisionPad was motivated by the need to handle a mix of hard and soft information in a way that is satisfying to a wide range of decision participants.  There are fancier analytical methods that are theoretically better but are not useful in practice because they cannot be coupled to real people.  More on how DecisionPad deals with these issues in future articles.

The net result is clear: a framework like DecisionPad can help people converge as information accumulates in the matrix and notes.  Instead of each meeting backing up over old ground,  then scheduling the next meeting, each meeting builds on the last to move forward.

Hard Times Demand Smart Decisions Implemented Quickly – Part I

In this article, Bill Ray, Apian President, discusses the decision-making environment that influenced his development of the DecisionPad software, how his experiences informed that development, and the sort of problems DecisionPad was originally created to address. Read Part II.

I joined Hewlett-Packard in 1969 just after my MBA.  In those days H-P hired us from school with limited experience, virtually all with engineering degrees, and we were promoted from within.  We went through the same management training classes including Kepner-Tregoe which promoted a particular philosophy of effective decision making.  That made H-P what the business schools call a “strong-culture organization”.  People approached business decisions in much the same way horizontally and vertically within the organization.

In 1985 I became VP engineering at a mid-sized Silicon Valley company that had pioneered and grown rapidly in the computer accessory business.  Like most high-growth firms they hired people from where ever they could be found and spread them out in numerous buildings where ever they could rent space.  All this growth – which industry analysts projected to keep right on going — attracted competitors at about the time a sudden technology shift cut the market growth to near zero.  That left everyone in the business with too much capacity and too many people, with prices falling to manufacturing cost or even dumped below true cost.

When the crisis came we needed smart decisions made quickly and implemented effectively.  The cash bleed rate was impressive.

Unfortunately the fast buildup meant some managers expected to reach decisions bottom-up and others top-down.  Worse yet, within that polarization people disagreed on how to analyze or talk about a decision.

The bottom-up managers would try to collect good information and have meetings to decide, but these meetings got bogged down for lack of a consensus on process.  The top-down managers would become frustrated and make arbitrary decisions that soon fell apart because all the relevant information and tradeoffs had not been properly taken into account.  And of course, because the organization was fragmented geographically, both kinds of managers were often mixed into the same decision as shrinking departments were consolidated.

If a decision did get made, often it was too little too late – one traumatic layoff was not deep or fast enough so it would be followed shortly by another.  And another.

Equally often the decision might fall apart in implementation for two reasons:  (1) it overlooked something important and thus did not work, or (2) it could not be communicated quickly and accurately in detail by the decision makers so it would be misunderstood or even sabotaged.  For example, measured by the overall business needs the wrong people might be laid off.

This would have been a perfect place for DecisionPad to provide structure, but DecisionPad was still two years in the future.  However these experiences set many of its design parameters:  to be accessible to a wide range of people without being trivialized, and to be “open” so it would be an effective communication tool during and after the decision.  I wanted to use the power of the emerging personal computers to package up a proven successful decision process in a way that non-specialists could use effectively.

“Fan Apian Software” on Facebook!

Are you curious about what our mascot “Esmerelda” looks like (here’s a clue, she’s related to “Audrey”).

Maybe you want to keep up to date with new releases and promotions? Join our page on Facebook and we’ll let you know when there is any news or when we post fun stuff.

“Become a fan” is all you need to do on this page:


Of course, you’ll need to join Facebook first if you haven’t already.

Welcome to the Apian Software Blog!

All about what’s new, fresh, and very occasionally, funny. We’ll be telling you about:

New Releases

  • Tips for using our software
  • Custom programming tricks
  • Upcoming events, training classes
  • Helpful information about surveys and decisions.

Let us know what you think, what you’d like to see more of! We’ve got a lot of product information to share, and are delighted to have this new medium.