difference between troubleshooting and problem solving

Troubleshooting Professional Magazine

[ Troubleshooters.Com | Back Issues ]

Editors Desk

Vote for your favorite troubleshooting professional, distinctions, problem solving principles, root cause analysis, theory of constraints, statistical process control, well defined system troubleshooting, generic problem solving, cars and tanks, specialized problem solving methodologies, some books for problem solving, i stand on their shoulders, linux log: linux troubleshooting distinctions, letters to the editor, how to submit an article, urls mentioned in this issue, by steve litt.

Basically, troubleshooting and problem solving are the same thing. They both relate to solving problems. The word "troubleshoot" tends to be used more for repair of well defined systems (as implied in the references to "mechanical" devices), or in human disputes. But really, according to the dictionary they're both the same thing, and can apply to well defined systems (systems with a known and documented "as designed" state and behavior), or fuzzily defined systems without a known or documented "as designed" state and behavior.

The generality in definition has led to some interesting choices and mischoices in the hiring of consultants and expert trainers, as well as the adoption of methodologies to "solve problems". The good choices have spawned success, while the mischoices have failed and been labeled "program of the month".

I'm not immune to making mischoices. Although I have, for years, steadfastly defined my brand of Troubleshooting as "The act of restoring a sub-performing system back to its as-designed state", and alternatively (as used with Bottleneck Analysis) "The act of improving the performance of a system beyond its as-designed state", several times early in my career I made the mistake of selling it to those needing to solve problems in "systems" lacking an "as designed state". You know, business problems, human relationships and organizational issues and the like.

And of course, I've seen folks sell generic problem solving courses to those who needed to "restore a sub-performing system back to its as-designed state" -- an equally bad mistake.

In both cases, desire for revenue partially accounted for such mistakes. But not entirely. The different types of problem solving, and the distinctions between them, are obvious only after considerable thought, even to experts.

This issue of Troubleshooting Professional Magazine discusses the various types of problem solving (and troubleshooting), the distinctions and the root differences between types of systems, and the problem solving methodologies optimized for those types of systems. Be sure to see the article titled Cars and Tanks , which asserts by analogy the point that although generic problem solving methods CAN be used to solve well defined problems, doing so is suboptimal.

If you're a Troubleshooter or Problem Solver of any type, this issue of TPM was made especially for you.

Steve Litt can be reached at Steve Litt's email address .

Also, we're having our first annual Troubleshooting Professional Magazine trivia contest. Simply name the issue (by year and month) and article names for the ten different articles containing the these ten phrases:  

Anyone answering all 10 correctly will be mentioned in the January 2001 issue, and if they'd like, will have an email link and an http link from the 1/2001 issue. If nobody gets all 10, the person with the most correct will get their name, and if desired email and/or http links.

Steve Litt is the author of "Rapid Learning: Secret Weapon of the Successful Technologist". He can be reached at Steve Litt's email address .

"Distinction" is more of an entity in and of itself, which is what we want for many of the explanations that follow. In many types of mental activity, the key to mastery is understanding the distinction, not just the two items being contrasted.

• Analyze the problem state.
• Analyze the solved state.

Analyzing the solved state is basically asking "how would you like things to be", followed by inductive reasoning to formulate a system that can deliver those results. Also included is design work in actually realizing the conceived solved state. Because design and inductive reasoning requires much more creativity, analyzing the solved state requires quite a bit of creativity (and therefore quite a bit of brainpower to supply that creativity). Remember this point.

Sometimes only one of these two steps is required. In fixing a machine, the solved state degenerates into "the as designed state and behavior". No analysis, induction or creativity needed. This point will be made time and again throughout this issue of Troubleshooting Professional.

