Learn about the technologies behind the Internet with The TCP/IP Guide!|
NOTE: Using robot software to mass-download the site degrades the server and is prohibited. See here for more.
Find The PC Guide helpful? Please consider a donation to The PC Guide Tip Jar. Visa/MC/Paypal accepted.
|View over 750 of my fine art photos any time for free at DesktopScenes.com!|
Get to the Root Cause: Ask "Why" Five Times
One of the keys to truly solving a problem is to first truly understand it. It is easy to observe that too often, people are quick to jump to solve a problem before they really understand what it is. It is easy to see a symptom and think that you know what is causing it, but surprisingly often, if you take the time to explore more deeply you will find that what you thought was the cause is in fact just another symptom, and that the problem lies much deeper within.
One technique that you can employ is borrowed from Japanese manufacturing management theory. This method is used to help identify the real causes of problems that occur on the manufacturing floor. The goal is not to simply correct the effects of the problem, but to find out the root cause of why the problem is occurring so that we can ensure that it will not happen in the future.
One simple way to do this is called asking why' five times. The idea is that by the time you have asked "why" the fifth time, you will be at the root cause. It isn't always that simple, but the exercise can be surprisingly insightful in helping you figure out what is really going on, and can help you avoid "quick fix" solutions that are really just band-aids and don't resolve anything. It is especially useful for tackling chronic problems that show up over and over again in a system; it is less useful for problems that are unlikely to recur.
Here's an example. Let's suppose your hard disk is having a problem with bad sectors showing up. The knee-jerk reaction to this happening is "the hard disk is bad, replace it". Instead, ask yourself:
You can see the general idea; the answers will differ in every case, but it is the process itself that is useful. Another example: imagine an office that has just had a catastrophic data loss due to a PC crashing after an electrical storm. The initially identified cause of this problem was a lack of a UPS on the PC, which would have protected the system from the electrical storm (usually). So the MIS department starts drafting purchase requisitions for UPSes for all the PCs. Instead, if they looked at the problem carefully, they may have employed the following process:
As you can see, the root cause that we came up with here is very different than the cause we saw when we only scratched the surface. This means of course that the solution will be very different as well; it might well make a lot more sense here to spend a small amount of money on training instead of a large amount of money on UPSes for every PC.