Caseworkers’ participation in procurement: Infrastructuring Child Welfare Services in Norway

Abstract

Procurement is a widely adopted collaborative approach for acquiring new systems in the public sector. It exemplifies a situation in which the early stages of digital system design define the boundaries and constraints of a new system that must be specified in the tender document (i.e., a binding offer). Researchers and government officials have long recognized the benefit of end-user participation in system design. Given the central role of the pre-tender phases in procurement processes, however, there is a need to better understand what affects user participation in such early stages. In this paper, we research a procurement process in municipal Child Welfare Services in Norway. We focus on caseworkers' participation in procuring a future case management system. We build on the concept of participatory infrastructuring to characterize how the meaning of participation was shaped through three overarching participatory infrastructuring practices of decision-making within a rigid procurement process: (i) scaling up the project, (ii) negotiating participation in meetings with potential suppliers and in tender documents, and (iii) positioning caseworkers as subject experts. The analysis of these practices reveals that the definition of user needs in the tender documentation and the creation of knotworks define both the boundary conditions and the modalities of participation. We contribute to the conversation on participatory infrastructuring in Computer-Supported Cooperative Work by discussing how participatory infrastructuring provides a conceptual understanding of participation in the context of municipal systems procurement.

1 Introduction

The early stages of digital systems development have been found to be crucial for creating the conditions for maintaining active user participation. Decisions made in the early phases define the boundary conditions for future user involvement possibilities (Svanæs and Gulliksen, 2008) as the systems begin to entangle with existing ones (Parmiggiani et al., 2015). The most expensive mistakes and shortcomings in system development are those made in the early phases, focusing on analysis and design (Bødker and Grønbæk, 1991). Additionally, early decisions regarding who is involved in developing a new system impact, andare often detrimental to, the quality of use (Bratteteig and Wagner, 2016). This tendency is particularly visible in the public sector, where innovation typically happens through procurement processes that must accommodate upfront bureaucratic procedures, legal frameworks, political agendas, cost-benefit analyses, and citizens’ and officials’ uneven digital literacy (Aanestad et al., 2017; Mikalsen et al., 2018; Shapiro, 2005).

User participation is generally considered important in digital public service development (Anthopoulos et al., 2007; Karlsson et al., 2012; Shapiro, 2005). However, active user inclusion and participation in the design of new systems has proved challenging, resulting in participatory design (PD) approaches not being widely adopted in the public sector (Saad-Sulonen et al., 2020). Computer-Supported Cooperative Work (CSCW) has investigated collaborative practices promoting various forms of user participation in public settings, such as consultation processes (Weise and Chiasson, 2020), educational contexts (Bødker, 2017), and the prevention of social isolation in rural settings (Hayes et al., 2021). These studies show that active user involvement and participation in system and service development are difficult to maintain beyond the initial phases. However, questions remain regarding what participation entails, who participates in what, and how (Andersen et al., 2015; Saad-Sulonen et al., 2018) in the context of procurement in the public sector, which is still characterized by a rigid division between system requirement specification and actual design.

Procurement is the acquisition of supplies or services through purchase or leasing through a tender agreement (Lloyd and McCue, 2004). Research within CSCW has long demonstrated that the participation of stakeholders in general, and future users specifically, has significant positive effects on the quality of systems acquired and developed through procurement (Bowers, 1994; Møller et al., 2020; Pollock and Williams, 2010). Meanwhile, public procurement is heavily regulated to ensure fair competition. Important decisions are typically made early on due to the constraints associated with external sources, e.g., tenders and contracts, the internal structure of supplier and customer organizations, and political interests. These constraints amplify the tension between the need to specify systems requirements upfront and a lack of knowledge about what new systems should look like (Langseth and Similä, 2021; Mikalsen and Farshchian, 2020). As this tension is solved in practice, user involvement tends to be reduced or hindered, resulting in users being understood as merely a source for testing system requirements. More research is needed to understand how early-stage decisions impact user participation in public procurement processes and in what ways - if at all - user participation is possible. Therefore, we ask: what affects participation in early-stage procurement processes in the public sector?

We answer this question by identifying opportunities for caseworkers to participate in the procurement of a new digital infrastructure for delivering services to citizens at the municipal level in Child Welfare Services (CWS) (DigiBarnevern, or DigiChildProtection in English). We unpack caseworkers' participation in the work of writing the tender report in the process of procuring a new case management system. In addition to caseworkers, the stakeholders in the DigiBarnevern-project consist of municipal officials and citizens involved in ongoing CWS cases. The project aims to develop systems that will facilitate better relationships between caseworkers and citizens, allowing the latter to have more influence over the management of their cases. We chose the caseworkers’ perspective because they have been found to have precious professional expertise acquired through their daily work practices that should be leveraged to develop better digital welfare systems (Boulus-Rødje, 2018). Therefore, caseworkers’ role as users and co-designers in collaboration with IT professionals continues to interest the CSCW community. As a separate system used by citizens will be developed internally and not procured, its development and citizen participation will be the focus of a later paper. However, citizen participation is mentioned here as it came up in discussions related to caseworkers’ needs.

We adopt the concept of infrastructuring as a lens to describe system development that overcomes traditional boundaries between initial design, implementation, and use, toward a more fluid understanding of the way heterogeneous stakeholders shape the system over time and across locales building on existing technologies and competencies (Parmiggiani et al., 2015; Star and Bowker, 2002). Against this backdrop, though the case is not a PD project - in that those driving the development are not rooted in the PD tradition - we take inspiration from PD as a lens to uncover challenges and practices with the goal of framing caseworkers’ participation in the procurement of a case management system for municipal CWS. From this perspective, we view participation broadly as the power to shape action in decision-making practices (cf. Bratteteig and Wagner, 2016). We find that the participation of CWS caseworkers is a function of how they are recruited in positions of decision-making and influence, the mapping of end-users’ needs, and how users’ needs are translated and negotiated when writing requirements in the tender report. Through this process, the tender report becomes a critical artifact that defines users’ needs and how participation will be framed and organized in the subsequent development in collaboration with the supplier.

This study contributes to the CSCW literature in two ways. First, at the empirical level, we analyze how caseworkers’ interests are addressed along three sets of recurring practices: (1) managing project scalability—deciding a project’s content and limitations; (2) negotiating participation—how caseworkers will participate; and (3) positioning CWS experts in key positions in procurement. These practices are forms of participatory infrastructuring in which possibilities for participation are opened and closed as caseworkers are engaged in processes to accommodate emerging tensions while expanding the existing infrastructure, i.e., the network of stakeholders and systems across organizations (cf. Bødker et al., 2017).

Second, at the theoretical level, we describe how the procurement phase defines the boundary conditions and modalities of participation. We believe that embracing the big issues associated with digital innovation processes in the public sector is important, calling ‘for people, in various communities and practices, to take control and partake in the shaping and delivery of technological solutions, processes of use, and future developments that matter to them and their peers’ (Bødker and Kyng, 2018, p. 1). We further the discussion of how public procurement influences participation in system design by focusing on (i) how users’ needs are embedded in the procurement through requirement specification, (ii) how user representatives can be organized in such a process, and (iii) how infrastructuring can help us conceptualize participation on the conceptual level.

2 System procurement in the public sector

Procurement is generally defined as an activity with the goal of meeting a need for products or services (Børmer, 2014; Lloyd and McCue, 2004). In public contexts, procuring new systems aims to satisfy a public, governmental, or societal need for government services. System procurement projects are often characterized by fragmented responsibility between customer and supplier in different phases (Artman, 2002; Svanæs and Gulliksen, 2008) and present significant planning and organizational challenges for commercial suppliers to facilitate stakeholder involvement, usually with the end goal of increasing system usability (Artman, 2002). CSCW researchers have been interested in system procurement since the field’s early days (Bowers, 1994). Based on a long-term study of Enterprise Resource Planning systems, Pollock and Williams (Pollock and Williams, 2010) argued that procurement deserves closer scrutiny because it lays the foundation for subsequent extensions of the systems’ scope. The signing of a contract between an organization, such as a public agency, and one or more suppliers represents a watershed moment between a more open exploratory phase when the focus is identifying the right problem to solve, and a more defined phase when attention shifts to solving the problem ‘right’ (Mikalsen et al., 2018). However, without appropriate user involvement strategies, users tend to resist the integration of digital systems that do not align with their work practices and mental models (Orlikowski, 1992).

