Resources

Research

White Papers

Wicked Problems: Naming the Pain in Organizations

by E. Jeffrey Conklin & William Weil

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. -Laurence J. Peter

There is a subtle but pervasive pain in organizations. You can recognize it in such complaints as "How am I supposed to get my work done with all these meetings?" and "We always have time to do things over again, but never time to do them right." It is the pain of expecting things to be one way and repeatedly banging into a different reality. It is the pain of trying to do good work in an environment full of motion and effort but few results.

I was working late one evening when the janitor came in to vacuum the office. I noticed that he was pushing the vacuum cleaner back and forth over some lint on the carpet without getting it up. I smiled and shouted to him (the machine was loud), "It must be frustrating to have to use that vacuum cleaner." He looked at me with a sad smile and said, "Not as frustrating as being told to go back and do it over!" That kind of pain goes all the way up to the executive suite.

The pain stems from a misunderstanding of the nature of the problems we face. We are having to solve a new class of problems-wicked problems-using thinking, tools, and methods that are useful only for simpler problems. That is like trying to use woodworking tools to fix your car. The pain is exacerbated by the fact that people have not distinguished this new problem variety. It is as though we believe the best tool for a tune-up really is a hammer. The pain and frustration are so pervasive they seem inevitable.

Because my janitor friend was not working on a wicked problem, he had an advantage over the rest of us in organizations-he could clearly see that his vacuum was not picking up the lint. When we are working on wicked problems, it is much harder to realize that our tools are failing to get the job done.

Before defining wicked problems, it would be useful to examine how we actually solve complex problems, and how we think we should solve them.

A study at the Microelectronics and Computer Technology Corporation (MCC) examined how people solve problems. The study focused on design, but the results apply to virtually any kind of problem solving.

A number of designers participated in an experiment. Each was asked to design an elevator control system for an office building. All the participants were experienced, expert designers, but none had worked on elevator systems. Participants were asked to think out loud while they worked on the problem. The sessions were videotaped and then analyzed (see Guindon, 1991).

The analysis showed that the designers focused on two areas: understanding the problem and formulating a solution. They tried to understand the problem in two ways:

• By trying to identify the requirements for the system (from a one-page problem statement they were given), and
• By performing mental simulations (for example: "Let's see, I'm on the second floor, and the elevator is on the third floor, and I push the 'Up' button. That's going to....").

Traditional thinking, cognitive studies, and existing design methods all predicted that the best way to work on a problem like this was to follow an orderly and linear process, working from the problem to the solution. Everybody knows that. You begin by understanding the problem, which can include gathering and analyzing data. Once you have specified the problem and analyzed the data, you are ready to formulate-and then implement-a solution. This is illustrated in Figure 2.1. In the software industry, this is known as the waterfall model because it suggests a waterfall as the design flows down the steps.




Figure 2.1 Traditional wisdom for solving complex problems-the "waterfall"

This is the pattern of thinking that we all assume we follow when faced with a problem. The conventional wisdom is that the more complex the problem, the more important it is to follow this orderly flow. If you work in a large organization, you have probably seen the waterfall model of problem solving enshrined in policy manuals, text books, internal standards for the design process, and the most advanced organizational tools and methods.

In the MCC study, however, the designers did not follow the waterfall model. They would start by trying to understand the problem, but would immediately jump to formulating potential solutions. Then they would go back to refining their understanding of the problem. Rather than being orderly and linear, the line plotting the course of their thinking looked more like a seismograph for a major earthquake, as illustrated in Figure 2.2. We call this pattern both chaotic, for obvious reasons, and opportunity-driven, because in each moment the designers are seeking the best opportunity to progress toward a solution.




Figure 2.2 Actual pattern of problem-solving activity of one designer-the "seismograph"

These designers were not being irrational. Their thought processes were something like this: "Let's see, idle elevators should return to the first floor, but then you only need one elevator on the first floor, so the others could move to an equitable distribution. But the elevators need to be vacuumed regularly. I suppose we could add a switch that brought idle elevators down to the first floor. But then what does that do to our energy efficiency? I need to reevaluate the requirements." What drove the flow of their thoughts was an internal drive to make the most headway possible, regardless of where it occurred, by making opportunity-driven leaps in the focus of their attention. Precisely because they were being creative, the flow of their thinking was full of unpredictable leaps.

Figure 2.2 also shows that problem understanding continued until the very end of the experiment. In observing people working on design or planning problems, our experience is that their understanding of the problem continues to evolve as long as the project does. Even as the design or plan is being implemented, the nature of the problem, the "real issue," continues to change and grow.

