Integrating Communities of Practice in Technology Development Projects

Technology development projects usually benefit when knowledge and expertise are drawn from a variety of sources, including potential users. Orchestrating the involvement of people from disparate groups is a crucial task for project managers. It requires finding a balance between differentiation, when teams work in isolation, and integration, when groups come together to exchange knowledge. This article argues that a “community of practice” perspective can help project managers to achieve this balance, by drawing attention to the assumptions, interests, skills, and formal and tacit knowledge of the different groups involved. Successful integration can be achieved by ensuring that the developing technology is comprehensible to all the groups concerned, and making sure that it satisfies their various interests.


Introduction
The success of complex technology development projects depends heavily on the ability of team members to interact productively so that relevant knowledge can be acquired, generated and circulated in a timely and cost-effective fashion.Often, projects benefit from the integration of expertise from different specialisms [1,2], including potential users.In this article we demonstrate how a "communities of practice" perspective can help project managers to maximize the fruitfulness of the relationships that are crucial to knowledge exchange in complex projects.As Nidumolu et al. [3] noted recently, there is a "ground beneath" knowledge management that consists of the situated contexts in which the production and exchange of knowledge occur.The management of complex projects requires an appreciation of this ground, so that degrees of engagement among diverse groups can be varied over time.This involves a balance between differentiation -when communities work in relative isolation from one another -and integration -when they are brought together to exchange knowledge and skills.A communities of practice perspective draws attention to the social processes that produce differentiation, as well as processes that facilitate productive integration.The article proceeds as follows.First, we briefly discuss the characteristics of communities of practice.We then consider different ways of organizing technology projects as alternative ways of structuring communities and establishing channels of communication among them.To illustrate how a community of practice perspective can facilitate an understanding of the issues involved, we draw on a case study of a project that was carried out in a manufacturing firm in Australia.
As the project progressed, its organization was characterized by a shift in emphasis from differentiation to integration.The flows of knowledge generated by this shift turned out to be quite different from those envisaged at the outset.Despite this (or more accurately, because of it) the project succeeded.While it is important to specify and pursue technical goals, complex projects are also social enterprises.
Applying a communities of practice perspective to our case study, we highlight some of the social processes that contributed to success -the use of brokers to bring diverse communities together, and the importance of aligning interests around the technology that is being developed.

Situating Knowledge and Skills -Communities of Practice
The concept of communities of practice has recently gained attention as a way of explaining how knowledge and learning develop in specific social contexts [4,5,6,7].According to Wenger [5, p. 45

],
Over time, … collective learning results in practices that reflect both the pursuit of our enterprises and the attendant social relations.These practices are thus the property of a kind of community created over time by the sustained pursuit of a shared enterprise.It makes sense, therefore, to call these kinds of communities communities of practice (emphasis in original).
Communities of practice are organised around circumscribed sets of activities and their members are generally in direct contact with each other.They develop their own routines, formal and informal "rules", and stores of shared assumptions and knowledge.Over time, they often create their own languages, which may contain jargon and colloquialisms whose meanings are obscure to outsiders.As a result of learning, practices evolve.However, community members may also import knowledge from similar communities or more disparate sources.The extent to which a community of practice learns internally or imports new knowledge is in part a function of the nature of the practices it undertakes.In many complex technology projects, knowledge acquired from external sources, that is, from other communities of practice, is crucial.

Projects and Communities of Practice
It is important to distinguish between projects and communities of practice.
There are differences in personnel, goals, and how they located in time.Projects are more clearly instrumental than communities of practice.A project may be defined as "any undertaking that has definite final objectives representing specified values to be used in the satisfaction of some need or desire" [8].What distinguishes a project from many other activities is that it has a defined point at which it is completed.
Projects also differ from communities of practice in their ad hoc nature.They have no collective history (although some members of the project may share a history), and no collective future.Nevertheless, the people who work on a project may belong to a number of communities of practice.For example, in a matrix organization, the membership of functional teams extending beyond the project remains explicit for many project participants.The extent to which a community of practice is involved in project activities can vary, with clients perhaps only peripherally associated, while team managers may devote virtually all of their attention to the project.Communities of practice operating within a project allow for concentrations of expertise.However, a high degree of differentiation may make it difficult for participants to develop project-wide goals if members of particular communities are too focused on internal concerns.

