Research Design and Case Selection

Managing dependencies in data supply chains takes place in real-life situations on an ongoing basis. As discussed by Yin (2014), Cavaye (1996), and Darke et al. (1998), case studies are very well suited to explore the complexities and richness of such phenomena. In designing case study research, a fundamental question is how many cases should be studied and which cases should be selected. While Yin (2014) and Eisenhardt (1989, 1991) suggest that more cases lead to better theories, Flyvbjerg (2006), Dubois and Gadde (2002, 2014, 2017), Chen (2015), and Järvensivu and Törnroos (2010) point out the value of deep insights and theories that can be obtained from a single in-depth case study. The discussion about the number of cases is related to their generalizability or external validity, i.e., the way findings can be generalized beyond the case(s) that first generated the findings. This is based on the idea that a theory should be able to account for phenomena in settings other than the setting that was used to develop it (e.g., Yin 2014; Gibbert et al. 2008). Analytical generalization is used in case study research to generalize findings into theory, rather than to populations (Bryman 2012; Yin 2014; Gibbert et al. 2008). In this research, the purpose is not to develop a theory that explains smart maintenance, but to design a framework that can be used to measure smart maintenance maturity. Generalization in this work comes down to specifying the context for which the maturity framework was developed, and providing detailed research procedures and transparent criteria used for selecting cases, analyzing data, and identifying maturity dimensions (Dubois and Gadde 2014, 2017). By providing an account of the methodology applied, the researchers describe their intellectual journey so readers can evaluate the research approach (Dubois and Araujo 2007; Ruddin 2006).

Several measures were taken to validate the smart maintenance maturity framework and to allow it to be transferred to other contexts. First, the context was clearly specified as being for CFM organizations of universities. This guided purposeful sampling of cases during the design stage and experts in the validation stage. Second, an extreme case was studied as a high-quality instance of smart maintenance in CFM organizations. This case provided detailed insights into smart maintenance capabilities. This is to say that an extreme or deviant case was used to obtain information from an unusual case at the far end of a particular dimension of interest (Bryman 2012; Flyvbjerg 2006). If dimensions of smart maintenance maturity are identified in this extreme, or best practice case, then it is likely that these same dimensions can also be used to measure maturity of CFM organizations of other universities. A third measure was collecting feedback from experts on a preliminary version of the framework. While this does not confer the framework with universal applicability, it can provide an initial confirmation of its applicability in the given business context of CFM organizations.

This research used a two-stage research design, in which a typical and atypical (extreme) case were used to design a smart maintenance maturity framework. This was subsequently validated via an expert consultation (Fig. 1). In the design stage, the interview guide (as the key research instrument) was tested through pilot interviews with independent practitioners (a senior asset manager and a tender manager) and an academic facilities management researcher. Two CFM organizations from two universities were selected for identification of maturity dimensions of smart maintenance and measurement scales. Two different networks within each CFM organization were studied (embedded cases) around two different maintenance contracts. Background information on the cases is summarized in Table 3.

In the validation stage, the preliminary smart maintenance maturity model was presented to a panel of seven experts selected for their experience and expertise. First, a profile was developed of the expertise required for validating the smart maintenance maturity framework. Four expert knowledge domains were identified as critical for validation: (1) CFM in universities, (2) organization of maintenance processes, (3) predictive maintenance, and (4) data science and analytics in asset management. LinkedIn was used as a search tool to identify experts who matched either one, or a combination, of the required knowledge domains. Candidate experts were contacted through mail and were sent a two-page information sheet with background information about the research and the aim of the expert meeting. The final step in selecting the experts was a brief intake interview by phone to assess the candidates’ suitability as an expert for the purpose of the meeting. This procedure created an expert panel that could cover all dimensions of the maturity framework. The final panel balanced the roles of the asset owner and the maintenance contractors (Table 4). Four experts worked for asset owners; two of them in CFM organizations of universities, and two of them in large asset management organizations of public infrastructure operators. Three experts worked for maintenance contractors in building services and data science. Two had experience in working for CFM organizations of universities. All experts were provided with information on the maturity framework 5 days before the consultation took place. The consultation was held online. Separate online meetings were organized for two experts who were unable to join the group meeting. During these meetings, the experts commented on the following questions: (1) Which maturity dimensions do you recognize as important and why?; (2) Which maturity dimensions do you consider unimportant and why?; and (3) Which maturity dimensions are missing?

Case Study and Data Collection

