Tag Archives: Root Cause Analysis

Are you splurging long-term dollars for a short-term fix ?

Diagnosing the root cause of a problem is a critical analytical skill. Most often, what you see is not what you get – the symptoms might indicate something, but the root cause might be entirely different. Some cases require a short-term fix – an immediate one, while some require careful investment in the long-term to completely eliminate root cause of a problem. Generally, most problems require a combination of the two. While ‘Process Pundits’ favor a long-term, preventive action, the action-oriented Cowboys can’t wait for eternity and want some short-term, immediate corrective fix to the problem, even if the problem resurfaces a few weeks later. In a way, the corrective-action Cowboys are like John Keynes, who said: “The long run is a misleading guide to current affairs. In the long run we are all dead”. After all, of what possible utility would be a long-term investment if we are not around, say, next quarter. So, no arguments that an immediate need must be addressed first and foremost, but it is like the proverbial firefighting – lack of preventive action eventually leads to emergencies that simply need a big fire hose to douse the fire. Initial trivialization of small incidents only leads to benign neglect which eventually deteriorates into a full-fledged Frankenstien of problems that simply refuse to die.

If initial and repeated trivialization is bad, so is other end of the spectrum – taking every problem far too seriously and calling the army when a watchman will do. In a zest to solve problems, we sometimes make them appear larger than life, and then find solutions that would perhaps address every exception condition, every nook and corner – mindless of the fact that for perhaps 80% of the times, a 20% solution could have done. The result is wasted money, time and effort, and an overbureauracratic process that stifles not just creativity but even the work itself. Look at what happens to our bus driver in this nice story when he takes the problem a little too far: 

One fine day, a bus driver was driving his bus along the regular route. No problems for the first few stops, a few people got on, a few got off, and things went generally well.

At the next stop, however, a big hulk of a man got on. Six feet eight, built like a wrestler, arms hanging down to the ground.

He glared at the driver and said, “Big John doesn’t pay!” and sat down at the back.

The driver was five feet three, thin and basically meek. Naturally, he didn’t argue with Big John, but he was not happy about it.

The next day the same thing happened. Big John got on again, said, “Big John doesn’t pay!” and sat down. And the next day, and the one after that, and so forth.

This irritated the bus driver, who started losing sleep over the way Big John was taking advantage of his size.

Finally, he could stand it no longer. He signed up for body-building classes, karate, judo and all that good stuff. By the end of summer, he had become quite strong.

So the next Monday when Big John got on the bus and said, “Big John doesn’t pay!” the driver stood up, glared back and screamed, “And why not?”

With a surprised look on his face, Big John replied, “Big John has a bus pass.”

Moral: First, be sure there is a problem before working hard to solve one.

Can we relate this story to something at workplace?   Are we sometimes guilty of ‘goldplating’ a problem – perhaps to get enough management attention, or to get enough resources, or simply to promote our interests in the organization ? Goldplating of requirements is a perennial problem for a product manager (or the engineering team – depending on what camp you are from :)). Then again, haven’t we seen the second-time architect syndrome – the architect tries to play so safe to avoid all the problems he faced in his first architecture that the second one becomes a virtual fort – and ineffecient in the short run and quite clumsy in the long run. What about testing ? In last ten years or so, I have seen a dramatic shift in the testing philosophy. From the goal of “good software”, the software industry seems to have gradually moved to “good enough software” and finally to “good enough to ship software”. Look at the amount of patches that download into your system everytime you are connected to the net. Granted that the problem complexity is perhaps a few notches higher than before, and internet has specially made it easier to shorten the feedback look from end-users, but I am sure there is life in between two extremes. No one could test a software forever, but customer surely can do with a little better software :).

So, what do you do when you see a problem? Do you percieve that to be a ‘trivial’ problem and choose to ignore it till it grows tall to your eye-level, or you simply get into a panic mode and raise the emergency alarm? Or, you treat a long-term problem with patches and quick fixes in a hope that sustained amount of small efforts can eventually move the mountain. They sure can, if you are willing to wait for a while. Or, finally like our bus driver friend, you choose to fix a short-term problem with long-term efforts only to realize that you have not only been taken for a ride, but also lost most valuable resource of them all – time. I think the wisdom is in keeping options open until the time it becomes critical to take a call, but institute mechanisms for periodic checks and balances lest you are sent on a wild goose chase.