ICT Standards in Smart Grid Projects – Between a Standard’s Intended and Factual Role in Complex Technological Developments

2.1 New ICT Standards for the Development of Digital Technologies

Digital technologies are ushering in a new era of standards that can only be understood by delimiting them from ‘ordinary’ standards. All types of standards aim at structuring organizational processes by reducing flexibility, diversity, interpretation or even chaos. In turn, they should increase safety or efficiency (Timmermans and Epstein 2010). Seen this way, standards are a form of organizing and coordinating (Brunsson, Rasche, and Seidl 2012) as they are formalized rules with the possibility to measure an outcome (Busch 2011; Loconto and Arnold 2022). Given the voluntary nature^[1] of standards (Brunsson and Jacobsson 2005a; Timmermans and Epstein 2010), they are often developed by national or international standardization organizations such as the International Organization for Standardization (ISO) or the German Institute for Standardization (Deutsches Insitut für Normung - DIN) (Blind 2020), thus enabling their application by multiple organizations across national borders (Arnold 2019; Loconto and Arnold 2022).

Arnold (2019) distinguishes between three different waves of standardization that can all be summarized as ‘ordinary standards’: (i) technical standards, (ii) quality management standards and (iii) sustainability standards. In the early 20th century, technical standards had a strong social orientation. The introduction of standard measuring units or standards in industrial production was intended to boost trade and economic growth. Following the development of specific quality management standards in some countries, the first international standard (ISO 9000) was established in 1987. With this move, the focus shifted from technical to behavioral aspects. Such standards aim at improving organizational processes for a higher quality of products or services. Finally, sustainability standards aim at fostering socially and economically friendly production, trade and consumption.

All three waves hardly address technological aspects. For example, the quality management standard ISO 9000^[2] aims to “increase organizational performance and to secure organizational survival” (Beck and Walgenbach 2005: 843). This standard is well institutionalized and its meaning or effectiveness is rarely questioned – it is regarded as an essential part of organizations. A central reason for ISO certification is to gain legitimacy and to present a modern image (Beck and Walgenbach 2005; Sandholtz 2012), which is why Timmermans and Epstein (2010: 82) assign such standards a “signaling function” instead of anything “material”.

Although there are commonalities between ICT standards and ‘ordinary’ standards in terms of legitimacy, e.g. specific expectations and a defendable, auditable process (Skotnes 2020), ICT standards differ from the standards described above in that their central goal is to break down and manage the complexity of multifaceted digital technological developments such as smart grids:

With the new functionalities, systems, devices and the variety of actors that come along with Smart Grid, the complexity increases. To realize such a complex and time critical system respective IT and automation technologies will have to be put in place. This complex system of systems, which need to be interconnected, demands adequate ICT-standards to enable an efficient integration and communication (Trefke, Gonzalez, and Uslar 2012: 903).

Smart grid development is often associated with a ‘fundamental’ change in the energy sector (Erlinghagen and Markard 2012) because the intended intelligent, self-regulative and communicative network infrastructure needs to incorporate technologies and physical devices from different domains e.g. sensors, software or communication protocols (Cambini et al. 2016). The energy transition is hence also a transformation from an analogue toward a digital sector (cf. also Andersen et al. 2021). The volume of data generated in the course of this digital transformation is increasingly considerably. In addition, more and more different types of data from diverse actors in the energy sector and beyond have to be exchanged, which is why pre-existing data processing and analysis programs reach their limits here (Farhangi 2010; Köhlke 2020). In this context, ICT are meant to facilitate the exchange and use of data and knowledge (Ho and O’Sullivan 2019). Data coordination is directly connected to the coordination of a multitude of actors from different sectors, and ICT standards explicitly address such issues of coordination in technological and organizational terms and are hence particularly suitable for distributing responsibilities and coordinating heterogeneous interests (Rohde and Hielscher 2021; Vial 2021). Finally, since smart grids as part of the energy sector are critical infrastructure and hence particularly dependent on high safety and security requirements, ICT standards are also meant to avert malfunction or attacks (Skotnes 2020).

Drawing this together, ICT standards are designed to be key to success. They enable the development of complex systems in an efficient and cost-effective way (Uslar et al. 2011). There is “an industry-wide consensus on a suite of standards enabling end-to-end command and data exchange between various components of the smart grid” (Farhangi 2010: 26). In this context, standards such as those investigated in the case study in this paper, the Use Case Methodology (UCM) and Smart Grid Architecture Model (SGAM) (Gottschalk, Uslar, and Delfs 2017), explicitly address the creation and documentation of interfaces and interoperability issues. Despite being only a ‘representative’ for external displays of organizational processes, ICT standards lay the ground for the development of and rules for sector activities (Scott and Orlikowski 2022).

