Patterns to Promote Individual and Collective Creativity

John C Thomas

IBM T.J. Watson Research CenterPO Box 704

Yorktown Heights, New York 10598 USAjcthomas@us.ibm.comwww.truthtable.com

AbstractTo some, “Collective Creativity” sounds like an oxymoron. In American culture, at least, the culturally accepted icon of creativity is of the lone inventor, struggling against all odds, perhaps an outcast, “swimming against the tide” until she or he is ultimately successful (or not). This story-line is supported by the Patent System which presumes a basic dichotomy between those who “were” and those who “were not” involved in the innovation behind a patent. In classical Aristotelian story, there is a “hero” who overcomes all odds and enemies to become successful in the end. From a social engineering perspective, there is an advantage to the promulgation of such a myth. It might help prevent discouragement from those who are on an exploratory path far from the mainstream. However, the downside risk is that this myth minimizes both the impact of the larger social and cultural context within which innovation occurs and the more local impacts of family, community of practice, and industrial policy. Moreover, even in the unlikely (though appealing) story of an isolated individual breakthrough effort, whether or not that effort influences the rest of society depends on cultural and social factors. The truth lies more in the acceptance of a kind of tension between individual and collective creativity.

Perhaps an apt analogy may be drawn from golf. Tiger Woods is obviously an amazingly able individual combining innate talent with early and persistent training. On the other hand, it would be meaningless to ask “how good a golfer would Tiger Woods be if the game did not exist?” The existence of golf courses, instructors, manuals, traditions, rules, best practices, and an economic infrastructure all support the development of such an individual. On the other hand, it is also true that this particular individual has increased the economic infrastructure for the game generally through his popularity and has increased the number of future players through his foundation. This is a prototypical example. The individual both benefits from and contributes to the social system and the social system both gives rewards to and benefits from those individuals who manifest advances in a field.In an attempt to recognize and facilitate this reciprocal relationship between the individual and the social context (at various levels of scale), we propose a Pattern Language for Collective Creativity which comprises an inter-related set of named recurring problems and their associated solutions. Patterns include: “Who Speaks for Wolf?”, “Small Successes Early”, “Support Conversation at the Borders”, “Special Roles for Special Purposes”, and “Cycle of Unity and Diversity.” A current real-world application of these patterns is to support a community of practice in consulting which requires both flexibility to deal with individual clients and uniformity so that knowledge gained in one arena may be used in another.

1 Background and Motivation

An agent (individual human, group, organization, or software agent) can be said to have a problem if there is a mismatch between the current state and some desired state and there is no pre-existing algorithm for transforming the current state to the desired state. Problems can be categorized according to whether the starting state, the ending state, and the allowable transformations are well-defined or ill-defined. Proving a Euclidean Theorem is an example of a completely well-defined problem while designing a house, a useful software system, a new business process and writing a teaching story are examples of completely ill-defined problems. There are many software tools for helping people solve various types of well-defined problems; however, relatively few tools exist for helping people solve ill-defined problems such as design problems. Yet, design problems are often extremely high leverage problems. For instance, errors in design, whether in software, drugs, business processes, public buildings, or automobiles are extremely costly, compared, for instance, with coding errors or manufacturing errors. Conversely, effective and innovative designs can be extremely lucrative; innovation is one of the hallmarks of long-lived companies (Collins and Porras, 1994; DeGeus, 1997).

The world is changing more quickly but the ability of people to creatively design has not increased in any noticeable way. As a result, there is a widening gap between the degree of flexibility and creativity that is needed to adapt and the capacity of individuals and organizations to do so (Drucker, 1995). In particular, failure to innovate is not random, but can generally be ascribed to two main difficulties: 1. Individuals or groups do not engage in effective and efficient processes of innovative design. 2. The necessary skills, talents, and knowledge sources are not brought to bear on the problem. Laboratory (e.g., Thomas, 1974; Carroll, et. als, 1980; Farnham, 2000) as well as field research (e.g., Carroll, Thomas, & Malhotra, 1979; Olson & Bly, 1991; Poltrock & Englebeck, 1999) over the last several decades has established that the major process difficulties of individuals and groups are mainly due to a limited number of errors and that these errors can be avoided or ameliorated by providing appropriate structure.

