Keywords

1 Introduction

In most of today’s organizations competition is hard. Providing for innovation and rapidly adapting to changes driven by the business and organizational environment is a matter of survival. In order to be able to organizationally sustain innovation capability and support the evolution of services and processes, the IT infrastructure must adapt to changes as well as provide a base for future innovations.

End-User Development (EUD) (Lieberman, Paternò, Klann, & Wulf, 2006) allows domain experts to tailor and customize their software. However, non-IT professionals are not always incentivized or even welcome to change the IT infrastructure (Dittrich, Lundberg, & Lindeberg, 2006). This chapter addresses the question of what it takes to include EUD as part of a developing and evolving IT infrastructure of an organization as a means of supporting continuous organizational innovation.

The chapter reports the re-analysis of two case studies:

  • Case 1 – The Telecom Provider: Empirical research took place from 1999 to 2006 concerning IT support for the back office and economic unit. In long-term engagement, both the development of a tailorable application supporting specific tasks and the flexible integration of different applications were addressed (Dittrich et al., 2001; Eriksson, 2008; Eriksson & Dittrich, 2007). Though not at that time a focus of the research collaboration, the IT unit and business units worked closely together to handle the flexibility necessary to co-design work practices and technologies (Dittrich & Lindeberg, 2002, 2004).

  • Case 2 – The UN University: Empirical research took place from 2008 to 2013 on the Participatory Design (PD) of the IT infrastructure for a university. Though the technical base was crucial for providing enough flexibility (Bolmsten, 2016), collaboration between end-user developers and the IT professionals turned out to be important as well (Bolmsten & Dittrich, 2011). To support the co-development of work and business practices and the supporting technology, participatory approaches were developed at the project and organizational level of structures and processes for participatory IT management (Bolmsten, 2016).

Both cases turned out to address EUD and flexible technical infrastructures to support organization and work practice change and innovation. In both cases, a sustained culture of EUD was developed. These similarities triggered a meta-analysis of the two cases: Yvonne Dittrich has been part of both projects as a principle investigator PhD supervisor, respectively. While engaged on the latter project, similarities between the two projects became visible. Jeanette Eriksson is one of two PhD students who worked on the telecom provider case. Johan Bolmsten completed his PhD studies while employed as an IT officer at the UN University.

Based on our meta-analysis, we recognize how flexible technologies are an enabling factor that needs to be complemented with empowered employees who are entrusted with making (design) decisions, and constructive collaboration between IT professionals and end-user developers. These three factors need to be supported and complemented by organizational structures and processes that provide a frame for organizationally accountable development and the evolution of a common IT infrastructure. The concepts, together with their interaction, can be regarded as an empirical theory grounded in the meta-analysis of the two case studies. An analytical framework is put forward that relates the observed sustained EUD to technical, organisational and collaboration practices. In the discussion we argue that such sustained EUD becomes part of the continuous day-to-day infrastructuring that, in turn, is a central contribution to the innovative capabilities of an organisation.

The remainder of the chapter will be structured as follows: Sect. 2 discusses related work with respect to EUD, innovation, and IT infrastructures; Sect. 3 discusses the research approach of the meta-analysis; Sect. 4 present the relevant aspects of the two case studies; Sect. 5 then discusses the findings and develops the core concepts and their relations; Sect. 6 sums up the conclusions and discusses the study’s limitations as well as possibilities for future research.

2 Innovation, End-User Development, and Infrastructuring

In order to provide the necessary background to understanding the further discussion, this section discusses related work around four concepts: innovation, EUD, IT infrastructure, and infrastructuring. As innovation and infrastructuring are not commonly associated with EUD, they warrant a more comprehensive discussion. The first Subsect. 2.1 develops a modern concept of organizational innovation by relating democratized innovation to organizational processes of learning and innovation. In the organizational arena, user-driven innovation is dependent on an evolution of the enabling technical infrastructure. Subsect. 2.2 presents research on EUD that focuses on providing and using technically flexible infrastructures to support the evolution of the organization. Sect. 2.3 then presents state-of-the-art understanding of “infrastructuring” (Karasti, 2014; Karasti & Syrjänen, 2004) as a way to conceptualize the social aspect of the socio-technical design and evolution of the infrastructure that is needed to support organizational innovation.

2.1 Democratized Innovation in the Organization

Organizations have become faced with the challenge of developing and sustaining capabilities for innovation to cope with the increased pressure for change, the acceleration of globalization, and the possibilities that come with new information technologies (Ober, 2008; Orlikowski, 2002). According to Lawson and Samson (2001), an innovation capability is the “ability to continuously transform knowledge and ideas into new products, processes, and systems for the benefit of the firm and its stakeholders.” At the same time, both the capability to innovate and the understanding of how to put innovations to use is a learning process that must continuously develop (Lawson & Samson, 2001).

Current developments in the understanding of and conditions for innovation provide new opportunities for organizations faced with the challenge of innovating. Using the concept of “democratizing innovation,” von Hippel (2005) shows that in many cases it is the users of technology who actually take the first step that leads toward basic innovations. According to von Hippel (2005), user-centered innovation processes offer great advantages in that users can develop exactly what they need. These differ from the traditional model in which dedicated designers and engineers develop products and services. In this traditional model, the user’s role is to have needs, which are funneled in design and where somebody else develops solutions (von Hippel, 2005).

This new innovation trend is supported by technological developments that enable users both to innovate IT products and services and to share their innovations. When it comes to IT, the users’ ability to innovate is radically and rapidly improving in line with the quality of computer software and hardware, increased access to easy-to-use tools and components for innovation, and enriched innovation commons (von Hippel, 2005). This is illustrated, for example, by free and open source software projects, which are in many cases well developed. It is further illustrated by the potential of new internet-based innovation communities, in which individual users do not have to develop everything they need on their own: they can benefit from innovations developed and shared by others. Users joining together in networks and communities provide useful structures and tools for their interactions and for the distribution of innovations.

Different spheres of user-centered innovations can be distinguished. Von Hippel (2005) focuses on the benefits to the consumer in the marketplace of user-centered innovations, and how innovations by users provide a necessary complement and feedstock to manufacturer innovation. Companies are well advised to open their innovation models to incorporate the innovations especially of lead-users of their services and products in their business models: “if […] the information needed to innovate in important ways is widely distributed, the traditional pattern of concentrating innovation-support resources on a few individuals is hugely inefficient” (von Hippel, 2005, p. 14). Björgvinsson, Ehn, and Hillgren (2010) discuss democratized innovation from the point of view of public spheres and everyday life. They address the question of how open innovation milieus can be participatory designed for the user as a citizen, and how new constellations, issues, and ideas evolve from bottom-up and long-term collaborations among diverse stakeholders.

In this chapter, democratized innovation is discussed from the perspective of users as members of organizations. Democratized innovation, in this respect, is about the need for organizations to take advantage of the capabilities of their own members. User-centered innovation by organizational members is needed for organizations to develop new products and services as well as internal operations (Manville & Ober, 2003; Ober, 2008). Organizations need to make use of and cultivate the capabilities of their members, the communities that they are part of, and the networks that they have access to – inside and outside the organization. This is a process that involves both user-centered innovation and organizational learning of how to make use of innovations to add organizational value. Orlikowski (2002) recognizes that especially when it comes to complex organizational change, the collective capabilities of organizational members need to be drawn on, with a focus on “organizational knowing as emerging from the ongoing and situated actions of organizational members” (Orlikowski, 2002; Suchman, 1987, 2007).

The need to combine bottom-up innovation and learning processes that take their stance with organizational members is addressed by Andreu and Ciborra (1996), ranging from improvements of routines to strategic capabilities, and involves both what can be referred to as “bricolage” and “radical learning.” The former relates to incremental advances through situated tinkering by organizational members to improve their everyday work, and the latter concerns bringing about radical change by becoming aware of what the context is and explicitly stepping out of the box and innovating in a new manner (Andreu & Ciborra, 1996). Combined democratized and user-centered innovation and organizational learning challenge traditional approaches to information system management, where top-down planning-oriented management schemes are not sufficient to keep up with innovation and learning pressures (Andreu & Ciborra, 1996; Ciborra, 2000).

In Eriksén (1998), shop floor IT management by users is recognized as highlighting their capabilities to cater for the development of their own software support to the benefit of the organization. How such “design in use” complements a traditional “use for design” in the user-centered development approach PD is further developed by Dittrich, Eriksén, and Hansson (2002). In the analysis of two cases of software support in a municipality and a public service one-stop-shop, respectively, they find that important development activities are going on “in the wild,” which are managed by the users themselves with only a secondary dependence on IT professionals. In “From control to drift,” Ciborra (2000) analyzes a number of infrastructure development projects in multi-nationals with regard to how bottom-up development initiatives are important to understanding the dynamics of corporate information infrastructures; nevertheless, such development initiatives are found to appear to be “drifting” (anarchic) compared to the wisdom of the predominate information system management approaches.

In the chapter by Cabitza and Simone (2017) a conceptual framework called the Logic of Bricolage is developed to understand the technical malleability of systems to allow end-users to both make incremental improvements and innovate new solutions. Our cases focus on socio-technical dimensions enabling such practices. The comparative analysis of our two cases shows how EUD can become an integral part of such organizational user-centered innovation. Based on the observations, the discussion section indicates how the user-centered innovation of IT infrastructures can be contained and supported by IT management structures that make EUD practices organizationally accountable.

2.2 End-User Development