Likewise, analyzing the problem state is sometimes not necessary, as pointed out by problem solving expert Fred Nickols (link in URL's section). Fred points out that sometimes it's impossible to return to the pre-problem state anyway, so analyzing the problem state is a needless exercise. As an example he points out the stock market crash of 1987, and the fact that though the crash caused many problems, the crash could not be undone.

Perhaps a more common example of irrelevant problem state occurs in problems created by progress. When the free Linux operating system acquired a power level comparable with UNIX, many UNIX vendors went out of business. The UNIX vendors were still operating as designed, but now they were in an environment hostile to that design. No amount of assigning cause would make the UNIX vendors profitable. Only a new solved state would do that.

Most advocates of general problem solving methodologies make additions to the two steps of analyzing the problem state and analyzing the solved state. Many include a step or substep that could be called "how do we get there from here?". In other words, how do we move from our present condition to the solved state? Oftentimes that requires co-worker support, management "buy in", a budget, and much, much more. It's not simple.

Another frequently added step is "how do we prevent future problems?". That can be either future occurrences of the same problem, problems caused by the solution, or even brand new problems. So a possible generic problem solving process could look like this:

• Find the root cause of the problem
• Determine the desired solution
• Decide how to implement that solution
• Head off future problems

Most experts have an extremely complex methodology for determining the desired solution. It's tough to jump-start creativity.

So we have an interesting distinction in problem solving. Some systems have a documented as-designed state and behavior -- typically machines, computerized systems and networks. The desired solution in such systems degenerates to the restoration of as-designed state and behavior. No inductive solution finding is necessary.  Several problem solving methodologies are optimized for systems with defined and documented state and behavior. Those methodologies produce ultra-fast solutions because the Troubleshooter doesn't waste his time doing steps whose purpose is to creatively determine the solved state, which in this case is already defined.

I choose to call systems with a defined and documented state and behavior "well defined systems". I choose to call systems without a defined and documented state and behavior "fuzzily defined systems". System definition is not a binary absolute, but rather a spectrum. On one end are machines designed by humans, with complete schematic diagrams. Everything about the system is known. Simple to moderately complex machines, and extremely well documented computer programs are great examples.

On the other end of the spectrum is the human mind, which is probably the most erratic, unpredictable and variable system imaginable. Any documentation of the human mind, or relationships between small number of people, is a matter statistics at best, or conjecture and anecdote at worst. When dealing with the human mind or relationships between a few people, solutions are almost completely creative in nature -- it's just too hard to deduce a "root cause". This is especially true in relationship disputes, where each party assigns causation to the other :-)

Human physiology is somewhere in the middle. It's absolutely documented and defined that a human without a liver or a heart will soon die. It's absolutely documented and defined that the organ used to see is the eyes. At the most general level, doctors and physiologists can draw a very accurate block diagram of a human. But when it gets down to details like the effect of hormones on various systems in the body, the definition goes way down, once again supported by statistics and anecdotal evidence. To the extent that human physiology is well defined, the "fix" is to restore the bad "part" to its as-designed (or in this case normal) state. At lower levels where physiology is fuzzily defined, much creativity is necessary to fix symptoms with a minimum of side effects.

Somewhere between human physiology and simple machines are complex mechanisms like computer operating systems. Although the point could be made that an operating system is completely documented by its body of source code, the fact is there's no human capable of knowing that whole body of source code. Therefore, its level of definition depends on block diagrams and other documentation. Some operating systems are more predictable and straightforward than others. UNIX and most of its workalikes (Linux included) are fairly modular, lending themselves well to rather complete documentation of state and behavior. The Windows operating system, on the other hand, is rather non-modular and unpredictable, so that at many levels it is not well defined in spite of the fact that it was built by humans and its entire body of source code exists.

Somewhere between human physiology and the human mind is the human organization. Humans are like gaseous material -- the more of them there are, the more predictable (deducible) they become. The existence of rules and policies make them even more predictable, in some cases to the point where they can be accurately modeled. Human organizations can be documented, defined and modeled when mixed with machines, technology and policies, such as in a factory. This is one of the reasons for the extraordinary success of the Theory of Constraints in the manufacturing sector.

So to solve problems, the level of definition defines whether it's necessary to analyze the problem state, the solved state.

Other Distinctions

Reproducibility/intermittence.

Within the reproducibility distinction, there's a sub-distinction consisting of whether intermittence is caused by fuzzily defined system (example: the Windows operating system), or a well defined component whose malfunction happens to vary with time, temperature, stress, distortion, etc. (a thermally intermittent transistor is an example). They are both very difficult to solve. The latter is usually soluble given sufficient time. The former often is not. They're both troubleshot approximately the same way, so this is the last we'll say about this sub distinction.

The most effective weapon against intermittence is maintenance, both preventative (proactive: before the fact) and repair-consequent (reactive: after the fact, called General Maintenance in the Universal Troubleshooting Process). Intermittence is often caused by worn, dirty or bent connections between components, rather than components themselves. Such non-component causes are harder to find by normal deductive reasoning, but they're a primary target of maintenance. Repair consequent maintenance is forbidden and extremely dangerous in safety critical situations, but preventative maintenance  is acceptable and necessary in safety critical situations.

Because maintenance is such an effective weapon against intermittence, those problem solving methodologies emphasizing maintenance are most effective against intermittence. The champion here is the Intelliworxx Era 4 troubleshooting tool, which raises repair-consequent maintenance to an artform. The Universal Troubleshooting Process also places emphasis on repair-consequent maintenance, having it as step 5 of the process (General Maintenance).

The Root Cause Analysis problem solving methodology contains a step called Barrier Analysis, which examines barriers to failure. Certainly preventative maintenance, and the policies and procedures that support it, is a major barrier. Though not specifically named in Root Cause Analysis, preventative maintenance is obviously a major part of that methodology.

As a matter of fact, intermittence seldom survives Root Cause Analysis. Besides its emphasis on preventative maintenance, Root Cause Analysis demands the finding of the true root cause. For instance, a power plant's reactor tripped because of a bad power supply board, but what was wrong with the board? The board had a bad solder joint, but why did that bad solder joint happen? The solder joint occurred from constantly elevated temperatures in the room, but why were the temperatures high? The temperatures were high because one of the room's air conditioners had conked out, but why wasn't that fact discovered before it caused damage. The fact wasn't discovered because there was no reporting procedure for temperature in the room. So ultimately, lack of a procedure to report the room's temperature tripped the reactor. Once the procedure is put in place, the air conditioner is repaired or replaced, the solder joint is resoldered, and the reactor is put back on line, it will never happen again. Well, except that my simplification forgot to follow the fault tree down the air conditioner to find why it failed, but assuming you follow that fault tree too, you can be pretty sure that failure mechanism will never occur again.

Contrast this with the repair of consumer equipment, where the solder joint itself is considered the root cause. If that stereo is returned to a hot room...

Safety Sensitivity

Most evident, the repair-consequent maintenance that speeds repair so much in non safety sensitive systems can kill in safety sensitive systems. I have no idea how nuclear defense systems work, but imagine an armed missile goes into launch sequence and fortunately is manually disarmed. Would you go in and clean all switches and controls?

Not likely. Let's say cleaning those switches and controls fixed the problem because the problem was a dirty switch. You don't know which switch. You don't know what caused it to get dirty. You never will. You just erased the evidence. Some day that switch or another one will get dirty, a missile will go into launch sequence again, and maybe, just maybe, nobody will shut it down in time. No repair-consequent maintenance is acceptable in extreme safety sensitive situations.

Another obvious difference in the treatment of safety sensitive systems is that you don't try to reproduce the problem. It would be just a little too gutsy to try, for instance,  to reproduce the missile's spontaneous launch sequence initiation, thus placing the world within a minute of nuclear war. Incidentally, this is sort of what happened at Chernobyl. The technicians wanted to investigate the system's behavior in the absence of various safety mechanisms, so they defeated those safety mechanisms.

And then there's the fact that in extreme safety sensitive systems, the term "root cause" has an entirely different meaning, as illustrated by the discussion of the power plant in the preceding section of this article. Also, in extreme safety sensitive systems, one never dismisses an apparently disappeared intermittent with "it's probably fixed". Consumer testing is wonderful for televisions, but not for jumbo jets.

Between the extremes of battery powered radios and nuclear defense systems are a wide spectrum of systems whose problem solving methodologies represent a tradeoff between the cost effectiveness and safety.

Bad car brakes can kill, but nobody would spend the thousands of dollars it would take to trace a lone event of brake failure. Instead, symptom reproduction is attempted, repair-consequent maintenance is done, and finally a non-rigorous analysis is done of likely causes, and all implicated parts are replaced. This is half way between what would be done with a battery operated radio (sorry, we can't reproduce the symptom), and a nuclear power plant (full Root Cause Analysis).

Total Failures vs. Inadequacies

• It's too slow
• There's not enough power
• The bandwidth is insufficient
• The water comes out too fast

Inadequacies don't just happen in machines and technology:

• We're over budget by 30%
• We took a loss (insufficient revenue to cover expenses)
• Our high employee turnover is a major cost
• All our shipments are late

These Distinctions Determine the Problem Solving Methodology

Using one problem solving methodology, for all categories of problems, would be like building houses using only a hammer. In this competitive world, for each type of problem solving you do, you need a problem solving methodology optimized for that category of problem.

The good news is once you've learned one, the rest are easier to learn. They all have commonalties.

Problem Solving Commonalties

• Every legitimate problem solving methodology demands that you define the problem very early. The reasons are pretty obvious.
• All methodologies demand that you work toward a goal, although in the case of methodologies optimized for well defined systems that goal degenerates into "return system to as-designed behavior and state".
• Most methodologies either explicitly or implicitly demand you prevent future occurrence of the problem.
• All methodologies demand that if it's necessary to find the root cause, it be found by deductive reasoning.
• Most methodologies demand testing of the "repair" in one form or another.
• All legitimate methodologies are based on cause and effect, especially when analyzing the problem state.
• Most methodologies incorporate ethics explicitly or implicitly.
• All methodologies demand that if it's necessary to define a solved state beyond "as designed", that creative processes be used. Many methodologies offer suggestions on creative processes. Most methodologies encourage considering solutions that deviate significantly (often radically) from "the way we've done it before".
• Well defined systems can grow into fuzzily defined systems when the environment in which they operate changes significantly. For instance, after thousands of transistor radios shorted out in the shower, somebody invented a shower radio. A well defined computer program becomes fuzzy when the humans forming the work, paper and data flow that the computer program models do fuzzily defined things.
• Degree of definition
• Degree of reproducibility
• Degree of safety sensitivity
• Is the problem a matter of degree?

In spite of the differences between systems and their associated methodologies, there are remarkable similarities between the methodologies. After learning one, it's likely that learning others will be significantly easier. That's a good thing, because it's likely the expert problem solver will need multiple methodologies because he solves multiple problem categories.

When safety concerns permit, we often ignore sparse intermittents. How many invoices come back "could not reproduce problem". But in an electric power station, to name one example, future occurrence must be prevented. And that means finding the root cause.

Root Cause Analysis is a troubleshooting process optimized specifically for sparse intermittents. Max Ammerman, formerly of Florida Power & Light, literally "wrote the book on the subject". His book is called "The Root Cause Analysis Handbook". This 135 page book is certainly not simple, but it's understandable by a person who solves problems for a living, especially if he's studied any other problem solving methodology.

In the introduction, the book describes Root Cause Analysis as using the following process:

• Significant event occurs
• Problem definition and initial data collection
• Task analysis
• Change analysis
• Control barrier analysis
• Begin the event causal factor chart
• Conduct interviews
• Determine root causes
• Recommend corrective actions
• Report conclusions

In fact, every chapter offers hints, tips, guidelines and pitfalls. He even tells you exactly how to interview a person, how to avoid "leading" him, and what to do if the person appears to be hiding something (a likelihood when interviewing someone about a serious messup). It's the little "how to" explanations that make this book so useful.

Task analysis it the act of analyzing the task related to the event. Task analysis reveals how the task should be done, as a baseline to evaluate what actually happened.

Change analysis is the comparison of the activities during or leading up to the event, contrasted with those same activities done successfully. The trick here is to ask questions leading to distinctions. These distinctions prove useful in later steps.

Control barrier analysis is the study of failed control barriers. A control barrier is anything, be it physical, policy, or anything else, that prevents problems. Either the existing control barriers are insufficient and need augmentation, or a control barrier failed to prevent the event. In the latter case, evaluate what caused the control barrier to fail. It's absolutely vital you identify all control barriers.

Event and causal factor charting is the creation of a flow chart detailing all the activities before, during, and after the event, as well as conditions, changes, control barriers. The idea is to trace the cause and effect back to the various causes, so that in a later step a root cause can be correctly identified. This step is complex, so read chapter 5 carefully.

We all think we know how to conduct interviews. Chapter 6 goes over the process with a fine tooth comb. Many times during the chapter, I thought to myself "that's a good point -- I didn't think of that". The final work product of the interview is an interview sheet and an observation sheet. These are used to reveal and to substantiate hypotheses necessary to finish the Root Cause Analysis.

Determining the root cause is where the rubber meets the road. A wrong root cause will doubtlessly create a flawed solution, at best a "coathanger" solution fixing a symptom but creating or allowing side effects. At worst it will simply not work, or make things worse. In this respect Root Cause Analysis is identical to the Universal Troubleshooting Process. Chapter 7 discusses how to put together all the info gleaned earlier to correctly deduce the root cause.

Developing corrective actions requires knowledge of the root cause, failed barriers, distinctions between functional and dysfunctional tasks, economics, company policies, government regulations, and a host of other information. In the terminology of generic problem solving, this step analyzes the solved state.

The final work product of the Root Cause Analysis is the report. It must give conclusions and recommendations, and must be presented correctly.

Root Cause Analysis is vital for sparse intermittents, and for safety critical situations where letting the problem recur or reproducing the problem is out of the question. It's an excellent tool for the diagnosis of failed processes, policies, even human interactions. When you read this book, be aware that it mentions PIC without ever defining it. PIC stands for Problem Identification & Correction, Florida Power & Light's internal name for the Root Cause Analysis process.

If you solve problems, you need to know Root Cause Analysis. Max Ammerman's book is called "The Root Cause Analysis Handbook", ISBN 0-527-76326-8. It's widely available. Get it.

Steve Litt is the content lead at Troubleshooters.Com. He can be reached at Steve Litt's email address .

Bottlenecks leave clues. Put a 40 watt, a 100 watt and a 150 watt lightbulb in series, and only the 40 watt bulb lights. The clue is that it's got most of the voltage, so it lights up. On the factory floor, the bottlenecked machine or process has a huge stack of inventory awaiting work by that machine or process. And on a long trail too narrow for people to pass, the slowest person has a huge space in front of him :-)

Sometimes the bottleneck's clues must be uncovered. In a computer, you need software to display the memory and CPU usage in order to see if either is bottlenecking your computer. Any suspected bottleneck can be tested by reducing its throughput and seeing if system throughput decreases commensurately. For instance, if you don't know whether your network is the bottleneck, slow it down either by adding traffic to it, or by decreasing its bits per second figure. If your computer programs slow commensurately, that's the bottleneck. Otherwise not. In computer programs for which you have source code, you can sometimes temporarily comment out a suspected bottleneck and see if the program speeds up significantly. Or you can add a delay to it and see if the program slows commensurately.

The theory of constraints doesn't stop with finding the bottleneck. It offers alternatives on how to "fix" the bottleneck. Of course the most straightforward way is to add capacity to the bottleneck. Buy a faster CPU. Add another drillpress and operator. Switch from 10mb to 100mb Ethernet. Get a faster modem. Hire more salesmen.

Adding capacity to the bottleneck can be a great solution. But it's often expensive, especially in cases like the microprocessor where you need to replace, rather than add to, the resource. Luckily there are other ways to "fix" a bottleneck. One of the easiest is to make sure the bottleneck is running full blast all the time. If it's a machine in a factory, make sure it runs three shifts, make sure its operator does nothing but run that machine, and make sure upstream machines supply it with parts as needed, with an adequate stockpile so it can continue through those inevitable variations that crop up. In an audio amplifier, make sure the power supply runs full blast all the time by putting huge capacitors across the DC so that when the music is soft, the power supply goes full blast charging that capacitor, which is then discharged when loud music sucks out more electricity than the power supply can produce.

OK, so it's running full blast and it's still not enough. Often you can offload some of the bottleneck's work to a non-bottleneck. If you read "The Goal" by Eliyahu M. Goldratt and Jeff Cox, you know you can get a fast guy to carry all of Herbie's (the slowest guy on the march) equipment.  You can get a less efficient machine to process the parts instead of the bottleneck, or even outsource the processing. Sure, it's expensive, but remember, the increased expense is only for that one process, but because it's the bottleneck, the one-process investment increases throughput for the entire system. Perhaps the coolest example of offloading is cache memory in a computer. Dynamic memory, the only kind cheap enough to use in quantity in computers, is unacceptably slow. It's the bottleneck. So computer designers long ago learned to offload most of the dynamic memory's work to the CPU, which must synchronize dynamic memory's contents with a small, fast and expensive static ram Cache memory. For each memory access, the CPU decides where to go for it, and if the accessed memory is not in cache, places it there, getting rid of what the CPU calculates is the most dormant data in the cache.

Whew, that CPU has to work. But because it's not the bottleneck, by definition it has excess capacity available. The result of memory caching is that up to 90% of the time, the CPU doesn't need to go through the slow process of requisitioning data from dynamic RAM. On Windows computers, you can have the CPU offload some work from the hard disk. Obviously disk cache does that, but in Windows there's a subtler way. If you have a fast processor (or a slow disk) you can speed system throughput by using disk compression. Sure, the CPU must work overtime compressing and uncompressing those files, but the resulting disk reads and writes are smaller. Given that disk access could be 100 times slower than memory access, those smaller reads and writes increase system throughputs. So unless your CPU is already close to overworked, disk compression speeds system performance.

Sometimes the bottleneck busies itself doing unnecessary work. In a factory, maybe some of the parts put in the oven don't really need the heat treatment. Or maybe, because there isn't an inspection station right before the bottleneck, bad parts are going into the bottleneck, displacing potential good parts. Or maybe downstream people and processes are ruining parts that came out of the bottleneck. All these sources of unnecessary work can be corrected.

The theory of constraints tells us there are many ways to "fix" a bottleneck. But so far what I've described is just bottleneck analysis on steroids. The theory of constraints goes much farther. As an introduction, let's discuss the difference between compressible and incompressible systems.

Compressible and Incompressible Systems

That's similar to a factory. Each machine has room for a stockpile in front of it. Each stockpile is like a capacitor. It can grow and shrink. And in a factory, you can always increase the stockpile potential by adding space, or even warehouse space. It's like adding capacitors while a circuit is running. Another difference between a factory and a circuit is that machines are not like resistors. A resistor conducts more as the pressure on it increases. Not so a machine. A machine either runs at its rated throughput, or if it runs out of incoming parts, less. But having a huge stockpile does not increase the throughput of the machine. So electronically, a factory machine would be modeled as a constant current source, not as a resistor.

The final difference between the factory and the circuit is one of degree. Stockpiles resemble 100 kilo farad capacitors in a 1 amp circuit -- they can take a month or more to "fill up".

And they exhibit little or no loss during the month. That's very hard for an electronics person to wrap his mind around. But that's what it would take to model a factory. From here on we'll discuss the factory in factory terms.

Released raw materials are "pushed" into the system, after which each machine "pushes" materials to the next. In a factory, order counts. Everything upstream of the bottleneck can be functioning at breakneck speed, while everything downstream of the bottleneck is starved. Order becomes more significant when combined with the deadly duo of dependent events (cascaded stages in a process) and statistical fluctuation (variation).

Take two machines, with the faster machine four times the throughput of the slower. If the slower machine feeds the faster machine and the faster machine goes down for an hour, there is no lost production. The slow machine simply builds a stockpile for the fast machine. When the fast machine comes back on line, it makes quick work of that stockpile because it's four times faster than the slow machine.

Now reverse the machines. The fast machine feeds the slow one, and the fast one once again breaks down for an hour. Let's say that after 1/4 hour the slow machine finishes its stockpile of incoming parts. Now it has to wait for more parts from the fast machine. Now there's lost production in the amount of 3/4 of the slow machine's hourly throughput. Remember, the slow machine can't "catch up" the way the fast one can. The only way to have prevented that was to keep a continuous stockpile in front of the slow machine equal to the worst case downtime throughput of the fast machine.

This isn't especially impressive with just two machines. But if a factory were unfortunate enough to be cascaded with machines sorted fastest to slowest from upstream to downstream, the requisite stockpiles in front of each machine would be enormous. Those stockpiles represent money spent but not recovered from customers. They represent potential obsolescence. They represent a mess making it harder to work in the factory. They represent storage costs. They can drive you to the poorhouse.

On the other hand, a factory fortunate enough to have the slowest machine at the beginning would require no stockpiles. Every other machine could "catch up" to the slowest machine's pace if something in front of it went down.

But the bottleneck is seldom at the front. So the theory of constraints presents methods of calculating material release so that the bottleneck always has a stockpile of incoming parts.

It gets even more complex. Typically the bottleneck machine will process several different types of parts. The different parts are destined to go into finished products in different customer orders, each of which must be delivered on time. How do machines upstream schedule delivery of appropriate parts to the bottleneck such that those parts contribute to ontime delivery. Remember, the bottleneck must run continuously at full speed. Among other things, that means minimal parts changes (each parts change requires a setup). In other words, for a given incoming part, process all of that part in the incoming stockpile. Or at least enough to satisfy all current orders.

In the name of (false) efficiency, some folks extend the "long run" philosophy to non-bottlenecks. The result is that the bottleneck is starved for certain needed parts, because the upstream processes are creating excessive numbers of a different part. So one order ships late, and excessive inventory in the long run part are developed.

The trick is to use shorter runs on the non-bottleneck machines. After all, by definition they have excess capacity, so they can afford to be idled by extra setups. Meanwhile, the shorter runs on non-bottlenecks means a more even parts distribution arrives at the incoming stockpile of the bottleneck, so it can fulfill orders.

But wait, there's more. As taught in the Universal Troubleshooting Course, bottleneck analysis is all about speeding up bottlenecks, which are considered bad. But in the Theory of Constraints, bottlenecks can be useful. Think of your car. It would continuously go 120mph if you didn't have a bottleneck called "the accelerator" to slow system throughput (via fuel delivery). The theory of constraints endeavors to minimize stockpiles by calculating the release of raw materials at a time such that they will arrive (as part of finished goods) at the shipping dock just in time for ontime delivery to the customer. They USE the bottleneck to calculate the time from parts release to shipping dock, and can even use it to calculate parts orders and promise dates to their customers. It's the bottleneck that allows them to accurately calculate these things.

Trickier still, there are situations in which throughput is significantly slower than the bottleneck. The classic example is the fixed speed streaming tape drive, which must be supplied with sufficient data to fill the tape passing the tape head. If the streamer moves faster than the data supply feeding it, many streaming tape drives cannot simply stop. There's a finite time until they've stopped, after which they must reverse and re-cue before recording more data. Depending on the mismatch between the tape and the data flow into it, this constant "shoe shining" could cut the theoretical capacity of the bottleneck by several fold. In fact, such inefficiencies happen in any system where a component has speed and inertia. An assembly line comes to mind. If the line is sped up beyond the capacity of a specific nut tightener to tighten his assigned nut, he must either skip certain units and put them aside, pass them on creating rework down the line, stop the line, or some equally counterproductive action. True assembly lines, as opposed to cascades of stations with stockpiles, react very badly to oversupply of incoming material.

So you've eliminated some bottlenecks, eliminated excessive supply to the existing bottlenecks, and exploited bottlenecks to schedule orders. Now you're running a phenomenally smooth factory. But as you continue to further enable the bottleneck, there comes a time when you seem to have many roving bottlenecks, even though calculations indicate that these roving bottlenecks have more than enough capacity to supply the bottleneck, and indeed the order flow.

Here's what's happening. As the bottleneck approaches the throughput of certain other machines, those machines are no longer able to "catch up" when inevitable upstream variations deplete their stockpiles. So they don't move needed parts to the bottleneck in time, and there's lost production. Basically, everything's running too close to "the edge". The solution is to release parts early enough to maintain non-bottleneck stockpiles big enough to cover any expected upstream downtime.

And of course, if the bottleneck's throughput continues to be improved, you reach a point where another machine becomes the bottleneck. It's very important to recognize that change, and continue your calculations using the new bottleneck. And remember, sales can be the bottleneck (meaning the factory as a whole has excess capacity). That's the time to acquire new customers and get more orders from the old by promising the delivery times that your excess capacity can provide.

Whew! Quite an explanation, and it barely scratched the surface. Luckily, Eliyahu Goldratt and Jeff Cox have written a book on the Theory of Constraints called "The Goal" (ISBN 0-88427-061-0). I've read it probably once a year for the past 5 years, and it's my favorite book. The Goal has a "can't put it down" plot, in which characters we can all recognize (some we can identify with, and some we recognize as enemies) blunder through life slowly learning the lessons of the Theory of Constraints. By the end of the book they're Ninjas, and the reader has learned right along with them. There are good guys, bad guys, good guys who are forced to be adversarial by circumstance, love and plenty of conflict. I'm a Stephen King fan, and I can tell you that "The Goal" is every bit as exciting as the best of King's books.

But by far the most memorable parts of the book are the ingenious analogies Goldratt and Cox use to demonstrate the complexities of factory logistics. One, a boy scout hike, uses a boy named "Herbie" as a metaphor for a bottleneck. Every time someone slows down in front of him, he has to stop, but when the faster boy in front of him sprints to close up his own gap, Herbie can't catch up, so he falls ever more behind, opening a huge gap in the line. Putting Herbie at the front eliminates all gaps, and allows the group to progress at Herbie's maximum speed. They then offload work from Herbie the bottleneck by carrying the heavy stuff in his backpack, and the whole line sped up. "Herbie" probably has more name recognition than many state governors.

The second well known analogy from the book is "the match game". It's a game invented by the hero to model the effects of the combination of dependent events (cascaded steps in a process) and statistical fluctuation (variation). By the time you're done with the book, you can do more than understand the principles. You can do more than recite the principles. You can FEEL the principles. And if your experience is like mine, every time you read the book you obtain a greater level of understanding and feeling.

I recommend that everyone who ever solves any kind of problem (and who isn't included in that definition) read this book. At $20.00 for the book and maybe 10 hours to read it, the learning to investment ratio is right off the charts.

Steve Litt is a Theory of Constraints true believer, as well as a bottleneck analysis expert. He can be reached at Steve Litt's email address .

It won't work, of course. And the main problem won't be the ensuing morale problems, or even turnover. The problem is that very few of the fired employees contributed to the root cause of the company's problems. Very few of them contributed to the company's bottleneck. Sadder, some of the fired employees might be among the company's best. How can that be?

Everything has variation. Some of the variation has a cause, and some is statistically insignificant "random noise". With extreme amounts of employee variation, all the variation could be random noise. In other words, the worst guy this year could be the best guy next year, in spite of the fact that nobody changed what they were doing.

The process of assigning causation through statistical analysis is called Statistical Process Control (SPC). This was W. Edwards Deming's starting point. It's an extremely powerful tool. SPC isn't used only to evaluated the performance of people. It can evaluate anything that can be expressed numerically. Basically, when any given "thing" falls outside of the UCL/LCL borders, it should be investigated and either fixed or propagated, as appropriate. Notice that this bestows the opportunity to answer the question "why was this month so good" (of course after determining that the months figures were above the UCL). That answer can then be used to make permanent improvements.

So SPC first alerts us to problems, and then gives us some tools to diagnose those problems. Note that at any point in the investigation we can move from SPC to a diagnostic process like the Universal Troubleshooting Process, Jim Roach's Diagnosis, the Six Step Loop, Root Cause Analysis, or Theory of Constraints, to finish getting down to the root cause.

SPC is deeply rooted in the quality movement. One hallmark of "quality" is the reduction of variation. As variation decreases, the UCL and LCL approach each other. In the case of the people in the preceding cartoon, the reduction of variation would come not from hiring new people, but from creating a system that allows them more consistent (and hopefully higher) production. This would be equally true if the preceding control chart were ball bearing diameters instead of human performance.

In the vernacular of SPC, anything outside the UCL/LCL limits warrants investigation and is called an "assignable cause", or sometimes a "special cause". Anything within those limits is termed a "chance cause", a variation born of random noise needing no investigation. If one wants to reduce the variation or raise the numbers en-masse, the system common to all the numbers must be investigated.

There are many books on the subject. The book I own is called "Understanding Statistical Process Control by Donald J. Wheeler and David S. Chambers. This book contains all the equations you need to calculate the UCL and LCL, as well as the math to diagnose numerous problems that can be evaluated statistically. As is obvious from this article, I haven't even scratched the surface of the information contained in this book.

Steve Litt has presented at several ASQC meetings, on the topic of Troubleshooting. He can be reached at Steve Litt's email address .

Universal troubleshooting process.

• Get the Attitude
• Get a complete and accurate symptom description
• Make damage control plan
• Reproduce the symptom
• Do the appropriate general maintenance
• Narrow it down to the root cause
• Repair or replace the defective component
• Take pride in your solution
• Prevent future occurrence of this problem

It's the only technology Troubleshooting process I know of that addresses the mental outlook of the Troubleshooter, instead of considering him or her a perfectly rational robot.

Jack Ganssle's Looping 6 Step Process

• Observe the behavior to find the apparent bug.
• Observe collateral behavior to gain as much information.
• Round up the usual suspects.
• Generate a hypothesis.
• Generate an experiment to test the hypothesis.
• Fix the bug.

To really understand the beauty of Jack's methodology, you need to visit his Troubleshooting web page (in the URL's section of this magazine). Throughout the explanation of his method runs a message of "be careful, trust nothing". Obviously, an in-process (and therefore incomplete) design is buggy, and may not behave as expected. There could be double and triple root causes, and the system may not be designed as you think it is.

If you're in the middle of creating an electronic design, use Jack's methodology. Although I personally use the UTP in troubleshooting software under design, it's very possible that Jack's would be better optimized for that. Basically, when designing anything, make sure you're familiar with Jack's 6 step loop.

Era 4 Troubleshooting Systems from Intelliworxx

I met Jim when he emailed me in 1996, wanting some advice on placing a Troubleshooting Process in an automated diagnostic system. At the time he was a highly placed training executive in GM. If it had been anyone else I would have chalked it up to "another expert system marketed to replace a human Troubleshooter". But Jim knew his stuff, and it was obvious he understood Troubleshooting Process through and through. So we talked frequently throughout 1996 and the first half of 1997.

But I really didn't understand the finished product. I'd heard so much about it, but didn't understand what the finished product would be like. Until 1999, when I tried it in at a conference. It was incredibly easy to use. Jim Roach gave several demos where people used it to find bugs (intentional malfunctions) placed in a Cadillac.

This Troubleshooting Process is highly optimized for situations in which the vendor has provided voluminous service documentation, including quickchecks, error code documentation, predefined diagnostics and the like. The process starts out with symptom acquisition and reproduction. Next what would be called General Maintenance in the UTP, including tech bulletins, diagnostic codes, and the like. This is followed possibly by a divide and conquer session, guided to the extent possible by existing predefined diagnostics. The final step is repair and testing.

So far it sounds like the Universal Troubleshooting Process. But if you look at the details, the Intelliworxx model assumes that most problems will be solved with the help of existing documentation, and that the Troubleshooter won't need to devise his own diagnostic tests. Given the volume of system information in the smart manual, for the first time this becomes a viable assumption. Indeed, combined with a smart manual on a voice actuated, ruggedized hands-free computer, the Troubleshooter has instant, just in time access to exactly the necessary information. At every stage of the game, the first priority is to look at existing documentation. That documentation is a smart manual (or as Intelliworxx would call it, a mentoring application). Only when all documentation has been delivered to the Troubleshooter, without a solution being found, does the Troubleshooter go "offroad", creating and testing his own hypotheses. At that point, the well equipped Troubleshooter would know the Universal Troubleshooting Process, which is optimized for those times when relevant system documentation is not available.

Authoring such a smart manual is costly, but so is a truly detailed paper manual. This Troubleshooting Process enhanced, voice actuated, hands free smart manual, is the first tool integrating effective, low cost information lookup with Troubleshooting Process. For the first time it's quicker to follow predefined diagnostics than to create your own. In industries providing detailed, accurate and timely system information (the automotive industry is a perfect example), it can multiply productivity.

Contrast this with an industry like proprietary computer equipment and software, where documentation is incomplete and scattered. In software diagnosis, if you haven't found the info in 10 minutes you're probably better off diagnosing it yourself. We software guys can only dream how fast Troubleshooting could be if we had instant, as needed access to all accumulated knowledge of the machine or system.

A link to the Intelliworxx website appears in the URL's section of this magazine.

Steve Litt is the author of "Troubleshooting: Tools, Tips and Techniques". He can be reached at Steve Litt's email address .

There was a time I answered that question affirmatively. Not that I ever successfully used it to solve an interpersonal relationship, but problems are problems, right?". I actually made the mistake of using relationship problems as examples in some courses. Sometimes it worked, and sometimes it bombed very badly.

Eventually I backed off my claim of being able to solve relationships, guaranteeing only to solve problems in "well defined systems". But I still didn't know why the Universal Troubleshooting Process didn't work on fuzzily defined systems.

To figure that out, I had to learn about the anatomy of a problem. You see, a well defined system problem is a subset of generic problems. A well defined system comes with two additional pieces of information for the Troubleshooter:

• Complete definition of system components and their relationships
• An as-designed state and behavior

But the as-designed state and behavior is a vital distinction. Here's why...

The most basic definition of problem solving is the following 2 step process:

• Analyze the problem state
• Analyze the solved state

They both work 75 hours a day, and have responsibilities for their son and his activities. This obviously leaves no time. Should they:

• One quits his or her job, and adjust their budget and living accommodations to the lesser income.
• Both demand their companies respect their time, cutting their workload to 50 hours/week, and take the chance of getting fired, laid off or passed over for a promotion.
• One or both get new jobs that take less time, and take the chance of an interruption of income.
• Surround Junior with tutors and sitters to give them more time.
• Take a second mortgage out on their house, and start a business together.

Generic problem solving methodologies are equipped to address both the problem state and the solved state. The Universal Troubleshooting Process is not a generic problem solving methodology, and therefore is sufficient only in the subset of problems in which the solved state is "restore to the as-designed state and behavior". So why would anyone use the Universal Troubleshooting Process, when generic processes handle all problems?

Simply stated, tools meant to design and to weigh alternatives are wasteful in problems where the solved state degenerates to "the as-designed state and behavior". This issue has an article called Cars and Tanks that discusses just how wasteful this can be.

So the purpose of this article so far has been to show that generic problem solving methodologies and problem solving methodologies optimized for well defined systems are neither interchangeable, nor viable substitutes for each other.

The previously listed two step representation of generic problem solving actually leaves out a couple things. A more realistic generic problem solving process would look like this:

• Determine how to transition to the solved state
• Prevent future problems

There are different kinds of future problems to prevent. One is a recurrence of this same problem. That's achieved primarily by the problem state analysis. Then there's the creation of different problems. This is an area for study in the solved state analysis.

Creativity Jump Starts

Many of us think most creatively when exercising. I've designed many a computer program while skateboarding, bike riding, or walking through the woods.

The Universal Troubleshooting Process's Troubleshooter's mantra, "How can I narrow this down just one more time?" can easily be adapted to creativity jump starting. There are other questions that can jump start creativity:

• How can I use this (perceived problem) to my advantage?
• Does the task or process even need to be done at all? Why? Can I eliminate part of it?
• How can I simplify?
• What are the priorities? Why?
• Whose help would be valuable in thinking this through?
• Can I think of similar problems or situations?
• Who has solved a problem like this before? What did they do?
• What are the ethical considerations?
• Who has a stake in the direction of the decision? Why? Have I talked to them?
• How can I reduce antagonism in the decision making process?
• Construct questions with words who, what, where, when, why, how and how much.
• Construct questions with phrases "what is" and "what isn't".

Methodology Availability

If you're lucky enough to be in a company whose budget allows you receive generic problem solving training from a vendor, do it. If not, I'd suggest a thorough reading the web material of Dr. Charles Camp and Fred Fred Nickols. Both are excellent, and the URLs are in the URL's section of this magazine.

And a word of warning. One day a generic problem solving vendor may try to sell you generic problem solving training for your technologists, even though the technologists primary troubleshooting is technical (restoring well defined systems back to their as designed state). These vendors may even offer to train you to be a trainer in their methodology, with the obvious resume benefits.

Sounds great, but be very careful. Because when it comes to fixing well defined systems, if your organization uses a generic problem solving methodology and your competitor uses something like the Universal Troubleshooting Process, they'll clean your clock.

Read the next article.

Imagine driving to work in a M1A1 Main Battle Tank, also called an Abrams tank. It has tracks instead of wheels, and it can go absolutely anywhere. It can roll over obstacles 42 inches high. It can cross trenches 9 feet wide. It can go up a 60 degree slope. And due to its almost impenetrable armor, its 120mm main gun, and three auxiliary machine guns, it can traverse the most hostile environments. An M1A1 main battle tank can go almost anywhere on land, including the freeway. So why use a car to go to work, when cars accommodate only a small subset of terrains?

One reason is that the M1A1 gets less than 1 mile per gallon of gas. Working only 10 miles from home, you'd pay $150/week in fuel alone. On those rare occasions when the freeway travels full speed, the M1A1's 45 mph maximum speed is a liability. At a length of 32 feet, one inch, a height of 9.5 feet, and a width of 9.5 feet, parking is a problem.

There's no doubt the M1A1 can get you to work. But your friends driving Chevy Luminas get there faster, cheaper and more conveniently. Yes, the M1A1 can go anywhere, but that ability is costly indeed.

Reminds me of companies selling general problem solving training to those requiring electronic, mechanical or computer Troubleshooting.

Mechanical, electronic and computer troubleshooting is a subset of problem solving. Machines and automated systems are well defined systems . By that I mean they have a documented and well defined state and behavior. Fixing them requires only returning them to their as-designed state and behavior . You needn't analyze the solved state, with its heavy design and creative thinking requirements. You needn't ask how you want the machine to perform after repair -- you already know that. It must perform as designed. You needn't ask if there's some better way you can do it. All that's necessary is to get it back to its as-designed state and behavior.

Some training vendors are all too happy to sell you a generic problem solving course for your technical people to use on machine/computer/software problems. Such generic problem solving methodologies contain several time consuming steps necessary only to design the solved state (which degenerates into the as designed state and behavior for machine, computer and software problems). The vendor might justify this by mentioning that the generic problem solving methodology can solve all problems, including those of machines, computers and software. They're telling the truth, and it's about as practical as trading in your car for an Abrams tank.

If you want to win, you go to war in a tank and the office in a car. If you want to win, you fix technical problems with a Troubleshooting Process optimized for technical problems, and fuzzily defined problems with a generic problem solving methodology. If a person solves both types of problems, train him in both methodologies.

So the question you need to ask is this: How would it affect my business if my competitors used more optimized Troubleshooting methodologies than my company?

Steve Litt presents and licenses courses on troubleshooting well defined systems, and well defined systems only. He can be reached at Steve Litt's email address .

Human-centric problem solving methodologies.

Except for the Universal Troubleshooting Process. The UTP's Step 1 (Get the Attitude) and Step 9 (Take Pride) are inward focused.

Outside of Star Trek and Isaac Asimov novels, I've never met a Troubleshooting robot. What I have met are technicians angered to the point of throwing equipment across the room, and computer managers panicked to the point of paralysis. Frequent failure results from methodologies that doesn't at least consider the person doing the fixing. None of us is a robot, and if we haven't learned to control our emotions, those emotions can wash away all logic.

But the Universal Troubleshooting Process isn't human-centric. Only two of the ten steps are. The majority is procedural. In machine/technology repair, all you need to achieve is the as-designed state and behavior. Contrastingly, many methodologies are almost entirely focused on the person doing the problem solving. I call them human-centric methodologies.

And that's exactly what's needed when the system under repair is the problem solver himself. In such cases, the problem solver is troubleshooting himself, surrounded by an environment for which he has limited control. Personal problems are typically triggered (I didn't say caused, I said triggered) by either changes in the environment around the person, or a "bad break".

Note: Such "self help" can be propagated by trainers training others in these methodologies. They can even be extrapolated to solution by consultants using human-centric principles to fix business problems, but this runs the risk of the "program of the month" label if not done in a way that respects employees' intelligence, time and motivation.

• It's incredibly difficult for a person to know what he or she wants (identify the solved state).
• By definition it's impossible to retain what the UTP calls "The Attitude", because without panic, fear, depression or anger there wouldn't be a personal problem in the first place.
• There is no clear documentation on how the human mind works, leaving the door open for numerous conflicting philosophies, religions and personalities to declare themselves "the one true way".
• A good methodology doesn't insult the intelligence of the reader.
• A good methodology doesn't insult the intentions of the reader.
• A good methodology is easy enough to follow that it will show some results even when tried by a skeptical reader.

When it comes to insulting the intentions of the reader (or in this case listener), certainly radio's pop-psychologists corner the market. The listener calls in with a serious and complex problem, and the first thing the radio guy does is paints the listener as weak, stupid and unethical. Yeah, that's real productive!

A problem solving methodology is effective only if followed. It is followed by a reader only if the investment is justified by the expected return. The average reader has been unsuccessful with some human-centric methodologies in the past, and is thus skeptical, meaning the expected return is uncertain. Therefore, the book expounding an overly complex or demanding methodology is read but not followed. The methodology offering a quick and easy route to small benefits, followed by a staircase of additional investments with additional gains, is followed.

There are effective methods of "putting across" complex and difficult methodologies. One method is charging a lot of money, so it makes it worth the student's while to devote a month to learning and practicing the methodology. This is accompanied by live lectures, one on one consultation, tapes and exercises. This will work with methods that, once fully learned, are truly beneficial. But it requires extraordinary faith in the program. And unfortunately, some are in it just for the money. As the old saying goes, once bitten twice shy.

Another component of benefiting even the skeptical reader is use of plain language. Methodologies defining their own terms, and especially those engaging in psychobabble, are much less credible to the intelligent person.

Purveyors of human-centric methodologies would be wise to study the merits of the Universal Troubleshooting Process, which itself is not human-centric. The UTP requires very little buy-in -- merely hanging the list of steps on your wall produces improvement. A single day of studying step 6 produces another vast improvement. And as the reader gains confidence, there's a continuing stepwise route to study and improvement. And the reader can pretty much determine the order and pace of the steps.

The documentation of the Universal Troubleshooting Process is devoid of jargon. Extra effort has been taken to use plain language to define and discuss its concepts.

Human-centric problem solving methodologies are optimized to solve personal problems, but they can be helpful solving other problems. Consider that many highly paid technical Troubleshooters are limited by their emotions, especially in the face of extremely difficult problems. All other things being equal, including training in technical Troubleshooting Process, the technical Troubleshooter who has mastered an effective human-centric problem solving methodology will be more effective solving technical problems.

There are many outstanding human-centric methodologies out there. Following are discussions of these human-centric methodologies:

The 7 Habits of Highly Effective People

Schuller's "tough times never last, but tough people do", affirmations, psycho cybernetics.

• Be Proactive
• Begin with the End in Mind
• Put First things First
• Think Win/Win
• Seek First to Understand... Then to be Understood
• Sharpen the Saw

#3 deals with use of time and prioritization. If you're a regular reader of Troubleshooting Professional, you know I believe in easiest-first prioritization. But that's WITHIN the prioritization methodology Covey discusses in #3:  

Blow off unimportant tasks. If a task doesn't help you reach your goal, and not doing it won't prevent you from reaching your goal, don't do it. Now of course, somebody else might consider it urgent that you do unimportant tasks. Try to work it out so you're not required to do them, because they're a waste of time. Or figure out a way to make them important in reaching your goal.

Note the similarity here to my admonition not to troubleshoot unprofitable work. This is discussed in the August 2000 issue of Troubleshooting Professional.

One might instinctively think important and urgent tasks are where we should spend our time. But in fact, that's not true. Tasks always take longer when they're urgent. Urgent tasks spawn the need for explanations, written reports and meetings. Many individuals you work with react to urgency with anger or panic, both of which lead to costly mistakes. And of course, if you go over the deadline and don't sell the product or get something to market, that's extremely costly.

So the object is to have all the important stuff done before it gets urgent, which is why once you've gotten your fires put out, spend all possible time on important tasks that are not yet urgent, and make every effort to prevent important tasks from becoming urgent.

Covey explains that the first three habits are done in isolation -- you don't need to collaborate to accomplish them. The next three are collaborative.

Thinking Win/Win usually promotes success, depending on the definition of success. We all have seen enough of the world to know it's not an absolute prerequisite for success. We all know of companies succeeding through playing dirty tricks on their competitors rather than making good product. But in the vast majority of cases, the win/lose crowd finally become losers themselves, either because the ethical emptiness of their lives leads to substance abuse or other problems, or because they run afoul of the law. Or both. The intelligent person knows that sometimes each of us must "go to war", but generally speaking, Win/Win is the best policy.

Most sales books I've read have a paraphrase of habit 5, "Seek First to Understand... Then to be Understood". Sales books typically mention you have 2 ears and one mouth, and to use them in proportion. In a technical Troubleshooting scenario, you'd never attempt a fix before knowing the root cause -- you need to understand first.  But understanding is not always so easy. Psychology 101 teaches us there's a principle that most people attribute their own actions to their situation, but they attribute the the actions of others to the others' personalities. I drive 80 mph on the freeway because I'm late to my wedding. The guy in the red car drives 80mph because he's reckless. One cannot really deal with others until one understands their situation. You need to walk a mile in the other guys shoes.

Covey's habit #6 is "Synergize". Work with a group in such a way that the whole becomes greater than the sum of the parts. I've found that if you put 10 people in a room they can accomplish just about anything, because there's almost no piece of knowledge not possessed by at least one. If the people practice the first 5 habits, #6 can be correctly accomplished. Once one can work synergistically with a group, he or she can accomplish amazing things. So what's left? Why is there a habit #7? For exactly the same reason there's a step 9 (Take Pride) in the Universal Troubleshooting Process.

Consider this: If you saw wood for a living, you'd surely sharpen your saw when it got dull. Otherwise, your productivity would plunge. Sharpening the saw is Covey's 7th habit.

People get dull after protracted periods of hard and effective work. They must be sharpened. Covey lists four categories of such sharpening -- physical (exercise, nutrition, sleep), mental, spiritual, and social/emotional. I'd like to add a fifth -- savoring triumph, which definitely encompasses mental and social/emotional. If done during a walk, skating, bike ride etc., it encompasses the physical. And you know what? I've had cases where savoring triumph approached a spiritual activity.

Covey's 7 habits are my favorite human-centric problem solving methodology. It's common sense, without inordinate amounts of early 90's mission statement pabulum. And it's so simple that an average individual can read the book and begin to put it into practice. One thing I really like about the 7 habits is they avoid the "believe in it, and it will come" trap, instead portraying faith as one necessity among many.

Schuller wrote this book to help the fearful and hopeless in that dreadful year. Above all, this book is exquisitely inspirational. Read just the first chapter to see how Schuller weaves the present (in 1982) economic disaster with his own hard and poor childhood, working back forward to the present, ending with what all but the most hardcore Atheist would call a gift from God. Even the Atheist would call it a 9.2 on the Richter scale of lucky breaks. Armed with the "anything is possible" feeling the first chapter bestows, Schuller lays down several sound principles, tips and techniques for snatching victory from the jaws of defeat.

Schuller gives some great marketing advice. His "how do you catch a marlin" discussion details the need for access to a market for your product. His "possibility thinking" discussion with its 10 alternative method is the self-help equivalent of "how can I narrow it down just one more time?" question in technology Troubleshooting.

In every chapter, Schuller has lists to be followed, and examples of people succeeding by following those lists.

This book is a must-read for anyone facing seemingly insoluble problems. After all, it was written for just such an audience.

The basic idea is that you're effective when you're in a good and creative mental state. Rather than waiting for external events to put you in that state, you can put yourself in that state and then reap the benefits. As Abraham Lincoln said, "a man is just about as happy as he decides to be". Of course, I understand Lincoln had a problem with depression :-)

I believe that the NLP techniques I've read in Anthony Robbins' books "Awaken the Giant Within" and "Unlimited Power" are excellent personal problem solving techniques that cannot be learned by skeptics, or even the unconvinced. They require a huge commitment, maybe a month or more, to practice and master the techniques. I see no "low hanging fruit" that can boost results in a day or two. Robbins includes many real-life exercises you need to do. If you don't do them, you'll get little from the books.

If you believe your problems can be helped by a better life outlook or a better use of your mental resources, and you're willing to invest a lot of time, I'd highly recommend getting these books, and taking the significant time it takes to work through and master their exercises. I cannot recommend these books, or the methods they espouse, to those unwilling to make a substantial commitment to mastering their techniques.  

Note: There's a Tony Robbins book called "Notes from a Friend: A Quick and Simple Guide to Taking Control of Your Life". It's based on "Awaken the Giant Within" and "Unlimited Power". It may be a way to ease yourself into these techniques without big time prior commitment.

To solve this type of problem, Keith Ellis recommends, in his article titled "Affirmations", saying something like this:

"I choose to joyfully become a great Troubleshooter."

Once again, this solves only problems whose root cause is attitude. But it's powerful, because a single destructive attitude leads to tunnel vision. If your goal requires $100,000 to start, and you've got only $859 in the bank, it's just possible that an affirmation like this could break the conflict:

I choose to joyfully find inexpensive ways to quickly reach my stated goal.

Sales Optmized Problem Solving Methodologies

Attention, interest, desire and action.

The attention and interest steps are done during prospecting, with desire split between prospecting and sales calls. Conviction and action are done during an actual face to face meeting (usually). This meshes very nicely with the sales funnel, described later in this article.

Steve Litt's Access to a Market for your Product

After reading many books, and observing the successes and failures of myself and others, I've reached the conclusion that sales and marketing boil down to having Access to a Market for your Product . It's the matchup of Access, Market and Product that IMHO is a prerequisite for good sales. You don't sell your acting skills in Wisconsin or your farming skills in Los Angeles. Because access is hardest to obtain, choice of new products should always favor the markets to whom you already have access . You can slowly grow the boundaries of your market access area, but don't make a product outside it.

Some people think they don't have access to any market. Not true. All one needs to do is look around at his friends. That's access. What kinds of people does one get along with well. Some of us get along with the upper crust, and some of us have friends in low places. We sell to the people we get along with.

Almost everyone gets requests for advice and help. Many of these requests are for favors that don't involve money, but make no mistake, if people are asking you for advice and help, you have something to offer. The trick is to expand your access outside your immediate group, because it's often hard to charge a fee to friends. Sometimes you can even sell your knowledge in the form of books.

Before you go out and base your entire sales strategy on my ideas, keep in mind that I'm just a middle class guy, and with my products, if I were a great salesman I'd be a multi-millionaire. But I think once I get the execution down correctly...

The Walter Litt Three Base Approach

Gain access, make it easy to buy, bury the cost in the big picture.

He also concentrated on getting more business from other departments in businesses he sold to. For instance, he was in the Sears Tower so much that he was able to expand from labels to tags, selling them to many different departments.

Nope, he just made sure his quality was as good as the Japanese, and then buried the extra cost in the cost of the entire item. A $40.00 dress has a single label. A Japanese one might cost a penny, the American one two cents. That penny difference is 0.025% of the sales price. It's negligible, and Dad approached it that way. It was much easier to buy from him, and the cost was 0.025% of the dress. It's a no brainer.

It could be said that burying the cost in the big picture is practical only with very cheap items. But in fact it's simply easier to explain and understand with cheap items. If you program computers and charge $20.00 more per hour than the competition, but you can better demonstrate that you're likely to do it right, you're easy to buy from. Now multiply the $20.00 differential by 2500 hours for a one year project making a cost differential of $50,000. Now total the hardware and software costs of the project, training, administration, as well as the coding cost that is not differential. In many cases, your differential comes out to be peanuts. And for the icing on the cake, find some way you can save them more than that small percentage, making you cheaper .

Summary of Walter Litt's Method

Ralph desanto's friendly method.

When Ralph complemented, he complemented the person. When he criticized, he criticized their action. I think he basically believed people are good.

Unfortunately, there's no way you can package Ralph's basic belief in the good of humanity. Few of us have that outlook. But to the extent possible, try to see your customers and prospects as cool people you might like to get friendly with some day. You'll be glad you did.

Mark Kassof's Marketing Tips

Not too shabby for a site with no IPO and no venture capitalists. But I had great marketing advice from Kassof.Com. Basically, Mark emphasizes seeking an audience you can realistically attract, and super-serving them. Being a technology and Open Source kind of guy, I super-served the technologist and Linux audience.

Kassof emphasizes that with so much noise in the media, you need to be a little outrageous to be heard. So I did. I told my true feelings about Microsoft. Many friends told me I was doing the wrong thing. They told me I'd be closing doors on myself. They told me I'd blow off 95% of my potential audience. And they were right.

But that remaining 5% loved Troubleshooters.Com, just as Mark predicts in his insights. One of his quotes is that "These days, the 'middle of the road' is a good place to get run over".

I've just scratched the surface here, but it would take 10,000 words to fully explain Kassof's marketing strategies, and I don't have the bandwidth. So go to Kassof.Com, and study both his "Research Insights" and his "Quotations of Chairman Mark". Links to both, as well as to his main page, are in the URL's section of this magazine.

You might also wonder what marketing has to do with sales. In a big company maybe very little. But in a small company, prospecting begins with marketing and transitions to sales as the prospects become more interested.

Don't let it throw you that Mr. Kassof's tips are targeted at the radio industry. They work on the web too. Believe me :-) And for any of you out there who are involved with radio, use him. My reading of his website tells me that if I needed radio research, I'd go to him, because he's independent and not affiliated with a radio chain or consultant, he's unbiased, and he knows radio.

Strategic Selling (Miller and Heiman)

• Above the funnel (uncontacted leads and research based hunches)
• In the funnel (a lead who has been contacted and is listening)
• The best few (an interested prospect who is probably a good fit)
• Below the funnel (got the order)

This book makes the point that too many salespeople and organizations hammer the best few until they've sucked it dry, and then discover their abandonment of the upper levels means they need to wait months to refill that level. So they hammer the upper levels and finally get an influx of best few. This explains certain extreme cyclical sales events.

In many other ways, this book takes a systemic and scientific view of sales. I recommend it.

Tom Hopkins

First, be aware that my copy of  "How to Master the Art of Selling" is the second edition, which appears to have been copyrighted in 1982. It's probable that Mr. Hopkins has changed the book a lot since then.

My second edition book gives many, many examples. That's a good thing. My wife's a Realtor (R) , and I just mentioned an example from this book that directly applied to a situation she was in. Especially refreshing is that Mr. Hopkins hasn't gone overboard on "consultative selling". Tom isn't afraid to admit that he likes to close, and likes to close hard. And he's not afraid to imply that not all prospective customers are peers of Einstein.

Which brings up the problem. Many of the techniques he espouses in my Second Edition book are insulting to an intelligent person. Anybody trying Hopkins' "Ben Franklin Balance Sheet Close" or the "Porcupine Test Close" on me would find themselves out the door (without an order) in a hurry.

"How to Master the Art of Selling" is a must-read for anyone in sales. The author has obviously been there and documented his strategies and tactics. Just carefully temper your adoption of those suggestions that seem to insult the buyer's intelligence. And if you're contemplating a sales career, or new to sales, be sure to pick up a copy of Selling for Dummies".

Non Manipulative Selling

How i raised myself from failure to success in selling.

There's a myth that consultative selling started in the 1980's. Check out this line from the 1949 edition:

"I resolved right then to dedicate the rest of my selling career to this principle: Finding out what people want, and helping them get it. "

Don't worry though, Bettger's not just a consulatively correct wet noodle -- he also suggests the "sign by the X assumptive close".

Unbelievably, this book is still in print, copyright 1992. It is 24 hours available at Amazon, where it's ranked #7,966 and has a five star review average. Frank Bettger looks about 35 years old on the 1949 copy cover, which would have made him 78 in 1992. To me, this book's staying power makes it not only a classic, but a tried and true resource.

The Greatest Sales Stories Ever Told

This book is obviously not a complete sales problem solving methodology, but serves beautifully in the function of example. I believe the seasoned salesperson would profit from this book, right along with the newbie.

In a world where even we salespeople start to believe in the plaid sportcoat car salesman and Arthur Miller's Willy Loman, Shook's deep love and admiration for his profession makes the reader stand a bit taller. If you EVER contemplate selling anything, get this book.

One Business Optimized Methodology: Reengineering

So from my understanding of Hammer and Champy's definition of reengineering, its optimized for those cases where the business is so out of touch with present day realities as to be "totalled", like a car hitting a bridge at 120mph or a house burned to the ground. If you'd like to "improve" your business while keeping its core advantages, my understanding is that reengineering is not the way to go.

Obviously, my understanding of the term is crude at best, so please don't take my word for it. Read the book for yourself, and see if I've been overly critical. I invite all more knowledgeable on reengineering to write letters to the editor (instructions near the bottom of this page) so that next month the truth about reengineering will surface.

I believe that one of these tools, Covey's "The 7 Habits of Highly Effective People", rises above the others to take its place among general problem solving methodologies. It's true you can't fix a car using his methodology, but you can sure use it to make yourself a better mechanic.

According to Fred Nickols' website, he's a writer, consultant, and executive. A further perusal of his site reveals his credentials to be, putting it mildly, outstanding. Be sure to read Fred's articles and his distance consulting page. His articles on problem solving are insightful, and all too rare on the web. His URL is in the URL's section of this magazine.

Charles V. Camp is a Professor of Civil Engineering at the University of Memphis. His web notes for the CIVL 1101 course he teaches,  Civil Engineering Measurements, contain some of the best problem solving content on the Internet. I'd suggest you read all the content related to problem solving. The URL is in the URL's section of this magazine.

For time reasons, I didn't detail Fred's and Charles' contributions to problem solving, but their content is outstanding and a must-see for any problem solver.

Linux Log is a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.

• Reboot the computer
• Reapply the service pack(s)
• Reinstall the app or operating system

Linux Has Logs

Imagine how much easier diagnosis of intermittents would have been with a continuously running strip chart recorder. I could have looked for the onset of the symptom, and seen what else happened around that time. I could have observed which voltages changed.

These logs can be used for more than just after the fact detective work. Using the tail -f command, you can view messages in real time as you exercise the system. Better yet, most daemons have methods to increase or decrease the verbosity of what they write to logs, enabling you to "drill down" to execution details. When combined with access to the source code, this becomes a powerful Troubleshooting tool. To find how to change the log verbosity of a daemon, look at the man page of the daemon.

When troubleshooting Linux, always look at the relevant log files.

Available Source

Enter source available software. Now you can peer into the actual design of the software. This can be done at several levels.

The simplest way to use the source is to crank up log levels, search for the source statement issuing a suspicious log message, and work backwards through the source until you come upon an interesting question. This can be done with minimal knowledge of the software.

As you gain a little more expertise, you can use the source to form a Mental Model of the software, and make deductions and form new tests based on that Mental Model.

Finally, you can actually change and recompile the source to test hypotheses. Although this is extremely powerful, care must be taken not to cause harm. Original source files must be backed up, the original executable files must be backed up, and it's best to do this on a non-live system, if one exists and if the symptom can be reproduced on it.

Source code needn't be thoroughly digested to be helpful in Troubleshooting. Often you can start in the type source distribution directory, and search for a term or phrase like this:

Little General Maintenance

General Maintenance is especially powerful against non-component flaws -- dirty contacts, loose bolts and other things not appearing on the schematic diagram. It is also extremely powerful against intermittents. But neither of these situations pops up frequently in Linux. As a rule, software has few "non components". Especially software whose source code is available. And as far as intermittents, Linux is a stable and robust operating system that seldom exhibits intermittents.

General Maintenance has one huge downfall. It prevents positive ID of the root cause. If the symptom goes away after you clean all switches and controls, you don't know which switch, you don't know which contact within the switch, and you don't know why the contact got dirty or oxidized. This is obviously taboo in a safety sensitive situation, but even in a business computing environment, it's not desirable.

In fact, the system logs are often a more productive tool in diagnosing intermittents. And it's all too easy to conduct tests with the various software tools that come with Linux, in order to positively determine the root cause, and toggle it.

So except in cases of complete befuddlement, don't reboot a Linux box as a Troubleshooting step. It might not even be desirable to restart a service, although this is done often. Try to find the root cause without General Maintenance.

Most problems caused by human error or human cracking

Long upgrade history.

This isn't necessarily true of Linux. It's often better to upgrade, thereby keeping dns, dhcp, samba, apache and other configurations intact. Installing fresh means restoring each of those configurations (and many, many more) from documentation or (human) memory.

The downside is that on a Linux system that's gone through a long series of upgrades, the system state is not fully known. I recently heard of somebody who had continuously upgraded a mid-90's copy of yggdrasil and still has it running today. Almost all the yggdrasil code is gone, but over the continuum of time, it's the same system. Obviously, such a system could not be replicated from distribution.

When should you finally bite the bullet and install Linux fresh? I guess when the system becomes so unknown that you cannot troubleshoot it.

Text config files and vi

Remember to restart the appropriate daemons or services after changing a config file. My experience is that daemons recognize certain config file changes immediately, but need to restart in order to recognize them all. After changing a config file, you're in an undefined state until restarting the daemon or service.

If you do any Troubleshooting tests that compromise security, try to get the box off the network before doing them. Write them down so you can quickly undo them.

The bad news is that an owned Linux box is more dangerous than an owned Windows box. The good news is that a Linux box can be made much more secure than any Windows box.

A discussion of security is very much beyond the scope of this article, but there are many fine books and websites devoted to the subject. Unless you're running a single machine that does not log into the Internet or LAN, you need to understand security.

Steve Litt is a member of Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). He can be reached at Steve Litt's email address .

