Team Cognitive Work Analysis

Abstract

Today’s complex sociotechnical systems involve more than just single operators and often include rich team interactions. In this article, the authors explore cognitive work analysis (CWA), a method typically used for deriving design requirements to support single operators, and rework this methodology into a version that is intended to show requirements required to support successful team collaboration. Team-suitable approaches are presented for the first two steps of CWA, work domain analysis and control task analysis. These approaches are collected from past attempts to model teams with CWA and two new teamwork visualizations, collaboration tables and decision wheels. The applicability of the extended models is demonstrated with a health care example.

Introduction

In complex sociotechnical systems, collaboration is critical; however, the requirements for such collaboration are often not considered in system analysis and design of supporting technology. Designing for collaboration requires a consideration of participation, cooperation, and interaction factors present in a team environment. Nevertheless, teams often do not perform to their potential because of an inadequate awareness of team goals, conflicts between team members, mismatched individual goals, and breakdowns in process and coordination between team members. This article focuses on addressing these problems by creating a theoretical framework to reveal design requirements for technologies that support team collaboration. Much of the existing research literature focuses on evaluating team efficiency, but there are relatively few design approaches for examining team design requirements. This work fills a gap by creating the theoretical basis for transforming knowledge about team efficiency into team-supporting technologies that will improve team performance and collaboration.

Although there are reasonably good measures in the literature for evaluating team efficiency (e.g., Brannick, Salas, & Prince, 1977; Cooke, 2005; Gorman, Cooke, & Winner, 2006; Guzzo, Salas, & Associates, 1995; Heinemann & Zeiss, 2002; Salas, Goodwin, & Burke, 2008; Swezey & Salas, 1992), very few studies have focused on how to design proper technologies to improve team performance. Team situation awareness (SA) is one exception that has shown good results for differentiating the information requirements of individuals and teams (Endsley & Robertson, 2000, is an example). A complementary approach to SA has been cognitive work analysis (CWA; Vicente, 1999). Whereas SA takes a cognitive information-processing approach to deriving requirements, CWA builds constraint-based models of sociotechnical system, seeking to reveal functional behavior. CWA was developed explicitly for the purpose of analyzing complex systems in which unanticipated events could occur. CWA has shown success in modeling the work of single operators (e.g., Bisantz & Mazaeva, 2009; Burns, Enomoto, & Momtahan, 2009; Effken, Brewer, Logue, Gephart, & Verran, 2011; Flach & Amelink, 2003; Groppe, Pagliari, & Harris, 2009; Ho & Burns, 2003; Kilgore, St-Cyr, & Jamieson, 2009; Naikar, 2009), but relatively few attempts have been made to use CWA for modeling team situations (e.g., Ashoori & Burns, 2010; Burns, Torenvliet, Chalmers, & Scott, 2009; Burns & Vicente, 1995; Euerby & Burns, 2012; Naikar, Moylan, & Pearce, 2006; Rasmussen, Pejtersen, & Schmidt, 1990). Certainly there has not been a concerted effort to study how CWA can be used for teams and whether the approach requires modification or extension to team situations. In this work, we study the first two steps of CWA, with a view to how these phases can be adapted to model the work of teams.

Toward a Team CWA

When designing collaborative systems for teamwork environments, it is essential to clearly understand how people work in a team. A deep understanding of teamwork principles, such as shared processes and team strategies, can considerably affect the design requirements and eventually the quality of the final product. Hence, the challenge in designing a teamwork solution is to study teamwork not only at a task level or a strategy level but in a broader spectrum to include physical work domain elements of the teamwork environment as well as the qualifications required for effective teamwork. CWA provides a comprehensive guidance on extracting design constraints in five analyses of (a) work domain elements, (b) individual tasks and goals, (c) individual strategies, (d) social and organizational constraints, and (e) qualifications and competencies of individuals.