The typical case was used to find barriers for smart maintenance because data quality was identified as a concern to the CFM organization. The research question that guided the case study was as follows: What are the characteristics of maintenance networks that form a barrier for smart maintenance and what processes are required to eliminate those barriers?

The extreme case was used to find drivers of smart maintenance maturity. Contrary to the typical case, in the extreme case, asset data management was insourced. Prior to the case study, asset data management-related capabilities were implemented, enabling the organization to reach an unusual high level of maturity in asset data governance. The university’s CFM organization had been recognized by independent researchers as a best practice case in asset management and the asset management team was internationally certified and awarded for their achievements (Vago 2018). During the initial conversations with leaders and key informants of the CFM organization in negotiating access, this unusually high level of maturity was reflected in a detailed, accurate asset register and implemented practices and procedures for intra- and interorganizational asset data governance. For the extreme case, the following research question guided the case study: How is internal and external collaboration driving smart maintenance and what processes are required to implement such collaboration?

Data was collected through 48 semistructured interviews and analyzing case-related documentation. The respondents were selected for their knowledge and experience in working with asset data. They were recruited from different teams within CFM (project management, maintenance management, procurement), main contractors and subcontractors. They were identified with the assistance of the key informant through snowballing on embedded case level, as well as on organizational level (Tables 5 and 6). All interviews were recorded, transcribed, anonymized, and sent to the respondents for comments. The software NVivo version 12 was used to code and analyze interview data. The case studies were also informed by project data. The documents collected included, among others, contracts, information system documentation, and minutes of contract governance meetings. In Cases 1 and 2, the first researcher was given access to contractual documentation and to the online file sharing platform used to store and share drawings and technical data on the buildings. The contract documentation included, but was not limited to, requests for expression of interests, program of requirements, pricing formats, and maintenance implementation plans. The information management documents included (when available) asset register structure, site-related technical log file structure, data hub structure, and building passport design. Organizational policy documents included, but were not limited to, organizational charts and the contract governance structure. In Cases 3 and 4, the first researcher joined a project handover meeting as an observer (Case 3) and visited an equipment site (Case 4) with a service technician. Finally, secondary data was collected: two student reports on data quality and data ownership in building maintenance (Cases 1 and 2), a state government audit report on asset management in universities (Case 3), and online news articles (Cases 1, 2, and 4). During the overlapping periods of data collection and analyses, the researcher kept a diary and took notes from informal and occasional conversations. These were used to interpret the data and adjust the interview questions during the data collection.

In the final stages of both the typical and the extreme case, findings were discussed with key informants of the cases. In the typical case, draft versions of case study reports were discussed with participants and key informants from both levels of analysis (embedded case level and organizational level). In Cases 3 and 4, findings were discussed with two key informants during final interviews.

Cross-Case Analysis and Expert Validation

Case data of the four cases was analyzed in different ways to identify the maturity dimensions for smart maintenance. Coding was used to analyze the data and identify maturity dimensions. Coding in qualitative research is a process of breaking down qualitative data into component parts, which are given labels that seem to be of theoretical significance or that appear to be particularly salient within the social worlds of those being studied (Bryman 2012). The way the data is labeled in coding may depend on which angle or lens is being used by the researchers (Saldaña 2016). Using different lenses in coding the data for the cross-case analyses of the typical and extreme case provided understanding of what happened in both cases (Bazeley 2009). In Cross-case analysis 1, for the typical case, the lens used for coding was finding barriers for smart maintenance (Fig. 2). For the typical case, data was screened for text fragments that described processes related to absent or underdeveloped asset digitalization. Coding of the data produced 15 barriers (Cases 1 and 2) for smart maintenance (Table 7). For Cross-case analysis 2, the lens for coding was finding drivers for smart maintenance (Fig. 2). Data was screened for text fragments that described processes that enabled collaboration between asset owner and maintenance contractor in exchanging digital asset data. Initial coding produced 17 drivers (Cases 3 and 4) for smart maintenance (Table 7). The second step in data analysis was to use several tactics to combine and refine these 15 barriers and 17 drivers into a coherent and manageable set of maturity dimensions. First, the barriers and drivers were compared in case they might refer to the same underlying process and could be integrated into a single maturity dimension. Second, axial coding was used to refine and describe the meaning of the maturity dimensions. In that process, data or text fragments were reassembled to link lower-level maturity dimensions to higher-level maturity dimensions, thus bringing structure and hierarchy into the maturity framework (Saldaña 2016). Third, the emerging maturity dimensions and their relations were compared with those of existing maturity models to understand to what extent they confirmed or deviated from them. This iterating process, comparing empirical findings with existing maturity models or frameworks, is described as “matching” by Dubois and Gadde (2002, 2014).