All letters become the property of the publisher (steve litt), and may be edited for clarity or brevity. we especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. we reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.)., submit letters to the editor to steve litt's email address, and be sure the subject reads "letter to the editor". we regret that we cannot return your letter, so please make a copy of it for future reference..

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.

• Troubleshooting Processes for well defined systems:
• http://www.ganssle.com/articles/atblsho.htm : Jack Ganssle's looping 6 step Troubleshooting Process. Also see his other Troubleshooting info at http://www.ganssle.com/articles/tblsht1.htm :, as well as his main page at http://www.ganssle.com .
• http://www.Intelliworxx.com/html/mentoring.html : This is the starting point to read about Intelliworxx's Era 4 Troubleshooting product, which they call MentorWorxx.
• http://www.troubleshooters.com/tuni.htm : The 10 step Universal Troubleshooting Process.
• Other problem solving processes
• http://www.concentric.net/~Maxainc/indexm.htm : Website of Max Ammerman, the Root Cause Analysis authority.
• http://www.goldratt.com : The website of the Avraham Y. Goldratt Institute (The Goal and Critical Chain). Information on all works of Eliyahu M. Goldratt. See also http://www.goldratt.com/library.htm :, the library page for Theory of Constraints.
• http://www.jeffcox.com : Website of Jeff Cox, the co-author of The Goal.
• http://www.deming.org : Website of the W. Edwards Deming Institute. Deming started with the SPC problem solving method, and elaborated from there. In my opinion, Deming told the truth, the whole truth, and nothing but the truth.
• http://home.att.net/~nickols/articles.htm : Fred Nickols' wonderful articles on generic (fuzzily defined problems) problem solving.
• http://www.ce.memphis.edu/faculty/camp/1101/notes/index.html : This page and its subpages contain some truly excellent information on problem solving. The site was authored by Charles Camp, Professor of Civil Engineering at the University of Memphis.
• Sales tools useful in problem solving
• http://www.kassof.com : Website of marketing researcher Mark Kassof. Especially valuable are his marketing tips at http://www.kassof.com/insights/index.htm . See also "The Quotations of Chairman Mark" at http://www.kassof.com/mark/quote.htm .
• http://www.millerheiman.com : Website of the authors of "Strategic Selling". Be sure to read their great "Tip of the Week Archive" at http://www.millerheiman.com/tip/archive/index.htm .
• http://www.tomhopkins.com : Website of sales author and consultant Tom Hopkins.
• http://www.shookbook.com : Home page of Robert L. Shook, author of "The Greatest Sales Stories Ever Told : From the World's Best Salespeople".
• Human-Centric tools useful in problem solving
• http://www.ozemail.com.au/~caveman/Creative/Resources/crquote2.htm : Not mentioned in this magazine, but this site contains numerous quotations about creativity and problem solving.
• http://www.crystalcathedral.org : This is the website of the Crystal Cathedral, whose founding pastor is Robert Schuller, author of "Tough Times Never Last, But Tough People Do!". Also see the Robert Schuller book list at http://store.crystalcathedral.org/acb/showprod.cfm?
• http://www.keithellis.com : Website of Keith Ellis, who wrote the "affirmations" article that can be seen at http://www.keithellis.com/bootstraps1.7.html .
• Other URL's
• http://www.troubleshooters.com : Author Steve Litt's website.
• http://www.hqmc.usmc.mil/factfile.nsf/
• http://call.army.mil/call/newsltrs/98-10/chap8.htm : More info on the M1A1 main battle tank. This site was my source of the tank's gas mileage.
• http://www.dictionary.com : The source of the definitions in this magazine.