Unfortunately, it is already at the stage of identifying the right problems - and thus translating them into system requirements - that user participation is often downplayed to a series of meetings with a selection of subject experts from which system requirements must be elicited (Mikalsen and Farshchian, 2020; Zahlsen et al., 2020). Studies on requirement engineering in CSCW illustrated the dangers of this tendency and showed, for example, that plans made at this stage often clash with actual, situated system use (cf. Dittrich et al., 2009; Suchman, 2006). In a study of a classification scheme for system requirements during the redevelopment of a nationwide information system, Hertzum (Hertzum, 2004) showed that: ‘The vast majority of functional requirements are not accompanied by any description of the context in which they occur—neither in terms of goals, constraints, and priority measures nor in terms of real-world examples or other detailed descriptions of typical or exceptional cases. It is left to the readers to supply this information, and unless they can do that, they will be unable to make much sense of the requirements’ (Herzum, 2004, p. 58).

While not all system requirement elicitation happens in the context of procurement processes, these studies are nevertheless indicative of the need to pay closer attention to the early-stage context of design, including, among other aspects, ‘the internal structure of the developer and the client organizations, contractual and tender issues, software engineering tools, and stakeholder agendas and relations’ (Svanæs and Gulliksen, 2008, p. 353). As a result, we are interested in investigating the context of design in early-stage procurement processes up until the tender documentation was issued because, as the studies cited above more or less explicitly illustrate, this phase paves the way for present and future possibilities - or lack thereof - of active user involvement and engagement in systems that matter in work, everyday life, and society (Bødker and Kyng, 2018).

Against this backdrop, we intend participation as ‘the fundamental transcendence of the users’ role from being merely informants to being legitimate and acknowledged participants in the design process’ (Simonsen and Robertson, 2012, p. 5). While procurement processes in the public sector seldom, if ever, follow PD principles by the book, we believe it is relevant to leverage the PD tradition and discourses to propose a conceptual apparatus to investigate forms of participation in which users act as not only source for defining requirements but influential voices in design in public service development.

3 Theoretical background

3.1 End-user participation

Different research domains have sought to define participation by describing what participation is and what it is not. These descriptions range from the motivation behind user participation (Beck, 2002; Bjerknes and Bratteteig, 1995; Ehn, 2008), practices of participation (Cornwall, 2008; Halskov and Hansen, 2015; Kyng, 2010), levels and typologies of participation (Arnstein, 1969; Cornwall, 2008) and outcomes of user participation (Bratteteig and Wagner, 2016). The research tradition of PD informs our conceptual view of participation. Since its advent in Scandinavian research communities in the 70s and 80s, PD has been motivated by democratizing work life. Early PD sought to empower workers to have a say when new systems were being developed and introduced into their place of employment (Simonsen and Robertson, 2012). Many of these initiatives were spurred on by trade unions which, since the 90s, have concerned themselves less with system development and implementation. More recent PD projects are initiated by PD researchers in varied but small projects in and outside workplaces (Kyng, 2010). Since its emergence, PD has built on an ideal of democratic decision-making and facilitating ‘genuine participation’ through a collaborative design process (Greenbaum and Kyng, 1991; Simonsen and Robertson, 2012).

PD researchers have argued for participatory practices in systems design and development, such as mapping users’ needs through dialog and prototyping activities and continuous user testing using prototypes (Bødker and Grønbæk, 1991; Svanæs and Seland, 2004). User participation is seen as necessary throughout, especially when deciding what to develop and as quality control ensuring that a system fulfills its intended purpose (Simonsen and Robertson, 2012). Envisioning the system in context becomes crucial as ‘to find out how the computer application functions in the use situation users must be able to somehow experience this’ (Bødker and Grønbæk, 1991, p. 4). User participation in decision-making requires a division of power through negotiation and the agency to ‘shape action’ (Bratteteig and Wagner, 2016). This agency relates to who makes or influences decisions, when they do so, and what these decisions concern. Defining participation during a system development project’s early phase is essential for understanding how participation will be practiced throughout the project.

In the municipal sector, decisions made over a decade ago affect how users (municipal employees and citizens) can participate in system development today (Bratteteig and Wagner, 2016; Dahl-Jørgensen and Parmiggiani, 2020). It is necessary to follow decision-making through different levels and contexts to distinguish between participatory rhetoric and participation in action. Bratteteig and Wagner (Bratteteig and Wagner, 2016) explained design persuasively as a process of creating choices and decision-making. Further, seeing decision-making as a complicated process in which ‘moves of opening and closing choices in the process of making are driven or modified by decisions that users participate in’ (Bratteteig and Wagner, 2016, p. 427). Participation in design is seen as the sharing of power in decision-making. Inspired by Schön (Schön, 1983; Schön and Wiggins, 1992), decision-making is illustrated as a process of seeing what choices or ‘moves’ one could make, ‘moving’ by making a choice, and after that, seeing what new moves are possible. When making design choices, some possibilities are opened while others close, revealing decision-making’s contingent nature. Bratteteig and Wagner (Bratteteig and Wagner, 2016) also point out that some decisions have more significant repercussions on the result and strongly impact later choices.

Though PD research has provided rich empirical examples of collaborative design projects, researchers in the field have pointed out that paradoxically there remains a need for conceptualizing what participation is (Andersen et al., 2015; Halskov and Hansen, 2015). Halskov and Hansen (Halskov and Hansen, 2015) reviewed ten years of PD research to uncover previous definitions of participation. Their review revealed a broad range of definitions of participation, categorized as implicit involvement of users, full participation of users in a design process, and mutual learning between users and designers. Andersen et al. (Andersen et al., 2015) argue for a broader view of what participation is than the typologies offered by, for example, Arnstien (Arnstein, 1969). According to Andersen et al. (Andersen et al., 2015), participation cannot be seen as limited to isolated instances of design activities. They see participation as mediated through time and space, inferring that the voices of participants are ‘translated and overtaken by policy reports, evaluations, and prototypes before they are manifested in action’ (Andersen et al., 2015, p. 6). This broader view on participation leads the authors to view users as not stand-alone participants representing only themselves but as networks. In the instance mentioned in their paper on the design of digital communication between social workers and children, children were represented not directly as individuals but through networks of other people, governmental institutions, and reports. In addition to viewing participants as network configurations, they argue for viewing participation as a characteristic of all project-related activities. This broader view of participation as something that permeates the entirety of the project and is enacted by a network of actors is a view we draw on in this study.

A key aspect of PD is that end-users are involved in the design work, such as through cooperative prototyping. However, this entails practices connected to the recruitment of end-user representatives and creating common understanding. Bødker and Grønbæk (Bødker and Grønbæk, 1991) discuss both these aspects of cooperative prototyping. Generally, they found that participants were recruited based on their role or experience within an organization or by being elected by coworkers or self-elected based on their own interest in development projects. They found that ‘establishing a working group together with competent user representatives’ to be the most important to support a continual mutual learning process (Bødker and Grønbæk, 1991, p. 17). A mutual learning process also requires understanding that goes both ways; users must put their work practices into words that can be translated into a language suitable for designing specific functionality that supports their work. The same applies to designers: the language they use when prototyping is not usually suitable when communicating with users. The work of joint prototyping becomes an act of fostering common understanding and mutual learning between the designer and the user. Recruiting user representatives is also an issue of resource allocation. To ensure active user participation, they must ‘be freed from parts of their daily work’ (Bødker and Grønbæk, 1991, p. 23). Though it is important for users not to be completely severed from their work tasks, they should not be expected to do additional work, and their contribution to development and design work should be recognized.

3.2 Infrastructuring

One aspect of end-user participation that has recently been questioned is, does it scale? (Roland et al., 2017). Halskov and Hansen (Halskov and Hansen, 2015) found that PD research often addresses a single design activity and rarely large-scale projects over several years. There is a lack of descriptions in existing PD research on the decision-making in-between design activities (Andersen et al., 2015). Therefore, open questions remain in terms of how participation should be practiced when creating large, interlinked systems and infrastructures (Oostveen and Van Besselaar, 2004). This is unfortunate as digital innovation projects - particularly in the public sector - are often characterized by extended design, i.e., they span several years, stakeholder groups, and locales (Monteiro et al., 2013). Several researchers have identified the issue of scaling participation as important to an extended design perspective and the heterogeneous dimensions it covers (Bødker and Kyng, 2018; Dahl-Jørgensen and Parmiggiani, 2020; Hochwarter and Babak, 2020; Oostveen and Van Besselaar, 2004; Roland et al., 2017). In line with Parmiggiani and Karasti (Parmiggiani and Karasti, 2018), we use the term ‘scaling’ to refer to participation in a political sense, emphasizing that different concerns and phenomena are revealed as projects extend along different dimensions, such as the dimensions of space, time, use, and policy. Importantly for this current study, some CSCW and Information System (IS) scholars have specifically addressed the scaling of participation through the process of ‘infrastructuring.’

