Beyond Expertise Seeking: A Field Study of the Informal Knowledge Practices of Healthcare IT Teams

Beyond Expertise Seeking: A Field Studyof the Informal Knowledge Practices of HealthcareIT Teams

Patricia Ruma Spence & Madhu ReddyCollege of Information Sciences and Technology, The Pennsylvania StateUniversity, 329B IST Building,University Park, PA 16802–6823, USA (E-mail: [email protected]; E-mail: [email protected])

Abstract. CSCW has long been concerned with formal and informal knowledge practices inorganizations, examining both the social and technical aspects of how knowledge is sought, shared,and used. In this study, we are interested in examining the set of activities that occur when co-located knowledge workers manage and resolve issues by seeking, sharing, and applying theirinformal knowledge. Informal knowledge seeking involves more than identifying the expert whohas the knowledge or accessing the knowledge through physical artifacts. It also involves workingwith that expert to identify and apply the appropriate knowledge to the particular situation.However, our understandings of how people collaboratively work together to find, share and applythis knowledge are less well understood. To investigate this phenomenon, we conducted a fieldstudy of how professionals in three IT teams of a regional hospital managed and resolved IT issues.These knowledge workers used various collaborative practices such as creation of ad-hoc teams andthe use of email to identify, share, and use informal knowledge to resolve IT issues. In addition,particular team practices such as how issues are assigned affected these knowledge activities. Ourfindings highlight how informal knowledge activities are affected by a variety of implicit andsometimes subtle features of the organization and that organizational knowledge managementsystems should support informal knowledge seeking activities and collaboration amongst theknowledge sharers.

Key words: knowledge seeking, informal knowledge, collaboration, IT teams, knowledgemanagement systems, healthcare, qualitative research, team practices, organizational work

1. Introduction

The creation, acquisition, and management of knowledge in collaborativeenvironments are of growing interest to the CSCW community. Researchershave found that organizations that can better develop, share, and applyknowledge are also better at problem solving and innovation (Ackerman 1994;Ackerman and McDonald 1996; Nonaka et al. 2000). Yet, the very concept ofknowledge can convey a variety of meanings (Leonard and Sensiper 1998). Onone hand, informal knowledge often refers to knowledge that people have gainedover time through everyday practice and workplace experience that is notformally captured or documented (Howells 2002; Malcolm et al. 2003). On the

Computer Supported Cooperative Work (2012) 21:283–315 © Springer 2011DOI 10.1007/s10606-011-9135-1

other hand, formal knowledge refers to knowledge that is documented andaccessible by people in an organization. Although the concept of knowledge maybe broad, it is a central theme in research on organizational work, teams,expertise, and collaboration.

The acquisition of knowledge in collaborative environments is a prominentpart of the CSCW literature. These issues have ranged from organizationalmemory and expertise location (Ackerman and Halverson 1998; Lutters andAckerman 2002; McDonald and Ackerman 1998) to the management of codifiedknowledge (Bandini et al. 2003; Pipek and Wulf 2003). Some of these studiesfocus on how expert’s knowledge is found and accessed (Ehrlich et al. 2007).Other studies have focused on how knowledge is captured in a system ordocument in such a way that it is easily accessible to members of the organizationand where annotations in that system or document evoke tacit knowledge in theuser (Cabitza and Simone 2009). The acquisition and codification of knowledgehas been a major topic of empirical and technologic investigation. When peopletalk about “organizational memory systems,” they are referring to systemsdesigned to support the seeking and sharing of both formal and informalknowledge (Staab et al. 2001). This includes knowledge about the organizations’processes including steps in the processes as well as assumptions, constraints, anddesign decisions about these processes. In essence, organizational memory is the“know-how of a business recorded in documents” (Lehner 2004).

At the same time, CSCW researchers are also starting to examine, in greaterdetail, issues related to informal knowledge (Lutters and Ackerman 2007; O’Haraand Brown 2001). In particular, the study of informal knowledge has focusedon what people know and the location of knowledge experts through eitherpersonal social networks or organizational social networks similar to Facebook(Ackerman 1994; Ehrlich, et al. 2007). When studying knowledge seekingactivities, there has also been a great deal of focus on the activities involvedin the seeking of informal knowledge (Lutters and Ackerman 2007). Further,Cabitza and Simone (2009) focused on how to circumvent the explicit codification of(representational) knowledge in such a way that system users could be aware of itsintended pragmatics (that is, its “value for action”) in their daily work. However,informal knowledge seeking involves more than identifying the expert who has theknowledge or accessing the knowledge through physical artifacts (i.e. documents,information systems). It also involves working with that expert to identify and get theappropriate knowledge for the particular situation. Consequently, while we havedeepened our understanding of certain aspects of informal knowledge seeking, suchas how to identify who has it or how it is shared across group boundaries, ourunderstandings of how people collaboratively work together to share and apply thisknowledge are less well understood.

In this study, we examine how co-located knowledge workers collaborativelyresolve issues by seeking, sharing and applying their informal knowledge. Inparticular, we want to uncover how team practices affect these activities as well as

284 Patricia Ruma Spence and Madhu Reddy

identify specific informal knowledge practices in this context. In unpacking thisphenomenon, we move beyond expertise location to discuss how knowledgeworkers find and share their informal knowledge as part of the issue resolutionprocess. By focusing our attention on these issues, we approach informalknowledge seeking and sharing as a set of collaborative activities that isundertaken as part of a team member’s everyday work. The focus of our researchis conceptual in nature. Our goal is to contribute to the body of empirical researchon knowledge work in organizations. Although this research is not linked to anyparticular design proposals, we discuss some design implications that focus onways in which collaborative knowledge activities can be supported.

In particular, we are concerned with how team members collaboratively seekand share the knowledge needed to resolve issues in the context of hospitalinformation technologies. We are studying how workers resolve issues by seekingand sharing informal knowledge in an information technology (IT) department ofa large regional health system. The IT department is a team-based environmentwhere informal knowledge plays an important role in ensuring that operations ofthe hospital are not disrupted by IT problems. Healthcare IT teams are aninteresting domain to investigate knowledge seeking. These teams play a veryimportant role in the organization because they are essentially the front-lineinformation workers. Hospitals are information-intensive, safety-critical, highreliability organizations; and technology and information systems are pervasive topatient care (Bates 2002). Incorrect or unavailable information can lead toinappropriate patient care decisions. Therefore, IT team members must ensurethat these information systems are available and accurate. We were particularlyinterested in understanding how contextual factors affect the knowledge practicesof IT team members. Through this perspective, we identified the interplaybetween team practices and work activities, and their effect on informalknowledge seeking and sharing.

The paper proceeds as follows: in the next section, we discuss studies ofknowledge acquisition and management. In section 3, we describe the researchsite and methods. Next, we explain the particular work activity – issuemanagement – that we observed. We then present findings from our study insection 5. In section 6, we discuss the implications of these findings with regardto teams, temporality and design. Finally, we conclude with some thoughts oninformal knowledge, collaboration, and co-located teams.

2. Background

CSCW researchers have examined knowledge issues in organizations from twomain perspectives: field studies of knowledge practices and design of technol-ogies to support knowledge practices. These areas are of particular interest toCSCW researchers because they focus our attention on the interplay betweenknowledge, collaboration, work, and technology. This growing body of research

285Beyond Expertise Seeking

has examined aspects of knowledge management as well as knowledgemanagement systems (Ackerman and Halverson 2004; Cabitza andSimone 2009; Ehrlich, et al. 2007; Huysman and Wulf 2006). Through theseand other studies, researchers are laying the foundations for understandingknowledge management work in collaborative environments and how technol-ogies can support this work.

2.1. Understanding knowledge practices in context

CSCW researchers have employed ethnographic field studies to understand therole of knowledge in collaborative environments. In particular, there has been agreat deal of focus on expertise location as well as knowledge access and sharing.

Knowledge plays a pivotal role in problem solving. However, knowledgeseekers often, first, need to identify individuals who have the needed informalknowledge. CSCW researchers have highlighted different methods that indivi-duals have taken in indentifying the “experts.” One knowledge seeking practiceincludes the use of an “expertise concierge,” a person within the organizationwho can direct the individual to the person with the required knowledge(McDonald and Ackerman 1998). The “expertise concierge” directs theknowledge seeker to potential experts. Another knowledge seeking approach isto first learn the competencies of others using an “expertise awareness client”such as eXacT (Dörner et al. 2007). This “intelligent” awareness system isintegrated into an organization’s groupware and offers its users’ notifications ofothers’ competencies based on the use of existing systems.

Additionally, how people seek knowledge is affected by both organizationaland individual characteristics. For example, the identification of potential expertsis not sufficient to find knowledge – the knowledge seeker must also select anexpert from those identified. However, certain organizational and individualcharacteristics influence this selection process:& The organizational process of asking for help – they must first ask

team members, then go outside to other departments (McDonald andAckerman 1998);

& The personal characteristics of each potential expert including their generalhelpfulness, general knowledgeability, overall willingness to help, as well astheir history of helpfulness (Greer, et al. 1998); and

& The workload and the performance of the potential expert (McDonald andAckerman 1998). The performance of the potential source is particularlyinteresting as it includes specific individual characteristics such as problemcomprehension, ability to provide a suitable explanation, and attitude.

These organizational and individual characteristics affect the knowledgeseeking practice of selecting an expert source of knowledge with whom tocollaborate.


Researchers outside of CSCW have also studied the challenges of knowledgeseeking in teams and found other organizational and individual characteristicsaffecting these work practices. Alberts (2007) found that team member support isvery important to managing knowledge in teams as it requires team members tohelp each other find, share, and evaluate information. In addition, characteristicsof team members themselves affect issues such as knowledge transfer.Specifically, the capability, credibility, and degree of communication of aknowledge source within a team will determine the extent of knowledgetransferred to recipients (Joshi et al. 2007).