The CWA approach clearly allows room for social and team interactions in the fourth level of analysis, the social organizational analysis. However, the original CWA literature (Vicente, 1999) left this particular level largely unspecified. In recent work, as people have tried to develop social organizational analyses for their work domains, a plethora of approaches have emerged. For example, Burns, Bryant, and Chalmers (2005) modeled the soft constraints that were introduced in work domains with strong intentional components; Hajdukiewicz, Vicente, Doyle, Milgram, & Burns (2001) modeled work domain regions to show when individuals needed to collaborate; Naikar et al. (2006) modeled team activity. It became apparent in reviewing this work that a single-phase model for social organizational analysis may not exist or may not be appropriate. Indeed, social organizational interactions have a complexity of their own and result in a broad set of social and functional constraints influencing not only work domain elements and control tasks but also strategies and worker competencies. For this reason, we are proposing that it can be useful to modify the traditional five-level CWA approach to a 2 × 4 approach, whereby there is a parallel set of social or team models. Although this new structure may not be needed in all cases, we suggest that it could be useful in modeling sociotechnical systems with a strong social component. In team CWA (Ashoori, 2011; Ashoori & Burns, 2010), we look past individual work to identify teamwork constraints in four levels: (a) team work domain analysis (team WDA), (2) team control task analysis (team ConTA), (3) team strategy analysis, and (4) team competencies analysis. Figure 1 shows the connections between the original five-level CWA approach and the proposed team CWA.

Figure 1.

Team cognitive work analysis as an extension to cognitive work analysis for teamwork environments.

Team CWA suggests techniques and models that leverage the synergy between social organization analysis and the available guidelines of CWA for individual work analysis. Considering the social aspect of collaboration, team CWA starts at a high-level analysis of teamwork within the work domain and drills down to shared tasks, teamwork strategies to accomplish those tasks, and qualifications that operators should exhibit for effective teamwork.

The following section describes a typical, but complex, collaboration scenario revealing how team CWA can be used in a broad range of teamwork-like scenarios. We will continue to use this sample scenario throughout this article to explore the first two steps of team CWA and to demonstrate the applicability of the extended models in familiar application domains. Using the same scenario for each example makes it easy to follow the various techniques we modified.

Scenario

A subject matter expert, a birthing unit coordinator at the Ottawa Hospital, developed this sample scenario. The scenario exemplifies different levels of interactions among the health care professionals working at the Labour and Delivery Department of this hospital. Following the scenario, we show the overall workflow of the scenario so it can be understood more clearly.

A patient, Mrs. X, has entered the hospital to deliver a baby and develops a fairly straightforward complication, a headache. She is assigned a staff nurse to manage her care. The staff nurse assesses the patient and determines that the patient needs to be assessed by a physician. The nurse talks to the obstetrical resident available about Mrs. X. The obstetrical resident comes to the Mother-Baby Unit (MBU) to assess the patient and decides that the patient could benefit from an epidural blood patch (a simple surgical procedure that injects a sample of the patient’s blood into her epidural space). He contacts the anesthesiologist to double-check the prescription with the anesthesiologist. The anesthesiologist obtains the patient’s consent for the blood patch and calls the care facilitator in the MBU to arrange for transferring the patient to the Birthing Unit (BU) for the blood patch procedure. This care facilitator contacts the care facilitator in the BU to arrange a time for the blood patch. The care facilitator in the BU identifies a primary nurse to do the blood patch for Mrs. X and calls the care facilitator at the MBU to discuss a time for the procedure. The patient is transferred to the BU. The anesthesiologist is present to do the procedure. Afterward, the patient is ready to transfer back to the MBU. The primary nurse reports the situation to the staff nurse before transferring the patient to the other unit.

Figure 2 shows the work-flow diagram of this scenario. Different roles and responsibilities are shown along the vertical axis. The horizontal axis shows the work progress over time.

Figure 2.

Work flow of the sample health care scenario.

The following sections use the aforementioned scenario to explain the first two steps of team CWA: team WDA and team ConTA.

Team WDA

WDA examines the fundamental domain constraints within the scope of what an operator wants to control or have information about. Rasmussen, Pejtersen, and Goodstein (1994) suggest following a hierarchical structure, called abstraction hierarchy (AH), to identify the work domain constraints. The AH is the key tool in performing a WDA and describing the physical nature of the work domain (Burns & Hajdukiewicz, 2004; Vicente, 1999).

From a teamwork perspective, the goal of a WDA is to create a set of models for the team that describe shared values, purposes, and priorities of teamwork. Some of previous attempts to use WDA for establishing collaborative work requirements have examined joint work domain models (Burns, Torenvliet, et al., 2009), trajectories (Rasmussen et al., 1990; Burns & Vicente, 1995), responsibility maps (Hajdukiewicz et al., 2001), and intentional WDA incorporating values or soft constraints (Burns et al., 2005). Although these approaches begin to show how work domain spaces can be used by teams, they can fall short in identifying which WDA elements are used by which team members. As well, they can suffer from a scaling issue, being better suited to environments with two or three clear team roles. In team WDA, we propose that these methods continue to be used but suggest the explicit mapping of work domain collaboration be added when larger teams are being modeled or more detail is needed.