EUD and end-user software engineering (Ko et al., 2011) address tools and techniques that allow non-IT experts to develop software applications, such as Excel sheets, or finalize the design of software, as when developing the filters of an e-mail reader, through an interface that is understandable to non-IT professionals. In this volume, Ludwig, Dax, Pipek, and Wulf (2017) put forward a practice-oriented definition of EUD where EUD is defined to occur whenever an end-user has to switch to a lower language layer to fulfil a specific task. An open question identified that relate to the contribution of this chapter is how to support cooperative approaches in order to allow end-user developers to together develop IT-support of different technical complexities. Whereas the EUD community in the US emphasizes programming language technologies to support non-IT professionals, the European part of the community emphasizes the need to understand the context in which EUD takes place in order to support not only the individual end-user developer but also the sharing and evolution of the results of EUD. As the analysis presented in this chapter focuses on the deployment of EUD and sustainable innovation, the research on cooperation around EUD and its connection to the organizational arena is most relevant here.

From the very start, the research on EUD has not only addressed the tools and interfaces for EUD but also the sharing and cooperation around the tailoring of software. One of the very first articles, “There’s no place like home: continuing design in use” by Henderson and Kyng (1992), discussed the sharing of EUD results. In “A small matter of programming,” Nardi (1993) analyzes, among other things, the role of super users of customizable Computer Aided Design (CAD) software to support other users in the organization and how to quality assure and support the sharing of macros and customizations. In these early cases, the end-user developers and users cooperated around the adaptation of individual performance tools.

However, organizational and cooperative aspects became more prominent when EUD research extended into contexts where EUD tasks concerned the adaptation or provisioning of common resources or infrastructures. An early example is the research reported by Trigg and Bødker (1994) in “From implementation to design: tailoring and the emergence of systematization in CSCW.” The development of a set of form letters to be shared among the employees of a public agency in Denmark was considered to be of an organizational importance that warranted an organizational process to review and approve the form letters by a committee of lawyers. Likewise, the tailoring of a common cooperation infrastructure used by ministerial employees that cooperated between Bonn and Berlin during the transition of the German government to the new capital in the 1990s needed to be subject to negotiation and discussion, as EUD did not only affect individual work tools (Pipek & Kahler, 2006). Dittrich et al. (2006) mention deliberation and quality assurance in the context of configuration and customization of mission critical systems as two of the central challenges for EUD in such contexts. However, the research of Wulf (1999) on the tailoring of access rights indicates that EUD can be used to implement and assure compliance with organizational strategies. To date, the research on the organizational side of EUD has, in most cases, been analytical.

Reflecting on their experiences, Pipek and Kahler (2006) provide a categorization of cooperative tailoring scenarios: most of the early projects, like that of Henderson and Kyng (1992), fall into the shared usage scenario that requires the least coordination, whereby user groups are a self-help feature in both commercial and private contexts. The tailoring of CAD systems reported in Nardi (1993) is an example of the shared context scenario that requires better possibilities for sharing customizations, but might result in conflicts if changes to the individual tool hinder the sharing of work results. In a shared tool scenario, as in the case of form letters by a public agency (see Trigg & Bødker, 1994), the group needs to negotiate not only the adaptations but also the usage of the common tool with the adaptations.

Shared infrastructure scenarios, the last of Pipek and Kahler’s (2006) categories, have been and still are the least researched scenarios. Here, tailoring results can affect configurations of other systems. The shared infrastructure scenario also provides additional challenges. The design space for EUD of an individual application is constrained by interoperability requirements. Both the cases discussed in our meta-analysis fall into this scenario. Heterogeneous user groups are dependent on each other, though they share neither a common work practice nor a common tool.

Another challenge that might also be responsible for the difficulties in researching cooperative EUD in shared infrastructure scenarios is that the evolution of shared infrastructures often involves collaboration between users, end-user developers, and IT professionals. The notion of meta-design (Fischer, 2010) has been introduced to describe the need for software engineering of EUD systems to target the design of design environments for end-user developers. Fischer (1998) also coined the term of “seeding – evolutionary growth – reseeding” to describe long-term cooperation between users and IT professionals in the context of EUD, whereby the IT professionals provide initial design environments with currently needed building blocks as a base for EUD. Over time, the dynamics of usage and EUD practices result in requirements that cannot be supported within the current state of the EUD environment. In this situation, IT professionals are required to evolve the EUD environment. Fischer’s concepts have informed the design of successful EUD environments (Costabile, Dittrich, Fischer, & Piccinno, 2011).

Shared infrastructure aspects have already been discussed in earlier publications on the projects presented here: Dittrich and Lindeberg (2002) observe that in infrastructures supporting data-intensive businesses like telecommunications, the flexibility of a specific application can only be deployed when other applications in the same network and the interoperability platform are tailored accordingly (Dittrich & Lindeberg, 2002). The importance of combining EUD and professional development activities when evolving such a common infrastructure and gaining support for it has been raised in both cases (Bolmsten & Dittrich, 2011; Bolmsten, 2016; Eriksson, 2008; Eriksson & Dittrich, 2007). In our comparative analysis, we go one step further: we aim not only to understand how EUD can take place in a shared infrastructure setting but what it takes to integrate EUD and infrastructure development in order to sustain the innovation capacity of an organization.

2.3 IT Infrastructures and Infrastructuring

Infrastructures and their maintenance and evolution have been subject to discussion in their own right in the Information Systems and PD communities. Inspired by observations similar to the ones leading to Eriksén’s (1998) concept of “shop floor IT management,” Karasti (Karasti, 2014; Karasti & Syrjänen, 2004) developed the concept of “infrastructuring.” Karasti (2014), here, refers to Star and Ruhleder’s (1994, 1996) salient characteristics of information infrastructures.

Star and Ruhleder (1994, 1996) use information infrastructures to analytically target technology development that goes beyond the local project and to discuss how technology affects organizational transformation. Based on their analysis of the development of a distributed information system that served as a platform for archiving and exchanging data in a scientific community, eight characteristics of information infrastructures are described: (1) embeddedness in other social and technological structures and arrangements; (2) transparency in invisibly supporting tasks; (3) spatial and temporal reach or scope; (4) the taken-for-grantedness of artifacts and organizational arrangements, learned as part of membership in a community; (5) infrastructures shape and are shaped by conventions of practice; (6) infrastructures are plugged into other infrastructures and tools in a standardized fashion, though they are also modified by scope and conflicting (local) conventions; (7) infrastructures do not grow de novo, but wrestle with the inertia of the installed base and inherit strengths and limitations from that base; (8) normally invisible infrastructures become visible upon breakdown. These eight characteristics stress situated and socio-technical relations. The analysis of infrastructural relations provides an understanding of infrastructure development that, according to Star and Ruhleder (1994), moves away from a conception of infrastructure as a substrate of “something upon which something else runs or operates” to infrastructure as something that is constantly “in the making” (p. 252). The possibility of infrastructures as “genuine universals,” where tasks to be automated are well-structured, the domain well understood, and system requirements determinable by formal a priori needs assessments, is challenged by this definition (Star & Ruhleder, 1994, 1996). In Star and Bowker (2002), the discussion is extended to implications for infrastructure development and a focus on “how to infrastructure.” This includes the challenge of designing for flexibility and the need for the infrastructure designer to always be aware of the multiple set of contexts upon which her work impinges.

Karasti and Syrjänen (2004) approach infrastructures from a bottom-up point of view, compared to Star and Ruhleder (1994, 1996), who are concerned with large infrastructure projects. Through two cases in very different contexts, one community of dog hobbyists and one community of information managers within a large-scale research network, Karasti and Syrjänen (2004) develop an understanding of community PD. The community members in both of these cases exhibit common traits: a community identity through common causes, shared interests, and strong commitments. In addition, they take long-term responsibility for their work domain and for both existing systems and procedures and the development of new ones. The notion of “infrastructuring” is applied to sensitize the understanding of infrastructure maintenance and development as a procedural, ongoing, and multi-relational activity that unfolds over extended periods of time (Karasti & Syrjänen, 2004). In order to deepen the relational understanding of infrastructures, Karasti and Syrjänen (2004) also connect infrastructuring to Suchman’s (1987, 2007) notion of artful integrations, which refer to hybrid systems comprising media, material, and practices. This emphasizes a “located accountability” of design, where change becomes a part of everyday practice, and further highlights design as a continuous process of inscribing knowledge and activities in new material forms.

Infrastructuring can be further understood in an organizational context through Pipek and Wulf’s (2009) framework of infrastructural layers of technology development. Their framework takes a stance on the “work infrastructure” of in-situ development activities and connects these to preparatory and background related activities. In addition, work- and technology-related activities are distinguished. In the framework, infrastructure development is triggered by “points of infrastructure” at which an infrastructure becomes visible to its users (and IT professionals), either during instances of infrastructure breakdowns or local innovation. As the infrastructure becomes visible, the activities that contribute to that specific part of the infrastructure development become visible as well. This can, in turn, trigger new work and technology design in the supporting infrastructure layers, such as method-driven design activities (preparatory) and basic development of work and technology standards (background). Pipek and Wulf (2009) further highlight the role of end-users and their EUD activities, observing that any actual work infrastructure includes numerous user innovations, and that IT professionals are rarely, if ever, able to take full account of the evolution of the systems and practices involved in the local accomplishment of work goals. They further argue how a wide variety of work practices – tasks, routines, and praxes – prepare both users and professional designers for “points of infrastructure” design. In this volume, Rohde & Wulf (in, press) develop a process framework of Integrated Organization and Technology Development (OTD) to facilitate change in organizational structures and processes with their supporting IT-infrastructure. The process framework has been developed over time to support a practice-based research perspective in a number of empirical cases that are characterized by parallel development of work practice, technical, organizational systems. In Bolmsten, (2016), participatory IT management structures and processes are proposed that support the linking of different work and technology layers in organizationally accountable infrastructure development, which are independent of the support and intervention by researchers. The focus is on managing integrated technical and organizational change through empowering end-users to participatory in sustainable change processes. These proposals are taken up and further developed in this chapter.