Another important issue surrounding knowledge practices in collaborativeenvironments is the role that boundary objects play in carrying knowledge acrossteams (Star 1990). These boundary objects serve as bridges between organiza-tional groups, particularly with regard to sharing knowledge. For example,boundary objects play a vital role in information reuse. These boundary objectsallow information to be decontextualized and stored by one team, and thenaccessed and recontextualized for use by another work team (Lutters andAckerman 2007). Further, the use of social tagging to categorize knowledge isbeneficial within a department because the tags serve to form a situated ontologyas boundary objects cross the various departmental teams (White and Lutters2007). This allows boundary objects to be accessed more easily by members ofvarious teams who might categorize the information differently and otherwise notfind the needed information. Furthermore, boundary objects enable collaborativeknowledge flow across groups because the information found in the boundaryobjects is stable. Therefore, members of different groups can use boundaryobjects with confidence because they are assured that the information containedin them is established and reliable (Phelps and Reddy 2009).

Knowledge practices are deeply embedded in organizational work activities.These practices range from identifying who has the required knowledge to howthat knowledge is shared across various organizational boundaries. While anindividual may seek knowledge and apply it to a problem or situation, thecomplexity of work today has created a need for more teams in the workplace(Guzzo and Shea 1992). These teams also seek, share, and use knowledge toresolve a shared problem (Hackman 1990). In order to problem solve effectively,these team members must share knowledge and process information, jointlyassess the situation, reason with each other to develop a useful solution andmonitor that solution (Oser et al. 1999). Additionally, many of these individualand team knowledge practices are supported by a variety of knowledgemanagement systems.

2.2. Understanding knowledge management technologies

CSCW researchers have not only studied knowledge practices but also the designof different types of organizational memory, expertise recommender, and


knowledge management (KM) systems (Bandini, et al. 2003; Cabitza andSimone 2009; Ehrlich, et al. 2007; Pipek and Wulf 2003).

Several systems have been designed to support knowledge practices incollaborative environments including Answer Garden (Ackerman andMalone 1990), SmallBlue (Ehrlich, et al. 2007), and the Active KnowledgeArtifact Management System (Cabitza and Simone 2009). These systemsinclude functionality that supports knowledge seeking activities. These functionsinclude the ability to: (1) automatically forward a question to the person with theexpertise to answer the question (Ackerman and Malone 1990); (2) find expertsincluding the location of that expert in one’s social network (Ehrlich, et al. 2007);and (3) combine archival documents with contextual information in order to promoteworkers’ knowledge evocation when coordinating team activities (Cabitza andSimone 2009).

Some systems such as Ackerman’s Answer Garden (Ackerman andMalone 1990),are organized around a subject area (customer service issues) consisting of a databaseof answers to questions, both frequent and rare. In addition, Answer Garden includesan element of process work because if an answer is not found, the question isautomatically forwarded to a subject matter expert. Once answered, it is not onlyincluded in the database, it is also sent to the person originally posing the question.This system allows users to gather knowledge to solve a problem without having toactively seek out a collaborator or an expert. This is helpful to users who do not knowwhere to find potential experts and for processes that do not support lengthycollaborations, such as customer service hot lines.

Other systems, such as Ehrlich’s SmallBlue (Ehrlich, et al. 2007), use socialnetworks to help users find potential experts (knowledge) with which tocollaborate. The tool not only enables users to see their smaller, personal work-related network, but all the experts in the organization. The user must first enter asearch term, and SmallBlue returns a relevance-ranked list of people in theorganization related to that search term. Alternatively, the user can enter a topicand see the top 100 experts for that topic. Knowledge seekers can quickly andeasily find potential experts and see how they are socially connected to reach outto that expert. In essence, this tool facilitates knowledge seeking across broadtopics within a large organization.

Investigations of these and other KM systems provide us with a betterunderstanding of what is required to design KM systems to support collaborativework. Huysman and Wulf (2006) discussed how knowledge management systemsmeant to support “informal emergent knowledge sharing within communities”must take into account social factors such as the social capital of the group itselfin order to be successfully adopted by users. Not only are contextual factorsimportant to the design of KM systems, the functions of the system itself canaffect system use and acceptance. For example, certain elements of a cross-organizational memory and expertise recommender systems are important for thesuccess of these systems. In particular, the inclusion of personal and site


information, new methods of establishing trust, and a flexible ontology builtusing methods of social tagging (White and Lutters 2007).

The formal knowledge that is codified and included in a KM system comesfrom individuals within the organization, and others then look for that knowledgeand access it as needed. The knowledge seeker may have multiple sources ofcodified knowledge from which to choose. Therefore, the characteristics of asystem’s sources can affect how informal knowledge is accessed within thesesystems. For example, the capability (expertise level), credibility (status), anddegree of communication of a expert source affects the extent of knowledgetransferred using the system (Ackerman 1994). The more capable, credible, andcommunicatively literate an expert source, the more likely that expert source willbe selected and the knowledge more easily transferred.

2.3. Summary

There is a growing body of literature examining knowledge seeking andknowledge management systems in collaborative environments. Through thisresearch, we know that knowledge seeking is composed of a set of complexactivities involving people, processes, and objects as they seek knowledge.

Yet, there are still open questions regarding knowledge practices incollaborative environments. For example, how do team members shareinformal knowledge? Do organizational factors, contextual factors or variedtask types affect knowledge seeking and sharing practices in these teams? Weexamine these questions in the following sections. In particular, we areinterested in identifying team and organizational characteristics affecting thepractices of seeking and sharing informal knowledge in these teams in thecontext of IT issue resolution.

3. Research site and methods

To investigate knowledge seeking activities, we conducted an ethnographic fieldstudy of three teams in the IT department of Regional Health System (apseudonym). These teams are co-located.

3.1. Research site: the IT department at Regional Health System

The IT department at Regional Health System consists of approximately 60employees responsible for all IT systems in the hospital. It is a very busydepartment dealing with approximately 120 calls per day, and sometimes as manyas 250 calls per day during the implementation or upgrade of a major application.The department is staffed 24 hours/day.


Although the IT department at Regional Health System consists of four teams(Table 1), we focused on the following three teams because they dealt with themajority of IT issues:& Customer Service Center (CSC) – Responsible for linking the client

(technology users) and the IT department regarding issues that arise, takingclient calls, documenting issues, and forwarding issues to the appropriate ITteam.

& IT Clinical Software Services (Clinical) – Responsible for the development,implementation, and support of all clinical IT systems in Regional HealthSystem and its partner organizations.

& IT Financial Software Services (Financial) – Responsible for the develop-ment, implementation, and support of all financial IT systems in RegionalHealth System and its partner organizations.

Regardless of the issue type and ownership of the issue, the teams are expectedto work together when necessary to solve IT problems as quickly as possible andto keep the clinical work in the hospital running seamlessly.

In order to resolve each IT issue, analysts and technicians rely not only uponeach other, but also upon a variety of information technologies.& Microsoft Office Outlook – A personal information manager used mainly as

an email application.& Microsoft SharePoint – A browser-based collaboration and document-

management platform that allows users to access shared workspaces,documents, wikis, and blogs from a browser.

& HEAT – A customer service and support software used by the CSC tocapture client issues. The issue is then assigned to an analyst on one of theother IT teams based on the nature of the issue, and a notification email is

Table 1. IT teams and membership.

Team Members

Clinical Software Services • Director (1)• Project Manager (1)• Software Analysts (9)• Integration Analysts (4)

Financial Software Services • Director (1)• Project Manager (1)• Software Analysts (9)

Network Services • Admin Director (1)• Network Admins (3)• HW Specialists/Techs (3)• Architecture Specialists (4)• Telecom Specialists (2)

Customer Service Center • Director (1)• Cust Support Reps (4)


sent to the assigned person and/or team. As the issue is advanced, the analystprovides updates and resolution within the system.

3.2. The workspace

The IT department has office space in two adjacent buildings on the hospitalcampus. The Clinical and Financial teams are in the same building. The Clinicalteam is in a large open space on the first floor, while the Financial team is directlyabove on the second floor. Each team is setup in cubicles that are open to acentral corridor (Figure 1). Like many customer support settings (e.g., (Ackermanand Halverson 2004)), the cubicles are arranged in such a way that it is easy tohear the conversations and activities of other IT staff members. The layoutprovides a private workspace, while simultaneously offering a collaborativeenvironment.

3.3. Data collection & analysis

For the study, we spent over 250 hours from September 2007 to February 2009observing the work of the teams in the IT department (Table 2). We “shadowed”different team members to get an in-depth understanding of how theycollaborated with each other to seek knowledge and solve problems. We alsoconducted a number of formal and informal interviews focusing on the

Staff A Staff B Staff C Staff D Staff E

Staff F Staff G Staff H Staff I Staff J

Staff K

Staff L

Staff M

Staff N

Staff O

Staff P

Figure 1. Layout of the IT clinical software services workspace.


knowledge seeking practices of the team members and collected artifacts such asscreen shots and organizational policies. The observations and interviews yieldedmore than 400 pages of transcribed field notes and interviews for analysis.