Diagnosing vs. Troubleshooting

What's the difference.

Diagnosing and troubleshooting are two essential processes in problem-solving, particularly in technical fields. Diagnosing involves identifying the root cause of a problem by analyzing symptoms, conducting tests, and gathering relevant information. It requires a systematic approach to narrow down the possibilities and reach a conclusive diagnosis. On the other hand, troubleshooting focuses on resolving the identified problem by implementing specific steps or procedures. It involves a hands-on approach, where the troubleshooter applies their knowledge and expertise to fix the issue. While diagnosing is more about understanding the problem, troubleshooting is about taking action to rectify it. Both processes are interconnected and often go hand in hand to effectively resolve issues.

Further Detail

Introduction.

Diagnosing and troubleshooting are two essential processes in various fields, including technology, medicine, and automotive industries. While both aim to identify and resolve issues, they differ in their approach and focus. In this article, we will explore the attributes of diagnosing and troubleshooting, highlighting their similarities and differences.

Diagnosing refers to the process of identifying the root cause of a problem or determining the nature of a disease or condition. It involves gathering information, analyzing symptoms, and making an informed judgment based on available evidence. Diagnosing is often performed by professionals with specialized knowledge and expertise in a particular field.

One of the key attributes of diagnosing is the systematic approach it follows. It typically involves a series of steps, such as gathering patient history, conducting physical examinations, ordering diagnostic tests, and interpreting the results. This structured process helps ensure accuracy and reliability in identifying the underlying issue.

Another important attribute of diagnosing is the reliance on evidence-based information. Professionals use their knowledge, experience, and available data to make an informed diagnosis. This evidence-based approach helps minimize errors and ensures that the diagnosis is based on objective findings rather than assumptions or guesswork.

Furthermore, diagnosing often requires critical thinking and problem-solving skills. Professionals need to analyze complex information, consider multiple possibilities, and make logical connections to arrive at an accurate diagnosis. This attribute highlights the importance of expertise and experience in the diagnostic process.

Lastly, diagnosing is an ongoing process that may involve reassessment and adjustment. If the initial diagnosis does not align with the patient's response to treatment or new information emerges, the professional may need to reevaluate the diagnosis and make necessary modifications. This attribute emphasizes the dynamic nature of diagnosing.

Troubleshooting

Troubleshooting, on the other hand, focuses on identifying and resolving issues or malfunctions in a system, device, or process. It is commonly associated with technical fields, such as IT support, electronics, and mechanical engineering. Troubleshooting aims to restore functionality and eliminate problems that hinder optimal performance.

One of the primary attributes of troubleshooting is its reactive nature. When a problem arises, troubleshooting comes into play to identify the cause and implement a solution. Unlike diagnosing, which involves a systematic approach, troubleshooting often requires quick thinking and the ability to adapt to unexpected situations.

Another important attribute of troubleshooting is the emphasis on practical solutions. Troubleshooters focus on finding immediate fixes or workarounds to restore functionality. While diagnosing may involve a more comprehensive understanding of the underlying issue, troubleshooting aims to address the problem swiftly, minimizing downtime or inconvenience.

Troubleshooting also requires a strong understanding of the system or device being addressed. Professionals need to have in-depth knowledge of the components, their interactions, and potential failure points. This attribute highlights the importance of technical expertise and familiarity with the specific system or device.

Furthermore, troubleshooting often involves a trial-and-error approach. Professionals may need to test different solutions or perform diagnostic tests to narrow down the cause of the problem. This attribute reflects the iterative nature of troubleshooting, where multiple attempts may be required before finding the most effective solution.

Lastly, troubleshooting is often a collaborative effort. In complex systems or processes, multiple individuals with different areas of expertise may work together to identify and resolve the issue. This attribute emphasizes the importance of effective communication and teamwork in troubleshooting scenarios.

Similarities and Differences

While diagnosing and troubleshooting have distinct attributes, they also share some similarities. Both processes aim to identify and resolve problems, albeit in different contexts. They require analytical thinking, problem-solving skills, and the ability to gather and interpret information.

However, the main difference lies in their approach and focus. Diagnosing is more comprehensive and systematic, aiming to identify the root cause or nature of a problem. It often involves a structured process, relies on evidence-based information, and may require ongoing reassessment.

Troubleshooting, on the other hand, is more reactive and practical. It focuses on finding immediate solutions to restore functionality and eliminate issues. Troubleshooters often rely on their technical expertise, adaptability, and a trial-and-error approach to identify and resolve problems swiftly.

Another difference is the level of expertise required. Diagnosing often involves professionals with specialized knowledge and experience in a specific field, such as doctors, engineers, or technicians. Troubleshooting, while also requiring expertise, may be performed by individuals with a broader understanding of systems or devices.

Furthermore, diagnosing is commonly associated with medical or healthcare fields, while troubleshooting is more prevalent in technical or mechanical domains. However, both processes can be applied in various industries and sectors, depending on the nature of the problem.

In conclusion, diagnosing and troubleshooting are two essential processes used to identify and resolve problems in different fields. Diagnosing focuses on identifying the root cause or nature of a problem, following a systematic and evidence-based approach. Troubleshooting, on the other hand, aims to restore functionality swiftly, relying on technical expertise and practical solutions.

While they have distinct attributes, both processes require analytical thinking, problem-solving skills, and the ability to gather and interpret information. Understanding the differences and similarities between diagnosing and troubleshooting can help professionals in various industries approach problem-solving more effectively and efficiently.

Comparisons may contain inaccurate information about people, places, or facts. Please report any issues.

Are You Problem-Solving, or Just Worrying?

Insights on how to stop worrying about your problems and start solving them..

Posted February 1, 2021 | Reviewed by Matt Huston

We all have problems—it’s an inevitable part of being alive. But sometimes, when we’re trying to focus our energies on solving these problems, we may actually be doing something far less productive: worrying .

In the anxiety literature, worry is defined as a repetitive pattern of negative thinking about unresolved and threatening issues that could end badly. It’s not just about having one negative thought (“Oh no, I forgot to write that report due on Monday!”). Instead, worry is a sustained period of negative thinking about the issue, and often focused on the worst-case-scenario outcomes (e.g., “What if I can’t finish on time? What if it’s terrible? What will people think of me? I might get fired!” and so on).

It’s not uncommon for people to confuse worry with problem-solving. But unfortunately, despite our best intentions, worry actually derails the problem-solving process.

As worry researchers, Michelle and I have carefully studied the literature on this topic, and have conducted our own research as well. Here are our responses to some of the common questions and misconceptions about worry versus problem-solving.

When I’m worrying about my problems, I’m working on solving them, right?

Actually, no. Worrying is NOT the same as problem-solving. But it seems that lots of us have trouble telling the difference. For example, research shows that when asked why they worry, many people say it’s because they’re trying to solve problems. And this may be especially true for those of us who worry a lot: Another study found that chronic worry is linked to believing that prolonged thinking is required to find the best solutions.

However, recognizing the distinction, and being able to shift away from worry and into more productive thinking, can make a big difference in how efficiently you solve your problems.

Okay, so what is problem-solving, and how is it different from worrying?

In the research literature, successful problem-solving is described as following these steps: clearly pinpointing and defining the problem, determining what you hope to achieve with the solution, coming up with a range of solutions while withholding any judgment regarding the quality of those solutions (brainstorming), weighing the solutions based on pros and cons, and then identifying the optimal solution ( D’Zurilla & Goldfried, 1971 ). In general, the best problem-solvers also hold a positive stance toward their problems—accepting that difficulties are bound to happen from time to time, and believing that they are capable of responding appropriately.

Worry, on the other hand, is more focused on all the things that can go wrong. We identify the threat (e.g., work we forgot to do), but then get stuck in either rehearsing the threat itself (“I can’t believe I forgot! How did this happen? I’m so irresponsible.”) or mulling over all the possible repercussions (“My boss will be so disappointed. This will really throw off the project. Everyone at work will be mad at me.”). When we’re worrying, we’re so focused on these things that we may never even get to the point of coming up with solutions.

Why do I get these two processes confused?

Because thinking about our problems can make us feel anxious, we might confuse that thought process with worrying. This is especially true for those of us who worry a lot. Worriers can have pretty negative beliefs about our ability to solve problems. We find problems to be kind of scary, and don’t feel as confident that we can handle them.

So if you’re a worrier, you may find that thinking about your problems can make you anxious, which can then trigger worrying about the issue instead of focusing on it objectively.

Another reason is that, for many of us, worry feels productive. We’re focusing on the threatening issue, repeating it over and over to ourselves, mulling over possible outcomes (mainly the bad ones), and spending a LOT of time and mental energy doing it. But we’re not getting anywhere . It’s like pressing really hard on the gas pedal while the car is in neutral. You might expend a ton of energy and feel mentally exhausted, but you haven’t moved an inch.

Is worrying really such a bad reaction to my problems?

The short answer is: yes. While it may be totally normal to feel a surge of anxiety when you first identify a threat or problem, it’s not so helpful to keep that anxiety going when you’re trying to fix it.

Here’s why worry is bad for problem-solving.

For one, worrying makes us feel bad . And research shows that feeling bad can influence our judgments and decision-making . That is, a negative frame of mind can make us feel more pessimistic about the problem, and more likely to dismiss any solutions we come up with as not good enough.

Furthermore, when we’re worrying, it takes a lot of mental effort to stop focusing on the threat and shift into more goal-directed thinking. This means fewer cognitive resources left to actually solve the problem.

To get to the bottom of things, Michelle and I recently ran a study (which we also discussed here ) to directly test the impact of worry on problem-solving.

We asked some people to worry about a current problem and others to consider their problem without worrying (e.g., focus on breaking it down into smaller parts, think about end- goals , and set aside negative thoughts). When we then asked everyone to come up with solutions, worry took its toll. Not only did people who worried generate less effective solutions to the problem, worry also predicted that they were less inclined to put these solutions into action. And for those participants who were naturally high worriers, worrying had a significant negative impact on their confidence , too.

In essence, we found that worry impaired problem solving when compared to more objective, less emotional thinking.

Here are some ideas for how to tell when you’re worrying versus problem-solving, and how to change these patterns.

1. When you’re thinking about the issue or problem, take a moment to assess how you’re feeling. Are you tense, distressed, and upset? If so, you might be worrying.

Instead, try to take some slow breaths from your diaphragm and relax. If that doesn’t help, maybe decide to come back to the problem when you’ve had a chance to settle down (e.g., go for a run, take a shower, etc.). Just be sure you actually DO come back to it.

2. Are you spending a lot of time focusing on how things could go terribly wrong (i.e., catastrophizing )? If so, you are worrying.

Remember, focusing on what you DON’T want to happen takes time away from more productive thinking. Instead, focus attention on your goals— this might make it easier to come up with a pathway toward achieving them.

3. As you’re brainstorming, do you find yourself immediately dismissing all your solutions as ineffective? If so, you may be worrying.

Remember, worrying makes us feel pessimistic about our brainstorming process. Coming up with lots of solutions (even if some aren’t that great) is an important part of problem-solving. Just accept them as they come—you can evaluate and fine-tune them later.

Here’s the bottom line:

When you’re going to sit down and focus on a problem, try to do so in an open-minded, calm, and non-judgmental manner. Clearly define the problem, identify your ultimate goals, and think positive! But if you find yourself slipping into negative thinking (e.g., thinking about everything that could go wrong), don’t get frustrated or give up. Just try to let those thoughts go, and refocus your mind on the problem itself.

And remember, despite what you may hear, there is no such thing as "good worry," especially when it comes to your problems. There are so many more productive ways to spend your time!

LinkedIn image: AshTproductions/Shutterstock.

Facebook image: By Marina Andrejchenko/Shutterstock

Llera, S. J., & Newman, M. G. (2020). Worry impairs the problem-solving process: Results from an experimental study. Behaviour Research and Therapy, 135, 103759. https://doi.org/10.1016/j.brat.2020.103759

Sandra J. Llera, Ph.D . is a clinical psychologist and an Associate Professor at Towson University.

Michelle G. Newman, Ph.D ., is a Professor of Psychology and Psychiatry at the Pennsylvania State University.

• Find a Therapist
• Find a Treatment Center
• Find a Psychiatrist
• Find a Support Group
• Find Teletherapy
• United States
• Brooklyn, NY
• Chicago, IL
• Houston, TX
• Los Angeles, CA
• New York, NY
• Portland, OR
• San Diego, CA
• San Francisco, CA
• Seattle, WA
• Washington, DC
• Asperger's
• Bipolar Disorder
• Chronic Pain
• Eating Disorders
• Passive Aggression
• Personality
• Goal Setting
• Positive Psychology
• Stopping Smoking
• Low Sexual Desire
• Relationships
• Child Development
• Therapy Center NEW
• Diagnosis Dictionary
• Types of Therapy