Notably, already in the 1990s, Ruhleder, Star, and Bowker’s idea of infrastructure viewed technologies as appropriated and reappropriated as part of interlinked socio-technical networks and use situations over time (Bowker, 2015; Star and Ruhleder, 1996; Star and Bowker, 2002). This perspective supplemented the local view of system design as confined to situated encounters with technology from an ‘extended design’ perspective that scales, i.e., captures how technologies are shaped across different contexts and periods (Monteiro et al., 2013). Infrastructuring, as a verb, denotes work to accommodate the infrastructures’ dynamic complexity by temporarily resolving tensions between human and non-human stakeholders over time (Karasti, 2014; Lodato and DiSalvo, 2018; Parmiggiani and Karasti, 2018; Star and Bowker, 2002) while providing interfaces for coordinating work at scale (Scott and Orlikowski, 2021). From this perspective, infrastructures shape and are shaped by daily work practices (Star, 1999), including practices facilitating participation in design (Neumann and Star, 1996).

Building on this, (Bødker, 2017), p. 246) defined the concept of participatory infrastructuring as ‘infrastructuring activities that engage users in processes of design and use’. They also expanded on an existing understanding of participation as typical front-stage design activities, seeing participation as a continuous process that ties ‘into existing networks and systems across organizations’ (Bødker, 2017, p. 248). Infrastructures are seen as significant in innovation processes, requiring collaboration between many actors over time (Björgvinsson et al., 2010). Participatory infrastructuring encompasses not only the front-stage activities that PD research often focuses on but also what happens at several levels - namely at technical, decision-making, competency, and policy levels (Bødker, 2017). Le Dantec and DiSalvo (2013) illustrate how infrastructuring processes are central to constituting publics as they can be used to engage with authorities and problematize future scenarios. It also encompasses participatory processes in political arenas, the backstage of design work, and the work of tying participatory processes into existing networks (Bødker, 2017). In integrating participation processes into an existing infrastructure, the concept of knotworking by Engeström et al. (Engeström et al., 1999) describes the work performed by social constellations of members with diverse backgrounds and agendas that emerge temporarily during design phases. These temporary knotworks are seen as instrumental during an infrastructuring process.

In sum, although system procurement has received some attention in the CSCW literature (see e.g., Bowers, 1994; Møller et al., 2020; Pollock and Williams, 2010), little has been written about user participation in pre-tender procurement processes and how knotworking during this stage defines and shapes user participation. This paper contributes to filling this gap in the literature by presenting a case of new system procurement through an infrastructuring lens and analyzing the practices that shape caseworkers’ participation.

4 Empirical case: systems procurement in child welfare services

CWS’s goal in Norway is to ensure children’s welfare and protect them from detrimental care (Falch-Eriksen and Skivenes, 2019). Municipal CWS have several responsibilities, from assessing incoming notices of concern and conducting examinations to initiating and evaluating various measures. The history of the Norwegian CWS has been punctuated with friction (Langford and Kirkebø, 2019), in part due to a lack of transparency concerning decision-making processes related to citizens’ cases. Legacy systems have mainly been used to archive and share documents with other governmental agencies, not citizens. Caseworkers play a central role and are afforded discretion in decision-making and documentation. As a result, they are primary users to be considered in designing future digital systems for CWS. By implementing new technological solutions, the Norwegian government intends to increase CWS’s transparency and more clearly show the reasons for decisions made in their case (Bøhmer, 2020). In this context, the process of improving case management systems is seen by municipalities as an opportunity to both streamline case management and improve the Norwegian CWS’s reputation. Due to digital innovation and legal reform, the municipal CWS’s work practices will likely change drastically in the coming years.

4.1 Public procurement in the municipal sector

Considering the prevelance of small municipalities in Norway and the decentralization of services, municipalities may join forces during formal system procurement processes by inviting suppliers to develop new products or services (Ahlgren et al., 2019). This process can be precarious for the customer, requiring them to balance ‘between the innovation’s need for informal dialogical processes, and adherence to formal procurement processes regulated by laws’ (Mikalsen and Farshchian, 2020, p. 1). In our study case, the procured system will be embedded in an existing CWS infrastructure. Thus, the procurement process must engage with ‘a mature infrastructure during a turn in its life which happens when strategically mandated adjustments to existing arrangements are pursued’ (Grisot and Vassilakopoulou, 2017, p. 11).

Public procurement requires a tender, meaning a competition resulting in a binding, public offer (Langseth and Similä, 2021; Mikalsen and Farshchian, 2020). The procurement process can be divided into three general phases, according to Langseth and Similä (Langseth and Similä, 2021): the mapping phase, competition phase, and contract follow-up phase. All these phases center around the tender as ‘the starting point for a potentially broad dialogue with several vendors’ (Mikalsen and Farshchian, 2020, p. 6). The tendering process is subject to regulations and includes a tender report with specific requirements of what the public entity, acting as procurer, wants—as well as a deadline for submitting an offer (Langseth and Similä, 2021). As suppliers of a system or service, bids from companies on the needs outlined in the tender report. Therefore, adequately mapping end-users' needs is vital for ensuring the quality of the procured system or service.

Additionally, early and continuous dialogue with suppliers is important in creating a shared understanding of technical limitations and opportunities (Langseth and Similä, 2021) through conversations with potential suppliers during the competition phase (Mikalsen and Farshchian, 2020). After an offer is accepted, contract negotiation begins with a new round of adjusting the final product’s requirements. During the final follow-up phase, the procurer checks whether the set requirements have been met (Langseth and Similä, 2021). Similar phases were described in the International Handbook of Public Procurement (Thai, 2008), covering international and EU (European Union) procurement legislation, with determining requirements as the first phase.

As requirements are usually provided using formal, executable language, they are unsuitable when communicating with users (Bødker and Grønbæk, 1991). Additionally, decisions connected to procurement are made early on, when requirements are often uncertain (Moe and Päivärinta, 2011). This presents a clear challenge for end-user participation in public procurement. Since public procurers tend not to have a complete understanding of the needs of clients, including end-users to a greater extent in the procurement process has been suggested, as early pinpointing of requirements that correspond with user needs ‘guides the procurement initiative towards better usability, efficiency, and innovativeness from day one’ (Torvinen and Ulkuniemi, 2016, p. 60). A significant problem in public procurement is writing good enough requirements, as a supplier is only legally required to deliver what the tender specifies (Moe, 2006). Tender requirements vary depending on a project’s complexity and procurement type. These can range from high-level and flexible requirements that necessitate negotiations between customer and supplier to exact requirements detailing specific functionality the supplier must include in the procured system (Moe, 2006).

4.2 DigiBarnevern

In this paper, we focus on the infrastructuring practices leading up to the publication of the tender. To unpack how caseworkers participate during the procurement process, we draw on an empirical study of an inter-municipal project aimed at digitalizing CWS in Norway called DigiBarnevern. This project is a collaboration between the municipal sector, represented by a few municipalities, the Norwegian Association of Local and Regional Authorities (KS), and the state, represented by the Office for Child, Youth, and Family Affairs (Bufdir).

The DigiBarnevern-project officially began at the end of 2016 with seven Norwegian municipalities: Trondheim, Oslo, Bergen, Stavanger, Kristiansand, Bærum, and Asker. Thus, these municipalities became the customer, represented by a project management team, publishing a tender to procure a case management system for their CWS. From the beginning, the project management team situated in Trondheim was composed of two subject experts with experience as CWS caseworkers from Trondheim (defined as CWS experts in findings), as well as three systems development experts (defined as IT experts in findings). The members of the project management team were consistent throughout the procurement process but took on different roles in the development and implementation in later stages, mainly working on the citizen services subproject. The project was initiated by these Norwegian municipalities alleging that the current case management systems were not meeting the needs of citizens or caseworkers. These legacy systems lack a professional foundation in relevant social service practices and have been used as mere archival repositories. Additionally, little to no information is available for citizens about CWS generally and does not facilitate simple communication between CWS and the citizen, making participating in one’s case cumbersome and time-consuming. These limitations have resulted in considerable uncertainty and may have helped spread misinformation about CWS’s role in Norway. From the stakeholders’ perspective in CWS, citizens lack an overview of their cases and opportunities to participate, and caseworkers lack support in their work tasks.

To address issues of inefficiency and the need for clearer communication channels, DigiBarnevern includes two main sub-projects, including (a) the development of a new case management system and (b) citizen services. In this paper, we only focus on the procurement of (a): employees and managers in CWS will use the case management system as their primary work tool. A private supplier will develop this system through a procurement process initiated by the participating municipalities, and Trondheim municipality will act as a pilot for both main deliverables. This system will receive all notices of concern and present prompts for descriptions of measures taken in each case based on a professional framework. Citizen services (b) will be used by citizens with an ongoing case as an additional communication channel with caseworkers for receiving information about their case and to comment on case documentation. Since the Norwegian CWS infrastructure exists and is governed at the state and municipal levels, the project also seeks to integrate guidelines and prompts as a professional framework based on social work expertise developed at the state level. The project management team situated in Trondheim municipality defined the requirements of the new case management system, consulting CWS caseworkers and managers from other municipalities and other public entities (KS and Bufdir).