After transcribing the field notes and interviews, we analyzed the data usinggrounded theory (GT) (Strauss and Corbin 1990). The underlying assumption ofGT is that a deep understanding of social phenomena can only occur from real-world observations. GT foregrounds the data and helps create an evolvinghypothesis through systematic data coding. In the course of this coding, patternsbecome visible giving rise to hypotheses. In turn, these hypotheses arestrengthened or dismissed via further coding of the data and, in some cases,additional data collection. The strength of GT lies in the interaction between thedata collection and the coding. The coding is a continual process that occurs notat the end of the data collection but during it; categories (e.g. themes) emerge fromthe data and are strengthened, modified, or discarded as more data is collected. Weused a qualitative data analysis software, NVivo (QSR International), to assist inthis analysis. All the data was imported into the software as documents. As datawas reviewed and compared, first-order themes emerged and nodes were created.As analysis progressed, we recorded memos in the software of emerginghypotheses at both the document and node levels. As these hypotheses weretested, nodes were modified (e.g. ordered, combined, and collapsed) and second-order categories emerged. GT helped us identify categories of team knowledgeseeking practices as they emerged from the data.

4. Issue management and resolution

The IT department at Regional Health System is responsible for all IT systemsthroughout the health system. The overall objective of the department is to haveall systems up and running 24 hours per day, 7 days per week, 365 days per year.Therefore, as issues (i.e. problems) arise, the IT teams are responsible forresolving them as quickly and efficiently as possible.

Table 2. Data collection methods.

Data Collection Methods Specific Examples Time/Quantity

Observation IT work processes, issue documentation,issue resolution

18 months, ~ 250 h

IT SW Services meetings, SoftwareImplementation meetings, Siemenssoftware meetings

15 meetings

Interviews (semi-structured) Formal 15Artifact Collection Job descriptions, Computer Access

Form, Org chart, Report Request Form,Job Status Form, Ticket Flow Chart,Services Excellence Plan

26


4.1. Competing objectives

Although providing appropriate IT support is at the heart of the IT department’swork, each team within the department has different objectives that guide theirdaily work. For the Customer Service Center, the objectives include issuedocumentation and surge management. For the Clinical and Financial teams, theprimary objectives are issue management and resolution.

The Customer Service Center is the first line of contact for clients with ITissues. The CSC’s main goal is not to solve the client’s problem. Rather, it is toidentify and document the client’s issue so that it can be assigned to a specialist inone of the other two IT teams for resolution. The CSC must manage the flow ofissues into the center and out to the appropriate IT team. However, the timing andflow of issues into the CSC is very unpredictable. Therefore, the CSC team mustmanage the surge of issues to ensure that they are assigned and subsequentlyresolved in a timely manner. On the other hand, the goals of the Clinical andFinancial teams are slightly different. In those teams, the goal is not to documentthe client issue but to resolve the issue as quickly as possible. In many cases,collaboration was essential to meeting their team, as well as their individual andorganizational goals.

4.2. Issue management workflow

When a problem or question arises with any software and/or hardware usedwithin the Regional Health System, the client (user) contacts the CustomerService Center via telephone, email, fax, interoffice memo or walk-in. The CSCrepresentative greets the client, gathers needed information – documenting theinformation in the HEAT system – and takes appropriate actions to answer thequestion or resolve the issue when possible. CSC representatives use immediatelyavailable resources such as manuals, resolved HEAT tickets and trainingdocumentation as reference during issue resolution. If the issue is immediatelyresolved, the representative updates the ticket in the HEAT system with theresolution information and closes the ticket.

However, the Customer Service Center representative only has 10 minutes toresolve the issue per organizational guidelines. If the issue is not resolved within10 minutes, the representative must escalate the issue to the next support level. Inthis case, the CSC representative notifies the client of the assigned issue numberand selects the appropriate issue type based on severity of the issue with regard topatient care and number of clients affected. The representative then assigns theissue to the appropriate second level support team. Finally, the CSC represen-tative advises the client that another IT staff member will be in contact regardingthe issue in a timeframe based on the issue type. The issue type translates intoexpected resolution time. The more critical the issue, the faster it should beresolved.


Depending on the software type, the escalated issue is either directly assignedto the on-call analyst on the Clinical team, or the issue is directed to the Financialteam’s director who then reassigns the issue to the analyst best suited to resolve itbased on specialization. Once the issue is assigned to an analyst or technician, theclient is promptly contacted to acknowledge receipt of the issue and to confirmissue details. If possible, the issue is resolved during the initial contact; however,this may not always be possible. In the following paragraphs, we describe how anon-call analyst in the Clinical team would respond to issues assigned to her.

As new issues are assigned via the HEAT customer service and supportsoftware, the on-call analyst receives a page as well as an email notification. Theanalyst then reviews the issue in HEAT, contacts the client to discuss the issue inmore depth and then attempts to resolve the issue immediately. When an issue iswell known or has occurred frequently, the analyst may already have theknowledge to talk the client through resolution. However, sometimes the issuecannot be resolved during initial contact with the client. In this case, the analystreviews the issue type to determine how long she has to resolve the issue. Themore critical the issue, the faster it has to be resolved.

When the issue is uncommon and/or complex, the analyst may need tocollaborate with others. In this situation, the analyst tries to understand theproblem by re-creating the issue in the software and viewing the actual error.During the issue resolution process, the analyst frequently talks to other analystsnot only to find needed information but also to request help in analyzing what isalready known in order to determine next steps or to further troubleshoot theproblem. Next, the analyst typically works closely with other analysts to testdifferent resolution scenarios. Once a solution is identified, the analyst contactsthe client to discuss the solution and to confirm that the issue is resolved to theirsatisfaction. Upon resolution, the analyst updates the ticket in the HEAT systemwith the resolution information and closes the ticket.

In the next section, we present our findings about how different intra- and inter-team practices regarding issue management and resolution affect informalknowledge seeking and sharing activities.

5. Findings

When addressing IT issues, we observed that particular team practices such as (1)training all team members on the basic functionality of the supported softwaresystem and (2) assigning issues affected informal knowledge seeking activities. Inaddition, we also identified certain informal knowledge seeking and sharingpractices used across teams. These practices included the creation of ad-hocteams, the evaluation of potential solutions, and the use of the organizationalemail system instead of an available KM system. We describe these practices indetail in this section.


5.1. Intra-team practices affecting informal knowledge seeking

Team processes and practices drive a team’s work activities (Campion et al.1996). In this study, we found that certain intra-team practices – team-wide basicpackage training and issue assignment– affected how team members sought andshared informal knowledge.

5.1.1. Team-wide basic package trainingEach team within the Regional Health System IT department supported a particulararea of IT (clinical, financial, etc.), and within each team, members specialized in aspecific piece of software or technology. However, every member of the Clinicalteam was also trained on the basic functionality of the clinical software package. Allsoftware packages have two major components. One component is the basicpackage, which includes the core functionality of the system. The second componentincludes select add-on modules for specific functional areas. At Regional Hospital,all members of the Clinical team were trained in the basic packaged functionality ofthe Electronic Health Record (EHR) – an electronic version of a patient’s medicalhistory. The basic package included functionality dealing with demographics,progress notes, problems, medications, vital signs, past medical history, andimmunizations. Further, each member also received additional training in a specificclinical add-on module such as laboratory, pharmacy, computerized physician orderentry and reports. Consequently, every Clinical analyst was trained in and expectedto support the basic functionality of the electronic health record while alsospecializing in an area of expertise in one of the add-on modules. This practice ofbasic package training for everyone on the team led to clinical teammembers havinga common understanding about the EHR.

This basic package training for all Clinical team members allowed them tohave common ground when discussing client issues (Clark 1996). This commonground led to easier informal knowledge exchange due to the commonterminology and understanding across the team. As the following vignettehighlights, a shared understanding of the basic software package allowed formore seamless communication and ease of interpretation between team membersworking together to resolve an issue with an interface used by nurses.

It is brought to Danielle’s attention that part of the Clinical Summary data, theMedical Orders, is not populating for some patients while they are for others.Danielle walks into Edith’s cubicle to let her know about this issue since she isthe Clinical on-call support analyst. They discuss what information is neededto diagnose the problem. Is there a pattern in the patient data that will explainthe discrepancies? Is the most up-to-date filter configuration implemented inthe production environment? They split the information search with Edithreviewing the patient data in the electronic medical record and Daniellecomparing the view filter setup in development to the one in production.Danielle goes back to her cubicle to search for this information and realizes


that the filter on the Medical Orders in production is set to a specific valuerather than showing all orders. Danielle walks back to Edith’s cubicle to sharethis information. They decide to change the filter setting in production and testit to determine if this is the root cause.

Both Danielle and Edith had a shared understanding of the basic clinicalsoftware package while also serving as “experts” in particular sub-functionalitiesof the software. Danielle’s specialty was orders while Edith’s specialty waspharmacy. While they each had an area of specialization within the clinicalsoftware, their common understanding of the basic software package allowedthem to identify where their specialized knowledge overlapped. Each of them wasable to understand the issue from their particular knowledge perspective, which inturn made it easier to share relevant knowledge with their collaborator. Therefore,as client issues arose with this software, Clinical analysts needing help to solve anissue could turn to teammates for assistance. This knowledge seeking wassupported by a shared baseline knowledge in the software, which allowed teammembers to have a common understanding and terminology to collaboratively“make sense” of the issue and the potential solutions (Paul and Reddy 2010).

Unlike the Clinical team, the Financial team was much more specialized. Theentire team was not trained in the basic financial software package functionality –only two members of the team were trained in the basic package. The other teammembers were only given specialized training in specific add-on modules, such asclaims and reports. Therefore, unlike the Clinical team, the lack of basic packagetraining left Financial team members not willing to turn to teammates forassistance because they believed that their teammates did not have the relevantknowledge to help them. Instead, members of the Financial team tended to onlyturn to specialists in the same add-on module of the software when needing help.For example, Kelly is the claims specialist on the Financial team. While sheexpressed interest in collaborating with others when claims issues arise, she alsoadmitted that she was limited in her knowledge seeking activities because she is“on [her] own” since no one else on her team specializes in the claimsfunctionality of the software. On this team, collaboration during knowledgeseeking activities was not prevalent. Given a lack of common knowledge acrossthe team, the team members tended to work on their own.

