Your options, after printing: Home Archives Contact Us Subscribe Community Current Issue

    For all the research into and adoption of step-by-step problem-solving strategies, you might think that all problems can be solved with the right sequence of steps.  It's lulled a whole generation of systems analysts into the belief that every problem can be broken down into constituent parts, separately understood, then reassembled with a composite comprehension.  It's apparent that most people believe "the truth is out there" and if you can't find it, it's because you haven't yet used the right procedure.

    But there are some problems that are so big, so critical and so pervasive they're called "wicked."  They don't lend themselves to the search for Ultimate Truth.  Examples abound:

    These are truly wicked problems, and not just because there are so many divergent opinions about the "best way" to solve them.  In every case, there are consequences...only some of which are known in advance.  There's not only a high likelihood that someone is not going to like the outcome, there's always someone who wants to propose a simplistic fix that ignores many of the important issues.

    Every important social issue and every significant strategic issue in business will—upon inspection—turn out to be a wicked problem.  The easy problems are solved with the analytical tools taught in Business School.  But, wicked problems are seldom considered, and are often dismissed as "political problems," as if they don't deserve serious intellectual effort.  How to compute the net-present value of a future stream of earnings for a new product is an analytical problem.  Finding a good place to build the polluting factory to produce that product is a wicked problem.

    With wicked problems, the process of finding a solution will be intertwined with the process of understanding the problem.  Each time you try a solution, it teaches you something new about the problem.  You simply cannot perform a complete analysis, then implement a solution.  These are not problems that can be solved with a spreadsheet.

    When Horst Rittel coined the term¹ he identified ten distinguishing properties.  In our client work, we've found three sufficient to gain acknowledge-ment that some problems are truly "wicked:"

    Wicked problems, by their nature, are big, tough problems that typically only grow larger with time.  It's the "800-pound gorilla in the corner;" everybody knows it's there, and leaders will acknowledge it as an important issue to be addressed.

    You have a problem; part of what makes it wicked is that the situation will only get worse if you ignore that gorilla.

    Wicked problems have so many interlinked and interacting components that you can't create a list of all possible solutions.  First of all, the problem may not be well understood, and you can't create any meaningful solution to a problem you don't adequately understand.  Secondly, the problem is probably changing as you examine it:  People change, priorities change, external factors like crises, legislation or new science can suddenly interrupt your pursuit of what you think is the best solution.

    Because you can't create a comprehensive list of solutions, you have no way to claim you've found "the best" solution.  There is no "optimum," because invariably there will be some stakeholders who won't be satisfied with each potential solution.

    These are problems with no "Ultimate Truth" at their core.  They often expose ethical dilemmas, and ethical dilemmas are always about two (or more) desirable outcomes that are in mutual conflict.

    Conventional, linear, analytic models are ineffective, yet often inappropriately applied in a vain attempt to find a simplistic solution.  Every "Environmental Impact Statement" document is an example of this phenomenon:  We can only document those impacts we can identify, and often there are factors that will only emerge when we actually begin to change that environment.

    Wicked problems demand we dive into the dark and grope our way along toward acceptable solutions.  We can find solutions that are "better" or "worse," but never solutions that are "right" or "wrong."  This flies in the face of everything we've been taught about problem-solving, and it can be hard to get some stakeholders (e.g., senior management) to sanction the unclear, murky ways of solving these kinds of problems.  Play your hand wrong, and some senior manager with inadequate appreciation of the problems will step in and tell you what to do...and that's virtually guaranteed to fail.

    No matter what you do, once you solve the original wicked problem, you're going to be left with the residue of some unsolved problem(s) you had to ignore and/or an unanticipated consequence of your solution that raises new issues.

    If your team was responsible for deciding to refurbish the housing in an economically depressed area (instead of razing it for a new freeway), you've still got to decide how to solve the traffic problem...and people who live there today might not be able to afford the new housing.  On the other hand, if you drive a freeway through the area, how will you solve the housing problem for the thousands of people displaced?

    Wicked problems are tempting to ignore, because there's no way to assure everyone will be satisfied with the results.  These are, by their very nature, insatiable in their demand for attention:  Create a partial solution, then turn to the next problem.  It's a thicket with no path out.  What's a leader to do?

    Since, as we've said, there's no Ultimate Truth that will solve a wicked problem, pursuit of that goal is futile.  Every time you look at the problem a little deeper, you find a new problem that also needs to be solved.  Every time you consider a solution, you discover undesirable consequences.

    It's tempting to assign a high-powered team the job of solving the problem on a schedule.  Ideally, they'd go off and understand the problem, report back on optimum solutions that are then implemented.  The subsequent failure is attributed to a "poor solution;" seldom to the "wrong problem."

    It's popular to assign a team of independent, objective experts to find a solution.  They'll produce a logical, reasoned document recommending changes, and then present it to affected people for their feedback and consent.  The process of gaining "buy-in" has begun.

    What's most often surprising is the vehemence with which stakeholders reject such solutions.  Their preconceptions, unfettered by the learning experience gained by the experts during their investigations, leads them to believe simpler solutions would be better.  So begins the long process of education and dialog that will transform the original document into something no longer resembles the original.  As a result, the design team feels unappreciated, and stakeholders feel their ideas have been systematically ignored.

    Seeking "buy-in" from affected people is flawed at the outset:  It is built on the premise that the designers have developed some "best" solution and others merely need to be brought around to that way of thinking.  Experience shows that stakeholders resent being considered as mere rubber stamps, and it brings out all their anger and frustration.  "Buy-in" smacks of a paternalistic sales approach.

    Rather than pursuing some elusive Truth, it's always better to find ways to build Trust among those who will be affected.  Engage them in the process, and you can deal with objections early.

    The traditional analysis / design / implement sequence doesn't work for wicked problems.  If you go for "buy-in," there will be a lengthy process of review, seeking consent and approval of the solution by those who'll be affected.  Most often, however, they'll attack the very assumptions and premises on which the design is predicated.  It adds a messy ending to a pristine design.

    Rather, it's important to take a different tack altogether.  Put the messy part of the process up front and engage people in the search for solutions.  You can both leverage more minds while helping people understand why their favorite early ideas might not work for other stakeholders.

    The old approach:  Design it, then get "buy-in."  The new approach:  Engage the stakeholders, and get them to help design it.  It's going to take as long either way.  But the result of building trust will expose more people to the complexities, and they'll help educate others.  As a consequence, they more readily understand why some ideas prove to unworkable, and why their preferences can't be met.

    The extra benefit is that occasionally you'll find someone outside the core design team who has the nugget of an idea that loosens the logjam and leads to a truly "breakthrough" idea.

    By accepting the idea that there will be a messy, unclear and chaotic part of the process, you have the choice to decide whether you want that at the front- or back-end of the process.  Experience demonstrates that if—contrary to traditional wisdom—you do it on the front end you'll generate a better result, and the stakeholders will already be "bought in" when it finally emerges as a solution.

    Above all, in solving wicked problems, the core design team should act as facilitators to the process and engage as many stakeholders as possible.  While they may have excellent design skills, it's always better if ideas come from the very stakeholders who're most likely to affected by the outcome.

    Stakeholders are people who will be affected by the outcome, or representatives of groups of such people.  Sometimes the issue is so compelling that people who actually have no apparent stake in the outcome will volunteer to participate.

    Exclude no one.  When new stakeholders are identified or ask to be included, include them.  If they discover they're not really affected, they'll remove themselves from the process.

    No matter how hard to try, your initial list of stakeholders will always be inadequate.  As the problem description changes and evolves, and as trial solutions emerge, more stakeholders will emerge.

    The goal is to not to control the process, stake-holders, or their contributions, but to build trust among them all.

    Have large meetings, hold small meetings, conduct private meetings with crucial stakeholders.  Have lots of meetings with volunteers.

    Draw stakeholders out, find out what's important to them.  Above all, listen, and acknowledge the value of what they say.  Again, it might not affect the ultimate result, but people who have been heard are the least likely to object in the end.

    Meetings that involve stakeholders need to be conducted in a collegial atmosphere.  In some cases, that's very, very hard to do, especially when passions run high...and sometimes the core design team can become defensive of their own pet positions.

    There are new and important ways to engage stakeholders that have emerged over the past decade, the most powerful of which is called "Dialogue."  It encourages people to reveal their deepest concerns in an atmosphere of total trust and acceptance of each speakers' understanding of the truth.  But, it takes experience to properly manage the process.  Just reading books is inadequate preparation.

    Unless your team has been formally trained in the art of managing group dialogue and dynamics, seek out a professional to lead these meetings.  The art of drawing out hostile people and helping them find common ground is a sophisticated skill that requires lots of experience and a gentle touch.

    Each interaction, each idea must be documented and made available to other stakeholders so they can assess the quality of the process as it evolves.  This is a good time to use a web site or secure intranet (depending on the nature of the problem), so stakeholders can track progress, review work to-date, and determine whether they should themselves become more active to ensure their interests are seriously considered.

    You might even supplement those records with an on-line discussion in which peripheral stakeholders can offer their thoughts and ideas without having to spend time in face-to-face meetings.  It expands the pool of potential contributors and the range of innovative ideas you can add to the mix.  And, it extends the sphere of trust to more people.

    With wicked problems, designs and implementations are intertwined.  So, the design effort is—and will always be—a work in progress.  At stage six (say) of that iterative process, you may start to implement ideas that have emerged...and discover the solution is incomplete and/or creates new problems.

    Solving wicked problems is always an experiment.  There's too much to be known, too many interactions that may be hidden at the outset, too many conflicting demands to be satisfied.  Engage the very people who'll be affected, build trust with and among them, and together, you can move the entire process toward progressively better solutions.

    Wicked problems aren't solved with ready-made solutions.  No matter what you do to improve the system you're changing, you will discover new problems, new information and new opportunities.  You will also make new mistakes, which are usually opportunities for learning in disguise.

    Success in addressing wicked problems utterly depends on a change in attitudes about stakeholders.  Invite stakeholders to actively participate in forging the agreements of what constitutes success, in identification of the real problems, and in the development and refinement of potential solutions.  When stakeholders are part of the process, you'll capture the best ideas, and they'll understand why choices have been made.  That way, they become active partners in achieving success.