2.4 Summary

The interrelated work on democratized innovation, organizational innovation, and learning indicates, on the one hand, that there is a need to acknowledge user innovation of the IT and work infrastructure as part of the innovation necessary for an organization to continue to perform in a changing environment; on the other hand, such user innovation is regarded as (anarchic) drift that is in contradiction to the traditional IT management frameworks (Ciborra, 2000). The observation of such “shop floor IT management activities” (Eriksén, 1998; Dittrich & Eriksén, 2002) inspired the development and exploration of the notion of “infrastructuring,” as such innovation and design activities involve maintaining and evolving the IT infrastructure. EUD has been identified as a core activity in such scenarios (Bolmsten, 2016; Pipek & Wulf, 2009).

The current chapter sets out to explore what is needed to sustain EUD activities to better the organization and to correspondingly underpin EUD as an innovation capability of the organization. Sect. 3 that follows discusses the research methods before the following section presents the analysis of two cases focusing on the relevant dimensions of the resulting model.

3 Research Methods

Both case studies examined in this chapter were designed and researched as independent projects. Both of them applied Cooperative Method Development (CMD), an action research approach combining qualitative empirical research with software engineering tool, method, and process improvements (Dittrich, Rönkkö, Eriksson, Hansson, & Lindeberg, 2008) The research results of each case have been published prior to the meta-analysis undertaken for this chapter. Table 1 summarizes the fieldwork supporting the meta-analysis for both cases and the prior publication in the context of each case. The specific research method applied in each case is briefly introduced in the case descriptions. The method section here refers to the method of meta-analysis. The Subsect. 3.1 describes the meta-analysis performed. Thereafter in Subsect. 3.2, we discuss what measures we have taken to assure the trustworthiness of the research.

Table 1 Research methods and earlier results related to the two cases
Full size table

3.1 Meta-Analysis

The chapter aggregates qualitative research from two case studies. A common way to aggregate qualitative research is multiple case studies (Yin, 2013) or meta-ethnography (Britten et al., 2002). Multiple case studies are typically designed as such, and the cases are chosen to triangulate specific research questions. Meta-ethnography involves aggregating published research based on articles. This case is a hybrid between the two: research on each case took place independently of the other. Both cases are based on long-term engagement. A strict control for the sake of comparability would not have allowed us to follow the dynamics of the collaboration. Furthermore, the two cases took place one after another, and it was not anticipated that there would be common themes emerging from the research. Compared with a meta-ethnography, the meta-analysis does not only refer to the published results but is also able to take the original field material into account. Below, we describe how the meta-analysis was conducted.

Both case studies resulted in new insights about EUD, cooperation between users and organizational units, and IT professionals and their departments. Given a prior understanding of common threads in the empirical material, the researchers involved met for a brainstorming session on how innovation, IT infrastructure, and EUD were interrelated in the field material. Episodes of the respective field materials resulted in an initial identification of common themes.

This initial set of themes was used to identify relevant sections in the field material. The researchers then went back to their original analyses and the field material itself using the themes in an axial coding manner, identifying supportive and contradicting evidence. The results were used not only to refine the set of themes but also to identify relationships between these themes.

The results were again integrated, giving us a first version of Fig. 1, representing an empirical theory grounded in the two cases. The initial figure was then used as a basis for theoretical coding, resulting in a refined version of the figure and theory.

Fig. 1
figure 1

Empirical theory based on two cases

Full size image

The meta-analysis informed an empirically grounded theory relating how technology, people, and organizational aspects contribute to sustainable organizational innovation capabilities.

3.2 Trustworthiness

To assure trustworthiness of the meta-analysis, on the one hand, we relied on the quality assurance of the original research detailed in Table 1; on the other hand, we worked with both data triangulation across the cases and researcher triangulation.

A comparative meta-analysis of the two cases situated in as widely differing domains as education and telecommunication, in itself provides an indication that the developed, empirically grounded theory is sound. Relating different cases to the same codes and concepts forced us to sharpen our conception.

Researcher triangulation assures that the judgments, e.g., on codes and the relationship between concepts and empirical material, are inter-subjective. The first author has been involved in both cases and is able to triangulate the main fieldworkers’ analyses in both cases. Further, the cooperation between researchers not engaged in each other’s cases forced us to explicate our at times tacit assumptions and to explicate the relations encountered.

Finally, we provide a thick description (Ponterotto, 2006) to allow the reader to review our analysis and discussion.

Sect. 4 presents the two cases based on the categories identified as constitutive for sustainable EUD.

4 The Two Cases

In this section, we present and analyze the two cases. For each of them, we first give an overview of the case and the major lines of research. We then present the original research approach and methods. The following subsections then focus on the need for change that was the rationale behind the observed EUD practices, the organizational characteristics that sustained EUD as an organizational practice, and finally the organizational IT management that provided a frame for this sustained EUD. An overview of these building blocks and their relations is given in Fig. 1, which illustrates our meta-analysis (see Sect. 3). Our resulting empirical theory of how the different building blocks contribute to sustainable EUD as infrastructuring is discussed further in Sect. 5.

4.1 Telecom Case: Innovating for Changing Business Practices

The telecom case was carried out in cooperation with a major telecommunication operator in Sweden. Since this line of business is characterized by rapid change, the company’s information infrastructure and development processes need to support frequent change. Telecommunication operators remain competitive by, among other things, being innovative and introducing new types of services to their customers. Their business system must therefore be upgraded to continuously support these new services. In such a fast-changing world, flexible software is beneficial to prevent it from becoming obsolete. Because changes are very fast, it takes a lot of effort to keep business systems up to date. To come to terms with this problem, the telecom operator had invested in making some systems tailorable by the end-user (Dittrich & Lindeberg, 2002; Dittrich et al., 2006), and started to cooperate with the researchers of this study in this pursuit. In the beginning, the research focused on a contract and payment system – from hereon called “the payment system.” To keep up with changes in the telecom market, new payment types had to be created at short notice. The payment system was used to compute payments based on contracts that were modelled in the system, and the payments were triggered by specific events. The data describing the triggering events were periodically imported from another system. It became evident that the communication and data exchange between systems constrained the flexibility of the individual applications. In a second cooperation project, we therefore focused on flexible connections in the infrastructure: the researchers developed concepts and prototypes to provide the end-users with the possibility to tailor the communication paths and data flow between different systems – a possibility to manage the system infrastructure. This second part of the cooperation focused on how to structure a tool that made it possible for end-users to manage a large infrastructure and at the same time facilitate use, tailoring, and further development of the tailoring capabilities (Eriksson, 2008).

From the very beginning, it struck us that the users were treated as equal members of the development team and engaged in tweaking the system and developing workarounds where necessary in cooperation with the IT professionals (Dittrich & Lindeberg, 2001, 2004). When so engaged, it is important that the users are aware of the possibilities and limitations of the software, so they can recognize when tailoring is not enough. The tailoring capabilities are always limited, meaning that tailoring cannot support completely unanticipated changes. The tailoring capabilities must therefore be extended, and tailoring activities must be coordinated with software evolution activities performed by IT professionals. The second study with the telecom provider (Eriksson, 2008) shows that it is possible to benefit from both user and system perspectives through collaboration between users, tailors, and IT professionals. It is necessary for users and IT professionals to collaborate closely in order to make tailorable information systems both durable and innovative to the business environment. In this way, the development of useful, sustainable software, which adapts easily to changes in an evolving environment, can be achieved.

4.1.1 Methods of Original Research

The study followed the CMD methodology and implemented two research cycles with three iterative phases: (1) understanding the problem, (2) cooperation to make improvements, and (3) implementation and evaluation. Both cycles involved the development of prototypes as part of the improvement based on the findings in the previous phase. The research approach adopted in the second phase may be termed “design science research,” as the projects started out by defining the research question based on business needs and unexplored issues in the research discourse. Design research has been discussed in several papers, among others Nunamaker, Chen, and Purdin (1991), March and Smith (1995), Hevner, March, and Park (2004), and Peffers, Tuunanen, Rothenberger, and Chatterjee (2007). In 2016, Rohde, Brödner, Stevens, Betz, and Wulf (2016) published an evolved version of Design Science Research called Grounded Design (GD). In retrospective, the Telecom case can be seen as Grounded Design as the study implements the GD principles (Rodhe et al., 2016). The prototypes were iteratively developed and evaluated in cooperation with IT professionals and users at the telecom company. In another chapter in this volume, Tetteroo and Markopoulos (2017) discuss how to evaluate successful deployment of EUD technology and how EUD should be postponed until the host technology is accepted by the users. In line with their recommendations, the prototype in the Telecom case was implemented on top of existing software. The evaluation involved not only technical issues but also addressed “how” and “why” the prototypes worked. In other words, issues such as user knowledge, collaboration, and organizational aspects were considered in the evaluation.

In both studies, the collected data were analyzed in a qualitative manner. Coding schemes were developed, taking field notes and transcripts as a starting point. For specific research questions, multiple sources of data were combined. For quality assurance, member checking and researcher triangulation were applied.

4.1.2 Need for Change

As mentioned above, the motivation to explore the use of flexible technical solutions allowing for EUD stemmed from the market competition that forced the telecom operator to devise and compute new payments to keep up with the changing telecom market. The payment system that was the subject of cooperation had several predecessors, all of which were suitable for the needs at hand but unable to scale or to provide the necessary flexibility for future development needs. Each solution supported a number of contracts and payments but failed to support innovative marketing strategies. This resulted in only part of the payments based on events being able to be handled automatically by the regular payment system. Innovative contracts and payments, which were called “extra payments,” needed to be handled and computed manually once a month, just like the regular payments. The computation of the extra payments was done based on database queries and complex spreadsheets.