The different teams’ approaches to training their staff members led to differentknowledge seeking practices. For instance, on the Clinical team where they wereall trained on the basic software package, collaboration was the norm. On theother hand, on the Financial team, collaboration was not the norm and knowledgeseeking and sharing activities were much less prevalent.

5.1.2. 2nd level issue assignmentAnother important team practice that affected informal knowledge seeking wasthe way issues were assigned to team members. The Clinical and Financial teams


differed in their approach to issue assignment. For example, when CSC passed ahelpdesk ticket to the Clinical team, it was assigned to the on-call analystregardless of functional issue. On the other hand, tickets assigned to the Financialteam were first assigned to the team’s director who then reassigned the issue tothe analyst with specialized training and knowledge to resolve it. When it came toissue resolution, management’s expectations regarding responsibilities differedacross these teams. The Clinical team’s management expected team members tohandle client problems regardless of area of expertise, while the Financial team’smanagement emphasized specialization and individual responsibility. Theseopposing expectations led to differing work practices within each team that inturn affected knowledge seeking.

For example, the Financial team assigned issues based on expertise. Therefore,each teammember might have had several issues to resolve on a given day or none atall – it varied across the team. Since the team director believed that issue resolutionwas an individual responsibility, there was no expectation for assistance nor anyincentive to assist teammates. Further, the atmosphere of this teamwas one of a quietworking environment. There was no loud talking in the work area, no use ofspeakerphones, nor any impromptu meetings or interruptions making it nearlyimpossible to overhear conversations and offer assistance if the opportunity arose.

In contrast, the management of the Clinical team believed that issue resolution wasa shared responsibility. As a result, the Clinical team’s working environment andinteraction were more relaxed than the Financial team. In the Clinical team, it wasperfectly acceptable to interrupt a teammember to ask a question or ask for assistance.Quite often, meetings of as many as five teammembers were held in a cubicle, raisingthe noise level in the room. Speakerphones were also used allowing other teammembers in the room to overhear the conversation and offer assistance when needed.

The degree to which team members shared responsibility for these assignedissues affected the knowledge seeking and sharing activities of the team. Forexample, in the Clinical team where issue resolution was a shared responsibilityand interactions were informal, teammates overheard each other’s conversationsand jumped in to share their knowledge to resolve an issue without first beingasked for assistance. On the other hand, on the Financial team where issueresolution was seen as an individual activity and team interactions were moreformalized, team members did not share their knowledge as easily.

The shared responsibility within the Clinical team led to greater collaborationin their knowledge seeking activities as demonstrated in the following vignette.Laney, Katherine, and Danielle, members of the Clinical team, came together inan impromptu manner to troubleshoot a computerized physician order entry(CPOE) print issue.

Laney and Katherine share a large cubicle. They are discussing a CPOE printerwhere print jobs sent to the CPOE printer are always sent to the manual feed tray.Another analyst, Danielle, happened to be walking by the cubicle and overheard


the conversation. Danielle stopped to participate in the troubleshootingdiscussion because she is very experienced in dealing with printing issues.Danielle suggested that further information was needed to determine the cause ofthe problem. What are the settings on the CPOE reports? Have the settings on theprinter in question been changed? Danielle logged into the electronic medicalrecord to review the report settings while Katherine called the on-site PCtechnician to find out if the printer settings had been changed.

Both Laney and Katherine, CPOE functionality experts, worked together totroubleshoot the CPOE issue at hand. Yet, because of the sense of sharedresponsibility and the helpful nature of the Clinical team, Danielle offered herexpertise because she happened to overhear the conversation. The cooperativespirit within this team allowed for additional collaborators to be involved inknowledge seeking activities without the need to explicitly ask them.

In contrast, the Financial team, with their sense of individual responsibility andquieter environment, had less opportunity for this type of knowledge seeking.Consequently, potential collaborators in the issue resolution process could easilybe overlooked. In this team, the analysts would first determine with whom itwould be most beneficial to collaborate, then formally request their assistance viaan email for phone conversation, then set up a time to discuss the issue. Thissometimes took hours if not days, slowing the issue resolution process.

At 10:00 a.m., Jeni, a financial software services analyst, receives a newHEAT ticket stating that the physician scheduling software is runningextremely slowly. Jeni cannot do anything about this issue herself as theserver most likely needs to be rebooted. Therefore, Jeni emails Randy, anetwork administrator, to let him know of the issue and to ask for his help insolving the problem. An hour later, at approximately 11:02 a.m., Randyresponds to Jeni’s email and suggests they the server be rebooted at 12:30 p.m.over the lunch hour. In the meantime, Jeni receives more HEAT tickets fromother clients complaining that the system is slow and that other users cannoteven log into the system. Eventually, at approximately 11:30 a.m., Jeni callsRandy to discuss their options for fixing the connectivity issues.

The individual nature of the Financial team led Jeni to first determine fromwhom to seek expert knowledge in solving the connectivity problems and then toformally request assistance via email. If the culture of the Financial team wasmore similar to the Clinical team, Jeni might have called Randy directly or evenstopped by his desk to discuss the problem and request assistance. Instead, Jeniused more formal channels that led to an extended (1.5-hour) turn-around time insolving the problem.

These intra-team practices affected the informal knowledge seeking andsharing activities of team members. In the next section, we describe informalknowledge seeking and sharing practices common across the teams.


5.2. Inter-team practices affecting informal knowledge seeking

In collaborative environments, certain practices are particularly useful in seekinginformal knowledge. Some of these practices include the use of an expertiseconcierge to identify knowledge sources (McDonald and Ackerman 1998) andthe use of boundary objects to contextualize explicit knowledge (Lutters andAckerman 2007). In this study, we observed IT team members use threeparticular work practices to seek and share informal knowledge across teamboundaries. These practices were (1) creating ad-hoc teams, (2) evaluatingpotential solutions, and (3) using email instead of a traditional KM system forknowledge seeking.

5.2.1. Another approach to expertise seeking: creation of ad-hoc teamsThe IT department at Regional Health System consists of four permanent teams(described in section 3.1), each responsible for a specialized area of IT. However,because the knowledge needed to solve complex IT issues is often spread acrossdifferent people who may or may not be on the same team, ad-hoc teams wereoften temporarily created to find and apply the informal knowledge needed tosolve a particular IT issue. The creation of ad-hoc teams served two purposes: 1)to bring the experts together to find out what they know, and 2) to share theinformal knowledge “right then and there”.

It was often simple to pull together these ad-hoc teams because the people withthe required knowledge were usually co-located and could meet face-to-face towork on issues. These temporary teams dispersed once the issue was resolved.The following vignette highlights the practice of creating an ad-hoc team to bringtogether the knowledge needed to solve an issue.

Jim, a CSC representative, cannot resolve a client issue in the time allotted;therefore, he creates a HEAT ticket and assigns it to Richard on the ClinicalSoftware Services team. Richard is able to determine the cause of the problemimmediately (the user has access rights to the scanning folders on the networkthat are beyond his job need); however, Richard does not have the knowledgeto determine exactly how to resolve the issue. Therefore, Richard pullstogether an ad-hoc team of experts to tackle the problem. Richard calls ameeting to discuss the problem. The meeting participants include Chip, asystems programmer, Chris, a network technician, and Matt, a projectmanager. The meeting takes place in Richard’s office so that everyone inattendance can discuss the issue while having access to the system andnetwork in question.

When Richard realized that he did not have the necessary knowledge to solvethe access rights problem, he turned to other members of the IT staff who didhave the expertise needed to solve the problem. The ad-hoc team that Richardcreated consisted of IT department staff members with expertise and experience


in the software as well as the network architecture, representing different internalIT teams.

When asked in a survey of the entire IT department why they choose tocollaboratively seek the knowledge that they need to solve a problem,respondents answered that the potential collaborator(s) had either the technicalor the domain expertise needed to help solve the problem. Further, when askedspecifically how to choose with which expert to collaborate, one intervieweeexplained it as follows, “Aside from the things we already talked about as far asskill, reputation, competence, rapport … I will go to somebody that will [help]me [with] the answer [quickly] because I need to get it done.” While there may beseveral experts from which to choose to participate in the ad-hoc problem solvingteam, those experts that have a good reputation for proficiency as well as thosewho are amiable and have good relations with others are sought out to participateon these ad-hoc teams. At times, team members also brought in staff from acrosshospital departments to deal with particularly difficult IT issues. While moredifficult to assemble and organize, these ad-hoc teams were created because theend users of the software often held valuable knowledge about a particularsystem’s use and functionality.

In the following vignette, Kim, a clinical software analyst, pulls together ateam of experts to solve a pharmacy order issue.

As the on-call analyst for the electronic medical record system, Kim receives anew ticket regarding the ancillary number for a pharmacy order. After logginginto the system and reviewing the medication order in question, Kim calls theclient and asks for the order number of the medication in question. Next, Kimcalls the pharmacist to discuss the ancillary number error. They discuss thepotential of resending the medication order. With this in mind, Kim brings Matt(a project manager and integration specialist) into the discussion to determineif the order can even be re-sent. Matt investigates the issue in the interfaceapplication. Together, they find the pharmacy transaction and Matt suggeststhat they resend the transaction. They do, however this does not solve theirproblem. Kim again calls the pharmacists and asks if the time on themedication can be changed so that the ancillary number can be generated.The pharmacist says that this is possible.