After the maturity dimensions were identified, both CFM Organizations A and B were compared in Cross-case analyses 3 to identify measuring scales for the maturity dimensions. Many existing maintenance maturity models, based on the capability maturity model (CMM) or capability maturity model integration (CMMI) framework (Paulk et al. 1993; Macchi and Fumagalli 2013), use five or six levels to measure maturity as the extent to which certain processes are implemented and repeatedly practiced. Although this approach has proven its value for certification purposes, it has received criticism as discussed by Pöppelbuß and Röglinger (2011). According to King and Kraemer (1984), maturity models should not focus on a sequence of levels toward a predefined end state, but rather on factors driving evolution and change. The rationale behind the Cross-case analysis 3 is to maximize learning by comparing the extreme with the typical case. Therefore, the analysis aimed at identifying the factors for each maturity dimension that drove evolution toward an extreme case. The question that guided the analysis was as follows: What variables can be used to express differences in the level of maturity for the identified maturity dimensions?

Combining the data from the typical case and the extreme case for all maturity dimensions, ensured that both ends of the spectrum could be defined qualitatively. Selective coding of data from Cases 3 and 4 for all maturity dimensions ensured the data was screened for text fragments that described the organizational development of CFM Organization B for that particular dimension. This process showed that, for almost all 23 lower-level maturity dimensions, there was a strong relationship between the lower-level and the associated higher-level maturity dimension, in the sense that the same scale variable could be used for both.

When these maturity dimensions were presented to the experts, they were asked to respond to three questions: (1) Which maturity dimensions do you recognize as important and why?; (2) Which maturity dimensions do you consider unimportant and why?; and (3) Which maturity dimensions are missing?

With respect to the first question, “alignment,” “leadership,” and “culture” were mentioned as important maturity dimensions because they were considered critical for collaboration and communication between clients and contractors, as well as between different departments of the client. “Culture” was considered important as something that should be developed top-down from senior management toward middle managers and the workforce, in order to stimulate behaviors aligned with the intentions of contractual arrangements. “Knowledge management” was considered important because retirement of maintenance staff and outsourcing often lead to a loss of tacit knowledge.

With respect to unimportant dimensions, one contractor-employed expert regarded “tracking and tracing of jobs” to be unimportant because this data allegedly would be recorded elsewhere in the maintenance supply network by the contractors and subcontractors. However, one other client-employed expert thought this was a relevant dimension because it assures access to relevant management information. These differing expert opinions point to the different positions that clients and contractors take in controlling the maintenance service supply network and the use of information for that purpose; this will be discussed later in the paper.

With regard to maturity dimensions missing in the model, one expert suggested “user communication.” In the final analysis, the researchers chose not to follow this suggestion because, while relevant for facilities management, this was deemed to be beyond the scope of the smart maintenance maturity model.

Dimensions Found

According to the procedures described in the “Methodology” section, the smart maintenance framework was developed and validated. It consists of 23 lower-level maturity dimensions that are linked to 8 higher-level maturity dimensions (Fig. 4).

Governance structure is about allocating responsibilities for tasks, activities, or processes to persons or organizational units. The data from the cases showed various levels of maturity in this respect, but designing governance structures emerged as a relevant dimension of maturity in smart maintenance in all the cases, in particular on the areas of: project governance, maintenance governance, and data governance. Governance of projects refers to decision-making responsibilities for initiating and delivering projects. These responsibilities can be allocated to one centralized capital works unit, or they can be allocated to different parts of the organization (e.g., based on location, project-type, or asset class). Governance of outsourced maintenance refers to the allocation of responsibilities for outsourcing maintenance and administrating maintenance contracts. These responsibilities can be allocated to one centralized unit, or to different parts of the organization (e.g., based on location, building, or asset class). Governance of asset data refers to the allocation of responsibilities for definition, capturing, and storing asset data. Just as with the other governance dimensions, these responsibilities can be centralized or decentralized.