Each generation of the in-house developed system included the current extra payments as regular payments in the new system. Experience suggested that it was impossible to anticipate what future extra payments would look like and which details were needed. It became clear that this situation was set to continue: the competitive telecom business was forcing the company to come up with new services on a continuous basis, which consequently resulted in new types of payments that could not be handled through the system. These extra payments were based on new types of events, which meant that new types of datasets were needed. This resulted in the innovation of a new approach to not only replace manual computation but also support EUD of contract types and payments as well as user-defined assembling of data from different systems.

Besides a more flexible payment system, this required an event definer/handler that was able to communicate with any system in the infrastructure. What was needed was an infrastructure tool for inter-application communication, which could be adapted by the user. At the same time, it was essential that the tool allow for expansion of the tailoring capabilities so that new data sources could be added.

What made the telecom case special at the time was that the EUD features where not introduced to support personalization of tools or the adaptation of generic software to any specific organization, but as a continuous development of part of the IT infrastructure in order to support business innovation on a corporate level.

4.1.3 Flexible Technologies as Enablers

From the very start, the exploration of flexible technologies to support this specific area of business was at the center of the cooperation. Creating prototypes that acted as mediating artifacts enabled exploration of what was required of the flexible technology to support EUD for business critical processes. One of the central insights was that not only EUD but three different interfaces needed to be considered: the tailoring interface, the deployment interface, and the development interface.

From the study, it was determined what was required of technology to act as an enabler for innovation (Dittrich et al., 2006; Eriksson, 2008):

  • Functionality for controlling and testing changes has to be integrated into the tailoring interface, and there must be sufficient technical support for the end-user to estimate and check the correctness of the computation.

  • A tailorable system has to support the development of a mental model that makes a clear division between normal execution and tailoring. This mental model must be adopted in the tailoring interface and shared by users, end-user developers, and IT professionals.

  • The tailoring interface also has to make the potential for unanticipated use visible. This means that the information given must, to a certain extent, exceed what is currently necessary.

  • The tailoring interface can be more complex, provided that the tailoring process makes the usage easier. The tailoring interface is not used as often as the deployment interface and the tailoring itself often additionally involves careful thought.

  • The developer expanding the tailoring capability should only interact with one clearly defined point in the tailorable system: that is, changes are made at one point in the system.

The flexibility for innovation of the technology was clearly recognized by the users in the business unit, both for its potential and its challenges. The following citation underpins the innovative potential of flexible technology.

This is interesting! It opens up new opportunities. It might be like one extra payment uses another payment as a base. (User comment, evaluation session, February 24, 2004, cited in Eriksson & Dittrich, 2007)

In a discussion with the business department of the potential design of a tailoring interface, one of the business unit managers indicated an organizational problem: if a change in the business practices does not require an IT development project anymore, the deliberation on what to offer has to be taken care of by the business units (Dittrich et al., 2001). For the technology to act as an innovation enabler not only must the “right” flexibility from a business perspective be implemented but also the support functionality in terms of control and testing.

4.1.4 Collaboration Between End-User Developers and IT Professionals

One of the central findings was that end-user developers and IT professionals needed to work tightly together to make sure that the IT infrastructure allowed the company to maintain its competitive edge. The fieldwork and evaluation established that it is impossible to know what future contracts and extra payments will look like. Therefore, there will always come a time when the end-user wants to establish payment types that cannot be supported in the current system, or use data that is not yet published in an available view. In such cases, IT professionals need to step in to develop new modules, implement a new view in the system, or update existing ones, and also to publish the relevant information on how to use and tailor the system.

Another issue related to communication and cooperation between users and IT professionals concerned the decision of how much information to make available for the users to do a good job of tailoring. The users wanted to see as much information as possible, within reasonable scope. The IT professionals would rather restrict the users’ options in order to have better control over the execution of the system and detach maintenance that would not necessarily impact on communication with the payment system. These two perspectives had to be negotiated. The culture of cooperation between users and IT professionals had a major impact on the evaluation of trade-offs between flexibility, usability, development effort, and change effort (Dittrich & Lindeberg, 2003).

In the telecom company, cooperation between business units and the IT unit worked very well. The users were quite aware of the limits of their own competences and knew when to consult the responsible IT professionals. All users frequently referred to IT professionals when they experienced something that was beyond them. As the IT professionals were involved in maintenance and operation of the software, they could, if needed, take over the adaptation, tailoring, and especially the testing of the changes (Dittrich & Lindeberg, 2003). Neither users nor IT professionals considered the necessary coordination and cooperation to be a serious problem.

4.1.5 Empowered Users

In the information systems and PD literature, users are often described as people with low power and influence that need to be supported in their participation; this definitely was not the case at the telecom provider. Users were equal members in the project teams and sometimes even shared project management responsibilities (Dittrich & Lindeberg, 2004). During participatory observations at the telecom company, the high expertise of the users was acknowledged, not only with regard to their tasks but also to managing the data available in the different databases that were part of the IT infrastructure. To be able to create new kinds of payment, data had to be collected from different sources and then pruned and aggregated using algorithms implemented as spreadsheets. To map requirements regarding the task at hand demanded expertise about the available data in the different systems. The communication between different systems was normally hidden from the user in a data communication layer for the separate systems, but users nevertheless acquired the knowledge necessary to perform the assembly of data.

The prototype created in the second study helped with the exact location of the data; for example, it guided the user to which fields to use by listing them with examples of the data they contained. However, the user had to understand the sometimes quite cryptic names and know where to look for specific data. Both users and IT professionals were aware of each other’s competences and the responsibilities for the different systems were clear to all parties. This contributed to transparency in the organization, whereby the users and the IT professionals knew whom to ask depending on what the question was.

Business knowledge about contracts and payments provided the basis on which the users decided what data to collect. Extensive business knowledge was a prominent feature of the results in the evaluation of the created prototype. The users’ reflections on which data to collect often concerned different aspects of the business tasks. The users were also well aware of which errors could occur, that is, errors concerning the use of the prototype, the IT infrastructure, and the task. Task-specific errors were, for example, particularly important for the end-user to monitor since they could cause serious consequences for the company if they were not caught. Concern over making errors was expressed in statements like this:

when you work as we do you must know a little about database management, you have to understand how the tables are constructed and how to find the information. And also in some way understand the consequences of or the value of the payment. In other words how you can formulate conditions and what that leads to. (User comment, evaluation session, February 24, 2004; cited in Eriksson & Dittrich, 2007).

In summary, the users’ awareness of system capabilities, fellow workers’ competences, and business cases made it possible for them to compile and execute data for extra payments. At the same time, users cooperated with IT professionals on equal footing in the development projects as well as the operation of the systems (Dittrich & Lindeberg, 2004). This required users to become trusted end-user developers (Eriksson & Dittrich, 2007).

4.1.6 Organizational Structures and Processes

From the very beginning of the research cooperation, it was striking how closely domain experts and IT professionals cooperated. This was partly due to the company’s project model. The workspace at the telecom company was organized as open plan offices. Initially, the IT unit was co-located with some of the users, and cooperation did not only take place in meetings but also by walking over to other people and having a chat about a problem or an idea. The IT project model was a specialization of the general project model that was used for any kind of change project. The model was structured around three decision points where the company-wide project committee decided whether to continue the project: the start of a pre-study was based on a document formulating the business unit requirements. The pre-study resulted in a document describing the outcome of the project in more detail and outlining the budget and a development model. For software projects, this document was complemented by requirements’ specification, a more technical implementation proposal, and a time-plan detailing implementation tasks based on the implementation proposal. The implementation proposal described the functionality of the future system at a more concrete level. This meant that it already contained a preliminary design.

The general project model required all affected organizational units to be represented both in the project team and in the steering committee. The same principle applied for users and IT professionals in the software development projects. The first study was related to a project developing a new and innovative version of the payment system. The project management of this project was shared by a general project manager from the business department and a technical project manager from the IT department. As further elaborated on in the previous articles (Dittrich & Lindeberg, 2001, 2004), the collaboration built on long-term contact and mutual appreciation.

IT professionals were not only responsible for new developments, but also for supporting operations of the system in the case of errors occurring. They also supported users, e.g., when looking for up-to-date and accurate data on which to base new payment types. The established way of cooperating across departments and the day-to-day cooperation around the operations of the system provided a sound basis for the continuous and flexible evolution of the system both through end-user tailoring and new developments.

In the studies, it could be observed that a flexible system requires an organizational structure to decide what changes can actually be reasonably implemented from a business point of view (Dittrich & Lindeberg, 2003). This requires cooperation between the IT unit and the business units around the deliberation of changes not only by IT professionals but also by end-user developers.

Further, the prototype demonstrating the possibility to tailor the interaction between other systems and the payment system showed the need for coordination across the infrastructure of the telecom provider: when preparing an extra payment, regardless of whether the process is supported by tailorable software or not, the user needs to know where to find relevant and accurate data. During some workshops, it became apparent that there was friction in the coordination between the payment system and the changes in the surrounding systems. Each one of these systems was itself the subject of both tailoring and evolution. Both users and the IT professionals addressed the necessity of communicating with other system owners and assigning responsibilities regarding the publication and updating of the connected information and kinds of data available. When one system in the IT infrastructure was changed, the changes were orally communicated to the owners as well as users of other systems that might be affected by the change. This indicates that it is important for the organization to support these kinds of communication paths.

4.2 The UN University Case: Infrastructuring in a Knowledge Organization