5 Research methods

This paper adopts a case study as a strategy (Flyvbjerg, 2006; Walsham, 2006) to research the early stages of the procurement process, that is, the phase leading up to the definition of the tender documentation, which crystallizes users’ needs and how participation is envisioned in the development. Our aim was to investigate how the inclusion of caseworkers in the early stages of the system procurement process happened in practice by flashing out the perceptions, motivations, and actions of the actors involved during day-to-day activities of making decisions. Access to the case was negotiated by the first author who carried out the data collection for two years between September 2020 and September 2022 (see Table 1 for a comprehensive overview). The data collected for this study is solely qualitative. To gain a better understanding of the context and impact of the procurement, the period for data collection extended beyond the tender stage.

Table 1 Data collection overview.

Our primary data source consisted of interviews. Twelve (12) informants were interviewed in total. These interviews were crucial to gain an in-depth understanding of experiences of practices related to participation and allowed informants to reflect (Rubin and Rubin, 2011) on choices made about end-user involvement over time. This was important to compensate for the fact that we had no access to the workshops and hearings that had happened before we began the study. We adopted a snowballing strategy to identify relevant informants who were or had been involved in the procurement process. Interviews happened in two main phases. In the first phase, we design interviews following a storytelling approach to obtain deep insight into the context where participation unfolded (Lutters and Seaman, 2007). In the second and concluding phase, we used interviews to validate our findings and invited informants to reflect on our reconstruction of three practices affecting caseworkers’ participation over time. In doing so, we were inspired by Karasti et al.’ (Karasti et al., 2021) approach to devising timelines as a visualization tool to help informants reconstruct their perception of the temporality of infrastructuring work (see also Bowker, 2015). Observations of meetings and documentation constituted a secondary source to further nuance our findings and identify additional informants. Interviews were documented using voice recordings that were transcribed and anonymized and extensive field notes were taken during observations.

Using the qualitative data analysis software Nvivo, our analysis involved coding in stages based on Tjora’s (Tjora, 2018) stepwise-deductive induction. Though the analysis process devised by Tjora (Tjora, 2018) comprises seven distinct steps, these steps were simplified into three stages. In the first stage, the first author coded data inductively in vivo, keeping the codes close to the original utterance to avoid misunderstandings. At the same time, extensive memos were written to identify quotes that stood out while noting related concepts. This inductive phase of empirically close coding resulted in over 150 unique codes, while memos kept a log of overarching themes in our data as they emerged. In the second stage, both authors reviewed codes and memos linking them with concepts from the CSCW literature, thus inverting the coding process and organizing the in vivo codes under abductively produced, theory-based categories. Finally, codes were combined into three overarching practices. This analysis method aimed to build our conceptual understanding from the ground up through detailed empirical analysis, testing our conceptual framework’s robustness in the later stages of our analysis to enable generalized concepts. Table 3 in the appendix describes the stages of our analysis and the coding categories are presented in Figure 1.

Figure 1.

Hierarchy of coding categories.

The coding revealed a trend in the data that resulted in three infrastructuring practices affecting participation, as illustrated in Figure 1. These infrastructuring practices capture continuous work to temporarily accommodate emerging tensions over time, space, and political concerns in the emerging infrastructure (Star and Bowker, 2002). Initially, procurement emerged as an overarching narrative theme of the data, providing the context of this study. Our analysis revealed that the procurement process defined much of the narrative during interviews regarding their content and temporality (i.e., what practices were taking place in the procurement process). We further characterize the procurement process through three practices, 1) scaling, 2) positioning representatives, and 3) negotiating participation. Though the whole case was seen through a participatory lens, how participation was discussed and negotiated was also explicitly reflected in the collected data and was the focus of the analysis. We called the resulting sets of practices infrastructuring practices because, as we shall illustrate, they aimed at opening or closing possibilities for users to participate in the design and, therefore, the use of the new infrastructure (Bødker, 2017). These infrastructure practices shaped the character of participation, i.e., who could participate, in what ways, and when, during the procurement process.

The quotes presented in this paper were all translated from Norwegian and quotes from field notes were reviewed by the informants to ensure accuracy and validity. Informants are represented by an initial in the findings section.

6 Findings

In this chapter, we present the findings from our analysis. First, we provide some context for the Digibarnevern-project and the motivation for procuring a new case management system. In the sections below, we illustrate three main practices enacted by the project management team that affected the participation of caseworkers in the procurement process i.e., the scaling up of the project, negotiating participation, and positioning of CWS representatives.

Caseworkers and managers in Trondheim CWS are currently using one of the two case management systems supplied by private companies in Norway for archiving case documents and financial management.

[The project] began with an investigation and mapping of needs in the Trondheim region in the autumn of 2015. [...] The need for a new case management system was identified based on interviews with employees with frontline workers in different roles in CWS. (Informant ‘G,’ CWS expert, Trondheim municipality, interview).

Caseworkers and managers felt that the existing case management systems did not facilitate easy communication with citizens and were inefficient. In their day-to-day work, caseworkers still used physical documents and archives. This resulted in a lot of time being spent plotting the same information in different systems.

Current internal mailing systems [in municipal CWS] and communication are slow. [This system] requires that you send physical letters as this is considered the safest [form of communication]. Right now, there is a lot of information in the systems, but in the case assessment process, there is often missing information about why holdups in a case occur and a lack of explanations for decisions being made (Informant ‘T,’ project manager, Trondheim municipality, meeting).

In a project management team meeting, former caseworker and subproject manager ‘G’ describes a typical experience trying to communicate with one of their clients during a workday:

So, I’ve had a meeting with a child or a parent with a case with us, I write a report based on that meeting. If they want to contact me between appointments, they have to call. My day also consists of other meetings, so if a parent calls while I am in a meeting, I would have to wait until [it] is over before calling them back, and then they often don’t respond and call again when I am in another meeting. So, we go back and forth like this. (…) The fact that we have to physically archive documents, stamp, copy, and number them is a big time-stealer for the municipalities that still do it that way. (Informant ‘G,’ CWS expert, Trondheim Municipality, meeting).

In 2016 Trondheim municipality concluded that procuring an off-the-shelf system was not an option. This realization came from the interviews of CWS workers conducted by Trondheim municipality highlighted the many deficiencies of the two current case management systems available. ‘We needed to go through a procurement anyways [due to public sector regulations], so it might as well be something new that supports the caseworkers and the citizens.’ (Informant ‘T,’ project manager, Trondheim municipality, interview). The project management team saw this change as an opportunity to design a new, tailored case management system that allows better communication with citizens, resulting in the initiation of a larger project lasting several years (see Figure 2). The envisioned result was thus a system in which citizens and caseworkers could experience increased ownership and collaborate in creating documents related to a case. The project management team described the participation of end-users in interviews and in the tender documents, as we will present in the following sections.

Figure 2.

Timeline of the DigiBarnevern-project.

6.1 Scaling up the project

Since the project management team decided in 2016 that Trondheim municipality would procure a new case management system, the scale of the project has grown in two ways. Firstly, the project scaled up with multiple municipalities collaborating and, secondly, through establishing subprojects. The project’s scale evolved since other municipalities identified the same needs and frustrations with existing case management systems as Trondheim municipality.

In a conversation with IT expert ‘Y’ and CWS expert ‘G’ at DigiBarnevern’s offices, they describe collaboration across municipalities and with Bufdir [the Norwegian Directorate for Children, Youth, and Family Affairs] state level. Informant ‘Y’ told the first author, ‘[W]e decided in the fall of 2016 that we should collaborate with others in procuring something entirely new.’ ‘G’ added, ‘After caseworker’s needs were identified in Trondheim, we found out from [the municipal interest organization] KS that other municipalities had the same experience with the current case system. So, there was an opportunity here not just to improve the situation in Trondheim but for other smaller municipalities as well.’ ‘Y,’ ‘From there, I think KS took the initiative to connect with Bufdir to develop the professional framework that will be integrated into the case management system. So that’s when the project expanded into two projects, one at the state level and one across municipalities.’ (Project management team, Trondheim municipality, meeting).

KS encouraged collaboration across municipalities and with Bufdir. Since KS and Bufdir had found similar needs for a new case management system across Norway, the municipal and state-led projects converged to create CWS systems addressing these needs, including a built-in professional framework for decision-making aimed at caseworkers. In a meeting, informant ‘B,’ who was heading the state-level project at Bufdir, mentioned the parallel work they were involved in:

They [Trondheim and Oslo municipalities] were talking to smaller municipalities about their needs early. From the state side, we started independently and in parallel with the municipal project DigiBarnevern. It began with a dialogue between the ministry and directorate to ask if there was any need among municipalities. [...] We found the same need as Trondheim municipality. (Informant ‘B,’ project manager, Bufdir, group interview).