Alignment of data definitions, processes, and systems is about linking and connecting data definitions, processes, and systems from different actors in a meaningful way. There was no central repository where all asset data was stored for any of our cases, and each actor used his own system. Alignment emerged as a relevant maturity dimension. Alignment of processes and work instructions refers to the extent to which processes and work instructions of the maintenance organization are aligned with those of internal stakeholders (mainly the capital works team), as well as external contractors. Processes prescribe workflows that can flow across organizational boundaries, and work instructions prescribe how individuals behave in certain situations. When processes and instructions are aligned, contractors, project managers and maintenance managers use consistent ways for capturing and working with data in different stages of the project or asset life cycle. Alignment of data definitions refers to the extent to which data definitions of the maintenance organization are aligned with those of internal stakeholders (mainly the capital works team), as well as external contractors. When the data definitions are aligned, contractors, project managers, and maintenance managers use the same terminology and data definitions across different stages of the project life cycle. Alignment of systems refers to the extent to which systems of the maintenance organization are aligned with those of internal stakeholders (mainly the capital works team), as well as external contractors. Different stakeholders should be aligned to produce the same output, even when they use different commercial products and systems.

Tracking and tracing is about the ability to identify individual pieces of asset data. Tracking and tracing was associated with three types of asset data: assets, condition, and jobs. Assets tracking and tracing refers to the way the maintenance organization tracks and traces individual assets. One manager reported that approximately 600 smaller and larger projects were executed on a yearly basis to adapt the facilities to accommodate changing requirements. Asset data can be stored in the asset register according to different levels of detail to keep track of all assets. The level of detail is related to the way larger infrastructures are configured and broken down into individual components and subcomponents. Condition tracking and tracing refers to scale and frequency of collecting condition data. Condition data, for example, can be captured for all the assets on a yearly basis (large scale + high frequency), or for a part of the assets, on a 3-year frequency (limited scale + low frequency). For some pieces of equipment that are monitored closely, specific condition data can be automatically sampled in intervals of milliseconds. Jobs tracking and tracing refers to the way individual maintenance jobs can be traced back to individual assets. A maintenance job on a chiller, for example, can be linked to that specific chiller (high detail) or it can be linked to the building where the chiller is located (low detail).

Data-driven decision-making is the ability to support maintenance decision-making by the analysis and interpretation of various data sets. Data-driven managerial decision-making emerged around life cycle modeling, predictive maintenance, and evidence-based contract administration. Life cycle modeling refers to a structured and systematic approach to analyze and predict the service life of all assets, based on condition data and predictive models. The maintenance organization, for example, can produce a yearly life cycle condition report for the assets under maintenance. Predictive maintenance refers to the ability to implement and use predictive maintenance policies for critical assets in which servicing is not executed according to predetermined intervals or run hours, but according to predictive analysis of real-time data streams. In evidence-based contract administration, the maintenance organization supports the procurement organization in managing the contract with the maintenance contractor by providing evidence-based information on the number of assets and the exact amount of maintenance tasks that have been carried out in a specified time window.

Sustainability monitoring is about the ability to measure and report asset performance from a sustainability perspective. In our cases, this was related to energy performance and asset replacement and upgrade programming. Energy performance measuring and verification refers to the consistent evaluation of energy performance. In energy performance contracting, the evaluation of the realized water and energy savings relies on accurate data and certified verification methods. Asset monitoring and replacement programming refers to the systematic review of the asset portfolio from a life cycle perspective. While certain assets may have several remaining years of technical service life, upgrading them before end-of-life may improve the energy performance or might even be desirable from a strategic real estate management perspective. For some asset classes, relocation of an asset from one building to another may be an option.

Knowledge management in this context describes the ability to learn from the processing of networked asset data. This emerged in some rather practical and down-to-earth ways. Contractor instruction and coaching refers to the maintenance organization’s role in instructing and coaching the maintenance contractor in their data capturing role (e.g., barcoding individual assets, tagging maintenance jobs to individual assets, coordinating subcontractors), ensuring that the contractor is supplying the data in the right formats and definitions. Project manager support refers to the maintenance organization’s role in instructing and coaching the project managers in their data capturing responsibilities, during project delivery and project handover, ensuring the project manager is supplying the data in the right formats and definitions. Knowledge creation refers to the way data is used to create managerial insights about maintenance, combining explicit and tacit knowledge in various degrees. In Cases 1 and 2, for example, planning and decision-making was based heavily on tacit knowledge, while in Cases 3 and 4 tacit knowledge was used to trigger and interpret the data analytical side of understanding. The maintenance organization can use its data about the assets and their behavior to learn about the maintenance needs and requirements of their assets. The accumulation of data creates insights, making the maintenance organization become more knowledgeable.