Even though they seem to provide a reliable framework for collaboration, ICT standards need to be adopted to their specific setting, a process to which we now turn.

2.2 The Adoption of Standards and ICT Standards

To understand the mechanisms of ICT standards in organizational settings, we focus on the adoption process of ICT standards in innovation projects because complex technological developments such as smart grids tend to be organized as projects (Ryghaug and Skjølsvold 2021). There are different approaches to study how exactly standards are implemented by organizations. The key difference is whether the characteristics of the standard are changed or standards are simply copied. In this paper, we follow Beck and Walgenbach (2005), who refer to a mere adoption of existing institutionalized and structural elements or practices, which does not necessarily result in changes of standards. Other studies, however, extend this perspective by focusing explicitly on these changes, which is called adaptation. Here, standard implementation is understood as process of translating the standard rules into organizational specific rules (e.g. Brunsson, Rasche, and Seidl 2012; Skotnes 2020). Irrespective of these perspectives, the implementation of standards reveals their formal boundaries: “While standards and standardization are typically associated with notions of stability, lately researchers have taken a particular interest in the various dynamics involved in the processes of standardization.” (Brunsson, Rasche, and Seidl 2012: 621) Despite the assumed assimilation of organizational actions, standards may also promote differences (Sandholtz 2012) because non-identical interpretations (Skotnes 2020) result in dissimilar implementation or embedding of standards (Arnold 2019).

Standardization research shows that these differences can be traced back to several aspects. First, due to their external development and the resulting top-down perspective, all standards differ from hierarchically established rules and formalization (Arnold 2019; Timmermans and Epstein 2010; Ahrne and Brunsson 2011),^[3] which is why standards face validity and credibility issues.^[4] Second, standards are complex, abstract and not free of interpretation (Loconto and Arnold 2022): “[M]any industrial standards are sufficiently complex and ambiguous that they do not provide clear prescriptions for conduct.” (Skotnes 2020: 166) Complexity originates not only on a technological level but also results from the “constituting actors network” (Braa et al. 2007: 397), e.g. users, practitioners or even developers. These two aspects illustrate the need for an adoption to the internal conditions of the organization (e.g. Brunsson, Rasche, and Seidl 2012), which also shifts the focus to the actors who make standards work and give them a specific meaning. “A standard or a regulation does not have any natural force or intrinsic momentum. It requires agents who are prepared to make it in reality.” (Barry 2001: 75).

Empirically, there are numerous studies on the adoption process of ‘ordinary’ standards. What they all have in common is that the action-guiding potential of standards is rather low and contradictory. For example, Sandholtz (2012) highlights that different forms of ‘decoupling’ are one of the most central findings. Here, the usual organizational practices remain unaffected by the adoption. This is especially the “case where firms have a great need for legitimacy but limited internal implementation capacity” (Brunsson, Rasche, and Seidl 2012: 618). Not only the influence on structures is striking, but also the degree to which the original rules and intention of standards are adopted. Higgins, Dibden, and Cocklin (2010: 168) show that adoption focuses on “sectoral and local priorities rather than striving to meet the full requirements of the international ISO 14001 standard.” Deviations from the original intention are common. One and the same standard can therefore be used in completely different ways and contexts, depending on the actors’ interpretations (Arnold 2019; Star and Lampland 2009). Therefore, standards should generally be flexible enough to achieve smooth implementation (Braa et al. 2007). When being introduced, adoption is a balancing act between the “[formal] expectations” and “informal world of practices” or “real-life situations.” (Le Coze et al. 2017: 30)

Taken together, the adoption of ‘ordinary’ standards is neither smooth nor straightforward, and, generally, their coordination function seems to be rather subliminal. However, as outlined above (Section 2.1), ICT standards explicitly aim at managing complex technological developments, which raises the expectation that they are more prone to actually fulfilling this function than ‘ordinary’ standards. ICT standards intervene much more deeply in organizational processes because they govern the development of digital technologies from the very beginning, which could further render them more binding than ‘ordinary’ standards. This question will now be investigated empirically.

4.1 Standardization in the Smart Grid Domain: the Example of the Use Case Methodology (UCM)