Varieties of Project Organization
Project organisations have been used since "cavemen formed a project to gather the raw material for mammoth stew" [9, p. 7].Formal interest in project management grew during and after the Second World War as a result of a number of gigantic development undertakings, many of which were defence related [10].
Depending on size and complexity, projects can be organised differently.Meredith and Mantel [9] describe three basic types of organisation.One is to assign a project to a functional section of a larger organisation, for example to give it a "home" in the engineering division or the accounting department.Secondly, a project may be accommodated in a pure project organisation, a separate, largely self-contained section that is devoted exclusively to the project and will be disbanded when the project is completed or abandoned.Finally, projects may be run on a matrix basis in which control rests with a project manager but the bulk of the human and other resources are "borrowed" from different sections in the larger organisation.Hobday [11] has refined this into six different forms, including three types of matrix organisations.Regardless of the form a project organisation takes, however, problems of managing connections among people with different areas of expertise remain.
The baseline for technology development processes, against which more recent commentators have reacted, is a model of sequential interdependence [12], in which downstream stages depend on those that precede them but there is no reciprocity.
When this is the case, planning, development, manufacturing, marketing, and use can all be planned without reference to what might happen later.From the 1980s, however, increased competition from Japanese firms suggested that sequential organisation was too time-consuming [13,14,15,16].Alternatives were developed.
Stalk and Hout [13], for example, established rules for design teams that included mixed membership across functional areas, co-location of team members and other ways of achieving quicker and tighter co-ordination.Similarly, Smith and Reinertsen [17] advocated cross-functional groups that brought together marketing, development and manufacturing representatives from the onset.In this way, opportunities for the transfer of tacit as well as formal knowledge are enhanced [18,19].
In recent decades, the role of potential users in the process of technology design has gained increasing attention [20,21,22,23].In theory, different relationships between users and developers are possible, spanning the spectrum from complete differentiation to close integration.Sometimes, technologies can be successfully developed without any contact with potential users [24].Provided the new products are comprehensible and easily integrated, minimal interaction between developers and users need not to be a barrier to adoption [23, p. 98].On the other hand, when new technologies and the systems into which they are to be introduced are complex, lack of knowledge exchange can lead to considerable problems.Millions of dollars have been wasted on technologies that were never successfully adopted [23, p. 98-99, 25].
To counteract these problems, various levels of user participation in design and implementation have been advocated.In some cases, users are so heavily involved in the design of a technology that they are, in effect, co-developers [23, p. 100-102].In general, however, users lack the expertise to carry out development activities themselves, especially when advanced technical skills are required.
Connections between developers and users are thus likely to fall somewhere between the two extremes of complete differentiation and total integration.While integration may, in theory, facilitate more efficient sharing of knowledge, there are obstacles that must be overcome.Leonard-Barton [23] has pointed out that people within communities develop particular mindsets and "signature skills" that are, in part, products of their professional training.Indeed, they are the means through which group members distinguish their own activities from those of others.The problem for project managers is to overcome barriers to communication created by the existence of groups with quite different skills, languages, expectations and assumptions.Some authors [17,26] have argued that different arrangements are appropriate depending on circumstances.In some situations, differentiation, balanced with collaboration rather than integration, may be beneficial.Quinn et al. [26] for example, cite complexity as a major reason for the success of what they call "independent collaboration" in innovative situations.
"In an increasing number of innovations … complexity is so high (as in advanced physics, aerospace, communications, or biotechnology projects) that teams, as they are ordinarily defined, cannot cope as well as collaboration among a large number of relatively independent units" (p.107).
Clearly, there is no "one-size-fits-all" prescription for effective project management.In complex projects at least some differentiation is advantageous, as it facilitates the concentration of expertise.However, as Lawrence and Lorsch [27], Chandler [28] and Galbraith [29] have all emphasised, differentiation also requires collaboration and/or integration.This is widely recognised in the project management literature [30,31,32].To illustrate some of the issues associated with differentiation and integration in complex technology projects, we turn now to our case study.The case highlights the importance of managing flows of knowledge between two important groups that are almost always involved in projectstechnology developers and end-users.The relationship between these groups is frequently quite delicate, and many projects have failed because it has not been managed well.