The appropriate overall structure for innovation has several sub-steps and structure is necessary both to help facilitate the progress through these steps and to help guide the separate sub-steps; distinct guidelines are appropriate for each of these sub-steps (Stein, 1974; Thomas, 1989). As an example of a common failure in the overall control structure, people typically fail to spend sufficient time in the early stages of design; viz., problem finding and problem formulation (cf. Sobel, 1995). As an example of a common failure during a specific stage of innovative design, people often bring critical judgment into play too early in the idea generation phase of problem solving. As another example, empirical evidence shows that, unlike Newell and Simon’s (1972) normative model of ideal problem solving, in fact, people’s behavior is path-dependent and they are often unwilling to take what appears to be a step that undoes a previous action even if that step is actually necessary for a solution (Thomas, 1974). As a third example, most people find it difficult to generate additional solutions after they have generated one that they feel solves the problems. No doubt, there are cases where time pressure may require this approach, but in many cases, the generation of additional solutions may be critical. Other solutions may not only meet the requirements, but exceed them in various ways. Or, conditions may change in a way that makes the first solution no longer tenable. A particularly insidious type of example occurs in the interpretation of ordinary social interactions. Since human behavior is so complex, we can consider the creation of an interpretation or narrative as a kind of creative endeavor. Consider the following example. You are sitting in a meeting room and note that Fran is not there. The clock reads 10:04 and according to your calendar the meeting is supposed to start at 10:00. You create the following interpretation: “Fran does not really care about this project.” This might be true. According to the Iroquois “Rule of Six” (Underwood, 1999) however, before acting on such an interpretation, one should generate five additional interpretations. In this case, additional solutions might include: 2) Your calendar is wrong. 3) The clock is wrong. 4) Fran comes from a culture where 10:00 means sometime near ten. 5) Fran got waylaid on the way to the meeting by the company President and is currently pitching the project. 6) Fran is stuck in a traffic jam.

Regarding the second issue (bringing to bear necessary skills, talents and knowledge sources), evidence suggests that individuals have a large amount of relevant implicit knowledge which they often will not bring to bear on a problem and that giving appropriate strategies (Thomas, 1974), knowledge sources (Thomas, Lyon, and Miller, 1977) or representations (Carroll, Thomas, and Malhotra, 1980) can significantly improve an individual’s effectiveness in problem solving and innovation. In controlled laboratory experiments, for instance, Carroll, Thomas, and Malhotra (1980) showed that subjects did significantly better in a temporal design task when they used a spatial representation; yet, very few subjects spontaneously adopted such a representation. The impact of felicitous representations, however, is not confined to laboratory demonstrations. Speech research advancements accelerated greatly when waveforms were largely replaced with speech spectrograms and Feynman diagrams allowed similar breakthroughs in atomic physics.

2 Pattern Languages

A Pattern is a recurring problem in a specified context, an analysis of that problem, and the (named) outline of a solution. In its full form, a Pattern consists of several parts: a useful, evocative, and mnemonic pattern name, the author (with reviewer and revision dates), synonyms for the pattern name, an abstract (possibly including an evocative picture), a statement of the problem that the pattern attempts to solve, a statement of the context(s) in which the problem occurs, an analysis of the forces in the problem, the solution (possibly including one or more schematics), some examples of how the pattern might be applied, the likely resulting context(s) of applying the pattern, the rationale explaining how and why the solution works, references to related patterns, reference to some known uses, and a reference section listing any relevant literature. A Pattern Language is a set of inter-related

patterns that deals with some coherent domain. While each individual pattern has utility, a Pattern Language also has emergent utility. A Pattern Language makes an implicit claim about how to partition complex problems into more manageable sub-problems. The structure of the language itself helps designers find those Patterns relevant to the task at hand. Work presented here focuses on the Socio-technical area because technological and social issues must be addressed concurrently. Many failures to reap the proposed benefits of systems come from trying to solve problems either by technology alone or by social practice alone. The first Pattern Language was developed by an architect named Christopher Alexander (Alexander, et. als., 1977). The Pattern Language approach has since been applied to many different fields; first, and most notably to Object Oriented Programming design (e.g., Gamma, et. al, 1995; Vlissides, et. als., 1996). In addition, attempts have been made to build pattern languages in Human Computer Interaction, Business Process Design, Change Management, and Organizing Software Projects. Technological and social support for increasing individual and group creativity may be generalized appropriately through the development of a socio-technical Pattern Language.

3 Patterns for Creativity Enhancement

In this paper, we cannot present an entire Pattern Language for Creativity Enhancement (and, to the best of my knowledge, such a complete Pattern Language does not exist); however, some example patterns are given in outline in order to exemplify such patterns.

Small Successes Early

Abstract: Some problems require large teams of relative strangers to work together cooperatively in order to solve the overall problem. Yet, people generally take time to learn to trust one another as well as to learn another's strengths and weaknesses and preferred styles. Plunging a large group of strangers immediately into a complex task often results in non-productive jockeying for position, failure, blaming, finger-pointing, etc. Therefore, insure that the team or community first undertakes a task that is likely to bring some small success before engaging in a complex effort.Context: A complex undertaking requires the interaction of many people with various backgrounds, skills, and temperaments. Often, whether in an industrial setting or a community building effort, many of these people have not worked together before. The group wants to get started and wants to be successful. Although their diversity is a potential source of strength, at first, there is likely to be natural confusion about how to proceed because people will have different experiences about the best way to organize and proceed. Forces: * Problems are often too complex for all aspects to be addressed simultaneously.* If a problem is understood, it is logically better to deal with the hardest constraints first. * The structure of complex problems often becomes clearer as one tries to solve the problem.* A part of any complex problem solving process requiring more than one person is the interaction and relationship among the people.* People in a new team need to learn about each other's skills, working styles, and trustworthiness.* When people get frustrated because of non-success, they tend to blame each other.* As people work toward a goal, the goal tends to become viewed as more valuable and therefore people are willing to work harder to reach it.Solution: Therefore, when bringing new teams or organizations together, it is useful to begin with a small success. In this way, people begin to learn about each other and trust each other. People learn more about the nature of the problem domain. This makes tackling more difficult problems later relatively easier.Example: At the kick-off to a new software development project, rather than having the people be invited to "attend" an event that is "thrown" for them, encourage them to organize a party, cook-out, pot-luck, song-fest, or storytelling event among themselves. In the process of organizing and carrying out this activity, they will learn about each other's styles, learn about the trustworthiness of others, and be encouraged by having a success.Alternatively, the team might simply work on an aspect of the problem to be solved, provided it is something fairly clear that will result in "success" quickly. For instance, the team might initially work profitably on a short presentation about the project, a poster, or a scenario but not immediately jump into working on a systems design or a requirements document.Rationale: As people experience team success, they tend to view the others in the team more positively. Teamwork