The ICT standards commonly applied in smart grid projects are the Use Case Methodology (UCM) together with the Smart Grid Architecture Model (SGAM) (Gottschalk, Uslar, and Delfs 2017) that are defined by the International Electrotechnical Commission (IEC) (International Electrotechnical Commission 2015). In this section, we briefly introduce these standards with regard to both its technological range and its expected impact on the organizational aspects of the collaboration.

Starting with the technological range, the UCM aims to describe the main functions of a smart grid and to identify the necessary system components (Trefke, Gonzalez, and Uslar 2012). The central parts – the use cases – of the standard are defined as follows: a “specification of a set of actions performed by a system, which yield an observable result that is, typically, of value for one or more actors or other stakeholders of the system” (International Electrotechnical Commission 2015). The use cases are intended to provide an external overview of systems to be developed. For this purpose, system components are represented in two different ways. On the one hand, their relation to the system is shown and, on the other hand, the dynamics between different actors and systems are described. The objective is to present a set of instructions: What do I want to achieve and how? As some of these aspects are not available at the start of the process, development is carried out in parallel with the development project starting with approximate targets and gradually adding the technical specifications or requirements (Gottschalk, Uslar, and Delfs 2017). Therefore, the ICT standard can be understood as a ‘table of contents’ or ‘blueprint’ (see Table 2) for the future smart grid with a strong focus on the availability and accessibility of knowledge, data and used technologies (Faller et al. 2020).

The contents of the use cases can then be mapped in the three-dimensional SGAM^[6] (see Figure 1). The aim is to create a “conceptual model which outlines the domains of the power system. It enables actors to identify their role in the context of Smart Grids and possible connections towards other actors, components, and used standards.” (Trefke, Gonzalez, and Uslar 2012: 903) By taking a holistic view of the system to be developed, both solutions and relevant technical standards can be identified (Trefke, Gonzalez, and Uslar 2012). In contrast to the UCM, SGAM not only identifies the involved actors but also their mutual relations in the physical distribution (Santodomingo et al. 2014).

Figure 1:

Smart grid architecture model (SGAM). Source: Gottschalk, Uslar, and Delfs (2017, p. 45).

On the organizational level, the UCM is meant to structure the joint development process, provide a common understanding and facilitate the accessibility of implicit knowledge (Gottschalk, Uslar, and Delfs 2017; Santodomingo et al. 2014; Trefke, Gonzalez, and Uslar 2012).

The development of use cases, affecting this extensive group of stakeholders, requires participants with equally varying background knowledge and viewpoints. If use case descriptions shall express requirements and system functionality, and support collaboration between actors from different disciplines, like electrical engineers and IT experts, a shared methodology and tool support is required (Trefke, Gonzalez, and Dänekas 2013: 43).

Taken together, UCM and SGAM are ICT standards that aim to provide an action-steering framework for the collaboration by providing a binding rule portfolio with appropriate tool support. At the same time, the adoption of the ICT standards involve negotiation processes and its application is open to interpretation – which will be subject of the empirical investigation.

4.2 Case Study, Data Collection and Analysis

As current smart grid developments mostly take place in (innovation) projects (Boer and Verhaegh 2016; Mah et al. 2013), the empirical research draws on a single case study of such a smart grid project (Yin 2018). Especially in innovation projects, ICT standards are often applied to make tasks manageable, to provide a framework for action and to make concrete plans (Besio 2019). The project under study is inter-organizational and collaborative involving more than 30 organizations from industry, business and research from the energy sector and beyond. Structurally, the participating organizations are relatively heterogeneous and include both young and established organizations. The size of the organizations also varies greatly. During the project, new sample solutions for energy supply were to be developed and field-tested. The focus was on the topics of digitalization, flexibility and control. In addition to technology development of e.g. data platforms, the project also focused on scientific research in the field, e.g. regulations. The project had quite different focal points and not all work packages were closely interlinked. Both the heterogeneous actors and the diverse content are typical for smart grid developments. Further reasons for choosing this project for investigation were that the UCM standard was applied from the very beginning and it was possible to gain nearly full access to all relevant participants due to a high commitment on the part of the project leader.

Between autumn 2020 and spring 2021, we conducted a total of 25 semi-structured expert interviews (Gläser and Laudel 2010) with 26 project partners from the organizations involved.^[7] Roughly equal numbers of interviews were conducted with project participants from research and industry. Many of the interviewees were involved in more than one work package or held different functions in the project. Therefore, different hierarchical levels, project methodology experts and associated partners were covered. As a broad spectrum is well represented in the interview sample, we were able to gain insights into almost all sub-projects and the overall context. In the end, we were able to obtain a relatively complete picture of the project that also acknowledged heterogeneous ways of dealing with the UCM standard.