Research Methodology
The first and third authors were involved with the IMS project from mid-1996 to November 1998.As management academics with an interest in the social aspects of technology design, we were contracted by the developers of the IMS to help them organise a factory trial of the new technology.[Name] took a leading role in arranging and conducting meetings and workshops, while [name] acted solely as a nonparticipant observer and analyst.Our methodology could be characterised as reflexive action research [33].During the IMS trial period, one or more members of our research team [include footnote with other names] spent more than 20 days with the developers and/or factory personnel.A variety of activities were involvedconducting meetings and workshops, and collecting data through observations and interviews, and from documents produced by the R&D team and the IMS test factory.
All researchers took notes and recorded their reflections of events.

Factors' risks
The organisation in which we conducted our research is a well-established, large and diverse mining and manufacturing company.The bulk of its factories and mines contain complex mixtures of old and new equipment.During the 1990s, the company supported a number of in-house R&D laboratories, in which more advanced experimental technologies were built and tested.The intelligent manufacturing system (IMS) was one of these.It consisted of a set of interconnected computers and software designed to provide finely-tuned control of a continuous manufacturing process.In its fully-functioning form, the computers would be attached to pieces of equipment at critical points along the process.They would gather and exchange data about the equipment and the process, and adjust settings to optimise the functioning of the system as a whole.For example, if a valve in one piece of equipment was worn or broken, the IMS would be able to adjust settings elsewhere to compensate [34].
The IMS R&D team was established by senior company executives in 1994.
The initial aim was to build a system in a laboratory setting so that its capabilities could be explored.This would allow the company to be an "intelligent customer" of the technology in the future, and also to influence standards if and when the technology became commercially available.The R&D team consisted of 8 qualified computer scientists who, by virtue of their shared expertise, common task and close interaction, constituted a community of practice.In the laboratory, they used simulated data and a scaled-down model of a manufacturing process to build an experimental IMS.They did so without reference to the factory operators who would eventually use the technology, should it ever be installed.At this stage, the major "users" of the project's output -arguably information rather than a working artifact -were senior company executives.In this specialized environment, the concentration of expertise facilitated rapid development of the software.Because the technology worked well in the simulated conditions, a decision was made to test it in an actual manufacturing site.This would yield further, and probably more relevant, information about its capabilities.This decision introduced a new group of users, and a new set of challenges with respect to knowledge transfer and learning.
The employees at the test site, which was more than 1,000 km away from the company's main research laboratories, comprised another distinct community of practice.The site was selected because its manufacturing process was relatively stable and well understood.Sufficient data were available at various points along the process to make an IMS feasible.Nevertheless, the developers realized that implementation would not be straightforward.In the past, there had been considerable problems with the transfer of technology from laboratories to worksites within this company.The factory chosen for the IMS trial had, some years earlier, been the site of an unsuccessful technology transfer.In 1988, employees were sent on a holiday while the factory was upgraded.No-one told them what was happening.When they came back, they found a new product tracking device that simply did not work.They tried to fix it, and, in their own words, "created a monster".It took years of tinkering to make the device useful.The drama surrounding the installation was still notorious almost a decade later, when the factory was chosen as the site of the IMS trial.
By 1996, when planning for the trial began, the company was conducting "risk reviews" in an effort to prevent such problems.The IMS risk review identified a set of "human factors" risks as particularly important.They included fears that the IMS "won't be simple enough for staff for handle", that its "continued use [would lead to] operator deskilling" and that there would be "inadequate preparation of end-users".After the meeting, the developers summarized these concerns into a single statement of risk -that "end users do not adopt the technology".
By identifying the possibility of user rejection, the risk reviewers had implicitly acknowledged the existence of a separate and distinct community of practice at the test factory, whose actions with regard to the new technology were unpredictable.
Moreover, because of the problems created by the company's traditional "leave it at the doorstep" approach to technology implementation, relationships between factory workers and technology developers were often characterised by suspicion and distrust.To overcome these barriers, the developers employed a mechanism that is frequently used by people trying to establish connections across the boundaries of different communities of practice.They engaged brokers -a group of academics from [site withheld] who were contracted to "reduce the risks of user opposition or lack of involvement" in the IMS trial.This contractual obligation, together with statements made at the risk review, give important indications of the developers' view of their relationship with the users at this early and crucial phase of the project.They assumed that the flow of knowledge would be uni-directional.
That is, for the trial to work, the users would have to be educated to accept and operate the IMS.

