Solving the Right Problem

The way of thinking discussed here follows from understanding the essence. This section is relevant to all requirements analysts, regardless of the size of the project or the degree of agility.

You have heard the old joke about the drunk who is looking for his keys under the lamppost at night. The kindly policeman stops to ask if he can help. The drunk tells him he lost the keys a block or so away, but he is looking for them here "because the light is better."

We have seen real-life adaptations of this scenario: The project team sets out to build some whiz-bang product. The product is built but somehow, despite the project team's enthusiastic cheerleading from the sidelines and the expense of building it, the users never seem to put it to use. Why? Because it solved the wrong problem. Why didn't the team build a product to solve the right problem? Because for the problem the team did solve, the "light was better." The team members looked for solutions where the light was brightest, but ignored the shadowy corners where the real problem lurked.

One of our clients, a financial institution, was looking into building a new system that would allow passwords to be reset more efficiently. This task posed a major problem for the organization, as the cost of establishing its customers' bona fides before resetting their passwords was running at several million dollars per year. The proposed new system would reduce some of the cost. But what is really happening here? The system producers are looking where the light is bettera slick new system to establish bona fides more effectivelyand not into the dark corners. The real problemthe one they are avoidingis that customers forget their passwords.

Gause, Don, and Jerry Weinberg. Are Your Lights On? How to Figure Out What the Problem Really Is. Dorset House, 1990.

Discovering the right problem to solve appears to be harder than building a new system: It's finding a way for customers to remember their passwords. Of course, if you read what we said about essence earlier, you will by now be saying, "Hold it! Passwords are a technology for doing something, not the essence." Passwords are not part of the business problem; they are the bank's chosen technology, and they now appear to be a less than perfect solution.

Jackson, M. Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley, 2001.

The right problem to solve is this: Allow customers secure access to their accounts, and do so in a way that does not require prodigious feats of memory on the part of the customers.

We usually set out to solve the wrong problem when we begin a project by thinking about the product and not the work, or by not having a sufficiently large work scope to begin with. By focusing inward, on the proposed product, the project team fails to see the larger worldthe one that contains the real problem to solve.