The natural pattern of human problem solving appears chaotic on the surface, but it is the chaos of an earthquake or the breaking of an ocean wave. It reveals deeper forces and flows that have their own order and pattern. The non-linear pattern of activity that expert designers follow gives us fresh insight into what happens when we work on a complex problem. It reveals that in normal problem-solving behavior, we may seem to wander about, making only halting progress towards the solution. This non-linear process is not a defect, not a sign of stupidity or lack of training, but rather the mark of a natural learning process. It suggests that humans are oriented more toward learning (a process that leaves us changed) than toward problem solving (a process focused on changing our surroundings).

Most people are not surprised to learn of the non-linear pattern of problem solving. But the MCC Elevator Study is significant because, for the first time, we have a model of the process that people actually follow when they tackle hard problems. And it is not the orderly, linear process we have assumed is proper.

Of course, linear processes are quite appropriate for solving many problems, such as computing the square root of 1239 or choosing the shortest route to the new mall. But within organizations-such as corporations, institutions, and government-where lots of people work on complex issues, people are encountering a new class of much more difficult problems. We call these wicked problems because of the dynamic and evolving nature of the problem and the solution during the problem-solving process. It is these problems that the techniques described in this book are especially useful for solving.

Wicked problems have ramifications that make them difficult to solve. (See the papers by Horst Rittel in the bibliography for historical detail.) A wicked problem meets the following criteria:

• The problem is an evolving set of interlocking issues and constraints. Indeed, there is no definitive statement of the problem. You don't understand the problem until you have developed a solution.
• There are many stakeholders-people who care about or have something at stake in how the problem is resolved. This makes the problem solving process fundamentally social. Getting the right answer is not as important as having stakeholders accept whatever solution emerges.
• The constraints on the solution, such as limited resources and political ramifications, change over time. The constraints change, ultimately, because we live in a rapidly changing world. Operationally, they change because many are generated by the stakeholders, who come and go, change their minds, fail to communicate, or otherwise change the rules by which the problem must be solved.
• Since there is no definitive Problem, there is no definitive Solution. The problem-solving process ends when you run out of time, money, energy, or some other resource, not when some perfect solution emerges.

Here are some examples of wicked problems:

• Should we route the new highway through the city or around it?
• Formulate our mission statement.
• Should the U.S. send armed forces to defend _________ (fill in the current hot-spot country)?
• Determine the features of our next product.

To distinguish what makes a problem a wicked problem, let's consider one of these examples-determining the features of a new car-in light of the criteria for wicked problems:

• You don't understand the problem until you have developed a solution. In the design of a car, some features interact with other features. If you add structural support in the doors, for example, the car is safer from side impact, but the added weight increases the cost of the frame, changes the fuel economy and ride, and requires an adjustment to the suspension and braking systems. Making the car safer also impacts marketing, raising issues such as pricing and demand-"How much do people really care about side-impact survivability?" All these problems interact. Once you get a list of potential features, you can begin to explore the conflicts among them. And at some level in the organization, someone needs to ask, "Should we produce this car at all?"
• There are a number of people who have something at stake in how the problem is resolved. In designing any product, there are two clearly defined and opposing corporate camps: the people who know what is needed (usually in Marketing or Sales) and the people who know what can be done (usually in Engineering or Manufacturing). Virtually all product features and design problems fall squarely into both camps. One side argues that there is no point building the product if it doesn't have Feature X; the other argues that Feature X is so expensive, complex, time consuming, untested, or otherwise impossible that it should not be tackled on this project. Management has its own stake in these decisions, as do many others in the organization. Some key stakeholders, such as customers and regulatory bodies, are generally not even represented in the design meetings.
• The constraints change over time. Almost all solutions have the constraints of time (the problem must be solved before some critical date, condition, or event) and money (the solution must be cost effective). Quality is usually another key constraint. In the case of car design, some decisions, such as the addition of side-impact reinforcements, might be forced by unpredictable constraints, such as the need to impress a politician or a Wall Street analyst with the company's commitment to safety.
• The problem-solving process ends when you run out of resources. Whatever is finally decided, it will be hard to claim that it was the right answer. No amount of study, laboratory experiments, or market surveys will indicate the ideal solution. At some point, the design team will have to make a decision. Inevitably, once the car is produced, critics will point out that the doors are heavy and difficult to open, while people injured in side-impact accidents will file law suits against the company.