Trondheim municipality also decided to collaborate with other municipalities after discussing the procurement of a new case management system with potential suppliers:

It turned out that it was not possible to find a supplier who would deliver what was desired and to adapt a professional case management system just for ‘little Trondheim.’ Trondheim does not constitute a large enough demand, so there was a need to merge with other municipalities in the form of the [inter-municipality collaboration] project, which is DigiBarnevern. (Informant ‘G,’ CWS expert, Trondheim municipality, interview).

This interaction with suppliers led the project team to decide they needed to join forces with other municipalities. Trondheim municipality along with Oslo, Bergen, Stavanger, Kristiansand, Bærum, and Asker i.e., municipalities of varying sizes came together as a customer who published the tender. During the first phase of the project, former CWS caseworkers from Trondheim and Oslo took the initiative to interview fellow caseworkers around the country, especially focusing on the needs and participation of smaller municipalities. Former caseworker and system administrator for CWS in Oslo, informant ‘N,’ told us about the mapping they had done with ‘G’ from Trondheim.

I’ve been involved in the [DigiBarnevern] project ever since Oslo first got involved in the project at the end of 2016. [...] Interviews were done in the fall of 2017, where we interviewed workers in CWS in smaller municipalities all around Norway [...] about case management systems and their need for digital solutions. We wanted to see if there was a big difference in that most of the DigiBarnevern municipalities are big, and KS was very concerned with us creating something that everyone could use. So, yes, we made an effort in talking with smaller municipalities as there are differences in whether or not they have collaboration agreements with other municipalities around CWS. (Informant ‘N,’ CWS expert, Oslo municipality, interview)

With Trondheim being the third largest municipality in Norway, smaller municipalities had seemingly less expertise when procuring new systems and services. Informant ‘J’ who was leading the procurement process speculated that a lack of expertise in procurement and digitalization processes led to municipalities missing opportunities to participate.

There are clear municipal differences. The other municipalities can make comments and come up with input through hearings. But it varies, some municipalities did not comment on the descriptions of needs and the specification of requirements at all, which suggests that they have not taken the time to look at it as there is always something to comment on in such documents. The other smaller municipalities probably lack a certain amount of expertise in the development of digital services since they were involved to a minimal extent. They also do not have enough ownership of what is being developed as a professional system. (Informant ‘J,’ procurement consultant, Trondheim municipality, interview).

During the concept phase, all Norwegian municipalities were invited by project management to contribute to hearings during the procurement process. However, smaller municipalities contributed less when writing requirements for the tender. Unless the municipalities have in-house expertise, this lack of power greatly limits digital system innovation. Notably, Oslo (Norway’s largest municipality) and Trondheim contributed the most to the procurement mapping phase. According to informants, this was due to their lack of expertise in system development.

Oslo has a large professional environment already. We have a professional system department that has reasonable support for all districts and child welfare programs and other types of programs. [...] So, it was quite natural to think that Oslo could invest resources in such a project. (Informant ‘N,’ CWS expert, Oslo municipality, interview).

The larger municipalities involved in the procurement had more experience and CWS-related resources and could participate to a greater extent in the project. By collaborating with all the municipalities involved in the procurement, a lot of the project management team’s time was spent coordinating with all the different stakeholders. This effort was mentioned by several of the project management team members:

It is quite rare that the municipalities go together like this on a procurement. This is because the municipalities are autonomous in the systems they choose. [...] So, the challenge has been to collaborate with other municipalities in procurement while considering their individual organizational structure. (Informant ‘Y,’ IT expert, Trondheim municipality, meeting).

G also brings up the possibility of challenges during development arising from inter-municipal collaboration in the procurement process:

The municipalities have their own organizational structures that add uncertainties when collaborating on a larger development project like this. For example, Oslo municipality is more politically governed which could lead to restructuring and changes in management. Also, we have seen that even though the municipalities can have the same needs but different ideas about how to complete the procurement. (Informant ‘G,’ CWS expert, Trondheim municipality, interview).

The project management team suggested that changes in the political and structural organization for single municipalities could possibly lead to changes in the priorities of financial allocation as well as who would be the project's contact person within a given municipality. On the one hand, collaboration allowed the municipalities to pool their resources and expertise but brought on challenges related to the participation of each municipality. Smaller municipalities with less expertise from similar development projects had fewer opportunities to send caseworkers to participate in hearings and meetings on writing requirements. On the other hand, without collaborating with other municipalities, a single municipality would not be able to contribute at all to such a project.

In addition to collaboration at municipal and state-level, the project scaled as KS and the Digibarnevern municipalities made the joint decision to develop a second system for children, parents, and foster parents to communicate with caseworkers and follow information about their case with CWS if a notice of concern has been issued.

In an in-person meeting with the project management team after the procurement process had ended the question was posed of how the project was separated into two subprojects. Y recalled; ‘The topic of creating citizen services came up during the concept phase. Everyone [KS, Bufdir, and municipalities] saw the need for establishing a good dialogue with the citizen.’ G elaborated; ‘The idea was always to have better collaboration with the citizen.’ (Project management team, Trondheim municipality, meeting).

The division of the project into subprojects also served to center two different main user groups; one project focusing on caseworkers and the other on citizens in contact with CWS. As the citizen services subproject would be developed by the municipalities in conjunction with KS, this was not part of any procurement and therefore out of the scope of this paper. However, though the two systems are divided into subprojects, their development processes were linked, just as the systems themselves will be linked through a joint content base.

Project leader ‘T’ describes how one subproject, citizen services, depends on the other, i.e., the development of the case management system. Making decisions about the content and development timeline of the case management system, and therefore also citizen services is an outcome of writing the tender report.

The content and timetable for citizen services depend on the case management system. Thus, it must be viewed in part according to the outcome of the tender process. In the process of mapping needs, a lot will happen. [...] What happens when announcing a public procurement is that the tender specifies what will be included in the case management system. [Users’ needs] must be specified and included in the tender so that the suppliers know the parameters of what they offer. (Informant ‘T,’ project manager, Trondheim municipality, interview).

In sum, the project management team had to translate users’ needs into the requirement also on behalf of citizens in the procurement of the case management system. Mapping of citizen needs had to be done early on during the concept phase of the case management system in parallel with the mapping of caseworkers' needs. As rounds of negotiations between the municipalities and potential suppliers followed in 2021 based on the original tender, many users’ needs had to be articulated for both caseworkers and citizens.

6.2 Negotiating participation

Many parameters related to functionality and user needs had already been defined when the tender report was written at the beginning of the procurement process in addition to the project’s scale. ‘Y’ summarized the process of specifying needs in the requirements:

In writing the requirement specifications, we focused on being user-oriented, listing the needs of users and not specifying a solution. It is the supplier's job to deliver something that aligns with those needs. [...] After the requirements are specified the focus is no longer on dialogue [with potential suppliers]. There might be some clarifications but no dialogue.’ (Informant ‘Y,’ IT expert, Trondheim municipality, meeting).

‘G’ reflects on how the project management team had to translate the needs of citizens and caseworkers into requirement specifications while writing the tender:

In formulating the needs, we focused on describing the needs from different angles in order to achieve the best possible technical solution. We didn’t want to make cool gadgets but something that actually supported practices. [...] I think the focus on user participation in this project is considerably larger than what has previously been done in development projects in CWS. Considering the dialogue with user organizations, the inclusion of CWS experts in the project, and the thorough mapping of users’ needs. When mapping the focus was on how they can be supported, not which solutions they want.’ (Informant ‘G,’ CWS expert, Trondheim municipality, interview).

In total, 221 requirements are specified in the tender report distributed across 38 topics related to laws and regulations; security; privacy; supporting work processes; usability, quality of service; system interoperability; scheduling, planning, and documentation during the development process; and maintenance and further development. These requirements were central to much of the decision-making in procurement as they have two important aims. First, requirements describe the users’ needs and the functionality desired for the procured system. Second, they function as a checklist against which suppliers’ offers are evaluated. DigiBarnevern’s tender report mentions the need for the participation of citizens, citing legal arguments, ‘the law shall facilitate local government and a strong and representative local democracy with active citizen participation.’ (Section 1: Laws, regulations, standards, and language, Tender report Appendix 1, p. 22).

The participation of caseworkers and others within CWS was grounded in the tender report by specifying that representatives from the different municipalities would work together in reference groups throughout the project. The reference group would consult the project management team in the development. The municipalities also wrote that an interdisciplinary project management team would be established, consisting of subject experts from municipal CWS, service design, and procurement. In addition to ensuring the quality of the system, CWS experts had an important role because they were invested in establishing a good relationship with the supplier. This was seen as necessary for a good collaboration, both during and after the procurement.