The difference between the team WDA methods and traditional WDA is that the team methods seek to show various aspects of teamwork or team requirements explicitly. A regular WDA would still be conducted as the base for these models; then, depending on the nature of the team situation to be analyzed, the base WDA is reexamined for team aspects. Joint work domain models are appropriate when two or more team members share parts but not the entire same work domain. Responsibility maps show how team members work on a single work domain together. Social and physical constraint models help to identify the social constraints that affect decision making. Trajectories show how various team members move through time through a work domain. Collaboration tables identify each work domain element separately, showing in detail the various team members influenced by that element. Although this information can be derived from joint work domain models or responsibility maps, with larger teams and more complex interactions, the table format can be clearer. Since the other methods have been described in other publications, we focus in the next sections on exploring the collaboration tables using the health care scenario.

Collaboration Tables (CTs)

A typical WDA examines the fundamental behavior-shaping constraints, such as purposes, values, priorities, processes, and resources. Figure 3 shows the basic work domain model for the health care scenario. Figure 4 shows the responsibility map for the sample scenario. The overlap between the decision spaces of each team member shows how they work on a single work domain together. For larger teams with more complex interactions, it gets complicated to graphically illustrate the overlaps between the decision spaces. Responsibility maps are appropriate for two or three team members but do not scale up well for large teams.

Figure 3.

Basic work domain model of the Labour and Delivery Department.

Figure 4.

Responsibility maps for the Labour and Delivery Department.

The goal of WDA from a teamwork perspective is to identify which work domain elements are shared, and by whom, and which elements influence only individuals. Although this information can be derived from joint work domain models or responsibility maps, with larger teams and more complex interactions, using a table format can be clearer. CTs provide a table format for examining the overlaps between the decision spaces of team members.

A typical CT as an extension to the AH examines the work domain at five levels: (a) functional purpose, (b) abstract function, (c) generalized function, (d) physical function, and (e) physical form. At the functional purpose level, a CT indicates roles and responsibilities that contribute to a work domain purpose. For example, all the health care professionals in Table 1 collaborate to provide pain management, but only the care facilitators perform administrative duties, such as operating telephones, keeping track of equipment, and other clerical functions (Table 1).

Table 1:

Shared Purposes at the Functional Purpose Level

Functional Purposes	Staff Nurse	Obstetrical Resident	Anesthesiologist	BU Care Facilitator	MBU Care Facilitator	Primary “Nurse
Pain management	X	X	X			X
Administration				X	X
Maintaining patient health	X	X	X			X

Note. BU = Birthing Unit; MBU = Mother-Baby Unit.

At the abstract function level, a CT identifies shared or not-shared values, principles, and priorities. In the sample scenario, Table 2 shows three shared values of (a) timely treatment, (b) appropriate treatment, and (c) effective administration. Whereas the health care professionals contribute to provide an appropriate, timely treatment for the patient, the care facilitators smooth the caregiving process by facilitating administration.

Table 2:

Priorities and Values at the Abstract Function Level

Abstract Functions	Staff Nurse	Obstetrical Resident	Anesthesiologist	BU Care Facilitator	MBU Care Facilitator	Primary Nurse
Timely treatment	X	X	X			X
Appropriate treatment	X	X	X			X
Effective administration				X	X

Note. BU = Birthing Unit; MBU = Mother-Baby Unit.

At the generalized function level, a CT describes the overlap between the processes that each team member is responsible for. When designing a new system to facilitate a collaborative process, it is important to clearly examine to what extent a team member contributes to complete that process. For example, as shown in Table 3, all team members contribute to patient assessment, consulting, and patient teaching, but only the primary nurse and the anesthesiologist are responsible for the blood patch procedure.

Table 3:

Shared Processes at the Generalized Function Level

Generalized Functions	Staff Nurse	Obstetrical Resident	Anesthesiologist	BU Care Facilitator	MBU Care Facilitator	Primary Nurse
Patient assessment	X	X	X			X
Prescribing		X
Consulting	X	X	X			X
Patient teaching	X	X	X			X
Blood patch procedure			X			X
Administrative services				X	X