As was stated earlier, not all problems are wicked. A tame problem is one for which the traditional linear process is sufficient to produce a workable solution in an acceptable time frame. Traditional problem-solving methods are adequate for any of the tame problems encountered in organizational life. Unless we can distinguish between tame and wicked problems, however, we are doomed to using tame problem-solving methods on all our problems. The result is frustration and ineffectiveness.

It can be difficult to recognize a wicked problem. Many problems appear tame, but are not. Confusion and disagreement among the stakeholders are signs that the problem on which you are working is, in fact, wicked. If the process goes on for weeks, months, or years without any real progress, chances are that the problem is wicked. With practice and the right tools, you will get better at spotting wicked problems early, and using the appropriate problem-solving approach.

When our company first embarked on writing a mission statement, it seemed like a fairly tame endeavor. We would get the executive committee together, come up with a general statement about who we are and where we want to be, throw in a few high-minded values statements, and get someone to polish the grammar and pick a nice font. It would be a day's work.

We ultimately spent two days just trying to distinguish between a mission statement, a vision statement, and a slogan, and another day deciding which we really needed. We spent months determining what business we are in, and realized that we needed to include the board and our customers in the process. We then realized that the most critical stakeholders were the employees, so we scrapped everything and turned it over to them. The problem was never "solved" to anyone's satisfaction. We have a mission statement today only because our CEO gave us an ultimatum with a date.

Once you begin to see the difference between tame and wicked problems, you wonder why everyone does not see it. You notice that business and government persist in applying inadequate thinking and methods to solving problems. One reason they do is that it is possible, in fact easy, to tame a wicked problem. To do so, you simply construct a problem definition that obscures the wicked nature of the problem, and then apply linear methods to solving it.

For example, suppose we are trying to decide whether to route a new highway through the city or around it, and we base our decision on an analysis of construction costs and traffic flows. Because they make the process too confusing and time consuming, we ignore environmental impacts, residents' desires, and impact on historical sites. We have tamed the problem, and will make the decision on time. Of course, our solution will be no more once the regulators issue an injunction, or members of the historic society lay down in front of the bulldozers in protest. But, by golly, we're moving!

Given the human tendency to simplify and abstract, it is easy to see why we are prone to tame problems into a linear framework. Taming a problem can of course be effective, if you do it in the context of wicked-problem solving. But unless you can distinguish between tame and wicked problems, you may tame the problem inappropriately. When all you have is a hammer, everything looks like a nail.

Wicked-Problem Solving Is Inherently Non-linear

Modern man has developed a kind of Gallop-poll mentality, relying on quantity instead of quality and yielding to expediency instead of building a new faith. -Walter Gropius
The traditional linear approach to problem solving-in which we gather data, analyze it, formulate a solution, and implement that solution-is rooted in a linear and mechanistic view of the universe. This view has served human beings well for centuries, but no longer allows us to meet the demands of the world as it is now. (We will explore this shift in Chapter 4.)

The problem with the linear problem-solving approach is that it obscures the real underlying cognitive process, as the MCC Elevator Study showed. We think that we should think linearly, but we don't. It is a handy fiction, one that is even serviceable when we are working on tame problems. But, when we try to follow this linear pattern to solve wicked problems, we inevitably run into serious breakdowns. If we suppress or ignore these breakdowns long enough, they will show up in the implementation stage. In wicked-problem solving, the issues that are not considered, or are discovered too late to take into account, will always haunt us in the end.

To solve wicked problems, we need to confront a more complex mass of information than we are used to dealing with, while unleashing creativity and opportunity-driven thinking. It is a more complex and chaotic process.

Given that a wicked problem is an evolving set of interlocking issues and constraints, a linear approach to solving such a problem simply will not work. Opportunity-driven problem solving allows for the natural and spontaneous flow of attention by an individual or group. It permits sudden changes of topic or focus; welcomes new insights, regardless of whether they appear to pertain to the problem or the solution; and allows for the emergence of new pieces of the problem, even if they seem to make the process more challenging.

A wicked problem is an evolving set of interlocking issues and constraints. A linear approach to solving a wicked problem simply will not work.

Of course, going with the flow of wicked-problem solving takes some getting used to. It is like going for a quiet canoe ride and finding yourself in rapids. You perk up and pay attention to cues you did not notice before, and paddle like your life depends on it.