The medication order issue was complex because it involved data sent acrosstwo different systems. While Kim is very knowledgeable about the electronicmedical record system, she is not an expert in either data interfaces or the pharmacysystem. Therefore, she created an ad-hoc team of herself, a pharmacist, and anintegration specialist. Together, they used their respective informal knowledge todiagnose the problem, offer potential solutions, and troubleshoot the issue. Thecreation of ad-hoc teams was a common practice in the IT department, particularlyfor issues that involved more than one system. This practice allowed IT membersto share their informal knowledge to solve an IT issue.


While these ad-hoc issue resolution teams shared their informal knowledge todiagnose problems, provide possible solutions and troubleshoot as needed, theiractions were not as formal and organized as a traditional team brainstormingsession. For instance, the teams were much smaller than the ideal six to twelveparticipants for traditional brainstorming (Rickards 1999). Further, these ad-hocteams often met “on the fly” as problems arose and without any pre-warning orset agenda (Rickards 1999). Lastly, while potential solutions where generated, thelist of solutions was not exhaustive. Solutions where brought forth andconsidered until one that could solve the problem “well enough” was encounteredas will be discussed in the next section.

5.2.2. Knowledge evaluationThe creation of ad-hoc teams did more than just bring experts together to answerquestions. Instead, these experts engaged in the issue (shared understanding andresponsibility) and shared their knowledge, expertise and experience as part ofissue resolution, not merely as a “work around” to work processes (Ehrlich andCash 1994). Further, these ad-hoc team members resolved the issues collabora-tively. The ad-hoc teams went beyond just expertise location and served as asetting where informal knowledge was shared, evaluated and applied.

Once the informal knowledge was found and shared, team members had todetermine if the subsequent solution would be helpful in solving the issue athand. In essence, they had to determine if the correct knowledge was foundto resolve the issue. Therefore, another important aspect of knowledgesharing was the evaluation of that particular knowledge to ensure that it wasuseful in the current situation. If not, team members would have to continuesearching for the appropriate knowledge needed to solve the problem. Weobserved two knowledge evaluation techniques: 1) testing the knowledge and2) deliberation.

One way to determine if the correct informal knowledge was found is to testthe resulting potential solution. When resolving a software or hardware issue,team members often performed empirical investigations based on the proposedsolution. First, they ran through a scenario to recreate the issue. Then, they madechanges to the hardware or software based on what was learned by the gatheredknowledge. Next, they ran through the scenario again to see if applying the newsolution changed the results. If the solution resolved the problem, the team wasfinished. However, if not, the team continued working until the appropriateknowledge needed to solve the problem was found.

To demonstrate testing as a knowledge evaluation practice, we continue thestory about Richard and his ad-hoc team attempting to resolve the folder accessrights issue.

…On his computer, Richard shows the team the current permissions settingsfor the scan folders. They talk through what permissions should and should


not be given to users based on a previous system configuration. The teamdiscusses if the scanning groups should be broken down more granularly. Afterthe team members share their particular knowledge on the subject, Matt says,“Why don’t we take the global group and give them read/write/modify? I couldhave sworn modify allows for deleting of files.”Richard suggests that they testMatt’s hypothesis. Richard edits the share permissions and then suggests thatthey do a preliminary test where Chris attempts to get access to the scan foldernow that the Everyone group has been removed from share permissions.Richard and Matt walk over to Chris’s desk to have him test his access. Chris’saccess to the scan folder is denied. This proves that removing the Everyonegroup from the share permissions seems to have worked. The meeting isadjourned. At this point, the issue is considered resolved.

As described in this vignette, team members were seeking knowledgeregarding folder permissions. The knowledge seeking activities involved anexchange between experts combined with the use of information found in anexisting system. Next, they evaluated the usefulness of the knowledge to solvethe current problem through testing the potential solution generated throughknowledge exchange. Once the potential solution proved useful then theknowledge was clearly appropriate and used to solve the problem.

Another knowledge evaluation technique was the use of deliberation, wheredifferent aspects of an issue were discussed. We observed two types ofdeliberation. One type of deliberation was focused discussion of the viability ofa single solution. We call this “solution-vetting”. Solution-vetting was used toappraise or validate one particular solution to the problem that arose throughcollaborative knowledge seeking activities. The other type of deliberation tookplace when there was no apparent solution, leading to a more general, open-ended discussion. During these open-ended discussion sessions, team membersbrainstormed to generate potential solutions. Often, potential solutions wherepresented until one arose that was sufficient.

In the instance of a solution-vetting session, a single proposed solution wouldbe presented to the ad-hoc team members and discussed. This allowed the teammembers to “check” the solution for application to the problem. In the followingexample, Richard proposed a solution to a problem with the existing ghost serverand received feedback on his solution from his teammates. The team used thisfeedback to modify the proposed solution to fix the ghost server.

Richard, a network administrator, walks into the office of Chris, a networktechnician, to ask his opinion about moving the ghost server to a faster switch.Richard further explains that if this is done, then the ghost server will be onthe new network. Chris recalls an issue they had the last time they tried tomove the ghost server to the new network. Chris explains that there wereissues seeing the ghost server from devices on the old network; therefore,Richard’s proposed solution will not suffice. As a result, Richard decides to put


the ghost server on the old network, but on a new switch. This allows for fasterperformance (data transfer), while allowing all devices to see the server.

Richard presented his proposed solution to move the ghost server to Chris.Chris then gave Richard feedback on the proposed solution explaining thatdevices on the old network would not see the ghost server if it was configured asRichard proposed. Based on this knowledge, they modified the proposed solutionto allow for faster performance and access to all devices regardless of networklocation.

Team members also employed open-ended discussion sessions as a knowledgeevaluation technique. In these situations, not only would team members exchangetheir views, ideas and knowledge but they would also consider all sides of theissue when weighing the applied knowledge for relevance or sufficiency. Theteam members took turns presenting what they knew, potential solutions based onwhat they knew, and their opinions on both, eventually leading to a potential,useful solution. In the following example, Laney attempted to configure aworkflow by mapping potential scenarios with her teammate, Katherine.Together, they reviewed scenarios and generated a list of potential configurationissues. These issues were further discussed with other experts, and based on thatdiscussion the potential configuration was found to be inadequate.

Laney is configuring the electronic medical record software to deal with anAssessments/Foley workflow issue. Laney, who shares a cubicle withKatherine, asks Katherine to review workflow scenarios with her using theconfigured solution. When a Foley is inserted in a patient, a checkbox must tobe clicked and a date of insertion entered in the patient assessment record. Thesame must be done when a Foley is removed. Yet, neither is required by thesystem and these checkboxes trigger the workflow and send data to a log forreference. Katherine explains that the system most likely works off both thecheckboxes and the dates, but she needs to confirm. While Laney meetsvirtually with the clinical information specialist to review the Foley workflow,Katherine has a conference call with a technical specialist at the softwarevendor. In her meeting, Katherine gathers information that will affect theconfigured solution. She discovers that the nurses must physically check thebox on insertion, but the trigger can run off the removal date, not the removalcheckbox. Katherine returns to her cubicle and shares this information withLaney. Based on this newly gathered information, Laney will rollback herconfiguration changes and wait for the vendor to get back to them withanother potential solution.

Laney, while proficient in workflows in the electronic medical record softwareand with the Foley workflow, lacked the confidence to generate a proposedsolution to the workflow issue. Consequently, she turned to her colleague,Katherine. The analysts took turns presenting and sharing information and their


own knowledge with regard to Assessments/Foley workflow. This allowed themto evaluate both their knowledge and the potential solutions. The collaboratorsacted as “sounding boards” for each other as a means of evaluating potentialsolutions. They weighed and examined the options for designing the Assess-ments/Foley workflow, carefully considered these options, and then made adecision based on these deliberations. While they did not come to an agreed uponsolution, they did determine that the current potential configurations would notsuffice and therefore further knowledge seeking would need to take place.

Team members used collaborative evaluation techniques such as testing anddeliberation to determine if the informal knowledge proposed by team members,and the resulting solution, was useful to address the IT issue in a given situation.

5.2.3. Use of emailIn the IT department, there were a number of technologies available to staffmembers. While the organization has a traditional, packaged knowledgemanagement system, Microsoft SharePoint, they did not use this KM system tofind information and pertinent knowledge because it did not support theircollaborative knowledge practices. Further, it was not integrated into their workroutines and processes. Instead, IT staff members most often used a traditionalcommunication tool, email. They used email both asynchronously and synchro-nously to support informal knowledge seeking and sharing activities.

There were three major reasons why Microsoft SharePoint was not widely usedby the IT staff. First, when seeking and sharing knowledge with a collaborator,the IT staff needed a medium of communication. Microsoft SharePoint, asimplemented at Regional Health System, did not allow for communicationbetween collaborators, synchronously or asynchronously. Therefore, IT teammembers had to use email to seek and exchange knowledge. While SharePointcould have supported this type of communication, Regional Health System didnot implement the software with this functionality enabled.

Second, the IT staff had long been using network file folders to store and sharedocuments and other pertinent IT system information. The IT staff viewedMicrosoft SharePoint as a glorified network file folder and therefore saw nobenefits to changing their current work processes and practices to incorporateSharePoint. Because the staff thought it would require additional work to putinformation into SharePoint, they chose not to and continued to use the networkfile folders for document storage. Additionally, while Regional Health Systemused Microsoft Office productivity tools including Outlook, SharePoint was notintegrated into this suite of tools. This lack of integration made it more difficult touse SharePoint seamlessly because it was difficult to link to or send codifiedknowledge from within SharePoint to the knowledge seeker. Therefore, IT staffmembers continued to use Microsoft Outlook to seek and share knowledge asneeded.


Finally, while IT staff members were encouraged to use Microsoft SharePoint,they were not mandated to use it. Consequently when they found it difficult toincorporate into their work routines and knowledge seeking practices, they fellback to using the corporate email system.