Due to the coronavirus pandemic, the interviews were conducted via an online conference tool.^[8] Compared to telephone interviews, this format was considerably closer to face-to-face interviews, since the use of a webcam also supports non-verbal communication (O’Connor and Madge 2017; Janghorban et al. 2014; Deakin and Wakefield 2014; Lobe, Morgan, and Hoffman 2020).^[9] The interviews lasted between 25 and 75 min, with an average duration of around 50 min. The main topics related to the application and use of the UCM as well as its effects on the overall project and the internal project communication. All of the interviews were recorded, transcribed and coded with the qualitative analysis software MAXQDA.

The interviews were analyzed using a combination of theoretical and analytical categories (see among others Kuckartz 2018). The starting point for the theoretical categories was the characteristics of the formal and informal decision premises (see Table 1). These were supplemented with analytical categories that emerged during the coding. We coded with particular attention to the main topics described above, formal and informal application. In a second round, we identified empirical instances related to the three theoretically derived areas: (i) Decision programs: structural adoption of the UCM in the project, (ii) Communication channels: creation of functions and roles to handle the UCM and (iii) Personnel: division of responsibilities and labor. The analysis presented in Section 5 is based on this triad and outlines formal and informal aspects of adopting an ICT standard.

5.1 Decision Programs: Structural Adoption of the UCM in the Project

Decision programs concern the planning of the process and the project targets. The UCM is explicitly intended to impact its structure. To understand how the ICT standard^[10] impacts decision programs, we first look at the project context and then turn to the resulting structures that were created to implement the ICT standard.

A priori, the UCM was an external requirement of the project’s funding program. It was hence assumed that the UCM would be used internally to identify dependencies and cross-relationships at an early stage in order to centrally manage data and technological developments (e.g. I_22_energy provider, I_07_research institution). This especially concerned the leading technological development, a comprehensive data platform, internally called the “spider in the web” (I_22_energy provider). On the organizational side, the UCM should act as a conjoint fixed starting point without the need to further negotiate other forms of coordination (I_16_ research institution, I_05_ research institution).

Despite these clear aims, the adoption of the UCM drew heavily upon formal power: The consortium leader was entrusted with the task to “get this methodology rolling” (I_22_energy provider) and reminded the partners of their obligation to use the UCM (I_07_research institution). Being a “relatively weak form of organizing” (Brunsson, Rasche, and Seidl 2012: 624), standards in general can hardly impose an action-guiding framework. In the present case, this ‘weakness’ was balanced out via authority. Therefore, one interviewee expected that, if powerful roles had not stood behind the UCM, its application would have been virtually impossible (I_05_research institution).

In contrast to this formal side, the partners enjoyed a great deal of freedom in implementing and planning their sub-projects, as only general guidelines were implemented (I_21_service organization, I_12_research institution). This implies that while it was clear that the UCM had to be applied, the contents of the sub-projects were underspecified (I_24_energy provider). This approach exhibits parallels to Rammert’s (1988) concept of “controlled autonomy”, according to which innovation processes are usually detached from rigid requirements and thus cannot be subjected to an economic-rationalistic approach. Instead, the focus is on the “organization of informal and professional self-management and control of the infrastructure framework conditions” (Rammert 1988: 215). In some cases, this intervention was viewed critically, as one interviewee describes by drawing an analogy to cutting down a tree:

[B]ut whether it is done by hand, […] a chainsaw or a crampon or whatever [ …]. Good management is also characterized by the fact that this does not happen. That I do not have to say how the work needs to be done, but rather when. (I_24_energy provider)

These tensions resulted in deviations and informal ways of handling the ICT standard. Many of the partners perceived the UCM as an onerous chore and did not follow its rules. Some partners were even unable to follow its rules as their development project was not sufficiently specified: “You could only model a system and not a process […] and this is why [the UCM] is difficult at this point.” (I_25_service organization). One interviewee highlighted a variety of open questions regarding the rigid requirements of the UCM: “We cannot answer that yet. Especially ‘Who is talking to whom? What interfaces are there?’” (I_22_energy provider).