In wicked problem-solving, we have to alter our notion of "progress." Linear methods allow a smooth, straight ride from well-understood problem to final solution. Progress is quantitative, marking distance from our goal. Progress in solving wicked problems is, for the most part, qualitative. It has to do with what we are learning about both the problem and the solution. Moreover, even though you know that you will not discover what the Real Problem is, since there is no Real Problem, you do make progress toward a satisfactory statement of the problem as you work toward a solution.

In particular, those who have worked on large projects and struggled with the immense problem of "requirements volatility" should benefit from knowing that there is no definitive statement of The Problem in wicked-problem solving. Requirements volatility can be summed up as "the darn customer just keeps changing their mind about what they want." It is a serious problem in the aerospace and construction industries, where it is the basis of frequent contractual disputes. The Requirements Document is the supposedly definitive statement of The Problem. Of course, these projects are virtually always wicked problems, so the requirements simply cannot be specified up front and frozen until the project is complete. To insist on this is to ignore the fundamental nature of the design process.

In solving a wicked problem, you have to stop at some point, and declare that "this is the problem we've addressed, and this is our solution." You still make progress; and in the end, you still stop and declare your work complete. In the opportunity-driven approach, however, you pay as much attention to the learning that has occurred as to the elegance of your solution.

One of the sources of pain in organizations, especially for managers and project leaders, is the gap between the linear and orderly progress you and your group are supposed to be making, and the chaotic reality in which you operate. The power of the distinction wicked problems is the freedom you gain by knowing that chaos is inherent in solving the problems you face. With this knowledge, the chaos does not decrease, but
you can let things be the way they are, and stop feeling like something is wrong with you or your co-workers.

Given that many people care about or have something at stake in how the problem is resolved, the process of solving a wicked problem is fundamentally social.

Solving a wicked problem is a fundamentally social process.

Most wicked problems involve lots of stakeholders. In a corporate project, stakeholders could include:

• All the members of the project team
• Upper management
• People in other parts of the organization working on related projects
• People in other departments, like Finance or Purchasing, who have some general oversight function
• External stakeholders, such as customers, investors, partner companies, regulators, watchdog organizations, and organizations in other countries.

What makes wicked-problem solving so challenging is that none of these stakeholders can be safely ignored. Many are involved in defining the problem, and many also add constraints to the solution. Other teams working on related projects have a particularly large stake, because one team's solution is the next team's problem.

No project leader is brilliant or experienced enough to go off and solve a wicked problem alone. It is not even possible to assemble a team of brilliant people to go off and solve the problem, because the moment they go off, they leave behind stakeholders whose input is essential.

The social nature of the process presents problems in our culture, which reveres individual achievement over team achievement. Even as we struggle to develop a culture that values the team player, many people secretly long for tamer problems and the days when an individual's "brilliant solution" was what mattered. In fact, in school, most of us were led to equate teamwork with cheating. Most adults in our culture today are poorly equipped for the complex social interactions that are required to effectively solve a wicked problem.

What is the dynamic of many people working on a wicked problem? Consider what happens when a second designer is added to solve the elevator design problem. This designer's problem-solving process is represented by the medium bold line in Figure 2.3.




Figure 2.3 Pattern of problem-solving activity when a second designer is added to a wicked-design project

While the second designer follows a seismographic pattern of problem-solving activity, just at the first designer did, the line graphing her work is different from the first. Because her background and approach are quite different from the first designer's, the pattern of her attention differs. The two problem-solving patterns may match well at times; but at other points in the project, the designers are in different places and have different views about what to do next. In a typical meeting, they will have to confront these differences, as well as explain why they are not on track with the project (according to waterfall-method expectations). The designers will no doubt dread the meetings, and feel that they are a waste of time. Trying to get people to reason in a way that is not natural for them is like trying to teach a pig to sing. You don't accomplish anything, and you annoy the pig.

If you are the project leader, and the project is in the requirements definition phase, you only count as valid anything that resembles data-gathering. For example, at Point A in Figure 2.3, you are a happy project leader because both designers are working on the requirements. But at Point B, you are trying to focus on high-level design, and your team is elsewhere. One designer is focusing again on the requirements, saying, "We've got to go back to the customer to find out what they really want!" The other has jumped on a solution, saying, "No, look--this is obvious. You just use the pemory widget, plug it in the refofrazitz, and it's a piece of cake!" Your two star designers look at each other as though they are from different planets. You plead for linear thinking, saying, "That's a good idea, Henry-hold on to that point until later."

