<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" xmlns:georss="http://www.georss.org/georss" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0"><id>tag:blogger.com,1999:blog-2214230078779276579</id><updated>2009-03-30T07:03:08.536-07:00</updated><title type="text">Making Robust Decisions</title><subtitle type="html">Make the best decisions in spite of uncertainty and risk. Work in collaboration with a group. Learn about tools and techniques for making robust decisions.</subtitle><link rel="alternate" type="text/html" href="http://www.robustdecisions.com/making-robust-decisions/index.php" /><link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="http://www.robustdecisions.com/making-robust-decisions/atom.xml" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><generator version="7.00" uri="http://www.blogger.com">Blogger</generator><openSearch:totalResults>22</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><link rel="self" href="http://feeds.feedburner.com/making-robust-decisions" type="application/atom+xml" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com" /><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-4378742943577612980</id><published>2009-02-23T08:41:00.000-08:00</published><updated>2009-02-23T08:48:16.313-08:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="decision managment" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making maturity" /><category scheme="http://www.blogger.com/atom/ns#" term="new economy" /><title type="text">Decision-Management for the New Economy</title><content type="html">&lt;p&gt;The new economy forces new practices in making critical business decisions. Cost overruns, late to market, and rescoping all lead to inefficiencies that can no longer be tolerated. One approach to improve performance in these areas is to ensure that your decision-making processes lead to the best choices in an efficient manner every time.&lt;br /&gt;&lt;/p&gt;&lt;p&gt;Symptoms of poor decision practice are:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Decisions take too long – some are discussed, shelved, discussed again a year later, with no resolution&lt;/li&gt;&lt;li&gt;Meetings end with no clear direction forward – decisions aren’t made and actions not taken&lt;/li&gt;&lt;li&gt;Firefighting dominates useful work – with some fires clearly caused by poor earlier decisions &lt;/li&gt;&lt;li&gt;Projects championed by the strong dominate what is best for the organization &lt;/li&gt;&lt;li&gt;Decisions come unstuck – you decide what to do next, everyone agrees, and then something different happens &lt;/li&gt;&lt;li&gt;Decisions are made without using all of available information and you know it &lt;/li&gt;&lt;li&gt;Risk is ignored or padded over – all decisions are based on uncertain information and thus are risky.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;br /&gt;It is estimated that half of all decisions fail. By “fail” I mean that some time after the “decision” was made, there is no evidence that any effort went into making it, i.e. nothing changed. The only evidence that any effort was put into the decision was the expenditure of time and money. A decision is a call to action and if no useful action occurs, the time and effort that went into making it was wasted, or worse.&lt;br /&gt;&lt;/p&gt;&lt;p&gt;The risk of making a poor decision, one that isn’t actionable and doesn’t stick, can be reduced through decision-management. Decision management is a process whose goal is to use the available uncertain, incomplete, conflicting, and evolving information to make the best possible choices with known expected risks, within time and resources available. Some of the basics of decision management are:&lt;br /&gt;&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Decision-management begins with assuring that everyone is addressing the same issue. This isn’t a given. I have been in many meetings where everyone thought they were addressing the same topic, but weren’t. Even if generally on topic, everyone is making different assumptions and these must be made explicit. In watching the debates on bailouts and stimulus packages in early February 2009, it was clear that the issue is not well understood or agreed to. &lt;/li&gt;&lt;li&gt;To make a decision, there must be more than one alternative. If there is only one alternative and rejecting it is not an option, then the effort is for justification, not decision making. Decision-management helps develop alternative courses of action. The Wall Street bailout program of late 2008 seems to be an instance of rubber stamping a single alternative. &lt;/li&gt;&lt;li&gt;A major component of decision-management is developing a clear picture of how you will know if you have a good decision - what should be measured – what is important and to whom is it important. Determining stakeholders’ values before diving in too deep is critical if you want a result that everyone can buy into. The lack of clarity with the stimulus packages being debated in Washington seems to hinge on a clear picture of what is to be measured (e.g. jobs created, home foreclosures saved, etc.). Good decision-management helps to develop measures, and at the same time, honors differences of opinion about which measures are important. This might be helpful in Washington. &lt;/li&gt;&lt;li&gt;All decisions are based on estimates that are uncertain and yet we do a very poor job of taking this uncertainty into account. Past performance may be known (if it was documented), the present is obscured by its immediacy, and the future is just the best guess. In other words, very little is known with certainty. Adding uncertainty at the end of a decision making process with a “what-if” discussion is too late. Decision-management helps identify and capture the information uncertainty at the beginning of the process in an effort to produce a robust decision, one that is as immune as possible to the uncertainty. &lt;/li&gt;&lt;li&gt;A key part of decision management is a process to fuse together all of the information is a timely and useful manner. Sometimes, there is need for a fast decision and sometimes, if the stakes are high and time is available, more effort needs to be placed on issue, alternative, measure, and estimate development. Good decision-management controls the time spent versus the depth of analysis to reach a decision. &lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;br /&gt;In the 1990s most organizations began to review their processes to make them more efficient, agile and manageable. Making processes more efficient is mandatory in the new economy. However, many find that as they refine their processes, inefficiencies occur with poor decisions. In other words, efficient processes need efficient decision-management. Good decision-management is possible in most organizations and can alleviate many of the symptoms itemized at the beginning of this article. &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-4378742943577612980?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/CmhAjt1l-Ms" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/4378742943577612980/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=4378742943577612980" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/4378742943577612980" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/4378742943577612980" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/CmhAjt1l-Ms/decision-management-for-new-economy.php" title="Decision-Management for the New Economy" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2009/02/decision-management-for-new-economy.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-439846078382224755</id><published>2008-12-10T05:41:00.000-08:00</published><updated>2008-12-10T05:45:23.405-08:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making maturity" /><category scheme="http://www.blogger.com/atom/ns#" term="team decision making" /><title type="text">Decision-making maturity</title><content type="html">&lt;p&gt;I just spent a day judging a contest of pre-teens making design decisions.  I learned a lot about decision-making.  My day was in support of the US First Lego League (FLL) local competition.  The theme this year’s event was “Climate Connections Challenge”.  As part of the event the 10 -14 year-old students built robots out of Legos to compete in a simulated world.  They also had to make a presentation on climate change and their community.  Finally, they prove they could work as a team. &lt;br /&gt;&lt;br /&gt;This year I was the chief Teamwork judge.  To show teamwork each team (between 4 and 8 students) was given a simple task and 5 minutes to solve it.  On entering the room, I welcomed them and had them gather around a table.  I then put on the table a thin plywood disk and a small bag of large sized paper clips.  I read them directions which were something like: “You are to build a structure that will hold the disk off the table.  You can bend the paper clips in any form you like.  The paper clips must be connected in some way.  You can not use the plastic bag.  You can not harm the plywood disk.  You have 5 minutes.  Go!”&lt;br /&gt;&lt;br /&gt;Two other judges and I then observed them solving the problem.  We were not interested in the solution, but in the team-work displayed during the solution.  We had rubrics to guide our assessment and had time to ask questions at the end.&lt;br /&gt;&lt;br /&gt;It dawned on me part way through the day that I had 21 samples of conceptual design decision-making by pre-teens to observe.  This became clear to me too late to allow me to take formal data, but I did make the following anecdotal observations.  In each, I juxtapose them to what I have observed in adult decision makers.&lt;/p&gt;&lt;ul&gt;&lt;li&gt;As soon as I stopped reading, the kids grabbed the clips and started bending and talking at the same time.  One team was so eager I feared for my safety as I jumped out of the way (slight exaggeration).  There was no planning or reflection by any of the teams!  I did an experiment in the late 1980s where I gave 6 professional engineers a design problem and five hours to work it.  I video taped the sessions.  Most of these mature engineers read the requirement over several times before beginning to generate ideas. One subject however dove right in like these pre-teens.  He pursued his first and only idea and proceeded to patch on it (see next item), never leading to a reasonable solution of the problem.  My conclusion from these experiences is that it takes maturity to do the up front work necessary to make decisions.&lt;/li&gt;&lt;li&gt;Once the kids jumped in, they patched their way to a solution.  Patching means to try different ideas until you stumble onto a solution (I discuss this further in The Mechanical Design Process).  What is bad about patching is that it is usually random with no structured method to explore the design space.  I saw the same with the engineer described above and other immature designers.&lt;/li&gt;&lt;li&gt;When they asked clarification questions we only responded with “Read the problem description”.  Few did (less than 1/3).  They took our response to mean “No”. to whatever was asked.  I was surprised at this and after the first few times, I made a big deal of laying down the problem description (in big font on green paper) in the same location as the wooden disk and paper clips.  Only one team (out of 21) reread the description together to clarify their issue after we prompted them.  My generalization of this is that, for the most part people don’t use all the information available to them. &lt;/li&gt;&lt;li&gt;On the whole most of the teams did a good job of including most of the members on their team.  This is a credit to FLL and the mentors who worked with the teams.  I have had many college level teams that were not as inclusive.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;By the way, there were three classes of solutions, 1) bend the clips so they sat on the table and the disk was supported by upward extending wire legs (most did this with great patching), 2) bend the clips so that they fastened onto the disk with downward extending legs (only saw this done once successfully), and 3) lay two clips flat on the table and set the disk on top.  The last was the most elegant and simple. One team discovered this 40 sec into the five minutes.  To see more teamwork, I quickly said “Great, now make the support as tall as possible” (whew!).  Most teams never found this solution, but with their dive right in approach and random patching, I am not surprised.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-439846078382224755?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/x1BE2OTsC4E" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/439846078382224755/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=439846078382224755" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/439846078382224755" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/439846078382224755" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/x1BE2OTsC4E/decision-making-maturity.php" title="Decision-making maturity" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/12/decision-making-maturity.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-7915948162810402267</id><published>2008-11-24T07:15:00.000-08:00</published><updated>2008-11-24T07:23:21.678-08:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision thinking" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><title type="text">Decision Thinking – its time is coming</title><content type="html">I was trained as a mechanical engineer.  I know how to model systems, take data and develop an understanding for physical things.  Most (nearly all) technical university courses are about how to analyze things.  In my case these were physical things, but my education could have been in any engineering discipline, in business or in the sciences, and the courses still would have been primarily “thing” focused. &lt;br /&gt;&lt;br /&gt;In the 1980s I was teaching mechanical engineering design at a university and began to appreciate that things come into being through a process.  My thinking moved from being thing focused to being process focused.  Process thinking was not new to some fields.  In fact, in engineering there are control processes, chemical processes, fluid thermal processes etc.  But these are nothing but “process” things.  What I became interested in was the process of developing these things.&lt;br /&gt;&lt;br /&gt;In 1990 I began work on a text book for mechanical engineers so that they could study the process of how things mature from need to a final, working object.  I agonized over the title as the term “process” was not really a part of the engineering lexicon except for process things.  I finally chose the title “&lt;em&gt;The Mechanical Design Process&lt;/em&gt;” and the book was published in 1992. This title turned out to be a good choice and the 4th edition of the book is out in January 2009. &lt;br /&gt;&lt;br /&gt;When I began to research the design process in about 1984, my goal was to understand how objects evolve with eye toward developing methods and tools to better support this evolution.  I don’t mean CAD and solid modeling tools as these are representation tools for what is being designed, not tools that actually support the design process.  In fact, I have argued in a paper I wrote in 1990 that CAD can be detrimental to the design process ( Ullman and Wood, 1990).  Since writing this paper, CAD has evolved into solid modeling which is much better, but the arguments in the paper still hold.&lt;br /&gt;&lt;br /&gt;Anyway, I was especially interested in developing a tool that could record the evolution and rationale for product evolution.  This design rationale system would be able to capture how a product came into being and could be reused, queried and vetted to form a permanent record of its birth, life and death.  When I began, I focused on the evolution of the assemblies, parts, and features.  I quickly realized that this wouldn’t work because these things evolve during the design process and thus, focusing on them missed all the birthing – all the interesting, creative engineering.&lt;br /&gt;&lt;br /&gt;My thinking turned to capturing the process through which things evolved.  Process thinking encapsulates thing thinking as the process is about the evolving things.   This shift in my thinking coincided with the text book mentioned above.  However, it became evident by the mid 90s that process thinking, although much better than thing thinking, was not the best way to develop a design rationale system.  What became evident was that decisions are the punctuation marks in the process and that my approach had to make yet another shift, one to decision thinking.&lt;br /&gt;&lt;br /&gt;Thus, by the late 1990s my thinking had matured from thing, to process, to the decisions made during the process to develop things.  Specifically, I wanted to understand and support the decision-making process.  My research showed that on macro level, decisions were made at gates (in a stage-gate process) a countably few times during the evolution of a product.  On the micro level – the cognitive level - they occur about 1 decision per minute (see  Stauffer,and Ullman 1991).  Somewhere between these extremes there is much need for decision making support.&lt;br /&gt;&lt;br /&gt;Before we go on, a definition of decision thinking - decision thinking is focusing on the decision-making process used during technical or business development.  “Focusing” implies understanding and supporting individual decision makers and teams of people making decisions when information is incomplete, evolving and conflicting so that the decisions are robust. &lt;br /&gt;&lt;br /&gt;I am not alone in this evolution in thinking.   First, when I chose the tile “&lt;em&gt;The Mechanical Design Process&lt;/em&gt;”, the word “process” was problematic as it was not commonly used in industry.  Now, the product development industry makes good use of process thinking.  Then, when I started talking about decision thinking in the late 1990s few in industry knew what I was talking about.  Now there is much evidence that companies and the government are beginning to realize the importance of decision-making in their processes.  My evidence for this is not firm, but many of my contacts seem to understand what I am talking about and few did five years ago, and the number of hits on the Robust Decisions web site continues to climb.  Their thinking is maturing through the process to the decisions made during the process.&lt;br /&gt;&lt;br /&gt;Second, the CAD industry matured into PLM (Product Lifecycle Management) during the 1990s.  Where CAD and solid modeling is about things, PLM is about processes that manage things and document things.   I have tried to interest the PLM vendors in decision thinking for about eight years.  Initially they told me there was no customer pull (see the previous paragraph).  Recently, I have gotten their attention.  Now that they have the process under control, they too are maturing toward decision thinking.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family:times new roman;"&gt;Ullman, D.G., S. Wood, D. Craig, "The Importance of Drawing in the Mechanical Design Process," Computers and Graphics, Special Issue on Features and Geometric Reasoning, Vol. 14, No. 2, 1990, pp. 263-274.&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family:times new roman;"&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family:times new roman;"&gt;Stauffer, L.A., D.G. Ullman, "Fundamental Processes of Mechanical Designers Based on Empirical Data," Journal of Engineering Design, Vol. 2, No. 2, 1991, pp. 113-126.&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-7915948162810402267?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/WDGdy4-yBpI" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/7915948162810402267/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=7915948162810402267" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7915948162810402267" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7915948162810402267" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/WDGdy4-yBpI/decision-thinking-its-time-is-coming.php" title="Decision Thinking – its time is coming" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/11/decision-thinking-its-time-is-coming.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-5825562077443016824</id><published>2008-10-08T09:40:00.000-07:00</published><updated>2008-10-08T09:45:44.723-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="risk management" /><category scheme="http://www.blogger.com/atom/ns#" term="decision risk" /><title type="text">Risk Management as a decision issue</title><content type="html">&lt;p&gt;The term “risk management” has been around for a long time in financial, technical and medical practice.  It is a term that is very loosely used and I want to dive in with a decision-centric view just to further muddy the waters.&lt;br /&gt;&lt;br /&gt;A good place to begin is with a formal definition of “risk”.  If you enter “risk definition” into Google you will get over twenty-five definitions; some are redundant, and there is little consistency.  Regardless of the definition, risk traditionally amounts to answering three questions:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;What can go wrong? Some event.&lt;/li&gt;&lt;li&gt;How likely is it to happen? Probability that the event happens based past statistics, an analytical model of the event, or best guess based on experience.&lt;/li&gt;&lt;li&gt;What are the consequences? Money, time, and possibly even lives are wasted.&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;br /&gt;The above set of questions describes event risk.  They are the basis of technical risk evaluation.  However, most managers are concerned with decision risk rather than event risk.  For decision risk, the questions managers really want answered are:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;What can go wrong if I choose alternative X?&lt;/li&gt;&lt;li&gt;How likely is it?&lt;/li&gt;&lt;li&gt;What is the impact?&lt;br /&gt; &lt;/li&gt;&lt;/ol&gt;&lt;p&gt;(Brian Seitz of Microsoft articulated these as cleanly as shown here)&lt;br /&gt;&lt;br /&gt;Note that these are the same three questions as with event risk, just slightly tweaked.  Regardless of whether focused on an event or a decision, risk management, by definition needs to be effort directed at some or all of these questions.&lt;br /&gt;&lt;br /&gt;The first question raises the issue of how we know our choice was poor. In the book Why Decisions Fail, the definition of a poor decision is one that had no positive impact after two years. There are other measures of a failed decision. For example, our time is up and no satisfactory alternative has been developed. Or not everyone on the team agrees with the choice made and some team members feel disenfranchised. More often, the result of a poor choice is not known until much later. For example, if we choose a bad restaurant, we will not know until we have eaten there. Or if an engineer makes a poor decision on what material to use for a product, this may not be evident until the customers have used the product for a number of years.&lt;br /&gt;&lt;br /&gt;One thing is consistent in this discussion: Without uncertainty there is no risk.  A corollary is that the more uncertainty, the higher the risk of making a poor decision. “What can go wrong?” is that one or more of the criteria are not satisfied.   “How likely is it?” is directly dependent on our certainty during the alternative evaluation.  We may know from past experience or data that the probability of something failing is XX%.  But, this probability may be compounded by other uncertainties such as lack of knowledge, disagreement amongst team members or incomplete data. And “What is the impact?” is that the alternative chosen no longer is as good as it was originally thought.    &lt;/p&gt;&lt;p&gt;In order to manage risk during decision making: &lt;/p&gt;&lt;ul&gt;&lt;li&gt;You must address risk during decision making, not as a task to complete after you have selected an alternative. This is because decision risk is a measure of your lack of knowledge, as well as other uncertainties you need to consider when you make a decision. &lt;/li&gt;&lt;li&gt;There is risk associated with every feature of every alternative. Traditional risk assessment separately addresses financial risk, performance risk, and schedule risk. But when including risk as a part of the decision-making process, you must integrate the uncertainty inherent in all the features at once, because it is the combination of them that drives your decision. &lt;/li&gt;&lt;li&gt;You can get a good assessment of uncertainty, and thus risk, by fusing the evaluations of all the members of your team. &lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-5825562077443016824?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/j1BBjLA5a-4" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/5825562077443016824/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=5825562077443016824" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/5825562077443016824" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/5825562077443016824" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/j1BBjLA5a-4/risk-management-as-decision-issue.php" title="Risk Management as a decision issue" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/10/risk-management-as-decision-issue.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1664515718668415663</id><published>2008-09-19T08:26:00.000-07:00</published><updated>2008-09-19T08:42:16.481-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="criteria" /><category scheme="http://www.blogger.com/atom/ns#" term="Ralph Keeny" /><category scheme="http://www.blogger.com/atom/ns#" term="criteria development" /><title type="text">More on Criteria Development</title><content type="html">&lt;p&gt;In my blog of Sept 10, I noted that my newsletter statements in "&lt;a href="http://www.robustdecisions.com/decision-expert-newsletter/newsletter0306.php"&gt;Robust Criteria for Robust Decisions&lt;/a&gt;" had started an interesting conversation with Ralph Keeney. In the newsletter I had stated: &lt;/p&gt;&lt;p&gt;&lt;em&gt;Research has shown:&lt;br /&gt;1. The more effort put into understanding the criteria early in the process, the better the decision&lt;br /&gt;2. Too little effort is generally put into understanding criteria. &lt;/em&gt;&lt;/p&gt;&lt;p&gt;He asked for references, and I provided, in my blog what weak evidence I had. He in turn sent me an interesting paper titled “Generating Objectives: Can Decision Makers Articulate What They Want?” (Management Science Vol 54 No 1, Jan 2008, pp 56-70). In this paper, Keeney and his colleagues present the results of a series of experiments designed to address how well people can list the objectives (i.e. criteria) they used in making decisions on real problems. In summary, Keeney and company concluded that people commonly undertake important decisions without considering many of the most important criteria. It seems that they generate only the objectives that are cued by their incomplete representation of the problem. In other words, as people work to understand a problem, by reading a problem statement, talking with others, hearing a news cast, etc, they build a mental model of the situation and base their criteria on this model.&lt;br /&gt;&lt;br /&gt;The implications of this are:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Decision making is guided by whatever incomplete set of objectives is made salient&lt;/li&gt;&lt;li&gt;Criteria generation can be improved by helping decision makers develop a broader understanding of the problem through:&lt;/li&gt;&lt;ul&gt;&lt;li&gt;Time - One of the studies in the paper showed that addressing the problem at multiple points in time increases the number of criteria identified.&lt;/li&gt;&lt;li&gt;Multiple perspectives - Although not in the study, multiple perspectives (i.e. a team approach) can help develop the broader understanding&lt;/li&gt;&lt;li&gt;Templates - External aids can help in generating the broader understanding.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/ul&gt;&lt;p&gt;What follows are some thoughts on these three criteria development crutches&lt;br /&gt;&lt;br /&gt;Time&lt;br /&gt;My research in the 1980s focused on how engineers design products. In these studies my students and I video taped engineers solving simple but realistic design problems. We observed how engineers repeatedly returned to the problem statement as their mental model of the situation evolved. Before these experiments I tried to force students in my design classes to develop criteria first and then alternatives. The rationale was that, if you have a solution (or a set of solutions) in mind, then the criteria will evolve to match them. More recently, I have come to believe that criteria and alternatives co-evolve as the understanding is developed. That is not to say that you should just dive in. I now teach Quality Function Deployment (QFD) first but treat it as a living document. Also I have the students work in teams on all projects as that brings multiple perspectives.&lt;br /&gt;&lt;br /&gt;Perspectives&lt;br /&gt;One criticism of virtually all the research on decision making (including my own) is that it has been on individual decision makers. I comment on this in an &lt;a href="http://www.robustdecisions.com/making-robust-decisions/2008/08/psycholgy-research-misses-reasons-for.php"&gt;earlier blog&lt;/a&gt;. The reality is that at work and to a great degree at home, we all solve problems with others. Either we bounce ideas off of each other or are on teams. In these situations the multiple perspectives help flesh out understanding and criteria. Large teams can actually reverse the situation. In many of my consulting jobs I see teams from multiple groups in an organization working to winnow down the criteria that are important for each individual group into a single, shared understanding. This is almost the antithesis of Keeney’s study.&lt;br /&gt;&lt;br /&gt;Templates&lt;br /&gt;The idea of using templates or other criteria crutches is one that we have tried to incorporate into &lt;a href="http://www.robustdecisions.com/decision-making-software/"&gt;Accord&lt;/a&gt;, our decision support software. Currently there are templates for about six different generic problems (e.g. Concept selection, Portfolio evaluation, Proposal selection, Vendor selection, Job candidate selection). However, many decisions in business are unique and developing a template for these problems is not possible. The paper that started this string “Robust Criteria for Robust Decisions” was an effort to address those problems that don’t allow for templates.&lt;br /&gt;&lt;br /&gt;The upshot of the dialog with Ralph Keeney is that I will be doing some experiments this fall that address the two points I made initially. We will see what evolves to help frame decision problems. &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1664515718668415663?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/7w-HzWrT59s" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1664515718668415663/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1664515718668415663" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1664515718668415663" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1664515718668415663" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/7w-HzWrT59s/more-on-criteria-development.php" title="More on Criteria Development" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/09/more-on-criteria-development.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-2368740812379461472</id><published>2008-09-10T13:18:00.000-07:00</published><updated>2008-09-15T10:12:22.915-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="criteria" /><category scheme="http://www.blogger.com/atom/ns#" term="Ralph Keeny" /><category scheme="http://www.blogger.com/atom/ns#" term="criteria development" /><title type="text">Robust Criteria for Robust Decisions</title><content type="html">I just wrote a newsletter that appear on my web site on how to develop criteria and titled "&lt;a href="http://www.robustdecisions.com/decision-expert-newsletter/newsletter0306.php"&gt;Robust Criteria for Robust Decisions&lt;/a&gt;" In it I state:&lt;br /&gt;&lt;br /&gt;Research has shown:&lt;br /&gt;&lt;br /&gt;&lt;ol&gt;&lt;li&gt;The more effort put into understanding the criteria early in the process, the better the decision &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Too little effort is generally put into understanding criteria. &lt;/li&gt;&lt;/ol&gt;After sending this to my mailing list, I received a message from Ralph Keeny (A major thinker in decision making for the last 20+ years) asking " I am very interested in both of these issues, and I believe that each are true. However, research addressing these issues is not so easy to come by. Hence, if it is not too inconvenient, I would be pleased to receive references  of the research referred to in the statements. Thank you very much."&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;This is what I wrote back.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Thanks for the note. I agree that data supporting these two contentions are hard to come by. By far the best I have seen is from a German PhD dissertation that used protocol studies of mechanical engineers similar to those I did in the late 1980s: &lt;em&gt;Thinking Methods and Procedures in Mechanical Design&lt;/em&gt;, Dissertation, Dylla, N., Technical University of Munich, 1991, in German. From Dylla’s data, I wrote the following and developed the plot (note this is from page 142 in Making Robust Decisions, some copies of which have the wrong plot for the figure)&lt;br /&gt;&lt;br /&gt;&lt;em&gt;The experimenters measured the amount of time each of the six engineers spent developing criteria. This included reading the given criteria, rereading them, and refining them. Then a team of professional engineers evaluated the technical quality of each design. Part of the evaluation concerned how well the final designs met the criteria, and part was more objective— evaluating the elegance of the solution. The evaluation team scored each of the six designs on a scale of 0 to 100. As figure 6.1 shows, there is a significant relationship between the percentage of time spent analyzing the goals of the problem and the technical quality of the result. The engineers who spent around 7% of their time understanding and developing criteria had a 60% better solution than those who spent 2–3% of their time developing criteria. I don’t mean to imply that 7% is an adequate time for working on the criteria; this particular experiment involved a simple, crafted problem and just one decision maker. The engineers didn’t spend all their criteria time at the beginning of the task. In fact, the successful engineers worked hard to refine the criteria at the beginning and then revisited and refined them many times during the course of the experiment. This result should come as no surprise: a prime measure of the success of a decision is how well the results meet the criteria. In general, the time you spend up front to clarify the problem (understand the criteria) saves time and many headaches later.&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;img style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://www.robustdecisions.com/making-robust-decisions/uploaded_images/6.1-733868.jpg" border="0" /&gt;&lt;br /&gt;&lt;br /&gt;Admittedly, I have taken some license that a better mechanical design is analogous to a better decision. I don’t think the leap is very great however as deign is repetitive decision making.&lt;br /&gt;&lt;br /&gt;The second point is based partailly on Dylla’s finding (4 of the 6 engineers might have done better had they put in more time on criteria) and partially on the studies done for the book &lt;em&gt;Why Decisions Fail&lt;/em&gt;, by Paul Nutt, Berrett-Koelher, 2004. One of his three decision blunders is “Decision makers base many decisions on premature commitments.” Premature commitment implies that to little time is spent on one or all of the following 1) developing alternative courses of action, 2) developing criteria, 3) evaluating alternatives relative to criteria or 4) managing the decision making strategy. He never breaks this down, but on page 167 he compares the success of four different evaluation tactics: analytical, bargaining, subjective and judgment. Paraphrasing Nutt: In an analytical evaluation, data is gathered and inferences made from analytical tools. In judgment there are no specifics. Thus, analytical methods require more effort on the measures, i.e. the criteria than does judgment. He found a decision adoption rate of 64-75% when analytical methods were used versus 36% -47% for judgment. Unfortunately, Nutt never really addresses the evaluation details and wraps criteria development in with evaluation as many authors do.&lt;br /&gt;&lt;br /&gt;All pretty weak stuff. To add useless anecdotal “data”, I see companies do a very poor job of defining criteria for making decisions. One let an RVP with 60+ specs. After reading the 15+ proposals these specs enabled them to separate them into two piles, acceptable and not acceptable. The specs were not really what they needed to make the decision amongst the “acceptable” proposals. They then needed to spend additional time determining what their criteria were for finding the best amongst the acceptable.&lt;br /&gt;&lt;br /&gt;Do you have any references that might add to this?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-2368740812379461472?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/twR1UGIHMaI" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/2368740812379461472/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=2368740812379461472" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/2368740812379461472" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/2368740812379461472" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/twR1UGIHMaI/robust-criteria-for-robust-decisions.php" title="Robust Criteria for Robust Decisions" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/09/robust-criteria-for-robust-decisions.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-8162425876381274377</id><published>2008-09-04T08:20:00.000-07:00</published><updated>2008-09-11T18:09:30.201-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="Saaty" /><category scheme="http://www.blogger.com/atom/ns#" term="Pairwise comparison" /><category scheme="http://www.blogger.com/atom/ns#" term="pair-wise comparison" /><category scheme="http://www.blogger.com/atom/ns#" term="criteria importance" /><category scheme="http://www.blogger.com/atom/ns#" term="criterion importance" /><title type="text">Why pairwise comparisons are a waste of time for finding criteria importance</title><content type="html">Many people use pairwise comparisons during their decision making efforts. First, this method may be used to determine the relative importance (the weightings) of the criteria. Second, pairwise comparisons are sometimes used to evaluate the alternatives relative to the criteria. BOTH OF THESE ARE A WASTE OF TIME!! Don’t get me wrong, I think pairwise comparisons can be helpful, just that there are faster ways of getting virtually the same results. In this brief note I will only tackle why you shouldn't bother for finding importance.&lt;br /&gt;&lt;br /&gt;Through his books and companies, Tom Saaty has popularized pairwise comparisons as a part of his Analytic Hierarchy&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftn1" name="_ftnref1"&gt;[1]&lt;/a&gt; (AHP) and Analytic Network&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftn2" name="_ftnref2"&gt;[2]&lt;/a&gt; Processes In the Analytic Network Process book, on pages 26- 31, Saaty gives the example of using eight criteria to help select a house (e.g. Size of House, Transportation, Neighborhood, etc). His method requires that all the criteria be compared to each other one pair at a time to find the most important for each comparison. Further, a dominance factor is given to the better of the pair relating how much more important one factor is to another. If working with a team, they need to come to agreement on the dominance factors (I will come back to this point later). For the 8 criteria, there are 28 comparisons and the need to judge 28 dominance factors. In general, for N factors there are (N-1) + (N-2) +…. 1 comparisons.&lt;br /&gt;&lt;br /&gt;For the example in his book (where the numbers represent the 8 criteria (i.e. factors)) a matrix of the pairwise comparisons is a shown below. Note that the opposite entries are just reciprocals of each other. Criterion 1 is 5 times as important as criterion 2 and so criterion 2 is 1/5 as important as criterion 1.&lt;br /&gt;&lt;br /&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center;" alt="matrix of the pairwise comparisons" src="http://www.robustdecisions.com/making-robust-decisions/uploaded_images/ahp-table-754994.bmp" width="379" height="133" /&gt;&lt;br /&gt;The Priority Vector is reduction of the values (using an eigenvector analysis) to develop the relative weightings - the importance of each criterion.&lt;br /&gt;&lt;br /&gt;Compare this to a method proposed by Ward Edwards, one of the fathers of modern decision theory. He suggested that asking decision makers to weigh criteria is so fraught with error that it is easier, and no less accurate, just to ask them to rank the criteria and then automatically set the weights according to the ranking&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftn3" name="_ftnref3"&gt;[3]&lt;/a&gt;. This “error” is exasperated when there are multiple constituencies represented in the organization.&lt;br /&gt;&lt;br /&gt;Find the rank order the criteria, write each criterion on a sticky note and arrange them on a wall or desk, and reorder with the most important on top. This is best done in a pairwise fashion by selecting the criteria two at a time and asking, “If an alternative could meet only one of these, which criteria would I choose?” Then, move the chosen one to the top and the other to the bottom of the arrangement.&lt;br /&gt;&lt;br /&gt;You can convert the ranking to a weighting by using the table below. This table shows the Rank Order Centroid (ROC) method developed by Edwards and shows the weights for up to 12 criteria.&lt;br /&gt;&lt;br /&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center;" alt="Rank Order Centroid table" src="http://www.robustdecisions.com/making-robust-decisions/uploaded_images/rank-table-797169.bmp" border="0" width="394" height="200" /&gt; &lt;br /&gt;Weights based on ROC method&lt;br /&gt;&lt;br /&gt;If you have more than 12 criteria, you can use the equation wk= (1/K) ∑ (1/ i ) as i goes from k (the number of the criterion, with 1 being the highest weighted and K being the lowest) to K (the number of criteria). This equation was used to generate the values in the table. The values for 8 criteria are shaded in the table above and plotted below compared to the pairwise method.&lt;br /&gt;&lt;br /&gt;The results of the two methods are shown on the bar chart below.&lt;br /&gt;&lt;br /&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center;" alt="decision method comparison graph" src="http://www.robustdecisions.com/making-robust-decisions/uploaded_images/plot-724538.jpg" border="0" /&gt; &lt;br /&gt;The Mean Absolute Error between the two (the sum of the absolute differences between the two) is, on average, 2%. Other examples I have tried have even had less error. Considering that there is no right answer and that one change in pairwise comparisons can change the results. The difference between the two comes at the expense of a major difference in the amount of effort. Twenty eight comparisons and assignments of priorities versus simply rank ordering the criteria.&lt;br /&gt;&lt;br /&gt;Now, adherents of pairwise comparisons can argue that the method also computes consistency, a measure of how well the many dominance factors agree with each other. I believe this is of little importance as the dominance factors are just averages across a committee of stakeholders who are trying to quantify subjective values. In other words, the uncertainty in the pairwise scoring is so high due to averaging and quantifying subjective values that consistency in the dominance factors is just noise. Consistency analysis gives false comfort that the matrix is consistent when the numbers themselves are very uncertain.&lt;br /&gt;&lt;br /&gt;Based on the above arguments, I believe pairwise comparisons are a waste of time. I prefer to allow all the stake holders to rank order and use the resulting inconsistent weighting factors in my analysis. Thus, I honor all party’s values and use them all in downstream analysis. More on this in another note.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftnref1" name="_ftn1"&gt;[1]&lt;/a&gt; Decision Making for leaders: The Analytic Hierarchy Process for Decisions in a complex World, Thomas L. Saaty,RSW Publications, Pittsburgh PA, 1999&lt;br /&gt;&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftnref2" name="_ftn2"&gt;[2]&lt;/a&gt; The Analytic Network Process, Thomas L. Saaty, RWS Publications, 1996.&lt;br /&gt;&lt;a href="http://www.blogger.com/post-create.g?blogID=2214230078779276579#_ftnref3" name="_ftn3"&gt;[3]&lt;/a&gt; Edwards, Ward and F. Hutton Barron, &amp;quot;SMARTS and SMARTER: Improved Simple Methods for Multi-attribute Utility Measurement&amp;quot; and F. Hutton Barron and Bruce Barrett, &amp;quot;Decision Quality Using Ranked and Partially Ranked Attribute Weights.&amp;quot;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-8162425876381274377?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/MHW-1efbb34" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/8162425876381274377/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=8162425876381274377" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/8162425876381274377" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/8162425876381274377" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/MHW-1efbb34/why-pairwise-comparisons-are-waste-of.php" title="Why pairwise comparisons are a waste of time for finding criteria importance" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/09/why-pairwise-comparisons-are-waste-of.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1701353692912634348</id><published>2008-09-01T05:57:00.000-07:00</published><updated>2008-09-01T06:07:08.886-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="wisdom of crowds" /><category scheme="http://www.blogger.com/atom/ns#" term="team knowledge" /><category scheme="http://www.blogger.com/atom/ns#" term="team decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="constulting" /><title type="text">Are two heads better than one?</title><content type="html">&lt;span style="font-family:arial;"&gt;I was listening to NPR the other day and heard the word “constult”.  This word is in Oxford English Dictionary (I checked).  It is a verb that means “To play the fool together.” Both examples in the OED are from the 17th century: &lt;br /&gt;&lt;br /&gt;&lt;/span&gt;&lt;span style="font-family:arial;"&gt;&lt;em&gt;&lt;blockquote&gt;&lt;span style="font-family:arial;"&gt;&lt;em&gt;1630 &lt;/em&gt;&lt;/span&gt;&lt;a href="http://dictionary.oed.com.proxy.library.oregonstate.edu/help/bib/oed2-t.html#j-taylor" target="oedbib"&gt;&lt;em&gt;&lt;span style="font-family:arial;"&gt;J. TAYLOR&lt;/span&gt;&lt;/em&gt;&lt;/a&gt;&lt;em&gt;&lt;span style="font-family:arial;"&gt; (Water P.) World's eighth Wonder Wks. II. 67/1 Some English Gentlemen with him consulted And he as nat'rally with them constulted. &lt;/span&gt;&lt;/em&gt;&lt;a name="50048207q2"&gt;&lt;/a&gt;&lt;em&gt;&lt;span style="font-family:arial;"&gt;1659 &lt;/span&gt;&lt;/em&gt;&lt;a href="http://dictionary.oed.com.proxy.library.oregonstate.edu/help/bib/oed2-g.html#gauden" target="oedbib"&gt;&lt;em&gt;&lt;span style="font-family:arial;"&gt;GAUDEN&lt;/span&gt;&lt;/em&gt;&lt;/a&gt;&lt;span style="font-family:arial;"&gt;&lt;em&gt; Slight Healers (1660) 91 What&lt;/em&gt; do they meet, and sit, and consult (or rather constult) together?&lt;br /&gt;&lt;/span&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;/em&gt;&lt;/span&gt;&lt;span style="font-family:arial;"&gt;&lt;br /&gt;So, this brings up the question (posed on the Car Talk web site); “&lt;strong&gt;Do&lt;/strong&gt; &lt;strong&gt;two people who don’t know what they are talking about know more or less than one?&lt;/strong&gt;”  This is worth asking since most hard decisions are plagued by a lack of knowledge.  In fact, this was this question (not so well articulated) that led me to start thinking about decision making in the mid 1990s. &lt;br /&gt;&lt;br /&gt;When I am designing a new product, I don’t know much about the new details of it.  Designing is learning.  Often I will enlist others to help on the functions and features I know the least about.  Are these colleagues consulting or constulting, and if the latter, why do I seek their help?&lt;br /&gt;&lt;br /&gt;I think I know the answer.  If I know absolutely nothing about something and my response is a wild guess, then the probability of my being right is 50%.  If another person is added to my team and they too know nothing then she is truly constulting, together we know nothing and the probability is still 50%.  However, if I know a little and what I know is correct, then my probability is greater than 50%.  And, if I add a colleague and she knows a little then the probability of us together being correct is greater still. &lt;br /&gt;&lt;br /&gt;As a numerical example (taken from “&lt;/span&gt;&lt;a href="http://www.robustdecisions.com/decision-making-resources/making-robust-decisions-book.php"&gt;&lt;span style="font-family:arial;"&gt;Making Robust Decisions&lt;/span&gt;&lt;/a&gt;&lt;span style="font-family:arial;"&gt;” page 231), say that I know enough that the probability that I am right is 68%.  If another person is added to the team and they independently also have a probability of being correct of 68%, then our fused probability is 82%.  If there are three of us, it raises to 91%.  The theory behind these numbers is in the book, but they do make intuitive sense.&lt;br /&gt;&lt;br /&gt;This also supports the examples in the book “&lt;/span&gt;&lt;a href="http://www.randomhouse.com/features/wisdomofcrowds/"&gt;&lt;span style="font-family:arial;"&gt;Wisdom of Crowds&lt;/span&gt;&lt;/a&gt;&lt;span style="font-family:arial;"&gt;” (a good read).  Obviously there are some limitations.  What if members of the team disagree on the answer?  What about Group Think?  What is the level of knowledge is less than estimated?  All of these can lead to constulting.&lt;br /&gt;&lt;br /&gt;So to answer the question:&lt;/span&gt;&lt;/p&gt;&lt;span style="font-family:arial;"&gt;&lt;ul&gt;&lt;li&gt;Two people who know nothing know as much as one person who knows nothing.&lt;/li&gt;&lt;li&gt;Two people who know a little independently (no group think or peer influence) and their meager knowledge is correct, know more than one person.  This is how we get to the wisdom of crowds.  If their knowledge is conflicting, they still know more, just that answer is still in doubt.&lt;/li&gt;&lt;li&gt;Two people who know a little and they have influenced each other through peer pressure (think alpha males), group think or other mechanism, or one or more of them knows less than they think they do; together they may actually know less and be constulting.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;The goals then are to know when you know nothing and how to avoid the pitfalls that lead to constulting.  I have been struggling with these goals for about ten years.&lt;/span&gt;&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1701353692912634348?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/2lp6ZlXH9oo" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1701353692912634348/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1701353692912634348" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1701353692912634348" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1701353692912634348" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/2lp6ZlXH9oo/are-two-heads-better-than-one.php" title="Are two heads better than one?" /><author><name>David G. Ullman</name><uri>http://www.blogger.com/profile/17313926425758954185</uri><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/09/are-two-heads-better-than-one.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-349389380545071715</id><published>2008-08-17T08:50:00.000-07:00</published><updated>2008-08-20T08:19:37.268-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="group decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="team decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="cognitive limitations in decision making" /><title type="text">Psychology Research Misses the Reasons for Decision Making Teams</title><content type="html">&lt;p&gt;I am reading “Straight Choices: The Psychology of Decision Making” by Benjamin Newell, David Lagnado and David Shanks (Psychology Press 2006). It is a very good summary of decision making from the viewpoint of cognitive psychology. It makes some muddy topics very clear. However, it totally fails in Chapter 14, Group Decision Making. This isn’t the authors’ fault – all work on team or group decision-making misses the main points. I will get to these in a moment.&lt;br /&gt;&lt;br /&gt;First, some background. I attempted to address this topic in Chapter 5 of “Making Robust Decisions”, cleverly titled “Teams Don’t Make Decisions, But…” The title reflects the problem with the topic. In business and technology there is always one person who signs off on a project to move it forward. This manager is the ultimate “decision maker”. But, if this person is good at what they do, for complex problems they have a team that is studying the problem and advising them about what choice to make. On this team, some of the people know about some of the information, they all have different fields of expertise and knowledge. For complex problems, no one person can know all about all of the important features of all the alternatives. Further, they bring a range of viewpoints about what is important.&lt;br /&gt;&lt;br /&gt;So, is the manager the decision maker or the team? Depends how you draw the line around the term “decision”. If it is an event, then the manager is the decision maker. If decision-making is a process, then it is the team. I see decision-making as a process.  The cognitive psychologists seem to see a decision as the event.&lt;br /&gt;&lt;br /&gt;In “Straight Choices”, the authors summarize research on group decision making. All of the studies they sight are for very simple problems, not for problems with distributed knowledge. In other words, the toy problems the psychologists have used to study teams do not reflect what happens in business and technology. They tend to focus on the "right" answer to simple problems with a known solution. This why Chapter 14 was such a let down.&lt;br /&gt;&lt;br /&gt;From my reading, the two main reasons to use a team are:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;Obtain the best information when no one person can know all that is needed to be known&lt;/li&gt;&lt;li&gt;Build stakeholder buy-in and accountability&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;These goals mean that you need to:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;Build an environment and a team strategy that fosters communication of the right information and buy-in&lt;/li&gt;&lt;li&gt;Suppress the effect of differences in cognitive styles (“suppress” is not the right word, but you want to level the playing field so the alphas don’t dominate, the closers don’t stop things too soon, the wafflers don’t lead to team paralysis and so forth.)&lt;/li&gt;&lt;li&gt;Guard against group think&lt;/li&gt;&lt;li&gt;Help build a shared understanding&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;br /&gt;Of the six topics itemized above, Chapter 14 only addresses Group Think. It comes close to talking about a shared understanding when it discusses consensus, but consensus is not important for a decision buy-in. (Quoting Margaret Thatcher, "To me, consensus seems to be the process of abandoning all beliefs, principles, values and policies. So it is something in which no one believes and to which no one objects."). The two main goals are never discussed. It seems the cognitive research has focused on getting the “right” answers to toy problems. Most real decisions have no right answer, so the psychologists are asking the wrong questions.&lt;/p&gt;&lt;p&gt;In the authors’ defense, they end the chapter with “Research on group decision making is both appealing and frustrating”. In spite of this frustration, decisions are made by teams every day and I believe the key to robust team decisions is in the six items listed above. These are discussed at length in Making Robust Decisions. I just wish there was more good research on each of them so you don’t have to take my word for it.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-349389380545071715?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/ELeDEpm4WYQ" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/349389380545071715/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=349389380545071715" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/349389380545071715" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/349389380545071715" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/ELeDEpm4WYQ/psycholgy-research-misses-reasons-for.php" title="Psychology Research Misses the Reasons for Decision Making Teams" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/08/psycholgy-research-misses-reasons-for.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-6585834182436830845</id><published>2008-08-08T05:59:00.000-07:00</published><updated>2008-08-08T06:35:14.496-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making maturity" /><title type="text">Decision making maturity</title><content type="html">I just returned from an &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_0"&gt;ASME&lt;/span&gt; (American Society of Mechanical Engineers) meeting in NYC. During my time there I discussed the concept of decision making maturity with three different groups and thought it worth writing about.  Best to do in context with my career.&lt;br /&gt;&lt;br /&gt;When I was trained as an engineer, I focused on how &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_1"&gt;components&lt;/span&gt; and assemblies were shaped, manufactured and functioned.  This element-centric view of the world is not at all unique to engineers. Businesses focus on documents, e.g. POs, recepts, memos, contracts, etc)&lt;br /&gt;&lt;br /&gt;By the 1980s I became &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_2"&gt;fascinated&lt;/span&gt; with the &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_3"&gt;process&lt;/span&gt; of developing the elements.  This process-centric view is &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_4"&gt;recent&lt;/span&gt;.  Sure engineers have studied and developed chemical and manufacturing processes for years, but the concept of product design processes and business processes is &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_5"&gt;recent&lt;/span&gt;.  As evidence of this, in 1990, I wrote an engineering text book about how to progress from customer need to produced product.  I debated long and hard about what to title it.  I finally landed on "The &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_6"&gt;Mechanical&lt;/span&gt; Design Process", a title that proved to be right on the mark (note that its 4&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_7"&gt;th&lt;/span&gt; edition will be out in January 2009).  The use of the word "process" in the title was problematic because it was only &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_8"&gt;beginning&lt;/span&gt; to be used to discuss product evolution.&lt;br /&gt;&lt;br /&gt;In the early 1990s my research was about how to capture and manage the evolution of products, the rationale for form and function.  This was process-centric, but not getting anywhere.  In about 1995, it dawned on me that "design is the evolution of information, punctuated by decisions".  That started me on a decision-centric view of the business and technical worlds.&lt;br /&gt;&lt;br /&gt;My maturity from element through process to decision is being taken by industry.  While in NYC I met with a &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_9"&gt;PLM&lt;/span&gt; (Product &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_10"&gt;Lifecycle&lt;/span&gt; Management) guru.  &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_11"&gt;PLM&lt;/span&gt; grew out of CAD (Computer Aided Design) which was all about parts and assemblies - element-centric.  PLmis currently focused on the process, i.e. the &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_12"&gt;lifecycle&lt;/span&gt; of products.  I have been trying to sell decision-centric capabilities into &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_13"&gt;PLM&lt;/span&gt; since 2001 with no success.  The &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_14"&gt;push back&lt;/span&gt; has always been "we &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_15"&gt;aren't&lt;/span&gt; ready for that yet" and they weren't.  Now there is the &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_16"&gt;beginning&lt;/span&gt; of interest.  The product development industry is maturing through process to realize that business and technology progress is punctuated by decisions and it is the quality of those decisions that determine the product and business success.&lt;br /&gt;&lt;br /&gt;Further, when I talked about this decision-centric view of the world five years ago to industires, audiences had no idea what I was talking about.  Now I get good awareness and it is building.  There is yet hope for "evolution punctuated by decisions".&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-6585834182436830845?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/Gm3GylBisNc" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/6585834182436830845/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=6585834182436830845" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/6585834182436830845" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/6585834182436830845" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/Gm3GylBisNc/decision-making-maturity.php" title="Decision making maturity" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/08/decision-making-maturity.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-6710135666081914464</id><published>2008-07-21T10:10:00.000-07:00</published><updated>2008-07-22T06:11:52.420-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="hypothesis driven decisions" /><category scheme="http://www.blogger.com/atom/ns#" term="ACH" /><category scheme="http://www.blogger.com/atom/ns#" term="hypothesis driven approach" /><title type="text">Choosing the best hypotheses</title><content type="html">Many problems revolve around choosing the best hypothesis - the one that best explains some observations. This is a cornerstone of science and medicine, and is the day-to-day reality of intelligence agencies. Choosing the best hypothesis is a form of decision making. But there are some differences from traditional decision making problems as I discussed in an earlier &lt;a href="http://www.robustdecisions.com/making-robust-decisions/2008/07/evidence-based-decisions.php"&gt;blog&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;I want to compare two approaches to hypothesis-driven thinking. The first is in a paper by Jeanne Liedtka, of the University of Virginia, Darden School of Business, "&lt;a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=907959"&gt;Using Hypothesis-Driven Thinking in Strategy Consulting&lt;/a&gt;". The second is Richards Heuer's work for the CIA called &lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/art11.html"&gt;Analysis of Competing Hypotheses &lt;/a&gt;(ACH) (Chapter 8 of his book "&lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/index.html"&gt;The Psychology of Intelligence Analysis&lt;/a&gt;.")&lt;br /&gt;&lt;br /&gt;Liedtka tunes her process to consulting and states "The traditional decision-making process that we are most familiar with in business involves a linear method of thinking in which the problem is defined, a comprehensive range of alternative solutions is generated and evaluated, and the optimal one is selected. In contrast, the hypothesis driven approach, associated with the scientific method selects the most promising hypothetical solution early in the process and seeks to confirm or refute it" She goes on to out line the following steps:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Define the problem&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Gather preliminary data that allow construction of initial hypotheses about the causes of the problem&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Develop a set of competing hypotheses about the causes&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Select the most promising&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Identify analyses to study these&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Collect data and test the hypotheses&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Reformulate as needed&lt;/li&gt;&lt;/ol&gt;Admittedly, I have paraphrased and shortened the description of these steps, but I have not lost what the paper says to do.  When I read this, I get stuck on items 3 and 4.  In step 3, what is the difference between "developing a set" and the linear method decried in the quotation?  In Set 4, how should you "select the most promising"? &lt;p&gt;Heuer on the other hand suggests that you should:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;Identify possible hypotheses&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Make a list of significant evidence for/against&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Prepare a Hypothesis X Evidence matrix&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Refine matrix. Delete evidence and arguments that have no diagnosticity&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Draw tentative conclusions about relative likelihoods. Try to disprove hypotheses&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Analyze sensitivity to critical evidential items&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Report conclusions.Identify milestones for future observations&lt;/li&gt;&lt;/ol&gt;&lt;br /&gt;&lt;p&gt;These two processes are very similar. Where Liedtka, in the quotation beats up on developing multiple hypotheses, her method encourages more than one to be tested at a time. Heuer, on the other hand begins with "identify multiple hypotheses". He never states that this list needs to be complete, just that there needs to be more than one.&lt;br /&gt;&lt;/p&gt;&lt;p&gt;My research into how people develop products has shown, that designers that only develop a single alternative for a problem usually get into trouble because they have nothing to compare their efforts to and no secondary course of action, if the first idea hits a road block.  When hypothesis driven, it is somewhat the same. You can develop a single hypotheses and test it. If it fails, you can develop a second one, maybe even using some of the information developed during the first effort. However, this is fragile as you may be headed in the wrong direction.&lt;/p&gt;&lt;p&gt;A better approach is more like what Heuer suggests. Develop multiple hypotheses and then use measures (i.e evidence) to try to disprove them. Heuer never says that the the list of hypotheses needs to be extensive or complete, just multiple.  &lt;/p&gt;&lt;p&gt;One additional thought- as evidence is generally uncertain then you just take great care in using it as sufficient to eliminate a hypothesis.  This is why multiple evidence is generally best.  The good news is this is the way we naturally operate.  For example, I was approached last week by a man with a business idea close to something I was already interest in.  My initial hypotheses about him (in retrospect) were, 1) he had a good idea, was credible and I should invest time with him, and 2) he was a flake and I should waste little time with him.  I began with hypothesis #1 and began to collect evidence by talking with him.  After a reasonable time, I decided he passed the "sniff test" and modified my hypotheses so I could dig deeper into the business proposition.  However, I have not yet totally eliminated hypothesis #2.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-6710135666081914464?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/9M787a9lewA" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/6710135666081914464/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=6710135666081914464" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/6710135666081914464" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/6710135666081914464" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/9M787a9lewA/choosing-best-hypotheses.php" title="Choosing the best hypotheses" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/07/choosing-best-hypotheses.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1840224826421233239</id><published>2008-07-12T16:31:00.000-07:00</published><updated>2008-07-12T16:56:36.428-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="decision risk" /><category scheme="http://www.blogger.com/atom/ns#" term="event risk" /><title type="text">Event Risk vs Decision Risk</title><content type="html">I was just gave a presentation at the IG's (Inspector General's) office.  They are concerned about the risks involved when they make decisions.  What they don't realize is that there are two kinds of risk they have to worry about, event risk and decision risk.&lt;br /&gt;&lt;br /&gt;&lt;p&gt;Event risk is what most people mean they talk about "risk".  It is the expected value of an event, its undesirable consequences and probability of its occurrence.  Determining risk amounts to answering: &lt;/p&gt;&lt;ol&gt;&lt;li&gt;What can go wrong? –An event occurs that may have bad consequences&lt;/li&gt;&lt;li&gt;How likely is it? – Probability dependent on past statistics and model results&lt;/li&gt;&lt;li&gt;What are the consequences? –Money, time and possibly lives are wasted &lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;a href="http://www.hq.nasa.gov/office/codeq/doctree/praguide.pdf"&gt;NASA&lt;/a&gt; and others have entire handbooks on assessing event risk.&lt;/p&gt;&lt;p&gt;During decision-making, risks are inherent in uncertain knowledge, information and models. Uncertainty creates the risk that a poor decision will be made.  This doesn't say that the alternative chosen will fail, that is even risk.  Drawing analogy to event risk, decision risk focuses on:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;What can go wrong? – A poor choice is made &lt;/li&gt;&lt;li&gt;How likely is it? – Probability dependent on uncertain knowledge, and the fusion of the team’s interpretation of information and models &lt;/li&gt;&lt;li&gt;What are the consequences? –Money, time and possibly lives are wasted &lt;/li&gt;&lt;/ol&gt;&lt;p&gt;One problem the IG wants to address is selecting new employees.  Clearly the risk here is a decision risk - they want to ensure that they don't make a poor hiring choice.  They also want to manage their portfolio of projects.  Here the risk that the project can go wrong affects the risk that they make a poor decision.  The higher the event risk associated with an option, the higher the decision risk may be.&lt;/p&gt;&lt;p&gt;Both types of risk are based on probabilities.  However, traditional probability methods (often called frequentist methods) are good fro event risk, but are not capable of managing knowledge uncertainty.  Rather, Bayesian probability methods are specifically designed to integrate accumulating, uncertain, incomplete and conflicting knowledge. &lt;/p&gt;&lt;p&gt;Can I convince the IG folks of this?  We will see.&lt;br /&gt;&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1840224826421233239?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/8pKjcRo04SE" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1840224826421233239/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1840224826421233239" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1840224826421233239" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1840224826421233239" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/8pKjcRo04SE/event-risk-vs-decision-risk.php" title="Event Risk vs Decision Risk" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/07/event-risk-vs-decision-risk.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-7482003865726983053</id><published>2008-07-07T10:51:00.000-07:00</published><updated>2008-07-08T10:50:33.736-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="MAUT" /><category scheme="http://www.blogger.com/atom/ns#" term="evidence based decisions" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><title type="text">Evidence Based Decisions</title><content type="html">I have begun to work on intelligence agency decision-making and, in doing so, realized there were two different types. I have never seen this decision-making dichotomy written up anywhere and cant find it in the literature (any literature).&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;The first decision-making formulation is the standard process where the goal is to choose the best alternative from a list.  This is facilitated by comparing each alternative to a set criteria. Each  is measured relative to each criterion and its success in meeting it is combined (either formally or informally) to find the overall satisfaction with the alternative.  For example, say you are buying a new car. One criteria is that the car should accelerate for 0 to 60 in some fast time and a second is that it should get better than xx miles/gallon. Information with which to evaluate each of these may come from different sources. I may actually measure the acceleration of one car but rely on the test figure in a magazine for another.  In this way the evaluations for acceleration are independent from one alternative to the next.  The mathematics for this is  referred to as Multi-Attribute Utility Theory (MAUT).  Methods based on MAUT that support  decision-making are the decision matrix, Pugh's method, Expert Choice and &lt;a href="http://www.robustdecisions.com/decision-making-software/decision-professional.php"&gt;Accord&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;The second formulation is what is seen in medical and system diagnosis, and business and government intelligence.  This has not been formalized as best I can tell.   Here the goal is to choose the most likely hypothesis.  A hypothesis is like an alternative.  The big difference here is that , as each piece of evidence is gathered and analyzed, it either supports, denys or has no import on each of the hypotheses.  This differs from the first formulation in that a single evaluation potentially adds information to all the hypotheses (instead of independent).  For example, supposed we want to determine Iran's nuclear intentions.  Hypotheses include: 1) generate power only, 2) develop a nuclear weapon for ground delivery, or 3) develop a nuclear weapon for air delivery.  A piece of evidence, say a satellite photo of activity at an airbase, contributes information to all three of the hypotheses. &lt;br /&gt;&lt;br /&gt;The standard MAUT formulation does not support this second type of decision-making and neither do the tools listed above.  An aside, the medical profession uses the the term "evidence based" to mean making clinical data available to practitioners in a usable manner so that the doctor trying to figure out why your finger is rotting off has all the best clinical data on which to base her diagnosis.  This does not really support choosing which of the hypothetical diseases you actually have, but supplies information on which to evaluate the evidence.&lt;br /&gt;&lt;br /&gt;Situations like what I have just described can be modeled with methods like Bayes Nets, but there is no known method for facilitating the process as with the decision matirx, Pugh's and Accord.  I have spent months working on this and have found little in the literature.  Do you have any leads?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-7482003865726983053?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/Ul2TQ1jcGIg" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/7482003865726983053/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=7482003865726983053" title="3 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7482003865726983053" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7482003865726983053" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/Ul2TQ1jcGIg/evidence-based-decisions.php" title="Evidence Based Decisions" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">3</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/07/evidence-based-decisions.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-2581350300488153754</id><published>2008-07-03T05:33:00.000-07:00</published><updated>2008-08-14T12:10:58.459-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><title type="text">What is decision making, anyway!</title><content type="html">I track the term "decision making".  Like most terms the more you think about it, the more you realize that it is used rather loosely.  The word "decision" itself is really a noun but is often used in its verb form.  As a noun, it is the result of a process (to be discussed in a minute) that is a call to action.  I have decided to marry Adele. I have decided to walk through the doorway.  I have decided that, indeed grass is green.&lt;br /&gt;&lt;br /&gt;When people use the term "decision" they often mean the process of making a decision.  I am making a decision about which restaurant to eat at.  The team is working on that decision.  We often qualify the activity of choosing a course of action by using the term "decision-making".&lt;br /&gt;&lt;br /&gt;Decision-making implies that a choice is to be made - i.e. there must be two or more alternative courses of action.  However, often the process is about justification for a single course of action and the activity is focused on convincing someone that that this is right course to take.  (think politics and decision making processes used in attacking the Bay of Pigs and Iraq).&lt;br /&gt;&lt;br /&gt;I came across another curious use of "decision-making".  I found a web site titled "&lt;a href="http://mayet.som.yale.edu/coopetition/java/threenumbers.html"&gt;Test Your Decision Making&lt;/a&gt;" that has you do a short and very simple exercise to guess the rule that governs the sequence 2,4,6.  This is on the Yale University web site.   The answer is simple (it is a sequence) and the explanation centers on "To test a hypothesis, try to disprove it."  I frankly found the discussion confusing, but it at least it was about testing hypotheses (potential courses of action) in order to choose the best.  However, the point about testing each one until I found a counter example seems daunting for anything other than simple, toy problems like the one presented.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-2581350300488153754?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/A3RvF-iSA9U" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/2581350300488153754/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=2581350300488153754" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/2581350300488153754" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/2581350300488153754" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/A3RvF-iSA9U/what-is-decision-making-anyway.php" title="What is decision making, anyway!" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/07/what-is-decision-making-anyway.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1403154730917331843</id><published>2008-07-01T06:55:00.001-07:00</published><updated>2008-07-01T07:29:50.535-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making estimates" /><category scheme="http://www.blogger.com/atom/ns#" term="world trade center" /><category scheme="http://www.blogger.com/atom/ns#" term="uncertainty" /><title type="text">Most estimates suck</title><content type="html">The rebuilding of the World Trade Center (WTC) is behind schedule and over budget.  According to the executive director of the Port Authority, Christopher Ward "The schedule and cost estimates for the rebuilding effort that have been communicated to the public are not realistic," (from &lt;a href="http://ap.google.com/article/ALeqM5joqtqJP1HL4E_ZYbJAIwKeTlkpRQD91KVPPG0"&gt;AP article&lt;/a&gt;).  I can only say "Duh!" &lt;br /&gt;&lt;br /&gt;All decisions are based on estimates of the murky future.  In most public works projects honest estimates would never get them funded.  It is much easier to get something approved with optimistic time and cost estimates and then, once its started ask for more.  However, even if you are not playing politics, making estimates is hard work that is not well recognized for its impact of organizations&lt;br /&gt;&lt;br /&gt;Let's get this straight.  Even if you are trying to be as accurate and honest as possible, making an estimate is a highly uncertain undertaking.  And, most decisions are based on many, interdependent estimates.   In a simple experiment, I  asked hundreds of people to estimate the length of time needed to clean some dishes.  I gave them a detailed list of the dishes, and a photo of them, the sink, and cleaning materials.  I asked them to estimate how long to clean the dishes.   Depending on how I worded the question, the average time estimated was anywhere from 17 to 32 minutes and standard deviation was as high 10 minutes.  In other words, asking for an estimate for this simple, daily task isn't a whole lot better than using a random number generator set to give an estimate in the range of 10 -40 min.&lt;br /&gt;&lt;br /&gt;If this simple estimate is so bad, think of what happens with complexity, or for tasks that have not been done before.&lt;br /&gt;&lt;br /&gt;What is to be done then.  The only solution I know is to use methods that account for uncertainty.  For planning , the old PERT system made an effort at this (much improved method is &lt;a href="http://www.advanced-projects.com/"&gt;Critical Chain&lt;/a&gt;).  For decision making, I have been pushing people for years to include uncertainty in their decisions making process. &lt;br /&gt;&lt;br /&gt;In decision making, it is not only the estimates that are uncertain, it is the targets that you are trying to achieve that are uncertain.  More on this in a later blog.&lt;br /&gt;&lt;br /&gt;Back to the World Trade Center, I believe that if there had been a non-political effort at making decisions, and uncertainty had been included in the estimates, the plan would have been far less grandiose.   However, the WTC should be grandiose, shouldn't it?  This leads me to believe that honest estimates may not be the bast for all situations.  I would hate to run or work for a business with that in mind.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1403154730917331843?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/_Tpx3wM0ScY" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1403154730917331843/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1403154730917331843" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1403154730917331843" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1403154730917331843" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/_Tpx3wM0ScY/most-estimates-suck.php" title="Most estimates suck" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/07/most-estimates-suck.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-7003699437280983318</id><published>2008-06-24T06:28:00.000-07:00</published><updated>2008-06-24T11:08:36.551-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="estimates" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="anchoring" /><category scheme="http://www.blogger.com/atom/ns#" term="cognitive limitations in decision making" /><title type="text">Decision Anchoring</title><content type="html">A nice summary of how results can be anchored just appeared on the &lt;a href="http://www.nontoxin.com/anchoring-decision-making-advanced-persuasion-tactics/"&gt;web&lt;/a&gt;. This human behavior has great implications in business and technical decisions.&lt;br /&gt;&lt;br /&gt;Anchoring sets a biased context for estimation. It is a cognitive limitation that affects the quality of our decisions. Anchoring occurs, for example, when a manager asks for an estimate with something like: "I don’t see how we could commit more than $10,000 to this." $10,000 now becomes the anchor point. This stated amount biases all the following estimates that are generated.&lt;br /&gt;&lt;br /&gt;Anchoring can happen in subtle ways. Let’s say you are bidding on a project and you have been led to believe that the customer has a ceiling of, say, $10,000. You are now anchored to this value and will make decisions to try to force your project to fit it. This only seems logical, but it has interesting effects. First, the amount of work you propose will be descoped to fit the budget. But people always are optimistic, so, if you get the job, you will still have more work than money. Then begins the dance of working more for less money (overtime), further descoping or asking for more money. This dance is further discussed on pages 82-85 in &lt;a href="http://www.robustdecisions.com/decision-making-resources/making-robust-decisions-book.php"&gt;Making Robust Decisions&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;To demonstrate anchoring, I gave a group of people a simple estimation problem - asking them how long it would take them to wash a list of dishes. I described the dishes in detail, how dirty they were, and what "wash" meant. The mean estimate was 32 min with a standard deviation of 10 min. I then asked another group of subjects to estimate how long it would take to clean the dishes exactly as before, but this time I added "Your partner has told you that the kitchen needs to be clean in 15 minutes." This anchoring resulted in a new distribution with a mean of 18 minutes and a standard deviation of 6 min.&lt;br /&gt;&lt;br /&gt;Think of the implications on decision making. All decisions are based on best estimates of past performance, assessments of the current situation, and visions of the future. Every one of these can be clouded by anchoring. You cant totally avoid it. However, you can be aware of how you word your need for information and consciously try not to anchor estimates on which decisions will be based.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-7003699437280983318?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/LQHgIsZFGuI" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/7003699437280983318/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=7003699437280983318" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7003699437280983318" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7003699437280983318" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/LQHgIsZFGuI/decision-anchoring.php" title="Decision Anchoring" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/decision-anchoring.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-5651614394879905723</id><published>2008-06-17T09:00:00.000-07:00</published><updated>2008-06-17T09:43:50.437-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="cognitive limitations in decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making in medicine" /><title type="text">Cognitive problems in making decisions</title><content type="html">I have been reading "&lt;a href="http://www.amazon.com/How-Doctors-Think-Jerome-Groopman/dp/0618610030"&gt;How Doctors Think&lt;/a&gt;" by Jerome Groopman.  It is one of two books with the same title.  Basically, reading this will make you scared to go to the doctor as doctors are human and make lousy decisions, just like all the rest of us.  He has a good chapter titled "The Uncertainty of the Expert" which focuses on my favorite topic, decision making with uncertain information.  All of Groopman's comments come from cognitive psychology and apply to business and technical decisions as well.&lt;br /&gt;&lt;br /&gt;The key point in the chapter is  captured in one sentence about half way in: "Physicians, like everyone else, display certain psychological characteristics when they act in the face of uncertainty".  Uncertainty arises from 1) incomplete mastery of the available knowledge, 2) limitations of the knowledge,  3) difficulty distinguishing between the 1 and 2, and 4) (he leaves this one out) the variability of the nature of things.&lt;br /&gt;&lt;br /&gt;In the face of uncertainty we all tend to:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Focus on the positive rather than the negative (except engineers who are pessimists by nature).&lt;/li&gt;&lt;li&gt;Ignore uncertainty.  This is very evident in how we all talk about technical issue in terms of single values.  Luckily we have terms like "about", "near to"&lt;/li&gt;&lt;li&gt;Go with what's been done before even if it is based on an unknown and unproven orthodoxy.  Of course risk aversion is good and in medicine often leads to the correct diagnosis, whenever the problem is by-the-books.  However, in business, technology this aversion can lead to being swamped by the competition.&lt;/li&gt;&lt;li&gt;Have a confirmation bias.  This means that we look for support for our favorite alternative or hypothesis, at the expense of work on other possible options and discounting the negative (see item 1).&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;In the medical profession these characteristics are supported by the lack of time, risk aversion and an old-boys-club attitude.  It is interesting watching the decision making on the TV program House.  Here an arrogant, troubled doctor who hates the establishment diagnoses rare conditions and displays items 1,  2, and 3.  He is really good at #3. But, most of us are.&lt;/p&gt;&lt;p&gt; &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-5651614394879905723?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/Gx-4BGzuKzc" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/5651614394879905723/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=5651614394879905723" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/5651614394879905723" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/5651614394879905723" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/Gx-4BGzuKzc/cognitive-problems-in-making-decisions.php" title="Cognitive problems in making decisions" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/cognitive-problems-in-making-decisions.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-8303967294745807690</id><published>2008-06-12T05:40:00.000-07:00</published><updated>2008-06-12T06:40:56.715-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="neuroscience decision making" /><category scheme="http://www.blogger.com/atom/ns#" term="uncertainty" /><category scheme="http://www.blogger.com/atom/ns#" term="team decision making" /><title type="text">Bayesian Brain and Bayesian Teams</title><content type="html">An interesting article "Is This a Unified Theory of the Brain?" appeared in the New Scientist (&lt;a href="http://reverendbayes.wordpress.com/2008/05/29/bayesian-theory-in-new-scientist/"&gt;full text&lt;/a&gt;) on May 28&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_0"&gt;th&lt;/span&gt;.  This is basically a discussion of the work and theories of &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_1"&gt;neuroscientist&lt;/span&gt; &lt;a href="http://www.fil.ion.ucl.ac.uk/Friston/"&gt;Karl &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_2"&gt;Friston&lt;/span&gt;&lt;/a&gt; of the University College in London.  His work is based on an earlier theories that the brain makes decisions by trying to make sense out of the uncertainties in the outside world.  Basically, you make hypotheses about reality and compare sensory inputs to them, updating the hypotheses and the belief in them as you gather more information.  In essence you are constantly updating the probabilities that the hypotheses are true.  In fact the wiring in the brain is continuously changing to is suppress prediction errors.&lt;br /&gt;&lt;br /&gt;What makes this really &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_3"&gt;fascinating&lt;/span&gt; is that 1) this is Bayesian updating and 2) this applies to team decision making also.  The first observation has spawned the Bayesian Brain camp of &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_4"&gt;neuroscientists&lt;/span&gt;.  They believe we are all Bayesian thinkers, updating the probabilities that your hypotheses are correct as you solve small problems (e.g. if I turn the knob, the door will open) and large ones (e.g. If I choose to study the Bayesian brain, I will better &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_5"&gt;understand&lt;/span&gt; team decision-making).&lt;br /&gt;&lt;br /&gt;This brings us to applying what the &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_6"&gt;neuroscientists&lt;/span&gt; are doing on the individual, to what happens in a team making &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_7"&gt;business&lt;/span&gt; or technical decisions.  These decisions are generally about what courses of action to take to address a current situation (obscured by its immediacy) or the future (clouded by uncertainty).  A team that is functioning well will develop alternative courses of action or hypotheses and then gather an communicate information to increase its belief that one is better than the other, or to update the options based on the new information.  No different than a single brain, just much more complicated. &lt;br /&gt;&lt;br /&gt;What makes it harder is not only the communication of information amongst the team members (a clear focus of &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_8"&gt;Information&lt;/span&gt; &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_9"&gt;Management&lt;/span&gt;, Business Intelligence and the &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_10"&gt;Webex's&lt;/span&gt; of the world), but developing a shared vision of the information.  This is not to imply that everyone needs to understand all the information, but that there is some common understanding of the important bits.  This is a topic I beat on in Chapter 4 of &lt;a href="http://www.amazon.com/Making-Robust-Decisions-Management-Technical/dp/142510956X/ref=pd_bbs_sr_1/104-5215025-9091158?ie=UTF8&amp;amp;s=books&amp;amp;qid=1175657302&amp;amp;sr=8-1"&gt;Making Robust &lt;span class="blsp-spelling-corrected" id="SPELLING_ERROR_11"&gt;Decisions&lt;/span&gt; &lt;/a&gt;"Team Don't Make Decisions, But...."&lt;br /&gt;&lt;br /&gt;When we were first developing &lt;a href="http://www.robustdecisions.com/"&gt;Accord software&lt;/a&gt;, an effort to support the team decision making process,  we assumed that we could help teams by making what occurs inside one person's head transparent for the entire team.  Maybe we should become &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_12"&gt;neuro-scioscientists&lt;/span&gt; and study "Bayesian Team Dynamics".&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-8303967294745807690?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/TBngP0AZ-gs" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/8303967294745807690/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=8303967294745807690" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/8303967294745807690" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/8303967294745807690" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/TBngP0AZ-gs/bayesian-brain-and-bayesian-teams.php" title="Bayesian Brain and Bayesian Teams" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/bayesian-brain-and-bayesian-teams.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-286134693009587354</id><published>2008-06-11T05:23:00.000-07:00</published><updated>2008-06-11T12:56:11.970-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="analysis of alternatives" /><category scheme="http://www.blogger.com/atom/ns#" term="Knowledge management" /><category scheme="http://www.blogger.com/atom/ns#" term="Business intelligence" /><category scheme="http://www.blogger.com/atom/ns#" term="data mining" /><category scheme="http://www.blogger.com/atom/ns#" term="what to do next" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making methods" /><title type="text">Decision Making for KM and BI</title><content type="html">A June 10th article "&lt;a href="http://www.b-eye-network.com/view/7621"&gt;Knowledge Management and Business Intelligence&lt;/a&gt;" tries to tease apart KM and BI.  In the piece the author, Richard Herschel, refers to Gartner's definitions of the two terms:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;BI= a set of all technologies that gather and analyze data to improve &lt;strong&gt;decision making&lt;/strong&gt;&lt;/li&gt;&lt;li&gt;KM = a systematic process of finding, selecting, organizing, distilling and presenting information in a way that improves an employee's comprehension in a specific area of interest  Specific knowledge management activities help focus the organization on acquiring, storing and utilizing knowledge for such things as problem solving, dynamic learning, strategic planning and &lt;strong&gt;decision making&lt;/strong&gt;.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;What has always amazed me about these and other fields such as Analysis of Alternatives (AOA), Data Mining and even most Decision Support Systems (DSS) is that they are all about developing and managing information to support and improve decision making, yet &lt;strong&gt;none of them actually support the decision making process.&lt;/strong&gt;  &lt;/p&gt;&lt;p&gt;The decision making process requires 1) framing the problem, 2) evaluating the alternatives, 3)fusing the evaluation and 4) deciding what to do next.  All of the methods listed above help gather and organize information that is vital to good decisions, but all stop short.  Decision making requires more than the availability of database information.  In fact, as mentioned in the article "up to 80% of business information is not quantitative or structured in a way that can be captured in a relational database".  This non-quantitative information is the basis on which many business and technical decisions are made.  &lt;/p&gt;&lt;p&gt;Two cases support this.  First, a manufacturer of rocket engines uses our &lt;a href="http://robustdecisons.com/"&gt;Accord&lt;/a&gt; software because many of their key early decisions are qualitative and Accord can manage fusing the qualitative and quantitative evaluations.  Second, a Fortune 100 company received 20 proposals in response to an RFP for a piece of electronic equipment.  In the RFP were over 60 quantitative specifications for size, functionality, reliability, etc.  When they reviewed the proposals, they sorted them into two piles, those that met the specs and those that didn't.  Then they began to use the unstated, usually qualitative measures to differentiate the acceptable proposals so they could decide how to award the contract.  &lt;/p&gt;&lt;p&gt;The point is, most best practices focus on generating and managing information so decisions can be made.  They don't spend enough effort on framing,  fusing and managing what to do next.  Framing and evaluation fusion are the social interactions occur that develop buy-in, accountability and robust decisions.  It is these areas that are the hard part, that are not covered in school and are not well supported.&lt;/p&gt;&lt;p&gt; &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-286134693009587354?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/ePdoooM2JLU" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/286134693009587354/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=286134693009587354" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/286134693009587354" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/286134693009587354" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/ePdoooM2JLU/decision-making-for-km-and-bi.php" title="Decision Making for KM and BI" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/decision-making-for-km-and-bi.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-7941634339001229712</id><published>2008-06-08T08:55:00.000-07:00</published><updated>2008-06-24T11:21:57.732-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="decision support system" /><category scheme="http://www.blogger.com/atom/ns#" term="analysis paralysis" /><title type="text">Stuck in 'Analysis Paralysis'?</title><content type="html">Unresolved decisions can be very damaging to an organization.  You know something needs to be done but can't decide what to do.  Deliberation continues among your staff without an actionable conclusion.  You have 'analysis paralysis'.  Your operation is not moving forward, but you're using resources and your competition is not standing still.&lt;br /&gt;&lt;br /&gt;Symptoms of 'Stuck' decision making include the following:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Holding more than 3 meetings on a single issue &lt;/li&gt;&lt;li&gt;Continually gathering more information &lt;/li&gt;&lt;li&gt;Endlessly discussing and deliberating but not coming to a conclusion &lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;'Stuck' deliberation is often resolved at the twelfth hour and by a manager who may be forced to act arbitrarily, if not irrationally.  For any organization this is a highly risky way of operating. Here are some pointers for avoiding analysis paralysis:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Build a Shared Understanding: Information about the alternatives and criteria in a decision are understood only from each team member's own perspective.  Team members may not have a complete picture of the situation, nor the knowledge or time to develop a full, long-term view.  The key here is to set up environments that support the sharing of pertinent information needed for the decision. &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Work to separate Goals from Importance: Separate what is to be achieved (i.e. goals, targets) from how important it is to achieve it.  It is easier to agree on goals than what is important.Evaluation uncertainty may swamp out the differences in importance, but only if this goal/importance separation is made explicit.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Acknowledge and Manage Uncertainty:  The future is always uncertain.  The extent of this uncertainty needs to be identified as objectively as possible during decision-making.  Engineers and financial analysts in particular are prone to giving single, deterministic values for information that is really a distribution.  Push back on them to find the distribution, even if it is in terms like "very sure", "about" or "sort-of".  Early in the development of a system all estimates are uncertain and need to be managed as such.Information that is highly uncertain needs to be discounted or its uncertainty reduced if-and-only-if it is important (see item 2)&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Develop Multiple Alternatives:  Always consider multiple courses of action that can be itemized.  If the choice is to do A or "do nothing", then make an effort to develop alternatives B and C.  Develop methods within your organization that encourage creative options.Find ways to help the champions of each idea compare and contrast their alternatives with others.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Define a Decision-making Strategy:  Make sure there is an agreed to decision-making strategy.  Decision-making by stirring and restirring existing information is not beneficial. &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Build collaboration: Collaboration means that all stakeholders' opinions are heard during deliberation.  Then, even those whose first choice is not chosen will more likely buy in to the outcome.  This also gives the whole team a sense of accountability for the final decision.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Be Aware of Diminishing Analytical Returns:  Analysis is expensive and is likely to postpone resolution.  Over-analysis is the risk-averse activity of trying to drive out all uncertainty.  When the fidelity of simulation is greater than the uncertainty of the information on which the simulation is based, time and money are being wasted.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Reuse History:  Work toward learning from past decisions.  Evaluating your success requires keeping track of past choices; the actions as well as the results.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Find a Platform to manage and fuse uncertain team evaluations: Use proven methods and tools that help your organization reduce risk and avoid deliberative quagmires.  &lt;/li&gt;&lt;/ol&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-7941634339001229712?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/KlCiSn2kK4k" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/7941634339001229712/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=7941634339001229712" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7941634339001229712" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/7941634339001229712" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/KlCiSn2kK4k/stuck-in-analysis-paralysis.php" title="Stuck in 'Analysis Paralysis'?" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/stuck-in-analysis-paralysis.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1026809963674764576</id><published>2008-06-08T08:33:00.000-07:00</published><updated>2008-06-24T11:27:19.664-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="Blink" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making process" /><category scheme="http://www.blogger.com/atom/ns#" term="justification" /><title type="text">A Justification is Not a Decision</title><content type="html">There are two kinds of decision-making: justification and selection.  Justification occurs when the result is a foregone conclusion — the choice is made in advance of any argument or consideration. This often happens when the boss already has his favorite option in mind and wants information to "prove" that it is the right choice. I have seen this during my career in product design and the nation saw it in President Bush's decisions about Iraq. In Maureen Dowd's NY times Op-Ed on June 1 2008, "&lt;a href="http://www.nytimes.com/2008/06/01/opinion/01dowd.html?_r=1&amp;amp;oref=slogin"&gt;Cult of Deception&lt;/a&gt;" she says that "our president is a one-man refutation of Malcolm Gladwell's best seller &lt;em&gt;Blink,&lt;/em&gt; about the value of trusting your gut."&lt;br /&gt;&lt;br /&gt;In an earlier blog, I discussed &lt;em&gt;Blink&lt;/em&gt; and how trusting your gut can be the wrong approach for complex decisions, because you can't include sufficient information or study alternative courses of action. However, managers that get that warm fuzzy feeling when they know the best course of action, before they have sufficient information, can be dangerous. Of course, they may be right. If they usually are, then they clearly have sufficient information and a good decision making style. But if these justifications often end up with later fire-fighting, then justification is not working in lieu of decision-making.&lt;br /&gt;&lt;br /&gt;Actually, the CIA has a method that is supposed to short circuit justification-thinking.  It is called Analysis of Competing Hypotheses and is in a downloadable book titled "&lt;a href="https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/index.html"&gt;Psychology of Intelligence Analysis&lt;/a&gt;."  Basically, ACH prescribes the following steps:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Identify the possible hypotheses to be considered.&lt;/li&gt;&lt;li&gt;List the significant evidence and assumptions for and against each hypothesis.&lt;/li&gt;&lt;li&gt;Draw tentative conclusions about the relative likelihood of each hypothesis.&lt;/li&gt;&lt;li&gt;Analyze sensitivity of the conclusion to critical items of evidence.&lt;/li&gt;&lt;li&gt;Identify future observations that would confirm one of the hypotheses or eliminate others.&lt;/li&gt;&lt;/ol&gt;&lt;br /&gt;This differs some from the process I develop in &lt;a href="http://www.amazon.com/Making-Robust-Decisions-Management-Technical/dp/142510956X"&gt;Making Robust Decisions&lt;/a&gt;, but both begin with basic fact that — &lt;strong&gt;YOU MUST HAVE ALTERNATIVES TO MAKE A DECISION&lt;/strong&gt;. I put this in bold because it seems evident that many Washington decision makers don't follow this basic truth. In fact, many business leaders don't follow this either. In the book &lt;a href="http://www.amazon.com/Why-Decisions-Fail-Paul-Nutt/dp/1576751503/ref=pd_bbs_1?ie=UTF8&amp;amp;s=books&amp;amp;qid=1212940047&amp;amp;sr=1-1"&gt;Why Decisions Fail&lt;/a&gt;, Paul Nutt gives three basic blunders. One of these, "Premature Commitments" is the the same as the justifications we are discussing here.&lt;br /&gt;&lt;br /&gt;So what do you do to stop this kind of ineffective decision-making. The only thing to do is to set up an environment that forces multiple decisions to be considered. Sometimes this is difficult from below, but if you are a manager, insist on multiple alternatives to consider.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1026809963674764576?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/8RTvuTtZOxY" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1026809963674764576/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1026809963674764576" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1026809963674764576" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1026809963674764576" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/8RTvuTtZOxY/justification-is-not-decision.php" title="A Justification is Not a Decision" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/justification-is-not-decision.php</feedburner:origLink></entry><entry><id>tag:blogger.com,1999:blog-2214230078779276579.post-1400355659298406005</id><published>2008-06-07T08:53:00.000-07:00</published><updated>2008-07-07T01:07:50.536-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="Blink" /><category scheme="http://www.blogger.com/atom/ns#" term="gut decisions" /><category scheme="http://www.blogger.com/atom/ns#" term="decision making methods" /><title type="text">Gut decisions don’t work well in many situations</title><content type="html">There has been a recent spate of best-selling books that support the notion that you should go with your gut when making a decision (e.g. &lt;a href="http://www.amazon.com/Blink-Power-Thinking-Without/dp/0316010669/ref=pd_bbs_sr_1?ie=UTF8&amp;amp;s=books&amp;amp;qid=1212680757&amp;amp;sr=1-1"&gt;Blink&lt;/a&gt;: The Power of Thinking Without Thinking by Malcolm Gladwell, &lt;a href="http://www.amazon.com/Gut-Feelings-Intelligence-Gerd-Gigerenzer/dp/0670038636"&gt;Gut Feelings&lt;/a&gt; by Gerd Gigerenzer and Gary Klein's &lt;a href="http://www.amazon.com/Power-Intuition-Feelings-Better-Decisions/dp/0385502893/ref=pd_bbs_sr_1?ie=UTF8&amp;amp;s=books&amp;amp;qid=1212680822&amp;amp;sr=1-1"&gt;The Power of Intuition&lt;/a&gt;: How to Use Your Gut Feelings to Make Better Decisions at Work).&lt;br /&gt;&lt;br /&gt;The authors of these books state that for many decisions there is no need to formally identify the issue, develop multiple alternatives, and itemize criteria — just go with your intuition. Of course, they are right — for some decisions. We make decisions in two very different ways. Sometimes we reach conclusions unconsciously — our minds quickly and silently sorting through the available information and drawing an immediate judgment. This may be in a blink — so quickly and so far below our level of awareness that we may have no consciousness of where our conclusions came from. If we are trying to decide what to do in an emergency, how to walk through a doorway, or many other simple or no-time-to-think situations then this is the right approach.&lt;br /&gt;&lt;br /&gt;One study of decision-making methods (see Payne, Bettman, and Johnson, &lt;a href="http://www.amazon.com/Adaptive-Decision-Maker-John-Payne/dp/0521425263/ref=sr_1_1?ie=UTF8&amp;amp;s=books&amp;amp;qid=1212681165&amp;amp;sr=1-1"&gt;The Adaptive Decision Maker&lt;/a&gt;) found that&lt;br /&gt;&lt;ol&gt;&lt;li&gt;People use a variety of cognitive strategies, dependent on task and context factors.&lt;/li&gt;&lt;li&gt;Given that people have limited cognitive abilities, strategy selection is a compromise between accuracy and the desire to minimize cognitive effort.&lt;/li&gt;&lt;li&gt;People are opportunistic; they change their strategies on the fly.&lt;/li&gt;&lt;/ol&gt;&lt;br /&gt;The study indicated that intuition follows a strategy in which we compare the first alternative solution for the situation to the most important criterion. If our evaluation shows that the alternative satisfies that criterion, we accept it and move on. If it doesn’t, we generate another alternative and try again. If there is more than one alternative that satisfies the most important criteria, we move to the next most important criterion to try to zero in on the one to choose. Of course, this strategy may be modified if we are out time, there are too many alternatives, or there are others involved.&lt;br /&gt;&lt;br /&gt;Research I did in the early 1990s showed that designers who pursued their first idea generally ended up with concepts that needed much patching to make them work, if they could be fixed at all. Another study of design engineers showed that the quality of design results linearly improved with the time and effort spent on developing alternatives and criteria (this work is in an obscure German dissertation but the results can be read in a paper I wrote "&lt;a href="http://www.robustdecisions.com/theidealenginsyste1.pdf"&gt;The Ideal Engineering Decision Support System&lt;/a&gt;."&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='http://res1.blogblog.com/tracker/2214230078779276579-1400355659298406005?l=www.robustdecisions.com%2Fmaking-robust-decisions%2Findex.php'/&gt;&lt;/div&gt;&lt;img src="http://feeds.feedburner.com/~r/making-robust-decisions/~4/BmC_YT6bWm0" height="1" width="1"/&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/1400355659298406005/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=2214230078779276579&amp;postID=1400355659298406005" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1400355659298406005" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/2214230078779276579/posts/default/1400355659298406005" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/making-robust-decisions/~3/BmC_YT6bWm0/gut-decisions-dont-work-well-in-many.php" title="Gut decisions don’t work well in many situations" /><author><name>David G. Ullman</name><email>noreply@blogger.com</email></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://www.robustdecisions.com/making-robust-decisions/2008/06/gut-decisions-dont-work-well-in-many.php</feedburner:origLink></entry></feed>