The second case concerns a UN-based university. The rationale of the university is the development and alignment of education and training across the member countries of a particular UN agency. Students at the university come from all over the world and stay for a 14-month master’s program. The special nature of the university also implies that it does not align with the host country’s legislation and framework concerning higher education. This has meant that the employees need to innovate the organizational strategies, policies, processes, and structures, and supporting IT solutions – as it turned out, with or without the assistance of IT professionals. Three such cases are reported on in a long-term action research study by Bolmsten, (2016) about sustaining PD in the organization: (1) faculty and faculty assistants working closely with IT professionals in the development of course administration support (such as scheduling, marking, and e-learning components); (2) the registrar also taking on the technical development of a registry system to support enrollment, grade reporting, curriculum quality evaluation, and student welfare and living support; and (3) an administrative assistant developing electronic forms and an address database. These shop floor IT management practices, where local software development takes place in close connection to daily work activities in different situated constituencies, were established approaches that predate the research study by many years.

The research focused on the increasing need for cross-organizational collaboration and integration: the enrollment process, for example, takes place not only within the registry department but has many points of integration with the faculty, where information flows back and forth; consequently, many considerations and decisions have to be made at both ends before a student is enrolled. In the same way, marking entails a work process that first involves a number of faculty and faculty assistants, and later continues at the registry department. Likewise, the working purpose of the electronic forms is not only for these to be used by the administrative department but by all departments and published in common information repositories.

The empirical research resulted in new insights about how EUD is an important contributor to the innovation capabilities of a knowledge intensive organization such as a university. The following sections describe how sustainable EUD depends on employees taking charge of their work tasks and the IT needed to support them. This, in turn, puts requirements on a flexible technical base when EUD extends from local applications to shared infrastructure, and mandates new ways of collaboration between end-user developers and IT professionals. Moreover, organizational structures and processes need to support participatory IT management to coordinate the development of an integrated technical base.

4.2.1 Methods of Original Research and Analysis for This Chapter

The empirical findings reported here are based on a PhD study (Bolmsten, 2016), where Bolmsten worked as an embedded action researcher employed as an IT professional by the university and combined action research with the daily development of software support with and for users. The research took place over the course of 5 years. Combined, the embedded nature and duration of the research provided an opportunity to understand, deliberate, and evaluate improvements of infrastructure development together with users. To guide the exposed research process, CMD was chosen as a structured methodology. CMD was appropriated beyond software engineering (1) to address PD and provide a focus on the development of the use organization, and (2) to include technical and organizational infrastructure from the users’ perspective. In total, three interlinked CMD research cycles were carried out, where the findings in one CMD research cycle pushed further inquiry and improvements in a new CMD research cycle. Empirical data were recorded during day-to-day interaction through an audio and text-based research diary, complemented with participatory observations, workshops, and semi-structured interviews. This also provided a basis for triangulation of the empirical findings. In addition, off-site debriefing sessions were carried out, and in some cases complementary interviews with end-users were conducted by Dittrich. The findings reported below are based on open coding of transcribed episodes selected from the empirical material.

4.2.2 Need for Change

As mentioned above, the university is a unique and specialized agency in the UN system to which standard university regulations do not apply, such as accreditation and quality assurance frameworks. Academic and administrative staff needed to develop policies, structures, and processes, borrowing meaningful elements from different national systems and adapting them to the specific context, which includes interaction with third-party organizations providing funding for the students for their education, for example. As the IT systems also needed to support these tailored procedures, EUD and close collaboration with IT staff were crucial to developing the IT infrastructure of the UN university.

The registry system is a primary example of how to deal with this need for change. Due to its special status, there was still no accountable system in place for course, subject, credit, and grade management when the registrar joined the university 10 years after its inauguration. “Can you imagine, coming into this situation?,” the registrar reflected on the situation that had confronted him. The registrar took on the creation of such a system himself, which also came to involve the technical development of the registry IT system. When analyzing the system 15 years later from a technical point of view, technical improvements could still be identified, partly due to the registrar not having been trained as an IT professional. For example, the technical database design was not optimized. However, when analyzed from a usefulness point of view, the registry system was one of the most integrated and comprehensively working systems in the organization.

Key to the continuous usefulness of the system were the development dynamics, wherein use and socio-technical development were intertwined as an often natural part of everyday work. When studying the development of the registry system, it was the day-to-day discussions that came across as most important, where the development of the technical system was discussed and negotiated in relation to its daily operation and development of work practices. The same development dynamics were observed in regard to the development of other university systems, where a piece of functionality working well or not so well in relation to the execution of a work task would lead to an in-situ discussion of how it could be improved. When interviewing a registry assistant about the development approach of the registry system, it was notable how such evolution of the registry system was an almost implicit part of her work. For example, she exemplified the nature of day-to-day development collaboration, citing an issue with menu tabs being divided into different databases in her interface “[…] you can always call him [the registrar], go in to him, and he listens […] it is not like it is small petites […] I have not thought about it before, but now when we are talking about it, it is pretty great […] and then he either says it works, if it works […].” These development dynamics would not have been possible to capture, for example, by studying a formal project management framework, which in many cases was, in fact, absent.

One of the motivations for the research resulting in a PhD thesis was the recognition that this approach has its limitations when the development of bespoke IT systems take up more and more resources and, at the same time, the need for integration becomes visible.

4.2.3 Flexible Technologies as Enablers

For the end-users to effectively participate in the development of IT support, the technology used was of importance. This became evident when EUD expanded from local development, adaptation, and configuration to encompass infrastructure development on a shared technical base. In total, three improvements to technical bases were designed as part of the action research, of which one was specifically implemented to support EUD. In order to allow for both cross-university integration and local innovation and EUD, a fourth-generation Content Management System was adapted as a technical base to host the Learning Management System and all other faculty portals. Special attention was paid to selecting a technical base that supported the integration with local tools and custom-developed modules for situated work practices. The improvements to EUD were twofold: when development took place on a shared technical base, possibilities opened up for end-user developers to exchange information and use the same datasets and modules as other local applications developed on the same technical base. This created opportunities for end-users to develop consolidated reports with interlinked information that previously resided within the confines of local departments. An example was academic reporting that used schedule data from the faculty department, grade data from the registry department, and employee data from the human resources department. Another benefit from a shared technical base was that it enabled shared investments that otherwise would not have been possible, e.g., new catalogues of pre-defined modules that could be shared, further developed, and configured by the end-users themselves in different local applications.

The shared technical base also came to prompt coordination between end-user developers and the IT staff: it became necessary to negotiate requirements for shared modules across the university. An example was the decision to have a new module for shared documents between two local application communities, which turned into a “straightjacket” for one of them as it had not been properly deliberated. For the grade notifications, the access rights needed to be configured in a more granular way than could be accommodated by the newly shared module. These experiences provided motivation for the organization as a whole to develop organizational structures and processes for proper deliberation of decisions impacting more than one department.

4.2.4 Collaboration Between End-User Developers and IT Professionals

Before the university undertook the development of an integrated IT infrastructure, IT staff had not only taken care of the administration of network servers but also supported users with the development of custom applications that required more technical expertise than they could master themselves. This cooperation became more pronounced when the shared technical base was implemented to support the integration of different local applications. The development, configuration, and maintenance of the shared technical base required the expertise of IT professionals. The empirical research showed that IT professional expertise is also needed to moderate the often complex and multi-layered negotiations between different user interests and areas of expertise that need to be accommodated: design options need to be analyzed and presented to the domain experts, and dependencies and trade-offs need to be rendered understandable so that domain experts can gain an overview of the implications of the decisions. In the university case, PD techniques and tools were experimented with for this purpose. These included rich-picture workshops (Bødker, Kensing, & Simonsen, 2004) and design workshops to support end-users from different application domains to learn about and negotiate the trade-offs of technical base decisions. However, different end-user developers had different strategies of how to relate to the organization and their IT professional colleagues: some decided to isolate their professional domain and its IT support; others included the IT professionals in their personal network and exploited their expertise where suitable (Bolmsten & Dittrich, 2011).

IT professionals also benefited from the expertise of end-user developers in their development work. End-user developers care about usability and are confronted with the problems of unusable software. This expertise came in handy for IT professionals when working with IT infrastructure tasks: end-user developers, for example, helped to recruit the right people for user participation, to prioritize issues, and to distinguish between those of them leading users to reject an application or representing “good to have” features that could wait until the IT professionals had time to attend to them.

4.2.5 Empowered Users

One of the motivations for the research was that users were in charge of the software support for academic and administrative areas: the academic vice president hired IT support personnel instead of administrative assistants to take care of the development under his guidance; administrative personnel very outspokenly rejected the design solutions (Bolmsten, 2016); and end-user developers took charge of the development of software support for their specific professional domains (Bolmsten & Dittrich, 2011).

The analysis of the empirical material (Bolmsten, 2016) shows that EUD is a professional skill that contributes to the service provisioning of the organization. It also became evident that this skill was not always adequately recognized, which could place both the individual end-user developer as well as the professional domains and co-workers that were beneficiaries of the EUD results in a vulnerable position.

The administrative assistant developing the electronic forms described herself as a “spider in the net.” For the electronic forms to work she consciously had to target other staff with her development. Over time, she developed her own approach not only to gathering requirements but also to addressing lifecycle management, such as training, further development, and maintenance. She had established relationships with internal staff stakeholders and developed the know-how of whom to ask for certain requirements and how different people could contribute. She also maintained relationships with internal IT professionals and external communities with lead-users and IT professionals that could aid her development. In addition, she continuously had to develop her own technical proficiency by reading manuals and books as well as downloading and testing new applications from the Internet.