Understanding what emotional intelligence looks like and the steps needed to improve it could light a path to a more emotionally adept world.

• Coronavirus Disease 2019
• Affective Forecasting
• Neuroscience

Problem Solving and Troubleshooting

Definition of problem solving and troubleshooting.

Problem Solving or troubleshooting is the ability to take an undesired state or issue, identify what is causing the issue, and then find the appropriate solution. The problem-solving competency is critical to the Systems Support community because most of the work done by this community is directly related to troubleshooting and solving undesired issues relating to technology.

Assistant: The Assistant is capable of following a logical thought possess that will help to identify the cause of a problem and possible solutions. This logical process will include the ability to gather data through various means, sort the data for relevancy, identify key information, hypothesize on the possible root causes of the problem, identify possible solutions, implement testing to find the correct solution and documentation of the complete process.

Associate: The Associate is comfortable with the problem-solving process and has experience solving problems in a technical working environment. The Associate is able to work through the steps of the problems solving process effortlessly and knows when and how to properly escalate problems.

Senior Associate: The Senior Associate consistently demonstrates problem-solving skills in work. Can independently identify problems, research, analyze, resolve, and verify solutions. Has appropriate logic and technical skills for the level of technical problems. Determines metrics, analyzes statistics, and applies good analytical/critical thinking. Contributes ideas that can further improve business processes.

Professional: The Professional possesses well-developed skills for resolving technology problems as well as business and customer relations problems. They can address foreseen and unforeseen obstacles successfully and apply proven analytical skills. They are capable of making decisions that impact the scope of a project in a timely manner, and take responsibility. The Professional researches and learns new techniques and then helps to mentor others.

Senior Professional: The Senior Professional has developed the business and technical acumen to foresee and resolve complex business and technology problems, and applies this knowledge to University-wide and systemic issues. They are trusted by others and help others to foresee challenges and strategize for long-term resolution. The Senior Professional exemplifies creativity by generating new solutions to client and University issues. They set standards of ingenuity for the organization through their ability to solve problems.

Principal: The Principal has developed the business and technical acumen to foresee and resolve complex business and technology problems often before they occur. They work to apply this insight to University-wide and systemic issues. The Principle is looked to and trusted by others to foresee challenges and strategize for long-term resolution. They exemplify creativity by generating new solutions and set the standard of ingenuity for the organization through their work. The Principle is comfortable making important product and business decisions utilizing appropriate data, collaboration, strategy, ethics, and risk management. The Principle is expected to contribute innovative ideas and solutions based on research and the ability to stay current on newest technological practices.

How to Develop Problem Solving - Troubleshooting

University courses:.

• CPSE 589R Gifted and Talented Creative Thinking Strategies
• TES 330 Creativity, Engineering, and Problem Solving

Training / Other Courses:

• LinkedIn Learning – Problem Solving Techniques
• EdX – Creative Problem Solving and Decision Making
• MIT Professional Education – Effective Problem Solving for Teams
• Learning Tree International – Critical Thinking and Creative Problem Solving
• Udemy – Problem Solving – Mastering Thinking Skills
• Critical Thinking and Creative Problem Solving Training – Learning Tree

Professional Associations / Certifications:

• Advanced Problem Solving Certification - Georgia Tech
• LeanMap PDCA Problem Solving Training and Certification

Books / Publications:

• Great Courses – The Creative Thinkers Toolkit, by Professor Gerard Puccio
• Bulletproof Problem Solving, by Charles Conn & Robert McLean
• Your Deceptive Mind: A Scientific Guide to Critical Thinking Skills by Steven Novella

Experiences that can assist the employee in his/her development:

• Document your current method for solving problems. Do you follow a framework or established pattern to solve problems?
• Work as part of a team to solve a complex problem. Document the steps the team went through to find a solution. What roles did each member play? How could the process be improved?
• Successful completion of a degree
• Successful completion of an advanced degree
• Study, develop, test and modify a personal problem-solving framework
• Work as part of a team to solve a complex problem. Document the steps the team went through to find a solution.
• Share in writing how the completion of a degree or advanced degree helped the development of your problem-solving skills.
• Share your personal framework for problem solving and how it has improved over time. Give specific examples.
• Describe the core skills need for successful problem solving.
• Share in writing a team problem solving experience you participated in. What was the problem? How was it resolved? What roles did each member play? How did the team process work and how could the process be improved?
• Document and share verbally to members of the CDC leadership team key takeaways learned while working to improve personal and team problem solving skills.
• Describe how previous problem-solving skills can interfere with current problem-solving efforts. Why is this important and how can it be avoided?

How to Demonstrate Problem Solving - Troubleshooting

DO: Describe what you did in completing / achieving your development plan

ASSESS: Share, if applicable, any assessments that were taken / provided related to your activities

LEARN: Explain what you felt that you were able to learn during your journey / experiences

APPLY: Give specifics examples where you have / plan to make direct application to your work

REFLECT: Review / consider things you would have done differently had you had this experience earlier

Try RevDeBug in action for free. Jump into our interactive demo >

Troubleshooting Vs. Debugging: The Difference and Best Practices

By RevDeBug

The terms “troubleshooting” and “debugging” are often used interchangeably. While they both have similar goals, their processes are different—but that doesn’t stop software companies like Microsoft from mixing and matching all the jargon. 

As you can see, this creates a lot of confusion, especially if within one company we have many roles: developers, DevOps, SRE, and their responsibilities can overlap and can not be clearly defined.

In this article, we’re going to talk about the difference between troubleshooting and debugging, as well as their best practices. Read on to learn more.

Troubleshooting Vs. Debugging

Both troubleshooting and debugging are concepts that developers are required to learn and understand thoroughly. Since they have some very common traits — yet different processes — they can be confusing. 

Developers arguably spend more time debugging than they do troubleshooting. However, as they move forward in their careers and take on more responsible operational duties, they’ll eventually be more focused on troubleshooting. 

So, let’s discuss the differences:

What Is Troubleshooting?

Troubleshooting is defined as the process that allows programmers to identify issues occurring within a given system. It notably exists at a higher level than debugging as it applies to many more elements within said system. 

Essentially, it’s the process of extracting the problem-causing items from a set of potential reasons. This process requires often to go beyond technical information and to communicate with end-users of the systems to figure out which steps they need to take to track down which part of the code, infrastructure, or configuration is causing the problems. 

Troubleshooting can be applied to virtually any system and can be compared to the aim of the root cause analysis. For example, if your car’s engine doesn’t start, you or a qualified mechanic would begin by trying to identify which component failed and what caused it to fail. It could be something as simple as needing new spark plugs or something more severe, such as a completely blown head gasket, but you’d have to run some diagnostics tests and look for clues to figure out the source of the engine failure. 

What Is Debugging?

Debugging can be defined as a subset for troubleshooting. Debugging requires the developer to find and fix the issues that are related to computer software. 

While debugging may seem simpler — find what caused the problem within your application and then fix it—there could be several points of failure, and it’s not always obvious where the issues are occurring. 

For example, you may be led to a specific JavaScript code related to browser failure, however, the issue has to do with an API response. The entire process becomes even more complicated when you’re dealing with complex apps, complicated microservice architecture, or a cloud-native environment. 

Stating the Difference Plainly

While debugging is known as a subset of troubleshooting, troubleshooting doesn’t always entail problem-solving. Troubleshooting is more procedural as the entire process typically revolves around specific workflow protocols that can keep the issue from being fixed as soon as it’s found.

Debugging, by definition, is meant to find and fix the problem all in one shot but the reality could be different.

As we add new roles like SRE (site reliability engineers) or DevOps to previously functioning developer/programmer and administrator the roles are beginning to change along with the industry, which could eventually bridge the gap between troubleshooting and debugging. For example when SREs become more involved with company operations activities. This means that they share a subset of duties with other team members and could assist developers and DevOps in the process of seeking out the issue so they can be fixed immediately.

Best Practices for Troubleshooting and Debugging

Since debugging and troubleshooting both aims, in the end, to find and fix the issue but they could be done on a different level, let’s talk about the general best practices for the situation:

Find the Changes

When something within a software’s ecosystem changes, failure occurs. Checking for changes is necessary for both troubleshooting and debugging, which makes it the first step in the discovery process. 

The best way to go about the discovery process is by quickly limiting the scope you are investigating and focus on finding the root cause. . You need to figure out whether the problems are connected with a code change, broken configuration, lower performance caused by infrastructure, or user-specific situation. 

Depend on Tools But Not in Isolation

Monitoring tools should help you identify where the problems are occurring, as they exist to support debugging and troubleshooting. 

However, these tools are often limited in their capabilities when you didn’t collect all relevant data before the issue, which means they can also mislead or delay you in your discovery process.

While tools are helpful, you shouldn’t also have in mind that problems could be caused by factors outside your systems or mechanism language-specific that can’t be easily connected with your problems.

Don’t Use Print Statements

As you progress in your carrier you will learn that the most problematic errors are those which: 

• Don’t have a clear path to reproduce
• Aren’t logged well enough
• Aren’t covered in tests

It’s tempting to add logs everywhere and it’s very helpful to use print statements but you need to be honest with yourself. You won’t be able to predict what to log before the error happens and even if add them to your code you can’t be sure that you will be able to reproduce errors to gather necessary data. 

This is where a tool like RevDeBug comes in handy because it’s constantly monitoring your code and if something bad happens it creates a recording of the code execution and all variables, so you can debug any situation, even those that happen. 

Luckily, if you’re unfamiliar with the monitoring tool like RevDeBug you’re presented with, you can use print statements.

Print statements come in hand as a brute force method you could use in all programming languages. They allow developers to display and view the values of the intended output stream so they are very useful but to streamline debugging and troubleshooting you need more powerful tools. 

Track the Bugs

Bug tracking or error monitoring is essential to your troubleshooting or debugging process. You need to know if it’s a new problem, or it’s something that you resolved previously and it resurfaces after the latest release. This is why bug tracking is the best way to capture and track the problems and provide one source of the truth to your team. 

If you don’t already use an error monitoring solution, it’s time to add RevDeBug to your process. 

Help Others Debug

It’s important to be confident that your code isn’t causing bugs in the software, but you shouldn’t stop there. Part of the troubleshooting and debugging process involves teamwork, which is why you’re not finished until the entire team is finished.

Plus, helping other team members with debugging is a good way to learn a few tips and tricks from their processes.

It’s important to remember that despite having different processes, troubleshooting and debugging tend to overlap. The end goal remains the same, however, and the industry evolves, IT teams must adapt. 

Subscribe to receive our newsletters

PROBLEM SOLVING VS. TROUBLESHOOTING TASKS: THE CASE OF SIXTH-GRADE STUDENTS STUDYING SIMPLE ELECTRIC CIRCUITS

• Published: 28 November 2013
• Volume 12 , pages 1341–1366, ( 2014 )

Cite this article

• Rafi’ Safadi 1 , 2 &
• Edit Yerushalmi 2  

552 Accesses

10 Citations

1 Altmetric

Explore all metrics

We compared the materialization of knowledge integration processes in class discussions that followed troubleshooting (TS) and problem-solving (PS) tasks and examined the impact of these tasks on students’ conceptual understanding. The study was conducted in two sixth-grade classes taught by the same teacher, in six lessons that constituted a third of a unit on simple electric circuits. In these lessons, one class was assigned PS tasks where students were asked to solve conceptual problems. Later they were asked to share their work in a class discussion. The other class was assigned TS tasks where students were asked to identify, explain, and correct the mistakes in “teacher-made” erroneous solutions to these same problems. They were also engaged later in a class discussion. We found that students’ performance on subsequent transfer problems was significantly higher for the TS class, in particular for students with low prior knowledge. We account for the difference in learning outcomes by the differences in the learning process: the TS tasks elicited more naïve ideas both in students’ worksheets as well as in class discussions, and the TS discussions involved more episodes where students developed criteria to discern scientifically acceptable and naive ideas. We also found differences in the format of students’ participation, where lower-achieving students participated in the TS discussions. The implications of these findings for future research are discussed.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price includes VAT (Russian Federation)

Instant access to the full article PDF.

Rent this article via DeepDyve

Institutional subscriptions

Similar content being viewed by others

Learning from erroneous examples in the mathematics classroom: do students with different naïve ideas benefit equally?

Rafi Safadi & Nadera Hawa

Commentary on Part III of Mathematical Challenges For All: On Problems, Problem-Solving, and Thinking Mathematically

Reaction: Students, Problem Posing, and Problem Solving

Asterhan, C. S. C. & Schwarz, B. B. (2009). Argumentation and explanation in conceptual change: Indications from protocol analyses of peer-to-peer dialogue. Cognitive Science, 33 , 374–400.

Article   Google Scholar  

Ayalon, M. (2011). Argumentation and school mathematics . Rehovot, Israel: The Weizmann Institute of Science (Unpublished doctoral dissertation).

Google Scholar  

Azmon, S., Hershkowitz, R. & Schwarz, B. (2006). The role of the teacher in turning claims to arguments. The role of the teacher in turning claims to arguments. In J. Novotna, H. Moraova, M. Kratka & N. Stelinkova (Eds.), Proceedings of the 30 th International Conference for the Psychology of Mathematics Education , Vol. 5. Faculty of Education, Charles University in Prague, Prague, Czech Republic, (pp. 65–72)

Bransford, J. D. & Schwartz, D. L. (1999). Rethinking transfer: A simple proposal with multiple implications. Review of Educational Research, 24 , 61–100.

Cazden, B. C. (1988). Classroom discourse: The language of teaching and learning . Portsmouth, NH: Heinemann.

Chi, M. T. H. (1997). Quantifying qualitative analyses of verbal data: A practical guide. The Journal of the Learning Sciences, 6 , 271–315.

Chi, M. T. H. (2000). Self-explaining expository texts: The dual processes of generating inferences and repairing mental models. In R. Glaser (Ed.), Advances in instructional psychology (pp. 161–238). Mahwah, NJ: Lawrence Erlbaum Associates.

Closset, J. L. (1983). Sequential reasoning in electricity. In Research on Physics Education. Proceedings of the First International Workshop. Editions du CNRS, La Londe les Maures (pp. 313–319).

Curry, L. A. (2004). The effects of self-explanations of correct and incorrect solutions on algebra problem-solving performance. In K. Forbus, D. Gentner & T. Regier (Eds.), Proceedings of the 26th annual conference of the cognitive science society (p. 1548). Mahwah, NJ: Erlbaum.

Durkin, K. & Rittle-Johnson, B. (2012). The effectiveness of using incorrect examples to support learning about decimal magnitude. Learning and Instruction, 22 , 206–214.

Eilam, B. (2002). Passing through a western-democratic teacher education: The case of Israeli-Arab teachers. Teacher College Record, 104 (8), 1656–1701.

Eisenmann, T. & Even, R. (2011). Enacted types of algebraic activity in different classes taught by the same teacher. International Journal of Science and Mathematics Education, 9 , 867–891.

Große, C. S. & Renkl, A. (2007). Finding and fixing errors in worked examples: Can this foster learning outcomes? Learning and Instruction, 17 , 612–634.

Härtel, H. (1982). The electric circuit as a system: A new approach. European Journal of Science Education, 4 , 45–55.

Heller, P. M. & Finley, F. N. (1992). Variable uses of alternative conceptions: A case study in current electricity. Journal of Research in Science Teaching, 29 , 259–275.

Herbel-Eisenmann, B. A., Lubienski, S. T. & Id-Deen, L. (2006). Reconsidering the study of mathematics instructional practices: The importance of curricular context in understanding local and global teacher change. Journal of Mathematics Teacher Education, 9 , 313–345.

Hieggelke, C. J., Maloney, D. P., O’Kuma, T. L. & Kanim, S. (2006). E&M TIPERs: Electricity & magnetism tasks . Boston, MA: Addison Wesley.

Jabot, M. & Henry, D. (2007). Mental models of Elementary and Middle School Students in analyzing simple battery and bulb circuits. School Science and Mathematics, 107 , 371–381.

Labudde, P., Reif, F. & Quinn, L. (1988). Facilitation of scientific concept learning by interpretation procedures and diagnosis. International Journal of Science Education, 10 , 81–98.

Linn, M. C. & Eylon, B. S. (2006). Science education: Integrating views of learning and instruction. In P. A. Alexander & P. H. Winne (Eds.), Handbook of educational psychology (2nd ed., pp. 511–544). Mahwah, NJ: Erlbaum.

McLaren, B. M., Adams, D., Durkin, K., Goguadze, G., Mayer, R. E., Rittle-Johnson, B., Sosnovsky, S., et al (2012). To err is human, to explain and correct is divine: A study of interactive erroneous examples with middle school math students. In A. Ravenscroft, S. Lindstaedt, C. Delgado Kloos & D. Hernándex-Leo (Eds.), Proceedings of EC-TEL 2012: Seventh European conference on technology enhanced learning, LNCS 7563 (pp. 222–235). Berlin: Springer.

Melis, E., Sander, A. & Tsovaltzi, D. (2010). How to support meta-cognitive skills for finding and correcting errors. In Proc of the AAAI Fall 2010 Symposium (pp. 64–68).

Osborne, J. (2010). Arguing to learn in science: The role of collaborative, critical discourse. Science, 328 , 463.

Reif, F. (2008). Applying cognitive science to education: Thinking and learning in scientific and other complex domains (pp. 82–83). Cambridge, MA: MIT press.

Reif, F. & Scott, L. (1999). Teaching scientific thinking skills: Students and computers coaching each other. American Journal of Physics, 67 , 819–831.

Schwartz, D. L., Bransford, J. D. & Sears, D. (2005). Efficiency and innovation in transfer. In J. Mestre (Ed.), Transfer of learning from a modern multidisciplinary perspective (pp. 1–51). Mahwah, NJ: Erlbaum.

Schwartz, D. L. & Martin, T. (2004). Inventing to prepare for learning: The hidden efficiency of original student production in statistics instruction. Cognition & Instruction, 22 , 129–184.

Shipstone, D. M. (1984). A study of children’s understanding of electricity in simple D. C. circuits. European Journal of Science Education, 6 , 185–198.

Siegler, R. S. (2002). Microgenetic studies of self-explanation. In N. Garnott & J. Parziale (Eds.), Microdevelopment: A process-oriented perspective for studying development and learning (pp. 31–58). Cambridge, MA: Cambridge University Press.

Chapter   Google Scholar  

Smith, J. P., DiSessa, A. & Roschelle, J. (1993). Misconceptions reconceived: A constructivist analysis of knowledge in transition. The Journal of the Learning Sciences, 3 , 115–163.

Sohmer, R., Michaels, S., O’Connor, M. C. & Resnick, L. (2009). Guided construction of knowledge in the classroom: The troika of talk, tasks and tools. In B. Schwarz, T. Dreyfus & R. Hershkowitz (Eds.), Transformation of knowledge through classroom interaction (pp. 105–129). New York: Routledge.

Summers, M., Kruger, C. & Mant, J. (1998). Teaching electricity effectively in the primary school: A case study. International Journal of Science Education, 20 , 153–172.

Tsovaltzi, D., Melis, E., McLaren, B. M., Meyer, A.-K., Dietrich, M. & Goguadze, G. (2010). Learning from erroneous examples: When and how do students benefit from them? In M. Wolpers, P. A. Kirschner, M. Scheffel, S. Lindstaedt & V. Dimitrova (Eds.), Proceedings of the EC-TEL 2010 fifth European conference on technology enhanced learning, LNCS 6383 (pp. 357–373). Berlin: Springer.

Vardi-Rath, E. & Blum-Kulka, S. (2005). The lesson as an asymmetric speech event: A study of the participant structure in the Israeli classroom. In I. Kupferberg & E. Olstein (Eds.), Discourse in education: Researching educational events (pp. 385–417). Tel-Aviv: Mofet Institution.

Yackel, E. (2002). What we can learn from analyzing the teacher’s role in collective argumentation. Journal of Mathematical Behavior, 21 , 423–440.

Yerushalmi, E., Puterkovski, M. & Bagno, E. (2012). Knowledge integration while interacting with an online troubleshooting activity. Journal of Science Education and Technology . doi: 10.1007/s10956-012-9406-8 .

Download references

Author information

Authors and affiliations.

Department of Research and Evaluation, The Academic Arab College For Education in Israel, Haifa, Israel