is often hard under the best of circumstances. In highly complex problems, when people come together from different cultures, backgrounds, or agendas, it often becomes so difficult as to seem impossible. Rather than having people simultaneously attempt to solve a complex problem AND at the same time learn to work together as a team, it is often more effective to separate the otherwise tangled problems. First, have the people solve a tractable problem where it is clear that they have a common agenda. A successful experience working together to solve that simple problem will help people learn each other's styles, strengths, weaknesses and so on. With this knowledge and trust, they can now move on to try to solve more difficult problems. Some care should be given to the task and setting. The "small successes early" task should allow some degree of give and take, some opportunity for expressive, not just instrumental communication. People should have the opportunity and space for doing something creative, for sharing stories, for physical interaction.

Support Conversation at the BordersAbstract: In complex business processes, it is often the case that many people and or computer programs in sequence are required to perform the complete process. Designers of business processes try to anticipate the information necessary to flow along these sequences in order to make sure the entire process works consistently. However, in reality, it often occurs that unanticipated additional coordination is required among the sequential components in a complex process. Therefore, across each transition, an additional facility should exist for conversation; that is, the transfer of unanticipated but vital coordinating information. Problem: One would like to have processes that are efficient and effective and lead to customer satisfaction even if the assumptions about the needs for information interchange among sub-processes in a more complex process turn out to be insufficient in scope. Context: Businesses today are always striving to become more efficient. Part of the solution offered for this striving toward greater efficiency is to automate some steps. When a human being is required to perform some steps in the process, most organizations choose to specialize function; that is, train one group of people to perform one function and then “hand off” the process to another group of people that has been trained to perform another function and so on. In fact, the level of integration that organizations strive for now commonly extends across formal corporate boundaries so that various elements in a supply chain attempt to coordinate their efforts. There is no doubt that such larger scale integration can result in greater efficiency. Systems are seldom designed, however, with a complete understanding of every possible contingency that can arise. Indeed, that is probably impossible in principle. What often happens is that systems are designed under a set of assumptions that are often, but not always true. When the assumptions break down, it is important for people on both sides of a functional boundary to be able to have a cooperative conversation in order to solve the problem left by the gap between the actual reality of a situation and the model implied by the system design. Luckily, given the right atmosphere, culture, and incentive structure, people can generally solve such problems. It helps greatly if they have the time and the appropriate space (preferably real, but at least virtual) to keep informal communication paths open through conversation. In this way, when a problem arises, they are much more likely to “bridge the gap” constructively rather than point fingers.

Historically, many organizations have recognized the need for such informal conversational ties and have provided both special places (Officer’s Club; Traditional Pub; Company Cafeterias) and events (Company Picnics; Religious Retreats; Holiday Parties; Clubs) to facilitate such interchanges. As organizations attempt integration across ever wider scales however, providing appropriate venues becomes increasingly challenging. In some cases, two related or sequential functions will report to a single manager. In such cases, the manager may serve part of the communication bridging function. Clearly, however, in complex, multi-step processes, formal management methods alone will be insufficient for coordination across all the boundaries. When links in a processing chain do not converse, inefficiency and poor customer service result.

Forces

* Modern business processes are often too complex to be understood in detail by any single person.* Performance on any task is generally a logarithmic function of time on task.* A person’s time is limited.* Complex systems are typically designed and built by decomposition. * Systems to automate, semi-automate, or coordinate are generally designed by people who are not the people who actually do the tasks.* Designs can never anticipate all contingencies.* Human beings can negotiate to solve novel coordination problems via conversation.