Although IT staff members used Microsoft Outlook as the tool of choice forseeking and sharing knowledge, they did so by adapting it to their needs. In thefollowing vignette, Kristina, a financial software analyst, and Bill, a CSCrepresentative, are sharing what they know in order to get a needed report. In thisvignette, email was used asynchronously to share knowledge between collabora-tors, allowing Kristina eventually to resolve the issue.

2:20 PM: While still on the phone, Kristina reviews her latest emails. She seesa response to an ongoing email conversation with Bill regarding a neededreport. Based on Bill’s reply asking for a piece of information from the SWIMapplication, Kristina goes into SWIM to look up the report archive. 3:39 PM:Kristina reviews her email again and sees another follow-up from Billregarding the November report. Based on the information provided by Kristinain the previous email, Bill gives Kristina instructions as to how to label thereport request. Kristina logs into the Signature application and completes theinstructions then emails Bill to let him know that she has completed therequest.

We also observed email used synchronously in “real time” much like an instantmessenger technology. It took the place of traditional synchronous communica-tions such as face-to-face and phone conversations. In the following vignette,Janice, a financial software analyst, uses email synchronously to solicit help fromCandice, another financial software analyst.

Janice is working on a new report. She runs the report and logs into thehospital financial system to compare data in the system to data on the report.Janice is unsure about a code in the financial system and wants to ask theclaims analyst, Candice, about it. Yet Candice is on the phone. In order to gether attention, Janice emails Candice hoping that Candice will see the pop-upemail notification and respond while on the phone. Candice does see thenotification and email and once she finishes her phone call she answers Janiceverbally through the cubicle wall. However, Janice has other questions as well.The analysts continue to discuss options and code meanings through the wallof their cubicles. Eventually, Candice walks over to Janice’s cubicle to seewhat she sees on the screen. Together, they review the data on the screen.Janice clarifies to Candice the data she needs to pull for the client. Candiceexplains a way to see the data, and then explains how to see if the informationis on the claim itself.

Janice’s lack of expertise triggered her need for Candice’s help to find theneeded knowledge. In order to initiate the collaboration, Janice used email to


solicit Candice’s help because in the IT department management does not allowany instant messaging applications. Because Janice wanted help immediately, sheused email as an “instant messenger client,” allowing her to get Candice’sattention and start the process. In this case, email was used in place of IM toinitiate the knowledge seeking activities after which, interactions took place face-to-face. As these vignettes demonstrate, the practice of using email in informalknowledge seeking and sharing activities was common in this environment.

We found that IT staff members adapted their email system to elicit and shareinformal knowledge. While traditional knowledge management systems are oftenthought to be the best way of sharing organizational knowledge, othertechnologies, depending on circumstances, might be better suited for knowledgeseeking and sharing. In the case of Regional Health System, email was thepreferred technology for knowledge seeking and sharing.

6. Discussion

Our fieldwork highlighted the intra- and inter-team practices that affectedinformal knowledge seeking and sharing in a collaborative environment. Wenow turn our attention to discussing the role of teams and KMS technologies inknowledge practices and how temporality affects these knowledge practices.

6.1. Role of teams in informal knowledge seeking and sharing

In response to a complex, global, and competitive environment, teams are playinga more prominent role in organizational tasks and functions (Guzzo and Shea1992; Hackman 1990). Organizations are increasingly faced with complexsituations where uncertainty, stress, and time-criticality influence decision-makingand problem solving. To deal with these complex situations, organizations havecreated teams of knowledge workers. In these teams, knowledge is distributedacross members with different experience and expertise, who act with incompleteinformation in an uncertain environment (Cannon-Bowers et al. 2001).Consequently, knowledge seeking and sharing in this environment is a non-trivial task.

However, not all teams are alike. They vary across a wide spectrum ofcharacteristics including location (co-located, virtual), permanence (ad-hoc,permanent), level of knowledge (expertise, training), homogeneity of members,formality of interactions, and configuration (self-directed, hierarchically managedteams) (Campion, et al. 1996). In our findings, we described the formation ofad-hoc teams and how the makeup and characteristics of these teams affectedknowledge seeking activities within the IT department. However, other featuresof teams can also influence knowledge seeking activities. For instance, oneimportant characteristic is the physical co-location of potential knowledgecollaborators (Reddy and Jansen 2008; Reddy and Spence 2006). This facilitated


the use of face-to-face interaction as the primary means of communication duringknowledge seeking. On the other hand, team members who were not physicallyco-located used communication technologies to support their interaction duringthese activities (Kellogg, et al. 2006; Tamaru et al. 2005). Clearly, different teamcharacteristics can lead to different approaches to knowledge seeking.

Although the primary focus of this study was on the seeking and sharing ofinformal knowledge within teams, we also identified some interesting issuesrelated to these activities when members of different teams interacted. Often, inthe ad-hoc teams described in the findings, the knowledge sharing aspects that arecrucial to successful problem resolution were severely affected when people weredrawn in from different teams. For instance, team members who preferred tointeract more “formally” (i.e. Financial team) would react negatively to membersfrom another team who had more relaxed interaction methods (i.e. Clinical team).This negative reaction hindered the seeking of informal knowledge because itrequired members from one team to modify their behavior to match theexpectations of the other, which was often done only grudgingly. Therefore,inter-team activities frequently required the management of different teamcharacteristics before knowledge seeking activities could be successfully carriedout. However, when seeking formal knowledge such as documentation orprocedural knowledge, team characteristics were not as influential because theseactivities often took place via electronic means including email where theformality or informality of interactions was not as problematic.

6.1.1. Organizational implicationsThese findings have interesting implications for managers when structuring anddesigning their teams to support informal knowledge sharing.

First, team structure and culture have been shown to influence teamperformance (Orchard et al. 2005) as well as individual job satisfaction (Glissonand James 2002). Our study demonstrates that team practices can also influenceinformal knowledge sharing. When the team practices support discussion in anopen and shared office space where it can be heard by many people, this can leadto more unplanned interactions and potentially more collaboration and knowledgesharing.

Further, our study also highlights how team-wide basic system training canplay an important role in the knowledge activities of a team, leading to moreinformal knowledge sharing. This was due to the common terminology andexpertise across a team. Basic system training for an entire team as a practice tofoster knowledge sharing is not new (Cabrera and Cabrera 2005) as it has beenshown to increase interactions, provide a common language and build social ties.However, our study highlights the important role that this basic training plays insupported informal knowledge seeking and sharing by allowing for moreseamless communication and ease of understanding between team memberssharing their informal knowledge in order to resolve issues. When an entire team


is trained in the basic functions, whether it is in a technology, a policy or aprocess, then all team members share a common terminology and baseline set ofskills that they could reference when working collaboratively. Thus, team-widesystem training allows more team members to be knowledgeable about a topicand therefore available for collaboration and knowledge sharing when dealingwith issues.

Although researchers have studied the relationship between team practices andconstructs such as performance, effectiveness, and knowledge transfer (Goh 2002;Marks et al. 2002), we need to further explore the relationship between teampractices and knowledge seeking activities both within and between teams.

6.2. Temporality and knowledge seeking

In these team environments there are many characteristics that affect howknowledge practices take place. An interesting aspect of the informal knowledgeseeking and sharing activities was the role of temporality in these activities. TheIT department used “issue type” to categorize client problems based on severitywith regard to patient care and number of clients affected. The issue type thentranslated into expected resolution time. The more critical the issue, the faster itwas to be resolved.

In a previous study (Reddy et al. 2006), we examined information-intensivehealthcare environments where patient care activities often required a quick paceof work. Consequently, there was urgency to finding the needed knowledgebecause it was critical for patient care. However, in different organizationalsettings, the pace and importance of work can vary dramatically. For instance, aswe observed in the IT department, in cases of routine or non-patient criticalsystem issues, the resolution of the problem could take several days. On the otherhand, if the extremely important electronic medical record system goes down, theproblem must be resolved as soon as possible or there could be significantconsequences. Therefore, a “hot issue” – an issue that has top priority and mustbe immediately dealt with by the IT teams (i.e., critical and urgent) – often led to“faster” knowledge seeking activities. In these situations, the increased pace andimportance of the work required solutions to be found more quickly.

The pace and importance of the work affected knowledge seeking activities. Ifthe problem was not immediate (i.e. non-critical), these activities took a longerperiod of time. However, if the pace increased due to problem importance (i.e.,critical), there was also an increased urgency in the knowledge seeking activities.Consequently, this affected the knowledge sources used (they type of knowledgesought) and the modes of interaction between team members.

First, during normal paced activities when a solution was not immediatelyneeded, IT team members often turned to electronic and textual sources of formalknowledge such as HEAT and technical manuals. Since there was little urgency,team members had the time to search through these various formal knowledge


sources to identify the potentially applicable solution. However, in a fast-pacedenvironment where the task is critical, team members turned to human experts asthe primary sources of both formal and informal knowledge (Reddy et al. 2002;Reddy and Spence 2006). These experts could be other team members or peopleoutside the department. During a fast-paced work activity, turning to humanexperts allowed team members to resolve the issue more quickly through thecreation of ad hoc teams and the sharing of informal knowledge between theexperts.

Second, during normal paced work activities, team members interacted witheach other in a variety of ways when seeking knowledge. For instance, teammembers may exchange more formal knowledge via email or voicemail as thereis little need for details and explanation. In general, because there was little needfor an immediate response, knowledge seeking during these activities was oftenasynchronous. However, if there was an immediate problem that neededresolution and the pace of the activities were increased, the interaction wassynchronous and usually involved direct communication such as face-to-face orover-the-phone discussions. The interaction mode during fast-paced andimportant knowledge seeking activities was more direct than in normal pacedor less important activities. Often times when ad hoc teams were broughttogether, they met face-to-face to better understand the issue, share their informalknowledge and develop potential solutions.

