Naming the Right Problem to Solve

Our cultural bent is toward action, toward fixing things, toward results. And doing it now! That pressure leads to a variety of unfortunate practices that dilute our effectiveness.

As difficult as the problems are that we might face, the more difficult task is choosing the right problem to focus on in the first place. The following questions are intended not only as a prompt for your own thinking, but as a template for making your case to your colleagues. You will probably find most of them useful, but feel free to skip one if it does not seem to relate well to your particular situation.

Without presuming a solution, what exactly is happening?

We often introduce a problem by hinting at the preferred solution, such as “We don’t have a long-range view” or "We don't communicate well enough". Even if such statements are true, they fail to define the specific events that deserve attention. For that reason, they pre-empt a discussion of alternate solutions for a better-named set of symptoms.

The goal here is to be as specific as possible. Here’s a test: The stated symptoms should be recordable by a video camera. This leaves out attitudes, beliefs, or imagined shortcomings (none of which are directly observable). Translate everything into the observable events from which these less visible things might be inferred. For example, “low morale” might mean very different things to different observers, so be specific about the behaviors that give you that impression.

As you try to capture the symptoms, consider the following:

• When are the symptoms most likely to occur?
• When might they be absent? Delayed? Reduced?
• Is there a sequence of similar events over time, a trend?
• How long have we been seeing these symptoms?
• If the symptoms have been around for a while, why are we considering them problematic now?
• Is there a group for whom these symptoms are not a problem? What is different about their perspective?

Why is the problem important?

What would happen if we did nothing?

Remember that the impact of a problem can be in a variety of currencies. There may be. . .

• Failure to reach a strategic objective
• Loss of key capability
• Dollar loses
• Lost market share
• Damaged market reputation
• Legal liability
• Worsened customer relationships
• Damaged credibility with employees
• Loss of key talent
• Compromised supply chain or vendor relationships
• Some noxious consequence for the environment
• Soured relations with surrounding community

The impact may be further broken down into immediate consequences vs. medium- or long-term consequences. We are often blind to the long-term consequences of our immediate behavior.

And sometimes there is an immediate advantage offset by a larger, but delayed cost. For example, a company can make their “quarterly numbers” but compromise systemic capability in the process, or lose key employees because of undue stress.

What lessons should we learn from earlier efforts?

The initial efforts to solve a problem usually use the traditional and most obvious strategies. And there’s every reason to use such an approach! Those strategies just might work!

But when they do not, it often reveals a subtlety to the problem that we had not considered.

• A training program might fail because there are no structural rewards for the new skill.
• A process improvement effort might fail because the culture is too hierarchical or too competitive to support cross functional collaboration.
• A clarification of “roles and responsibilities” might fail because the work is so variable that innovation and flexibility are the real requirements.
• An effort to shift the culture might fail because the CEO refuses to temper his or her own egregious behavior.

Each example merely highlights a new dimension to the problem, one that should help shape the next round of interventions.

Is this just the tip of an iceberg? Or have we already gone too far?

Are there other symptoms we should cluster together with our initial set? The initial concern might have been the perennial fight between Marketing and Engineering about product features. But what about the fights between Engineering and the Service department about resolving customer complaints? Is that another instance of the same problem, or is it separate?

Two of the most common stumblings in identifying a problem are (1) making a mountain out of a molehill, and (2) making a molehill out of a mountain. It's easy to see something too simplistically; it's equally easy to imagine it's part of something epic.

So it’s best to explore both options explicitly.

• Is there a straightforward, simple way of casting the problem that should be explored before making it more complex?
• Is there a broader perspective within which the problem makes more sense, and there are more powerful points of leverage?

Can we get at the problem?

Suppose you (as the Dean of Students at an ivy league university) are concerned about the increase in cheating among your students. But the problem only comes to you after the fact, after the student has been caught cheating on a test, or turning in a plagarized paper. You could do any of the following:

• Punish students who are caught in a way that publicly demonstrates the University's commitment to high ethical standards
• Coach faculty on how to explain their testing procedures
• Speak with students during their freshman orientation
• Coach Resident Advisors on how to spot cheaters early and counsel them
• Push for more ethical criteria in the admissions procedures
• Join forces with other colleges to influence high school curriculum and student advising
• Working with existing foundations that serve families to strengthen moral development in early childhood

While any strategy might make sense, they differ radically in their cost, their likelihood of immediate impact, and the degree of control the Dean of Students could exercise. But the range of options demonstrates the importance of deciding where you try to touch the issue. The options that are within your control might be tepid at best in their likely impact. Do we treat the symptoms when they occur? Or work to prevent them in the first place? These are all legitimate issues in the Naming phase.

Who has to be included in the change?

Stakeholders can contain at least 5 distinct groups:

• Those affected by the problem (customers, employees, vendors, etc.)
• Those with the key information or experience for unraveling the problem
• Those with the organizational authority to command the needed changes
• Those who provide the financial resources
• Anyone who defines the conceptual climate by imposing preferred models to use or other conceptual parameters; typically players of either financial or positional authority

There may also be some who are likely to oppose changes in the problem area; it is best to bring them into the stakeholder group, where their opposition can be translated into a positive contribution (after all, there’s probably a substantive reason why they might resist change).

Not every stakeholder needs to be a working member of the problem solving group, but their perspective should be represented in a way that is satisfying to them. A focus group or survey might be sufficient.

What would a solution look like?

Without pointing to a particular solution, name the criteria that would have to be met by any proposed solution. The criteria might be in terms of . . .

• overall cost
• speed of implementation
• consistency with existing culture (or alignment with a more desired culture)
• acceptability to Legal (or Sales, or Engineering, or IT)
• acceptance by employees
• visibility to market
• high likelihood of success
• supportable with our current IT systems
• acceptability to external regulatory agency (FDA, County Board of Sups, OSHA)
• or a variety of technical requirements.

It is easy for a results-oriented manager to slip into prescribing the solution, which absolves the staff of any responsibility for the outcome, and pre-empts any creative thought of their own. Staff may actually pull for your preferred solution, especially if they imagine you already have one in mind. In short, you start micro-managing.

The way out of this conundrum is to focus on the criteria for a solution rather than just describing the solution you want. Sometimes the easiest way to surface criteria is to acknowledge the solutions you are leaning toward, but then highlight the features of that solution that make it attractive. For example, you might be imagining an all-day training, but what’s really important to you about that option is that it would surface the wide disagreement you know exists among the staff involved. So, in fact, any solution that incorporated that feature would be fine with you. Or perhaps you’re favoring an off-the-shelf software solution. But what’s really attractive about that idea is the speed of installation. And any solution that could be implemented quickly would be satisfactory. Incidentally, once you state a criteria out loud, you may realize that there are faculty assumptions in your preferred model. An off-the-shelf software solution is often vulnerable to a long list of time-consuming complexities.