Brokering -Bringing Communities Together
Wenger [5, p. 109] defined brokering as the "use of multimembership to transfer some element of one practice into another".In our case, our ability to facilitate the transfer of elements of practice did not depend on our being members of the communities involved.Indeed, our legitimacy was probably enhanced by our status as "outsiders".Non-membership does have disadvantages, however.The early stages of our involvement were characterized by some confusion, as we struggled to familiarize ourselves with the worldviews, expectations and motives of the developers on one hand, and the people working at the test site on the other.As Wenger [5, p. 109] notes, The job of brokering is complex.It involves processes of translation, coordination, and alignment between perspectives.It requires enough legitimacy to influence the development of a practice, mobilize attention, and address conflicting interests.
These observations remain valid whether the brokers are imported from outside, as was the case in the IMS project, or whether they emerge from within the communities themselves.The important point is that integration of knowledge across communities requires a great deal of work in creating and maintaining social relationships.It is not merely a technical task.
Between May 1997 and February 1998 we and other participants in the IMS project arranged a series of "boundary encounters" [5, p. 112] -meetings, telephone calls, workshops and other activities that facilitated exchanges of information among groups.At first, there was some confusion, as perspectives were not aligned.The developers were primarily interested in conducting a trial that was valid and meaningful for them.Initially, however, the manager at the test site was reluctant to participate, thinking that the trial would be "a pain in the arse".
In his experience, new technology often "arrived at the doorstep and it's never as good as they say it's going to be".Subsequently, however, he changed his mind.It is often difficult to ascertain people's motives, but there are several reasons why he may have chosen to assist the trial.Firstly, supporting innovation would have helped his career.Secondly, the risk review workshop and our involvement as brokers demonstrated that this particular technology was not going to just "arrive" and cause problems for factory operations because of a lack of care with integration.Thirdly, the test factory managers had been conducting team-building exercises aimed at improving productivity and morale.The activities associated with the trial could provide another opportunity for eliciting greater operator interest and involvement in the running of the factory.Finally, there were technical reasons to support the development of more sophisticated computer control.The manufacturing process at the factory was rapid, and several key pieces of equipment had to be finely tuned and coordinated.There was considerable tacit skill involved in providing the optimal equipment settings.The IMS computers could potentially help with this, thereby enhancing productivity and competitiveness.
Gaining the support of the factory manager was an important early step in preparing for the trial.However, the cooperation of the operators was also required.
As the risk review noted, there was a distinct possibility that the workers at the test site would not, 1 or could not, do what was required to produce a valid test of the technology.Equipment upgrades in the company had often meant job losses.
Greater computer control over the manufacturing process could mean that valuable tacit knowledge would be lost as operations became more automated.The IMS was also technically complex.The R&D team was concerned that operators "would need a degree in computer science" in order to work the technology, even if they were prepared to incorporate it into their normal daily activities.
Ensuring the alignment of the operators was our major task as brokers.
However, we had our own perspectives on the IMS and the trial.Influenced by traditions of humanistic user-centered technology design, we wanted to make sure that the needs, aspirations and preferences of the factory personnel were taken into account.In other words, we wanted to steer the project in a direction that would do more than just elicit operator compliance.To this end, we negotiated opportunities to introduce and discuss methods for improving technology design by taking greater account of the needs and preferences of users [35,36].However, because the IMS was already fairly well-developed, the scope for the use of these methods was minor.Despite this, discussion of the methods did provide a focus for direct productive interaction between the developers and users. 2 They helped to break the ice and made later communication easier.One of the developers was based close to the factory site, and became a regular conduit of information.As the communication channels became more developed, the technologists began to learn from the operators.On several occasions, the company provided funding for employees to fly more than 1,000 km to the research laboratories to view the simulated factory process and the IMS prior to its installation.We were not present at these meetings, and our information about them is derived from what others have told us.The visits were, apparently, quite significant in contributing to the success of the trial.One of the factory workers who made the trip said "to be honest, the thing wasn't really anything like [the plant].It was completely devoid of the way we do things.Similar principle, but...".According the technologists, "eight or nine" details of the IMS and the trial were changed as a result of the visits.The developers' plans to use the IMS to completely control the process were dropped, as the operators convinced them that it would not be feasible.Instead, the IMS would suggest equipment settings, and the operators had the option of accepting or rejecting them.
The trial, when it came, was a success.The operators cooperated, and the developers were able to "prove the concept" of the IMS by demonstrating that when aspects of the manufacturing process were varied, the technology was able to suggest equipment settings that compensated for the variations.This situation was in marked contrast to the debacle of the product tracking device that was installed in 1988.The major difference between the two projects was the amount of care taken with the IMS to ensure a productive integration of the knowledge and practices of technology developers and users.