* People find conversation in the service of finding and solving problems rewarding.* People are subject to forming “in-groups” and “out-groups.” * If “in-groups” and “out-groups” are formed, rather than negotiating a solution to a problem that is globally optimal, each group will try to “win” by forcing the solution that is optimal for their sub-function.Solution At a minimum, Time, Space, and Means as well as Motivation must be provided for employees who form a bridge from one step in a process to the next to carry on continuing informal conversation. Employees must have time to carry on such conversations. A space must be provided in which such conversations can take place. If a physical space convenient to both parties is not feasible, some means of support for informal distant collaboration and conversation is necessary. Payoffs must accrue to the parties across a bridge jointly for solving problems, not for proving that the other party is to blame. Examples At IBM Research, I used to play a lot of tennis with other IBMers including an inter-company league. In the course of playing tennis, I met someone in the corporate tax department. I also used a system called ITIRC which returned the abstracts of scientific and technical articles that were predicted to be interesting to me based on a key-word in context search. Such systems are not terribly accurate and I got many false positives. One in particular had nothing whatever to do with my interests; it was about a new federal program that allowed highly profitable companies to trade tax credits with companies that were losing money. Instead of throwing this in the trash, because I had had conversations with Frank, I forwarded the abstract to him who looked into this program and saved a lot of money for IBM. This case illustrates that ideally people with no obvious process connection should be able to converse informally. In planning the first Universal Usability Conference (ACM SIGCHI), it was necessary to delegate various functions to various parties. While, we attempted to plan ahead of time by standard tools such as budgets and project timelines, there were numerous unanticipated problems that needed to be solved. A weekly conference call among all the functional heads allowed us to identify and solve such problems effectively and efficiently. In WorldJam (an on-line 3 day company-wide electronic meeting in which all IBMers were invited to participate; generate ideas and comment on them in ten topics), moderators and facilitators used Babble (an electronic blended synchronous/asynchonous chat) and Sametime (a synchronous chat system) as backchannels to collectively solve problems, as well as to coordinate information among the ten topics.In Hanna Pavillion, a children’s psychiatric hospital in Cleveland, each change of shift is marked by a short joint staff meeting in which any particularly novel observations or issues are discussed so that a continuity of knowledge persists across the shift boundaries (this is common in most medical settings, in fact). In addition, at least some people work double shifts or rotating shifts and get to know people from various shifts. There are ample opportunities for informal conversation during the course of the day as well as in various special outings. On these occasions, staff members can insure coordination of treatment for a specific child across the boundaries of the various nurses, psychiatrists, occupational therapists, and child care workers who interact with each child. Resulting Context In the ideal case, trust and even friendships can develop among people working on related processes even though they belong to different functions and report to different managers. Unanticipated problems can be identified, solutions designed and implemented in a cooperative spirit. As a result, the workforce is more productive and more satisfied leading to lower turnover, absenteeism, and sabotage. Further, the customers ultimately benefit from improved service and feel as though they are dealing with an integrated and intelligent entity and not an uncoordinated collection of selfish “not my job” people. Rationale People are naturally social beings. Conversation with others to solve jointly identified problems is a pleasurable and useful activity. However, people also have a tendency to form “in-groups” and “out-groups” which resist globally optimal solutions. The balance of these opposing tendencies can be shifted by allowing people the time, appropriate space, and lending management support to conversation and informally solving problems without resort to officially escalation.

Radical Co-locationSynonyms“Put the team in one room for the duration of the project”, “War rooms”

Abstract: When small to medium teams of people need to solve a problem or design a novel solution and there are many highly interactive parts, it is useful for the people to work in one large room where people have easy access to each other and shared work objects can be easily viewed, modified, and referred to when necessary.Problem Some problems are amenable to decomposition; that is, the overall problem can be broken down into a series of sub-problems and when each of the sub-problems is solved, the overall problem will be solved, possibly with slight modification to some of the sub-solutions. In other cases, especially problems that are relatively novel, complex, or “wicked”, such decomposition is not possible. If decomposition is attempted and each of the sub-problems is solved, the resulting composition of sub-solutions will not be anything close to an overall solution. Under these circumstances, people working alone on their sub-problem will become frustrated because all the progress they thought they had made will prove illusory. Morale will suffer. Management will become upset that the apparent progress has not been real and typically attempt a variety of counter-productive measures such as requiring more frequent reports and adding new personnel to meet a schedule.Context In the design of complex systems with many interacting parts, it is often the case that understanding how best to “decompose” a problem cannot be determined ahead of time. Examples include complex software systems, especially where the overall system includes human-human and human-computer interaction, new machinery, novel nuclear power plant designs, complex military operations. In such a context, handing out separate “assignments” to various individuals or small teams will at first seem to produce progress as each individual or small team carries out their assignment. Unfortunately, when an attempt is made to compose or integrate these sub-solutions into an overall solution, the result doesn’t work because of unanticipated interactions. For instance, suppose that a software development team is designing an integrated office support package. Independently, various teams or individuals design various functions. Each of these may be well-designed in itself. However, the combination will be flawed on at least three counts. First, numerous functions will have been duplicated in separate modules. Second, some functionality that would have been useful for the whole package will not have been implemented at all because it would have been too much work for any one team. Third, the user experience will be scattered and inconsistent as separate designers make independent choices about what the user experience will be. In addition, it is quite likely that hard bugs will also be in the design due to the inconsistent treatment of data objects, deadlocks, infinite loops, etc. There are two main general solutions common in the software development community. First, there may be an attempt to set “ground rules” or “style guides” that everyone is supposed to follow. These will help ameliorate the problem but cannot solve it entirely. Second, there may be overall project meetings where people report on progress or even do mutual design reviews. Again, this helps but even if problems are found and resolved, the resolution will require considerable rework.