In the beginning, the professionalization of the organizational IT management especially obscured such networking-oriented EUD. The administrative assistant, however, did not let that hinder her development efforts. Instead, she described how she approached it with a “bugger that” mentality and carried on with her development regardless. Not only does such lack of recognition of EUD create personal impediments, for example, for career development, but it can also make IT systems that are important for the organization vulnerable. In addition, organizational invisibility can also risk loss of opportunities for infrastructure integrations and collaborations. This was something that was taken into consideration in the improvements’ organizational decision-making structures and processes described below.

4.2.6 Organizational Structures and Processes: Participatory IT Management

The findings above triggered the development of an organizational IT management that supported both EUD and collaboration between users and professional IT-developers in more profound development projects. To this end, the changes facilitated by the action research built on the existing IT management at the WMU: the university already had a long-term tradition of committee-based IT management that involved representatives from user-, end-user developer-, IT professional-, and manager-stakeholder groups. However, being faced with increasingly complex infrastructure development, also involving an increasing number of stakeholders, called for improvements. The mandate for change that underpinned the action research was to extend the existing working shop floor IT management practices as EUD in the organizational arena. The action research contributed through structure, process, and procedure improvements to sustaining a participatory IT management for infrastructure development purposes, which can be related to democratic decision-making criteria (Dahl & Shapiro, 2015). As discussed in (Bolmsten, 2016) the proposed approach of participatory IT management consisted of:

  1. (a)

    A participatory and evolutionary project management approach enabling users and end-user developers to effectively participate in infrastructure development spanning the realm of individual EUD domains. The project management approach was based on a combination of the Bødker et al. (2004) PD approach called MUST together with an evolutionary and agile development and implementation approach based on Floyd, Reisin, and Schmidt (1989) and Beck and Andres (2004). The importance of not adding unnecessary bureaucracy was highlighted. The project management had to be flexible in order to cope with projects of different scope. The project management model was developed and appropriated throughout the empirical research: it was first introduced to support two projects that were already ongoing. The first project was about the development of electronic forms, which already had strategic anchoring but used project management to strengthen the definition of project scope, and supported the organization and prioritization of tasks during the course of the project. In the second project, which involved a further development of course administration, the project management framework allowed project members and stakeholders to take a step back and reconsider the strategic alignment of the project. This resulted in an in-depth study of work practices and several technical prototypes that were then used to define practical development tasks that were prioritized in an evolutionary manner, using the agile component of the project management framework.

  2. (b)

    PD representations that enabled users and end-user developers to acquire a thorough understanding of both work- and technology-related infrastructure design matters. These included extended versions of story cards (Beck & Andres, 2004; Kyng, 1995) that were used to communicate the implications of infrastructure development from a work practice perspective. They were co-constructed between users and IT professionals and continuously updated throughout the development as a living boundary object. In the most comprehensive project documented in the action research, the story cards were co-constructed through the use of a number of PD tools and techniques both to gain an in-depth understanding of important workflows in the current use organization and develop visions and proposals for new IT usage in regard to the registry system. Participatory observations were used to understand and document work domains and workflows, and underpinned an iterative writing process of a story card between users and IT professionals. The story cards were then mapped onto rich-pictures that were used in multi-stakeholder workshops to understand how both technical and organizational infrastructure improvements could be made. The story cards were further used in contact with IT-providers to understand how their applications provided solutions for the organization. The participatory observations and the story cards show how the original in-situ close-knit approach, where development took place in close connection to work realities, was further developed to address more complex socio-technical infrastructure developments.

  3. (c)

    Processes and associated documentation to connect the local development to IT and infrastructure development. To this end, a practice based on what was referred to as business plans was developed to detail the organizational rationale of the projects. These business plans related the inline analysis of the MUST-based project management approach to the cross-organizational infrastructure development. They contributed toward users exercising control of the complete agenda of technical and organizational infrastructure development that affected their individual applications. The business plans were important not only in prioritizing development resources, such as the time of the IT professionals, but also in providing transparency for affected stakeholders between different but linked local applications. A typical example was how a proposed change in one part of an administrative infrastructure to consolidate databases had implications for the local of the contact database that the administrative assistant was working with. The business plans allowed for the identification and negotiation of this dependence on a pre-project and development stage, using the organizational structures and processes described next.

  4. (d)

    Improved decision-making processes and procedures in the committee-based IT management. These addressed how to prepare, present, decide, and record agenda items, including the above-mentioned business plans to plan and track projects. This was of additional benefit to users, who could influence the agenda of design and development also in regard to infrastructure development. In addition, structural change was undertaken where the IT professionals were formally defined as a resource for committee-based management.

The empirical findings show that EUD and user-centered design need to be supported by a participatory IT management approach to effect the necessary change and innovation in a sustainable manner. The chair of the committee-based management described how the improvements resulted in an organized and constructive approach to planning by focusing on the “subject matter”:

then one has the subject matter, one has a presentation, the one who has prepared the case then has to focus on what is suggested […] it is important that opinions can be put forward, subject matter arguments, and that it is documented, then that goes a long way […] if one can come to a clear concrete decision, and if I then don’t get a hearing for my view then one kind of has to accept, there has been a forum, I have put forward the arguments, and they were not approved, then one has to accept the vote of the majority.

The citation shows that decision-making in the committee-based management was actually important. Even though it was not common for decision-makers to have to resort to voting, the stakes could be high when negotiating different interests in infrastructure development. The findings provide one example of how such participatory IT management can be instantiated, but there are other possibilities as well. They also show the value of the underlying principles of (1) enabling effective participation in individual projects, (2) enabling users to gain an enlightened understanding of infrastructure design issues, (3) including a broad array of stakeholders that can (4) control the agenda, together with (5) inclusive decision-making practices for other organizations to apply.

4.3 Summary

The studies reveal similarities between the organizations in regard to EUD as a sustained organizational capability for innovation. The pressure for change makes it necessary to consciously include EUD as part of the development of the organizational infrastructure. On the one hand, this requires flexible technologies when designing specific applications and, on an infrastructure level, when connecting different applications; on the other hand, users need to be capable as well as empowered to take on EUD tasks. In order to provide the right flexibility and to take local expertise into account, we observed close collaboration between IT and domain experts in local design constituencies in both cases. The organizational IT management needs to accommodate these design constituencies with processes and structures that make the situated infrastructuring organization accountable and to coordinate EUD and infrastructure evolution.

Table 2 summarizes the analysis and allows for a comparison of how the elements of the model in Fig. 1 become manifest in the two cases.

Table 2 Summary of analysis results
Full size table

5 Discussion

This section further discusses how, in the two cases, empowered employees, tight collaboration between domain experts and IT professionals, and flexible technologies contribute to sustainable EUD as infrastructuring. Sect. 5.1 highlights the need for change that has been identified as the driver for the development of the EUD culture in the respective organization and relates the cases to the discussion on user-driven innovation and organizational innovation. Sect. 5.2 further elaborates sustainable EUD in connection to the related work. Sect. 5.3 discusses the organizational structures and processes necessary to support sustainable EUD. Finally, Sect. 5.4 further considers how important sustainable EUD is in enabling the innovative capabilities of the organizations.

5.1 Need for Change and Innovation

The two cases’ area of operation is very different: where the telecommunications company needs to provide state-of-the-art technical services, the UN university provides education, research, and capacity-building. Both organizations have, however, experienced a long-term need to be innovative. The telecom company is in a constantly changing market, where the company is forced to invent new services both to retain existing customers and attract new ones. The services need to be unique to gain a market advantage. The UN university also provides services, but in terms of training, education, and capacity-building. The innovatory need stems from the university being in a unique situation that is not comparable with other universities. This implicated a need for unique administrative solutions, where standard systems did not suffice.

Despite the different organizations having different primary trades and different motivations for why innovation is necessary, we can see that their need for unique solutions is a common factor. The telecom company requires unique services to remain competitive, while the UN university needs unique solutions to address their particular situation. In both cases, therefore, unique technical support systems are required.

Both organizations have historically handled the need for change by isolated EUD initiatives. In the telecom company, the need for “extra payments” arose frequently and at short notice. This entailed both a need for EUD support in the individual “payment systems” and a technical infrastructure to support these type of activities. External circumstances push the need for constant updating and renewal of the administrative system. The UN university managed the bespoke systems through an individual initiative. For example, there was a need for a reliable academic management system to manage courses, subjects, grades, and grading, which the registrar developed on his own.

One similarity between the two cases is that the need for change and innovation is initiated by external factors. For the telecom company, this means external factors such as market forces, while the UN university need for change is initiated by the continuously developing demands of education and training from the International Maritime Organization and its member states.

The administrative support systems at both the telecom company and at the UN university must evolve over time. What made the telecom case special at the time was that the EUD features were not introduced to support personalization of tools or the adaptation of generic software to a specific organization but to continuously develop part of the IT infrastructure in order to encourage business innovation on a corporate level. What makes the UN university special is that all the knowledge of how to handle administrative issues was situated with the individual users, and to be able to elucidate the knowledge to form an infrastructure, a special kind of IT management was needed which would lead to the continuous development of the infrastructure.

The need for continuous change and innovation originated from external factors in both cases, but it demanded solutions that took their stance of origin in the situated development of end-user developers. In the telecom case, changes clearly needed to be effected at short notice, and it was the users who knew what kind of changes to the system were required and who was best positioned to perform the changes. In both cases, the need for change and innovation concerned complex socio-technical infrastructures that required the situated expertise of end-user developers to develop them. A comprehensive understanding of both current work practices and the need for change, together with technical know-how, were called for to come up with new solutions. These findings provide concrete evidence in support of the assumptions of user-centered innovation and organizational learning put forward by von Hippel (2005), Björgvinsson et al. (2010), and Orlikowski (2002), as described in the related work. In this way, the need for change is initiated by external factors but the innovative solutions are provided from the bottom up by the staff on the shop floor, which creates end-user developers. This, in turn, allows continuous change and innovation. The following Subsect. 5.2 discusses what was needed to allow both case organizations to rely on EUD as part of the continuing development of the IT infrastructure. Thereafter, the organizational structures underpinning these requirements are discussed.

