Personal Business Skills Articles
Submit Articles Back to Articles
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
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
Keep the Faith!
Note: All trademarks both marked and unmarked belong to
their respective companies.
Copyright © 2010 by Tim Bryce. All rights reserved.
About the Author
Tim Bryce is 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 firstname.lastname@example.org
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2010-08-29 19:12:41 in Personal Articles