Forces * People are naturally gregarious.* People can concentrate better on difficult mental tasks when it is quiet and when there are a minimum of interruptions.* Some problems are amenable to decomposition into relatively independent sub-problems; others are not.* Social cues can be used as a guide to when to interrupt others.* Having work-related shared artifacts that can be viewed and understood by others continually leads to productivity. * Shuffling work artifacts in and out of view in a small space takes time.* Space costs money and is therefore limited.* A group will tend to develop useful social conventions when they are co-located.* Noticing and resolving conflicts among sub-solutions early will result in minimizing rework.* Noticing common problems and solving them collectively as soon as possible will result in maximum efficiency. * Human performance often shows a “social facilitation” effect; that is, people perform better in the presence of others.Solution When small to medium sized teams work on non-decomposable problems, it is useful for them to be radically co-located in one large room. This room should provide each person some private space and individual work tools (e.g., a computer, a drawing table) as well as numerous spaces for public display of large scale work artifacts (e.g., designs, work plans, diagrams, decisions, group rules, etc.).

Examples: In the Manhattan Project, people from all over the country were relocated to a relatively remote and isolated area. There they had large workrooms to work on complex problems together.Recently, automobile companies have empirically compared software work teams that were radically co-located with traditional software development and found the former to be significantly more productive. Interestingly, although before the experience, people thought that they would hate working in a single room, afterwards they said they preferred it.Resulting Context: Prior to the experiments at the auto companies, developers were afraid that they would be too distracted by noise and interruptions to get much work done. In fact, social cues can be read fairly well and a potential interrupter can gauge the time to interrupt. In radical co-location, a person might have to wait minutes or hours to resolve an issue by conversation and mutual problem solving. In traditional software development, they may have to wait for a weekly meeting or not discover a problem until integration testing. People working under conditions of radical co-location tend to develop common vocabulary and artifacts quickly and can easily and efficiently refer to these artifacts. Motivationally, it is also easier to see where the individual’s work fits into the larger whole. Rationale: In a complex problem solving process, it is most efficient to solve the most difficult constraints first. Similarly, the sooner potential design conflicts or potential design commonalities are discovered, the more efficient the global optimization. Social groups that work together can rely on subtle cues about whether to interrupt or not. Being alone in the office may seem more conducive to concentration but is still amenable to a knock on the door or a phone call; in this case, the person interrupting generally does not know the state of concentration of the person being interrupted. When we work separately, it is easy to imagine that others are “slacking off.” If we actually see all of our colleagues working, it tends to motivate us to work harder as well.

Who Speaks for Wolf?

Problem: Problem solving or design that proceeds down the wrong path can be costly or impossible to correct later. As the inconvenience and cost of a major change in direction mount, cognitive dissonance theory (Festinger, 1957) makes it somewhat likely that the new information will be ignored or devalued so that continuance along the wrong path is likely.Context: Complex problems such as the construction of new social institutions or the design of complex interactive systems require that a multitude of viewpoints be brought to bear. Unfortunately, this is all too often not the case. One group builds a "solution" for another group without fully understanding the culture, the user needs, the extreme cases, and so on. The result is often a "system" whether technical or social, that creates as many problems as it solves. The idea for this pattern comes from a Native American (Iroquois) story transcribed by Paula Underwood (1983). In brief, the story goes as follows. The tribe had as one of its members, a man who took it upon himself to learn all that he could about wolves. He became such an expert, that his fellow tribes-people called him “Wolf.” While Wolf and several other braves were out on a long hunting expedition, it became clear to the tribe that they would have to move to a new location. After various reconnaissance missions, a new site was selected and the tribe moved. Shortly thereafter, it became clear that a mistake had been made. The new location was in the middle of the wolves’ breeding ground. The wolves were threatening the children and stealing the drying meat. Now, the tribe was faced with a hard decision. Should they move again? Should they post guards all day and night? Or, should they destroy the wolves? And, did they even want to be the sort of people who would kill off another species for their own convenience? At last it was decided they would move to yet another new location. But as was their custom, they also asked themselves, “What did we learn from this? How can we prevent making such mistakes in the future.” Someone said, “Well, if Wolf would have been at our first council meeting, he would have prevented this mistake.” “True enough,” they all agreed. “Therefore, from now on, whenever we meet to make a decision, we shall ask ourselves, ‘Who speaks for Wolf’ to remind us that someone must be capable and delegated to bring to bear the knowledge and interests of any missing stakeholders.” Forces: * Gaps in requirements are most cheaply repaired early in development; it is important for this and for reasons of acceptance (as well as ethics!) by all parties that all stakeholders have a say throughout any development or change process. *Logistical difficulties make the representation of all stakeholder groups at every meeting difficult.

*A new social institution or design will be both better in quality and more easily accepted if all relevant parties have input.* Once a wrong path is chosen, both social forces and individual cognitive dissonance make it difficult to begin over, change direction or retrace steps.