Other researchers (Dix 1992; Landgren 2006) have also highlighted how thecriticality and pace of work influences the types and intensity of the interactionsbetween various team members. In organizational settings, the pace of work isimpacted by the importance of a particular problem. In turn, pace impacts the on-going knowledge seeking activities in these settings. In summary, when non-critical, non-time sensitive issues arise, people turn to formal knowledge sourcesto help resolve the issue. However, then critical, time sensitive issues arise,people turn to the experts to share their informal knowledge and apply thatknowledge in a team context to resolve the issue.

6.3. Implications for design to support informal knowledge seeking and sharing

Organizations implement knowledge management systems as a means ofsupporting the creation, capture, storage, and dissemination of knowledge.Oftentimes these knowledge repositories are organized around a subject area,while others are organized around an organizational process (Kwan andBalasubramanian 2003, p. 204). For CSCW researchers, technology developmentwith regard to knowledge management has focused on organizational memoryand social networking systems (Ackerman 1994; Cabitza and Simone 2009;Ehrlich, et al. 2007).

While organizational memory and social networking systems are useful,particularly in larger, more dispersed organizations, the systems are less useful in


smaller, co-located organizations such as the IT department of Regional HealthSystem. At Regional Health System, the staff knows each other quite well andhas frequent face-to-face interaction. Further, their personal, work-related socialnetworks are quite large and the organizational culture is such that collaborationis encouraged and expected. In this type of environment, an easy, flexible, andseamless communication technology that facilitates knowledge seeking ispreferred. In the case of Regional Health System, email served multiple purposesas an everyday communication and time management tool as well as a tool tofacilitate knowledge seeking.

KM systems should not only support knowledge seeking activities but alsosupport collaboration amongst the knowledge seekers. In particular, we haveidentified three specific features that support informal knowledge seeking andsharing activities in a collaborative environment.& Asynchronous collaboration – The ability to asynchronously communicate is

vital in supporting knowledge seeking activities (Edwards, et al. 1997). Yet,additional functionality could be useful to the asynchronous knowledgeseeking process such as, keeping each knowledge seeking “stream” uniquewithin the technology and easily recognizable to the user, while allowing fora continuous flow of information into and out of the application. While atitle or subject line is useful in this situation, other functional options mightalso be valuable, including tags, keywords, folders, labels or the use of analgorithm to automatically connect knowledge seeking “streams” (Giacolettoand Aberer 2003; Tang, et al. 2008). This is especially useful when amember of a team is collaboratively seeking knowledge with more than oneteammate regarding separate issues. This will allow users to distinguishbetween the various collaborations as they progress.

& Chat – Clearly, one of the most important functions that KM systems need tosupport is synchronous communication. A chat function allows collaboratorsto interact with each other in real-time and plays an important role inenhancing the knowledge seeking process. Team members could use thisfunctionality to seek, access, and share knowledge and to provide feedback –synchronously. A chat message is much less intrusive and more subtle than aface-to-face interruption, but more noticeable and often faster than regularemail.

& Awareness – Knowing what other people are doing is important duringknowledge seeking activities. Therefore, KM systems should providepresence awareness information for the team members (e.g., availabilitymessages). In team settings with a formal mode of interaction, this isextremely useful and important. Based on the issue, a team member maychoose to collaborative when seeking informal knowledge from a potentialsubset of team members. Knowing which of these team members are and arenot available could help determine with which expert to collaborate, helpingto streamline the process.


The challenge in designing these and other features lies in not only developingthe individual components but also effectively integrating them together into aKM system in order to ensure that the system seamlessly supports collaborationas part of the informal knowledge practices of organizational teams.

Proposing features such as awareness, conferencing, chat, and visualization isnot new (Blackwell et al. 2004; Ertzscheid 2001; Morris and Horvitz 2007;Twidale and Nichols 1998). However, these features have been developed insystems that primarily support knowledge practices that take place via the Web,not in an organizational team environment. Furthermore, an organization may notwant to invest in a specialized KM system, but rather to incorporate usefulfunctionality into existing organizational technology, such as email. The design ofknowledge management systems is predicated on the formal capture ofknowledge to be accessed by others in the organization at different times. Whatwe found was a much more subtle set of interactions taking place. We do notsuggest replacing existing organizational knowledge management systems, butrather adding features to support collaborative knowledge seeking practices.

7. Conclusions

Knowledge seeking and sharing has long been viewed as an activity whereindividuals use knowledge repositories to find the knowledge needed to answer aquestion or solve a problem. Consequently, most current organizationalknowledge management systems are designed to support the seeking andacquisition of codified knowledge or the identification of experts that have thisknowledge themselves. However, there is growing interest in understanding therole that collaboration plays in seeking and sharing informal knowledge. Yet,before we can design usable and useful collaborative knowledge managementsystems, we need to understand not only how team members collaboratively seekinformal knowledge, but also how contextual factors such as team characteristicscan affect the activities of the users of these systems.

Our study focused on understanding intra- and inter- team practices and theireffect on informal knowledge seeking and sharing. Through this study, wedescribed how knowledge seeking and sharing is an integral aspect of the workthat takes place in the IT department. During the course of their work, IT teammembers often collaborate to find the needed knowledge to solve a particularproblem. In particular, we highlighted how the team members have developeddifferent knowledge seeking practices such as the creation of ad-hoc teams, theevaluation of potential solutions generated from the shared informal knowledge,and the use of email as an informal knowledge seeking and sharing tool.Collectively, these practices as well as team-wide basic system training and taskassignment point to how knowledge practices are affected by a variety of implicitand sometimes subtle features of the organization or team.


Our research also raises some questions for further investigation. What otherteam and organizational practices enable collaborative knowledge seekingpractices? What practices inhibit these activities? We must continue to examinethese and other important issues as we design, develop, and implementcomprehensive policies, procedures and technologies to support collaborativeknowledge seeking in different contexts.

Acknowledgements

We would like to thank all the participants from the IT department of RegionalHealth Systems. This study was supported in part by National ScienceFoundation grants IIS 082428 and 0844947.

References

