6. Referred Pain

The project solves the apparent problem but fails to address its underlying cause.

Referred pain is a term used to describe the condition whereby pain is manifest in parts of the body other than the location of the source. For example, spinal injuries are felt in places other than the spine. Sciatica is a case in point: The patient feels pain in the leg, yet the problem is a prolapsed disc pressing on a nerve in the spinal canal. You can treat the leg as much as you want, but the pain will persist—its underlying cause lies elsewhere. Similarly, a person who suffers a heart attack usually feels referred pain in the left arm. Treating the arm will do nothing to save the patient’s life.

There is a tendency when forming projects to address the obvious problem—the one that is most manifest and causing the most pain to the client. However, by looking only to the referred pain, the project delivers a product that, once delivered, turns out to be largely wasted as it does little to alleviate the real need.

Consider the following example: Bank customers who forget their password apply to the security department to have the password reset. This involves complex and costly processing to authenticate the customer before a new password can be issued. At one U.K. bank, resetting passwords cost in excess of four million pounds per year. A project was formed to build new software that would make resetting passwords easier and cheaper.

This project set out to treat the referred pain instead of the root cause of the problem (too many people forgetting their passwords). Because of a baroque password setup protocol, users ended up with passwords that didn’t stick in their minds and the bank experienced “I forgot my password” requests far in excess of what its competitors were receiving. If the bank had addressed the real problem, it could have—at a fraction of the cost—so reduced the number of requests that the existing password-reset approach would have been quite workable.

One commonly observed reason for treating the referred pain and not the cause is a reluctance to investigate. This is sometimes because of the organization’s culture, and sometimes because pressure is being brought to bear on the project to start delivering quickly: “Listen, I know exactly what I want, so just generate these reports for me, pronto.” In many organizations, it takes a brave analyst to first ask, “If you had these reports in hand, what would you use them for? What are you actually trying to do?”

Sometimes, we want to look where the light is shining brightest. For example, we may look to technologies that we know, seeing the problem in a way that best matches our familiar solutions: Ask a Web services designer how to solve a business problem, and he will typically suggest a Web services solution; ask a database designer, and you’ll get a database solution. Needless to say, either could easily disregard any part of the underlying problem that does not slot neatly into his preferred implementation. Moreover, we may be tempted to look to the most attractive problem to solve—the one that will deliver the coolest product. Either of these could result in the engineer rushing to find an ingenious solution to the obvious or stated problem, but exercising his abilities to the wrong end result.

A strong indicator that you are treating referred pain often involves workarounds. These crop up when the current system shows signs of needing some correction, and instead of correcting the prime system, a workaround—allowing something to go wrong and then fixing the result—is applied to correct the manifestation of the problem. A workaround is a Band-Aid and does little or nothing to address the underlying cause of a problem. Yet when one seems to work, more of them are used, sometimes on top of each other in layers of workarounds. Each time a workaround is used, the Band-Aid appears to be cheaper than surgery.

The root causes of many problems are subtle, and often quite removed from the apparent symptom. However, effort spent investigating the real need, and solving the right problem, is invariably returned severalfold.