Connecting Communities by Aligning Interests around Boundary Objects
The varieties of project organization outlined earlier, and the strategies for involving users discussed above, are all concerned with managing the balance between differentiation and integration.It is unlikely that a single form of project organization will prove effective in all circumstances.Given this contingency, project managers would be well advised to pay attention to the social ground beneath the production and exchange of knowledge, namely the communities of practice that are involved in technology projects.There are two related aspects of project management that we believe are particularly pertinent to the achievement of successful integration.Firstly , it is important to try to align the interests of the different groups involved.Secondly, interests need to be organized productively around the central focus of the project, that is, the developing technology itself.
Abstract "needs" for information transfer do not, in themselves, propel action.
The needs must be recognized as such by the actors involved, who must initiate actions that allow exchanges to occur.In the IMS project, the developers recognized a need to transfer knowledge into the community of users.They engaged us as brokers, and a mutually acceptable alignment of interests was negotiated through a contract that allowed us to pursue some of our own goals in exchange for ensuring operator cooperation with the trial.However, and most importantly, we also had to align the interests of the factory personnel.Our strategy of broadening the scope of the project to include a consideration of principles of user-centred design seemed to work.It provided opportunities for the operators to influence the final stages of the design of the IMS, and planning for the trial.As one of the factory workers said, "It's the first time we've actually been asked for input.And I will admit that it's good to get away from the bloody day-in, day-out grind to actually do something different".This quotation hints at another reason the men (they were all men) supported the trial.It provided relief from boredom.They held competitions between themselves and the technology to see which could suggest the most effective equipment settings.According the developers, the results were "neck-and-neck", a situation that would probably have provoked further competition (that is, cooperation with the trial) .Finally, the technology was highly experimental.It was not going to remain at the site, and there were no immediate prospects of job losses or deskilling.The fact that the technology could potentially assist, rather than replace, operators might also have been a factor in the acceptance of the trial.
The establishment of friendly relationships between developers and users, however, is irrelevant if technologies remain alien and ineffectual for those who are supposed to use them.In other words, when highlighting the importance of human relationships in technology development projects, it is important not to lose sight of the overall goal -the production of a useful, working artifact.For successful integration to occur, the technology must function as a "boundary object".This is an object that is "both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites" [40, p. 393].The importance of this mutual comprehensibility is illustrated by the case of the failed product tracking device that was installed in the test factory in 1988.It may have worked perfectly well in the research laboratory, but it was not robust and plastic enough to be integrated into its new environment.
In the IMS project, the IMS itself functioned as a boundary object.The negotiation of meanings around this central object constituted the integration of knowledge that contributed to the production of a viable, working technology.The integration was facilitated by actual physical contact with the object itself.
Demonstrations of the IMS in operation were organised for factory personnel before the trial, using simulated data and a scaled-down model of the manufacturing process.These demonstrations provided valuable opportunities for tapping into the accumulated expertise possessed by the factory workers.As one of the technology developers noted, the factory operators raised "issues about the complexity of the mill versus our simulation that we hadn't considered".They were able to make final adjustments that ensured a smooth passage of the technology from the research laboratory into the test factory.The details of the knowledge that needed to be transferred for the trial to succeed could not be predicted in advance.However, by crafting opportunities for people from the two groups to mingle and establish social relationships, the project managers created conditions conducive for the alignment of interests, and the identification and closure of gaps in knowledge.