The most important thing for me is that [the supplier has] an idea of how to use us [i.e., CWS experts] in the development, that they can hold out a few years, and that they have an idea of how to further develop things—not just that it should be developed and that it is a struggle every time something else is to be done. That’s the experience we are now left with, with what we have [i.e., the current case management system]. (Informant ‘M,’ CWS manager, Oslo municipality, interview).

The tender specifies many roles that will be filled throughout the project’s lifespan and by whom. Additionally, the tender emphasizes end-user participation in any supplier’s offer. ‘Emphasis will be placed on the extent to which the supplier will involve users [citizens and CWS workers] in idea generation, concept work, detailing, prototyping, and testing of functionality.’ (Section 36: Standard upgrades and maintenance, p. 129).

Though the tender included references to desired participation in the later phases of developing case management systems, the language in this section remained somewhat ambiguous regarding how participation was weighted related to other requirements. Procurement consultant ‘J’ worried that a lack of clarity in what they meant with user participation in the development phase would have ramifications when development began.

A good enough job has probably not been done to include [end-user] participation as a requirement in the procurement. This will probably have consequences for the degree of involvement of users in the development. (Informant ‘J,’ procurement consultant, Trondheim municipality; interview).

‘J’ was worried that if user participation was not described clearly enough in the tender, then suppliers would not prioritize it in the development phase. The DigiBarnevern municipalities’ choice of procurement was seen by some of the informants as a threat to good user participation during development. Informant ‘M’ explained that the traditional procurement process did not facilitate the flexibility that would allow for more user participation:

We had a description of needs that we were supposed to publicize because we were thinking that we should have a different type of tender than the ones that only contain requirement specifications. Then, we found out that we probably had to go the old-fashioned way with more requirement specifications. We reworked the description of needs so that it became as it is now before it went out on tender this spring. (Informant ‘M,’ CWS manager, Oslo municipality, interview).

When the municipalities decided to write a more traditional procurement type, many requirements had to be detailed enough not to confuse suppliers when reviewing the tender. However, this meant that user needs had to be translated to specific requirements that could be harder to revise with end-users' participation. Informant ‘J’ mentions the issues the project management team has dealt with when writing the tender report leading to several rounds of specifying descriptions of requirements and users’ needs.

We received feedback from suppliers about confusion when there is such a large difference between the degree of detail [of requirements]. If it is not detailed on some points, but on others, there is a recipe, then you run the risk that the suppliers will come up with something completely different on the vague parts. [...] Vague descriptions of users’ needs lead to less focus on needs in the conversations with suppliers because so many resources are used to navigate the relationship between the project management and suppliers. More resources were used on this than determining the needs in a way that suppliers could relate to. (Informant ‘J,’ procurement consultant, Trondheim municipality, interview).

‘J’ underscores the importance of specifying requirements in conjunction with suppliers as this becomes the foundation for a common language and understanding of users’ needs. Additionally, the project management team wanted user participation to be a part of the development of the system after procurement.

The project management team conducted a series of conferences with suppliers from mid-2019 to mid-2020. These meetings aimed to create an understanding of the role of CWS and the different user groups’ needs. The project management team put several participatory activities into practice, involving different stakeholder groups in multiple workshops in the four years before the tender was published (see Figure 2). In these meetings, representations of caseworkers and citizen groups were introduced to suppliers by using personas and user journeys:

Analysis of the target group brings empathy into the mapping of needs. The activities included in the workshops show how decisions affect people. The personas that we used have different degrees of IT knowledge, knowledge of the child welfare service, trust in the child welfare service, and the like. […] Using personas lifts the weaker user groups forward that otherwise are difficult to involve. We’ve done customer journey workshops using personas and user journeys with caseworkers. The purpose of user journeys is to map the users’ needs and experiences of the service from the first to the last point of contact. (Informant ‘Y,’ service designer, Trondheim municipality, interview).

In sum, the project management team and municipalities involved in writing the tender report engaged in negotiations of what user participation would look like in the development of a new case management system for CWS. This negotiation took place both formally through the work municipalities put in when writing the tender and requirements and more informally through direct dialogue with suppliers in conferences using personas and user journeys to establish a common language around users’ needs.

6.3 Positioning representatives

From 2016, representatives from municipal CWS in Trondheim were represented in the project management team as subject experts that worked alongside hired IT consultants in different capacities. This included mapping users’ needs, both the needs of CWS in multiple municipalities and citizen representatives. A concrete example of the positioning of CWS representatives is its formalization through the tender report. In the tender, municipal resources in the form of CWS expertise and hired consultants were recruited by the project management team in central roles for the future development phase:

The Customer [i.e., municipalities leading the procurement] will contribute expertise and capacity within several subject areas in the project implementation. It will be crucial that the Supplier takes advantage of the resources the Customer contributes to the success of the project. […] The customer can use their agreements for the purchase of goods and services within ICT and consultancy services to staff roles in the project. (Appendix 1, Section 28 - The Customers competence in the development phase, p. 109).

The tender goes on to specify an estimation of what the customer will provide of resources in the form of experts who will assist in the development phase. This includes 2 to 4 CWS experts working full-time, 1 to 2 full-time service designers and user interaction experts, 2,5 full-time system architecture and security experts’ positions, and 3,5 full-time equivalent professional resources. Most experts were repositioned from other roles in the municipality and subsequently inhabited key roles in the project before the contract with the supplier was signed.

In addition to addressing the participation of CWS caseworkers, CWS experts were tasked with mapping the needs of citizen representatives. According to a CWS manager, this decision came because of a shift in views on citizen participation in the past years:

When I first started working in CWS there was no talk of participation. No, they [the citizens] were allowed to say some things [regarding one’s case], and we would get consent, but we all know what consenting meant [=intended as passive consent]. So, this focus on participation is new. (Informant ‘M,’ CWS expert, Oslo municipality, interview).

As the project scaled up, including several municipalities, deliverables, and functionalities, caseworkers were seen as a resource that would contribute expertise to improve the quality of a new case management system. The scaling up of the project led to the establishment of levels of decision-making in the project. In addition to a steering group, reference groups consisting of CWS experts were formed to focus on specific concerns. These groups’ decisions would have much of the final say in the developed systems’ quality and functionality and report these to the project management group. Four reference groups, focusing on finance, archive, technical, and organizational, were formed in conjunction with acquiring and developing the envisioned case management system. These would be communicating with the project management group in the process of forming requirements. ‘M’ and ‘N,’ from municipal CWS in Oslo were recruited to be part of reference groups based on their unique expertise. CWS expert ‘N’ has 8 years of experience as a caseworker and from system support in Oslo municipality, thereby having a lot of insight into the inadequacies of the existing case management system they were using:

Yes, I’m probably what you call a subject expert, then. I know a lot about what they are struggling with in the use of the current case system especially. I’m a bit on the side as a professional resource, as I know more about the use of the system, and it is with that perspective I can say something about usability and what is important for employees in their daily work. (Informant ‘N,’ CWS expert, Oslo municipality, interview).

Informant ‘M’ also has a wealth of experience from CWS having inhabited different roles in CWS both as a frontline worker and a manager. ‘M’ had just quit the job as CWS manager at the district level when they were approached by the district manager wondering if they could be a CWS expert for the Digibarnevern-project due to their experience with the implementation of the current data system. As ‘M’ told us, their recruitment was a result of word-of-mouth and their own interest in systems:

It turned out that, since I am involved in some things, someone else heard about it and I was asked if I could participate in another part of the project as well… [I am] like a professional expert for those that develop this [case management system]. It is more because they know nothing about child welfare, but we do. So, then, I’m involved because I have knowledge and experience of child welfare but also because I have an understanding of the system that this should go into. (Informant ‘M,’ CWS manager, Oslo municipality, interview).

As CWS experts they had a great deal of impact on key aspects of the final system as the resource groups they are involved in have the task of evaluating the offers and during the subsequent development stage.

Several experts in the resource groups are taking part in the evaluation [of the procurement offers]. There are three CWS experts from Trondheim municipality who will be involved in evaluating the functional requirements related to that domain. And then there is someone else who will participate and evaluate archives and finances. And then there are some other [CWS experts], I think, that will also be involved in the technical requirements. Yes, and there are a few more that will be involved in the evaluation than those who have been involved in writing the requirements. (Informant ‘N,’ CWS expert, Oslo municipality, interview).

Whereas the CWS experts recruited from Oslo had systems expertise, that was not the case for all experts. Caseworker ‘A’ was hired in Trondheim as a CWS expert in the project management team. Before joining the project, they had worked as a caseworker for unaccompanied child refugees and joined the project through a normal hiring process. ‘A’ described that they had a detached relationship when using the existing case system before joining the project:

I had heard about the project and that they needed people. So, I applied, went to an interview, and was hired for the position. […] It is hard to remember now, but I think I got the announcement in an email. When you work in CWS, you don’t think about computer systems in this way. You are more like, okay, this is the computer system that we have, and you can be frustrated at it at times, but you don’t reflect on it much. So, I was very unsure how I was going to manage this job. […] There are many things I have not done before, like making mockups of what user interfaces could look like. That’s something I have never done before but it is very educational. There are many words and expressions I wasn’t familiar with. (Informant ‘A,’ CWS expert, Trondheim municipality, interview).

Despite having doubts about what they could contribute as someone without system development experience, ‘A’ now saw their expertise in a new light while learning how to contribute to envisioning a new digital system based on users’ needs. Before joining the project management team, ‘A’ felt that a case management system was something that they could not influence.

CWS experts were involved in mapping needs before procurement, from collecting interviews from CWS in smaller municipalities to facilitating user testing of prototypes with caseworkers and citizen representatives. During a meeting in mid-2021, ‘A’ mentioned work sessions the project management team was conducting with CWS and citizen representatives shortly after the contract was signed with the supplier to gather feedback on how the user needs had been translated to specific functionality. ‘A’ had experienced the feedback as quite positive:

Thorough mapping was done a while ago for both citizens and employees and based on that we have arrived at planned functionality for the system. Now we have again presented it to both citizens and employees to hear if we are on the right path or what they think about it. t it. [...] We experienced that everyone was very positive about most things. We’ve had a lot of good and constructive input, especially on the citizen side. (‘A,’ CWS expert, Trondheim municipality, interview).

Parallel to these sessions, ‘M’ was involved in testing the professional framework that would be integrated into the case management system. This included informational texts that were presented and continuously refined in different venues:

As soon as we have something ready that we think we can test on people, we will do it [...] and they have also been through the user organizations with information about thinking and mindset and received criticism and made some small changes. So yes, there is a good deal of user participation both from caseworkers as users of the case system and users of the quality part, but also our end-users who are then children and parents. (‘M,’ CWS expert, Oslo municipality; interview).

To summarize, by being involved in much of the mapping of needs, CWS experts had the role of advocating for both their own and CWS workers’ needs, but also the needs of citizens. Experts that had experience working both in CWS and with current case management systems played a central role in the procurement. Considering their dual expertise, they served as a link between social work as a profession and system development. While working alongside IT architects and service designers, municipal CWS workers can voice their colleagues’ needs while being relieved from their casework load to lend their expertise in procuring a new system.

7 Discussion: Infrastructuring participation in procurement

CSCW studies of system procurement and development have revealed that the early phases pose significant challenges for user involvement while they are crucial for shaping future opportunities for participation (Bødker, 2017; Farshchian and Thomas, 2017; Mikalsen et al., 2018). Despite the prevalence of systems procurement in the public sector, there is an evident lack of research in CSCW on how user participation is enacted in such cases. In answering our research question— what affects participation in early-stage procurement processes in the public sector? —we pointed to infrastructuring practices that affect participation in procuring a new case management system to be adopted by Norwegian CWS caseworkers; in the initial stages user needs and other requirements had to be defined upfront. The infrastructuring practices we identified correspond to decision-making practices that were collaboratively enacted by the project management team to pragmatically resolve emerging tensions by scaling the project, negotiating participation, and positioning subject experts. The results of these practices were crystallized in the official documentation accompanying the project’s tender process, which likely has consequences for subsequent user participation in the new system’s development (Table 2).

Table 2 Summary of infrastructuring practices.

In discussing our findings, we focus on three distinct but interrelated topics: 1) the concretization of users’ needs in the procurement, 2) the practice of participation and creation of knotworks, and 3) elaborating on participatory infrastructuring as a conceptual understanding of participation in the context of municipal systems procurement. Participation in the procurement process was instantiated in different ways; firstly, in writing the tender contract and aligning requirements with user needs; and secondly, regarding how future users might be included throughout the development process, in the opening and closing of choices, depending on the chosen suppliers.

7.1 Concretizing users’ needs in the specification of requirements

The expressed needs of users were anchored through requirement specifications in the mapping stage, which included workshops and feedback meetings with citizens and CWS workers. Tender requirements should be as detailed as possible when using traditional contracts for public procurement. This is beneficial when evaluating offers and selecting the supplier who will develop the best system. However, the specificity of requirements must be balanced with the flexibility necessary for several stakeholder groups to influence decisions throughout. In the findings, we described that the project management team had to rework and concretize the requirements that specified users’ needs to fit with the format of the procurement type. There was concern that in revisions, end-user participation would not be anchored well enough in the requirements. Therefore, the tension between prioritizing highly specified requirements and room for effecting decision-making through participation in the development remained. The step in formulating the tender was considered necessary by the project management team because any subsequent end-user participation would have to be negotiated between the municipalities (the customer) and the chosen system supplier. The supplier is assumed to have significant power over the final product due to their control of the following development phase. At the same time, the development will be based on the requirements set by the DigiBarnevern municipalities, represented by the project management team. Therefore, the division of decision power over what is being developed will depend on which phase the project is in.

According to this analysis, procurement can be seen in relation to the notion of decision-linkages as defined by Bratteteig and Wagner (Bratteteig and Wagner, 2016). Making design decisions is a complex and subtle process in design projects in which choices are opened or closed stepwise in the process of ‘seeing-moving-seeing’ (Bratteteig and Wagner, 2016; Schön, 1983). Based on the first decisions, some avenues for further decision-making will be opened while others will be closed. These ‘moves of opening and closing choices in the process of making are driven or modified by decisions that users participate in as co-producers of design ideas and as evaluators’ (Bratteteig and Wagner, 2016, p. 427). However, we found that many major choices about the user’s needs were formalized in the tender documentation, limiting the remaining availability of consecutive choices. Therefore, thorough mapping of user needs before the publication of a tender was essential to open avenues for future choices. The DigiBarnevern-project’s management team highlighted this in translating users’ needs into requirements with which a supplier must comply. These requirements were open enough to describe needs, not technical solutions, but clear enough not to create confusion. The tender defines the scope for further development; thus, it constitutes a pivotal moment because it crystallizes the needs documented in the tender. In sum, procurement involves making decisions that frame all later choices.

The procurement of digital systems warrants more flexible service development approaches compared to what traditional public procurement processes allow (Langseth and Similä, 2021; Mikalsen and Farshchian, 2020). The boundary between how much of the new system is defined based on requirements specified in the tender and how much end-users can influence outcomes can be seen in relation to the flexibility of the contract type. This tension between contract assessment and flexibility was highlighted by Langseth and Similä (Langseth and Similä, 2021), as well as in our findings. The project management team specified that user participation, through reference groups and user testing, should be part of the development phase, requiring some flexibility in the requirements. However, with added flexibility, like continuous user participation also during the development phase, evaluating whether a supplier’s proposed solutions become more difficult than creating a list of inflexible requirements. Contending with a traditional procurement became challenging for the project management team as standard requirement specifications prioritize future solutions before needs, as illustrated in the findings (Bødker and Grønbæk, 1991; Shapiro, 2005).

The tender documents required end-user participation in the development phase as a way to circumvent the rigidity of the traditional procurement. The DigiBarnevern-project’s management team used the tender report to specify resources in the form of subject experts’ time and how these resources should be organized. Though, any effect on decisions or project outcomes must be weighed against the other requirements set in the tender and the existing infrastructure of local CWS with their various organizational constraints. Hence, the tender and procurement process can provide limitations to participation but also be exploited to facilitate participation in development. However, newer approaches to procurement could offer new ideas and suggestions regarding who should be included in the development process, as well as how and when.

7.2 Establishing knotworks of CWS representatives

Bødker et al. (Bødker, 2017) have drawn on the concept of knotworks to describe the temporary networks that arise during infrastructuring processes, such as development and design work. In the DigiBarnevern-project, we found that experts—such as caseworkers—were recruited into knotworks with decision-making impact during the case management system’s ideation and procurement stages. Additionally, the establishment of knotworks was codified in the tender as resource groups. These knotworks were constellations of ‘participants with different backgrounds, perspectives, and agendas’ (Bødker, 2017, p. 251) who work toward a common goal of obtaining a new case management system. By positioning people with CWS experience alongside IT experts, DigiBarnevern fostered opportunities for mutual learning. CWS experts without previous systems experience previously perceived case management systems as rigid and unmalleable. However, CWS experts saw value in their expertise when collaborating with IT experts in writing requirements. This realization was a byproduct of collecting information about caseworkers’ practices in different municipalities and detailing their needs. We see mutual learning as integral to participation in system design and development. Working closely together over time towards a common goal allows for more opportunities to foster a collective understanding of key problems and the work that the new system will support. This increased input from CWS caseworkers in the DigiBarnevern-project intends to improve the procured system’s quality while facilitating caseworkers’ autonomy in the development. This positive outlook for the system’s future resonates with arguments found in the PD discourse (Bratteteig and Wagner, 2016).