The designers in this example are using their full capacity for creative and opportunity-driven intelligence. Unfortunately, this is not always possible. Faced with the frustration of wicked-problem solving, some people get fixated on some aspect of the problem or solution. They recognize that that aspect is vital to the project's success, and that it will get mishandled or forgotten unless they make sure that it is not. These people will make the same point, meeting after meeting. Henry, in the example above, will hold onto his idea for using the pemory widget-for weeks, if necessary-until it is time to incorporate it. Without a system to document or capture the full range of thinking and creativity that occurs in wicked-problem solving, people have to remember to keep in existence any idea that comes up out of sequence. Since repetition is one key to memory, project meetings are a ritual of repetition so that nobody forgets an important idea.

Without a system to document or capture the full range of thinking and creativity that occurs in wicked-problem solving, people have to remember to keep in existence any idea that comes up out of sequence. Faced with wicked problems, few people today are able to have meetings be effective. We often hear that there are "too many meetings" and that they don't go well. People identify with a point of view and defend it. Topics are continually rehashed, with little progress and virtually no learning taking place. Side issues seem to consume valuable meeting time.

Even when meetings are wonderful, the nature of a wicked problem is such that there are many points of view-more even than are represented at the meetings. The diversity of these points of view among stakeholders is a source of much of the pain within organizations. Instead of seeing the value of the diversity, we tend to blame others for the chaos, and we question people's competence to explain the disparity. Our backgrounds have prepared us to see and solve tame problems. Confronted with wicked problems, we resort to finger-pointing instead of learning.

If there is a single cause for the complaint of "too many meetings," it is that organizations today are mostly engaged in solving wicked problems. The social nature of the process demands that the stakeholders communicate with each other frequently. This is also the reason behind the mushrooming volume of communications through voice mail, memos, faxes, electronic mail, and bulletin boards. Overall, people complain loudly about the amount of time they spend communicating "instead of getting work done," not realizing that communication is now a necessary component of their work.

The third characteristic of wicked problems-the constraints, such as limited resources and political ramifications, change over time-is in part a consequence of their social nature. The many stakeholders that are part of the process discover new aspects of the problem over time. As a result, they keep coming up with new constraints that reflect their new understanding.

In some cases, stakeholders know the constraints all along, but fail to communicate them. Here is an example that is unfortunately too common. A manager created a team to solve a tough customer satisfaction problem within six months. "I want you to solve this problem," the manager told them, "and I'll back your solution one hundred percent!" Six months later, as the team leader was presenting the team's solution, the manager paled as he realized that there were constraints on the solution that he had thought were obvious, but which the team's carefully crafted solution violated. Explaining the hidden constraints, the manager had to reject the team's solution. He told them to try again, only faster. Members of the team felt disempowered and betrayed, and the manager concluded that this "empowerment stuff" doesn't really work.

The damage done in this scenario could have been lessened had the process been improved, although the fundamental condition still would have existed. The team could have made an interim presentation after three months. At this point, the executive would probably have recognized the constraints that the emerging solution would violate. He could then have communicated these as a mid-course correction. From the standpoint of the project team, however, they would have been halfway through the project when management added new constraints, invalidating much of their work. They would no doubt have been tempted to conclude that their management was inept, when in fact they were all just working together on a wicked problem.

This is one simple example of how stakeholders introduce constraints, changing the overall understanding of the problem. Another source of new constraints is new stakeholders, such as when Marketing gets involved late in a project, or when a partner organization is reorganized and its new leadership changes its thinking on the project. It should be clear that there is no way to prevent the introduction of new constraints to a wicked problem.

There is no way to prevent the introduction of new constraints to a wicked problem.

It is possible to manage the stakeholders' overall understanding of the problem, including the constraints, in a way that minimizes the disruption and rework that changing constraints cause. For example, by tracking the issues and constraints on a project, you can create a display that allows more peripheral stakeholders to monitor the progress of the project. This display must preserve a critical mass of the thought process that went into divining the issues and constraints. This allows stakeholders to spot new or changed constraints as they are introduced. Also, if you keep track of the key decisions and their rationale, it will be easy to review them to see if any need to be reassessed in light of a new constraint. As we will discuss in the next chapter, this kind of tracking of crucial process elements is precisely what the IBIS method provides.

Because of the number of stakeholders, the dynamic nature of the problem formulation, and changing constraints, it is not possible to reach an ideal solution for a wicked problem. Since there is no definitive Problem, there is also no definitive Solution.

Herb Simon, the Nobel-prize winning economist, described this process as "satisficing" (Simon 1969). According to Simon, the nature of the design process is such that it is virtually impossible to find the best solution, because the space of possible solutions is so large. Instead, you stop when you have a solution that is "good enough."

