ATTACKING SYMPTOMS

Have you ever observed someone driving in an automobile to a destination with only a slight idea of where he/she is going? Inevitably they become lost and instead of stopping to ask for directions they keep pushing forward. Maybe, if they're lucky, they'll eventually get to their destination. More likely though, they will become lost. Perhaps you have done this yourself. I tend to believe this is more common among younger people who are more impetuous than their elders who have committed this mistake in the past. Before someone knows where they are going with any certainty, they tend to jump in the car and drive off, a sort of "leap before we look" mentality. Only much later do they admit is was a mistake and they wasted a lot of time going nowhere fast.

This can all be traced back to our temptation to attack symptoms as opposed to addressing true problems. It is analogous to taking an aspirin when we may really need to perform an MRI or Cat scan to diagnose the cause of a headache. Too often in business we tend to attack symptoms as opposed to problems. I see a lot of this in the systems world. To illustrate, whenever a company begins to complain that I.T. projects are taking too long or are too costly, the first knee-jerk reaction is to improve their project management skills and tools. In reality, the culprit is not project management but the methodology they use to execute the project. Think of an assembly line operation; project management simply represents the dials and gauges monitoring the assembly line, it tells us if we are going too fast or too slow and we adjust accordingly. However, if the assembly line itself is fundamentally flawed, project management cannot do anything to correct the problem. Instead of addressing the dials and gauges, we should be reexamining our assembly lines (our methodologies).

I see other examples of this in the systems world where programmers tend to spend an inordinate amount of time patching and rewriting the same software over and over again. Instead of designing software to be reusable, they would rather rewrite it. Another indicator is when you see a ratio of four or five programmers to every systems analyst. This means systems are not being properly designed and the programmers are being given superficial requirements which they must waste a lot of time second-guessing what is needed. They may be fast at writing software but are they truly addressing the correct business problems? Probably not.

A more notable example includes the Health Insurance Bill passed earlier this year by Congress. I don't think there is anybody on either side of the aisle who truly believes this was properly thought out. As for me, I believe they overlooked the fundamental cause of the problem, namely frivolous lawsuits which haunt the medical, pharmaceutical and insurance communities. This glaring omission will inevitably come back to haunt us.

Our temptation to attack symptoms and not problems is an indication why productivity is dropping in this country. As I have written on numerous occasions, there are two aspects to productivity, effectiveness and efficiency, and the two are certainly not synonymous. Whereas efficiency concentrates on speed of execution, effectiveness questions the necessity of the task itself. For example, robotics provides efficiency on an assembly line for executing certain tasks, such as welding, but if the weld is performed at the wrong time or place no amount of speed will improve productivity. The best way to differentiate the two is: effectiveness asks "are we doing the right things?" and efficiency asks "are we doing things right?"

In Japan, it is still important to define the effectiveness of the business, then focusing on efficiency issues. However, this is not the case in the United States who is obsessed with efficiency and committing several errors in the process. Whereas Japan believes in "Ready-Aim-Fire," the Americans tend to practice "Fire-Aim-Ready."

Perhaps the best way to appreciate this symptom/problem phenomenon is to remember the Bryce's Law - "Do not try to apply a Band-Aid when a tourniquet is required to stop the bleeding."

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim's columns, see:
http://www.phmainstreet.com/timbryce.htm

Like the article? TELL A FRIEND.

Tune into Tim's THE BRYCE IS RIGHT! podcast Mondays-Fridays, 11:30am (Eastern).

Copyright © 2010 by Tim Bryce. All rights reserved.