The recruitment of CWS experts into the procurement process in the DigiBarnevern-project is reminiscent of, and further extends, the suggestions put forth by Bødker and Grønbæk (Bødker and Grønbæk, 1991). They see a tendency that many are recruited based on power relations within an organization, such as middle management, who might only have an abstract idea of the tasks of frontline workers. They suggest recruiting diverse participants for PD projects based on their tacit knowledge and expertise of daily work practices, either through the election of representatives or by recruiting those most enthusiastic about participating. In the case of DigiBarnevern, both recruitment tactics took place. CWS experts were either encouraged by management in their municipality to participate or by applying for an official position in the project, thereby having a specific interest. Bødker and Grønbæk (Bødker and Grønbæk, 1991) highlight the resources needed for real or ‘genuine participation’ in large projects. Representatives cannot be expected to do their normal workload in addition to contributing to systems development and design work. Their contribution to design work should be valued and, therefore, the management must plan to free them from at least part of their day-to-day work. Unfortunately, the number of resources needed to facilitate end-user participation is underestimated in many public sector development projects (Torvinen and Ulkuniemi, 2016). Though the DigiBarnevern-project embedded CWS experts in full-time or part-time positions, it remains to see if there is enough representation to avoid some of the significant issues other public projects have experienced in systems implementation.

Procuring a future system in the DigiBarnevern-project involved negotiations including end-users, CWS management, municipal officials, and potential suppliers, followed by decision-making at multiple organizational levels. Therefore, the effect of user participation on decision-making is difficult to isolate as practices embedded the involvement of CWS workers throughout. In the findings, we presented an example of CWS experts vocalizing the needs of children and families in interviews as they were also involved in mapping citizens' needs. Though the emphasis on citizens’ participation was mainly the concern of the citizen services subproject, the interconnectedness of the two systems led to discussions of whether citizen needs were preserved in the procurement process. In this way, the knotworks formed in the procurement project did not only send direct participants but a larger user base as the result of being involved in mapping users’ needs. However, that caseworkers and others in CWS represent citizen perspectives is not a fully unproblematic practice. In a qualitative study of parents with minority backgrounds in contact with Norwegian CWS, some reported countering narratives to caseworkers and the experience of being ‘othered’ by caseworkers and CWS (Fylkesnes et al., 2018). How well citizen perspectives have been cared for in the development of systems remains to be seen.

This finding aligns with those of Andersen et al. (Andersen et al., 2015), where participants’ perspectives were translated and represented through policy reports, evaluations, and prototypes that informed decision-making in design. Specifically for social work, they state that children ‘thus bring with them a network of people, institutions, reports, histories, problems, and concerns. These elements constitute children as participants, they mediate and form the participation of children’ (Andersen et al., 2015, p. 257). Participants are seen not as isolated subjects representing only themselves but as network configurations (Andersen et al., 2015). This is a similar view of participation as described by Bødker et al. (Bødker, 2017), where they view networks of people as the constellations that emerge through infrastructuring, with knotworks being more temporary forms of networks that are formed, for example, in development projects. The following subsection will expand on the network perspective and participatory infrastructuring.

7.3 Building on Participatory Infrastructuring

We view the case of procurement in DigiBarnevern as participatory infrastructuring as defined by Bødker et al. (Bødker, 2017), that is, the situated, day-to-day, and often seemingly mundane decisions that are made behind the scenes in creating official documentation that shapes the project’s future outcomes. Since the DigiBarnevern-project presents a major shift not only in terms of digital systems but also in CWS work practices, we allege that decisions related to who gets to participate in writing systems requirements in the procurement process will have implications later. The reason for this is that municipal CWS will have to contend with administrative tensions that need to be resolved at the local level in the implementation phase and beyond. This infrastructuring work will require the commitment of local CWS management in the affected municipalities focusing on long-term sustainability and embeddedness in existing social structures (cf. Bødker, 2017; Karasti and Syrjänen, 2004).

As described in the findings, early decisions related to the project’s scale also affected how participation was practiced in the procurement processes. The scaling-up of development projects has been regarded as a major challenge to participation (Neumann and Star, 1996; Roland et al., 2017). This is due to the increased complexity of, for example, practicalities related to organizational structures, the allocation of funding, and, most importantly, where the main authority for decision-making lies (Blomberg and Karasti, 2012). In our study, we found that larger municipalities with greater access to resources were responsible for much of the preparation work, leading to a power imbalance as smaller municipalities did not engage much in the decision-making process. Despite an attempt to address this imbalance by interviewing caseworkers from smaller municipalities and invitations to public hearings, this problem mainly remained unresolved since smaller municipalities lacked the resources to participate directly in the procurement from start to finish. These findings reflect the issues of spatial scaling of participation in that new infrastructure will be implemented at several municipalities, all with their own existing sociotechnical structures. Though spatial scaling issues have, thus, been described, empirical research on these issues is still lacking (Bødker and Kyng, 2018; Karasti, 2014).

Infrastructuring provided a useful lens through which to understand the procurement of DigiBarnevern’s case management system as part of a larger process that not only created new systems but also will shape new work practices for municipal CWS caseworkers. Viewed as infrastructuring, the practices performed in the context of procurement presented in this paper can be seen as a way of scaling participation. Building on the concept of participatory infrastructuring (Bødker, 2017), participation includes much more than the work done with users in workshops and other collaborative activities; it is also a continuous process that takes place over time at multiple levels, both horizontally and vertically, in an organization. Thus, it does not merely comprise of isolated participatory activities, but also in the writing of requirements and the inclusion of end-user representatives in various knotworks.

Consequently, understanding participation as something that also takes place behind the scenes—that is, decision-making in between workshops and user testing—provides a more nuanced view of how participation can scale up than in the traditional service design view of participation. Work practices centering around the new case management system will change in different ways depending on the context the system will be implemented. This provides challenges in writing the requirements, as additional considerations are to be made, and in establishing knotworks that attempt to represent all users. Here some municipalities participated more directly than others as they had the resources and an existing infrastructure that supported electing CWS experts to participate in knotworks and decision-making. Though challenges to user participation are often seen as an issue of the designer opening the decision-making process to users, the users’ context can also hinder their ability to participate.

In sum, we see participatory infrastructuring executed in the project in the way it was scaled up, the placement of CWS experts in decision-making positions throughout development, and the opening of some avenues for future decisions during the procurement process while closing others. This led to a view of participation as embedded in practices within the project that included remnants of CWS voices. In the context of the procurement process, essential decisions were made that profoundly affected how a developing system would function and therefore constituted a pivotal moment that crystallized the articulation of previous participatory activities.

8 Conclusions

This paper contributes to the discussion on participation in CSCW infrastructuring processes by presenting a case of new system procurement for municipal CWS. Particularly, we elucidated procurement’s role in shaping the outcome of infrastructuring processes, as well as its effect on defining how user participation in systems development is facilitated. The act of procuring systems in the public sector, through writing and publishing a tender report, has crucial implications for subsequent choices. The infrastructure practices that were triggered by the procurement process, and identified through analysis, related to the project’s scaling, the positioning of CWS workers, and the opening of avenues for future decisions.

Our analysis illustrated how early-stage infrastructure practices significantly influence CWS practices and participation. First, we have underscored this impact on project scaling regarding the procurement of the system and the parties with whom the project is negotiated and solidified. Thus, the project’s scale is determined in the tender, which—in turn—delineates who will participate in which stages of development. Any flexibility is established by the tender and/or negotiated between the customer and supplier. Second, we have shown that positioning CWS workers in different positions related to the development process is a way to embed subject experts into participatory activities. This approach allows experts to share their own experiences and opinions while working directly with IT specialists and participating in collaborative activities with other end-users, such as interviews, user testing, and workshops. Finally, we have shown that the procurement process, in the case of DigiBarnevern, opens avenues for further participation while closing others. This view of procurement in an infrastructuring light has not been explored much by existing CSCW; however, this study aims to highlight the realities of public procurement and the tendering process as an important factor in determining participatory practices.

Our study was empirically limited to findings regarding the early stages of the design and procurement process, focusing on case management systems and caseworker participation. Therefore, subsequent studies of this case seek to investigate other aspects of the DigiBarnevern-project, particularly participation by citizens as end-users, the development of citizen services, and other phases of the infrastructuring process, like that of implementation. Having focused on the planning and procurement phases, we do not unpack the results of participatory activities or infrastructuring work during the project’s later stages. Additionally, the context of this single case study is inspired by Scandinavian democratic ideals and with a participatory agenda while adhering to CWS and municipal CWS regulations and the organizational structure of the Norwegian public sector. However, we encourage similar studies on procurement’s role in relation to participation in the CSCW community.

Appendix

Table 3 Analysis stages