Note. BU = Birthing Unit; MBU = Mother-Baby Unit.

When an individual process, such as prescribing, is not shared in a team, designing an information system to automate that process may facilitate the work of the individual responsible for that process but not necessarily team interactions. A thorough understanding of shared processes in a team may lead to a better understanding of boundary objects and the way people exchange information in a team. A boundary object is a concept from activity theory to show how various artifacts pass between different activity systems (Bodker, 1991; Star & Greisemer, 1989). When two parties collaborate, the boundary object is either a shared physical or conceptual object. Boundary objects often present unique design challenges in that they must be designed to be compatible in different activity systems and, in this case, for different team members or for different teams entirely. The corresponding physical function level CT in Table 4 indicates the boundary objects for the given scenario. When the staff nurse reports patient status to the obstetrical resident, the boundary object shared between them is the patient record. As another example, the blood patch equipment is a boundary object that the primary nurse and the anesthesiologist share during the blood patch procedure. An information system designed to facilitate collaboration between the primary nurse and the anesthesiologist should then support information access to the patient record and the blood patch equipment but not necessarily to the ultrasound image that is used solely by the anesthesiologist.

Table 4:

Boundary Objects at the Physical Function-Form Level

Physical Functions	Staff Nurse	Obstetrical Resident	Anesthesiologist	BU Care Facilitator	MBU Care Facilitator	Primary Nurse
Patient	X	X	X	X	X	X
Blood patch equipment			X			X
Ultrasound image			X
Baby	X	X	X	X	X	X

Note. BU = Birthing Unit; MBU = Mother-Baby Unit.

Value From Team WDA

Several key requirements are identified by team WDA:

1. Shared or not-shared purposes, values, priorities, or principles: The CT can provide a representation of shared work domain purpose and values. When higher-level aspects of the work domain are shared, one can expect various team members to be collaborative and likely to work well together. By identifying areas in which higher-level elements are not shared, one may be able to identify where conflicts or counterproductive actions could occur.

2. Shared or not-shared processes: The CT can provide a representation of shared work domain processes. Shared processes require tight coordination between team members. Processes that are not shared can often be tailored to individuals.

3. Boundary objects: Boundary objects need to be carefully designed to be compatible with the needs and purposes of multiple operators. Boundary object is a critical, but understudied, theoretical construct in computer-supported cooperative work (CSCW; Lutters & Ackerman, 2002). At the work domain level, the collaboration tables can be used to identify boundary objects in a cooperative work.

4. Support for team SA requirements: CTs may support team SA requirements with identification of which work domain elements are shared and by whom. Team SA requirements indicate the degree to which the team members know which information needs to be shared. The CT can be used to identify the team SA requirements at different levels of purposes, values, processes, and physical work domain resources.

5. Potential for designing new teams or identifying poor team structures: Organizing along shared purpose and values, or shared process and objects, allows more effective team structures to be built.

Team ConTA

The collaborative nature of control tasks in a team considerably affects the control tasks for individuals and the role each individual plays in a team. Vicente (1999) describes ConTA as an analysis of what needs to be done, independently of how or by whom. However, we argue that such an approach can be improved by adding a view of how control tasks are currently shared between and within teams. Previous attempts have been made to extend ConTA to address collaborative work requirements. For instance, Rasmussen et al. (1994) introduce the decision ladder as a tool for modeling control task requirements across multiple parties, using chained ladders. Naikar, Pearce, Drumm, and Sanderson (2003) suggest a new formative representation for ConTA, called the contextual activity template (CAT), to represent activities that are characterized by both work situations and work functions. They argue that work functions for an individual can be different for various situations, which can lead to different interaction patterns in various collaboration situations.

The CAT is a helpful model when work functions change across different situations (e.g., a typical caregiving process and an emergency situation). Variations of the CAT include the color-coded CAT of Jenkins, Stanton, Salmon, Walker, and Young (2008) and the modified CAT for teams (Ashoori & Burns, 2011). Whereas chained ladders are a good representation to show how different parties interact on a single control task, the CAT is a good representation to show how individuals are involved in multiple control tasks. In this work, we propose a third visualization, the decision wheel. The decision wheel, like the CT, is aimed at showing interactions in larger teams. The decision wheel can also be used to explore synchronous and asynchronous collaboration. In the following section, we will build team ConTA for the same example we used in the WDA section.