Solution: Provide automated reminders of stakeholders who are not present. These could be procedural (certain Native Americans always ask, "Who Speaks for Wolf" to remind them) or visual or auditory with technological support. Examples: Some groups make it a practice to “check in” at the beginning of any meeting to see whether any group members have an issue that they would like to have discussed. In “User Centered Design”, and “Contextual Design” methodologies, an attempt is made to get input from the intended users of the system early on in the design process. Resulting Context: When every stake-holder’s views are taken into account, the solution will be improved in quality and in addition, there will be less resistance to implementing the solution.Rationale: Much of the failure of "process re-engineering" can be attributed to the fact that "models" of the "is" process were developed based on some executive's notion of how things were done rather than a study of how they were actually done or asking the people who actually did the work how they were done. A "should be" process was designed to be a more efficient version of the "is" process and then implementation was pushed down on workers. However, since the original "is" model was not based on a very complete picture of reality, the "more efficient" solution often left out vital elements. We hope that this type of mistake is not being remade in the field of knowledge management, but fear that many such systems are attempts to provide a purely technological solution in a situation that calls for a socio-technical approach (Thomas, Kellogg, and Erickson, 2001). In any complex human endeavor, once a wrong path is initiated, it becomes progressively more difficult to change. For instance, in “A behavioral analysis of the Hobbit-Orcs problem”, (Thomas, 1974), people found it difficult to solve a simple puzzle when it appeared that they had to “undo” progress that has already been made. In more complex endeavors, not only does individual cognitive dissonance make changing direction difficult. In addition, social and logistical factors multiply the difficulties of changing paths. Technological and sociological "imperialism" provide many additional examples where the input of all the stakeholders is not taken into account. Of course, much of the history of the US government's treatment of the Native Americans was an avoidance of truly including all the stakeholders. A challenge in applying the "Who Speaks for Wolf" pattern is to judge honestly and correctly whether, indeed, someone does have the knowledge and delegation to "speak for Wolf." If such a person is not present, we may do well to put off design or decision until such a person, or better, "Wolf" can be present.

Known Uses: As a variant of this, a prototype creativity tool has been created. The idea is to have a "board of directors" consisting of famous people. When you have a problem to solve, you are supposed to be reminded of, and think about, how various people would approach this problem. Ask yourself, "What would Einstein have said?" "How would Ghandi have approached this problem?" And so on. This prototype can be viewed at the following:

www.research.ibm.com/knowsoc/

In a previously published study (Desurvire & Thomas, 1993), Human Computer Interaction specialists, computer programmers, and individuals with a background in neither field were asked to do a kind of “heuristic evaluation” of a user interface design under one of two conditions. In one condition, they were simply asked to find as many potential problems as possible and to suggest new features. In a second condition, they were successively asked to try to find potential problems and suggest new features from various perspectives including a cognitive psychologist, a behaviorist psychologist, an occupational therapist, a worried mother, and so on. Subjects in the various conditions had equal amounts of time, but people whom were specifically asked to take different perspectives, on average, found more actual usability problems and made a greater number of suggestions than those who were not given the suggestion to look at the problem from these various perspectives.

Discussion. In the case of the tribal experience that gave rise to the story and subsequent heuristic pattern, “Who Speaks for Wolf?” the people of the tribe knew every member of the tribe. That is, all the stakeholders were known, even if all were not present. Furthermore, because of the nature of their culture, it was presumed that each person would have to “live with” the consequences of every other person and their family and friends continuing to be a part of that tribe. Thus, not only were all the stakeholders known, but every stakeholder was likely to remain a stakeholder with continuing influence. Under these circumstances, everyone is wise to consider quite seriously the concerns and perspectives of every other stakeholder, not only because greater overall wisdom will result, but also because of future negative consequences that would occur if someone’s concerns were not at least respectfully considered. In many circumstances today, we live under more complex circumstances. During discussions at the DIAC02 conference, it was brought up that we may not always know who all the relevant stakeholders are. Furthermore, because of complex property rights and power relationships, some people may believe that some stakeholders may be ignored without consequence. There are certainly many similar stories in today’s complex society wherein people really do want to include all relevant stakeholders but finding them can be challenging. The following related patterns are meant to offer various suggestions relevant in such situations.

Related Patterns. Radical Co-location. (See above).

Advocates. In this pattern, rather than each individual being on the look-out for activities, changes, and situations that may be highly relevant to their concerns (which would be extremely time consuming), a single person (or small group) is charged with the task of understanding the concerns of a related group of individuals and making it their business to watch the environment for situations in which this group should be considered as stakeholders. Examples include public advocates, lobbyists, and activists.

Honey-pot. In this pattern, the systems designers, in order to attract the input of all relevant stakeholders, produce an event, or a thing which has extremely wide appeal and wide publicity; e.g., a party, a fair, a website, a free gift. Associated with this is an appeal for input from anyone who has an interest in doing so.