Ackerman, M. (1994). Augmenting the Organizational Memory: A Field Study of Answer Garden.In Proceedings of the ACM conference on Computer Supported Cooperative Work (CSCW'94),Chapel Hill, NC, USA, 243–252.

Ackerman, M., & Malone, T. W. (1990). Answer Garden: A Tool for Growing OrganizationalMemory. In Proceedings of the ACM SIGOIS and IEEE CS TC-OA conference on Officeinformation systems (COCS'90), Cambridge, MA, USA, 31–39.

Ackerman, M., & McDonald, D. W. (1996). Answer Garden 2: Merging Organizational Memorywith Collaborative Help. In Proceedings of the ACM Conference on Computer SupportedCooperative Work (CSCW'96), Boston, MA, USA, 97–105.

Ackerman, M., & Halverson, C. (1998). Considering an organization’s memory. In Proceedings ofthe ACM conference on Computer Supported Cooperative Work (CSCW'98), Seattle, WA, USA,39–48.

Ackerman, M., & Halverson, C. (2004). Organizational memory as objects, processes, andtrajectories: an examination of organizational memory in use. Computer Supported CooperativeWork (CSCW), 13(2), 155–189.

Alberts, D. J. (2007). A model of multidiscipline teams in knowledge-creating organizations. TeamPerformance Management, 13(5/6), 172–183.

Bandini, S., Colombo, E., Colombo, G., Sartori, F., & Simone, C. (2003). The role of knowledgeartifacts in innovation management: the case of a chemical compound designer CoP. InProceedings of the First International Conference on Communities and Technologies (C&T2003), 327–327.

Bates, D. W. (2002). The Quality Case for Information Technology in Healthcare. BMC MedicalInformatics and Decision Making, 2(7)

Blackwell, A., Stringer, M., Toye, E. F., & Rode, J. A. (2004). Tangible interface for collaborativeinformation retrieval. In Proceedings of the ACM Conference on Human Factors in ComputingSystems (CHI'04), Vienna, Austria, 1473–1476.

Cabitza, F., & Simone, C. (2009). Active artifacts as bridges between context and communityknowledge sources. In Proceedings of the 4th International Conference on Communities andTechnologies (C&T 2009), University Park, PA, USA, 115–124

Cabrera, E. F., & Cabrera, A. (2005). Fostering knowledge sharing through people managementpractices. The International Journal of Human Resource Management, 16(5), 720–735.


Campion, M. A., Papper, E. M., & Medsker, G. J. (1996). Relations between work teamcharacteristics and effectiveness: a replication and extension. Personnel Psychology, 49(2), 429–452.

Cannon-Bowers, J. A., Salas, E., & Converse, S. (2001). Shared Mental Models in Expert TeamDecision Making. In R. J. Sternberg & E. Grigorenko (Eds.), Environmental Effects on CognitiveAbilities (pp. 221–246): Lawrence Erlbaum Associates.

Clark, H. (1996). Using language. New York: Cambridge University Press.Dix, A. (1992, Sept). Pace and Interaction. In Proceedings of the HCI’92 Conference: People and

Computers VII, York, UK, 193–207.Dörner, C., Pipek, V., & Won, M. (2007). Supporting Expertise Awareness: Finding Out What

Others Know. In Proceedings of the Symposium on Computer Human Interaction for theManagement of Information Technology (CHIMIT '07), Cambridge, MA USA.

Edwards, K., Mynatt, E., Petersen, K., Spreitzer, M., Terry, D., & Theimer, M. (1997). Designingand Implementing Asynchronous Collaborative Applications with Bayou. In Proceedings of the10th Annual ACM Symposium on User Interface Software and Technology (UIST'97), Banff,Alberta, Canada, 119–128.

Ehrlich, K., & Cash, D. (1994). Turning Information into Knowledge: Information Finding as aCollaborative Activity. In Proceedings of the Digital Libraries '94, College Station, TX, 119–125.

Ehrlich, K., Lin, C.-Y., & Griffiths-Fisher, V. (2007). Searching for experts in the enterprise:combining text and social network analysis. In Proceedings of the International ACMSIGGROUP Conference on Supporting Group Work (GROUP'07), Sanibel Island, Florida,USA, 117–126.

Ertzscheid, O. (2001). An Attempt to Identify and Manage Collective Practices Involved inInformation Retrieval. In Proceedings of the 5th World Multi Conference on Systemics,Cybernetics and Informatics (SCI/ISAS 2001), Orlando, FL.

Giacoletto, E., & Aberer, K. (2003). Automatic Expansion of Manual Email Classifications Basedon Text Analysis On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, andODBASE (pp. 785–802).

Glisson, C., & James, L. R. (2002). The cross-level Effects of culture and climate in human serviceteams. Journal of Organizational Behavior, 23(6), 767–794.

Goh, S. C. (2002). Managing effective knowledge transfer: an integrative framework and somepractice implications. Journal of Knowledge Management, 6(1), 23.

Greer, J., McCalla, G., Cooke, J., Collins, J., Kumar, V., Bishop, A., et al. (1998). The IntelligentHelpdesk: Supporting Peer-Help in a University Course Intelligent Tutoring Systems (pp. 494–503).

Guzzo, R. A., & Shea, G. P. (1992). Group Performance and Intergroup Relations in Organizations.In M. D. Dunnette & L. M. Hough (Eds.), Handbook of industrial and organizationalpsychology (2nd ed., Vol. 3, pp. 269–313). Palo Alto: Consulting Psychologists Press.

Hackman, R. (Ed.). (1990). Groups that Work (and Those That Don’t): Creating Conditions forEffective Teamwork. San Francisco: Jossey-Bass Publications.

Howells, J. R. L. (2002). Tacit knowledge, innovation and economic georgraphy. Urban Studies, 39(5–6), 871–884.

Huysman, M., & Wulf, V. (2006). IT to support knowledge sharing in communities, towards asocial capital analysis. Journal of Information Technology, 21(1), 40–51.

Joshi, K. D., Sarker, S., & Sarker, S. (2007). Knowledge transfer within information systemsdevelopment teams: examining the role of knowledge source attributes. Decision SupportSystems, 43, 322–335.

Kellogg, W. A., Erickson, T., Wolf, T. V., Levy, S., Christensen, J., Sussman, J., et al. (2006,November 4–8, 2006). Leveraging digital backchannels to enhance user experience inelectronically mediated communication. In Proceedings of the ACM Conference on ComputerSupported Cooperative Work (CSCW'96), Banff, Alberta, Canada.


Kwan, M. M., & Balasubramanian, P. (2003). Process-oriented knowledge management: a casestudy. The Journal of the Operational Research Society, 54(2), 204–211.

Landgren, J. (2006). Making Action Visible in Time-Critical Work. In Proceedings of the ACMConference on Human Factors in Computing Systems (CHI 2006), Montréal, Québec, Canada,201–210

Lehner, F. (2004). Organizational Memory. In B. Fahlbruch & J. H. E. Andriessen (Eds.), How tomanage experience sharing (pp. 53–65): Emerald Group Pub Ltd.

Leonard, D., & Sensiper, S. (1998). The role of tacit knowledge in group innovation. CaliforniaManagement Review, 40(3), 112–132.

Lutters, W. G., & Ackerman, M. (2002). Achieving Safety: A Field Study of Boundary Objects inAircraft Technical Support. In Proceedings of the ACM Conference on Computer SupportedCooperative Work (CSCW'02), New Orleans, LA, USA, 266–275.

Lutters, W. G., & Ackerman, M. (2007). Beyond boundary objects: collaborative reuse in aircrafttechnical support. Computer Supported Cooperative Work (CSCW), 16(3), 341–372.

Malcolm, J., Hodkinson, P., & Colley, H. (2003). The interrelationships between informal andformal learning. Journal of Workplace Learning, 15(7/8), 313–318.

Marks, M. A., Sabella, M. J., Burke, C. S., & Zaccaro, S. J. (2002). Theimpact of cross-training onteam effectiveness. The Journal of Applied Psychology, 87(1), 3–13.

McDonald, D. W., & Ackerman, M. (1998). Just Talk to Me: A Field Study of Expertise Location.In Proceedings of the ACM Conference on Computer Supported Cooperative Work (CSCW'98),Seattle, WA, USA, 315–324.

Morris, M., & Horvitz, E. (2007). SearchTogether: An Interface for Collaborative Web Search. InProceedings of the ACM Conference on User Interface Software and Technology (UIST'07)Newport, RI, USA, 3–12.

Nonaka, I., Toyama, R., & Nagata, A. (2000). A firm as a knowledge-creating entity: a newperspective on the theory of the firm. Industrial and Corporate Change, 9(1), 1–20.

O’Hara, K., & Brown, B. (2001, September 16–20). Designing CSCW technologies to support tacitknowledge sharing through conversation initiation. In Proceedings of the Workshop onManaging Tacit Knowledge at the 7th European Conference on Computer SupportedCooperative Work (ECSCW 2001), Bonn, Germany.

Orchard, C. A., Curran, V., & Kabene, S. (2005). Creating a Culture for InterdisciplinaryCollaborative Professional Practice. Medical Education Online, 10(11)

Oser, R. L., Gualtieri, J. W., Cannon-Bowers, J. A., & Salas, E. (1999). Training team problemsolving skills: an event-based approach. Computers in Human Behavior, 15(3–4), 441–462.

Paul, S. A., & Reddy, M. (2010, February 6–10). Understanding together: sensemaking incollaborative information seeking. In Proceedings of the ACM Conference on ComputerSupported Cooperative Work (CSCW'10), Savannah, GA.

Phelps, A. F., & Reddy, M. (2009, May 10–13). The influence of boundary objects on groupcollaboration in construction project teams. In Proceedings of the ACM international conferenceon Supporting group work (GROUP'09), Sanibel Island, Florida, USA.

Pipek, V., & Wulf, V. (2003, September 14–18). Pruning the answer garden: knowledge sharing inmaintenance engineering. In Proceedings of the 8th European Conference on ComputerSupported Cooperative Work (ECSCW 2003), Helsinki, Finland, 1–20.

QSR International. N6 Software Retrieved July 2, 2007, from http://www.qsrinternational.com/products_previous-products_n6.aspx

Reddy, M., & Spence, P. R. (2006, Nov. 11–15, 2006). Finding Answers: Information Needs of aMultidisciplinary Patient Care Team in an Emergency Department. In Proceedings of theAmerican Medical Informatics Association Fall Symposium (AMIA'06), Washington DC, 649–653.


http://www.qsrinternational.com/products_previous-products_n6.aspx

http://www.qsrinternational.com/products_previous-products_n6.aspx

Reddy, M., & Jansen, B. J. (2008). A model for understanding collaborative information behaviorin context: a study of two healthcare teams. Information Processing and Management, 44(1),256–273.

Reddy, M., Pratt, W., Dourish, P., & Shabot, M. (2002). Asking Questions: Information Needs in aSurgical Intensive Care Unit. In Proceedings of the American Medical Informatics AssociationFall Symposium (AMIA'02). San Antonio, TX, 651–655.

Reddy, M., Dourish, P., & Pratt, W. (2006). Temporality in medical work: time also matters.Computer Supported Cooperative Work, 15, 29–53.

Rickards, T. (1999). Brainstorming. In M. A. Runco & S. R. Pritzker (Eds.), Encyclopedia ofcreativity (Vol. 1, pp. 219–227): Academic Press.

Staab, S., Schnurr, H.-P., Studer, R., & Sure, Y. (2001). Knowledge processes and ontologies. IEEEIntelligent Systems, 16, 26–34.

Star, S. L. (1990). The structure of ill-structured solutions: boundary objects and heterogeneousdistributed problem solving Distributed artificial intelligence: vol. 2 (pp. 37–54): MorganKaufmann Publishers Inc.

Strauss, A., & Corbin, J. (1990). Basics of qualitative research: Grounded theory procedures andtechniques. Newbury Park: Sage Publications.

Tamaru, E., Hasuikie, K., & Tozaki, M. (2005, September 18–22). Cellular phone as acollaboration tool that empowers and changes the way of mobile work: Focus on three fields.In Proceedings of the 9th European Conference on Computer-Supported Cooperative Work(ECSCW 2005), Paris, France.

Tang, J. C., Wilcox, E., Cerruti, J. A., Badenes, H., Nusser, S., & Schoudt, J. (2008). Tag-it, Snag-it, or Bag-it: Combining Tags, Threads, and Folders in E-mail. In Proceedings of the ACMConference on Human Factors in Computing Systems (CHI 2008), Florence, Italy, 2179–2194.

Twidale, M., & Nichols, D. M. (1998). Designing interfaces to support collaboration in informationretrieval. Interacting with Computers, 10(2), 177–193.

White, K. F., & Lutters, W. G. (2007). Structuring cross-organizational knowledge sharing. InProceedings of the 2007 International ACM conference on Supporting Group Work(GROUP'07), Sanibel Island, Florida, USA, 187–196


Beyond Expertise Seeking: A Field Study of the Informal Knowledge Practices of Healthcare IT Teams

Documents

Transcript of Beyond Expertise Seeking: A Field Study of the Informal Knowledge Practices of Healthcare IT Teams