In our health care scenario, the sequence of control tasks is fairly straightforward. There are three main situations in the scenario: (a) patient assessment, when the health care team assesses the patient to figure out the reason for the headache and decide on the proper pain killers; (b) arranging for a blood patch, when the team has decided on that treatment and interteam interactions are required to arrange for the procedure; and (c) the blood patch procedure, when the primary nurse from the BU collaborates with the anesthesiologist from the MBU to complete the procedure. For simplification, the emergency situation is not considered in the health care scenario.

Team CAT

Figure 5 shows the modified CAT, representing interaction in the health care scenario. Work situations are shown along the horizontal axis, and responsibilities are shown along the vertical axis. The ovals indicate the teamwork functions, and the boxes around each oval indicate all work situations in which a work function can occur. The small solid circles attached to the teamwork functions indicate people collaborating on that function. This adaption clearly identifies what needs to be done in various situations and examines the interaction patterns over time.

Figure 5.

The modified contextual activity template for the Labour and Delivery Department.

Jenkins et al. (2008) suggest a color-coded CAT to show which actors can perform what functions and in which situations. Figure 6 shows a color-coded CAT representation of the health care scenario. The work situations are shown along the horizontal axis, and work functions are shown along the vertical axis. As in Figure 5, the circles indicate the teamwork functions and the boxes around each circle indicate all of the work situations in which a work function can occur. In this approach, each actor is represented by a specific color, which becomes very complicated for larger groups.

Figure 6.

The color-coded contextual activity template for the Labour and Delivery Department.

Chained Ladders

Rasmussen et al. (1994) discuss a chain of decision ladders whereby links between ladders demonstrate the collaboration points. Figure 7 shows a chain of decision ladders for the health care scenario. Although this approach can provide a model to represent the shared work flow in a team, it can suffer from a scaling issue, being better suited to environments with two or three clear team roles. The complexity of this approach can clearly be seen in the figure. Not only does it get complicated, but also the chain of ladders does not address team structures and interteam interactions.

Figure 7.

Chained ladders for the Labour and Delivery Department.

Decision Wheels

To respond to the scaling issue, Ashoori and Burns (2010) suggest extending decision ladders to decision wheels. The decision wheel as an extension to the decision ladders provides a unique model to distribute control tasks across team members, with each team member composing a portion of the wheel. Each wheel represents a team, which makes it possible to study both intrateam and interteam interactions. Each slice of the wheel represents the decision ladder of a team member. Interactions between two actors connect their decision ladders together. Figure 8 shows how to map a standard decision ladder to a slice of a wheel.

Figure 8.

How to map a decision ladder to a slice of the decision wheel.

Figure 9 shows the decision wheel for the given scenario. Each wheel represents one of the teams in the Labour and Delivery Department. Connections between the wheels represent interteam interactions. In the figure, the MBU decision wheel consists of five slices, representing the patient, staff nurse, obstetrical resident, anesthesiologist, and care facilitator. The BU team requires two slices, one for the primary nurse and one for the care facilitator. The connections between the slices of a team represent intrateam interactions, and the connections between the wheels represent interteam interactions. Further characteristics of each interaction are described in a decision wheel table, shown in Table 5. Each row of the table represents a single collaborative link between operators. Links are numbered and correspond to the numbers in Figure 9. For each collaboration link, type of interaction (synchronous-asynchronous), scope of interaction, corresponding control task, and boundary objects are listed in the table. These factors were chosen since they could be relevant to the design and development of a support tool for teams.

Figure 9.

The decision wheel for the Labour and Delivery Department.

Table 5:

The Decision Wheel Table for the Given Scenario

				CSCW Criteria (Reinhard, Schweitzer, Volksen & Weber, 1994)
Link	Team Members Involved	Task	Boundary Objects	Synchronicity	Distribution
1	Patient	Patient teaching	Patient record	Synchronous	MBU
	Staff nurse	Patient assessment	Baby record
2	Patient	Patient assessment	Patient record	Asynchronous	MBU
	Staff nurse		Baby record
3	Staff nurse	Consulting	Patient record	Synchronous	MBU
	Obstetrical resident		Baby record
4	Patient	Patient teaching	Patient record	Asynchronous	MBU
	Obstetrical resident	Patient assessment	Baby record
