Mercurial Hosting > go2
view src/RDMCh3.html @ 0:0e911cd3fd2a
add content
| author | Franklin Schmidt <fschmidt@gmail.com> |
|---|---|
| date | Sun, 02 Apr 2023 10:30:03 -0600 |
| parents | |
| children |
line wrap: on
line source
<html> <!-- Mirrored from users.eniinternet.com/bradleym/RDMCh3.html by HTTrack Website Copier/3.x [XR&CO'2014], Sun, 06 Nov 2022 06:59:18 GMT --> <head> <title> Reasoning And Decision Making - Milton N. Bradley</title> <link rel="stylesheet" href="style2.css"> </head> <body bgcolor="#E0FFFF"> <a name="top"></a> <center><br><br> <font class="booktitle"> Reasoning And Decision Making</font> </font> <br><br> <h1> <font class="chaptitle"> © Milton N. Bradley 2010</font> <hr></h1></center> <br><br> <center><a name="Chapter3"></a> <font class="chaptitle"> <strong>Chapter 3 - The Nature Of Problems, Problem Statements, Concept Mapping, Information Gathering</strong> </font><br> </center> <br><br><br> <font size= +1> <strong>Definitions:</strong><br><br> <strong>Problem =</strong> Recognition that the current situation (the initial state) is in some significant way different from and less desirable than a goal (the final/desired state).<br><br> <strong>Problem Context =</strong> The overall situation in which the Problem exists.<br><br> <strong>Problem Statement => Spells out:</strong><br> <ul> <li> <strong>Current Status =</strong> The set of known/given information that defines the Problem. <li> <strong>Goal = </strong>Specification of the final status that will be accepted as the Problem Solution. <li> <strong>Problem Description =</strong> The specifics of the difference(s) between the initial and goal states, which exist because one or more of the following are true: <ul> <li> Something is wrong that must be corrected. <li> Something is missing that must be provided. <li> Something is threatened that should be prevented. <li> A desirable improvement opportunity exists. </ul> <li> <strong>Problem Action Specification =</strong> The most precise statement possible of the set of feasible actions/operations that must be taken in order to move from the Current (Problem) state to the desired Goal (Solution) state. </ul> <strong>The Nature of Problems And Their Solutions</strong><br><br> In common with most other situations of interest, it is readily possible to conceive of the continuity of problems as being parsed in a number of different ways, each of which has special and often unique value in achieving understanding of the extremely complex underlying reality. For that reason, the reader should understand that the arbitrary and quite simple dichotomy proposed next is just one of many possible ways of characterizing that reality.<br><br> <strong>For our present purposes, we shall consider that all problems can be divided into two complementary but mutually exclusive classes:<br> <OL type = DISC> <LI> Problems with exact solutions. <LI> Problems for which exact solutions are unknown, infeasible, or impossible. </strong></OL><br> Problems with exact solutions occur largely in disciplines like mathematics and the sciences, but also can sometimes be found in the common simpler interfaces of ordinary existence. Although achieving a correct solution to the more difficult and advanced of this class of problem often requires prodigious amounts of training and the application of much hard work, ultimately, if you have those qualifications and make the requisite effort, the desired answer will be forthcoming. What happens is that you use your expertise to correctly evaluate the situation, recognize which techniques are relevant, apply due diligence in collecting and validating the requisite data, apply the appropriate technique and “turn the calculation crank”, and out pops the desired, unambiguous answer!<br><br> Problems that lack exact solutions include most of the non-trivial ones which we routinely encounter in everyday personal life, business, government, and social organizations. A major difficulty in solving these problems lies in the fact that in many cases the relevant facts are not completely known but must be estimated (at best) or “guesstimated” (at worst), and that precise solution techniques not only are often not known, but sometimes may not even exist.<br><br> Another major difficulty that we will encounter, both in this book and in applying its technologies to real world problems, is that the methods that we present and apply herein are designed to minimize the uncertainties (to the extent that’s feasible), and that we are then going to turn that same “calculation crank” to generate an answer. But although that “answer” may then have the same superficial appearance of precision as that obtained from calculation in problems with exact solutions, it’s really anything but! So falling into the mental trap of missing or ignoring that essential difference is something that the successful problem solver must studiously avoid! <br><br> In the search for real world problem solutions it’s also essential to understand and conform to the following “Guiding Principles”, most of which will not be found in any standard text. Failure to understand and be guided by them will almost necessarily result in an inability to ever develop correct solutions to an entire class of important real life problems, so they may be ignored only at your own peril! Except as otherwise noted, all are my own formulations.<br><br> <strong>Guiding Principles</strong><br> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="left" valign="top"> <br> <font class="txtboxbig"> <strong>“The validity and worth of an idea is independent of: <OL type = DISC> <LI> Who proposed it.<LI> How long it has been believed.<LI> The number and importance of those who subscribe to it.<LI> The vehemence with which they support their belief.”</strong></OL> </font> <br><br> </td> <td width="30"> </td> </tr> </table><br><br> </center> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “It ain’t what people don’t know that hurts ‘em, <br> it’s what they know that ain’t so!” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <center>Charles Farrar Browne, AKA Artemus Ward, 4/23/1834 - 3/6/1867, American Philosopher and Humorist</center><br><br> </table> </center> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “ Facts have no agenda.” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <br> </center> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “Truth is an Uncompromising Taskmaster.” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <br> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “Except by accident, the correct solution to a problem can only result <br> from accurate facts, objective analysis and Reasoning” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <br> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “The simplest explanation in accord with the facts is best.” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <center>"Occam's Razor", an accepted principle of Logic.<center><br> </center> </center> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxsmall"> “A simplistic solution to a complex problem is almost invariably wrong.” </font> <br><br> </td> <td width="30"> </td> </tr> </table><br> </center> <br> </center> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="middle" valign="top"> <br> <font class="txtboxbig"> <strong>The reliability of the answer <br> cannot exceed <br> the reliability of the input data. </strong> </font> <br><br> </td> <td width="30"> </td> </tr> </table><br><br> </center> So you must be careful in your search for problem solutions, always keeping in mind the well known caveat of computers, that:<br><br> <center> <br><table class="txtbox"> <tr> <td width="30"> </td> <td align="left" valign="top"> <br> <font class="txtboxbig"> <strong>GARBAGE IN, GARBAGE OUT!</strong> </font> <br><br> </td> <td width="30"> </td> </tr> </table><br><br> </center> <br> <strong>General Problem Solution Guidelines</strong> <ul> <li>Be careful not to look for a solution until you’re certain that you really understand the problem. <li>Carefully distinguish between symptoms and the actual underlying problem. <li>Take as much time as required to thoroughly examine and explore the Problem Context and Constraints before attempting to develop the Problem Statement. Often, properly understanding the problem is enough to solve it. <li>Avoid <ul> <li>Accepting information at face value <li>Making/using implicit but incorrect assumptions/premises <li>Making premature evaluations <li>Blindly applying stereotypes and/or analogies. <li>Blindly accepting the judgment(s) of “authorities”. <li>Functional fixedness = Using habitual modes of behavior/thought which make it more difficult to see new and better approaches. <li>Fixating on one presumed (often “obvious” but incorrect) “solution”, rather than continuing to search for the best solution. <li>Arbitrarily rejecting proposed solutions/solution mechanisms based on “gut feel”, bias toward the proposer, or other non-rational criteria. </ul> <li>Be sure to solve the problem that really exists and not just the problem you already have a solution for, the problem you wish existed, or the problem someone else thinks exists. <li>If a solution to the problem you are trying to solve already exists, begin by studying that solution even if you intend to improve on it. <li>Be careful not to select a solution until you have a whole range of choices. That will allow you to choose the best from among many. <li>The way in which the problem is stated has much to do with the quality of the solutions that can be found: <li>The formulation of the Problem Statement determines/constrains the range of available solution choices. <li>The initial Problem Statement proposed all too often reflects a preconceived (usually wrong) solution. <li>Breaking the problem into smaller parts can often make solving it much easier, because you can then solve each part separately. (This is a common and highly successful technique used in computer programming.) <ul> <li>Begin by solving the simplest version of each subproblem, then <li>Build the overall solution incrementally. </ul> <li>Remember the critical importance of obtaining acceptance in solving problems involving others. A solution that is technologically brilliant but sociologically stupid is not a satisfactory solution. <li>Operate with the understanding that people work to implement their own ideas and solutions much more energetically than they work to implement those of others. <li>Remember that, however exact they may appear, the solutions to real world problems involving people can never be completely precise, so their implementation must always take that caveat into account. <li>Avoid judging behavior. Labeling people as "good" or "bad" is an easy (but defective) way to dispense with interpersonal problems of instead of trying to figure out why people behave as they do. <li>Avoid assuming you are much smarter or better informed than others (with the result that you can safely ignore their input). <li> Remember that: <ul> <li>Denying the existence of a problem only serves to perpetuate it. <li>A problem is not a punishment, but an opportunity! </ul> <li>Recognize that many practical problem situations involve: <ul> <li>Personal values that influence which solutions may be “acceptable”. <li>Ambiguity and/or inadequate definition. <li>Multiple causality. <li>Inadequate information. <li>No elegant solution. </ul> <li>There is rarely one completely "right" answer. <li>Different answers may each be “somewhat right”. <li>Involved individuals and/or groups may understand their problems better than you do, and therefore act in ways they think entirely reasonable but which seem less than that to you. <li>Be patient and persevere. <li>Don't expect to find permanent answers. </ul><br> <strong>Underlying Problem Solution Principles</strong><br><br> <ul> <li><strong>The Law of Optimal Sloppiness</strong><br><br> Only employ the minimum degree of precision in data and analysis necessary to arrive at a decision that has an acceptable probability of being correct. <br><br> One of the best ways of determining which input variables need be considered to satisfy this principle is the following.<br><br> <li><strong>The Principle of Successive Approximation</strong><br><br> At the beginning of the problem solving process the first step should be to try to derive an order-of-magnitude answer using quick, gross approximations. Then only if that approximate answer seems reasonably productive should you incrementally invest the much greater amount of time and effort needed to obtain and analyze more complete and accurate information.</strong><br><br> <li><strong>The Pareto Principle</strong><br><br> Studies conducted by the Italian economist Vilfredo Pareto (1848 - 1923) produced the brilliant insight that 80% of his nation’s wealth was owned by only 20% of the people. Further studies and experience by Pareto and many others revealed the even more useful insight that this same ratio of cause and effect applies in a wide variety of fields and circumstances!<br><br> What this means is: In studying any situation it is usually feasible to reach reasonable decisions based solely upon identifying and considering the key 20% of all of the causal factors, while safely ignoring the vast insignificant multitude of others. </ul><br> <strong>To perform a Pareto Analysis:</strong> <ul> <li><strong>List the variables involved.</strong> If there are many, group related items. <li><strong>Score the items or groups.</strong> The scoring method to use will depend on the nature of the problem. (i.e. In one case the criterion might be cost, in another it might be convenience on a 0-5 scale, etc.) <li><strong>Act on the highest scoring items first </strong>, and stop whenever desired after 80% of the total expected benefit has been attained. (The options with the lowest scores will probably not even be worth bothering with, because solving those problems may cost more than the benefits received.) </ul><br> Applying the Pareto Principle in conjunction with each of the techniques that follow will enable greatly limiting the number of variables to be included in the analysis without significantly decreasing the validity of the decisions reached.<br><br> <strong>Principles of Cost/Benefit Analysis</strong> <ul> <li><strong>There Must Be a Common Unit of Measurement To Compare Costs With Benefits.</strong><br> The Simplest and Most Common Measurement Unit is Money. The difficulty here is that some benefits are intangible (i.e. “Quality of life”), and assessing a reasonable $ equivalent for these is not only a strictly subjective (and not always feasible) exercise, but one which may easily completely change the result of the final comparison. So such assessments must be conducted with extreme caution! <br><br> <li><strong>The Comparison Must be In Terms of $ at a Specified (future) Date. (= Discounted $ Value.)</strong><br> How to choose the appropriate interest rate to use for the discounting and then calculate the discounted value of money are standard accounting procedures which are beyond the scope of this course, so they will not be discussed here. Both are described in any introductory accounting text, and standard actuarial tables are available for this calculation for any interest rate and time period. <ul> <li>(Project Benefits $ value) x (Discount factor) = Discounted Present $ Value of Benefits<br> <li>(Project cost $) x (Discount factor) = Discounted Present $ Value of Costs<br> <li>(Project Net Benefit) = (Total Discounted Present $ Value of benefits) - (Total Discounted Present $ Value of costs.) </ul><br><br> <li><strong>If this net difference is positive and great enough to justify the time and energy that must be expended, then the project is tentatively worth pursuing.</strong><br><br> <li><strong>Semi-final confirmation of whether or not the project is worth pursuing should result from a “With vs. Without” Analysis of the proposed changes.</strong> In conducting this phase of the decision making process, it is important to recognize that for certain types of problem the result may vary depending on the particular study area chosen. (e.g. The best choice for a local situation might not be best in the overall context, or conversely.)<br><br> <li><strong>The final decision on whether or not to proceed with a particular project will depend on whether or not there are other mutually exclusive projects with a positive Net Discounted Present $ Value competing for the same limited amount of available resources of time, money and personnel.</strong> If there are, simple comparison will select that project with the highest Net Discounted Present $ Value for immediate action. (Whether or not the other projects with positive Discounted Present $ Value ever ultimately get worked on will depend on factors outside our present interest.)<br> </ul> <br> <strong>Solution Search Guidelines: </strong><br> <ul> <li>The entire problem space must be searched. <li>Backtracking and/or repetitive searching of the same local areas should be avoided. </ul><br> <strong>Desirable Solution Development Technique Characteristics</strong> <ul> <li>Simple <li>Quick <li>Inexpensive <li>Require no specialized tools, knowledge or expertise to apply <li>Applicable to a wide variety of problems</strong> </ul><br> These techniques are not mutually exclusive, and are often used sequentially or even simultaneously, to examine the various problem aspects from several different viewpoints, all with the same objective of maximizing the chances that the best possible Problem Solution will be reached. <br><br> <strong>Developing A Problem Statement</strong><br><br> The necessary first and often most critical step in arriving at an adequate Problem Solution is developing an appropriate Problem Statement, and this is sometimes so difficult to accomplish that it may not be possible to be certain that it’s been accomplished until you’ve actually succeeded in solving the Problem! <br><br> <strong>Creating a Problem Statement involves 8 essential steps:</strong><br><br> <ul> <li>Determine the Problem Context. <li>Objectively assess the current situation and its (often far from obvious) implications: <ul> <li>Identify the key operative factors. <li>Assess the relative importance of each. <li>Determine Their Relationships And Interactions. </ul> <li>Identify/Collect/Validate Relevant Facts and Data. <li>Identify/Quantify The Operative Constraints. <li>Create a Prototype Problem Statement. <li>Develop Rational Solution Alternatives <li>Verify That A Solution Is Feasible, Given The Available Data And Resources. <li>Repeat These Steps As Required Until The Best Possible Solvable Problem Statement Is Generated. </ul><br> Now let’s investigate each of these steps in detail. <br><br> <ul> <li><strong>Determine The Problem Context</strong><br><br> <strong>This</strong> should typically be apparent from direct observation, and <strong>will consist of some combination of the following contexts:</strong> <ul> <li>Social <ul> <li>Personal <li>Interpersonal <li>Group <li>Organization </ul> <li>Political <li>Employment <ul> <li>Technical <li>Organizational <li>Employee/Management <li>Peer <li>External </ul> <li>Economic <li>Educational <li>Professional </ul><br.<br> <li><strong>Objectively assess the current situation and its (often far from obvious) implications:</strong><br><br> <ul> <li>Identify the operative factors <li>Determine their relationships <li>Assess the relative importance of each </ul></ul><br> In this book we shall restrict our attention to Concept Mapping and Venn Diagrams, which are the simplest and most generally applicable of the many alternative methods for performing this essential task. Concept Mapping requires no special preparation, so we shall discuss it first. Applying Venn Diagrams requires some knowledge of Formal Symbolic Logic, and that was the main reason that subject was introduced in the previous chapter.<br><br> <strong>Concept Mapping</strong><br><br> This is a technique designed to make it easier to understand the interplay between ideas, by creating a visual picture of their relationships and interconnections. It allows you to better: <ul> <li>Understand the interactions between ideas you already have. <li>Relate new ideas to your existing knowledge. <li>Organize the ideas in a logical but flexible structure that indicates what future information or viewpoints need be included, while providing for their incorporation. </ul><br> <strong>Caution!</strong><br><br> <i>A Concept Map is not a goal in itself! Rather it’s a tool whose use in accurately representing and understanding the current situation can enable you to produce a better Problem Statement, and ultimately a maximally useful Problem Solution!</i><br><br> <strong>The Advantages of Concept Mapping</strong> <ul> <li>Replaces often complex verbal descriptions with a few simple diagrams. <li>Summarizes all the relevant information on one page. <li>Clearly identifies and defines the most important concept(s) >li>Specifies and clarifies the often complex relationships between concepts. <li>Illustrates their relative importance. <li>Readily allows identification of contradictions, paradoxes, and gaps in the system or in your understanding of it, so that corrective action can be initiated. <li>Makes recall and review of the relevant information more efficient. <li>Makes it easier to add new information. <li>Makes it easier to see the system and its information from different viewpoints. </ul> <br> <strong>The Structural Elements of a Concept Map</strong> <ul> <li>Concepts. These form the substance of the problem situation. <li>Branches. A concept may branch many times to include both closely and distantly related concepts. <li>Arrows join concepts from different branches. <li>Groupings of related concepts are usually indicated by enclosing them within a box or circle.. <li>Lists. <li>Notes. Usually shown alongside the appropriate portions of the Map to explain, question or comment on the concepts and/or the relationships between them. </ul><br> <strong>The Four Major Categories of Concept Map:</strong><br><br> <strong>The Hierarchy Concept Map</strong> presents related information in descending order of importance. <br><br> In the following example, this powerful method of organizing data is applied to the Concept mapping process itself! <br><br> <P ALIGN="CENTER"><img src="CM3.gif" align=middle> </P><br><br> A standard <strong>Organization Chart</strong> like that of The US Department of Agriculture Headquarters Office shown below is another prime example of a Hierarchy Concept Map.. <br><br> <P ALIGN="CENTER"><img src="orchart2.jpg" align=middle> </P><br><br> The <strong>Flowchart Concept Map</strong> organizes information to show the progression of the physical and/or temporal flow of materials and/or information. Originally developed to describe industrial processes, this technique soon proved to be applicable to almost any activity because of the simplicity and universality of its basic descriptors:<br><br> <strong><P ALIGN="center"><img src="oper.gif" align=middle> <ALIGN="center"><img src="trans.gif" align=middle> <ALIGN="center"><img src="store.gif" align=middle> <ALIGN="center"><img src="delay.gif" align=middle></strong> <ALIGN="center"><img src="insp.gif" align=middle></P><br><br> Adding a Diamond to this basic 5 symbol set to represent the asking of a question (usually requiring a “yes” or “no” answer) to determine which alternative path to follow, it is possible to accurately and concisely describe almost any realistic situation. As an example, shown next is a simple Flow Chart I created to describe the process of deciding whether or not to repair or replace a broken TV set. <br><br> <P ALIGN="CENTER"><img src="Broken%20TV%20Flowchart%202.gif" align=middle></P> <br><br> The "Spider" Concept Map is organized by placing the central theme or unifying factor in the center of the map, then surrounding it with outwardly radiating sub-themes and supporting details. <P ALIGN="CENTER"><img src="spider4.gif" align=middle> </P><br><br> <strong>The Systems Concept Map</strong> organizes information with focus on inputs and outputs. In this formulation the information is usually presented in hierarchical fashion, and in that limited sense it’s similar to the Hierarchy and Organization Charts. The simplified examples below describing the automotive manufacturing process were prepared by me especially for this book. <P ALIGN="CENTER"><img src="MB%20Cars%201.gif" align=middle> </P><br><br> <P ALIGN="CENTER"><img src="MB%20Cars%202.gif" align=middle> </P><br><br> <strong>Steps In Constructing A Concept Map</strong><br><br> The following are the steps in building a concept map manually. (A number of commercially available software programs exist for this task, and the steps are essentially the same in each case.)<br><br> <ul> <li><strong>Assemble Your Writing and Drawing Materials</strong><br> Interrupting your thought processes to find a tool or notebook is more than a inconvenience, because it can completely break your concentration. So have plenty of supplies on hand, including paper, colored markers, a ruler, and even a shape template for drawing the concept boxes.<br><br> <li><strong> Find/Gather/Understand Your Research Materials</strong><br> These can include: books, related newspaper, magazine and technical journal articles, notes of independent observations, data/statistics, computer data bases, web site addresses, and visual materials such as videos, photos and diagrams. This is your database, and it is vital that you not only become thoroughly familiar with it but can list 10-15 key concepts as well as several examples before you begin constructing a Concept Map.<br><br> <li><strong>Make as complete a list as possible of all of the relevant concepts and examples impacting your Problem.</strong><br> Remember that it is feasible to create many different maps from the same list, depending on how you interpret the relationships between the relevant components.<br><br> <li><strong>Rank the concepts (key words) from the most abstract and inclusive to the most concrete and specific.</strong><br><br> <li><strong>Cluster concepts that function at similar levels of abstraction, and note how and to what degree they interrelate.</strong><br><br> <li><strong>Become familiar with each of the different Concept Map Formats, and understand the type of information/analysis each is best suited for.</strong><br><br> <li><strong>Select The Concept Map Format that best fits the current problem.</strong><br> In the non-technical, non-business environment of this course, the Hierarchy and Spider/Network Maps will most often be appropriate.<br><br> <li><strong>Transfer the concepts, events, and physical entities to 3 x 5 cards, small pieces of paper, or post-it notes</strong>, preferably using different colors for each type of input. (In a computer model, use different symbols.)<br><br> <li><strong>Arrange the cards on a large sheet of paper or poster board in the structure consistent with the type of Concept Map you’ve chosen.</strong> (If it’s hierarchical, for example, you will place the broadest or most abstract ideas at the top and the most specific ideas at the bottom.). If appropriate, add subsidiary concepts that help explain, connect, or expand the key ideas that you have. Don’t include the examples yet. <br><br> <li><strong>Draw lines to connect the related concepts, events, and physical entities.</strong><br><br> <li><strong>On the connecting lines, write words or phrases that explain the relationships between these items.</strong><br><br> <li><strong>Enter the examples under the appropriate concepts, and connect them with arrows and accompanying explanatory phrases.</strong><br><br> <li><strong>Reorder and revise as many times as necessary until the best and fullest possible explanation of the relationships is reached.</strong><br><br> <li><strong>Copy the results of the above onto a single (possibly quite large) sheet of paper, and draw circles around the concepts. This is your first draft Concept Map.</strong> </ul><br> <strong>Revising/Refining Concept Maps</strong><br><br> Good maps are like good writing; and are usually the product of several drafts and revisions. The best possible result will usually require differing perspectives and insights, so showing your map to knowledgeable others like teachers, classmates, coworkers and friends to get feedback is an excellent strategy.<br><br> <strong>Ask questions about:<br> <ul> <li>The input data <ul> <li>What are its implications? <ul> <li>Could there be other ways of looking at it? <li>Is it true in all cases? <li>How far does its usefulness extend? <li>What more do you need to find out? </ul> <li>The Concept Map itself <ul> <li>How do the parts fit together? <li>And how well/completely? <li>Does it all make sense? why? or why not? <li>Is anything: <ul> <li>Redundant? <li>Missing? <li>Unclear? <li>Illogical? <li>Questionable? </ul> <li>How does the result accord with: <ul> <li>Other available information? <li>Prior experience? <li>Published information? </ul></ul><br> If there are items that don’t fit well , ask why! </strong><br<br> Of course not all of these questions will apply to every Concept Map, but the more closely you look at the material the more and better questions will occur to you. Focus on the central/most important aspect of the situation, and if anything about it doesn’t make sense or seems unresolved, try to state explicitly where the difficulty or problem lies. This may be difficult to do, but it’s worth the effort because it will frequently highlight the route to the solution.<br><br> <strong>Identify/Collect/Sort/Sift/Synthesize/Assess/Evaluate Relevant Facts and Data</strong><br><br> <strong>Types of Information</strong><br><br> <ul> <li><strong>“Hard” Data <ul> <li>Mathematical Data <li>Scientific Data</strong><br> Objective validation of data in this category is always theoretically possible, although in practice that’s sometimes quite difficult to achieve. But, on balance, this type of data is usually the most reliable.<br> <li><strong>Statistical</strong><br> The reliability of this kind of data lies somewhere between the “hard” and “soft” because by its very nature it's somewhat imprecise and subject to interpretation. So it’s not only necessary to validate the underlying statistical methodology used to determine that it has been applied correctly (sample selection is the area most frequently performed badly), but also to validate that the conclusions reached are justified by the data. <br> <li><strong>Economic</strong><br> The reliability of this kind of data is much the same as for statistical data, and should be treated in similar fashion. </ul><br><br> <li><strong>“Soft” Data <ul> <li>Historical Data <li>Sociological Data <li>Political Data <li>Personal/interpersonal Data</strong><br> This data is the least reliable of all, since the selection of the particular facts chosen for inclusion as well as the validity of their interpretation is often highly subjective, and sometimes even actively biased. And in the extreme some of it isn’t really data at all, but mere opinion and/or speculation masquerading as fact! Distinguishing between real and pseudo data is often as much art as science, but being able to do it efficiently is crucial to your ultimate success or failure. So giving that process the attention it requires and deserves is prudent, however reluctant you may be to invest the required time and energy. </ul></ul><br><br> <strong>Information Gathering</strong><br><br> This essential step provides the factual data base upon which all of your problem solving efforts and eventual success probability will rest, so carrying it out as efficiently and completely as possible is essential. Much of it is routine and possibly even boring if the subject at issue isn’t of the greatest interest to you, so it’s important to resist the tendency to “cut corners” in its completion. It’s also important to resist the tendency to uncritically accept data that supports your preconceptions, and/or to ignore or fail to adequately consider data that you find discomforting or inconvenient. Remember the basic rule: “Garbage in - garbage out”!<br><br> <strong>The key questions to be answered are: <ul> <li>What information is needed? <li>Is it available/accessible in the form needed? <li>If it must be transformed in order to be useful, is that process feasible? <li>Can it be obtained quickly and cheaply enough to be useable for our purposes? <li>Is its reliability adequate for the current purpose? <li>Do you have the expertise to correctly/adequately utilize it? </ul></strong><br><br> If and only if all of these questions can be answered affirmatively will it make sense to proceed with information gathering.<br><br> <strong>The essential elements involved in Information Gathering are:<br><br> <ul> <li>Memory <li>Research <li>Data <ul> <li>Collection <li>Sorting/Sifting/Organization <li>Assessment <ul> <li>Perception <li>Cognition <li>Synthesis </ul> <li>Evaluation<strong> </ul></ul><br><br> Once all of the relevant data has been collected and organized, perhaps the most difficult step of all must be carried out - evaluation, or making sense of it! We begin the exploration of this key topic in the next chapter.<br><br> <strong>Click Here To Move On To</strong><a href="RDMCh4.html"><font size=+1><font Color="#0033FF"><strong> Chapter 4</strong></font></a> <br><br> <strong>Click Here To Return To</strong><a href="RDMCh2.html"><font size=+1><font Color="#0033FF"><strong> Chapter 2 </strong></font></a> <br><br> <strong>Click Here To Return To</strong><a href="RDMTOC.html"><font size=+1><font Color="#0033FF"><strong> Table Of Contents </strong></font></a> <br><br> <strong>Click Here To Return To</strong><a href="index.html"><font size=+1><font Color="#0033FF"><strong> Milt's Go Page</strong></font></a> <br> <br><br> <strong>Click Here To Email Your Comments/Suggestions To</strong><font size=+2><font color="#0033FF"><a href="mailto:bradleym@eniinternet.com?subject=Reasoning And Decision Making Comments/Suggestions"> Milton N. Bradley</font></a> </td> <td width="100"> </td> </tr> </table> </body> <!-- Mirrored from users.eniinternet.com/bradleym/RDMCh3.html by HTTrack Website Copier/3.x [XR&CO'2014], Sun, 06 Nov 2022 06:59:35 GMT --> </html>