Culture is related to human values and behavior. Many respondents recognized that digitalization of assets was changing maintenance processes, but the extent to which the cultural dimension of these changes was addressed, varied among the cases. Culture is related to the handling of nonstandard data, the valuation of asset data and the innovation approach of the maintenance organization. Handling nonstandard asset data refers to the behaviors of individuals in dealing with unknown, unfamiliar, and nonstandard facts, information, and data. Nonstandard data was not treated as a valuable asset in Cases 1 and 2, while in Cases 3 and 4 the team members of the maintenance organization demonstrated ownership and acted as data stewards trying to incorporate nonstandard data into the system of data definitions. Valuation of asset data is related to the behaviors of individuals and teams to recognize the value of asset data to improve maintenance operations and to develop practices to assess this value from the perspective of different stakeholders. Innovation approach refers to the attitudes and behaviors with respect to innovation. This varied from a culture of continuous improvement toward one of incidental and incremental (project-based) improvement.

Leadership emerged in the sense of creating a safe learning environment and propagating shared business goals and values. As one senior management put it, “My team members are allowed to fail.” By practicing this rule, he was creating a safe learning environment. It is the ability to create a trustful learning environment where staff members are encouraged to “try new things” and “are allowed to fail.” At the other end of the spectrum, leadership can create an environment that is risk averse in which people are charged for their errors. Shared business values and principles refers to the extent to which leadership of the maintenance organization propagates and applies a set of shared values (e.g., service excellence, continuous improvement, innovation) and practices among its staff members. Leadership can be based either on a clear set of shared values and principles or on individualized values and principles.

Case Comparison

Table 8 provides the case data for the four embedded cases from CFM Organizations A and B. We can make some observations by comparing the case data. First, the data suggest that maturity in smart maintenance is more related to organizational factors than to contractual factors. It appears that when certain capabilities have reached a certain level of maturity, they are used in whatever contractual arrangement maintenance is executed. Cases 1 and 2 were situated in the same maintenance unit (MU) of the same CFM organization. While both cases dealt with different asset classes, there were many similarities in the way asset data was managed. In both cases the same governance structure for maintenance was used by the corporate facility management organization, in which authorization of maintenance jobs and projects was allocated according to a separation of responsibility for different groupings of assets. Capturing and maintaining asset register data was also outsourced to the maintenance main contractor in both cases, without processes, work instructions, and data definitions being clearly described and defined. Alignment of data definitions, processes, and systems was rather immature, just as the tracking and tracing capabilities were. While the MU did use a CMMS, it was not used for storing and warehousing structured asset register data. The CMMS data was on a high level of abstraction compared to the CMMS data in the main contractors’ system. The condition monitoring data was gathered on a high level of abstraction, and with a low frequency (once every 3 years). While the maintenance main contractor operated a digital asset register, this was not shared with the MU frequently. Data exchange was very much based on unstructured information in pdfs, Word documents, and spreadsheets. Since the basic data was not very well managed, the MU’s maturity on data driven decision-making and sustainability monitoring was rather low.

Both Cases 3 and 4, in many ways, were the opposite of Cases 1 and 2. Sustainability ambitions of the university, incorporated in the energy performance contract (EPC), triggered changes in the MU’s data management role. New jobs were designed around data management activities. Two asset database officers were made responsible for capturing asset data, scheduling maintenance jobs, and ongoing updating of the digital asset register for the entire building portfolio. Another job was designed around asset life cycle coordination and capturing condition assessment data systematically on a yearly basis. The development of this new role for the MU was part of a wider ambition within the corporate facilities management organization to raise the standards of professionalism and to create a culture of continuous improvement.

Comparing the MU of Cases 1 and 2 with the MU of Cases 3 and 4, it appears that a shared vision on the asset life cycle within the CFM organization can catalyze the maturing process in smart maintenance. It was accepted in Organization A that the worlds of project managers and the maintenance managers were to a certain degree two different worlds, each with their own interests, culture, and practices. Whereas in Organization B, senior managers from the maintenance unit invested heavily on a personal level in building relations with the project managers from the capital works team. They developed a shared vision on the overall project (or asset) lifecycle in which the roles of both teams were described. This so-called gateway process was the master process for many other collaborative processes and data definitions that transcended the boundaries of different units.