5	Obstetrical resident	Consulting	Patient record	Synchronous	MBU
	Anesthesiologist		Baby record
6	Patient	Patient teaching	Patient record	Asynchronous	MBU
	Anesthesiologist	Patient assessment	Baby record
7	Anesthesiologist	Administrative arrangements for the blood patch	Patient record	Synchronous	MBU
	MBU care facilitator		Baby record
8	MBU care facilitator	Administrative arrangements for the blood patch	Patient record	Synchronous	MBU-BU
	BU care facilitator		Baby record
9	BU care facilitator	Assigning a nurse	Patient record	Asynchronous	BU
	Primary nurse		Baby record
10	BU care facilitator	Administrative arrangements for the blood patch	Patient record	Synchronous	MBU-BU
	MBU care facilitator		Baby record
11	MBU care facilitator	Administrative arrangements for the blood patch	Patient record	Asynchronous	MBU
	Anesthesiologist		Baby record
12	Anesthesiologist	Consulting	Patient record	Synchronous	MBU-BU
	Primary nurse	Blood patch procedure	Baby record
			BP equipment
13	Primary nurse	Consulting	Patient record	Asynchronous	MBU-BU
	Staff nurse		Baby record

Note. CSCW = computer-supported cooperative work (Lutters & Ackerman, 2002); BU = Birthing Unit; MBU = Mother-Baby Unit.

As shown in Figure 9, the patient’s headache is the signal to initiate the work flow. She calls the assigned staff nurse to discuss her headache (Link 1). Afterward, the staff nurse visits the patient (Link 2) and calls the obstetrical resident to discuss the severity of the patient’s headache (Link 3). The obstetrical resident comes to the ward to visit the patient (Link 4) and decides that the patient may benefit from a blood patch. The obstetrical resident contacts the anesthesiologists to verify the procedure (Link 5). The anesthesiologist visits the patient to assess whether the patient would benefit from an epidural injection (Link 6). After verifying the blood patch, the anesthesiologist contacts the care facilitator in the MBU to arrange for the procedure (Link 7). The care facilitator at each unit is responsible for arranging interteam procedures (Link 8). The care facilitator at the BU assigns a primary nurse for the procedure (Link 9) and updates the care facilitator at the MBU with the time for the procedure (Link 10). The care facilitator at the MBU confirms the arrangement with the anesthesiologist (Link 11). The patient is transferred to the BU, where both the anesthesiologist and the primary nurse are present to complete the procedure (Link 12). Afterward, the patient is ready to transfer back to the MBU. The primary nurse reports the progress of the procedure to the staff nurse before the patient is transferred back to the MBU (Link 13).

The decision wheel along with the corresponding decision wheel table can be used to extract the team’s needs and to gain insight into the behavior of one team member in relation to another. A serendipitous feature of this structure is that high-level cognitive tasks become focused in the center “bulls-eye” of the wheel. This feature can help to identify team members involved in decision-making activities. Similarly, observations and actions tend to filter to the outside of the wheel, making it easier to identify inter- and intrateam interactions.

The decision wheel could also support an extraction of team SA devices by examining the distribution and synchronicity of interactions. Surely, knowing when people are collocated, collaborating synchronously or asynchronously, would be important in building a design that can support team SA.

Value From Team ConTA

Several key requirements are identified by team ConTA:

1. Type of interaction (synchronous vs. asynchronous): With respect to interaction requirements, CSCW taxonomy recommends an examination of synchronicity, communication channels, and a system distribution for each interaction (Reinhard, Schweitzer, Volksen, & Weber, 1994). When extracting design requirements for communication devices, it is essential to examine different types of team interactions and the way individuals communicate in a team.

2. Boundary objects: As discussed in the Team WDA section, boundary objects are a critical theoretical construct in CSCW (Lutters & Ackerman, 2002) and need to be carefully designed to be compatible with the needs and purposes of different team members (Star & Griesemer, 1989).

3. Intrateam interactions: An understanding of intrateam interaction at various cognitive states and cognitive processes, shortcuts, and shunts allows examining the cognitive aspect of collaboration and designing better-suited technologies for teams.

4. Interactions between teams: An identification of the collaboration points between multiple teams and the boundary objects they share within each interaction allows better-suited technologies to be designed for connecting multiple units across an organization.