Exploring the Formal Organization. In this pattern, one finds a person or small group of people who know the entire formal organization, or one uses a tool that displays the entire formal organization and then explores links to any functions that may be relevant to the situation at hand, contacting those people whose job title, interests, or function may relate. Not all of these will be stakeholders, but clusters who are stakeholders may be revealed with minimal effort or disruption. For example, IBM has a world-wide directory called “Blue Pages” that allows one to search not only by name, but also by job responsibility, project, expertise and interests. This still does not solve the problem that you may not know or recognize the correct term to indicate an important relationship.Exploring the Informal Organization via Chaining. Here, one begins with people one knows and asks them who they know who would be most likely to be a stakeholder or know a stakeholder relevant to the situation you describe. By working in this recursive fashion, one can connect to relevant stakeholders fairly quickly.

Gaming Scenarios. In this technique, one assigns separate known stakeholder roles to each of several people on the project team. Each is given a different perspective to take and a different set of payoffs. They begin to “play” through a scenario and begin negotiating requirements. In the process of doing this, however, people will be on the look-out for “missing players.” Once people begin to confront a concrete (though imagined) reality, other stakeholders who are not being represented become clear.

Hypothesized Anti-Hero. In writing good fiction, it is important, not just to have good heroes, but, perhaps even more important to create interesting, powerful, and believable villains. It is natural in undertaking a project to think of all the benefits of the project and to imagine ourselves as systems designers as the “heroes.” Step back and try to imagine that there is someone completely opposed to the system you are designing. What would this person be like? Try to avoid the temptation to imagine them as idiotic, misinformed, or evil (although that can also be a useful exercise). Instead, try to imagine a smart, well-informed, good-intentioned person who is against the project. Why? What is their perspective? What history led to their view?

Multiple Agents. Although so-called “intelligent agents” have not really reached the point where they exhibit intelligence in the human sense, multiple agents can help remind people of sources of knowledge and viewpoints that they might not have otherwise considered.

Public Notice. It might seem too obvious to mention, but of course, wherever feasible, projects whose implications are widespread should be given public notice in appropriate forums; in some, but not all cases, this is a legal requirement. However, the utility of public notice goes beyond the avoidance of a lawsuit. It can result in better design.

Environment Change. Typically, a design is produced for a specific context. One way to test the robustness of design is to imagine a change in the envisioned environment. As a part of that thought experiment, a new set of stakeholders may come to mind as well. Some of these same stakeholders may well be relevant to the project as it stands; they are simply more saliently relevant in the changed environment.

Extreme Characters. Just as stories typically portray the edges of human social and emotional experience, and for that reason we find them fascinating and instructive, we also find extreme characters to be interesting. Djajadinangrat, Gaver, and Frens (2000) from the Royal College of Art have been using a technique during design of imagining some extreme but very different characters and then building scenarios for how those characters would react to a design; how they might use it; what their concerns might be.

Similar Past Experience. Although it may well be the case that no-one on the design team has experience with exactly the current set of circumstances, it may prove worthwhile to exchange stories of past design projects in which there were forgotten stakeholders; how those stakeholders could have been found earlier. Then, the team can reflect on how that knowledge might apply to the current situation.

Of course, designing any new socio-technical system is a difficult undertaking and none of the methods expressed in these patterns can guarantee that all relevant stakeholders will be discovered ahead of time. Taken together, however, we believe such methods have three important effects. First, the methods increase the chances of finding previously undisclosed stakeholders. Second, the methods generally increase the sensitivity of the design team to potential “side-effects” of their design. Third, such actions demonstrate a values-based design process and if and when new stakeholders are found, negative reactions are more likely to be restricted to material concerns and not include emotional negativity due to being ignored.

References:Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl, I. And Agnel, S. (1977) A Pattern Language. New York: Oxford University Press.Alexander, C. The Timeless Way of Building. New York: Oxford University Press, 1979.Bayle, E., Bellamy, R., Casaday, G., Erickson, T., Fincher, S., Grinter, B., Gross, B., Lehder, D., Marmolin, H., Potts, C., Skousen, G. & Thomas, J. (1997) Putting It All Together: Towards a Pattern Language for Interaction Design. Summary Report of the CHI '97 Workshop. SIGCHI Bulletin. New York: ACM. Carroll, J., Thomas, J., and Malhotra, A. 1979. A clinical-experimental analysis of design problem solving. Design Studies, 1(2), 84-92.Carroll, J., Thomas, J. and Malhotra. 1980. Presentation and representation in design problem solving. British

Journal of Psychology, 71(1), 143-155.Collins, J. and Porras, J. 1994. Built to last. New York: Harper.DeGeus, A. 1997. The living company: habits for survival in a turbulent business environment. Boston: Harvard

Business School Press,.Desurvire, H. and Thomas, J. (1993). Enhancing the performance of interface evaluators using non-empirical evaluation methods. Proceedings of the 37th Annual Meeting of the Human Factors and Ergonomics Society, 1132-1136. Santa Monica, CA: Human Factors and Ergonomic Society.DIAC '02, "SHAPING THE NETWORK SOCIETY: Patterns for Participation, Action, and Change". See http://www.cpsr.org/conferences/diac02/Djajadiningrat, J., Gaver, W., and Frens, J. (2000). Interaction re-labelling and extreme characters: Methods for exploring aesthetic interaction. In Proceedings of DIS 2000, 66-71. New York: ACM Press.Drucker, P. 1995. Managing in a time of great change. Truman Talley Books: New York. Duncker, K. 1945. On problem solving. Psychological Monographs, 58:1-112.Erickson, T. (2000) Lingua Francas for Design: Sacred Places and Pattern Languages. In the Proceedings of DIS 2000. New York: ACM Press, pp. 357-368.Farnham, S. et. als. 2000. Structured online interactions: Improving the decision-making of small discussion groups.