Summary and Implications for Managing Complex Technology Projects
Analysts generally agree that the design of new technologies can be enhanced by integrating knowledge and skills from a variety of sources.Potential users are often depicted as a particularly rich and relevant source of knowledge, and much effort has been devoted to defining the conditions under which productive relations between developers and users can be established and exploited [20,21,41].
Creating a sensible balance between differentiation and integration is part of this endeavor, and a variety of project forms may be effective in enabling and enhancing timely communication and cooperation.However, to optimise relations between different groups, project participants need to construct integrating institutions based on effective mental maps of the social landscapes in which projects are conducted.
A community of practice perspective can assist with this endeavour.
The importance of taking communities of practice into account is illustrated by the case study, which includes varying levels of understanding on the part of developers of the existence and potential contributions of communities of users.Three primary communities of practice were involved in this instance, the developers of the IMS, the major corporate sponsors (who were also users in an abstract sense), and the people in the plant in which the IMS was tested.The earlier failure to install a tracking device in the factory suggested that the developers needed to take care to consult the users effectively on this occasion.The knowledge limitations inherent in the developers' community of practice meant that they could not fully comprehend the practical implications of using the IMS within the broader system of work undertaken in the factory.If this were the only gap between the communities of users and developers, the IMS as a boundary object might on its own have served as an integrating agent to bring about a shared understanding leading to necessary modifications in the IMS.In this case, however, more was needed because the social landscape in the factory, among both managers and workers on the shop floor, created substantial skepticism towards the objectives of the project as a whole.For their part, the designers viewed the users through lenses coloured by their own interests and worldviews.That is, they saw the users as either resistant or compliant, not as active contributors of knowledge.Thus brokers were needed as a further integrating agent, to help generate an environment in which both communities of practice were willing to concentrate on operationalising the boundary object rather than focusing on their own narrow preconceptions.
All complex projects need people to act as brokers, transferring and translating knowledge, and aligning interests and perspectives as projects move through phases of differentiation and integration.In the final testing and implementation stages, these activities should be directed towards ensuring the technology is comprehensible to people in the relevant communities, and that it is flexible enough to accommodate their different needs and preferences.Further research is needed on strategies that brokers can use to facilitate productive integration.This requires field work, as factors influencing success and failure may not be entirely 'rational'.For example, the capacity of the IMS to relieve boredom was a factor in the success of the trial.Only by exploring more fully the social dimensions of crafting new technologies can we create appropriate integrating agents to optimise conditions for productive engagement by diverse communities of practice.