5.2 Sustainable End-User Development

In both cases, the need for innovation and change was partly realized through established practices of EUD, although this took place in very different contexts. From the outset, faculty and administrators at the UN university took on EUD as part of the development of their work processes and practices, and partly due to the lack of professional IT support, as the IT department was focused on hardware and network provisioning; the EUD at the telecom provider took place in close collaboration with the respective software engineers of the IT unit. As the telecom provider was one of the pioneering companies in Sweden, software and business had to be developed hand in hand. Technical expertise among users and business knowledge among software engineers developed due to close collaboration that was supported by management. As in both cases EUD was not introduced by the researcher but was already an established practice in the organization, the comparison allows us to analyze what is needed for EUD practices to become a sustainable part of the IT development of an organization.

In both cases, users made use of standard applications for their development tasks: for example, spreadsheets provided an important tool for end-user developers in both organizations, which required interfaces to integrate results produced with the help of local tools. At the telecom provider, an interface for “extra payments” for which the necessary data were compiled “by hand” was implemented; at the UN university, the course management module supported the import of schedule and room allocation from spreadsheets. In both cases, the custom-developed software provided possibilities for end-user developers and/or IT professionals to configure and customize the individual applications. In both cases, the need for flexible integration between applications became visible. The telecom provider already had an, at that time advanced, data warehouse that allowed the sharing of data across different applications before the research cooperation was implemented. The second part of the cooperation explicitly addressed the development of customizable data exchange. From the very beginning, the research together with the UN university addressed the development of an infrastructure that was flexible enough to enable access to heterogeneous data sources to support specific, local practices. However, in both cases the deployment of flexible technology was clearly not enough to support sustainable EUD.

We observed a high level of IT expertise among the group of domain experts who undertook the EUD for the respective organizations. In the context of the telecom provider, domain experts had acquired substantial technical knowledge that enabled them to work independently with database queries and the aggregation of results in elaborated spreadsheets (Dittrich & Lindeberg, 2004). Similarly, at the UN university, especially those domain experts who took on the development supporting the whole organization and not only their individual tasks continuously had to acquire the necessary technical skills (Bolmsten & Dittrich, 2011). On their own initiative, they engaged in Internet communities to get answers to issues they were facing, read books and manuals, and participated in training courses. Whereas the IT skills and EUD by domain experts at the telecommunication provider were regarded as important and necessary to support the evolving business and to provide input into the development, however, the situation of end-user developers at the UN university depended from the outset on the organizational position of the EUD. Though EUD was wide spread in the organization, and the competence of domain experts and end-user developers was widely acknowledged, different end-user developers developed different strategies to sustain their practices.

One of the most prominent observations at the telecom provider was the close cooperation between end-user developers and IT professionals. The cooperation was based on long-term development between software engineers and domain experts. Often, the same domain experts and software engineers were involved in consecutive development projects addressing the same business domain. Between the projects, the software engineers were responsible for operations, fixed bugs, and implementing smaller changes to the software they had developed. They supported the end-user developers with their knowledge of the surrounding systems and their quality control expertise. As we mentioned above, users and developers openly discussed the need to cooperate when evaluating the prototype for flexible integration of heterogeneous databases. From the IT unit, this was an explicit strategy: one of the managers in the project emphasized that whereas technical expertise could be acquired through the use of consultancy hours, the business knowledge and the understanding of what was needed in terms of IT support was a strategic business asset. In the analysis of the end-user developers’ strategies at the UN university, a lack of collaboration between end-user developers and IT professionals was shown to be problematic, both for the individual EUD and also for the organization. Collaboration with IT professionals was necessary to support a controlled and accountable integration in the IT infrastructure. In both cases, the interlacing of EUD and evolution of both individual applications and the infrastructure became visible as a matter requiring both cooperation and organizational support.

Though other studies as well as theoretical work corroborate the findings above, the comparison between the two cases allowed us to address them in a more systematic manner and gain an in-depth understanding of the technical and organizational infrastructure that is needed to support EUD. Many case studies show and discuss the IT expertise of the end-user developers, indicating that non-IT professionals can indeed competently develop software if given the right tools. Only few studies discuss the organizational support for end-user developers. Nardi (1993), for example, compares different cases of EUD of Computer Aided Design software and proposes acknowledging the contribution of the end-user developers in the organization and supporting their role through formal structures. Trigg and Bødker (1994) report that, in their case, the organization needed to re-evaluate which configuration tasks could be left to end-user developers and which needed to be discussed and decided on at an organizational level. Kanstrup (2005) discussed the role of local designers as brokers between users and IT professionals. However, our analysis shows that skills and organizational empowerment but also collaboration with the software engineers are necessary to include EUD as part of the infrastructure maintenance and evolution. Our observations regarding the cooperation between IT professionals and end-user developers support Fischer’s (1998) approach to meta-design and the conceptualisation of software developments in terms of seeding, evolutionary growth, and reseeding. However, our analysis also shows that this is not the only interaction needed to support organizationally sustainable EUD. Collaboration between IT professionals and end-user developers continues between projects and only intensifies when an application is redeveloped to take care of the evolution pressure that cannot be handled by EUD alone. Similarly to Star and Ruhleder’s (1994, 1996) discussion of the use of information infrastructures to target organizational transformation, our analysis extends the understanding of salient infrastructural dimensions, what triggers their development, and their relations in supporting EUD. As shown, empowering employees, collaborating with IT professionals, and flexible technologies are integral infrastructure dimensions that are necessary to sustain EUD in the organization.

Our systematic analysis further points to the need for organizational structures and processes that provide a foundation and frame for both EUD and the collaboration between IT professionals when together developing the IT infrastructure for an organization. The next Subsect. 5.3 analyzes and discusses our respective findings.

5.3 Organizational Structures and Processes

Above, we have argued that sustainable EUD underpinned the evolution of both IT and work practices to meet the requirements for change that the case organizations faced. This requires not only flexible technologies supporting the adaptability of both the individual applications and their connection but also end-user developers who are empowered with IT skills and a mandate from the organization, as well as a close collaboration between IT professionals and domain experts. To mandate the former and establish the latter, IT management strategies and processes need to be adequately designed. In this respect, the two cases differ substantially: whereas the telecom provider had established IT management structures, the research at the UN university explicitly addressed this aspect. Here, we structure the discussion on the IT management based on the elements we identified and established at the UN university and compare it with the respective elements of the IT management at the telecom provider. In the latter case, we have analyzed the IT project model and its implementation in one of the projects in detail in the article “How Use-Oriented Development can take place” (Dittrich & Lindeberg, 2004). Much of the discussion below is based on this material and analysis. The difficulty is that, at the time of the research, we only focused on the project level and did not address the organizational level. This aspect is therefore rather underdeveloped in the following discussion of the telecom case. The comparison shows that what we deemed necessary together with the UN university was actually in place, though in a different form, at the telecom provider.

In order to take into account the requirements and needs of both the users and the end-user developers, the individual project needs to be organized in a participatory manner. To this end, the IT steering group at the UN university decided on a participatory project management approach, adapting the MUST approach by Bødker et al. (2004). The PD covered by the MUST approach was complemented with an XP-oriented agile development interlacing with the PD activities. In addition, a process and documentation approach referred to as business cases detailed the relation of the individual project to the organizational IT strategy and planning. Though not using the word PD explicitly, the projects at the telecom provider implemented a participatory process. Users and developers were equal project members: after developing an implementation proposal together, which also detailed the implications for other applications in the infrastructure, the development process was an iterative one (today one would call it agile), where annotated “implementation sketches” containing both a UI draft and technical specifications served as the main boundary object (Star & Griesemer, 1989) between users and developers. In the project that was the subject of the study, project management was shared between a software engineer from the IT unit and a project manager from the business side.

To empower the project to take decisions based on the PD process on the one hand, and make sure that the dynamics in the project do not lead the project beyond what has been decided at the organizational level on the other, the connection between the project and the organizational IT management level needs to be explicitly taken care of. At the UN university, this was achieved by the PD project management approach and the “business case” document, which was decided by the IT steering committee. At the telecom provider, the implementation proposal developed in a pre-study served a similar purpose.

In order to support joint decisions by representatives of the local design constituencies and the IT professionals on infrastructure matters, the IT steering committee needed to be supported by tools and techniques to discuss the impact of individual projects as well as cross-cutting infrastructure development decisions. In order to achieve a common understanding, we used an approach of storytelling initially called “reflection papers” that was inspired by user stories (Beck & Andres, 2004; Kyng, 1995). These were co-constructed between users and IT professionals and described the technical implications routed in day-to-day use as well as EUD practices. In the telecom provider case, the implementation proposal served the same issue. Before the company-wide project committee decided on a project, a pre-study was implemented resulting in a requirements’ specification, an implementation proposal, a specification of the implementation project model, and a budget. The implementation proposal also detailed the effect on other systems of the infrastructure. As in the specific case, the pre-study was not only reported to the project committee but presented in a meeting to which all affected units and groups were invited.