Rafi’ Safadi

Department of Science Teaching, Weizmann Institute of Science, Rehovot, Israel

Rafi’ Safadi & Edit Yerushalmi

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Rafi’ Safadi .

Electronic supplementary material

Below is the link to the electronic supplementary material.

(DOCX 232 kb)

Rights and permissions

Reprints and permissions

About this article

Safadi, R., Yerushalmi, E. PROBLEM SOLVING VS. TROUBLESHOOTING TASKS: THE CASE OF SIXTH-GRADE STUDENTS STUDYING SIMPLE ELECTRIC CIRCUITS. Int J of Sci and Math Educ 12 , 1341–1366 (2014). https://doi.org/10.1007/s10763-013-9461-5

Download citation

Received : 21 January 2013

Accepted : 20 September 2013

Published : 28 November 2013

Issue Date : December 2014

DOI : https://doi.org/10.1007/s10763-013-9461-5

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• class discussion
• conceptual understanding
• learning from erroneous solutions
• problem solving
• simple electric circuits
• Find a journal
• Publish with us
• Track your research

• Request a Demo

Educators Blog

Problem-Solving or Solving Problems?

By Carolyn Marchetti,

In both math and science, problem-solving is a critical skill.  It is a process that students will use throughout their schooling, work life, and beyond.  By developing problem-solving skills, our students not only learn how to tackle a math or science problem but also how to logically work their way through any types of problems that they face.  Our textbooks include word problems after every lesson – so this incorporates problem-solving skills, right?  Not necessarily.

I was at a conference over 10 years ago and heard a presenter say, “Problem-solving is what you do when you don’t know how to solve a problem”.  Solving problems, like the typical word problems found in our texts, on the other hand, is applying a known method to a problem that has already been solved before.

Here’s an example of how the majority of textbooks phrase a lesson — “Today we are going to learn how to multiply fractions.  Here are the steps to multiplying 2 fractions.   Here are some non-contextual examples to hone your skill”.  Then most follow with ‘real-life’ word problems which, more times than not, involve fractions that require multiplication. This is a routine of practicing skills.  I’m not saying that this isn’t important, just that problem solving is much more than this.

As teachers, we need to know the differences between the 21st-century skill of problem-solving and the traditional way of solving problems, and we especially need to learn how to recognize and even create true problem-solving experiences for our students.

I would like to give some tips on creating a problem-solving classroom by using an example of a task that I used when doing professional development with math teachers. The task is called The McDonald’s Claim Problem.  There are several versions of this task on the internet, but basically, it goes like this:

• Wikipedia reports that 8% of all Americans eat at McDonald’s every day.
• There are 310 million Americans and 12,800 McDonald’s in the United States.
• Do you believe the Wikipedia report to be true? Create a mathematical argument to justify your position.

Tips on creating a problem-solving classroom:

• Engage students in real-world problems that students can relate to and have a prior understanding of.  For McDonald’s, it was an interesting problem because it engaged students in prior learning – they’ve all been to McDonald’s and have all used Wikipedia.  For other tasks, videos can be used to spark interest.  For example, Dan Meyer’s 3 Act Tasks are one way to spark interest.  Another suggestion is to use a career video like the Defined STEM videos that are included with each performance task.  These videos grab students interest by answering the question of “When will I ever use this?”.
• Use group work for problem-solving. Students can frequently help each other, and talking about a problem helps them think more critically about the steps needed to solve the problem.  By discussing the problem, students will start to realize that problems have multiple solution strategies, and some may be more effective than others.  For the McDonald’s problem, I would have teachers work in groups of 4-5. There would be many discussions among the members before even starting the task. Discussions around what does “eat at” mean?  Does the drive-through count?  Does the question mean the same 8% eat there every day?  These questions and discussions had teachers brainstorming ideas before deciding on a course of action to solve the problem.
• There should not be a direct path to the solution.  Even better if there is not one right answer, like the McDonald’s problem, but these are harder to find.  Monitor student progress and solutions.  When they get stuck, answer their questions with other probing questions.  When the math teachers would ask me questions regarding the McDonald’s problem, I would always come back with “What does your group think?”, to encourage them to collaborate and come to a consensus.
• Have students share their solutions. When everyone is finished, have groups present their solution to the others, especially the ones that went about the problem in different or unique ways. Having the groups share their solutions and justifications is very important for others to see various ways of problem-solving. For the McDonald’s problem, even though groups often used calculations to solve the problem and would get the same numbers, many had a different answer of “yes or no” depending on their reasoning. Hearing the different reasons from other groups can be very enlightening.  I heard a lot of “I never thought of it that way”, which is a powerful aspect of problem-solving.

There are many other tips I can give, which I will continue in a later post.  For now, I would like to leave you with a quote from a colleague: “It is better to answer 1 problem 5 different ways than to answer 5 different problems”.  In one short sentence, that is the difference between problem-solving and solving problems.

Subscribe to the #1 PBL Blog!

Receive new articles in the world of Project Based Learning, STEM/STEAM, and College & Career Readiness. 

• Project-Based Learning (363)
• STEM/STEAM (167)
• Professional Learning (51)
• College and Career Readiness (50)
• Social and Emotional Learning (34)
• Career-Connected Learning (33)
• Computer Science (14)
• Assessment (6)
• Highlights (1)

Subscribe to our blog

• Career Advice
• Job Search & Interview
• Productivity
• Public Speaking and Presentation
• Social & Interpersonal Skills
• Professional Development
• Remote Work
• Our Products

Eggcellent Work

Critical thinking vs problem solving: what’s the difference.

In our blog “Importance of  Problem Solving Skills in Leadership ,” we highlighted problem solving skills as a distinct skill set. We outlined a 7-step approach in how the best leaders solve problems.

Table of Contents

Critical thinking vs. problem solving

But are critical thinking and problem solving the same? Also, if there are differences, what are they? Although many educators and business leaders lump critical thinking and problem solving together, there are differences:

Problem solving  uses many of the same skills required for critical thinking; e.g., observation, analysis, evaluation, interpretation, and reflection.  Critical thinking  is an important ingredient of problem solving.

Critical thinking vs. problem solving: Not all problems require critical thinking skills

Not every problem-solving skill is a critical thinking skill. That is because not every problem requires thinking. A problem like opening a stubborn pickle jar could simply require brute strength. On the other hand, it becomes a thinking skill when you remember to tap the edge of the pickle jar lid to loosen the seal.

Also, some problem-solving skills are the exact opposite of critical thinking. When you follow directions or use muscle memory or rote (memorization) thinking, there is no critical thinking required. Likewise, skills of persuasion or public oratory are thinking skills, but aren’t necessarily critical thinking skills.

Critical thinking vs. problem solving: The role of emotional intelligence

In our blog “ What is the role of communication in critical thinking ?” we highlighted one author’s argument that critical thinking and problem solving is not always a purely rational process. While critical thinkers are in great demand in the hiring marketplace, employees who are emotionally intelligent bring even greater value to an organization.

Writing for  Business News Daily ,  editor Chad Brooks describes emotional intelligence as “the ability to understand your emotions and recognize the emotions and motivations of those around you.”

So, when looking for star performers, research shows “that emotional intelligence counts for twice as much as IQ and technical skills combined in determining who will be a star performer.”

Further, in today’s collaborative workplace environment, “hiring employees who can understand and control their emotions – while also identifying what makes those around them tick—is of the utmost importance.”

Finally, one expert notes that dealing with emotions is an important part of critical thinking. Emotions can be at the root of a problem. They are frequently symptomatic of problems below the surface. Problem solving when dealing with emotions requires openness to authentic emotional expressions. It requires the understanding that when someone is in pain, it is a problem that is real.

• The Ultimate Guide To Critical Thinking

Is Critical Thinking A Soft Skill Or Hard Skill?

• How To Improve Critical Thinking Skills At Work And Make Better Decisions
• 5 Creative and Critical Thinking Examples In Workplace
• 25 In-Demand Jobs That Require Critical Thinking and Problem-Solving Skills
• Brainstorming: Techniques Used To Boost Critical Thinking and Creativity

Critical thinking and problem solving: A deeper dive

A recap of the distinct differences between critical thinking and problem solving.

Critical thinking,  according to an article on Drexel  University’s Graduate College webpage  “utilizes analysis, reflection, evaluation, interpretation, and inference to synthesize information that is obtained through reading, observing, communicating, or experience.”

The goal of critical thinking is to evaluate the credibility of both the information and its source. It questions the central issue and how the information will inform intelligent decisions. Finally, it asks the question, “Where does this information lead me?”

Problem solving , as previously mentioned, uses many of those skills, but “it takes the process a step further to identify obstacles and then to strategically map out a set of solutions to solve the problem. That extra step in problem solving is  identifying obstacles  as well as mapping out a strategic set of solutions to resolve the problem.

How to develop critical thinking skills to become a better problem solver

1. develop your analytical skills..

Pay attention and be more observant. Ask the questions “who, what, where, and why” and learn as much as possible about the topic or problem.  Map everything out  to imprint or gain a visual understanding and focus on the differences between fact, opinion, and your own bias.

2. Learn the skill of evaluating

As a subset of analysis, you can become skilled in evaluation by:

• comparing similar and related topics, programs, and issues. How are they different, and where are the similarities?
• looking for trends that support (or refute) what you intuitively feel is the solution
• recognizing barriers or conflicts to successful problem resolution
• asking questions and gathering information—assuming nothing, ever.

3. Interpretation with the help of a mentor or someone more experienced

Interpreting a problem accurately employs both analytical and evaluating skills. With practice, you can develop this skill, but to hone your interpretation skills, it is advisable to seek the help of an experienced mentor.

You’ll need to do the following:

• know how your own biases or opinions can be a roadblock to the best decision making
• recognize that cultural differences can be a barrier to communication
• look at the problem from the point of view of others
• learn as much as you can about the problem, topic, or experience
• synthesize everything you have learned in order to make the connections and put the elements of a problem together to form its solution

4. Acquire the skill and habit of reflection.

Being reflective is applicable to almost every aspect of your personal and professional life. To open your mind to reflection, think back to your educational experience. Your instructor may have asked you to keep a  reflective journal  of your learning-related experiences. A reflective journal requires expressive writing, which, in turn, relieves stress.

Perhaps you have just had a disagreement with a coworker, who became abusive and personal. Not everyone can come up with those instant snappy comebacks on the spot, and it is usually best to disengage before the situation gets worse.

Here’s where reflective journaling helps. When you’re in a calmer state of mind, you can journal the incident to:

• gain deeper insights into your thought processes and actions—How do you feel about not defending yourself from the colleague’s accusations or personal abuse? What was the perfect response that eluded you in the stress of the moment?
• build a different approach to problems—It could be that your co-worker perceives you as unapproachable or unreceptive to suggestions and criticism. Maybe it’s time to have a frank discussion to help you see yourself through the eyes of the coworker.
• get closer to making significant changes in your life—Your journal entries may have displayed a pattern of your behavior on the job, which elicits consistent negative reactions from more than one co-worker.

Your takeaways:

• When evaluating critical thinking vs. problem solving, the elements of both appear to blend into a distinction without a difference.
• Good problem solvers employ the steps of critical thinking, but not all problem solving involves critical thinking.
• Emotional intelligence is an attribute that is a hybrid skill of problem solving and critical thinking.
• You can hone your critical thinking skills to become a better problem solver through application of analysis, evaluation, interpretation, and reflection.
• 10 Best Books On Critical Thinking And Problem Solving
• 12 Common Barriers To Critical Thinking (And How To Overcome Them)
• How To Promote Critical Thinking In The Workplace

Is Critical Thinking Overrated?  Disadvantages Of Critical Thinking

11 principles of critical thinking  .

Jenny Palmer

Founder of Eggcellentwork.com. With over 20 years of experience in HR and various roles in corporate world, Jenny shares tips and advice to help professionals advance in their careers. Her blog is a go-to resource for anyone looking to improve their skills, land their dream job, or make a career change.

Further Reading...

Brainstorming: Techniques Used To Boost Critical Thinking and Creativity  

No Comments

Leave a reply cancel reply.

Save my name, email, and website in this browser for the next time I comment.

What Is The Role Of Communication In Critical Thinking?  

Problem Solving & Troubleshooting

Course modules.

• Engage the Customer
• Define the Problem
• Analyse the Problem
• Develop the Solution
• Close and Learn

Delivery and Duration

More information, 88 comments.

Instructor (Steve) was patient and was able to explain perspectives previously I wouldn’t have thought of. Problem solving as a life skill.

Great Instructor – appreciate Steve’s understanding.

Brilliant course, very informative and the trainer has a wealth of experiences and relates that to real life examples. Thank you for running an excellent training course!

Great 2 days, thank you for your time

Thank you I feel introduced to some important skills. Now I need to apply them.

He made it very interesting and enjoyable.

Stronger Lego Bricks!

It was excellent

Great experience and feel very motivated to implement fresh ideas.

Make info pack/content smaller and focus on exercises. Consider 3 day duration. Consider cheaper location to reduce total cost.

Thank you Steve! Great class and thank you for all the valuable information you have taught us!

The instructor was very engaging and informative. Overall I was very happy

Very good course. I have picked up plenty of information on how to put this into practice.

Thank you. It was very thought provoking. Hopefully will learn to use mind maps more / fishbone.

Thank you for your efforts in preparing this class. It helped me a lot personally. Will review the info regularly.

I would enjoy to take a follow up course if available.

Many Thanks!

Second day was awesome, first day is too much detail for L1 and L2 support.

Thank you for a great course.

Thank you very much / Matt

Everything was great – easy to follow, interesting, and has given me lots to try in my job going forward.

There is only one thing. Why there is no certification for this training?

Very good job. Well done 🙂

A lot of information for 2 day. Would have been more effective to spread it out.

I believe this class should be available when we begin the job.

Excellent course. Excellent presentation. very practical. Challenge is to integrate.

Great relevant material. Will be using these methods going forward.

I would like to see more time spent on topics within my sphere of influence.

Thanks very much for the class last week, it’s already helping me close more cases! 🙂

It was a great pleasure to take this course. It was very funny and pleasant. I really enjoy the games.

Instructor = 6/5

Really satisfied with the class. Enjoyed working with Steve.

Very helpful! Thank you!

Good teacher

This class gave me a new idea for support skills.

Very useful training. I got what I want.

Thanks Steven. This course was great to help me!!!

Very useful course.

Very good. Killer Q’s list great idea. Will try to push it here for new hires + as a TSE aid.

Excellent all round. Maybe include a section on confirming resolution with 3rd parties responsible for maintaining a clients environment.

Very informative, educational and a bit of fun. Thanks a lot.

Enjoyed use of fishbone and other diagram tools for brainstorming solutions/questions to customers.

Well presented and relevant.

Really helpful – At the start I was quite cynical that we could find a new methodology for supporting ICM. But we have a number of different things to take away and implement which could dramatically improve our work. Thank you.

Was very happy and delighted to have completed this course. Definitely worthwhile.

Very good instructor. Seemed to be aimed at entry level support during the first day.

Excellent course! Now I have to start applying what was learned so I can retain the information and change my habits. Thank you, Steve!

Well done. Good work!

Excellent course, well presented. I will recommend this company to others who could benefit from this experience.

Instructor was very motivated, explained everything very well. Smaller t-shirts 🙂 Learned VERY good techniques for troubleshooting and problem solving.

Hello Steve, I liked and enjoyed the course very much and you are one of the best instructors I met (and that’s the truth). I would be glad to receive information on the content of the other courses.

Thank you very much for teaching me some useful things to be use in my Tech Support and my life as well. Special Fish bones diagram. I need to read a manual.

GREAT. I really enjoyed the class. Lot of tips – mind maps.

Very good Troubleshooting training, and a very good presenter. The training could be more product specific. Examples are well presented, but could be more focused on finer details to prevent the errors discussed in class.

Presenter did well, he explained very well and the information has been very useful for my daily job.

Very satisfied. Would suggest that tutor can help us to review support process. A must for new hires.

Excellent. Would recommend to new hires. Instructor could be useful in restructuring the support process that we follow and his consultancy could be used for enhancement.

Every topic was useful. Very informative. Would expect more student activities. Bridge building exercise was very good.

All the techniques specified by Mr Steve can increase the productivity and efficiency in our day to day work. Tools used have been excellent. Good job Steve. Have a great one mate!

Completely satisfied. The class was very effective and informative. Steve was excellent in explaining the topics and was very easy to understand.

Good to have a trainer who has lots of field experience.

Best course I followed in years.

Very good class for support staff. However, mgmt course should have taken place before for the managers.

Instructor has a very good understanding ability for company-specific problems and challenges. Adapted very well to the individual needs. Very comprehensive, inventive, conclusive. Excellent summarizing and examples. Helpful tools and approaches. Thank you

Great course! learned a lot from it and already adopted many techniques. Instructor 10 out of 5.

Steve is an experienced professional and has most relevant information that can help our support team.

Excellent course. Time to re-evaluate my methods!

The instructor initially based a lot of the course on telephone support. Quickly adjusted once the class needs were identified.

Good course.

I think the material was excellent, but in general could be condensed maybe 15% or so. Steve had many good, direct examples and knows our industry. Just slightly differences between software support and hardware.

Very good presentation and material which is very relevant to what I am doing. Thank you Steve.

The instructor was enthusiastic and encouraging. The materials/examples were relevant, most of the time. Some relating to production were less relevant. One the whole, a really enjoyable course. Thanks.

Steve is the key point. His experience on support allows him to provide live examples of the different situations he has experienced.

Very good trainer – well done! You know what you are talking about.

The best course and instructor I’ve had regarding Problem Solving & Troubleshooting. Thank you.

Great course, really mind opening.

I really do hope that I can implement what I’ve learned on this course. Management should get us to revisit this material as soon as possible. Thanks!

Love to have Steve come and consult in VM Ware.

Some detailed catering to IT field specific references. I.e. case handling examples, example tools related to IT support cases.

The instructor, Steve Brand, was excellent and his experience in the IT and Tech support contributed greatly.

Fantastic class. Need more like it for everyone in the organization.

Very good instructor!

Useful information which came at the right time for me (as beginner in support). Lateral thinking is a way to explore in the future.

Liked the “take aways” – ideas that could benefit the whole organisation, not just the individuals in the class.

Very informative. Look forward to putting what I learnt into practice. Particularly interested in the documentation and capturing information in our knowledgebase.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

• Onsite training

3,000,000+ delegates

15,000+ clients

1,000+ locations

• KnowledgePass
• Log a ticket

01344203999 Available 24/7

What is the difference between Problem Solving and Decision Making?

Explore the nuances of "Problem Solving and Decision Making" in this insightful discussion. Gain a deeper understanding of the concepts - what Decision Making entails and uncover the key distinctions between Decision Making and Problem-Solving. This blog will equip you with valuable insights into these essential life and professional skills.

Exclusive 40% OFF

Training Outcomes Within Your Budget!

We ensure quality, budget-alignment, and timely delivery by our expert instructors.

Share this Resource

• Introduction to Management
• Introduction to Managing People
• Senior Management Training

Have you ever faced the trouble of deciding what is right or wrong? In our daily lives, we often come across situations that require us to confront challenges and make choices. This is why two critical cognitive processes are involved in addressing these situations: Problem Solving and Decision Making. While the terms are frequently used interchangeably, they represent distinct mental activities with specific objectives. Problem Solving involves identifying and resolving issues using critical thinking and creativity. On the other hand, Decision Making entails choosing the best course of action among alternatives and considering risks and rewards. In this blog, we will Learn the differences between Problem Solving and Decision Making, how to apply these abilities at work, and some advice on how to improve them.

Table of Contents 

1) What do you understand by Decision Making? 

2) Understanding Problem Solving 

3) What are the differences between Problem Solving and Decision Making?

4) Tips on how to improve Problem-solving and Decision-making skills

5) How can you integrate Decision Making and Problem Solving? 

6) Conclusion 

What do you understand by Decision Making? 

It is a hard choice for all of us when we are faced with the responsibility to make important decisions, both in the workplace and personal life. However, instead of getting afraid, we can tackle these important tasks by fully understanding the implications of our decisions. Before getting to know the differences between Decision Making and Problem Solving, let us first understand about Decision Making. 

It is a cognitive process that plays an essential role in our personal and professional lives. It involves evaluating different options and selecting the most appropriate course of action based on various factors and objectives. 

Effective Decision Making requires a combination of critical thinking, analysis, and judgment, and it can have a significant impact on outcomes and consequences. Let's uncover the important steps to Decision -making and some real-life examples:

1) Evaluation of alternatives: As a first step, you can start Decision Making by identifying and generating possible alternatives to address a given situation or problem. 

2) Rationality and objectivity: Making a correct rational decision involves a systematic analysis of available information, weighing the pros and cons of each alternative, and choosing the most logical and beneficial option. 

3) Heuristics and biases: In some cases, you may have mental shortcuts to make decisions quickly. However, remember that these shortcuts can also introduce biases and lead to suboptimal choices.  

4) Decision Making under uncertainty: Often, decisions must be made with incomplete or uncertain information. This requires you to make risk assessments. You also need to have the ability to adapt to changing circumstances. 

5) Group Decision Making: In collaborative environments, decisions may be made collectively through group discussions, brainstorming, and consensus-building. This approach leverages diverse perspectives and expertise. 

6) Strategic Decision Making: In organisations, you need to make strategic Decision Making. It involves considering long-term implications, aligning decisions with organisational goals, and anticipating potential impacts on stakeholders.  

7) Ethical considerations: Ethical Decision Making involves assessing the moral implications of choices. It revolves around making decisions that align with your values and principles. 

8) Learning from outcomes: To be an effective decision-maker, you need to learn from both successful and unsuccessful outcomes to improve your future Decision Making processes. 

Here are some real-life examples that may require you to make some justified decisions: 

a) Choosing between two job offers based on salary, benefits, and career prospects. 

b) Deciding which college or university to attend, considering factors like location, courses offered, and campus culture. 

c) Selecting an investment option after analysing risk, return potential, and financial goals. 

d) Determining the best marketing strategy for a new product launch, considering target audience, budget, and competition. 

e) Making a medical treatment choice for a patient after weighing the benefits, risks, and patient preferences. 

Gain a deeper understanding of yourself to take more effective Decision Making with our Personal & Organisational Development Training . 

Understanding Problem Solving  

You're now aware of how you can make effective Decision Making. Let us now learn how to effectively carry out Problem Solving tasks in our daily life. Problem Solving is a critical cognitive process that allows individuals to address obstacles, overcome difficulties, and achieve desired outcomes. 

It involves a systematic approach to understanding the issue, identifying possible solutions, and implementing the most effective resolution. This helps you to navigate complexities and arrive at successful conclusions. Let us now look at some tips that can help you in Problem Solving effectively:  

1) Problem identification: As a first step towards Problem Solving, effectively carry out tasks. Also, recognise and define the issue or challenge that needs to be addressed.  

2) Data gathering: Gathering relevant information and data related to the problem is essential for understanding its root causes and implications. This helps you become a good problem solver. 

3) Analysis and diagnosis: Analyse the gathered information to identify the underlying causes of the problem. This helps you in devising targeted solutions. 

4) Solution generation: Brainstorming and generating multiple potential solutions is crucial for you when you are exploring diverse approaches to resolve the problem. 

5) Evaluation of alternatives: Carefully evaluate the pros and cons of each solution. This helps you in selecting the most feasible and effective one. 

6) Implementation: After choosing a solution, you have to put the chosen solution into action. This requires planning, coordination, and effective execution. 

7) Creative thinking: Employing creative thinking approaches can lead you to have innovative solutions to complex problems. 

8) Root cause analysis: Identifying and addressing the root cause of a problem ensures that you have a more sustainable and lasting solution. 

Let us now see some real-life examples where you need to apply your Problem Solving skills: 

a) Resolving a technical issue with a computer by identifying and troubleshooting the actual cause of the problem. 

b) Finding an alternative transportation route when faced with unexpected road closures. 

c) Addressing a communication breakdown within a team by facilitating open discussions and conflict resolution. 

d) Solving a math problem by applying various Problem Solving Techniques and mathematical principles. 

e)  Fixing a malfunctioning appliance by diagnosing the issue and performing necessary repairs. 

Learn to be more Mindful when you are applying your Problem Solving skills with our Conflict Management Training .  

What are the differences between Problem Solving and Decision Making?

Let us now have a look how Problem Solving and Decision Making skills are different from each other:

1) Definition  

Problem Solving is a systematic process to identify, analyse, and resolve issues or challenges. It involves understanding the root cause of a problem, generating possible solutions, and selecting the best course of action. This approach aims to eliminate or reduce the negative impact of the issue. 

On the other hand, Decision Making is the process of choosing among various alternatives. Every Decision Making process yields a choice that can be an action, a strategy, or a resolution. It doesn’t necessarily need a problem; it can be any situation requiring a choice. 

2) Objective  

The main objective of Problem Solving is to overcome an obstacle or challenge. It aims to transform the current undesirable situation into a desired state. On the contrary, the primary goal of Decision Making is to select the best possible choice out of multiple alternatives. It could be proactive, like deciding on a strategy for market expansion, or reactive, like choosing a course of action in response to a competitor's move. 

3) Nature  

The process of Problem Solving is often reactive. It arises when a discrepancy occurs between the expected outcome and the actual outcome, necessitating a solution. However, in Decision Making it can be both proactive and reactive. Proactive Decision Making involves making choices in anticipation of future events, while reactive Decision Making responds to an immediate situation or problem. 

4) Process  

The process of Problem Solving often begins with understanding and diagnosing the problem. It is then followed by brainstorming potential solutions, analysing the feasibility of each solution, and finally, implementing the most suitable one. 

Whereas, in Decision Making, the process typically starts by identifying a need, gathering information, identifying alternatives, weighing them based on criteria like risks, benefits, and implications, and then selecting the best option.

5) Tools and techniques  

In Problem Solving, the common tools include Root Cause Analysis, Brainstorming, SWOT Analysis, and fishbone diagrams (Ishikawa). These tools help identify the origin of a problem and explore possible solutions. 

On the other hand, Decision Making involves techniques that are often used such as decision trees, cost-benefit analysis, pros and cons lists, and grid analysis. These help in evaluating the implications of each available choice. 

6) Skills required  

In Problem Solving, the major skills required are critical thinking, analytical skills, creativity, and resilience. The ability to persevere and not get overwhelmed when faced with challenges is vital. 

However, Decision Making requires analytical skills, risk assessment, intuition, and foresight. The ability to predict the outcomes of each choice and be accountable for decisions is essential. 

7) Duration and finality  

Problem Solving is time-consuming. It requires a deep dive into understanding the problem before moving on to solutions. The process concludes once a solution is implemented, and the problem is resolved. 

Tips on how to improve Problem-solving and Decision-making skills

Decision-making and Problem-solving are two most important skills that every individual must possess to excel in their career and in their personal life. There are multiple ways which can be used to improve these skills. Let’s have a look at some of these tips to improve these skills:

Developing skills related to Decision-making and Problem-solving

You can improve your Decision-making and Problem-solving skills by developing other skills such as analytical thinking, creativity and critical thinking. These allied skills will help you boost your analytical thinking skills, will help you think creatively and outside the box. Moreover, honing these skills will help you understand the problems deeply and analyse them without getting partial with your decisions.

Effective communication

Communication is the one of the major keys to success. Effective communication helps in solving problems, miscommunications and helps you understand different perspectives to the same problem. By practicing effective communication, you can convey an information or tasks seamlessly to you team members or colleagues. It helps you understand the root cause of any problem and helps you take an informed decision.

Think about past decisions

It may seem unrelated to you in this context, however, thinking back on your decisions that you made previously can help you not repeat the mistakes, or save you the time that you previously took to make a small decision. Reflecting on past decisions helpin analysing the current problems impartially and help you learn more about your own methods to decide or solve a problem.

Research your industry

Before you make any important decision, or solve out a problem, you need to know about your industry in detail. Since not all situations are same, neither are the industries. Every industry, company or business have their own set of goals, requirements, ideologies, and policies. Whenever you are a part of that specific industry, you should keep in mind, their framework. If you are going beyond their framework or their principles, while solving a problem, there may not be any significant impact taken by your decisions.

Keep yourself updated

It is necessary that you keep yourself updated. As you know that our world is going through many technological advancements. Hence you need to know and update yourself so that you can incorporate all these inventions and discoveries in your industry.

Crack Your Interview with Management Interview Questions and Answers

How can you integrate Decision Making and Problem Solving? 

Even though Decision-making and Problem-solving have their differences, there are still instances where you need to integrate these two special skills so that you can carry out any challenging tasks or situations, whether it be in the workplace or in your personal life. The following tips will help you show how you can take effective decisions and simultaneously solve problems: 

1) Foster a systematic approach: You can start by adopting a systematic approach to Problem-solving. It involves defining the issue, gathering relevant information, analysing data, generating potential solutions, and evaluating alternatives. Then, you can implement your structured Problem-solving process, which provides a solid foundation for your informed Decision Making. 

2) Identify decision points: You can recognise the key decision points within the Problem-solving process. Then you have to determine which factors require choices and weigh the consequences of each decision on the overall Problem-solving outcome.  

3) Incorporate critical thinking: You can emphasise your critical thinking throughout both Problem-solving and Decision-making. Engage in objective analysis so that you can consider multiple perspectives and challenge assumptions to arrive at well-rounded solutions and decisions.  

4) Utilise data-driven decisions: Ensure that the decisions made during the Problem-solving process are backed by relevant data and evidence. Your data-driven Decision-making minimises biases and increases the chances of arriving at the most suitable solutions. 

Conclusion 

If you integrate both Problem Solving and Decision Making, you can have a more potent approach toward various challenges or tasks. This will help you in making well-informed choices in those circumstances. Moreover, this synergy will empower you to have a Problem -solving mindset to navigate complexities with clarity and achieve effective outcomes. 

Enhance your remote leadership skills with our Managing Remote Teams Course .

Frequently Asked Questions

Problem-solving can be defined as the act of defining a problem, determine the cause of the problem, identify and prioritise solution according to the problem. Decision-making can be defined as the process of making choices by identifying a decision, gather information, and assess alternative solutions.

There are some common barriers to effective Decision-making. These are as follows:

a) Lack of knowledge about bias and decision-making in organisations

b) Poor culture of making proper decisions

c) Diversity in thought

d) Loss aversion bias

There are mainly five steps which are involved in Problem-solving and Decision-making:

Step 1: Identifying goals

Step 2: Gathering information for weighing options

Step 3: Considering consequences

Step 4: Making your decision

Step 5: Evaluating your decision made

There are seven steps involved in the Decision-making process. These steps are as follows:

Step 1: Identify the decision

Step 2: Gather relevant information

Step 3: Identifying the alternatives

Step 4: Weighing the evidence

Step 5: Choosing among alternatives

Step 6: Taking action

Step 7: Reviewing your decision and its consequences

The Knowledge Academy takes global learning to new heights, offering over 30,000 online courses across 490+ locations in 220 countries. This expansive reach ensures accessibility and convenience for learners worldwide.   Alongside our diverse Online Course Catalogue , encompassing 17 major categories, we go the extra mile by providing a plethora of free educational Online Resources like News updates, blogs, videos, webinars, and interview questions. Tailoring learning experiences further, professionals can maximise value with customisable Course Bundles of TKA .   The Knowledge Academy’s Knowledge Pass , a prepaid voucher, adds another layer of flexibility, allowing course bookings over a 12-month period. Join us on a journey where education knows no bounds.

Upcoming Business Skills Resources Batches & Dates

Fri 31st May 2024

Fri 26th Jul 2024

Fri 27th Sep 2024

Fri 29th Nov 2024

Get A Quote

WHO WILL BE FUNDING THE COURSE?

My employer

By submitting your details you agree to be contacted in order to respond to your enquiry

• Business Analysis
• Lean Six Sigma Certification

Share this course

Our biggest spring sale.

We cannot process your enquiry without contacting you, please tick to confirm your consent to us for contacting you about your enquiry.

By submitting your details you agree to be contacted in order to respond to your enquiry.

We may not have the course you’re looking for. If you enquire or give us a call on 01344203999 and speak to our training experts, we may still be able to help with your training requirements.

Or select from our popular topics

• ITIL® Certification
• Scrum Certification
• Change Management Certification
• Business Analysis Courses
• Microsoft Azure Certification
• Microsoft Excel Courses
• Microsoft Project
• Explore more courses

Press esc to close

Fill out your  contact details  below and our training experts will be in touch.

Fill out your   contact details   below

Thank you for your enquiry!

One of our training experts will be in touch shortly to go over your training requirements.

Back to Course Information

Fill out your contact details below so we can get in touch with you regarding your training requirements.

* WHO WILL BE FUNDING THE COURSE?

Preferred Contact Method

No preference

Back to course information

Fill out your  training details  below

Fill out your training details below so we have a better idea of what your training requirements are.

HOW MANY DELEGATES NEED TRAINING?

HOW DO YOU WANT THE COURSE DELIVERED?

Online Instructor-led

Online Self-paced

WHEN WOULD YOU LIKE TO TAKE THIS COURSE?

Next 2 - 4 months

WHAT IS YOUR REASON FOR ENQUIRING?

Looking for some information

Looking for a discount

I want to book but have questions

One of our training experts will be in touch shortly to go overy your training requirements.

Your privacy & cookies!

Like many websites we use cookies. We care about your data and experience, so to give you the best possible experience using our site, we store a very limited amount of your data. Continuing to use this site or clicking “Accept & close” means that you agree to our use of cookies. Learn more about our privacy policy and cookie policy cookie policy .

We use cookies that are essential for our site to work. Please visit our cookie policy for more information. To accept all cookies click 'Accept & close'.

Bug reporting

Debugging made way easier

Crash reporting

Full stack, not just stack traces

Here’s what Shake can do

Product managers

QA engineers

Internal app testing

Beta testing

Tech support

Documentation

Set up and effectively customize Shake

See, suggest and vote for upcoming features

Hot takes on various development topics

System status

Realtime updates on Shake service status

Integrations

Plug Shake into tools you use in minutes

Help center

Answers to common questions about Shake

• Get started

Troubleshooting vs. app debugging: what’s the difference?

In IT and software development, there are terms with distinct meanings that are still often used interchangeably, causing confusion.

This is particularly true for the terms troubleshooting and debugging.

They both refer to a process of identifying, isolating, and fixing issues.

But they have different meanings and connotations, which can lead to misunderstandings when discussing these topics.

That’s why we’ll dive into these two processes, compare them, and examine how they differ so that you can use them correctly.

Table of Contents

What is troubleshooting

At some point, every app or system will break down or exhibit some other undesirable behavior.

This can be attributed to various factors, such as poor infrastructure and architecture, malfunctioning third-party services, or faulty pipelines, permissions, and networks.

After such incidents, it’s necessary to investigate what went wrong and why.

In other words, troubleshooting must be performed.

Despite its widespread usage, the term troubleshooting is often confused with debugging, as we already mentioned in the introduction.

However, the definition from Wikipedia  should set the record straight:

Troubleshooting is a form of problem solving, often applied to repair failed products or processes on a machine or a system. It is a logical, systematic search for the source of a problem in order to solve it, and make the product or process operational again.

As the explanation suggests, the emphasis in troubleshooting is on identifying the core cause of an issue and establishing the most effective method to restore system functionality.

This means that it looks at the problems in a larger context than debugging does.

To accomplish this, troubleshooters typically follow a multi-step approach similar to the one represented in the image below.

The initial step entails isolating the issue and identifying the scope of its impact.

This typically begins with a strategic assessment of the entire system, during which diagnostic tools such as Komodor, displayed below, can be utilized to determine what went awry.

The next step involves collecting relevant data related to the issue, which may include checking the app’s manual, maintenance history, issue reports, and so on.

The collected data is then evaluated to rule out possible causes one by one and zero in on the root cause.

After examining all of the facts and conclusions, you should have more than enough data to suggest a solution and implement it.

Bug & crash reporting tool for mobile apps.

It’s important to note that while a flawed system may have minor consequences, it could also result in security breaches and have an impact on the company’s bottom line.

Therefore, troubleshooting should be conducted frequently, not simply when a user reports an issue.

What is debugging

Debugging, in contrast to troubleshooting, is a more specific process that primarily focuses on locating bugs, crashes, and other defects in code and removing them from the application.

Developers typically carry out this process after QA specialists have found and reported a bug or as standard procedure when coding.

However, although debugging may have a narrower focus than troubleshooting, that doesn’t necessarily mean that it’s less challenging.

A Quora user sheds some light on the subject below:

Debugging is an investigative process that requires you to examine the code in great detail, rule out different possibilities and assumptions, and discover why it’s malfunctioning so that the bug can be removed.

The process typically involves six steps, as you can see in the image below.

In other words, to fix a bug, it’s not only pivotal to discover and analyze the error but also to ensure that the patch doesn’t cause lateral damage to other components of the application and that all parts of the code are effectively integrated.

To achieve this, you can employ two equally effective types of debugging : reactive and preemptive.

Reactive debugging  is primarily focused on addressing bugs that have been identified during testing.

After receiving a bug report from QA experts, developers respond to the report and work to resolve the issue.

In contrast, preemptive debugging  takes a preventive approach and seeks to mitigate issues before they occur.

This type of debugging focuses on problematic areas during app development and tries to eliminate them through code reviews and static code analysis.

All in all, debugging takes place throughout the entire app development process and is one of the foundations of quality and functional code.

Troubleshooting vs. debugging: key differences

Although troubleshooting and debugging are two related processes, there are also significant differences between them.

Troubleshooting, for example, is a process that encompasses looking at the entire system to find gaps in functionality and performance and rectifying them.

It’s done at the macro level, meaning that you’re considering all the components that make up a system.

That means that you’ll handle the following aspects:

• Identifying symptoms
• Performing tests to isolate the issue
• Checking settings
• Verifying configurations
• Determining how components interact with each other

It also often necessitates going beyond technical information and communicating with end-users of the system in order to better understand their problems.

Debugging, on the other hand, is a narrower, more specialized process that can be considered a subcategory of troubleshooting.

While troubleshooting is concerned with solving large-scale, system problems, debugging focuses on fixing bugs, crashes, glitches, and other anomalies in the code.

To debug code, developers must be familiar with the programming language and environment being used, which is less important when troubleshooting.

Ideally, debugging should be done in a single session during which the problem is identified, and can involve techniques  such as backtracking, cause elimination, rubber duck debugging, and pair debugging.

You can also use tools such as our own Shake to alleviate the debugging process.

Although Shake  is not a debugger per se but rather a bug and crash reporting tool, it can come in particularly handy when you want to track down a bug.

As an SDK, it can be installed on any iOS or Android device with only a few lines of code, and you can trigger it by shaking the phone whenever you find a bug in your app.

It’ll then generate a comprehensive bug report containing more than 70 crucial pieces of environmental data that will make detecting bugs in the code significantly easier.

Some of the information that Shake automatically captures includes device information, memory usage, network data, CPU usage, and history logs, to name just a few, but it can be customized if you need more details.

This can be of immense help to developers during debugging.

Ultimately, the distinction between troubleshooting and debugging comes down to scope.

Troubleshooting involves a broader process of identifying the underlying cause of a problem as compared to debugging, which focuses on fixing bugs.

By understanding the differences between these two processes, you can better determine which approach to take when solving problems with your code or system.

Best practices that work for both

Debugging and troubleshooting go hand in hand because they both aim for the same goal—finding and fixing issues in an app.

This is why there are some practices that can be applied to both processes and used in either one. The following three sections contain the most important ones of these.

Check for changes

During troubleshooting and debugging, it’s best to inspect the changes first.

This means looking at what changed, when it changed, and where it changed, as this can be useful in your quest for errors and inconsistencies in the system.

This isn’t as simple as it may appear because it can depend on numerous variables, tools, programming languages, and systems you employ.

Despite the complexity of the task, you can begin by investigating your logs and version control to ascertain whether a change is the root cause of your problem.

Fortunately, there are top-notch logging tools available, including Papertrail , DataDog , and Cloudlytics , that enable you to not only inspect log changes but also alert you when performance errors occur.

For example, DataDog has a user-friendly interface that allows you to scrutinize the logs thoroughly, pinpoint changes, and determine if they’re the potential cause of the error.

You must admit, this expedites the whole troubleshooting and debugging process and helps you prevent errors from creeping into the system.

Another technique you can deploy here is to inspect your version control system because most of them give you access to the history of changes in the file or repository.

For instance, in Git you can use the  git log  command to see what changes were made between the two commits.

The git log command will then list the commits in a repository, with the most recent commit appearing first.

In general, checking for changes can be a valuable technique for detecting errors and inconsistencies in your code or system.

From there, you can move on to other practices.

Use tools with caution

Although tools are useful, keep in mind that they can only detect problems that are caused by factors within the system.

