Abstract
In 1994, Jonathan Grudin wrote his famous paper Eight Challenges for Groupware Developers; The question is whether these challenges still persist, or have we moved on here 30 years later? We revisit the challenges empirically through ethnographic observations in two companies examining their work practices, organizational structure, and cooperative setups concerning their use of groupware technologies. Today, groupware is seamlessly integrated into organizations, considered essential infrastructure that becomes part of the daily work routine. Contextualizing the original challenges proposed by Grudin, we categorize them into cooperative challenges, social challenges, and organizational challenges, and refine their phrasings to reflect present and future considerations faced by developers of groupware technologies. While the main arguments of the social and organizational challenges remain consistent, we rephrase the cooperative challenges as emergent exception handling and exaggerated accessibility to reflect the emerging characteristics associated with the ubiquity and seamless integration of groupware.
1 Introduction
In 1994, Jonathan Grudin proposed eight challenges for developers of groupware technologies [1]. Today, three decades later, groupware technology has gone through a huge development – from the 1990s when we discussed email and electronic calendars as new types of groupware technologies that potentially could have a dramatic impact on organizational practices, to 2020 where video-conferencing technologies and the ability to work from home using Internet and groupware technology to get us through the pandemic. The technologies designed to support cooperative engagements within and across organizations were adopted at a rapid pace during the COVID-19 pandemic where worldwide lockdowns forced millions of people to work from home. When the regulations were lifted, people returned to their offices, however, this transition has not been without difficulties [2–4]. The post-pandemic has not been a simple return to the “pre-pandemic status quo”, instead, the new situation has initiated discussions and negotiations within organizations about “the nature of the workplace”, and what is desirable and efficient for different organizational members [5–10]. The changing perspectives on work and persistent demands from organizational members for flexible work conditions with remote opportunities [11–14] have created a work environment where people are partially distributed, and working from different locations has become the norm rather than the exception. The term hybrid work has become popularized to describe the work model where some employees work from home, while others are physically located at the office [15, 16]. Hybrid work introduces new challenges for cooperative work [15–18] also impacting the design challenges for cooperative technologies [19–21]. Therefore, it is relevant to consider, which challenges are prominent for developing CSCW systems for work environments today – as well as for the future [8, 22], [23], [24]. With such dramatic changes, the fundamental question remains as to whether the eight challenges proposed by Grudin in 1994 still stand, or whether we need to re-consider these challenges three decades later.
In this paper, we ask the research question: What are the challenges for developers of groupware technologies in 2024? To answer the research question, we revisit the challenges identified by Grudin three decades ago [1] and interrogate these challenges in the empirical perspectives from ethnographic studies of hybrid office work today. We report from two empirical studies conducted in 2023 at two different organizations both struggling with establishing a modern workplace allowing the employees to occasionally work remotely from home, while still encouraging physical presence at the office.
We find that groupware today is ubiquitously integrated into organizations and is regarded as part of the fundamental infrastructure in organizations, often fading into the background as taken-for-granted technology. The use of groupware is consequently viewed as an everyday aspect of work, influencing the challenges associated with developing new groupware systems. Based on our analysis, we categorize the three-decade-old challenges [1] into three main categories: cooperative challenges (no. 4, 5), social challenges (no. 1, 2, 3), and organizational challenges (no. 6, 7, 8). This classification aims to capture the evolving considerations and refine the phrasings to reflect the present and future challenges faced by groupware developers. While the main titles and primary arguments of the social and organizational challenges remain unchanged (yet with added complexities), we rephrase the cooperative challenges to reflect the emerging considerations of groupware being seamlessly integrated into work practices. We find that enabling the design of groupware technologies as “open-ended” and “immediate availability” is critical, yet these characteristics also introduce new complexities. For example, when organizational cooperative practices are produced through continuously malleable configurations of locations, people, and groupware – the additional challenge for groupware design is the requirements to support continuous reconfiguration (sometimes on a day-to-day basis) while allowing people to create sociomaterial bounding of technologies in practice.
The paper is structured as follows: First, we contextualize the eight challenges for groupware developers in current CSCW research. Then we introduce our methods, and the two empirical cases, before we dive into interrogating each challenge, with empirical observations from our empirical data. This work includes suggestions for re-focusing some of the challenges. Finally, we discuss how the foundation for groupware design has changed since the early 1990s and speculate on the future challenges that contemporary groupware developers face when designing technologies for cooperative environments for the next three decades.
2 Challenges for groupware developers
In the early 1990s, Computer Supported Cooperative Work (CSCW) emerged as a coherent research field in light of existing insufficient approaches to the design of technologies [25–27]. The CSCW focus is on supporting people via the design of computer tools [25] in cooperative arrangements [26] where people are mutually dependent in work [28]. CSCW systems are interacted with by individuals and therefore possess the same interface challenges as individual user applications, however, new challenges arise when technologies should support cooperative work [1]. In 1994, Jonathan Grudin’s publication summarized and highlighted the challenges identified by multiple researchers [1], and the paper has been highly cited (more than 2000 citations and in 2023 alone the paper has been cited 24 times[1]), and in 2014, Grudin received the CSCW long-term impact award celebrating his work.
The 1994 paper does not introduce empirical data, instead, the paper is written as a reflective essay, where the author considers suggestions for the nature of specific challenges that arise with the introduction of groupware technology into organizational practice. It is evident that, at the time of writing the paper, the actual empirical insights and experiences from empirical examples were less, as only a few had the privilege to access and research organizational practices utilizing groupware systems. Two examples of the few researchers who successfully were able to gain access to and study groupware in organizations was Wanda Orlikowski, who with her famous paper ‘Learning from Notes’ from 1992 [29] studied how groupware technology was implemented and potentially failed within organizational practices – a paper which also was celebrated with the Lifetime Impact award in CSCW in 2015; and Paul Dourish and Victoria Bellotti [30] who studied the use of video-conferencing tools within Xerox Parc in the early 1990s (again winning the long-term impact award in CSCW, this time in 2016). Groupware technology was a key area of important research in thinking about how organizational practices were impacted by technologies designed to support the work of groups.
Groupware technology is fundamental to the very definition of CSCW research, as Irene Greif (cited in Ref. [28]) defines CSCW as “… an identifiable research field focused on the role of the computer in group work” [28, p. 9]. While the focus on ‘groups’ has been debated, researchers generally agree that the fundamental concern for CSCW research concerns situations where at least two or more actors are mutually dependent upon each other while being involved in a common field of work using computer systems [31–35]. This means that groupware technology is not the sole interest of CSCW technologies, but instead, a specific type of CSCW application where the aim is to design technologies that support groups in their joined engagement [36–39]. Grudin made the distinction between individual usages of technology (single-user technologies), large main frame systems (organizational software systems), and then groupware [1]. Cooperative work entails situations where at least two people are engaged in a common field of work in such a way that they experience interdependence [40–43] – then technology support depends upon the nature of articulation work required for handling this extra work. In Lee and Paine’s work on coordinative action, they unpack the dimensions of the cooperative engagements in terms of the number of participants, different communities, nascence, etc., suggesting these dimensions as a scale to determine the boundaries between the group as the smaller unite of cooperative action and the infrastructure of more than 1000 people being part of a larger coordinative action [34]. Thus, the discussions on cooperative technologies are much larger than simply groupware – however, our interest in this paper remains on groupware and the challenges that developers of these technologies face today. But first, let us remind ourselves about the nature of the original eight challenges for groupware developers proposed by Grudin [1].
2.1 Disparity in work and benefit
This challenge points to that groupware applications do not apply the same benefit for all the people involved in using the technology. In 1994, electronic shared calendars were introduced into the offices as a new groupware technology. These digital calendars were accessed through large desktop computers, and organizational members did not have a mobile phone in their pocket with access to their calendars. Thus, for mobility in office work, members would carry paper-based calendars reminding themselves of appointments and meetings. The electronic calendar requires people to add their appointments and meetings to the shared digital calendar, for the benefit of other organizational members, such as the actors whose job it is to identify availability for planning meetings. However, allowing others access to your calendar required extra work from organizational members in updating both their electronic as well as their paper-based calendars. Further, allowing access also risks reducing the autonomy of the individual by allowing others to take control of their time and schedule. Thus, the transparency of the shared calendar introduces extra work of the individual while reducing the autonomy of the individual. The question then arises as to who benefits from the shared electronic calendars. The benefit of electronic calendars is for the organizational members involved in planning meetings. The shared electronic calendars allow organizational members to compare and identify space for shared meetings, which otherwise would be the tedious work of calling around and checking people’s availability. However, the work of planning meetings would often be the work of secretaries while the extra work of calendar updating between electronic calendars and paper-based calendars would be done by other organizational members (e.g., salespeople) who did not plan meetings initially. In the last decades, multiple studies have demonstrated different technologies that add work on individual groups of organizational members for the benefit of others [44, 45], like the work of healthcare professionals recording additional data (or checking boxes) while interacting with patients for the benefit of hospital management [46]. Thus, the challenge for groupware technology is the challenge of creating technologies that consider and accommodate the disparity of work and benefit between different individual organizational members. Mitigating the challenge is about ensuring that the additional work required for the groupware technology to function is not experienced as unbeneficial for the people doing this work.
2.2 Critical mass and Prisoner’s dilemma problems
This challenge points to that for groupware technology to work, enough people must use the systems for the shared functions to work properly. Fundamentally, if an organization has implemented a groupware system allowing members to for example share documents (such as shared folder systems) or communicate (e.g., email and Slack) the groupware system will only be useful if enough organizational members use this system. If only a few people use the shared calendar system, the person planning meetings still needs to request additional information about individuals to identify appropriate times and places for planned meetings. Similarly, if only a few organizational members use a shared file system, people would not be able to identify relevant files, since several files would be outside the shared system requiring organizational members to request and share files in other ways (e.g., by email attachments). Thus, for organizations to benefit from a groupware system, enough people need to use it – however, getting people to use a newly implemented system (before the benefits arrive) is a challenge. Groupware technologies are not instantly producing cooperative efforts by simply being installed on the computers [29], instead, it takes time for groupware systems to gain a critical mass of users. Thus, the challenge for groupware developers is to design a groupware system that considers the critical mass problem within the design to make it a successful tool, otherwise, the users will not experience the advantages of using the system.
2.3 Disruption of social processes
This challenge points to that the introduction of groupware technology can interfere with social dynamics and implicit information such as social taboos and political structures. Organizations have embedded hierarchies, and while these hierarchical structures might take different forms and be structured quite differently dependent upon the structures shaping the social dynamics of the organization [47–49]. For example, walking over to a colleague asking for assistance with a specific task would be viewed as appropriate in many organizations, while taking the elevator to the top floor and knocking on the door of the CEO requesting to be involved in creating the strategic plan of the company would not be appropriate in many organizations. The social dynamics are thus shaped by the organizational structures of hierarchy, politics, and implicit organizational practices. When groupware technology is implemented into organizations, these technologies risk disrupting the social processes within the organization [50], since organizational members might have different types of access and navigation [51]. For example, while only a few would take the elevator and knock on the door of the CEO, the bar to send an email to the CEO might be lower. Or as we have seen in recent years with social media, citizens have direct access to politicians or other public figures by commenting, liking, and sharing posts which they otherwise would not have been able to do. Groupware technology impacts social dynamics and interaction, and not always for the better, as we have seen with the challenge of misinformation about disasters, health, and politics [52, 53]. Thus, the challenge for groupware developers is to design technologies that consider the risk of disrupting social processes appreciating productive interruptions while reducing problematic disruptions.
2.4 Exception handling
This challenge points to the fact that cooperative work never just follows the plan; instead, disruptions occur and are requiring exception handling. Groupware technology at its core is about reducing the efforts of articulation work for a cooperative engagement with the purpose of allowing organizational members to focus on other activities, finish tasks faster and more efficiently, or simply spend time on the content of the task rather than the articulation work [54]. This intention for groupware has caused developers of groupware technologies to focus on efficiency and streamlining the work-embedded coordination strategies [55, 56]. Workflow systems are a specific type of groupware technology designed to make coordination easier by allowing users to organize their individual, yet interdependent tasks, in tandem [57–59]. However, a crucial problem with these workflow systems is that cooperative work very seldom follows the predetermined path and workflow [60–64]. Instead, organizational members do what is required to make the work function, and often this includes exception handling to resolve breakdowns [65, 66]. For example, while bed management coordination in hospitals supposedly follows a certain pattern, the actual work involved in bed management might differ greatly from the pre-scribed processes [67]. Exception handling is not something that will be mitigated by technology. Instead, the design of groupware technology needs to support exception handling required for the work – and often we do not know which type of exception handling to expect. Thus, the challenge for developers of groupware is to create technologies that are open-ended and flexible in use allowing organizational members to accommodate and enact required exception handling.
2.5 Unobtrusive accessibility
This challenge points back to the balance between when organizational members are engaged in cooperative work, and when they are engaged in individual work. In all cooperative setups, people do not always and only collaborate. Instead, there are times when organizational members simply work individually. For example, co-authoring an academic paper does not mean that authors write all sentences together, but often co-authoring includes individuals writing drafts or revising draft text to later discuss between all authors. Cooperative work has dependencies, but there will be times when cooperative actors engage in individual tasks. Unobtrusive accessibility points to the fact that when designing cooperative technologies, it is important to ensure that the groupware allows for individual work and does not always have the cooperative engagement in focus. Thus, groupware technologies should be able to stay in the “peripheral background”, while individuals work alone, and then be able to zoom into focus when actors need to cooperate. Groupware should be accessible in an unobtrusive manner, blending into the background and only appear when needed. Fundamentally the challenge of unobtrusive accessibility is highly related to awareness in cooperative engagement. Awareness as a feature of cooperative work entails making activities visibly available for others can monitor these actions and act accordingly [68]. Awareness has been explored as a critical characteristic of cooperative work [69] as well as a design requirement for groupware technology [70] and continues to be a core area of research in CSCW [71]. While the conceptual understanding of ‘unobtrusive accessibility’ can be identified to consider concerns for the delivery of awareness data (such as how actors can unobtrusively access the cooperative engagement considering the infrequent use of groupware) the conceptual understanding of awareness has developed tremendously since 1994 [72]. Thus, the challenge for developers of groupware technology in 1994 centers around the assumption that teams are often organized to minimize social interdependencies, causing groupware features to be used less frequently than features for individual work. This infrequent use is a challenge when designing new groupware technologies, thus Grudin suggests that different design strategies should prioritize adding cooperative features into existing systems – turning these into groupware technologies [1].
2.6 Difficulty of evaluation
This challenge concerns the user-testing and evaluation of groupware technology features and design decisions. The methodologies for usability testing or user experience evaluation are appropriate when evaluating single-user systems. Differently, these methodologies are not appropriate nor useful to evaluate the quality of groupware systems [73, 74]. The problem is that the evaluation of the groupware is closely connected to the context of use, and thus evaluating groupware includes considerations for hierarchy, motivations, and social engagement which single-user methodologies do not allow us to capture. Usability testing methods are not equipped to consider social interaction. There are many empirical examples from CSCW research where cooperative technologies have been implemented into an organizational practice only to reveal fundamental design problems that only became pertinent after the groupware system had been implemented in real-life situations [75–77]. In some cases, expensive IT systems were taken out of use due to these problems [78], while in other cases organizations were forced to live with problematic systems and identify workarounds to survive [79, 80]. Concretely, usability evaluation does not reliably capture the complexities of cooperative engagements making it more challenging to evaluate groupware systems than single-user applications. Thus, the challenge for groupware developers is that groupware systems are difficult to evaluate as they are context-dependent [81–84] and affected by other actors involved in the work, thus developers might not know central design problems before the system has been fully implemented.
2.7 Failure of intuition
This challenge is directed at the decision-makers and managers who are responsible for identifying and requiring groupware technology to be implemented in their organizations. In 1994, when email was still a novelty in organizations, managers had little experience in knowing which groupware technologies would be relevant to acquire and implement supporting the organizational practices. Mostly, this was due to the lack of experience organizations had concerning groupware, making it impossible for them to rely upon their intuition when making decisions on IT systems. The famous empirical case ‘Learning from Notes’ is an excellent example of this challenge. Here Orlikowski documents how top management invested in acquiring Lotus Notes as a cooperative technology for the whole organization with the aim of creating ‘instant collaboration’, however, the systems did not have the expected effect in use [29, 85]. CSCW research has documented several cases of failed implementations of groupware systems and many of these are based upon a gap between the expectations of the groupware and then the actual use and effort required to make the IT system function in the organization [86–88]. Managers can fail in their intuition in assessing the value of implementing a system compared to the extra work required to make the system successful when they decide if the system should be purchased. Thus, the challenge for developers of groupware technology includes that managers often underestimate the additional work that is needed when using groupware applications.
2.8 The adoption process
This challenge concerns the organizational practice where groupware is implemented and brought into use in the organization. Unpacking this challenge, we start by making a distinction between different concepts; ‘Implementing groupware’ refers to the process of installing software on machines while setting up access to the system for different users. However, having groupware installed on computers in an organization does not mean that these technologies will be used. ‘Organizational implementation of groupware’ acknowledges that implementation is not just a technical issue but includes concerns about organizational changes [89, 90]. Research into organizational implementation has suggested to be affected by the timing within the organization [91] and that the introduction of new IT systems always will include a reduction in productivity, which is why we cannot measure the success of groupware immediately after the implementation [92–94]. Further, there is a large tradition within information systems research focusing specifically on the ‘acceptance’ of technology based upon organizational members ‘perceived’ usefulness and ‘ease-of-use’ [95–97]. In more recent years the focus has been more on the ‘appropriation’ of technology highlighting that when cooperative technologies are introduced into an organization, both the organization as well as the technology are transformed and hereof, they are transforming each other. Across this large literature on the adoption of groupware, it is clear that adopting a groupware application requires carefully planned activities where the group of future users is introduced to a clear purpose of the groupware system, as well as how to use the system in practice [98]. Thus, the challenge for developers of groupware technology is that groupware needs to be introduced carefully as different actors involved in the common field of work can have different perceptions of its usefulness. Groupware applications which are only appreciated by a minimum of the involved actors in the organization, risk becoming a disaster.
3 Methods
The empirical data presented in this paper is part of a larger research project investigating the future of work and the design of cooperative technologies for hybrid settings (ReWork Research Project [8, 99]). While the research interest of the ReWork project is at a larger scale, this paper focuses on challenges for developing groupware technologies. To investigate the challenges for developing groupware technologies today and reassess whether the challenges from three decades ago still persist, we employed empirical ethnographic research methods. Ethnographic methods provide insights into work and collaboration [100] and have previously been used to unpack office work [48, 60]. Drawing on current empirical data from two organizations, our analysis of challenges provides insights into present work conditions, particularly the hybrid organizational setup faced by most companies. Hybrid conditions manifest in various formats and constellations [16, 17, 101]. The flexibility and dynamic nature of geographical locations inherent in hybrid work models contribute to a growing adoption of computer-supported work practices facilitated by various groupware technologies to accomplish tasks. The groupware technologies employed in our empirical cases comprise a mix of systems used before the pandemic lockdowns, those that were introduced or intensively utilized during the lockdown to enable distributed team members to collaborate, and new technologies implemented after the pandemic to support the continuing partial remote work. This diversity in technologies and work practices makes these cases particularly interesting for studying the challenges that groupware developers face in 2024, by leveraging empirical data about how groupware is enacted in work within and across separate departments, small project teams, and organizations.
When initiating the empirical work, we (expectedly) realized that office work today is impacted by the possibility of remote work, creating hybrid work arrangements across departments as well as smaller project teams. Exploring the question of which challenges exist for groupware developers today, therefore, also forced us to navigate these challenges ourselves in our methodological considerations. The fact that work today involves collocated and online interactions, as well as physical and digital technologies, sets different requirements for ethnographic methods [58, 102], [103], [104]. Cooperation unfolds in different contexts, at different sites, both collocated and digitally. Capturing these elements using ethnographic strategies requires considerations for how to capture insight on ‘online interaction’ unpacking organizational members’ perceptions of the successes and failures of groupware technologies by different individuals or sub-groups in a context-dependent perspective. Studying hybrid environments can pose challenges similar to the findings of the challenges existing for designing technology supporting such work conditions [103]. To navigate these, we focused the ethnography on the office workplace, shifting our focus depending on different days (digital vs. physical), and incorporated archival data to recapture aspects of online interactions and cooperative work activities (e.g., text archives from messaging).
The ethnography was conducted in 2023 to understand how work unfolds in organizations striving to rebuild a “vibrant office atmosphere” after the pandemic. Before initiating the ethnography, we engaged with representatives from the organizations through workshops with multiple companies under the theme “The Future of Work”. Through these interactions, we learned about the companies, their departments, and some of their challenges with hybrid work. These insights were critical for initiating the ethnography within the companies. Being familiar with the organizations beforehand allowed us to build on existing discussions and concerns while directing our ethnographic work both be relevant for us as researchers as well as the organizations. This was crucial for providing access to conduct the empirical work. We studied ethnographically how cooperative groups within the two organizations arranged their cooperative work, which groupware technologies they used to support their work, and how different organizational members perceived the work conditions before, during, and after the COVID-19 pandemic. Particularly the new hybrid setup was important for the organizations to understand, thus we explored how work was performed after the reopening of the offices (for example, how hybrid configurations influenced work and use of artefacts). We focused on one department at each of the companies including conversations with department managers. For each department, we identified teams, and comparing the managerial perspectives with the everyday work practices of teams operating under different contexts allowed us insights into difference characteristics and nuances in the work.
3.1 Empirical cases
The two empirical studies were conducted in two distinct organizations operating within different business domains, yet both being mainly computer-based and therefore less reliant on the physical company facilities. The organizations differ in the type of work conducted, the size, (global) team distribution, and degree of coupling, as well as the need for collaboration across different groups (Table 1). The specific departments in each of the companies were chosen based on their willingness to be involved, access to data and office buildings concerning GDPR, as well as the companies’ non-disclosure obligations.
3.1.1 InterFin (Org1)
InterFin is an IT company with 1700 employees designing, implementing, and maintaining IT infrastructure for the financial industry. The company operates in two countries, Denmark and Poland, and has multiple office buildings (five in each of two cities in each country). InterFin expanded beyond its original presence in Denmark in 2017 by establishing an office in Poland and later opening a second office in a new city in Poland. Today, all 1700 employees are evenly distributed between the two countries. During the pandemic, all employees worked from home. In Denmark, pandemic-related restrictions were in place from March 2020 until the end of January 2022, when all restrictions were lifted. In Poland, the restrictions were lifted in March 2022.
The data collection took place in the Winter and Spring of 2023, initiated with interviews with the department manager, followed by empirical observations. We studied one department consisting of two teams in total including approximately 20 employees with a focus on respectively development and implementation of agile work practices.[2] All teams adhere to the agile work model, defining their processes and use of software tools for collaborative work. Both teams maintain close coupling in their work, conducting team meetings every morning, and engaged in collaborative activities throughout the day involving the entire teams or sub-groups within the teams. Moreover, both teams are interdependent, working across the department and collaborating with individuals and sub-groups from other departments within the organization. For example, they regularly meet with team managers from various departments to educate and coach on how to structure and manage in line with the agile work mindset. Although our primary focus is on work within the department, we also consider the cross-department nature of the work, including findings from collaboration with individuals outside this specific department.
The department in focus is situated in one office building in Denmark and another in Poland, with additional locations being private homes. The department as well as the sub-teams, are globally distributed and therefore never able to be physically collocated at the company office. Due to geographical constraints, our on-site visit was limited to the office in Denmark. However, we virtually met with the workers in Poland and were informed that their office mirrored the one we visited in Denmark. For subsequent references to the company, we use the designation ‘Org1’.
3.1.2 GlobalContent (Org2)
GlobalContent is a holding company with a presence in 200 location sites worldwide. As a holding company, its relationship with subsidiary companies varies. In our data collection, we focused on four companies that directly provide content to the parent company and engage with organizational members daily. Throughout the COVID-19 pandemic, the office experienced a lockdown, aligning with the same period as InterFin, following regulations set by the Danish government. Upon the reopening of the offices, teams were rotated to gradually reintroduce people to the workplace.
The data collection took place in the Summer and Fall of 2023, with a focus on the IT department, which is located at the headquarters. This data collection was also initiated with an interview with the responsible manager for the department, followed by a period of ethnographic observations. The IT department was chosen because it maintains close ties with subsidiary companies worldwide, by being responsible for parts of their IT solutions and infrastructure. The organizational members are dependent on global cooperation involving various stakeholders. The department is structured around four sub-areas focusing on data, security, infrastructure, government, and business partnering, comprising a total of approximately 55 employees. The cooperative group activities are structured within the departments, the sub-teams within the department areas, project teams collaborating across the sub-areas, and individuals from department and subsidiary companies. Depending on the work task, the teams sometimes collaborate with coworkers within the department or with external parties. For example, the ‘data’ group mainly collaborates within the team, while the ‘business’ group must visit the subsidiary companies weekly.
All employees associated with the IT department are based in Denmark and have geographical access to GlobalContent’s office building. However, work activities may necessitate collaboration with individuals placed in other areas of the organizational structure. The ethnographic work primarily focused on groups within the IT departments, but due to the nature of the work, we include data from collaboration across the organization. For subsequent references to the company, we use the designation ‘Org2’.
Empirical cases.
| InterFin (Org1) | GlobalContent (Org2) | |
|---|---|---|
| Employees (total in organization) | 1700 | 6600 |
| Employees (department for observation) | 20 | 55 |
| Countries (total in organization) | 2 (6 office sites) | 30 (200 office sites) |
| Countries (department for observation) | 2 (4 office sites) | 1 (1 office site) |
| Work domain | Finance | Entertainment |
| Main groupware applications | Office, Jira, Confluence | Office, Workplace, SolarWinds |
| Work model | Agile | Post agilea |
| Team sizes | 8–10 people | 3–12 people |
| Working across teams | Yes | Yes |
-
aThe organization previously followed the agile work model but transitioned away from it a month before we started the ethnography.
3.2 Data collection
The department managers at Org1 and Org2 allowed us to join their offices and observe their work activities. These activities include cooperative work both internally within the individual teams and across departments, as well as with external stakeholders. We observed both synchronous and asynchronous work. We quickly realized that most work activities were planned as meetings, so to observe synchronous work activities, we participated in different types of meetings between different groups of people. In this way, we got insights into the current projects in the companies, who collaborated with whom, and the general work goals and activities in the respective departments. Moreover, we used the meetings to identify specific projects and/or sub-groups who were willing to let us observe their work in more detail.
To study the asynchronous work, we identified team members who allowed for observation of their work activities during the day. This includes their location, which technologies were enacted (including the written communication, and use of software tools), and general work practices and task goals. The observations were conducted by the first author who sat next to the employees on different days. We observed the work practices and asked elaborating questions to clarify observations on what and why. This was either in the moment when it was appropriate to interrupt or otherwise noted down and asked at follow-up interviews later. This approach provided insights into the work task in focus, which sub-groups the person engaged in, and which technologies were used for which activities. Additionally, this approach revealed specific events that could be followed up on during the following weeks, and therefore get a timely perspective on the simultaneously synchronous/asynchronous work performed in the cooperative practices required to accomplish work. When allowed to, we documented the work events with pictures and screenshots. Otherwise, all observations were written down in detail in a notebook. Due to GDPR, we were not allowed to record employees’ voices, and therefore made sure to write memos and generally document all observations in written format.
When collecting data, we were aware of the limitations due to only conducting ethnography at the office when hybrid work also takes place at other locations. We did not have access to people’s private homes beyond what the participants expressed themselves about these places during interviews. We focus our analysis on the groupware, which technologies and applications were in use, how collaboration unfolds in different groups, and how groupware enables and constrains work. See Table 2 (Data sources).
3.3 Data analysis
To explore challenges for groupware developers, we gathered all collected data, encompassing observation notes, site pictures, company documents, screenshots, and similar materials. We carefully reviewed all data to categorize empirical insights, focusing specifically on challenges in cooperative work and the support of groupware systems.
We identified all technologies in use – hardware and software – to understand how they supported various work activities. Across the two organizations, these applications included email, calendar, intranet, MS Teams, PowerPoint, Word, Excel, Jira, Confluence, Workplace, SolarWinds, DataDog, CiscoBoard, and FixIt. The physical artefacts include phones, laptops, keyboards, additional screen monitors (personal at desks, shared at meetings rooms, and office space), paper/tablets, pens, headphones, chargers, cameras, speakers, and relevant adapters/cables. Subsequently, we mapped out cooperative activities observed during the ethnography such as planning, evaluation, production, coordination, monitoring, documentation, data analysis, testing, information sharing, knowledge sharing, and ideation.
For the identification of challenges in groupware technologies, we employed a deductive orientation for the analytical process [105], considering original phrases of Grudin’s challenges as our main themes [1]. We directly converted the challenges into thematical descriptions relying on both the descriptive parts of the challenges and the examples given in the paper [1], as well as exemplifying specific groupware technologies the challenge was referring to at that time (e.g., email application). The analysis was an iterative process, involving continuous scrutinizing of our empirical data and exploration of theoretical concerns. In the categorization process, we included observation data from actions, statements during interviews, and information from both managers and organizational members, considering all information across all teams and both organizations. In this analytical work, we use ‘post-it’ notes of relevant empirical observations inspired by affinity diagraming [106]. This included the technologies that we mapped out (physical and digital), the cooperative activities, the members involved and their geographical locations, specific events observed during the observation as well as statements from the organizational members. For our analysis, we identified empirical scenarios supported by diverse groupware technologies in both organizations, encompassing departmental activities and concerns (e.g., cross-department information sharing) and smaller team configurations (e.g., project work). These scenarios represented various cooperative distributions (i.e., collocated, hybrid, and remote setups). The empirical scenarios include events such as managers’ decision process on which groupware to implement, applications used to stay updated on activities in the department (i.e., MS Teams and Workplace), and communication/coordination within project teams (i.e., MS Teams, Excel, Jira).
Through several iterations of analytical discussions, we linked the challenges in the empirical examples to the thematic descriptions of the original challenges. First, we selected a specific groupware technology from the empirical data as an example to analyze the original challenges, assessing whether they persist, change, or become irrelevant (e.g., file sharing in MS Teams application). In the next analytical iteration, we focused on specific challenges presented in the original paper, relating these individually to empirical examples and situating concrete challenges in various scenarios. Then, we examined diverse empirical descriptions to identify which of the historical challenges that effectively pictured the current implications for groupware developers that were illustrated in our empirical data. Combining different analytical approaches allowed us to iteratively consider which challenges exist today, how these are different from 30 years ago, and how potential revision of the original challenge most accurately would represent our new empirical findings.
Throughout the process, we continually explored whether new challenges had arisen or if original challenges had become irrelevant. For example, while we initially considered if the challenge of unobtrusive accessibility had been conquered and thus ceased to be a challenge, we also identified a new challenge of creating boundaries across artefacts. Through our discussions, we found that proposing the challenge of unobtrusive accessibility as “conquered” and the challenge of creating boundaries across artefacts as “emerging” fail to acknowledge the link between what has been “solved” and what has been “introduced”. Instead, a revision of the challenges indicates how the challenges have historically evolved. The challenge of unobtrusive accessibility has transformed from the challenge of allowing multiple applications to run in parallel simultaneously allowing actors to easily shift across applications while working to instead introduce extra work of handling multiple artefacts (physical and digital) and their boundaries in as ecologies of artefacts (exaggerated accessibility). Moving back and forth between empirical data and theoretical concerns of the eight challenges, we iteratively discussed and reframed the challenges as we identified empirical examples in the data demonstrating how the challenges emerge today. In our results section, we selected empirical scenarios exemplifying each of the challenges, outlining how groupware is perceived today, how the challenges have evolved, and how these insights can assist developers of groupware systems in the future.
4 Results
4.1 Disparity in work and benefit
The disparity between work and benefit refers to the potential misalignment between who benefits from the use of the technologies and who needs to do the required work for the technology to work. Examining the empirical observations from Org1 and Org2 on their use of groupware technologies supporting their hybrid synchronous meetings, we identified several examples where the increased work of making the hybrid technology function relied on specific people, while others benefitted. What was pertinent in these empirical observations is how the sub-group of collocated participants must engage in additional work activities to accommodate the work of others – namely the individuals who were geographically distributed from the collocated sub-group. This additional work took different forms and shaped activities in certain ways, however, all the work of accommodating and adjusting the socio-technical setup for including remote participants in the meeting was left to a few people. Below we provide a few examples across both cases.
4.1.1 Teamwork in software tool rollout
The first example concerns a situation where a project team at Org2 was assigned the task of implementing a new software tool into the organization. Part of the implementation process includes detailed work of aligning multiple tasks and activities across the participants within the project team. This work includes creating a long-term plan for the implementation, developing the educational material based on information from the external provider of the tool as well as getting an understanding of the new features of the tool. When the project implementation was to be executed, different team members were responsible for various parts of the project, which required them to continuously align and coordinate their tasks. Since the team members are also new to the software tool, participants also need to learn about the tool, while planning the implementation and education. The project manager of the team is responsible for making the plan and structure of the team meetings throughout the project. The project team includes six participants who are physically located in Denmark working either from the office or remotely from home. The providers of the software tool are located in Britain. The geographical distribution required all meetings to be organized as hybrid meetings of blended collocated and geographically distributed members. The hybrid setup shaped the project team’s collaboration as well as the conditions of using a collection of groupware systems including video conferencing tools and associated digital applications. Below we go into more detail.
Initiating the software tool implementation project, the project manager created a kick-off meeting, where all members of the project were introduced to the scope and plan for the project. The initial meeting only included organizational members who were all internal to the organization and the meeting was performed in a hybrid setting with four collocated team members attending from the office in Denmark and two team members attending online from home. The collocated project members conducted the kick-off meeting in a room six floors from their office, in a space close to the canteen of the building. This room was large enough for all project members and available, whereas all the other rooms closer to their desks were too small and reserved for others. During the kick-off meeting, different challenges occurred, and they experienced several technological issues delaying the work. The project manager connected his laptop to the shared screen in the meeting room and another collocated participant joined the MS Teams meeting together with two other geographically distributed team members who both worked from home. Sound issues arose as the project manager connected a cable to their laptop attaching the speaker in the room. The speaker did not work. One of the team members went to the office six floors down to get a new cable, which did not solve the problem. One of the other team members changed the setting on the screen setup in the room, which provided sound from the speaker, however, echoing all that was said. After 10 minutes of troubleshooting, they gave up, and disconnected from the speaker and microphone in the meeting room, to use the laptop’s speakers instead. The project members introduce themselves, starting with the virtual attendees. When the physically collocated participants start talking, new sound issues arise by echoing the sound, making it impossible for the virtual attendees to hear the collocated participants. The echo was also interrupting the collocated sub-group. To solve the issue, the collocated sub-group had to turn on and off the sound and the speaker several times during the meeting depending on who (collocated or virtual participants) was talking. When forgetting to do so, the sound issues interrupting the meetings continued, either by echoing the sound or preventing playing the sound. This happened several times during the meeting, preventing the online participants and collocated group from hearing each other and delaying the meeting as participants had to repeat themselves several times confused by who was muted, and the constant attention to which speaker and microphone to turn on and off and when. Likewise, there were challenges in the online setup – the camera in the meeting room was used. The video feed showed only the end of the table in the frame, making it impossible for the online attendees to see the collocated project members when they talked. The project manager connected to the shared screen to share his slides, however, during the meeting, they realized that none of the online attendees were able to see these slides, as the project manager mirrored his laptop’s screen on the shared monitor but had not shared the slideshow in the video conferencing tool. One of the participants should have attended a new meeting at the time this meeting ended, but as he needed to go down six floors, he had to leave before the meeting ended.
Interestingly, zooming out from the details on the kick-off meeting for the software tool implementation project, it is evident that the additional work required to include geographically distributed team members is no small task and that all the work is done by the collocated project members. The collocated team members have much work to do in order to allow for remote participants to join – while the work remote participants can provide to solve the issues is limited. Remote workers depend upon the collocated team members to do the work of allowing them to join. They are ‘passive’ by design since their digital presence relies upon how collocated team member adjusts their bodies, the technologies, and connect the digital and the physical setup. While you can say that for the hybrid setting to work the remote participants depend upon the collocated members to engage in articulation work of the digital setup, while the remote participants mostly are involved by logging in to the groupware technology. Remote workers need to do extra work to make sure that they can be heard – for example, in this scenario see that the remote participants talk for around 30 s before the collocated team members manage to turn on and off the right microphones and can inform the remote participant that they are muted. Because the camera does not display any of the collocated participants in the video feed, the remote participant does not know that he is muted. The remote worker then needs to repeat himself. Thus, there is a disparity in work and benefit between the people doing the required work, and the people being able to benefit from the work. Based upon the experienced challenges of the hybrid setup, the project manager afterward plans an additional 15 min before all their meetings to test the technology setup. Due to logistic reasons, the meeting room was also changed across meetings, thus the project manager began to bring a speaker, microphone, and camera for every meeting as a backup in case the equipment within the rooms did not work.
Challenge: In our empirical data, the challenge of disparity in work and benefit from groupware use continues to exist. Concretely we showed the extra work required for accomplishing the cooperative work is related to the work of including all individuals into the common field of work. The project manager is required to do extra work to include participants from different locations, and the remote participants need to adapt to technical conditions produced by the collocated sub-groups and adjust their actions during breakdowns, like repeating themselves if required. Furthermore, the project manager stated when asked about hybrid meetings, that it is “easier to do the meeting as virtual [only]”. However, remote work without hybrid options also disregards the advantages of the cooperation of collocation. Leveraging on the physical collocated combined with remote participation might not be perceived as beneficial by the project manager as an individual; however, a hybrid arrangement does support the cooperative work when it is impossible to have everybody collocated. We therefore suggest reframing the challenge of disparity in work and the benefit to always depending on additional work from individuals or sub-groups, as today the increasingly digitally performed work and the possibility to work from different locations require cooperative activities and/or information to include digital features.
4.2 Critical mass and Prisoner’s dilemma problems
Critical mass refers to the challenge that for groupware to be useful, a high percentage of the involved actors must use the groupware system. In our empirical cases, we found that the cooperative participants all used the groupware applications required for them to conduct their work. For example, organization members in Org1 are present on the Microsoft Teams application and engaged in different sets of sub-group classification structures within the groupware technology. Thus, in our empirical data, we did not identify specific challenges related to critical mass. Instead, we saw how the critical mass challenge was related to access to technologies. For groupware to function, all involved people must have user access to the groupware platform. Therefore, in our cases, the challenge of critical mass was not related to the number of participants refusing to use the application, but instead, the challenge was in producing access (as in security access) to the relevant technology. We will provide an example below.
4.2.1 Mix-up in team scheduling
In Org2, we observed a team tasked with a substantial project, namely, to replace the fundamental Internet network infrastructure across 26 subsidiary office sites. This intricate endeavour involves members from various internal departments, the wider organization, and external consultants. The project encompasses different roles: internally within the main company is the Network Team, dedicated to designing the new network infrastructure and ensuring alignment with the subsidiary sites’ needs. Another internal team, the Device Team, focuses on managing devices across different sites. Externally, external consultants are hired for the technological procedures associated with replacing the network at the sites, as well as ongoing network maintenance.
The challenge in this empirical example arises from scheduling network replacement events to avoid disruptions to essential work activities at the local sites, ensuring all relevant sub-groups are available at the specified time. External consultants create and update the schedule weekly, sending it to the Network Team within the internal department. However, without specific updates explicitly outlined, confusion arises within the internal teams. As part of their coordination responsibilities, the Network Team organizes various activities based on a larger schedule, including coordination with the internal team responsible for devices. In preparation for a network replacement event, a joint meeting is held between a member of the Network Team and the Device Team to identify devices at the local site that must be enrolled on the new networks. The meeting is put into place to identify which devices are in use at the local site before replacing the Internet within increased security measures in order to prepare for any devices that require special attention (e.g., printers, shared tablets) allowing for a smooth transition.
In this specific example, the network replacement occurs in Norway, necessitating the company’s physical presence during the event to test its functionality on different devices. Consequently, a team member from the Device Team organizes a flight trip to Norway, as this team is responsible for identifying and managing devices. A coordinative complication arises when the two teams during the meeting realize that the planned trip to Norway does not align with the day scheduled for replacing the network. While it is the responsibility of the Device Team to manage devices, it is the responsibility of the Network Team to test the network functions ensuring these behave as expected after replacing the Internet. It is therefore a grey area who should be physically present at the site in Norway during the replacement event. The Device Team can identify devices on the same day as the testing of the devices, and it is therefore agreed to send only a person from the Device Team from Denmark to Norway for the network replacement event to reduce travel.
All the scheduling of the project is done by external consultants. To share the schedules, they are distributed to the Network Team by sending “photos” of the schedule. The absence of direct access to the planning tools and actual scheduling creates uncertainty in the team. It is unclear who updates the schedule, when, and where – and this opaqueness in coordinative processes exacerbates the situation, as the different sub-groups do not have the same updated schedule available or are able to monitor changes to the schedule. The external group of consultants is in charge of scheduling, while the Network Team is responsible for coordination across different geographical sites and sub-teams. This coordination includes securing agreements with local representatives to turn off the network on the designated day of replacement. The complexity of the work demands intricate coordination across different organizational groups. Unfortunately, the sub-groups involved in various tasks lack access to the same tools. The internal Network Team is without access to the tools used by the external consultants, potentially leading to misalignments. In this instance, conflicting information results in different sub-groups planning the same network replacement activity on different dates.
Challenge: For groupware to function effectively, access to the information stored in the groupware system (in this case scheduling) is critical for all relevant individuals, irrespective of their organizational conditions (internal employees as well as external consultants). Failure to do so risks the groupware application’s failure and impedes cooperative work. In the current landscape, most technologies are designed for collaborative use, and the critical challenge lies in ensuring that these systems accommodate the appropriate number of users and individuals. This appropriate number is not necessarily the majority of employees in the organization but includes all individuals relevant to the common field of work, regardless of their organizational affiliations. If the relevant individuals involved in the shared work activities do not have access, there is a risk of miscommunication and failure in coordination. Thus, based upon our empirical data on hybrid work, we propose to re-think the critical mass challenge from being ‘the majority’ of all employees to being relevant individuals for the common field of work.
4.3 Disruption of social processes
Disruption of social processes covers the challenge that groupware can interfere with social dynamics and implicit information such as social taboos and political structures. Going through our empirical data, we find examples of collocated sub-groups who interact directly person-to-person, circumventing the groupware technology protocols for interacting digitally to ensure that all participants in the group have equal access to important information.
4.3.1 Oversight in shared folder structure negotiations
Exploring the complexities of managing social dynamics in hybrid office environments, we turn our attention to a team in Org1. This team operates across at least four locations spanning two countries, engaging in daily collaboration. They commence each day with a daily meeting to synchronize current tasks and challenges. The team manager is stationed at the company office in Denmark along with two team members. Two other team members are geographically located in two different regional areas in Denmark, unable to commute to the office, while the remaining team members are situated in Poland. The Microsoft Teams application serves as the central hub for their communication including daily video meetings, direct messaging, updates, and file sharing. Beyond internal organizational collaboration, the team plays a pivotal role in coaching and educating other company departments and teams in agile work practices, sharing teaching materials, and more.
Due to the growing sets of files shared within the groupware system, two team members from the Denmark office requested a restructuring of the folder system from the team manager on behalf of the entire team. Subsequently, the team manager restructured the folders and informed the two team members in a team chat, including the three individuals who had previously discussed the need for restructuring. While this communication continues a conversation that originated in the office, communicating between members of the sub-group from one Danish location, it was only shared across the team digitally after the fact. Thus, other members remote to the sub-group who are restructuring are presented with the result of the conversations, but not included in the conversation to find the solution. It should be mentioned that the two collocated team members initiated the restructuring on behalf of the entire team, but having a direct conversation with the manager, detached the rest of the team from the conversation. Since the folders are shared across the entire team, the restructuring has an impact on all team members.
This scenario illustrates how collocated sub-groups risk inadvertently sidelining a broader discussion by circumventing the groupware tool for dialogue. The manager’s exclusive response to the two collocated team members creates distinct sub-groups within the cooperative team, impeding seamless information sharing. In hybrid work configurations, there is a high risk that sub-groups will emerge due to a lack of collocation. The risk of sub-groups necessitates cohesive teamwork to counteract potential negative social dynamics. In our empirical case, Microsoft Teams serves as a central platform for information and knowledge sharing, facilitated through shared folders and a chat forum, however, if only part of the conversation is displayed digitally the risk of exclusion is high.
Challenge: Cooperative groups consist of different sub-groups with varying conditions for accessing other individuals or sub-groups engaging in the shared work activity, presenting new challenges for violating social processes. While the groupware MS Teams enables access between different individuals and sub-groups, the organizational members risk violating social processes, if individuals engaged in the common field of work choose to interact in the (collocated) sub-groups either by circumventing the groupware technology and interacting directly with collocated individuals or by turning towards (existing or new) sub-groups within the existing groupware technology.
4.4 Exception handling
The challenge of exception handling refers to the difficulty of groupware being used differently than expected, especially when the cooperative work is organized variously making exception handling critical to solve a given task. Examining our empirical data, we see that groupware technology in our cases allows for exception handling by being designed priori as open-ended, and therefore not stipulating any specific ways of use. However, the open-ended design requires that organizational members engage to configure the groupware technology over time to accommodate for emergent exception handling.
4.4.1 Teams application used in multiple contexts
Examining the reconfigurations of Microsoft Teams within Org1 during the COVID-19 pandemic, which physically separated collaborating teams, sheds light on the challenges of exception handling. The adjustments aimed to make the software tool versatile for various work activities, evolving from its original purpose of primarily facilitating online meetings to becoming the central hub for all activities during the pandemic-induced shift to remote work.
As the agile coaches in Org1, responsible for teaching work practices to different departments, transitioned their activities online due to social distancing and work-from-home arrangements, Microsoft Teams became the platform for seminars and coaching sessions. This period coincided with Org1 revising its strategy, expanding activities, and hiring new employees in Poland. Even as regulations eased and some employees returned to the office, the workforce remained evenly distributed between Denmark and Poland. This led to a strategic management decision that all teams must include members from both countries, which consequently alters work conditions where teams will never be geographically collocated. Post-pandemic, despite some employees returning to the office, many activities, including teaching activities, continued to be conducted online due to the geographical distribution of team members.
Interestingly, one of the activities, the core agile practice of PI (Program Increment) planning, was referred to as crucially requiring individuals to be geographically collocated. PI planning involves the planning of the company’s goals and objectives for the following time scope. However, the post-pandemic work conditions did not allow for collocation among all team members, initiating discussions within the team on how to adapt to the partial distribution of team members. This included discussions before the event on possible ways to conduct PI planning and post-reflections. The team started using virtual digital whiteboards shared in the Microsoft Teams folder, for example, to brainstorm personal experiences of the PI planning event. Recognizing the importance of team and departmental cohesion, the organization initiates prioritization of social activities for relationship-building. These social events, mirroring the format of planning and evaluation meetings, were also conducted on Microsoft Teams. Each team member attended these activities individually from their personal workspace. During one such event, they engaged in a team-building game.
This example showcases how the Microsoft Teams application, initially used for specific meeting functions, evolved, and was adapted to multiple cooperative contexts, becoming integral to various aspects of work, collaboration, and team building in response to external challenges like a global pandemic, and the partial distribution of closely collaborating teams after the pandemic. What is important and interesting is that we across both Org1 and Org2 saw several examples where the same groupware system was used in multiple different ways and that the design of groupware technologies introduced all were fundamentally open-ended by design allowing for participant to configure and re-configure their used as needed. In this way, participants would not experience the need for exception handling – as in identifying a workaround to allow for smooth interaction. Instead, we, in both organizations, witnessed how the open-ended design of groupware technologies made the participants reflect iteratively while making it possible for organizational members to adjust the technologies addressing emergent situations of potential exception handling before these became an issue.
Challenge: The dynamic reconfigurations of the MS Teams application to accommodate diverse work scenarios are possible due to the open-ended and flexible conceptual structural design of the groupware technology. Teams as a groupware application extend beyond routine patterns of use to encompass various activities like quarterly planning, goal setting, evaluations, teaching, and social engagements. The adaptability of the groupware proves invaluable for supporting work in different contexts. The flexibility demands ongoing adjustments of the groupware based on reflection and action initiated by organizational members. The continuous addition of activities to be done using the same groupware system necessitates new ways to share files, link new applications, modify folder structures, and more. Surprisingly, we found that in both organizations the need for exceptional handling ‘outside the groupware’ to accommodate emergent situations did not exist, since the participants were able to adjust the technology.
4.5 Unobtrusive accessibility
Unobtrusive accessibility refers to the challenge of cooperative features to be infrequently used. Examining our empirical data, we saw that the groupware used in our cases enables unobtrusive accessibility by including intuitive built-in cooperative features. Concretely, the groupware technologies used allowed participants to engage in multiple, parallel, and different types of activities simultaneously. The multiple and parallel use however also creates challenges, since by allowing people to do multi-tasking, shifting across individual tasks and cooperative tasks seamlessly creates the challenge of creating boundaries for and around activities and technologies. In this way, the groupware used emerged as exaggerated accessibility that requires individuals engaging in group work to create boundaries in technologies in practice.
4.5.1 Re-bounding technologies in practice
Considering the groupware technology used it is evident across Org1 and Org2 that none of the organizations could be said to have ‘one type of groupware’. Instead, both organizations had an infrastructure of artifacts, including physical technologies like laptops, mobile phones, tablets, notebooks, keyboards, monitors, cables, and wires, and digital artifacts such as Microsoft Teams, Cisco Webex, Word, PowerPoint, Jira, and Datadog. All these artifacts and devices were interlinked; for example, it is possible to connect to Teams on both laptops and cell phones, and participants can share Word files in Teams folders or share an individual screen displaying Datadog in Cisco Webex. All these interconnections and relations created groupware setup as an ecology of artifacts enabling exaggerated accessibility supporting different types of activities, which blurred the boundaries between artifacts (devices and groupware applications), necessitating continuous reconfiguration of the setup.
Let us focus on one organizational member, Sophie, to illustrate. Sophie, an agile coach at Org1, commutes to the office three days per week, starting her day by picking up her physical devices from the locker and setting up her workstation. Her work setup for the daily catch-up meeting involves connecting her computer to two monitors, arranging her keyboard and mouse, and placing her notebook and pen next to the laptop. The first meeting is the daily catch-up meeting with the team. Sophie facilitates the meeting using notes on her laptop’s screen, with Microsoft Teams on the second monitor, occasionally sharing her screen to display a Jira board scheduling the team’s tasks and using her notebook for meeting notes. During the meeting, a backchannel is initiated, where team members share text messages; however, she refrains from checking it until after the meeting concludes to maintain focus on facilitating the meeting. The timestamp in the backchannel assists her in understanding the context in which the texts were sent during the meeting. Sophie has meticulously organized both physical devices and groupware applications to accommodate the needs for specific work tasks, creating boundaries for the artifactual setup.
After the meeting, Sophie worked on a task related to educating managers in agile work practices. Her setup includes Microsoft Teams on the laptop for immediate responses, a workboard on one monitor, and an Excel sheet on the third monitor. When collaborating with an organizational member (Bent) outside the team, Sophie goes to the Teams application and makes a Teams call directly to Bent. Bent and Sophie collaborate using the digital Board, sharing screens in the video call setup during their synchronous interaction. Sharing screens is the most essential functionality for their work including sharing the digital Board or other digital content like illustrations. Sophie continuously adapts her technical setup to support the collaborative work at hand considering collaborating partners, the content of the shared task, the digital opportunities as well as what shall happen after concrete engagement.
As part of agile coaching, Sophie meets with a manager in Microsoft Teams to discuss improving agile work practices within the team. For this personal coaching meeting, Sophie moves to a small meeting room, disconnects her laptop, and reconfigures the technical setup for a two-person meeting. Beyond office meetings, Sophie also works from home, adapting her technical setup accordingly. For example, she had a meeting with a colleague from the team by the end of the day, thus she decided to leave the office and then have the meeting when she arrived home. In this situation, she brought her laptop home instead of putting it back into the locker and then reconnected it to the setup she had at home.
The flexible work conditions and dynamic contexts require organizational members to rebound the technological setup – both physical and digital devices – to fit the specific work situation. For example, a manager at Org2 is taking early morning meetings on the Microsoft Teams application on his phone from the car due to a long commute time.
Challenge: Groupware supporting multiple, parallel types of use simultaneously is transforming the prior challenge of unobtrusive accessibility towards a revised challenge of participants bounding and creating boundaries around technologies. Instead of the challenge being the possibility of running multiple applications simultaneously, the challenge emerges as the difficulties of creating boundaries for the use of artefacts ecologies with an increased risk for mental overload constantly shifting between multiple interrelated contexts, artefacts, locations, applications, and devices simultaneously.
4.6 Difficulty of evaluation
Groupware systems are difficult to evaluate as they are context-dependent and affected by other actors involved in the work. The work scenarios in our empirical data exemplify this through the malleable team configuration continuously changing the context for the work. Despite engaging in a common field of work engaging the same individuals, the flexibility of the geographical locations of the different team members and the sub-groups, affect the context for work, making different technologies available to support the work.
4.6.1 Dynamic team configurations
Our research reveals that the dynamic nature of team compositions poses a significant challenge, especially within evolving group structures. Both Org1 and Org2 grapple with hybrid distributed teams, each navigating distinct geographical configurations. While Org1 consistently maintains geographical dispersion, both Org1 and Org2’s organizational members have the flexibility of accessing shared office spaces and working occasionally from home, allowing employees to seamlessly transition between working from the office and remotely. Org1 holds a free seating policy while Org2 has permanent seats for the employees in the organization. Both organizations have open office spaces requiring employees to move to meeting rooms when engaging in meetings either digitally or with collocated colleagues. Both organizations employ consistent department teams including the same individuals and project teams that are formed across departments working on a common field of work within a time-limited scope.
To illustrate, we draw on the example from the beginning of the Result section, which describes a project team working in changing contexts. The team engages in collaborative work, discussing specific steps in transitioning to a new software tool during internal project meetings and participating in educational sessions where external providers present the tool’s capabilities. However, the composition of these sessions varies on different days. During some internal project meetings, team members work from home while others are in the office, each day with new configurations. The same variability occurs in the case of educational sessions, where physical presence at the office differs. The project manager planning these sessions is unaware of the specific locations of team members for each session. Consequently, the project manager plans the sessions uniformly – booking a meeting room, bringing a camera, and microphone, and connecting his laptop to a second monitor. However, in some meetings, he is the sole physical attendee, while in others, the team is fully collocated, rendering the room size inadequate. Moreover, the nature of the meetings varies, ranging from 1-h external presentation to 10-min internal team discussions. This example highlights how the practical work context of the same project team can be entirely different, despite appearing similar in theory.
Challenge: While evaluation of groupware has always been challenging outside of real-life use cases, this challenge is further complicated as the cooperative configuration changes from day to day, due to the floating locations of individuals shaping the perceived usefulness of the groupware. The same systems must support work performed in various surroundings. Difficulties of evaluation refer to that we cannot simply test groupware within an experimental setting, since the cooperative engagement is shaped by the contextual nature of the work – which as the above example shows constantly changes. Testing groupware technology cannot be done outside the contextual use. Conducting a lab study to test if the groupware technology is suitable for Org2 or Org1 is not feasible because their work is shaped by the contextual contingencies that change daily (locations, rooms, content, people etc.). In this way, the dynamic nature of team compositions and contextual contingencies underscore the heightened complexity in evaluating groupware technologies as it was back in 1994, but moreover, we see how the locations are an added dynamic complexity when considering hybrid settings.
4.7 Failure of intuition
Failure of intuition refers to the challenge of managers’ decision-making regarding the implementation of cooperative systems. In our data, we see how managers strive to provide a vibrant and attractive workplace and office environment, however, question the quality of managerial decision-making related to groupware and the organizational conditions to perform the work.
4.7.1 Cultivating vibrant and attractive office environment
Our engagement with Org1 and Org2 unveiled a shared aspiration to foster vibrant and attractive hybrid offices. Working with the organizations we had several meetings with the managers from both organizations who openly acknowledged the challenge of creating a physical workspace infused with a lively atmosphere – especially after the pandemic. The ongoing process of achieving the vision of an attractive office involves intricate considerations. Org1, in an attempt to cultivate a vibrant office, has implemented policies mandating physical presence for a certain number of days a week, but this effort has not been seamlessly translated into the desired lively atmosphere. Despite recent physical renovations of the office space geared towards supporting various collaborative activities, employees often find themselves engrossed in online meetings at their laptops with headphones on and the challenge of finding a location in the office without disturbing others.
In contrast, Org2 adopts a different managerial approach refraining from enforcing physical attendance. Instead, the organization aspires to create an inviting, attractive, and innovative workspace that naturally draws employees in. However, both the push towards mandatory presence and the pull towards creating an appealing environment fall short of realizing their objectives. Notably, in terms of technology, both organizations have strategically equipped their offices with an array of groupware and devices, including laptops, tablets, and monitors at each desk, shared monitors in meeting rooms, and hubs for seamless connectivity. Org2 even invested in a Surface Hub (85′ screen on wheels) that can be moved around the office floor, for example, to be used for department meetings with partially hybrid participation. However, during the period of fieldwork at the office space, this screen was never in use, and employees also commented that it was not utilized.
The crux of the challenge lies in selecting a groupware portfolio and related devices that can effectively support the diverse work contexts prevalent in these organizations. Managers at both organizations express eagerness to implement strategies that cultivate a vibrant atmosphere and work environment. However, they grapple with deciding on specific actions to take. Cooperative groups within these entities may operate in fully collocated settings at times, shift to distributed work in various configurations, or navigate hybrid arrangements. Each of these work contexts imposes distinct requirements on the groupware technology, emphasizing the intricate balance needed to create a vibrant and effective hybrid office environment.
Challenge: The manager’s role in determining the appropriate groupware has evolved. While the historic challenge revolved around selecting specific groupware technologies for distinct activities (such as email for communication), the contemporary landscape presents a more intricate obstacle. Today’s challenge lies in curating a portfolio of diverse groupware technologies and devices capable of supporting a spectrum of work activities across different contexts. The complexity arises from the varied configurations, contexts, and purposes for which groupware is expected to provide support. The critical decision of which groupware to incorporate carries the risk of failure if it does not effectively cater to the diverse needs inherent in the organization’s multifaceted work environment.
4.8 The adoption process
The adoption process for cooperative systems is challenging as the value and usefulness of the groupware system are likely perceived differently by various individuals with a high risk of failing the implementation. In both our empirical cases the groupware systems were already in use when we arrived and thus it is difficult for us to see whether specific groupware technologies in use had adopting challenges. However, what we did witness was that any groupware application cannot be considered as a single entity. Instead, groupware technology in organizations today is always and immediately part of a larger infrastructure, thus the groupware adoption process is fundamentally about how new groupware systems extend the existing infrastructure supporting the work.
4.8.1 Implementation of cross-organizational social platform
In the intricate landscape of Org2’s organizational structure of subsidiary companies, with cooperative activities across different entities, the organization has incorporated the Workplace[3] software application into its extensive ecosystem. Crafted by Meta, Workplace stands as an online platform meticulously designed for fostering company-wide collaboration. Encompassing a rich array of features such as instant messaging, pages, and groups, WorkPlace positions itself as the professional sibling of Facebook. The primary objective of Workplace is to facilitate the sharing of work-related updates, critical information, IT developments, and events across diverse departments, subsidiary companies, and various groups within the organizational framework.
To encourage transparent communication and information exchange, Workplace is to become a shared platform accessible to different subsidiary companies at Org2. However, the assimilation of Workplace into Org2’s existing communication landscape encounters a challenge as the features of the social platform overlap with features of existing groupware used for their work, making the employees characterize Workplace as “yet another platform.”
Org2 heavily relies on Microsoft Teams as the primary tool for communication, serving as the cornerstone for sharing updates and information. The introduction of Workplace is met with skepticism by employees who view it as an additional layer of complexity. Microsoft Teams, a frequently used groupware system for employees, already offers a comprehensive suite of features, including shared ‘walls’ for information exchange, knowledge sharing, file sharing, direct messaging, and more. Deciding when to use Workplace instead (or additionally) is challenging due to the ingrained use of Teams, which can sometimes cause employees to forget about the new application. Introducing a new platform demands extra effort from the organizational members to post updates and stay informed. However, this work is not just about doing the work but remembering and considering when it is relevant to use. Org2 faces the delicate task of articulating Workplace’s unique value proposition and relevance, ensuring it does not become an additional burden for employees already adept at utilizing other groupware systems (such as Microsoft Teams). The challenge lies not just in technological integration but in delineating Workplace’s distinctive role to avoid redundancy and ensure seamless integration into the organization’s collaborative tapestry.
Challenge: While Workplace shares similarities with Teams, including group connections, post sharing, and direct messaging, the lack of a distinct value in use and the redundancy of features make it an additional, rather than an essential, tool. Consequently, the adoption process of Workplace necessitates a thoughtful implementation strategy, clarifying its unique value and relevance compared to the existing Teams platform. The challenge lies in articulating Workplace’s distinctive role, ensuring that it does not become an extra burden for employees who are already adept users of Microsoft Teams. During the adoption process of groupware applications and technologies, organizational members must integrate seamlessly with the existing infrastructure supporting common work processes. Failure to do so may result in these tools being perceived as additional tasks and, consequently, overlooked, or underutilized.
5 Discussion
Groupware technology is not just about designing and deploying technology into an organization but includes all the work of crafting socio-technical circumstances ensuring that the technology enables rather than constrains the work practices in which the technology is going to be situated. We sat out to explore whether the eight challenges for developers identified by Grudin in 1994 [1] were still pertinent in terms of creating and organizationally implementing groupware technologies in organizations today three decades later. We interrogated the challenges by introducing empirical observations from ethnographic work conducted in two organizations during 2023. By analytically considering our empirical data in terms of Grudin’s eight challenges, we were able to identify patterns across organizations and challenges, which allowed us to examine the empirical data in specific ways focusing on the groupware design, use, and adaption into the organizations. What is interesting about these cases is that after the pandemic the use of groupware has been ubiquitous within the organizations. This means that the way the organizations consider the fundamental technical infrastructure of the organization includes access and use of groupware technologies including, but not limited to, video-conferencing tools, shared folders, electronic calendars, and digital messaging systems (email, slack, etc.). Thus, when we went through the data to identify empirical observations that allowed us to comprehend more details about the design, use, and adaption of groupware, we quickly learned how groupware technology no longer is viewed as a potential add-on application within an organization. Instead, groupware technology tends to blend into the background assumptions of organizations and thus becomes a taken-for-granted infrastructure. Thus, the work people do to make groupware systems function is viewed as everyday circumstances of work, and thus requires an analytical gaze to pick apart for scrutiny. During this analytical scrutiny, it became clear to us that the original challenges for groupware developers were grouped into different overall categories of how groupware systems functioned.
The categories of the eight challenges are cooperative challenges, social challenges, and organizational challenges. Cooperative challenges (no. 4, 5) are related to how the cooperative engagement is conducted (in terms of articulation work and situated practices) and how well the groupware technologies support these cooperative practices. Social challenges (no. 1, 2, 3) are related to the social relations of the work, and in particular how groupware systems enable or constrain relationships among each other (including concerns of sub-group dynamics). Organizational challenges (no. 6, 7, 8) are related to the hierarchy and motivations embedded into decisions on groupware technology to support organizational practices. Together these three areas of challenges produce a set of relevant concerns that continue to be critical for groupware developers in 2024.
5.1 Cooperative challenges
The cooperative challenges for developers of groupware technology center the organization of work including procedures and protocols for work as well as the informal structures of the work organization. Work procedures and protocols are important for the design of groupware systems since these entail what people do, when and where [43, 56, 84]. Groupware systems embedded into organizations create the boundaries for which activities organizational members can do, and thus also bear the risk of constraining crucial activities of cooperative actors if these are not considered [54]. Cooperative work is always immediately socially organized [35], which means that the way participants interact and engage in the common field of work produces certain needs for groupware support. Different from single-user technology, Groupware cannot be understood outside the collective activities, making the design of generic groupware vulnerable, since the risk of producing a system that is completely aligned with an organizational practice is difficult [66, 82]. Organizational practices can be slippery, flexible, malleable, and unpredictable. The way people plan activities is rarely completely aligned with the way the activities actually are acted out in real-life practices [73, 74]. In practice when people act, they simply do what is necessary to accomplish the task, and often this is different from the actual prescribed practices [65, 80]. Paraphrasing Lucy Suchman, plans are only resources for practice, and situated practices are what actually takes place [61–63]. This is not to say that protocols and scripted activities are never followed and are unimportant [59] – they clearly are important and critical procedures following protocol (e.g., air traffic control). Instead, what CSCW researchers say is that the open-endedness, malleability, and reconfigurability of groupware systems are critical for success since groupware systems require organizational members to have the opportunity to change, revise, and realign the organizational procedures embedded into the design [83]. Without such opportunities, the participants would need to create workarounds (often in parallel systems) in order to accommodate the exception handling that often (close to always) is embedded in any kind of cooperative task [58].
Surprisingly, we did not detect the challenge of exception handling in the ways the two organizations enacted their groupware systems. Instead, our empirical data illustrated how the enacted groupware systems were open-ended in use, and how the organizational members were able to use the technologies across contexts and activities. We were very surprised to experience two cases, where the challenge of exception handling did not appear. Any literature review or summaries of empirical cases published in CSCW will demonstrate a wide range of exception-handling problems [77, 81]. Reflecting analytically upon this surprise, we discovered that the list of groupware systems that we have explored in the empirical cases were all fundamentally open-ended in nature as well as re-configurable – and thus the success of these concrete systems within the two organizations is very much due to that the technologies used, have in the very design of the groupware, including users’ ability to revise, re-structure, and re-organize content, folders, and structures. Further, we found examples where participants discussed and re-negotiated the conceptual structure of the groupware systems as part of their cooperative engagement. This is not to say that developers of groupware technologies now have solved the issue of exception handling; there are still multiple cases of for example workflow systems documenting the challenges arising when systems are not reconfigurable [74], and constraining important organizational practices, for example, in healthcare [57]. Instead, our argument here is that designing for exception handling in groupware systems continues to be crucially important to enable rather than constrain organizational practices, and our cases demonstrate how such designs can be successful. Further, our empirical cases suggest that organizational members have developed ways and practices that include configuration and reconfiguration of groupware technology as evidently important recurrent practices relevant to groupware technology use.
In our two empirical cases, the organizational members expected the groupware systems to blend into the background and thus to some extent support seamless cooperation in hybrid work arrangements. The seamless interaction took the form of organizational members taking for granted that they could work at various locations since the groupware systems allow them to access files and documents, as well as people and activities. The hybrid workplace ‘fantasy’ grew out of the ‘work-from-home-emergency’ during the pandemic, and thus organizational members knew from experience that working from different locations is possible. However, as we also document in the empirical data, the hybrid organization of work is severely more difficult than the complete geographical distribution of all participants. Further, our empirical cases demonstrate how access to groupware is not about ‘one groupware system’, but instead about a wide infrastructure of multiple parallel groupware applications that are interlinked across applications and digital devices. Organizational members move across organizational-, geographical-, application-, and device-contexts, thus, the current challenge on accessibility is not about allowing for unobtrusive accessibility [1], instead, the current challenge arises as mental, organizational, and technical overload, which risk stressing the individual [50]. Rather than focusing on designing groupware systems that allow for unobtrusive accessibility, the challenge for groupware developers is to find ways to reduce the mental load of navigating across contexts, applications, and devices.
Challenge 4: Emergent exception handling: For groupware flexibility to facilitate a wide range of activities (e.g., exception handling and improvisation) requires participants to reconfigure the groupware over time to accommodate emergent use reducing exception handling.
Challenge 5: Exaggerated accessibility: Groupware supporting multiple, parallel, and different usages of applications and devices simultaneously, requires participants in creating boundaries in technologies in practice.
5.2 Social challenges
When people cooperate, they are simultaneously engaged in social activities and relationships. How people engage socially includes considerations of motivational drivers and different forms of hierarchy. How cooperative work is organized socially matters for how people cooperate, and thus is also critical for the designers of groupware systems to ensure that technology enables rather than constrains the social organization of work. In our empirical cases, the social organization of work is shaped by the hybrid work organization [16], and this organizational structure shapes the cooperative work, and thus also the requirement for groupware technology in important ways. Re-thinking the social challenges for groupware developers, a core challenge for hybrid organizations is that organizational members are immediately and always in transition between locations [15]. This ‘space between’ is difficult to navigate [27] and the efforts of addressing relations work between artefacts, locations, and people increase in complicity in hybrid settings [47, 48]. This means that hybrid social organizations always are at risk of creating sub-groups. Sub-groups are not necessarily problematic, however, if the sub-groups align with the physical locations, there is a risk of faultlines [60].
Faultlines increase the risk of disrupting social processes, which often is related to hierarchy and motivation within the work. However, interestingly we found that the risk of disrupting social processes also arises when organizational members circumvent the technology. If an organizational member chooses to interact directly with another member engaged in the work, they create sub-groups within the team, consequently risking misalignment and faultlines [60]. Problematic sub-groups can jeopardize the creation of trust and commitment, which ultimately can lead to a ‘them/us’ binary [49, 51]. Organizational members working in different contexts are thus at risk of developing problematic relationships across members. Simultaneously, we found that for the hybrid interaction to function, it is required that cooperative actors are ready to collaborate [36], since without collaboration readiness the extra effort required to bridge across contexts risks being neglected [39]. Our empirical observations demonstrated that individuals working remotely in hybrid contexts are dependent upon the extra work of collocated members in making sure to include them remotely in the conversations. However, this additional articulation work required does not necessarily benefit the collocated members, especially in situations where organizational or geopolitical concerns make the dependencies asymmetric [37, 38, 44]. The challenges related to the disparity between work and benefit [1] thus remain today in 2024, however, this adds to existing complexities. The social organizational challenge in hybrid workplaces introduced concerns about the extra work required to execute and conduct hybrid meetings for the people who are collocated in the same room. The collocated sub-group must create a setup that supports both the collaboration with the physically present individuals and the individuals participating remotely, without this extra work benefiting themselves directly.
The social organization of work supported by groupware also requires that there is a critical mass of users to make the technology useful. Numbers of users are important for success with groupware technology, however in our empirical observations the challenge was not merely about the number of users but instead included an important extra concern. Namely, the groupware system needs to give the ‘appropriate users’ access to the system. We observed the importance of the relevant members engaged in the common field of work having access to the groupware. When organizations have complex organizational setups, such as multiple sub-companies, multiple different consultancy organizations involved, or engage in outsourcing or offshoring [45, 87], then the risk of people requiring access to certain systems but not having access to these systems increases. Access to technology and applications risks being constrained due to security concerns or simply misunderstandings; however, being excluded from important technologies jeopardizes both the organization, the team, and the individual. In one of our cases, external members had key areas of responsibility in the team, however, due to the limited access to internal resources, they did not have access to groupware applications and systems.
We acknowledge that our empirical cases both focused on hybrid cooperative work, and we are aware that not all types of organizational work are structured in a hybrid setting. Thus, we cannot assert that the social challenges we identified necessarily apply in the same way to organizational structures outside hybrid. However, the challenges of cost/benefit, critical mass, and disruption of social processes exist in hybrid contexts (with some additional twists). And we speculate that social challenges for developers of groupware technologies still exist in various other contexts, potentially with the ‘hybrid twists’. We did observe that the empirical examples were not only linked to the hybrid setup but to the organizational structures (complex subsidiary structures etc.). The use of groupware and the related challenges, therefore, arise not only from the location of the organizational members but also from the individual’s organizational association. For example, a flexible seating policy produces the constraints of organizational members to always think about and put together the technological setup each time they enter the office space, which is not the case if organizational members always are seated in the same place. We observed that organizational members sometimes refer to the groupware technology when collaborating with other organizational members even when being physically present at the office, due to the efficiency of accessing the digital application independent of where cooperative members are located on the current day. This is a complex and interesting challenge for developers of groupware – also taking into account the hardware and devices available.
Challenge 1: Disparity in work and benefit: Groupware always depends on additional work from individuals and/or sub-groups to support the cooperative work, which is not necessarily perceived as beneficial by the individual doing the work.
Challenge 2: Critical mass and Prisoner’s dilemma problems: Groupware must be accessible for and in some sense used by all individuals relevant to or being part of the common field of work.
Challenge 3: Disruptions of social processes: Sub-group dynamics risk violating negotiated social processes, if participants circumvent the groupware technology and instead interact directly with specific actors while neglecting others.
5.3 Organizational challenges
The final set of challenges for groupware developers is the organizational structures for which the groupware application is situated. These challenges concern decision-makers’ choices and processes of investing in groupware, implementing groupware systems into the organization, and finally being able to assess and evaluate whether these groupware systems are supporting the organization in important ways. Groupware technology is known to be considerably more difficult to implement in an organization because it requires convincing multiple stakeholders at multiple levels in the organization [1, 85].
Our empirical data observations focused on work practices and the use of groupware, and we did not follow decision makers’ process of selecting and implementing groupware technologies. However, our interviews and conversations with managers, as well as empirical study of organizational members did provide insights into the considerations for which technologies the organization chooses to invest in, and how the cooperative workers engaged in activities of adopting groupware into their work practices. Implementing groupware will always create reduced productivity for a while, and if successful hopefully reach a higher productivity after a while of use [93]. When new technologies are implemented, it takes time for the organization to fully comprehend and learn how the technology can assist organizational members in supporting their work [94], and often success with new technology relies upon the concrete moment where the technology presents itself as a new relevant opportunity [91]. In our empirical cases, the ‘windows of opportunity’ which was present before our entrance into the field was the pandemic, where organizational members and organizational decision-makers were presented with the constrain of going to the office thus the opportunities of groupware entering the organizations presented a way to solve this challenge. Investing in technologies allowing employees to work remotely was thus implemented and adapted into the organizational structures since 2020 – and now several years later have emerged as everyday technologies within the organization. The technology has been adopted into the work practices. However, as the pandemic ended, and organizational members could return to the office, it became clear that managers’ vision of groupware technology and work practices did not align with how the organizational members acted. Managers continue to struggle to get employees back into the office and thus confirm previous empirical observations [6, 10, 18]. Our empirical data demonstrated the risk of managers selecting groupware technology that potentially can support their vision about work, while the organizational workers choose to adopt the groupware technology to support the way they want to work (in this case independently of being at the office). Interestingly, the concrete groupware system implemented in both cases allowed for both managers’ and employees’ different visions, since the open-ended design could accommodate diverse ways of working. Thus, the groupware system did not constrain the different perceptions of use, and the conflicting agenda was visible in order ways than the lack of use which prior work suggests [46]. Thus, managers’ failure of intuition is not so much related to the actual purchase groupware system, but rather to their ability to imagine use.
Increased challenges of predicting the use of groupware technology in situated organizational practice are introduced with hybrid work since work in this setting is conducted in dynamic contexts where the location of the individual members changes on different days, weeks, and times. The dynamic reconfiguration of the work setup across days challenges both the technical infrastructure and the asymmetries arising due to connecting distributed sub-groups [88]. Predicting the organizational use of groupware technology in hybrid organizational work is thus very difficult (maybe even impossible), and only after an appropriate time after the implementation would it be possible to evaluate whether the technology features are appropriate for the situated practices [63]. Our empirical data hint that the use of groupware in the hybrid setting caused organizational members to not take advantage of the physical spaces within the office during work (invested in during a larger renovation of the office building) nor take advantage of the technological artefacts (large screens and video-equipment etc.) invested in to support collocation in hybrid events, since the effort of connecting the infrastructure of the groupware system to the larger infrastructure of buildings and devices were not viewed as beneficial in comparison with the extra effort of articulation work [43] and relation work [47, 48].
It is an organizational challenge for decision-makers to provide a portfolio of groupware technologies and infrastructures available for organizational workers that support cooperative work conducted in various and dynamic contexts, from different locations, and that which the organizational workers simultaneously adopt in the ways that are successful for the cooperative work.
Challenge 6: Difficulty of evaluation: Groupware is difficult to evaluate outside real-life use practices, compounded by flexible work conditions creating insurmountable obstacles for meaningful, generalizable analysis of evaluation of groupware use.
Challenge 7: Failure of intuition: Manager’s intuition, for selecting the specific portfolio of groupware applications to be implemented in an organization, risks failing, if managers are not aware nor in alignment with employees’ needs for groupware support in relation to different cooperative organizational setups (collocated, hybrid, distributed).
Challenge 8: The adoption process: Groupware requires careful implementation to meaningfully extend the existing infrastructure supporting the common field of work.
6 Conclusions
We revisited Grudin’s Eight Challenges for Groupware Developers, published three decades ago, to explore challenges for developing cooperative work technologies across the past, present, and future. Applying the challenges from 1994 to empirical examples of cooperative work in 2023, we reframed these challenges to reflect contemporary issues in designing groupware technologies supporting work in the future. Analyzing empirical data from two organizations practicing hybrid office work, we identify how groupware enables and constrains cooperative work in order to investigate associated challenges. Examining cooperative teams, the utilization of groupware within teams and across organizations, and the various ways in which groupware technologies are employed, we analyze the challenges that arise. Today, groupware is seamlessly integrated into an organization, becoming an essential part of daily work practices. Grounded in the challenges from 1994, we refined the original phrasings to reflect current work practices (Table 3).
Data sources.
| Empirical cases | InterFin (Org1) | GlobalContent (Org2) |
|---|---|---|
| Interviews/in-situ conversations | 10 (5–70 min) | 7 (10–90 min) |
| Observation | 55 h | 75 h |
| Meetings | 22 | 28 |
| Teams | 2 | 6 |
| People | 70 | 55 |
| Observation notes and rich descriptions | 107 pages | 138 pages |
| Office visit | 12 | 16 |
| Document analysis | 2 | 8 |
| Capturing digital interactions | 9 scenarios | 7 scenarios |
| Documenting office layout | Pictures | Floor plan |
We categorized the challenges into cooperative challenges, reflecting exception handling and accessibility (no. 4, 5), social challenges encompassing disparity in cost/benefit, critical mass, and social processes (no. 1, 2, 3), and organizational challenges including evaluation, intuition, and adoption (no. 6, 7, 8). We find that the social and organizational challenges face additional complexities related to factors such as sub-groups’ locations and organizational association, malleable group configurations, and dynamic contexts, yet the main arguments concerning the challenges from 1994 remain consistent. Differently, our empirical data revealed insights into the cooperative challenges being revised in light of the open-ended design of contemporary groupware, as well as the immediate accessibility and interconnectedness in the portfolio of groupware applications. In the future, developers of groupware technologies are hereof challenged by the ways in which social relations are enabled or constrained by the technology, the motivations for embedding groupware into the organization, and how cooperative engagements with groupware require continuous reconfiguration and rebounding of technologies in practice.
Eight challenges for developers of groupware technology in 2024.
| 1 | Disparity in work and benefit. Groupware always depends on additional work from individuals and/or sub-groups to support the cooperative work, which is not necessarily perceived as beneficial by the individual doing the work |
| 2 | Critical mass and Prisoner’s dilemma problems. Groupware must be accessible for and in some sense used by all individuals relevant to or being part of the common field of work |
| 3 | Disruption of social processes. Sub-group dynamics risk violating negotiated social processes, if participants circumvent the groupware technology and instead interact directly with specific actors while neglecting others |
| 4 | Emergent exception handling. For groupware flexibility to facilitate a wide range of activities (e.g., exception handling and improvisation) requires participants to reconfigure the groupware over time to accommodate emergent use reducing exception handling |
| 5 | Exaggerated accessibility. Groupware supporting multiple, parallel, and different usages of applications and devices simultaneously, requires participants in creating boundaries in technologies in practice |
| 6 | Difficulty of evaluation. Groupware is difficult to evaluate outside real-life use practices, compounded by flexible work conditions creating insurmountable obstacles for meaningful, generalizable analysis of evaluation of groupware use |
| 7 | Failure of intuition. Manager’s intuition, for selecting the specific portfolio of groupware applications to be implemented in an organization, risks failing, if managers are not aware nor in alignment with employees’ needs for groupware support in relation to different cooperative organizational setups (collocated, hybrid, distributed) |
| 8 | The adoption process. Groupware requires careful implementation to meaningfully extend the existing infrastructure supporting the common field of work |
Funding source: Innovationsfonden
Award Identifier / Grant number: 9142-00001B
About the authors
Melanie Duckert is PhD fellow in Computer Science affiliated with the Digital Research Center Denmark (DIREC). Her research focuses on the future of work in the field of Computer Supported Cooperative Work (CSCW), with a particular emphasis on hybrid cooperative work practices. She develops theoretical frameworks conceptualizing the dynamics of hybrid work environments, by exploring the intersections of technology, organization, and human behavior to address contemporary challenges in collaborative work settings.
Professor Pernille Bjørn specializes in Computer Supported Cooperative Work at the Department of Computer Science, University of Copenhagen, Denmark. Her research domains include distributed collaboration, healthcare IT, tech Entrepreneurship, and Equity in Computing. Currently, she researches Hybrid Collaboration from a fundamental theoretical perspective while exploring new contemporary methods involving art in CSCW research.
-
Research ethics: The work has been conducted in line with the national statement on research code of conduct.
-
Author contributions: The authors have accepted responsibility for the entire content of this manuscript and approved its submission.
-
Competing interests: The authors state no conflict of interest.
-
Research funding: This work is supported by the Innovation Fund Denmark for the project DIREC (9142-00001B).
-
Data availability: Not applicable.
References
1. Grudin, J. Groupware and social dynamics: eight challenges for developers. Commun. ACM 1994, 37, 92–105. https://doi.org/10.1145/175222.175230.Search in Google Scholar
2. Aksoy, C. G., Barrero, J. M., Bloom, N., Davis, S. J., Dolls, M., Zarate, P. Working from home around the world. In Working Paper Series; National Bureau of Economic Research, 2022.10.3386/w30446Search in Google Scholar
3. Liu, Z., Van Egdom, D., Flin, R., Spitzmueller, C., Adepoju, O., Krishnamoorti, R. I don’t want to go back: examining the return to physical workspaces during COVID-19. J. Occup. Environ. Med. 2020, 62, 953–958. https://doi.org/10.1097/JOM.0000000000002012.Search in Google Scholar PubMed
4. Murphy, K. R. Life after COVID-19: what if we never go back to the office? Ir. J. Manag. 2021, 40, 78–85. https://doi.org/10.2478/ijm-2021-0007.Search in Google Scholar
5. Boland, B., Smet, A. D., Palter, R., Sanghvi, A. Reimagining the Office and Work Life After COVID-19; McKinsey & Company: New York, NY, USA, 2020.Search in Google Scholar
6. Busboom, J., Boulus-Rødje, N. Planning for hybrid cooperation – a design driven exploration. [Online] 2023. https://dl.eusset.eu/handle/20.500.12015/4680 (accessed Nov 09, 2023).Search in Google Scholar
7. Cheon, E., Zaga, C., Lee, H. R., Lupetti, M. L., Dombrowski, L., Jung, M. F. Human-machine partnerships in the future of work: exploring the role of emerging technologies in future workplaces. In Companion Publication of the 2021 Conference on Computer Supported Cooperative Work and Social Computing, in CSCW ‘21; Association for Computing Machinery: New York, NY, USA, 2021; pp. 323–326.10.1145/3462204.3481726Search in Google Scholar
8. Duckert, M., Hoggan, E., Barkhuus, L., Bjørn, P., Boulus-Rødje, N., Bødker, S., Møller, N. H., Shklovski, I. Work of the future. In Adjunct Proceedings of the 2022 Nordic Human-Computer Interaction Conference, in NordiCHI ‘22; Association for Computing Machinery: New York, NY, USA, 2022; pp. 1–4.10.1145/3547522.3547707Search in Google Scholar
9. Helmold, M. New office concepts in the post COVID-19 times. In New Work, Transformational and Virtual Leadership: Lessons from COVID-19 and Other Crises, in Management for Professionals; Helmold, M., Ed. Springer International Publishing: Cham, 2021; pp. 79–89.10.1007/978-3-030-63315-8_7Search in Google Scholar
10. Smite, D., Christensen, E., Tell, P., Russo, D. The future workplace: characterizing the spectrum of hybrid work arrangements for software teams. IEEE Software 2023, 40, 34–41. https://doi.org/10.1109/MS.2022.3230289.Search in Google Scholar
11. Cook, I. Who is driving the great resignation? Harv. Bus. Rev. 2021. https://hbr.org/2021/09/who-is-driving-the-great-resignation.Search in Google Scholar
12. Hite, L. M., McDonald, K. S. Careers after COVID-19: challenges and changes. Hum. Resour. Dev. Int. 2020, 23, 427–437. https://doi.org/10.1080/13678868.2020.1779576.Search in Google Scholar
13. Sull, D., Sull, C., Zweig, B. Toxic culture is driving the great resignation. MIT Sloan Manag. Rev. 2022. https://sloanreview.mit.edu/article/toxic-culture-is-driving-the-great-resignation/.Search in Google Scholar
14. Ferreira, R., Pereira, R., Bianchi, I. S., da Silva, M. M. Decision factors for remote work adoption: advantages, disadvantages, driving forces and challenges. JOItmC 2021, 7, 70. https://doi.org/10.3390/joitmc7010070.Search in Google Scholar
15. Neumayr, T., Saatci, B., Rintel, S., Klokmose, C. N., Augstein, M. What was hybrid? A systematic review of hybrid collaboration and meetings research. arXiv, 2022; https://doi.org/10.48550/arXiv.2111.06172.Search in Google Scholar
16. Duckert, M., Barkhuus, L., Bjørn, P. Collocated distance: a fundamental challenge for the design of hybrid work technologies. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, in CHI ‘23; Association for Computing Machinery: New York, NY, USA, 2023; pp. 1–16.10.1145/3544548.3580899Search in Google Scholar
17. Neumayr, T., Jetter, H.-C., Augstein, M., Friedl, J., Luger, T. Domino: a descriptive framework for hybrid collaboration and coupling styles in partially distributed teams. Proc. ACM Hum.-Comput. Interact. 2018, 2, 128:1–128:24. https://doi.org/10.1145/3274397.Search in Google Scholar
18. Saatçi, B., Akyüz, K., Rintel, S., Klokmose, C. N. (Re)Configuring hybrid meetings: moving from user-centered design to meeting-centered design. Comput. Support. Coop. Work 2020, 29, 769–794. https://doi.org/10.1007/s10606-020-09385-x.Search in Google Scholar PubMed PubMed Central
19. Grønbæk, J. E., Saatçi, B., Griggio, C. F., Klokmose, C. N. MirrorBlender: supporting hybrid meetings with a malleable video-conferencing system. In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems, in CHI ‘21; Association for Computing Machinery: New York, NY, USA, 2021.10.1145/3411764.3445698Search in Google Scholar
20. Tang, J. C., Inkpen, K., Junuzovic, S., Mallari, K., Wilson, A. D., Rintel, S., Cupala, S., Carbary, T., Sellen, A., Buxton, W. A. S. Perspectives: creating inclusive and equitable hybrid meeting experiences. Proc. ACM Hum.-Comput. Interact. 2023, 7, 351:1-351:25; https://doi.org/10.1145/3610200.Search in Google Scholar
21. Mu, Q., Borowski, M., Grønbæk, J. E., Bødker, S., Hoggan, E. Whispering through walls: towards inclusive backchannel communication in hybrid meetings. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI ‘24), 2024; p. 16.10.1145/3613904.3642419Search in Google Scholar
22. Alaqra, A. S., Kitkowska, A. Impact of intrinsic factors and COVID-19 pandemic on the use of technology. In Extended Abstracts of the 2021 CHI Conference on Human Factors in Computing Systems; ACM: Yokohama, Japan, 2021; pp. 1–7.10.1145/3411763.3451669Search in Google Scholar
23. Tang, J., Inkpen, K., Luff, P., Fitzpatrick, G., Yamashita, N., Kim, J. Living through a crisis: how COVID-19 has transformed the way we work, live, and research. Comput. Support. Coop. Work 2023, 32, 211–213. https://doi.org/10.1007/s10606-022-09452-5.Search in Google Scholar PubMed PubMed Central
24. Flügge, A. A., Møller, N. H. The role of physical cues in co-located and remote casework. Comput. Support. Coop. Work 2023, 32, 275–312. https://doi.org/10.1007/s10606-022-09449-0.Search in Google Scholar PubMed PubMed Central
25. Bannon, L. Perspectives on CSCW: from HCI and CMC to CSCW. In Proceedings of EWHCI’92, East – West International Conference on Human-Computer Interaction: St. Petersburg, Russia, 1992; pp. 148–158.Search in Google Scholar
26. Bannon, L. J., Schmidt, K. CSCW: four characters in search of a context. [Online] 1989. https://dl.eusset.eu/items/6d7cbaa8-e9e5-4cb8-84d0-5a016a5083bc (accessed Oct 27, 2023).Search in Google Scholar
27. Mark, G., Abrams, S., Nassif, N. Group-to-group distance collaboration: examining the “space between”. In ECSCW 2003; Kuutti, K., Karsten, E. H., Fitzpatrick, G., Dourish, P., Schmidt, K., Eds. Springer Netherlands: Dordrecht, 2003; pp. 99–118.10.1007/978-94-010-0068-0_6Search in Google Scholar
28. Schmidt, K., Bannon, L. Taking CSCW seriously supporting articulation work. Comput. Support. Coop. Work 1992, 1, 7–40. https://doi.org/10.1007/bf00752449.Search in Google Scholar
29. Orlikowski, W. J. Learning from notes: organizational issues in groupware implementation. In Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work, in CSCW ‘92; Association for Computing Machinery: New York, NY, USA, 1992; pp. 362–369.10.1145/143457.143549Search in Google Scholar
30. Dourish, P., Bellotti, V. Awareness and coordination in shared workspaces. In Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work – CSCW ‘92; ACM Press: Toronto, Ontario, Canada, 1992; pp. 107–114.10.1145/143457.143468Search in Google Scholar
31. Ackerman, M. S., Dachtera, J., Pipek, V., Wulf, V. Sharing knowledge and expertise: the CSCW view of knowledge management. Comput. Support. Coop. Work 2013, 22, 531–573. https://doi.org/10.1007/s10606-013-9192-8.Search in Google Scholar
32. Bjørn, P., Østerlund, C. Sociomaterial-Design: Bounding Technologies in Practice; Springer International Publishing: Switzerland, 2014.10.1007/978-3-319-12607-4Search in Google Scholar
33. Ciolfi, L., Lewkowicz, M., Schmidt, K. Computer-supported cooperative work. In Handbook of Human Computer Interaction; Vanderdonckt, J., Palanque, P., Winckler, M., Eds. Springer International Publishing: Cham, 2023; pp. 1–26.10.1007/978-3-319-27648-9_30-1Search in Google Scholar
34. Lee, C. P., Paine, D. From the matrix to a model of coordinated action (MoCA): a conceptual framework of and for CSCW. In Proceedings of the 18th ACM Conference on Computer Supported Cooperative Work & Social Computing; ACM: Vancouver BC Canada, 2015; pp. 179–194.10.1145/2675133.2675161Search in Google Scholar
35. Schmidt, K., Bannon, L. Constructing CSCW: the first quarter century. Comput. Support. Coop. Work 2013, 22, 345–372. https://doi.org/10.1007/s10606-013-9193-7.Search in Google Scholar
36. Bjørn, P., Esbensen, M., Jensen, R. E., Matthiesen, S. Does distance still matter? Revisiting the CSCW fundamentals on distributed collaboration. ACM Trans. Comput. Hum. Interact. 2014, 21, 27. https://doi.org/10.1145/2670534.Search in Google Scholar
37. Bjørn, P., Boulus-Rødje, N. Infrastructural inaccessibility: tech entrepreneurs in occupied Palestine. ACM Trans. Comput. Hum. Interact. 2018, 25, 26:1–26:31. https://doi.org/10.1145/3219777.Search in Google Scholar
38. Boulus-Rødje, N., Bjørn, P., Ghazawneh, A. “It’s about business not politics”: software development between Palestinians and Israelis. In ECSCW 2015: Proceedings of the 14th European Conference on Computer Supported Cooperative Work, 19–23 September 2015, Oslo, Norway; Boulus-Rødje, N., Ellingsen, G., Bratteteig, T., Aanestad, M., Bjørn, P., Eds. Springer International Publishing: Cham, 2015; pp. 43–61.10.1007/978-3-319-20499-4_3Search in Google Scholar
39. Matthiesen, S., Bjørn, P., Petersen, L. M. “Figure out how to code with the hands of others”: recognizing cultural blind spots in global software development. In Proceedings of the 17th ACM Conference on Computer Supported Cooperative Work & Social Computing, in CSCW ‘14; Association for Computing Machinery: New York, NY, USA, 2014; pp. 1107–1119.10.1145/2531602.2531612Search in Google Scholar
40. Bannon, L. J. Understanding common information spaces in CSCW, Position paper for Workshop on Common Information Spaces, 2000.Search in Google Scholar
41. Bjørn, P., Bardram, J., Avram, G., Bannon, L., Boden, A., Redmiles, D., de Souza, C., Wulf, V. Global software development in a CSCW perspective. In Proceedings of the Companion Publication of the 17th ACM Conference on Computer Supported Cooperative Work & Social Computing, in CSCW Companion ‘14; Association for Computing Machinery: New York, NY, USA, 2014; pp. 301–304.10.1145/2556420.2558863Search in Google Scholar
42. Lipset, S. Social Organization of Medical Work; Routledge: New York, 2017.Search in Google Scholar
43. Strauss, A. The articulation of project work: an organizational process. Socio. Q. 1988, 29, 163–178. https://doi.org/10.1111/j.1533-8525.1988.tb01249.x.Search in Google Scholar
44. Bjørn, P., Søderberg, A.-M., Krishna, S. Translocality in global software development: the dark side of global agile. Hum. Comput. Interact. 2017, 34, 174–203. https://doi.org/10.1080/07370024.2017.1398092.Search in Google Scholar
45. Heeks, R., Krishna, S., Nicholson, B., Sahay, S. Synching or sinking: global software outsourcing relationships. Software IEEE 2001, 18, 54–60. https://doi.org/10.1109/52.914744.Search in Google Scholar
46. Bjørn, P., Balka, E. Health care categories have politics too: unpacking the managerial agendas of electronic triage systems. In ECSCW 2007; Bannon, L. J., Wagner, I., Gutwin, C., Harper, R. H. R., Schmidt, K., Eds. Springer: London, 2007; pp. 371–390.10.1007/978-1-84800-031-5_20Search in Google Scholar
47. Bjørn, P., Christensen, L. R. Relation work: creating socio-technical connections in global engineering. In ECSCW 2011: Proceedings of the 12th European Conference on Computer Supported Cooperative Work, 24–28 September 2011, Aarhus Denmark, 2011; pp. 133–152.10.1007/978-0-85729-913-0_8Search in Google Scholar
48. Bjørn, P., Christensen, L. R. Relation work in collocated and distributed collaboration. In COOP 2014 – Proceedings of the 11th International Conference on the Design of Cooperative Systems, 27–30 May 2014, Nice (France); Springer International Publishing: Cham, 2014; pp. 87–101.10.1007/978-3-319-06498-7_6Search in Google Scholar
49. Boden, A., Nett, B., Wulf, V. Trust and social capital: revisiting an offshoring failure story of a small German software company. In ECSCW 2009; Wagner, I., Tellioğlu, H., Balka, E., Simone, C., Ciolfi, L., Eds. Springer London: London, 2009; pp. 123–142.10.1007/978-1-84882-854-4_7Search in Google Scholar
50. Akbar, F., Bayraktaroglu, A., Buddharaju, P., Da, D., Silva, C., Gao, G., Grover, T., Gutierrez-Osuna, R., Jones, N., Mark, G., Pavlidis, I., Storer, K., Wang, Z., Wesley, A., Zaman, S. Email makes you sweat: examining email inter-ruptions and stress with thermal imaging. In ACM Conference on Human Factors in Computing Systems (CHI) 2019, https://doi.org/10.1145/3290605.3300898.Search in Google Scholar
51. Matthiesen, S., Bjørn, P., Trillingsgaard, C. Attending to implicit bias as a way to move beyond negative stereotyping in GSE. In Proceedings of the 15th International Conference on Global Software Engineering, in ICGSE ‘20; Association for Computing Machinery: New York, NY, USA, 2020; pp. 22–32.10.1145/3372787.3390432Search in Google Scholar
52. Hecht, B., Terveen, L., Starbird, K., Shneiderman, B., Golbeck, J. The 2016 US election and HCI: towards a research agenda. In Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing Systems (CHI EA ’17) 2017, pp. 1307–1311; https://doi.org/10.1145/3027063.3051140.Search in Google Scholar
53. Starbird, K. Examining the alternative media ecosystem through the production of alternative narratives of mass shooting events on twitter. In Proceedings of the International AAAI Conference on Web and Social Media, 2017; pp. 230–239.10.1609/icwsm.v11i1.14878Search in Google Scholar
54. Rönnberg, E., Larsson, T. Automating the self-scheduling process of nurses in Swedish healthcare: a pilot study. Health Care Manag. Sci. 2010, 13, 35–53. https://doi.org/10.1007/s10729-009-9107-x.Search in Google Scholar PubMed
55. Gerson, E. M. Reach, bracket, and the limits of rationalized coordination: some challenges for CSCW. In Resources, Co-Evolution and Artifacts, in Computer Supported Cooperative Work; Springer London: London, 2008; pp. 193–220.10.1007/978-1-84628-901-9_8Search in Google Scholar
56. Gerson, E. M., Star, S. L. Analyzing due process in the workplace. ACM Trans. Inf. Syst. 1986, 4, 257–270. https://doi.org/10.1145/214427.214431.Search in Google Scholar
57. Mesman, J. Disturbing observations as a basis for collaborative research. Sci. Cult. 2007, 16, 281–295. https://doi.org/10.1080/09505430701568685.Search in Google Scholar
58. Randall, D., Harper, R., Rouncefield, M. Fieldwork for design. In Computer Supported Cooperative Work; Springer London: London, 2007.10.1007/978-1-84628-768-8Search in Google Scholar
59. Schmidt, K. Of maps and scripts: the status of formal constructs in cooperative work [1999]. ACM International Conference on Supporting Group Work (GROUP ’97) 1999, 138–147.10.1145/266838.266887Search in Google Scholar
60. Cramton, C. D., Hinds, P. J. Subgroup dynamics in internationally distributed teams: ethnocentrism or cross-national learning? Res. Organ. Behav. 2004, 26, 231–263. https://doi.org/10.1016/s0191-3085(04)26006-3.Search in Google Scholar
61. Suchman, L. Plans and Situated Actions: The Problem of Human-Machine Communication; Cambridge University Press: Cambridge, England, 1987.Search in Google Scholar
62. Suchman, L. Human-Machine Reconfigurations: Plans and Situated Actions, in Learning in Doing: Social, Cognitive and Computational Perspectives, 2nd ed.; Cambridge University Press: Cambridge, 2006.10.1017/CBO9780511808418Search in Google Scholar
63. Suchman, L. A. Office procedure as practical action: models of work and system design. ACM Trans. Inf. Syst. 1983, 1, 320–328. https://doi.org/10.1145/357442.357445.Search in Google Scholar
64. Suchman, L., Wynn, E. Procedures and problems in the office. Inf. Technol. People 1984, 2, 133–154. https://doi.org/10.1108/eb022630.Search in Google Scholar
65. Bjørn, P., Rødje, K. Triage drift: a workplace study in a pediatric emergency department. Comput. Support. Coop. Work 2018, 17, 25. https://doi.org/10.1007/s10606-008-9079-2.Search in Google Scholar
66. Zuiderent-Jerak, T. Preventing implementation: exploring interventions with standardization in healthcare. Sci. Cult. 2007, 16, 311–329. https://doi.org/10.1080/09505430701568719.Search in Google Scholar
67. Clarke, K., Hughes, J., Rouncefield, M., Hemmings, T. When a Bed is not a Bed: Calculation and Calculability in Complex Organisational Settings. In Trust in Technology: A Socio-Technical Perspective. Computer Supported Cooperative Work, Vol. XXXVI; Clarke K., Hardstone G., Rouncefield M., Sommerville I., Eds. Springer, Dordrecht, 2006, 36, pp. 21–38. https://doi.org/10.1007/1-4020-4258-2_2.Search in Google Scholar
68. Heath, C., Luff, P. Collaboration and control crisis management and multimedia technology in London underground line control rooms. Comput. Support. Coop. Work 1992, 1, 69–94. https://doi.org/10.1007/BF00752451.Search in Google Scholar
69. Schmidt, K. The problem with ‘awareness’: introductory remarks on ‘awareness in CSCW’. Comput. Support. Coop. Work 2002, 11, 285–298. https://doi.org/10.1023/A:1021272909573.10.1023/A:1021272909573Search in Google Scholar
70. Gutwin, C., Penner, R., Schneider, K. Group awareness in distributed software development. In Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work, in CSCW ‘04; Association for Computing Machinery: New York, NY, USA, 2004; pp. 72–81.10.1145/1031607.1031621Search in Google Scholar
71. Gross, T. Supporting effortless coordination: 25 years of awareness research. Comput. Support. Coop. Work 2013, 22, 425–474. https://doi.org/10.1007/s10606-013-9190-x.Search in Google Scholar
72. Bardou, M., Letondal, C, Imbert, J, Causse, M, Bidegaimberry, M, Dubus, R, Marcon, C. Redesigning systems for single-pilot operations: the mutual awareness problem for remote crews. [Online] 2022. https://dl.eusset.eu/handle/20.500.12015/4377 (accessed Dec 06, 2023).Search in Google Scholar
73. Hanseth, O., Jacucci, E., Grisot, M., Aanestad, M. Reflexive standardization: side effects and complexity in standard making. MIS Q. 2006, 30, 563–581. https://doi.org/10.2307/25148773.Search in Google Scholar
74. Mørck, P., Langhoff, T. O., Christophersen, M., Møller, A. K., Bjørn, P. Variations in oncology consultations: how dictation allows variations to be documented in standardized ways. [Online] 2018. https://dl.eusset.eu/items/d18afb85-8614-48ac-871c-d75145cecbbe (accessed Aug 15, 2023).Search in Google Scholar
75. Ellingsen, G., Monteiro, E. A patchwork planet integration and cooperation in hospitals. Comput. Support. Coop. Work 2003, 12, 71–95. https://doi.org/10.1023/A:1022469522932.10.1023/A:1022469522932Search in Google Scholar
76. Ellingsen, G., Munkvold, G. Infrastructural arrangements for integrated care: implementing an electronic nursing plan in a psychogeriatric ward. Int. J. Integrated Care 2007, 7, e13. https://doi.org/10.5334/ijic.190.Search in Google Scholar PubMed PubMed Central
77. Fitzpatrick, G., Ellingsen, G. A review of 25 years of CSCW research in healthcare: contributions, challenges and future agendas. Comput. Support. Coop. Work 2013, 22, 609–665. https://doi.org/10.1007/s10606-012-9168-0.Search in Google Scholar
78. Bjørn, P., Burgoyne, S., Crompton, V., MacDonald, T., Pickering, B., Munro, S. Boundary factors and contextual contingencies: configuring electronic templates for healthcare professionals. Eur. J. Inf. Syst. 2009, 18, 428–441. https://doi.org/10.1057/ejis.2009.34.Search in Google Scholar
79. Ellingsen, G., Monteiro, E., Røed, K. Integration as interdependent workaround. Int. J. Med. Inf. 2013, 82, e161–e169. https://doi.org/10.1016/j.ijmedinf.2012.09.004.Search in Google Scholar PubMed
80. Kobayashi, M., Fussell, S., Xiao, Y., Seagull, F. J. Work coordination, workflow, and workarounds in a medical context, presented at the CHI Extended Abstracts, 2005; pp. 1561–1564.10.1145/1056808.1056966Search in Google Scholar
81. Boulus, N., Bjorn, P. A cross-case analysis of technology-in-use practices: EPR-adaptation in Canada and Norway. Int. J. Med. Inf. 2010, 79, e97–e108. https://doi.org/10.1016/j.ijmedinf.2008.06.008.Search in Google Scholar PubMed
82. Hanseth, O., Monteiro, E., Hatling, M. Developing information infrastructure: the tension between standardization and flexibility. Sci. Technol. Hum. Val. 1996, 21, 407–426. https://doi.org/10.1177/016224399602100402.Search in Google Scholar
83. Mazmanian, M., Cohn, M., Dourish, P. Dynamic reconfiguration in planetary exploration: a sociomaterial ethnography. MIS Q. 2014, 38, 831–848. https://doi.org/10.25300/MISQ/2014/38.3.09.Search in Google Scholar
84. Møller, N., Bjørn, P. In due time: decision-making in architectural design of hospitals. In COOP 2016: Proceedings of the 12th International Conference on the Design of Cooperative Systems 2016, pp. 191–206; http://doi.org/10.1007/978-3-319-33464-6_12.10.1007/978-3-319-33464-6_12Search in Google Scholar
85. Orlikowski, W. The duality of technology: rethinking the concept of technology in organizations. Organ. Sci. 1992, 3, 398–427. https://doi.org/10.1287/orsc.3.3.398.Search in Google Scholar
86. Langhoff, T. O., Amstrup, M. H., Mørck, P., Bjørn, P. Infrastructures for healthcare: from synergy to reverse synergy. Health Inf. J. 2018, 24, 43–53. https://doi.org/10.1177/1460458216654288.Search in Google Scholar PubMed
87. Matthiesen, S., Bjørn, P. When distribution of tasks and skills are fundamentally problematic: a failure story from global software outsourcing. Proc. ACM Hum.-Comput. Interact. 2017, 1, 74:1–74:16. https://doi.org/10.1145/3139336.Search in Google Scholar
88. Saatçi, B., Rädle, R., Rintel, S., O’Hara, K., Klokmose, C. Hybrid meetings in the modern workplace: stories of success and failure. In: Nakanishi H., Egi H., Chounta I. A., Takada H., Ichimura S., Hoppe U. (eds) Collaboration Technologies and Social Computing. CRIWG+CollabTech 2019. Lecture Notes in Computer Science 2019, Vol. XIMDCLXXVII, Springer: Cham, 2019, pp. 45–61. https://doi.org/10.1007/978-3-030-28011-6_4.Search in Google Scholar
89. Davidson, E. A technological frames perspective on information technology and organizational change. J. Appl. Behav. Sci. 2006, 42, 23–39. https://doi.org/10.1177/0021886305285126.Search in Google Scholar
90. Orlikowski, W. Improvising organizational transformation over time: a situated change perspective. Inf. Syst. Res. 1996, 7, 63–92. https://doi.org/10.1287/isre.7.1.63.Search in Google Scholar
91. Tyre, M. J., Orlikowski, W. J. Windows of opportunity: temporal patterns of technological adaptation in organizations. Organ. Sci. 1994, 5, 98–118. https://doi.org/10.1287/orsc.5.1.98.Search in Google Scholar
92. Grudin, J. Why CSCW applications fail: problems in the design and evaluation of organizational interfaces. In Proceedings of the 1988 ACM Conference on Computer-Supported Cooperative Work – CSCW ‘88; ACM Press: Portland, Oregon, United States, 1988; pp. 85–93.10.1145/62266.62273Search in Google Scholar
93. Grudin, J., Grinter, R. Ethnography and design. Comput. Support. Coop. Work Int J. 1995, 3, 55–59. https://doi.org/10.1007/bf01305846.Search in Google Scholar
94. Bjørn, P., Scupola, A., Fitzgerald, B. Expanding technological frames towards mediated collaboration. Scand. J. Inf. Sys. 2006, 18, 29–68.Search in Google Scholar
95. Bjørn, P., Fitzgerald, B., Scupola, A. The role of social awareness in technology acceptance of groupware in virtual learning teams. In Proceedings of the 26th Information Systems Research Seminar in Scandinavia 2003. https://api.semanticscholar.org/CorpusID:18346354.Search in Google Scholar
96. Bjørn, P., Scupola, A. Groupware integration in virtual learning teams: a qualitative analysis based on the TAM-model, presented at the International Federation for Information Processing Digital Library; IT Innovation for Adaptability and Competitiveness, 2004.Search in Google Scholar
97. Davis, F. Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Q 1989, 13, 319–340; https://doi.org/10.2307/249008.Search in Google Scholar
98. Bjørn, P. Re-negotiating protocols: a way to integrate groupware in collaborative learning settings. In ECIS, New Paradigms in Organizations, Markets and Society, Proceedings of the 11th European Conference on Information System, Napoli. [Online] 2003. https://researchr.org/publication/Rasmussen03%3A1 (accessed Sep 11, 2022).Search in Google Scholar
99. Bjørn, P., Busboom, J., Duckert, M., Bødker, S., Shklovski, I., Hoggan, E., Dunn, K., Mu, Q., Barkhuus, L., Boulus-Rødje, N. Achieving symmetry in synchronous interaction in hybrid work is impossible. ACM Trans. Comput.-Hum. Interact. 2024, http://doi.org/10.1145/3648617.10.1145/3648617Search in Google Scholar
100. Blomberg, J., Karasti, H. Reflections on 25 years of ethnography in CSCW. Comput. Support. Coop. Work 2013, 22, 373–423. https://doi.org/10.1007/s10606-012-9183-1.Search in Google Scholar
101. de Souza Santos, R. E., Ralph, P. A grounded theory of coordination in remote-first and hybrid software teams. In Proceedings of the 44th International Conference on Software Engineering, in ICSE ‘22; Association for Computing Machinery: New York, NY, USA, 2022; pp. 25–35.10.1145/3510003.3510105Search in Google Scholar
102. Jordan, B. Blurring boundaries: the “real” and the “virtual” in hybrid spaces. Hum. Organ. 2009, 68, 181–193. https://doi.org/10.17730/humo.68.2.7x4406g270801284.Search in Google Scholar
103. Ruhleder, K. The virtual ethnographer: fieldwork in distributed electronic environments. Field Methods 2000, 12, 3–17. https://doi.org/10.1177/1525822X0001200101.Search in Google Scholar
104. Rosenberg, D. Three steps to ethnography: a discussion of interdisciplinary contributions. AI Soc. 2001, 15, 295–315. https://doi.org/10.1007/BF01206112.Search in Google Scholar
105. Braun, V., Clarke, V., Hayfield, N., Terry, G. Thematic analysis. In Handbook of Research Methods in Health Social Sciences; Liamputtong, P., Ed. Springer: Singapore, 2019; pp. 843–860.10.1007/978-981-10-5251-4_103Search in Google Scholar
106. Lucero, A. Using affinity diagrams to evaluate interactive prototypes. In Human-Computer Interaction – INTERACT 2015, in Lecture Notes in Computer Science; Abascal, J., Barbosa, S., Fetter, M., Gross, T., Palanque, P., Winckler, M., Eds. Springer International Publishing: Cham, 2015; pp. 231–248.10.1007/978-3-319-22668-2_19Search in Google Scholar
© 2024 the author(s), published by De Gruyter, Berlin/Boston
This work is licensed under the Creative Commons Attribution 4.0 International License.