Proceedings of CSCW 2000. pp. 299-308. New York: ACM.Festinger, L. (1957) A theory of cognitive dissonance. New York: Harper.

Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.Gordon, A. 2001. Playing chess with Machiavelli: Improving interactive entertainment with explicit strategies.

AAAI Spring Symposium, Stanford.Landauer, T. The trouble with computers. Cambridge: MIT Press, 1995. Lawrence, D. and Thomas, J. Social dynamics of storytelling: implications for story-base design. Presented at AAAI workshop on Narrative Intelligence, Nov. 1999, N. Falmouth, MA.Lawrence, P. and Nohria, N. (2002). Driven: How Human Nature Shapes our Choices. New York: Jossey Bass.Lee, A., Danis, C., Miller, T., and Jung, Y. (2001) Fostering Social Interaction in Online Spaces. In Proceedings of INTERACT, '01 (Tokyo, Japan, July 2001), IOS Press, 59-66.Malhotra, A., Thomas, J., and Miller, L. 1980. Cognitive processes in design. International Journal of Man-

Machine Studies, 12, 119-140.Mattimore, B. 1993. 99% Inspiration: Tips, tales, & techniques for liberating your business creativity. New York:

American Management Association.Newell, A. and Simon, H. Human problem solving. Upper Saddle River, NJ: Prentice-Hall.Olson, M. and Bly, S. 1991. The Portland experience: A report on a distributed research group. International

Journal of Man-Machine Studies, 34, 211-228.Olson, G. and Olson, J. (2000) Distance matters, Human-Computer Interaction, 15, 2-3, 107-137.Poltrock, S. and Englebeck, G. 1999. Requirements for a virtual collocation environment, Information and Software Technology, 41(6), 331-339. Sobel, D. 1995. Longitude: The true story of a lone genius who solved the greatest scientific problem of his time.

New York: Penguin.Stein, M.1974. Stimulating creativity. New York: Academic Press.Thomas, J. and Carroll, J. (1978). The Psychological Study of Design. Design Studies, 1(1), 5-11.Thomas, J. Studies in office systems I: The effect of communication medium on person perception. Office Systems Journal, 1(2), 75-88, 1983.Thomas, J. and Kellogg, W. (1989). Minimizing Ecological Gaps in Interface Design. IEEE Software, pp. 78-86.Thomas, J. (1996). The Long-Term Social Implications of New Information Technology. In R. Dholakia, N. Mundorf, and N. Dholakia (Eds.), New Infotainment Technologies in the Home: Demand Side Perspectives. Hillsdale, NJ: Erlbaum.Thomas, J. 1974. An analysis of behavior in the hobbits-orcs problem. Cognitive Psychology, 6, 257-269.Thomas, J., Lyon, D., and Miller, L. 1977. Aids for problem solving. IBM Research Report, RC-6468.Thomas, J. and Carroll, J. 1978. The psychological study of design. Design Studies, 1(1), 5-11.Thomas, J. 1989. Problem solving by human-machine interaction. In K. Gilhooly (Ed.) Human and machine

problem solving. London: Plenum. Thomas, J.C. 1999. Narrative Technology and the New Millennium. Knowledge Management 2(9):14-17.Turner, M. 1996. The Literary Mind. New York: Oxford University Press.Thomas, J. (2001). An HCI Agenda for the Next Millennium: Emergent Global Intelligence. In R. Earnshaw, R. Guedj, A. Van Dam and J. Vince (Eds.), Frontiers of Human-Centered Computing, Online Communities, and Virtual environments. London: Springer.Thomas, J., Kellogg, W.A. and Erickson, T. (2001). The Knowledge Management Puzzle: Human and Social Factors in Knowledge Management. The IBM Systems Journal, 40(4).Underwood, P. (1983). Who speaks for Wolf: A Native American Learning Story. Georgetown TX (now San Anselmo, CA): A Tribe of Two Press.Underwood, Paula (1999). Three strands in the braid: A guide for learning enablers. San Anselmo, CA: A Tribe

of Two Press.Vlissides, Coplien, Kerth, eds. Pattern Languages of Program Design 2, Addison-Wesley, Reading, MA, 1996.

4 Potential Applications

4.1 [Click here and type Heading 2]

[Click here and type text]

4.1.1 [Click here and type Heading 3]

[Click here and type text]

4.1.2 [Click here and type Heading 3]

[Click here and type text]

[Click here and type first-level bulleted list] [Click here and type second-level bulleted list] [Click here and type second-level bulleted list]

[Click here and type first-level bulleted list]

References