Once you recognize that a problem is wicked, you shift your expectations about the kind of solution that is possible. With a problem as massive as determining the national health care policy, no one expects one final, satisfactory solution to emerge. On simpler, more mundane issues, however, such as creating a corporate mission or deciding which new markets your company should go into, it is easy to be lulled into expecting that, with enough time and thinking, a definitive answer will emerge.

Distinguishing problems as wicked has a beneficial side effect. Most of us yearn to "get to the bottom line" or "get the right answer." We call this the Answer Reflex-you jump to a solution, any solution, when confronted by a question or issue. Once you recognize that the most interesting problems in life cannot be solved definitively, you naturally shift your focus to the quality of the problem-solving process. What results is that you ultimately value learning over getting the right answer. Not only is this more satisfying; in our experience, it also produces better results.

Of course, if you are a project leader, you cannot just drift along, peacefully appreciating how much your team is learning while your deadline looms. You still have to deliver something, be it a plan, a product design, a statement, or a piece of legislation. You still have a deadline to meet, and you have to follow a linear plan to complete your project on time. The waterfall method is a very useful structure for determining your intermediate milestones.

But once you have a system for the opportunity-driven nature of the process-which is what the following chapters describe-you pay attention to such things as:

• What are the issues?
• Who are the stakeholders?
• What are the constraints?
• What are our assumptions?
• What are the key decisions you have to make, and how will you make them?

Managing an opportunity-driven process, you look for the opportunities for breakthroughs, synergies, connections, and allies. You drive for making decisions quickly, even before the team is ready, because you know that decisions and partial solutions will flush out new aspects of the problem. (This approach is called rapid prototyping in the computer industry.) You use meetings as occasions for learning and building shared mental models. You welcome disagreement as a sign that your stakeholders are putting their cards on the table. You use technologies that support communication among the stakeholders, and you promote the value of capturing and sharing soft information, such as ideas, questions, problems, objections, opinions, assumptions, and constraints. You are also managing the production of whatever documents are defined as your interim and ultimate work products.

Perhaps most importantly, you manage the scope of the problem. You determine which stakeholders to include in the process, and how to include them. You also choose which constraints to be ruled by, which to bend, and which to ignore. Since you have a system, you can manage many more stakeholders and constraints than you could have otherwise. In this way, you can make conscious and responsible choices about the scope of the problem.

Using this opportunity-driven process, the team may discover that it has a satisficing solution much sooner than expected. Often, an early wild idea turns into a breakthrough solution. But if the muse does not bless your project with such a breakthrough, you can be sure that either time or money will run out. At that point, you will have a satisficing solution, given the constraints, and you can declare the project complete. You will have created a solution that is operationally optimal with respect to the resources provided and the approval of the stakeholders. To expect more is to live in a fantasy world. Remember: the measures of success for solving a tame problem simply do not apply to wicked-problem solving.

The measures of success for solving a tame problem simply do not apply to wicked problem solving.

Wanted: Tools for Solving Wicked Problems

The pain in organizations has three components:

• The way people work together is unsystematic. Sometimes they work in sync. More often, each has a different focus and a very different view based on that focus.
• People are expected to follow a structured approach to solving problems, even though it does not work with the wicked problems they need to solve.
• Traditional tools and methods are suitable only for solving tame problems. Until now, there has been nothing available to structure the messy, opportunity-driven process that needs to take place.

What makes these circumstances painful is that we do not recognize them. The real problem is that we are tackling wicked problems without knowing it, and without having tools and thinking equal to the task.

The IBIS system can accommodate anything that arises in a project, no matter how complex and dynamic, and regardless of where you are in the project . You can collect requirements, solutions, and criteria at any time, in any order, and keep them coherently organized.

Using the IBIS techniques, you can collect requirements, solutions, and criteria at any time, in any order, and keep them coherently organized.

As the coming chapters explain, a system for opportunity-driven problem solving must capture and support the messy, social nature of the process. It must keep in existence and organize all the ideas, issues, decisions, assumptions, constraints, requirements, and information that the creative people working on the problem generate. It must be able to make all these key elements accessible when they are needed, yet it must be easy and natural to use, so that it can be a transparent part of the process. The next chapter introduces the Issue Based Information System for facilitating and capturing the opportunity-driven problem-solving process.


*Guindon, Raymonde (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, Vol. 5, pp. 305-344.