In order to take in the interests of the users and end-user developers in the management of the organization, the decision-making structures and processes need to be anchored with the different parts of the organization affected by the decisions. To this end, the UN university established an IT steering committee consisting of representatives of users, IT professionals, and managers, which was mandated to take decisions on IT projects. Decisions were deliberated based on the above-mentioned PD project management, representations, and the business cases for the individual projects. The agenda of the committee meetings and supportive material was published well in advance. Discussions and decisions were documented. This rendered the IT management procedures at the UN university open and accountable to the whole organization. Anyone affected by a decision had the chance to partake in the discussion either in person or through a designated representative on the committee. By comparison, the organizational IT management at the telecom provider was more comprehensive: the cross-organizational project committee did not only hold responsibility for IT-related projects; the company had a strict process organization. Any changes to existing processes were organized as projects, and all such projects were decided by the project committee.

In the book chapter “Organizational IT managed from the shop floor – Developing Participatory Design on the organizational arena,” with reference to the UN university case, Bolmsten (2016) argue that in order to support an organization heavily relying on empowered domain experts to reach its objective, the IT management needs to take a participatory approach as well, and show how it is possible to leverage PD in the organizational arena. They also demonstrate that it is possible to provide organizational structures that support a bottom-up IT management in which EUD is an integrated part of organizational IT development, challenging the current standard of IT management as a top-down structure design approach (Bernard, 2005). The discussion above indicates that also in organizations that need to have an IT management of a different size and scope due to their technical infrastructure, as in the case of the telecom provider, IT management structures can be found that support bottom-up as well as top-down decision-making. We also showed that the integration of EUD and professional software development benefits from such participatory structures: these structures allow us to take into account local developments to support evolving business and work practices, making local EUD organizationally accountable. In this way, they support shop floor IT management practices (Dittrich et al., 2002; Eriksén, 1998) and can provide an organizational frame for infrastructuring, as discussed by Karasti (2014; Karasti & Syrjänen, 2004) and Pipek and Wulf (2009). The next section will take this argument one step further by contending that such structures and the sustainable EUD practices they support substantially contribute to the innovative capability of an organization.

5.4 Innovation Capabilities

In the analysis above, we can see that EUD is an important ingredient of the innovative capability of the two case organizations. In the related work section, we defined innovation capability according to Lawson and Samson (2001) as the “ability to continuously transform knowledge and ideas into new products, processes, and systems for the benefit of the firm and its stakeholders.” In both cases of EUD presented here, EUD was part of the organizational practices and structures that enabled the development and evolution of IT systems to support the innovation of new services that the organization provided. As previously discussed, both the telecom provider and the UN university faced continuously high pressure to innovate. The fact that the systems were in both cases sustained over an extended period of time with a continuous dependence on improvements and extensions by end-user developers further adds to the recognition of end-user development as an innovative capability.

Not only do the cases demonstrate that, as an innovatory capability, EUD answers to organizational needs for change, but they additionally indicate which infrastructural technical and organizational structures and processes are necessary for EUD innovations to become a sustained ingredient of the innovation capabilities of an organization. When EUD expands from individual appropriation and customizations to becoming part of the cooperative development of the organization’s IT infrastructure, EUD alone is not enough. End-users need a supporting technical and organizational infrastructure to innovate. At the same time, this is a reciprocal dependence, where the resulting EUD innovations are put into use as part of the very same infrastructure. The dimensions discussed in the previous two sections, in this way, constitute a socio-technical infrastructure and together underpin the organization’s capability to innovate. This forms the main contribution of this chapter. An overview of these infrastructural dimensions and their relations is presented in Fig. 2 and summarized in the following claim: end-users need to be empowered through a flexible technical base, their development needs to receive professional recognition in the organization, and the collaboration between EUD and other IT professionals needs to be supported. As is further shown, these infrastructural dimensions are not statically provided; rather, end-users need to participate in decision-making structures and processes to develop them.

Fig. 2
figure 2

Overview of infrastructural dimensions

Full size image

Especially, the organizational IT management processes were necessary to sustain EUD and the innovation capabilities through it. The UN university case showed that these structures needed to be maintained and unfolded together with renewal and evolution of the technical infrastructure, the corresponding changes for the EUD, and the professional development processes. The evolution of the organizational structures, the EUD processes, and the technical infrastructure development can be denoted by the term “infrastructuring,” representing the continual maintenance and evolution of the organization’s socio-technical infrastructure (Karasti, 2014; Karasti & Syrjänen, 2004). Especially, in the case of the long-term action research at the UN university, it was possible to follow how the process of sustaining EUD as an innovation capability unfolded over time. The needs of the administrative assistant developing the address database to collaborate with IT professionals, for example, developed over time when the address database gradually benefited from interfacing with other systems on a shared technical platform. Another example is how possible synergies arising from the integration of the Learning Management System and the registry system at the UN university prompted a new and more advanced technical base and the advancement of coordination both on a project and organizational level between end-user developers, users, IT professionals, and other stakeholders that were associated with the respective developments. At the UN university, the challenge of sustaining an innovatory EUD capability can be recognized as maintaining a local accountability of development in an expanding process of technical and organizational infrastructuring. However, the telecommunication provider case also shows that EUD of the back-end systems and the connected IT infrastructure were backed up by continuous professional development and a close collaboration between the end-user developers and the software engineers of the IT unit. Also here, the organizational IT management structures underpinned the EUD practices as well as the close collaboration between end-user developers and the IT unit. Nevertheless, the resulting professional IT practices were contested as they did not adhere to the then prevalent control-oriented state of the art in software engineering; indeed, they were much closer to the more recently evolving agile paradigm.

Previous studies have described how organizations are challenged to develop and sustain capabilities for innovation to cope with an increased pressure for change (Orlikowski, 2002). At the same time, new possibilities of democratized innovation are described, whereby users themselves can innovate products and services (Björgvinsson et al., 2010; von Hippel, 2005), which can potentially meet those challenges. The combined analysis of the cases adds empirical evidence that such democratization of innovation is also possible within organizations and that this, if carefully supported, contributes to the innovation capability of the organization. Through the combined results of the cases discussed here, it is possible to concretize how a democratized innovation capability can be realized to cope with the increased pressure for change in an organization. Ciborra (Andreu & Ciborra, 1996; Ciborra, 2000) also discusses the principal need for a process that combines bottom-up innovation and learning to make both incremental and radical improvements that range from improvements of routines to strategic capabilities. The results here show how end-user development can be positioned to meet such need for innovation and learning. The occurrence and possibilities of end-user development have been discussed before in connection to a wide range of cooperative tailoring scenarios (Pipek & Kahler, 2006). The results here connect end-user development with shared infrastructure development as a strategic capability for innovation. In addition, it has been shown how the bottom-up process of innovation and learning can be depicted as “infrastructuring” (Karasti, 2014; Karasti & Syrjänen, 2004). Where this is based on end-user development, it is a central ingredient of the innovation capability in organizations that are dependent on an IT infrastructure. The several dimensions of “infrastructuring” that are presented can, in this respect, be related to Pipek and Wulf’s (2009) layers of infrastructural technology development. This ranges from how innovations are trigged by end-users – either through breakdowns or other needs for local innovation – to how end-users work together with IT professionals and other users in method-driven design activities, to the need to improve technical platforms and organizational decision structures and processes. Moreover, Sects 5.2 and 5.3 have detailed what is required with respect to technology, competences, and cooperation, and how the organizational structures need to support infrastructuring through adequate project models, collaboration tools, and decision-making procedures.

6 Conclusion

In this chapter, we have provided a comparative analysis of two cases of EUD in the context of organizations that depend on an IT infrastructure to provide their services. In both cases, EUD was not only used to personalize IT support but to maintain and evolve the organizations’ IT infrastructure. EUD was in both cases a constituting part of the innovation capability of the organizations.

Based on our two cases, we indicate what is required in terms of organizational IT management to support the inclusion of EUD activities as part of IT infrastructure development in the organization and support both lasting quality in use for the domain experts and the competitive advantage of the business. Besides a flexible technical base, the EUD practices were dependent on the skills and competences of the end-user developers as well as a fruitful cooperation between end-user developers and professional software engineers.

EUD as part of organizational IT management can be expected to become more and more relevant. The need for development and evolution of organization-specific software and IT solutions continues to grow, and has already outgrown the capacity of the software developers we educate. Even if we are able to educate more software engineers, we will not be able to keep up with the growing needs of organizations. The only solution to this situation is to open up participation to end-users in the development and maintenance of their work infrastructure. At the same time, more and more software provides generic functionality and invites users to configure and combine these building blocks. Examples here are learning environments and case handling systems.

The comparison of the IT management structures and processes of the two case organizations allowed us to abstract some cornerstones for an accountable organizational frame for EUD practices as innovation capability: PD on a project level was important to communicate local needs for change and diversity; IT development projects needed to be well-connected to the embedding infrastructure so that the impacted professional and EUD practices were not disrupted; the infrastructural implications of local development were in both cases part of the deliberation process preceding decisions on IT projects; and last but not least, the organizational decision-making about the IT infrastructure supported bottom-up as well as top-down initiatives.

This points us toward a number of future research trajectories: most prominently, the mutual dependency between IT management, organizational innovation capacity, and EUD is here only touched upon, yet the comparison of the two cases provides some indication of what is needed from an IT management to support both IT-based innovation and EUD. However, additional focused case studies would allow for the development of the observed regularities into recommendations and methods. From a technical and conceptual point of view, the integration of EUD with respect to individual applications and across applications and work practices has so far not been addressed. As in the case of early EUD, industrial solutions supporting and integrating both exist but are not systematized. It could be that the concept of meta-design needs to be complemented. Last, but not least, in both cases, the representation of infrastructures in order to visualize dependencies and deliberate new developments was an area in need of more development. At the UN university we experimented with extended user story-inspired descriptions; at the telecom company, involvement of relevant organizational stakeholders in the deliberation provided the relevant information. Here, we see the need for further research to support EUD with the means for participatory infrastructuring.