Even at a later stage, the UCM was not used for identifying technological interfaces or considered the basis for collaboration – which is surprising given that exactly this was the expectation: “There were these promised gigantic and strategic operational implications [of the UCM].” (I_24_energy provider) In reality, the partner adopted other approaches: “But then it turned out that the people we needed the data from were not thinking in that [UCM] perspective themselves. So, we then completely bypassed that process and went to the partners to get the data.” (I_09_research institution) Interfaces and dependencies were identified in the course of face-to-face discussions rather than via the formal ICT standard. This aspect shows that the informal approach is almost contrary to the formal intention: the concrete developments hardly made any reference at all to the UCM. Instead, experiences and opinions were exchanged and further steps were discussed individually. Instead of having a “multidimensional view” (I_22_energy provider) of the project, which should be one of the central achievements of the UCM, the developments rather happened in isolation. As a result, the use cases involved were disconnected from each other (see e.g. I_22_energy provider).

As the UCM’s reach hence remained limited to formalities and did not succeed in impacting informal processes, it is not surprising to find a similar duality for the resulting project structure. While traditional project management (with work packages) would have been possible without drawing on the UCM, the UCM in turn relied upon traditional management instruments to control economic aspects such as the budget (I_24_energy provider). This was resolved by formally implementing both the UCM and the work packages.

However, planning and implementation again diverged greatly in practice. The UCM’s utility for project management remained purely on paper as a classic project structure with work packages quickly took over. This can be partly attributed to the attitude of the partners towards the UCM: Work packages as a structure were more common, as it “[is] what you know, what you use” (I_09_research institution).

Nevertheless, the UCM structure also had to be maintained. The resulting dual structure led to confusion, “because it was more or less 1:1 the same thing” (I_12_research institution). Questions of boundaries between the UCM and work packages arose and the partners could not fulfill both requirements equally.

If you have work packages on the one hand and [UCM] on the other, […] you inevitably have to orient yourself somehow more towards one or the other. For me it was the work package structure, because it better followed these individual project years and the person-months. […] With the [UCM], you kind of had the line of the whole project, […] but the structure wasn’t really there. (I_12_research institution)

The dual structure was dealt with pragmatically. The working steps were written down as traditional work packages and the project partners transferred the results into the UCM structure (I_09_research institution):

In other words, all the preparatory work for the [UCM] actually happened beforehand in the work package structure. […]. The only thing that required additional work was the specification of the data requirements. Everything else was largely copy and paste. (I_09_research institution)

What is interesting here is not only the informal approach but also the ‘misuse’ of the UCM. While the UCM rather shows an overview of the project than individual work steps (I_12_research institution), in practice, it was primarily used for the latter. This modified use implied that the UCM content was less up to date as the project proceeded: Early documentation with the ICT standard was often quickly outdated as the project progressed, new features emerged or even plans changed (I_04_research institution). Therefore, the UCM would have needed to have been updated – “a never-ending story” (I_14_ technologies software and/or hardware) – throughout the project, which was hardly possible due to a limited project budget. For many partners, the focus was on the concrete development project and not on documentation (see e.g. I_23_service organization): “It could be adjusted, but the benefit is not proportional to the effort and there are other things that are higher prioritized.” (I_07_research institution). This went along with increasingly downgrading the importance of the UCM: Drawing on the dual structure, the project partners used the greater degree of freedom to structurally marginalize the UCM. The UCM turned more and more into an onerous duty (I_04_research institution).

5.2 Communication Channels: Creation of Functions and Roles to Handle the UCM

Regarding communication channels, formal implementation of the ICT standard involved defining two new functions that were explicitly intended to facilitate communication within the project. These functions were (i) methodology experts and (ii) the people responsible for the UCM.

The methodology experts channeled communication by supporting the implementation of the UCM in the overall project, particularly in its initial stages (I_14_technologies software and/or hardware). They held introductory sessions and workshops and oversaw the creation process and the reworking of the UCM. The people responsible for the UCM were accountable for both its content and administration. They were also seen as drivers for the UCM because they collected the required information and liaised with the methodology experts (I_03_research institution). Formally, both functions were meant to create linkages, channel the communication and also relieve the project partners by providing assisting expert functions.

However, informally, the importance and significance of the two formally created functions in the project deviated from the original plan and centered more on the traditional function of work package coordinators, as one interviewee describes:

The work package coordinators actually had a more important job than originally intended. The original intention was that the work package coordinators would only be important for the communication and organizational matters and that control over implementation would be held by […] [people responsible for the UCM] […]. They were supposed to be leading the way. […] [T]he [methodology experts] were only important at the beginning of the project when it came to documentation. After that, the [person responsible for the UCM] was meant to be more important but their significance decreased because the methodology was no longer applied and then the work package coordinators became important. (I_23_service organization)

One of the reasons for this informal deviation was the temporal positioning of the UCM in the project: The methodology experts were particularly relevant at the beginning when the UCM was being created. Their close contact with the project partners gave them an enormous amount of knowledge about the overall project and its inner workings. In this mediating function, they acted as an ‘informal network’ (cf. I_03_research institution). As the project progressed, however, this knowledge advantage diminished and communication channels reverted back to the more established structures based on work package coordinators.

Another reason for reverting back to structures outside the UCM standard was the lack of a formal description of the meant-to-be communication roles. There was neither a formal description for these functions, nor were the explicated activities outlined (I_19_energy provider). The general design of the work packages was also the responsibility of the respective partners (I_24_energy provider), which underlined their high degree of importance in day-to-day communication.

Finally, the people responsible for the UCM could often not be clearly distinguished from the work package coordinators – partly one and the same person – which is why increasingly pragmatic assignments of functions were made:

I think a pragmatic view was then taken there: OK, so who covers this use case best and then the [people responsible for the UCM] were defined on that basis, but I think the project structure actually existed independently of appointing the [people responsible for the UCM]. (I_21_service organization)

Overall, compared to the work package coordinators, the newly created function of being responsible for the UCM, which was meant to be central, was reduced to a “virtual construct” (I_24_energy provider) in terms of communication. Instead of drawing on them for channeling communication, informal communication resulted from content-oriented decisions and reverted to the more familiar role of work package coordinators. While the function of the methodology expert was briefly important at the beginning of the project, it later lost importance; and those responsible for the UCM did not gain a higher degree of importance at all. Once again, this highlights the pitfall that the UCM was not seen as a basis for collaborative working. Instead of having a comprehensive view of the overall project, the responsibilities were distributed in a classical way. As a result, everyone worked on their own work package without thinking outside the box (I_23_service organization; I_22_energy provider). The lack of formal descriptions of the functions as the project progressed further contributed to undermining the functions and ultimately rendering them marginal.

5.3 Personnel: Division of Responsibilities and Labor

Looking at the personnel and their specific qualifications, roles and knowledge, it is particularly striking that the extent to which the project partners were confronted with and involved in the UCM differs highly. A key instrument for clearly assigning expertise and responsibility to certain people is the creation of a special work package. One interviewee describes it as a “home port” (I_22_energy provider), implying that they could be sure that it intensively focused on the UCM, “so I didn’t get any stomach pains worrying that something would be left out or whatever” (I_22_energy provider). This reflects the clear formal adoption of this work package that involved a handful of partners – mostly from the IT sector and those who were familiar with the UCM.

The result of this was, however, not only a clear responsibility structure, but also a further reinforcement of the previously outlined marginalization. This led to a differentiated prioritization of the UCM and discrepancies between the work packages, and the other project participants no longer had any clear points of contact with the UCM at all.

In reality, some of the partners were already done with the UCM shortly after the start of the project (I_24_energy provider). As of this date, they focused on the content-related outcomes and development projects and not on documentation according to the UCM (I_07_research institution), which rendered the UCM standard unimportant for them.

This represented a challenge because it divided the project partners into two camps. For those who had studied the UCM in depth, its purpose was clear; for those who had not, it seemed irrelevant:

But we […] had the advantage that as users of the […] [UCM], we also had an insight into what happens with them. I can also understand though if someone […] who only had to initially create the [UCM], if they see the point of them less. (I_08_technologies software and/ or hardware)

By the same token, this finding highlights that attempted standardization by no means applies to the entire project. In addition to the negligible relevance of the UCM for many partners, they also did not understand it and thus did not consider it helpful. One interviewee sums it up as follows:

I think that it remained a small clique who had thought about it intensively [ …]. But I think that the potential that would have been there could not (…) [be] fully exploited simply because too few people understood what it involved and what kind of tool it could have been. (I_22_energy provider)

The strategy of formally tasking a work package with managing the UCM had simplified the entire project. Informally, however, this had the effect that the other partners increasingly withdrew and paid even less attention to documenting their activities in accordance with the UCM. The project participants thus ranged from those who were intensively involved with the methodology (and saw it as useful) to those who treated it as a minor point (and saw it as an onerous chore).