5. Potential for designing new teams or identifying poor team structures: Organizing along interteam interactions allows more effective team structures to be built.

6. Support for team SA: The decision wheel can be used to support the team SA devices through an examination of the distribution and synchronicity of interactions. Knowing when people are collocated, collaborating synchronously or asynchronously, would be important in building a design that can support team SA. The decision wheels can also be used to support team SA mechanisms in that they show when teams must collaborate on knowledge-based tasks together (the center of the wheel), where shared mental models might be most needed.

7. The decision wheel, like the CT, is aimed at showing interactions in larger teams. The decision wheel is a new adaptation of the decision ladder for looking at larger team interactions. Although this method does allow larger teams to be analyzed, it still suffers from scaling issues such that extremely large teams could not be studied with this model.

8. The modified CAT for teams may be used to extract the design requirements for different modes of operations required for an effective collaborative system to adapt to the changing demands of a dynamic environment. Whereas the modified CAT for teams distributes multiple activities across multiple operators, the chained ladders and the decision wheels distribute one activity across multiple operators.

Discussion

Although CWA has shown success in modeling the work of single operators, very few studies have focused on using CWA for improving team performance. We propose that it can be useful to modify the traditional five-level CWA approach to a 2 × 4 approach, whereby there is a parallel set of social or team models. The value gained from the first two steps of this approach, team WDA and team ConTA, were discussed in this article. Further work will involve examining team strategies and competencies required for effective collaboration (Ashoori & Burns, 2012).

Discussion of the Shared Elements

Although the previous attempts to use WDA for teamwork environments show how the work domain space can be used by teams, they can fall short in identifying which work domain elements are used by which team members. Team WDA can identify shared or not-shared purposes, values, priorities, or principles. By identifying areas in which higher-level elements are not shared, one may be able to identify when conflicts or counterproductive actions could occur. Team WDA also examines shared processes and boundary objects. Whereas shared processes require tight coordination between team members, processes that are not shared can be tailored to individuals.

With team ConTA, one can examine collaboration at a task level and can identify shared work flows, intrateam interactions, and boundary objects. By understanding intrateam interactions at various cognitive states and cognitive processes in team ConTA, one may be able to examine the cognitive aspect of collaboration and design better-suited technologies for teams. Team ConTA also identifies the boundary objects shared within each interaction. Boundary objects need to be carefully designed to be compatible with the needs and purposes of multiple operators.

Potential for Designing New Teams

Team CWA has potential for designing new teams or identifying poor team structures. Naikar, Drumm, Pearce, and Sanderson (2000) suggest the CAT to explore the feasibility of alternative team designs. They recommend summarizing patterns of activities to estimate spare capacity for further work responsibilities. Figure 10 shows three main groups of team activities extracted from the health care scenario at the control-task level. To minimize interteam connections, one can assign each activity group to a team.

Figure 10.

Representation of activity for the sample scenario.

The challenge in designing a new team is to study teamwork not only at the task level (Naikar et al., 2000) but in a broader spectrum to include physical work domain elements as well as values and priorities of a team. Organizing along shared purposes and values, or shared processes and objects, may result in building more effective team structures. In the health care scenario, three groups of activities can be extracted from the CAT (Figure 11). Although the blood patch procedure can be seen as a different group, it shares the purpose and values with maintaining patient health. The blood patch team can be a good candidate to be part of the health care team at the MBU. Redesigning the MBU team to include the primary nurse can reduce a considerable number of interteam arrangements and can result in a more effective team structure.

Figure 11.

Collaboration maps for the sample scenario.

Figure 12 shows the decision wheel for the new health care team. In comparison with the decision wheels in Figure 9, this new design saves unnecessary information exchange between the units and can result in a less complex caregiving process.

Figure 12.

The decision wheel for the new Mother-Baby Unit team.

Designing for Large Teams

The previous attempts to use WDA and ConTA for teamwork environments can suffer from a scaling issue, being better suited to environments with two or three clear team roles. In team CWA, we propose that these methods continue to be used but suggest the explicit mapping of work domain collaboration be added when larger teams are being modeled or more detail is needed.

To sum up, team CWA can make a methodological contribution by extending the CWA framework to support teamwork and should make a practical contribution by demonstrating the usefulness of the framework in a real collaboration context. These developments should enable human factors practitioners to understand the cognitive work of teams better and to design better systems to support teamwork and collaboration.