They cannot identify faults in a process that stem from outside elements, so they may not reveal important defects.

In that case, manually inspecting the app for malfunctions can be a great addition to your automated processes.

There are several situations when using tools alone isn’t sufficient:

• When the issue is related to the user interface or usability
• When the issue involves user input—tools may not be able to account for all the ways that users can enter input and have it trigger a problem
• The problem may be intermittent, occurring only under certain conditions or at certain times
• When the issue affects security—tools may be unable to detect all possible forms of attack or account for the fact that vulnerabilities in one area can lead to vulnerabilities in another

Bug and crash reporting tool for apps that gets you all the right data.

These are just a few circumstances in which identifying a problem requires more than simply using tools.

However, in cases where automated tools aren’t applicable, it’s still worth using them as part of a process for identifying problems.

But it would help if you also used human judgment combined with these results to verify and ensure that nothing was overlooked.

Use a bug tracking solution

Bug tracking tools are essential at every stage of the troubleshooting and debugging process.

It’s paramount to know what defects have been reported, who has worked on them, and whether each error is still an issue or has already been resolved.

A good bug tracking tool can help you keep tabs on all that information by providing you with a central location for organizing issues in one place.

There are many excellent bug-tracking tools available on the market today. Some of the most widely adopted ones include:

We’ll use Jira as our example since it’s widely used among developers and has a built-in bug-tracking system.

In fact, when Jira was originally built, it was intended to be used as a bug-tracking tool, and its many features reflect that intention.

As illustrated below, Jira’s dashboard gives you an overview of the current status of your projects, with a complete list of issues, their status, and their types.

The interface also has a section where you can assign tasks to your team members, create new projects and subprojects, and perform other tasks related to bug tracking.

The tool also comes with a number of integrations, which streamline its use.

For example, you can integrate Jira with bug and crash reporting tools such as Shake.

That way, when users report the bug, Shake will automatically send the generated bug report straight to Jira’s dashboard, where all stakeholders will be able to inspect it, analyze it, and track it through its life cycle.

This will make troubleshooting and debugging even more streamlined because it brings everything under one roof.

Troubleshooting and debugging are two closely related practices that help identify and fix issues in applications.

While troubleshooting is generally used to identify issues that occur at the system level, debugging is performed to find bugs in code.

It’s important to note that these practices are often utilized together in order to detect and resolve issues, so it’s important for developers of all skill levels to develop proficiency in both of them.

About Shake

Shake is a bug and crash reporting tool for mobile apps. It helps developers solve reported issues in their app faster, without having to bother the user.

Help your app be the best version of itself.

Add to app in minutes

Doesn’t affect app speed

GDPR & CCPA compliant

Want to create or adapt books like this? Learn more about how Pressbooks supports open publishing practices.

13 Conflict Resolution and Problem Solving

Chapter 13 Check-in:

• Identify Conflict Causes and Effects
• Explore Conflict Approaches Solutions
• Basic Problem Solving Strategy PDCA

Like all communication, good conflict management and resolution requires your time: listen, reflect, and consider all elements of a situation and the people involved.  It is not a simple process and there are some steps to help you navigate the process.  In the end, it is about the relationship.

Frequently considered a negative, conflict can actually be an opportunity for growth in relationship or work.  Your attitude towards the situation and person plays a role in any outcome.  Adam Grant, Professor of Psychology at The Wharton School at the University of Pennsylvania and Saul P. Steinberg Professor of Management, notes that “The absence of conflict is not harmony, it’s apathy.  If you are in a group where people never disagree, the only way that could ever really happen is if the people don’t care enough to speak their minds.” (Grant, February 2021).

However, it is easy to feel at a loss in an immediate conflict situation.  Here are some brief points to consider when faced with more than just a disagreement.

Conflict is emotional: it is much greater than a difference of opinions.  It is usually an expression of not being heard, seen, valued or respected.   It is based on a deeply person need and emotional response, based on perceptions which have identified a threat in any form.  If conflict is ignored, it can fester and result in such entrenched opinions and sides that resolution appears impossible (Segal et al, 2020).

The first step is to determine what the actual problem is as perceived by all parties.  The Conflict Tree analogy is especially useful if you respond well to visuals (O’Connor, 2020).  It is an excellent activity for a group or individual to clarify the effects (branches), core problems (trunk), and even causes of the issue (roots).

Once the actual problem is identified, you can move on to tackling a resolution together.

Approaches to Conflict

There are generally five styles for approaching conflict (Benoliel, 2017) and understanding what they are and what style you lean towards, identifies how you will move through the process.  These categories are determined by whether the focus is on the relationship or the end goal of a task/project.  While these may be more specific to workplace conflicts, they certainly identify personal conflict responses as well.

Collaboration is marked by a balanced focus on the relationship with others and meeting long-term objectives.  A Competition style is marked by individuals who are assertive and probably uncooperative who demonstrate that their priority is the outcome of the project more than the relationships.  Although few people enjoy conflict, the Avoidance style focuses on the the immediate unpleasantness and therefore avoids the issues.  This traditionally marks individuals who are unassertive and uncooperative largely because they assume it is safer to ignore than face an issue.  Sometimes there are individuals who will do anything to please others: this Accommodation approach results in self-sacrifice and is usually the route taken by those who care more about the relationship than the outcome.  Unfortunately, they are frequently taken advantage of in their efforts to please others.  Lastly, there are those who prefer the Compromise strategy. This may seem expedient in the attempt to resolve the problem by aiming for mutually acceptable terms and concessions, it does frequently leaves no one side satisfied even though it allows most to maintain an assertive and cooperative stance.

Strategies for Solutions

Sometimes those involved in conflict turn to an third person for assistance to resolve a conflict.  A mediator can listen to the perspectives of those in the dispute and focuses on helping each side hear the concerns and priorities of the other.  Working with the individuals in conflict, a mediator aims to help them create a solution acceptable to both sides.  Sometimes the third party is an Arbitrator whose role is to hear each side and provide a decision to resolve the dispute.  In some cases the conflict results in the even more formal process of a trial.

There are four key skills you need to approach conflict resolution with or without a third party involved (Segal et al, 2020; Fighting Fair, n.d.).

Conflict can be a very stressful experience and your Stress Management is an essential first step.  When we are stressed, we can’t think clearly, we can’t understand someone else’s thoughts or feelings, and it makes communication very difficult.  Use whatever method works best for you to manage your stress.

Once your stress is managed, it is easier to exert Control over your Emotions.  Recognize the emotions you are experiencing to assist in your processing the experience without having a purely emotional response.

With your stress and emotions recognized and managed, it makes it easier to recognize and pay attention to the feelings you and the other people express  and you can Identify Non-Verbal Communication.   Much is said without words and body language is a good indication of how the other person feels towards the situation.

Respect each other is standard for every communication situation and essential to remember if you are in a position of conflict.  Personal attacks, or drawing on personal knowledge, has no productive part in conflict resolution.

Many resources may explain the benefits of humour, but caution should be used.  Sometimes an emotional situation is not the best time for humour as you can unintentionally be seen to diminish the importance another person places on the experience.

Work together to identify the problem by taking the time to see it from multiple perspectives.  Be clear about the desired results and end goal.  Think about the relationships and long term impacts that any course of action may have on all parties.  It takes commitment to resolve a conflict.

Problem Solving

We covered Reflection and Feedback in Chapter 12 and these are essential steps for effective conflict resolution and problem solving. Even the Trial and Error process of problem solving relies on evaluating the success of an action before moving on to another attempt.

Many different approaches to problem solving exist though the basic core approach can be seen across geographic and language borders.  The PDCA approach – Plan, Do, Check, Act – provides the basic four steps process that can be expanded to suit any profession or experience (Plan, Do, Check, Act, 2021).

Problem solving starts with a clear identification of problem.  Then you need to clarify the desired end result.  The development of a plan can be as short or as long as necessary.  Once you have a plan, you have to implement it: Do.  Check is your opportunity to evaluate the success of your plan and make any amendments necessary.  Finally, Act: put your strategy into practice.  An important point to remember is that the reflection and evaluation should be an ongoing part of the solution you implement.

Chapter 13 Check-out:

• Explore Conflict Approaches and Solutions

Remember your last conflict with another person.  How was it resolved?  How would you like it to have been resolved?  What could you have done to implement that change in result?

How do you usually approach problem solving?  How successful has it been for you? 

What, if anything, would you like to change about how you’ve problem solved in the past?

Resources and References

Benoliel, B. (2017). Five styles of conflict resolution.  Walden University.  [Online]  https://www.waldenu.edu/news-and-events/walden-news/2017/0530-whats-your-conflict-management-style

Fighting Fair to Resolve Conflict. (n.d.).  Counselling and Mental Health Centre. University of Texas at Austin. [Online] https://cmhc.utexas.edu/fightingfair.html

Goleman, D. (April 2012). Daniel Goleman Introduces Emotional Intelligence .  Big Think. [Online] https://www.youtube.com/watch?v=Y7m9eNoB3NU

Grant, A., (February 2021). The Easiest Person to Fool .  The Hidden Brain. NPR Podcast. [Online] https://hidden-brain.simplecast.com/episodes/the-easiest-person-to-fool-f1hbMrGr

Grant, A., (April 2021). The Science of Productive Conflict . TED Podcast. [Online] https://www.ted.com/podcasts/worklife/the-science-of-productive-conflict-transcript

O’Connor, T., (October 2020). 3 Simple Conflict Analysis Tools That Anyone Can Use. [Online] https://medium.com/p/c30689757a0d

Plan Do Check Act: A Simple Problem Solving Methodology. (2021).  Educational-Business-Articles.com [Online] https://www.educational-business-articles.com/plan-do-check-act/

Segal, J., Robinson, L., and Smith, M. (2020). Conflict Resolution Skills. Helpguide.org. [Online] https://www.helpguide.org/articles/relationships-communication/conflict-resolution-skills.htm

Media Attributions

• Brain Ponder © Luc Grenier

Copyright © by Wendy Ward is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License , except where otherwise noted.

Share This Book

• Prompt Library
• DS/AI Trends
• Stats Tools
• Interview Questions
• Generative AI
• Machine Learning
• Deep Learning

Problem, Symptoms & Root Cause Analysis (RCA) Examples

Last updated: 30th Jan, 2024

Have you found yourself stuck in a cycle of solving the same or similar problems over and over again? Ever wondered why some solutions seem to only offer a temporary fix? Have you wondered if you have identified the correct problem or if you are trying to fix one of the symptoms? The key lies in your understanding of how we define problem statements, associated symptoms, root causes , and approach to problem-solving , which is fundamentally rooted in analytical thinking and critical thinking . What exactly is the difference between a problem and its symptoms ? And why is it crucial to conduct a root cause analysis to arrive at a lasting solution?

In both personal and professional spheres (workplace), the ability to identify correct problems and solve them is highly valued. Often, the issues we face are more complex than they first appear. Simply treating the visible symptoms of a problem rarely offers a lasting solution . This is where analytical thinking comes into play . Understanding the difference between a problem and its symptoms, and the role of root cause analysis in identifying and solving the actual problem, is a cornerstone of analytical thinking. This blog aims to throw light on these distinctions and demonstrate the importance of root cause analysis, empowering you to approach problems with a more analytical mindset for enduring solutions.

Table of Contents

What is a Problem?

In the context of problem-solving, a “ problem ” is a situation or condition that represents the obstruction for an entity (a person or a thing) to remain in or achieve the desirable or ideal state of being. Problems can also be referred to as “ challenges “. For example, a company aims to achieve a 20% increase in sales revenue by the end of the year. The problems or challenges that the company may face can be some of the following:

• Determining whether the product is not positioned correctly, and then coming up with the most apt product positioning in the manner that matches the needs of the customer
• Analyzing marketing strategy, identifying gaps, and coming up with a marketing strategy to reach out to potential customers matching the product positioning
• Create a potential customer pipeline from which X% can convert into the real ones
• Determine a sales strategy that can help make the sales to the potential customers.
• Determine the most apt communication channels for the potential customer to reach out and enquire
• Need for timely and cost-effective customer service

When the entity is moved to the ideal state (positive change) or most desirable condition, the problem stands resolved . The thing that takes the entity from an undesirable to a desirable state is called the solution .

Often, what we initially identify as a problem turns out to be merely a symptom of the underlying problem (or root cause). Symptoms of a problem can be understood as the indicators of the underlying “real problem”. Unlike symptoms , which are mere indicators or manifestations of the problem or real problem , the real problem itself is the root cause that leads to the observable symptoms. It is very important to discern between the symptom and the real problem. If not done well, there is a risk of solving the “ symptoms ” when you think that you are solving the problems.

Here is a problem vs symptom example . When you have a cough problem, it is important to differentiate between whether a cough is a problem and take medicines for it, or, if a cough is due to some lung problem and take the medicine to cure that lung-related problem.

Here is another example to understand problem vs symptoms . Let’s say, when a business is experiencing declining sales, one may call out the problem as “declining sales”. However, the “declining sales” is merely a symptom. The actual problem or the root cause can be traced to poor customer service based on the root cause scenario. It is the core issue that needs to be identified and resolved to bring about a positive change.

What are Symptoms? What’s the difference between Symptoms & Problems?

Symptoms of a problem are the observable effects or indicators that point towards an existing problem ; they are not the problem themselves. These are the signs that something is wrong, but they often don’t reveal the underlying cause. Understanding the distinction between symptoms and the actual problem is crucial because treating symptoms won’t eliminate the root issue.

The following are some of the problem vs symptom, or, symptom vs root cause examples :

• On the personal front, let’s consider recurring headaches. You might think the problem is the headache itself, but that is a symptom. The real problem or the root cause could be anything from dehydration to stress. Taking painkillers will temporarily relieve the headache but won’t resolve the underlying issue causing it.
• In a business setting, consider declining sales. At first glance, you might think the problem is the product or its pricing. However, declining sales are a symptom. The actual problem or the root cause could be poor customer service or ineffective marketing. Addressing only the symptom by slashing prices may bring a temporary boost in sales but won’t provide a long-term solution

By identifying and treating the root cause or actual problem rather than its symptoms , you can find a lasting solution that prevents the issue from recurring. This approach not only saves time and resources but also promotes better analytical thinking and decision-making.

The following are some of the key differences between symptoms and the problems or root cause :

• Symptoms when resolved can reappear after some time. Problems or root causes when resolved stay resolved.
• Symptoms are evident . They can be easily identified. Problems or root causes are difficult to unearth or determine. They can be deep-rooted .
• A problem can manifest in the form of many symptoms.

What is Root Cause Analysis (RCA)? Why is it needed?

Root Cause Analysis (RCA) is a structured approach for identifying the underlying causes of what is referred to as the problem (symptoms on the surface) . The goal is to find out what, how, and why something happened, thereby preventing recurrence. It’s like a detective’s investigation to find the “criminal” causing the symptoms, which in this context, are the undesired outcomes or challenges.

RCA is valuable because it helps you go beyond treating symptoms to find the real problem. It’s the difference between mopping up a water leak and fixing the pipe that’s leaking. By focusing on the root cause, you not only solve the immediate problem but also prevent similar issues in the future.

For instance, if a company is facing high employee attrition, addressing the symptoms might involve conducting exit interviews and providing compensation packages. However, a root cause analysis may reveal that the real issue is a toxic work culture or poor management. Addressing these root causes would lead to more effective and lasting solutions.

There are various methods for conducting RCA, and the choice often depends on the complexity of the problem and the resources available. Some popular techniques include:

• The 5 Whys : This method involves asking “Why?” repeatedly (usually five times) to drill down into the layers of a problem.
• Fishbone diagram : This visual tool allows you to categorize potential causes of a problem, helping to identify the root cause systematically.
• Analytical thinking : One can break down problems into sub-problems and continue this process until one reaches to most fundamental problems.
• First principles thinking : One can analyze a problem based on final, formal, material, and efficient causes and then repeat the process.

By understanding and applying these RCA techniques, you can develop a more analytical approach to problem-solving, thereby addressing issues at their core and preventing future recurrence.

Process for Arriving at the Root Cause of Symptoms / Problems

The following represents the process for arriving at the root cause of stated symptoms or problems:

• Distinguish Between Problem and Symptom : Your first task is to determine if what has been stated is the problem or merely a symptom of something deeper. For instance, experiencing a headache is generally a symptom, not the underlying problem itself.
• Identify the Underlying Problem : If what is stated is a problem, well and good. However, if you’ve identified a symptom, your next step is to discover what the problem could be. For example, if you’re dealing with headaches, the underlying issue may be something like ill-health.
• List All Observable Symptoms : Expand your perspective by identifying all the symptoms related to the issue at hand. This will give you a more comprehensive view and may provide additional clues about the root cause.
• Generate Cause Hypotheses for Stated Symptoms : Formulate hypotheses for what could be causing the symptoms for the identified problem. This step is essentially a diagnosis . Employ techniques like the “Five Whys” to dig deeper and identify potential underlying causes.
• Test Each Hypothesis to identify the real root cause : For each hypothesized cause, perform diagnostic tests to either validate or negate it. This could be in the form of data collection, interviews, or even controlled experiments. The aim is to gather evidence that either supports or refutes each hypothesis.
• Identify the Root Cause : After you’ve rigorously tested each hypothesis, you should be able to pinpoint one root cause that stands out as the most likely “actual problem” or “root cause” of the issues you’re observing.

Defining Problem Statement

The problem statement should consist of information related to the following:

• Ideal state: The ideal state outlines what the perfect scenario would look like once the problem is solved. This sets the vision and provides a clear goal for problem-solving efforts.
• What : Define the problem precisely. You can use root cause analysis to dig deep into the “What” aspect.
• Why : Identify why the problem is important.
• Where : Specify the areas or departments affected.
• When : Determine when the problem occurs or comes to notice.
• Who : Note who is impacted, either directly or indirectly.
• How : Describe the nature of the impact, be it financial, operational, or emotional.
• Outcome as a result of problem resolution : The outcome section elaborates on what success looks like, linking back to the ideal state. It can include quantitative and qualitative measures that indicate the problem has been solved.

Understanding the difference between a problem and its symptoms is the cornerstone of effective problem-solving. Many times, organizations or individuals get sidetracked by addressing symptoms without ever reaching the core issue. By employing a structured approach, like distinguishing between problems and symptoms, identifying all associated symptoms, formulating hypotheses for root causes , and rigorously testing these hypotheses, you set the stage for finding the actual root cause of the problem. This not only saves time and resources but also leads to long-lasting solutions.

From an analytical thinking standpoint, mastering this approach equips you with a crucial skill set. It helps you avoid the pitfalls of surface-level solutions and encourages a deeper understanding of challenges. So the next time you’re confronted with a “problem,” take a step back and consider: Is this the real issue, or is it just the tip of the iceberg? The answer to this question could be the first step toward effective and sustainable problem-solving.

Recent Posts

• Model Parallelism vs Data Parallelism: Examples - April 11, 2024
• Model Complexity & Overfitting in Machine Learning: How to Reduce - April 10, 2024
• 6 Game-Changing Features of ChatGPT’s Latest Upgrade - April 9, 2024

Ajitesh Kumar

Leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

• Search for:
• Excellence Awaits: IITs, NITs & IIITs Journey

ChatGPT Prompts (250+)

• Generate Design Ideas for App
• Expand Feature Set of App
• Create a User Journey Map for App
• Generate Visual Design Ideas for App
• Generate a List of Competitors for App
• Model Parallelism vs Data Parallelism: Examples
• Model Complexity & Overfitting in Machine Learning: How to Reduce
• 6 Game-Changing Features of ChatGPT’s Latest Upgrade
• Self-Prediction vs Contrastive Learning: Examples
• Free IBM Data Sciences Courses on Coursera

Data Science / AI Trends

• • Prepend any arxiv.org link with talk2 to load the paper into a responsive chat application
• • Custom LLM and AI Agents (RAG) On Structured + Unstructured Data - AI Brain For Your Organization
• • Guides, papers, lecture, notebooks and resources for prompt engineering
• • Common tricks to make LLMs efficient and stable
• • Machine learning in finance

Free Online Tools

• Create Scatter Plots Online for your Excel Data
• Histogram / Frequency Distribution Creation Tool
• Online Pie Chart Maker Tool
• Z-test vs T-test Decision Tool
• Independent samples t-test calculator

Recent Comments

I found it very helpful. However the differences are not too understandable for me

Very Nice Explaination. Thankyiu very much,

in your case E respresent Member or Oraganization which include on e or more peers?

Such a informative post. Keep it up

Thank you....for your support. you given a good solution for me.