Digital Integration in Construction: A Case Study on Common Data Environment Implementation for a Metro Line Project

Abstract

This study examines the deployment of a Common Data Environment (CDE) during the extension of a major North American metro line—an infrastructure project marked by complex stakeholder dynamics and fragmented digital practices. Employing a four-phase action research approach (diagnosis, planning, implementation, evaluation), the research identifies inefficiencies in existing document management through contract reviews, field observations, and stakeholder interviews. In response, three standardized processes were introduced to streamline document workflows within the Autodesk Construction Cloud (ACC). These processes enabled partial automation of data handling, reduced reliance on manual inputs, and improved the consistency of information exchanges. While constrained by limited governance and executive engagement, the initiative demonstrates the potential of CDEs to support digital integration and automation in construction. Findings highlight the need for early planning, field-level support, and a strategic framework to ensure sustainable adoption. The results contribute practical insights for leveraging CDEs to enhance automation in large-scale infrastructure projects.

1. Introduction

Large-scale infrastructure projects are characterized by the involvement of numerous stakeholders (clients, architects, engineers, contractors, subcontractors, specialists, etc.) and the deployment of diverse digital systems, making information management inherently complex [1]. digital systems and platforms refer to commonly used CDE solutions such as Autodesk Construction Cloud, Aconex, and Procore, along with internal document management systems; and project information encompasses drawings, models, technical specifications, quality records, contractual documentation, etc. Interactions between project participants are frequently fragmented, spread across multiple platforms, and often lack traceability [2]. This fragmentation undermines transparency, hinders the reconstruction of action histories, and impairs overall coordination [3]. In the absence of centralized information flows, errors, data duplication, contractual disputes, delays, and cost overruns become common [1,4,5]. Amid ongoing advances in information technologies, Common Data Environments (CDEs) have emerged as promising tools to address these challenges [6,7,8]. A CDE refers to a centralized digital space that enables all stakeholders to collect, manage, validate, and share project data throughout its entire life cycle [6,7]. By integrating collaborative functionalities with Building Information Modeling (BIM) capabilities, CDEs offer a structured framework for managing project information. They enable the centralization of document exchanges, the standardization of processes, and comprehensive traceability throughout the project life cycle [6]. Despite this potential, CDEs remain insufficiently deployed in practice. Their implementation is often hindered by the lack of standardized reference frameworks, appropriate governance structures, and alignment with on-the-ground operational realities [9]. CDE adoption requires strict document discipline, standardized procedures, and validation workflows aligned with contractual responsibilities [6]. International standards, such as PAS 1192-2/3, the Singapore BIM Guide, and ISO 19650, provide guidance for effective CDE implementation, defining responsibilities, interoperability requirements, and governance structures [10,11,12].

Operational CDEs are typically supported by platforms like Autodesk Construction Cloud, Aconex, Procore, or Unifier, which centralize project data including models, drawings, technical documents, and meeting records. When properly configured with clear roles, workflows, and trained users, CDEs improve coordination, traceability, and documentation quality, while reducing redundant tasks and data loss [13,14,15]. Despite these benefits, CDE deployment faces significant challenges. Interoperability issues are common, as large projects often involve a mix of client-mandated, contractor-specific, and subcontractor software, leading to information fragmentation and version inconsistencies [6,16]. Technical difficulties, including software updates, file format incompatibilities, and connectivity problems, further complicate adoption. Increasing data volumes amplify the need for structured processes, which many teams are not yet prepared to implement effectively [6,17]. While previous research has extensively described CDE concepts and standards, few studies have examined their practical deployment in complex infrastructure projects with a focus on bridging technological capabilities and organizational processes. This paper contributes by presenting a structured framework for CDE deployment that explicitly addresses interoperability, workflow standardization, and stakeholder coordination, providing actionable guidance for practitioners that goes beyond theoretical discussions.

This study aims to explore these issues through the implementation of a CDE in the context of a major infrastructure project currently underway in North America. The project presents a high degree of technical, organizational, and documentary complexity, making it a relevant and representative case for analyzing the practical challenges of deploying a CDE. The research adopts an applied, action-oriented methodology to investigate how a cross-functional digital solution can address field-level needs, enhance collaboration, and strengthen the integration of production, quality assurance, and project documentation. The remainder of this article is organized as follows: Section 2 reviews the theoretical foundations of digitalization and collaboration in construction projects, the use of Common Data Environment as a digital backbone, and the limitations of interoperability and implementation challenges. Section 3 details the research methodology. Section 4 presents the main results while the key findings and implications are discussed in Section 5. Section 6 concludes the article.

2. Literature Review

2.1. Digitalization and Collaboration in Construction Projects

Traditional organizational structures in construction projects are typically based on a sequential and fragmented approach [3], in which design, construction, and operation are divided among multiple independent entities, each operating under separate contracts [18]. This model results in low process integration and limited communication between stakeholders, which hinders collaboration [19]. In response to these limitations, various innovations have emerged to enhance coordination and collective performance. Integrated Project Delivery (IPD), for example, seeks to bring together all project stakeholders—owners, contractors, and designers—from the early stages of the project. It is based on a single multi-party contract and emphasizes shared risks and benefits [20]. Although not yet widely adopted, this relational approach encourages the development of synergies and shared goals at the project level. In this evolving context, the digitalization of processes plays a central role. Technological advancements—particularly the widespread adoption of Building Information Modeling (BIM), collaborative platforms, and information management systems—are driving the sector toward what some authors refer to as Construction 4.0 [21,22,23,24]. This transformation is not only enabled by BIM as a foundational technology but also by the growing integration of digital systems that enhance coordination, centralize data, and optimize workflows [25].

As Kalay [26] emphasizes, collaboration relies on “an agreement among specialists to share their capabilities within a particular process in order to achieve the broader objectives of the project.” Such collaboration depends on structured information management that allows stakeholders to share, access, comment on, and validate project data at any time, without loss of continuity. In this regard, digital platforms play a structuring role. They connect dispersed teams, centralize documentation, track approvals, and automate repetitive tasks. The BIM Handbook [27] identifies Common Data Environments (CDEs) as the digital backbone of the project, capable of supporting interdisciplinary communication and data exchange [8]. Among the most widely used platforms today are Autodesk Construction Cloud (ACC), Aconex, Unifier, Thinkproject, Procore, and Trimble Connect. Their adoption enables a shift from siloed operations to a collaborative model, integrating various information flows such as drawings, technical documents, meeting minutes, communications, and forms. These tools offer a framework conducive to real-time coordination, provided they are embedded in well-defined processes and supported by strong document governance [28,29]. However, the effectiveness of an information system does not rest solely on the technology itself. It also depends on organizational adaptation, the clear definition of roles and responsibilities, and the genuine adoption of platforms by users. Today, this adoption dynamic is at the heart of successful digital project delivery.

Finally, there is a growing trend toward the development of unified platforms that integrate multiple functions, including document management, scheduling, site monitoring, quality control, and communication. This centralization aims to improve traceability, reduce human error, and provide a consolidated real-time view of the project. As Guo [16] notes, a well-designed collaborative platform can help reduce costs and delays, improve quality assurance, and enhance risk management.

Despite the growing adoption of CDEs in construction projects, existing research primarily focuses on theoretical discussions of information management and platform capabilities [6,13,16,27]. Few studies provide a structured framework that explicitly addresses interoperability, workflow standardization, and stakeholder coordination, leaving practitioners without actionable guidance to implement CDEs effectively. This gap limits the ability of project teams to fully leverage CDEs for collaborative work and process optimization.

2.2. The Common Data Environment as a Digital Backbone

With the widespread adoption of BIM and collaborative approaches, Common Data Environments (CDEs) have emerged as key structuring components in construction projects. A CDE refers to a centralized digital space that enables all stakeholders to collect, manage, validate, and share project data throughout its entire life cycle [6,7]. Today, this concept is at the heart of digital transformation strategies in engineering and construction. The BIM Handbook [19] identifies CDEs as essential technical foundations for effective information management. Their primary objective is to provide a unified framework for document dissemination, accessible at any time to authorized users, with clear version histories, statuses, and validation records.

According to Preidel et al. [6], the use of a structured CDE requires strict document discipline: documents must follow standardized distribution procedures, adhere to predefined naming conventions, and undergo validation workflows aligned with contractual responsibilities. The adoption of international standards reinforces this approach. Several reference frameworks have been developed to guide the implementation of CDEs, including:

• PAS 1192-2 and PAS 1192-3 [10], which define documentation requirements for the delivery and operational phases;
• The Singapore BIM Guide [11], which outlines roles and procedures within a CDE;
• ISO 19650 [12], the internationally recognized standard that formalizes information management in the context of BIM through standardized processes and clearly defined responsibilities.

The UK BIM Alliance [12] emphasizes that applying ISO 19650 enables the establishment of a shared governance model for information, by defining the client’s information requirements, the associated responsibilities for data production, and the procedures for data transfer and archiving. This standard also promotes interoperability between tools, clarity of deliverables, and consistency in practices across project participants.

Operationally, the CDE is supported by a digital platform—such as Autodesk Construction Cloud (ACC), Aconex, Procore, ThinkProject, or Unifier—that centralizes project information, including drawings, models, technical documents, meeting records, inspection sheets, and more. Access is typically controlled through user profiles, with predefined workflows structuring the validation processes. Radl and Kaiser [13] highlight that a properly implemented CDE offers numerous benefits: improved coordination, enhanced traceability, reduced redundant tasks, minimized data loss, and overall better documentation quality. However, these benefits are only realized when the platform is correctly configured from the outset, roles are clearly defined, and users are adequately trained. The CDE is not merely a technical tool—it serves as an organizational infrastructure designed to structure information exchange, support project workflows, and provide a reliable foundation for project management [9,14,15]. Its success depends as much on technology as on the definition of usage rules, team discipline, and effective change management.

While standards provide general guidance, they do not offer concrete frameworks that integrate technical, organizational, and procedural aspects into actionable deployment strategies. This represents a critical research gap, which this study aims to address by proposing a practical, structured approach to CDE deployment that explicitly considers interoperability, workflow standardization, and stakeholder coordination.

2.3. Limitations of Interoperability and Implementation Challenges

While digitalization and the implementation of Common Data Environments (CDEs) are now central to modernization efforts in the construction industry, their deployment on the ground continues to face numerous challenges. Among the most prominent is the issue of interoperability, the ability of digital systems to communicate and function effectively together. In large-scale projects, it is common to encounter a mix of digital tools. A platform may be mandated by the client, while the contractor relies on an internally developed solution tailored to their operational needs. On top of this, subcontractors often use specialized software to meet their own requirements. This technological heterogeneity leads to information fragmentation and makes it difficult to establish a seamless document management chain. As Preidel et al. [6] highlight, the absence of a unified environment increases the risks of data redundancy, version inconsistencies, and loss of control over information flows. Guo [16] further emphasizes the necessity of centralizing data within a single collaborative system to ensure effective coordination among stakeholders.

According to Preidel et al. [6], a lack of interoperability results in duplicate data entry, document duplication, and diverging versions of the same files—all of which pose risks in terms of compliance, delays, and contractual accountability. The parallel use of multiple systems multiplies potential points of failure, complicates coordination, and places a significant administrative burden on site teams. These challenges are not limited to organizational factors; technical difficulties are also considerable. Frequent software updates, file format discrepancies, compatibility restrictions, and connectivity issues on construction sites all contribute to a diminished user experience. As noted by Khan, Flanagan, and Lu [17], the growing informational complexity, driven by the increasing volume of data to be managed, further underscores the need for rigorous process structuring, a requirement that many teams are not yet equipped or prepared to meet.

By highlighting these challenges, this study identifies the need for a structured CDE deployment framework that explicitly addresses interoperability, defines workflows, and clarifies stakeholder responsibilities, thereby providing practical guidance for implementation in complex infrastructure projects.

3. Research Methodology

3.1. Research Objectives

The digitalization of the construction sector, driven in particular by BIM and collaborative platforms, is profoundly transforming information management practices [24]. Common Data Environments (CDEs) have become essential for centralizing documents, ensuring traceability, and facilitating coordination among stakeholders. Their structure relies on solid frameworks, such as the ISO 19650 standard, which defines responsibilities and associated processes. However, the implementation of CDEs on the ground faces several challenges, including the coexistence of multiple platforms, limited interoperability, information overload, and resistance to change. These limitations highlight that the success of a CDE depends as much on technology as on its integration into the daily practices of the project. This observation forms the basis of our study, which focuses on the implementation of a CDE within a major project, such as the extension of a metro line.

The management of a metro line extension project presents several major challenges at the intersection of technical, organizational, and digital dimensions. Firstly, the scale of the project and its division into multiple independent contracts require the coordination of numerous stakeholders, each working within specific areas, with their own methods and schedules. This fragmented organization naturally complicates the flow of information and alignment between teams. Furthermore, the volume of data and documents generated throughout the project demands robust tools to ensure their storage, updating, and real-time distribution, while also facilitating their effective utilization. In addition, the coexistence of multiple digital platforms (ACC, Aconex, SharePoint, etc.), while individually useful, can create informational silos, duplicates, and even inconsistencies in document validation and transmission processes. Finally, in a multi-stakeholder context, it becomes essential to ensure both the traceability of actions, the reliability of shared data, and the accessibility of information for all participants, whether they are on-site, in the office, or on the client side. These challenges make it crucial to reflect on the digital tools used, their governance, and the accompanying work processes.

The objective of this project is to implement a centralized digital solution capable of meeting the technical requirements of the site while taking into account the specific needs of the various stakeholders involved. The goal is to create a Common Data Environment (CDE) that centralizes documentation, reduces manual tasks with no added value, and rigorously governs the document exchange flows, from their creation to their delivery. By facilitating access to information and ensuring its reliability, the solution also aims to strengthen coordination among all parties. Through this approach, the project seeks to support the execution of work while establishing coherent and shared digital governance.

3.2. Research Approach

The methodological approach chosen for this study is based on an action-research framework. This approach allows for the combination of observation, experimentation, and adjustment, relying on the active involvement of stakeholders and a deep understanding of the field [30,31]. As shown on Figure 1, it is structured around an iterative cycle consisting of four phases: diagnosis, planning, implementation, and evaluation.

3.2.1. Diagnosis: Analyzing the Needs and Existing Processes

The diagnostic phase constituted the first step in the action-research cycle. This phase allowed for the identification and definition of the issues related to the project. It also provided an understanding of the current context and the workflows in place on the ground. The main gaps in the processes and key areas requiring improvements were also identified. Furthermore, the goal of Common Data Environments (CDEs) is to serve as centralized data hubs. Interviewees were selected to capture multiple perspectives: the Quality Department on documentation and compliance, the construction team on operational workflows, and Technical Management on strategic coordination. This ensured a comprehensive understanding of CDE deployment challenges and practices. Given that the users are transversal and involved across multiple departments, the needs analysis took into account the specific expectations of the technical management (Methods, Surveying, etc.), Quality assurance, and construction teams.

These expectations were considered because, for these departments in particular, the data flows carry greater significance and present higher risks. Initially, a thorough analysis of the project’s reference documents was conducted. These documents are divided into two categories: contracts and internal management plans. At the time of the study, two contracts had been awarded to the consortium, while the others were still in the bidding process. These contracts are organized into two volumes and consist of 13 sections, with 8 of them addressing the various aspects of the project. Once the contractual documents were analyzed, a review of the management documents was necessary to assess what had been planned by the project teams to meet the previously listed expectations. In a construction project, at a minimum, one management plan per department is expected. However, the management plans relevant to the integration of a Common Data Environment (CDE) are as follows: the document management plan, the quality management plan, the subcontractor deliverables management plan, the technical management plan, and the BIM management plan. Finally, an in-depth analysis of the existing processes, whether integrated into official platforms or not, was conducted. This study included an examination of the flow of information through Aconex and ACC, as well as through other tools or platforms such as emails, SharePoint, or Unifier. This analysis allowed us to evaluate what had actually been implemented in terms of information exchange platforms for the project.

The interviews were conducted either individually or in groups, depending on availability and department. However, the discussion topics were the same and were divided into two segments: feedback on existing processes and their needs. The first part on feedback focused on several discussion points, helping identify the current issues present in the project:

• How did they actually use the platforms in place?
• Which platform did they use the most?
• How did information flow in practice?
• How was it linked to the documents and elements necessary for construction?
• Which actions were causing time loss?
• How was the tracking process carried out?

The second part involved a genuine exchange where all participants shared their needs or suggestions for improving their daily operations. Some were more open to changing their way of working than others. Since Aconex, SharePoint, and Unifier were already established within the company, the project team identified ACC as the platform with a broader set of functionalities that could address unmet needs not fully covered by the existing systems. To facilitate this, we demonstrated what ACC offers and how we had used it on other projects to give them an idea of the possibilities within ACC. The interviews in the Quality Department (Including Document Management) involved the quality director, the document management responsible, the quality control manager, and the document management technician. These interviews were conducted individually during the week of 28 October to 1 November 2024, with each session lasting approximately 30 min. These interviews were held in a hybrid format (in-person or remote). For the construction team, 4 group interviews were conducted on 4 different construction sites, during the week of 25 to 29 November 2024, and lasted approximately 1 h and 30 min. The interviews were held in the construction site trailers. The interview groups were selected based on the project sites. The first group interview includes 1 assistant construction manager, 2 work coordinators and 1 work supervisor. The second group interview includes 1 assistant construction manager, 1 work coordinator and 1 quality coordinator. The third group interview includes 1 project manager, 1 assistant construction manager, 2 work coordinators, 1 quality coordinator and 1 work supervisor. The last group interview involves 1 project manager, 1 assistant construction manager, 1 work coordinator and 1 quality coordinator. For the technical management direction, which consists of several branches, including the design of temporary works, BIM, geomatics, and discipline-specific specialists such as geologists, the interviews focused on two branches (Methods and Surveying). For the Methods branch, the interviews and were conducted collectively in-person at the project office, during the week of 28 October to 1 November. For the Surveying branch, the interviews were conducted remotely on 29 November. Each interview lasted approximately 1 h.

In addition to the interviews conducted to identify the issues and needs of each stakeholder expected to use ACC as a priority tool, regular discussions were held with the teams responsible for implementing digital tools. Indeed, the role of ACC had not been clearly defined, particularly regarding basic questions such as: What is the purpose of ACC beyond viewing drawings and documents? What types of documents are available on the platform? What is the relationship between Aconex, the project’s document management platform, and ACC? How do the two platforms interact or interfere with one another? Four entities were consulted: the project management team, including the directors of all departments, the system integration team, the project’s Aconex specialist and their supervisor. This phase aimed to understand how the platforms were configured and what the initial intentions were behind their deployment. The data collected during the preliminary phases was used to map the processes using Visio, with the objective of highlighting the following elements:

• Key process steps: Identification of the starting and ending points of information flows.
• Stakeholders: Visualization of interactions between field teams, document controllers, and other involved parties.
• Interactions: Understanding how information circulates throughout the project.
• Tools used: Integration of digital platforms such as ACC and Aconex, as well as email, Unifier, SharePoint, and others. Aconex is a cloud-based platform that facilitates document exchange, structured workflows, and traceable communications among stakeholders. SharePoint is a collaborative platform that provides document storage, file sharing, and basic versioning features, often serving as a repository within organizations. Autodesk Construction Cloud (ACC) integrates various modules for document management, model coordination, field tracking, and reporting, supporting both design and construction activities. Oracle Unifier is a project controls platform that emphasizes cost management, contract administration, and process standardization. Each of these platforms offers specific functionalities, and their combined or parallel use illustrates the diversity of digital solutions currently available to the construction sector.

The processes were analyzed based on several criteria including the frequency of individual involvement, the number of manual actions required, the number of tools involved, and the number of distribution platforms used. This evaluation allowed us to assess the efficiency of each process and identify potential areas for improvement. It also enabled us to determine where ACC could be effectively integrated within the workflow. The diagnostic phase enabled the precise identification of dysfunctions and improvement opportunities within the existing processes. The detailed review of contractual and internal documentation, combined with direct observations and numerous interviews across departments (technical management, quality, construction), provided a solid foundation for planning a tailored solution aligned with the demands of a major infrastructure project.

3.2.2. Project Planning

The second phase, project planning, served to structure and organize the actions to be undertaken in response to the issues identified during the diagnostic stage. It enabled the definition of clear objectives, the selection of appropriate technological solutions, and the preparation of an experimentation plan. Following the preliminary diagnostic, observations were structured to extract clear and actionable areas for improvement. The definition of objectives was carried out progressively:

• Grouping of Issues: Recurrent problems were first categorized by theme, such as information access, traceability, and cross-platform coordination.
• Formulation of Objectives: These thematic issues were then translated into concrete and achievable objectives, designed to guide the subsequent phases.
• Prioritization of Objectives: Each objective was assessed in terms of criticality, cross-referenced with contractual requirements, and aligned with the issues identified in the diagnostic phase. This enabled the establishment of a clear order of priority.
• Validation with Teams: Finally, the objectives were discussed with the relevant teams to validate their relevance and ensure alignment with field realities.

This step allowed the project team to move from a broad overview to a set of clear directives, forming the foundation for selecting tools and structuring the experimentation plan. Once the improvement objectives were defined, a comparative analysis of the digital platforms in use on the project was conducted. The aim was to clarify the respective roles of each platform and determine which ones to prioritize, based on their actual functional capacities. A set of functional criteria was developed to objectively evaluate the digital platforms. These criteria were derived from needs identified during the diagnostic phase and from the specific requirements of the construction site’s operational environment. They covered the technical, documental, and organizational dimensions of a Common Data Environment (CDE), and were grouped into four main categories: operations/Field use (mobility, navigation, BIM visualization, etc.), document management (structure, access rights, traceability, etc.), automation and processes (workflows, validation, reminders, cross-referencing, etc.), user experience (ease of use, loading times, customization, etc.).

For each criterion, a score out of 5 was assigned, along with a descriptive comment on the actual capacity of each platform (ACC, Aconex, SharePoint) to meet the corresponding requirement. A 5-point scale was chosen to balance granularity and simplicity. It allows participants to express degrees of agreement or satisfaction clearly, while keeping the scoring intuitive and consistent with common Likert-scale practices in construction management and information systems research. The evaluation intentionally focused on the native functionalities of the tools, independent of current usage or team habits. The objective was to compare the platforms on an objective functional basis, in order to identify their complementarities and limitations. This evaluation resulted in a comprehensive comparison table summarizing each platform’s performance across themes. were assigned based on the combined experience of the researchers and the feedback collected from interviewed practitioners. The individual sub-criterion scores were then averaged to produce the overall score for each criterion, ensuring a consistent and informed assessment of each platform. The findings guided the selection of priority tools and helped structure information exchange processes within a coherent multi-platform environment.

Once the roles of the platforms were clarified, a formalization phase was initiated to construct the associated processes. The goal was to organize interactions among the identified digital tools in alignment with the previously defined improvement objectives. An initial modeling of the proposed processes was sketched for validation and communication with project stakeholders. The purpose of this modeling was to establish a shared language ahead of the testing phase. This step followed naturally from the tool selection process, translating tool choices into operational sequences involving specific actors. The process models were based on improvement objectives, observations of existing practices, gathered during weekly site meetings held in December, iterative feedback from the quality and document management teams to gradually refine the proposed workflows. During the planning phase, project teams were actively involved through a series of weekly meetings conducted at each site throughout December. These sessions aimed to better understand the specific needs of each team and gain detailed insight into their current working methods, particularly in relation to document management and use of digital platforms. The feedback gathered during these sessions informed refinements to the working hypotheses, supported the process modeling efforts, and contributed to structuring the experimentation plan. This iterative approach ensured alignment with on-the-ground realities and helped foster greater ownership of the upcoming phases.

The experimentation plan was developed through a structured and gradual approach, combining a controlled test environment, checkpoints, and a phased rollout strategy. A dedicated test project was first set up to develop, adjust, and structure the tools and processes to be tested. This pilot allowed for the simulation of real use cases, identification of potential technical constraints, and preparation for field testing. Subsequently, regular presentations were held with involved teams (quality, construction, technical management) to compare working hypotheses with actual practices, collect precise feedback, and refine the selected scenarios. Finally, the experimentation plan was structured according to a progressive deployment logic designed to begin in a controlled and stable environment, extend the testing to another project segment with different characteristics, scale up to all project sites based on insights from initial testing phases. This structured approach aimed to secure the deployment by minimizing risks and maximizing learning outcomes. It also ensured continuous adaptation before any large-scale implementation.

3.2.3. Implementation

The implementation phase aimed to apply the solutions defined during the planning stage within a real-world environment. This phase facilitated the testing of new practices, observation of user reactions, and adjustments to solutions based on feedback. It was crucial for validating procedures and ensuring that the changes addressed identified needs, while also providing ongoing support to reduce resistance to change and ensure proper adoption of the tools. Following the planning phase, several workflows were proposed to the management and quality teams; only the approved and validated processes were deployed. The platforms involved, primarily ACC, were configured accordingly. The deployment adhered to the action plan established during planning and included: configuration of the TQ module in the test environment, adaptation of processes based on feedback from decision-making teams (quality, project management), communication of usage instructions to operational teams, demonstration of best practices and training sessions.

To ensure the effectiveness and adoption of the new tools, a methodology for observing behaviors and making continuous adjustments was implemented. This approach aimed to guarantee the efficiency and adoption of the new tools by the teams. Once the processes were deployed in the test environment, they were presented to the relevant teams. Meetings were organized to inform, train, and allow them to test the tool in the test environment. This enabled direct feedback, discussions, and addressing of their questions, facilitating continuous adjustments to the process or training. Subsequently, when these processes were deployed on the “pilot” site, a field observation phase was initiated to verify tool usage. This observation focused on several elements: smooth execution of steps by users (response time, blockages); adherence to planned sequences or deviations from the formalized process; misuse or unintended use, indicating unanticipated issues. Observation was conducted through direct consultations of platforms (examination of logs, activity tracking in ACC), informal interactions with users, and occasional on-site presence to capture real-time usage. After the observation phase on the “pilot” site, this phase was repeated on another site with different constraints and teams. Finally, after adjustments were made on both sites, the processes were generalized to all sites. Again, the observation phase was resumed, maintaining the possibility for further adjustments. The objective of this step was to identify areas of confusion or ambiguity in the process, as well as signs of process ownership, to guide necessary future adjustments.

Throughout the implementation phase of the new processes, active collection of user feedback was conducted to guide adjustments and assess the gradual adoption of the deployed tools. This approach aimed to capture diverse feedback, both formal and informal, from various stakeholders. Several methods were employed: weekly on-site discussions with construction teams, as well as office meetings with quality and document management teams, to regularly assess tool usage; spontaneous feedback from informal interactions, questions posed directly within platforms or via messaging. Feedback focused on clarity of processes and user understanding, ease of use of the processes, discrepancies between proposed processes and actual practices, suggestions for improvement or requests for support. This feedback was essential for understanding how users were adopting the new processes. It helped identify strengths and areas for improvement. With this information, processes were adjusted to better meet user needs and ensure successful adoption.

3.2.4. Evaluation

The evaluation phase was conducted following implementation in order to analyze the tangible effects of the processes introduced, to gather feedback from stakeholders, and to formalize improvements for long-term integration. This phase was structured around three complementary activities: a comparative analysis of processes before, during, and after implementation, overall stakeholder feedback, identification of final improvements. A comparative analysis was carried out to assess the discrepancies between the original processes, those designed prior to implementation, and the final processes. This comparison was based on flowcharts developed during the diagnostic, planning, and implementation phases, field observations, including processing times and delays, user feedback on the perceived impact of changes (workload, clarity, fluidity). The evaluation focused on the risks identified during the diagnostic stage. This approach enabled an assessment of how effectively the new workflows contributed to risk reduction and achievement of the improvement objectives.

The evaluation of goal attainment was conducted by comparing observed outcomes during implementation with the improvement objectives defined in the diagnostic phase. The assessment was based on comparative process analysis, observation of actions and process application, qualitative user feedback collected during weekly exchanges with the quality, construction, and methods teams. Each objective was evaluated according to the level of achievement demonstrated by the implemented processes: fully achieved, partially achieved, or not achieved. This analysis provided a concise overview of the extent to which each process addressed the identified operational needs, while also highlighting both the effective levers and the remaining limitations.

4. Results

4.1. Summary of Identified Needs and Issues

To clarify the issues and facilitate comparative analysis,

Table 1. Summary of needs by category.

Category	Contractual Needs (Client)	Internal Needs (Consortium)
Document management	– Updated RDL – Annotated plans (as-built) – Revision tracking – Drafts linked to schedule	– Centralization of information – Easy search – Reduction of duplicates
Traceability/compliance	– Formal validation workflow – Archiving of letters and deliverables – Clear statuses	– Ensure the document is up to date – Accessible history – Simple traceability
Quality	– PIE – Hold points – Tracking of non-conformities (NCR, DAC)	– Digitalization of quality tracking – Automation of reports and follow-ups
BIM/modeling	– Weekly model submissions – Clash detection – Constructability reviews	– Shared environment for modeling – Synchronization between models and documents
Planning and progress	– Progress tracking – Progress dashboard – Shared schedules	– Clear link between documents and schedule – Easy visualization on site
Tools interoperability	– Unified tool used by the owner – Compliance with required format	– Clarification of the ACC’s role – Simplified platform exchange
Usability and on-site		– Annotate, highlight, measure on plans – Quick access on site
External relationships	– Access to deliverables for the owner – Client exchange management	– Traceability with subcontractors – Fast and secure sharing
Support and Training		– Need for tool training – Support during change

provides a summary of the identified needs, distinguishing between the contractual requirements of the project owner and the internal needs expressed by the construction consortium teams during the interviews.

This synthesis highlights several discrepancies between the contractual expectations and the internal needs expressed by the teams. These gaps, further supported by field observations, enabled the identification of a series of issues that are presented in the following section. One of the first indications of these divergences emerged during the interview with the Aconex specialist. He described the platform as fully operational, with automated workflows, active use by the owner, and effective participation from subcontractors. However, these claims were found to be significantly at odds with the observations and feedback gathered during other interviews. Several points were thus called into question:

• Workflows were, in most cases, not automated: document controllers were still performing many manual actions, including the attachment of correspondence;
• Few subcontractors were actually present or active on Aconex: many exchanges still occurred via email or through other channels;
• The owner did not systematically respond via Aconex, with some of its departments already using Unifier for certain types of communication.

These validations confirmed that the “functional and theoretical” vision presented by the owner did not reflect operational reality. Several processes described as automated or integrated were, in fact, only partially implemented—or did not exist at all.

One of the most concerning findings—cutting across all the identified issues—is the current inability to ensure that the information available on the platforms is indeed the latest up-to-date version. On a construction site, such uncertainty can lead to execution errors, rework, or even non-conformities. This risk stems directly from the lack of governance over the digital tools, the fragmentation of communication channels, and the absence of clear processes for validating and disseminating information. Building on the previous observations, several major issues have been identified. These reflect a significant gap between the expected functioning of the digital platforms and their actual use by project teams:

Lack of a clear framework for the use of ACC: Although ACC was introduced as the reference platform for the construction phase, no official framework defined its specific role within the project environment. No document outlined which types of documents were to be published there, the rules for uploading, the associated responsibilities, or the connections with other tools.

Proliferation of platforms and loss of coherence: The project simultaneously uses several digital tools: Aconex, SharePoint, ACC, Unifier (introduced mid-project by the owner), and email. This proliferation of platforms without centralized governance has led to redundancies, inconsistencies, and fragmented information.

Some teams rely almost exclusively on SharePoint for their day-to-day monitoring, others continue to use email, while some work through Aconex. Documents often exist in duplicate, with different versions depending on the platform. This situation complicates information retrieval, undermines document reliability, and compromises traceability.

Non-automated document processes: Contrary to what was claimed in certain interviews, document validation processes are not automated in Aconex. While workflows exist in theory, their implementation relies heavily on manual actions, particularly by document controllers. One of the most illustrative examples is the manual attachment of correspondence within Aconex transmissions to process documents. These actions are performed manually, increasing processing time and exposing the process to errors or omissions. This lack of automation limits system efficiency and creates a considerable additional workload for the document management technicians.

Inefficient transmission between Aconex and ACC: A script was implemented to automatically transfer validated “Issued for Construction” documents from Aconex to ACC. In theory, this was meant to ensure smooth synchronization between the two platforms, avoiding duplication and enabling rapid access to documents in the field. In practice, the script does not function reliably. Poorly entered metadata in Aconex disrupts the import process in ACC, resulting in documents being misclassified or even unusable. As a result, essential documents are either not found or appear in incorrect locations, making ACC’s use chaotic for the field teams.

Lack of traceability in subcontractor communications: Another critical issue is the lack of traceability in exchanges with subcontractors. In many cases, subcontractors have not been fully integrated into Aconex or do not use it. Communication continues via email, with no clear version control or formal archiving. This poses a significant contractual risk, particularly when it comes to justifying decisions or tracking approvals. The absence of a single, controlled communication channel makes it difficult to reconstruct exchanges in case of disputes or quality inspections.

Limited knowledge and low adoption of digital tools: Finally, a project-wide issue lies in the lack of knowledge or poor adoption of digital tools. Some users have never been trained on Aconex or ACC and do not understand how these platforms complement each other. This leads to underuse of their functionalities and a return to informal practices. This is compounded by resistance to change: several individuals have developed specific work habits and show reluctance when changes are introduced or new tools are implemented. Recurring comments such as “I can’t find what I’m looking for in Aconex” or “I don’t know if my drawing is up to date” illustrate these usability challenges. Without proper support and role clarification, the digital tools fail to deliver their structuring potential and to improve the project’s overall efficiency.

4.2. Process Mapping and Analysis

To complement the analysis of the identified issues, a mapping of the documentary and informational processes was carried out. The objective of this mapping is to provide a clear and concise representation of the actual information flows and the digital tools used at each stage. This representation helps to illustrate current practices—which are sometimes misaligned with the project’s original intentions—and to highlight the manual actions and risks embedded in the existing processes.

4.2.1. Information and Document Flow from Subcontractor to Client

Figure 2 illustrates the example of a deliverable produced by a subcontractor. The subcontractor receives a request by email, prepares the document, and then returns it via email. The received file is then manually processed by the construction consortium team (including codification and the creation of envelopes), before being uploaded to Aconex. After several manual steps (workflows, correspondence), the document is sent to the client. A response may arrive via Unifier, which must then be manually transferred back into Aconex in order to maintain traceability. In parallel, the document is often re-uploaded to SharePoint, or even stored locally, to facilitate on-site access. This complex circuit illustrates the overlap of tools and the risk of disruption in information continuity.

Several critical points clearly emerge from this representation:

• Email-based exchanges with subcontractors: All communication and document reviews with subcontractors are conducted outside the official platforms, via basic email, without systematic archiving or guaranteed traceability.
• Bypassing of official tools: Some stakeholders do not use the designated platforms and instead continue to operate according to their established habits (manual transfers, exclusive use of SharePoint, etc.).
• Redundant document deposits: As a direct consequence of the previous point, the same document may be uploaded to Aconex, then transferred to SharePoint and/or saved locally. This leads to duplication and weakens version control. Information becomes isolated from its source, making it impossible for users to ensure they are working with the correct version.
• Lack of clear synchronization with acc: Aligned with the previous issues, document transfers to ACC rely on a script that, in practice, does not function properly due to poorly entered metadata. Documents are misclassified or cannot be located, which significantly limits the usability of ACC in the field. As a result, document transfers are carried out manually rather than automatically.
• Numerous manual actions: Codification, envelope creation, workflow initiation, and attachment of correspondence are all performed without automation, increasing the risk of human error and causing delays. While some manual actions are unavoidable, it is both possible and necessary to reduce their number.
• Parallel and unsynchronized circuits: Although Aconex is intended to be the official platform, the gradual implementation of Unifier by the owner further disrupts the continuity of processes. This adds yet another layer of mandatory manual transfer.

Table 2. Risks Associated with the ‘Subcontractor to Client’ Process.

Risk	Description
No guarantee of up-to-date version	Multiple sources of the same document exist; there is no guarantee that the one consulted on site is the correct one, as no one checks directly in Aconex.
Distribution errors	Manual actions (coding, attachment, distribution) are subject to omissions or incorrect handling.
Loss of traceability	Exchanges take place via email or SharePoint without formal archiving. In case of a dispute, the justifications are difficult to retrieve.
Loss of time	Non-automated workflows and multiple submissions cause delays in information distribution.
Inefficient use of ACC	The platform is not used as intended: documents arrive in a random or incomplete manner.
Confusion between platforms	No clear rule defines which tool should be used for which type of document or process.
Contractual risk	If a transmitted document is not the validated or up-to-date version, it may lead to liability for the contractor toward the owner.

presents the risks associated to the subcontractor-to-client process.

This mapping highlights a largely manual, fragmented, and interpretative operation, which is misaligned with the initial goals of a shared data environment.

4.2.2. Information and Document Flow from Client to Subcontractor

The second mapped process concerns the flow of information transmitted by the client to the subcontractors, passing through the internal teams at construction consortium (Figure 3). This is a critical process, as it determines the subcontractors’ access to essential documents: directives, plans, deliverables, contracts, etc.

The client transmits the documents via FTP upload (or Unifier). These documents are then manually downloaded by the Document Management team and subsequently integrated into Aconex with enriched metadata. A transmission is created, and the document becomes available on the platform. The majority of departments do not consult Aconex directly, as they receive notifications with all the necessary information. The information is then manually redirected to other channels (SharePoint, local servers, or email) to facilitate access. This redistribution is rarely structured or centralized.

The same risks identified in the previous processes are also present here (

Table 3. Risks associated with the ‘client to subcontractor’ process.

Risk	Description
Multiple Submission Points	Documents are copied across multiple platforms: SharePoint, local servers, ACC. This increases workload and multiplies the versions in circulation.
Lack of a Single Official Channel	There is no guarantee that the subcontractor receives the information via Aconex, as contractually required. Responses are sent only by email, without archiving.
Very Low Traceability	No system reliably verifies whether a document was sent to the right person or at what time.
Longer Processing Time	Lack of automation (uploading, submission, notifications) causes delays in dissemination, especially during major updates.
Contractual Risk	The contractor is supposed to ensure that subcontractors work with valid documents. However, the multiple detours and channels used weaken this guarantee.

and

Table 4. Risks associated with the Technical Questions management process.

Risk	Description
Transmission delay	Lengthening of processing times
Loss of traceability between the TQ and its response	Impossible to prove that the TQ was processed or received
Incorrect version	Execution of work based on outdated information
Contractual risk in case of failure to consider a TQ response	Liability of consortium questioned
Incomplete or erroneous dissemination	Lack of reliability in document management
Non-positioning of TQs on the plans	Risk of error or oversight on the ground
Duplication of information between platforms	Scattered information and divergent versions

). This process clearly illustrates the multiplicity of information dissemination platforms. In addition, there is a visible manual break in the transmission from the consortium to the subcontractor.

The management process for Technical Questions or Request for Information is a key formal communication channel to ensure proper interpretation of contractual documents, resolve technical uncertainties, and secure the execution of works (Figure 4). It is therefore critical that this process be rigorous, traceable, and fully integrated into the project’s digital environment.

These three process mappings highlight fragmented information flows, reliance on manual actions, and a proliferation of digital tools. Far from constituting a structured environment, the project’s digital landscape reflects a set of localized practices, often misaligned with contractual obligations. As such, intervention is required to restore coherence and reliability to these processes.

The diagnostic phase laid the groundwork for the development of a solution tailored to the project’s realities. Through document analysis, direct observations, stakeholder interviews, and process mapping, a clear picture of the current situation was established. This analysis revealed a significant gap between contractual expectations, the internal intentions of the construction consortium, and the actual practices implemented on the ground. The absence of a formal framework, the overlap of digital tools, the reliance on manual actions, the lack of traceability, and the uncoordinated use of platforms are all barriers to effective and reliable information management. This situation creates considerable uncertainty regarding the validity of documents used for work execution, thereby exposing the project to operational and contractual risks. The diagnostic clearly demonstrates the need for a structured intervention aimed at clarifying the roles of digital platforms, simplifying document flows, and ensuring the reliability of information. The next step will therefore consist in designing a solution that addresses the identified challenges.

4.3. Action Plan

The second planning phase was used to structure and organize the actions to be undertaken in response to the issues previously identified. It enabled the definition of objectives, the selection of appropriate technological solutions, and the preparation of a pilot plan.

4.3.1. Definition of Improvement Objectives

The first step in this phase involved clarifying the goals pursued through the implementation of a digital solution better suited to the project’s needs. These objectives were formulated based on the findings and risks identified during the diagnostic phase. The following objectives were defined, in order of priority:

• Make construction documents available through a single access point, by promoting a work platform that centralizes information and connects data sources;
• Ensure the reliability of the information distributed, by reducing the risks of duplication, conflicting versions, or data loss;
• Regulate the exchange and transmission of documents, particularly with subcontractors and laboratories, in order to limit email communication and formalize information flow processes;
• Reduce manual tasks and low-value-added actions for teams, such as document searches, redundant sending, or non-automated process management;
• Ensure continuous monitoring between construction activities and quality requirements, by facilitating the link between production documents and quality control elements.

These objectives served as a guiding framework for selecting tools, structuring the pilot plan, and engaging stakeholders in the process.

4.3.2. Selection of Platforms to Be Used

The aim of the analysis was to clarify the usage of the various digital platforms already in use on the project. This selection was based on a predefined set of evaluation criteria field use, document management, automation and workflow and user experience (See

Table 5. Comparison of platforms available within the consortium.

Category	Criteria	ACC	Aconex	SharePoint
Field	Field adoption/usability	3	3	3
	BIM support and plan visualization	5	4	0
	Interoperability	4	3	2
	Accessibility on mobile devices	5	5	2
	Ability to work offline	5	3	0
	Search capability	5	5	2
	Navigation within the drawings	5	3	3
	Subtotal	32	26	12
Document management	Information centralization	5	5	3
	Traceability/Logging	5	5	1
	Archiving/Contractual reference	3	4	2
	Access rights management	3	5	2
	Folder organization	5	1	2
	Customizable metadata	5	5	1
	Status tracking	4	5	0
	Timestamp/Signature	4	5	0
	Subtotal	34	35	11
Automation and processes	Automation/workflow	5	5	0
	Internal validation	5	5	0
	Automatic notifications	5	5	0
	Interactive forms	5	3	0
	Reports/Dashboards	5	4	0
	Deadlines and reminders	3	5	0
	Cross-referencing between documents	5	3	0
	Subtotal	33	30	0
User experience	User-friendly navigation	5	3	3
	Loading time	4	4	4
	Simplicity of common tasks	3	3	2
	Ease of use without training	5	3	3
	Interface consistency	5	3	3
	Customizable interface	5	5	3
	Integrated user support	5	5	2
	Subtotal	32	26	20
	TOTAL	131	117	43

). These criteria were designed to capture the core dimensions of CDE performance that are most relevant for project stakeholders and reflect both technical functionalities and user-oriented aspects. The framework is divided into three main categories—document management, automation and processes, and user experience—which together provide a holistic perspective on the capacity of CDE platforms to support collaboration and information management.

The first category, document management, focuses on the fundamental role of CDEs in centralizing, securing, and structuring project information. Sub-criteria such as information centralization, traceability, archiving, access rights management, and metadata customization ensure that data can be reliably stored, retrieved, and validated throughout the project lifecycle. These elements directly address contractual and compliance requirements while reducing risks of information loss, redundancy, or version inconsistencies.

The second category, automation and processes, evaluates the ability of the CDE to streamline workflows and reduce manual tasks. Features such as automated workflows, internal validation, interactive forms, dashboards, and deadline reminders provide significant value by standardizing procedures and minimizing the risk of human error. This dimension reflects the extent to which the CDE can act as a process enabler, transforming traditional document management into an integrated and proactive system that supports real-time coordination.

Finally, the user experience category emphasizes the importance of accessibility and ease of adoption. Even the most advanced technical platform cannot achieve its potential without strong user acceptance. Sub-criteria such as navigation simplicity, loading time, consistency of the interface, and the availability of integrated support were therefore included to evaluate how intuitive and user-friendly the CDE is in practice. By considering this dimension, the evaluation framework acknowledges that successful digital transformation depends as much on organizational adoption as on technical capacity.

Aconex stands out for its strong document control capabilities and customizable workflow management. It enables precise control over document circulation (access rights, strict versioning, conditional visibility) and prevents duplicate file names. It is therefore well suited for official communications. However, its rigid interface and transmission-oriented logic limit its effectiveness as a daily working tool. ACC was selected as the main working platform due to its ability to centralize information and facilitate collaborative work in the field. It allows users to view, annotate, measure, and link a wide variety of documents (PDFs, drawings, 3D models), while maintaining clear version control. Its intuitive interface, mobile consultation features, tracking tools, and cross-referencing capabilities make it an effective and accessible platform, especially suited to the needs of site teams and subcontractors. It supports the structuring of exchanges, reduces duplication, and enhances operational traceability. SharePoint does not provide significant added value for the project’s document management or as a working platform. In fact, its widespread use introduces considerable risks, particularly in terms of document duplication, loss of traceability, and confusion regarding current versions. To limit these issues, its use must be strictly controlled and restricted to internal Microsoft Office production documents (e.g., Excel calculation sheets, internal Word documents), with no archival or inter-team sharing function. Unifier is the platform mandated by the owner and serves as the exclusive channel for document exchanges with them. All documents officially sent to or received from the client must go through Unifier, making it an essential tool for structuring processes related to contractual obligations. Outlook is no longer part of the official processes; the objective is to avoid email-based exchanges altogether.

The allocation of roles across platforms helps clarify their use and avoid sources of confusion or information loss. ACC is designated as the central working platform for production-related information, while Aconex is maintained as the official document database. Unifier is used solely for formal exchanges with the client, and SharePoint is strictly limited to internal office documents. This clarification forms a foundational step in establishing coherent, readable, and operationally relevant processes. It also marks a clear break from the informal use of email as a transmission tool, which is now excluded from the target workflows.

4.3.3. Mapping of the New Processes

Following the clarification of platform roles and discussions with field teams, several processes were formalized to organize interactions between the project’s digital tools. These processes aim to structure the circulation of documents, regulate transmissions, and ensure the traceability of exchanges within a multi-platform environment.

Two main process families were identified, namely the owner inputs (documents received from the owner to be distributed to the construction consortium and subcontractors) and deliverables (documents produced by the construction consortium or subcontractors intended for the owner). We proposed generic “template” processes for each of these families. From these baseline models, we then developed more specific processes to be implemented quickly in order to mitigate existing risks.

Figure 5 and Figure 6 are flowcharts representing the two baseline processes upon which the subsequent workflows were built. This led to the development of dedicated processes for Technical Questions (TQs), the tracking of test requests to laboratories, and the management of internal documents issued by the technical department. These processes were represented using flowcharts, serving as a shared foundation for communication, experimentation, and future adjustments.

The proposed processes are primarily intended to address the shortcomings observed in terms of traceability, consistency of document uploads, and the dispersed workload among the various stakeholders. They directly respond to several previously identified risks, including the loss of information due to off-platform exchanges (e.g., via email), lack of visibility on the document progress status, and the absence of a consistent framework for transmissions between the construction consortium, its subcontractors, and the owner. By requiring the use of empty envelopes in ACC, establishing clear validation steps, and delineating interactions with Aconex, Unifier, and ACC, these workflows significantly reduce repetitive manual tasks (such as downloading, renaming, and redundant transfers). They also ensure a clearer separation between tools used for operational purposes (ACC) and those used for contractual exchanges (Aconex, Unifier). The potential implementation of these standardized processes would thus offer a concrete response to the complexity of a multi-platform environment, while introducing standardized, reproducible, and scalable practices.

As analyzed during the diagnostic phase, the current Technical Questions (TQ) process is inefficient, time-consuming, and disconnected from other construction documents. Based on this assessment and subsequent discussions, a new process was designed for proposal and testing (Figure 7). The new workflow is intended to address the main shortcomings identified: lack of formal tracking, document fragmentation, and redundancy in manual tasks. By placing ACC at the center of internal exchanges and assigning Aconex and Unifier their respective contractual roles (archiving and communication with the owner), the proposed process clarifies responsibilities, secures documentation, and significantly reduces coordination efforts. This structure supports a smoother and more compliant management approach that aligns with client requirements, while reinforcing the link between TQs and other project documents.

In parallel with the TQ process, internal workflows were developed in ACC to meet the operational needs of the technical management team, particularly the methods department. These processes, which are non-contractual and not intended for formal exchange with the client, were designed to improve upstream coordination by structuring the review of internal documents, temporary works drawings, and technical working deliverables. They are aligned with the standard workflow patterns previously defined. Nonetheless, this solution structures a review stage that was previously entirely informal. The new process introduces systematic validation by a methods coordinator prior to any distribution, with a clear cycle of revision, commenting, and metadata input. Although limited to internal exchanges, this workflow enhances document control discipline and helps ensure data reliability upstream of contractual exchanges, while streamlining collaboration between designers, coordinators, and other technical departments.

The process of managing test requests (Figure 8), fully designed in ACC through the Forms and Submittals modules, addresses the complete absence of a standardized procedure. Before its implementation, requests were made informally, often communicated by email or orally, without clear tracking or structured supporting documentation. The new workflow centralizes the entire cycle—from the creation of the request to the final submission of the test report to the client—within a unified circuit. Thanks to the standardized form in ACC, each request is traced, linked to contractual references, and positioned on the plan, which simplifies its processing by laboratories and validation by the quality team. The deposit of reports in a specific inspection envelope, combined with systematic verification before transmission, ensures the completeness of deliverables and strengthens the reliability of the transmitted data. This process also establishes a clear link between tests and inspection requests, thus ensuring greater documentary coherence and improved coordination between field teams, quality assurance, and document management (EDM).

All the proposed processes provide a concrete response to the limitations observed during the initial diagnosis, both in terms of traceability and documentary consistency, as well as coordination among stakeholders. By structuring exchanges around clear workflows tailored to the project’s constraints and the tools in place, these processes facilitate the gradual integration of a cohesive document management approach, even within a complex multi-platform environment. Each specific process reflects the intention to formalize operational practices, reduce discrepancies between departments, and ensure reliable information at all stages of the document cycle. By leveraging ACC as a technical foundation and ensuring contractual obligations through Aconex and Unifier, these solutions not only enhance efficiency but also enable better control of risks associated with exchanges, validations, and deposits. They thus provide a solid basis for the experimentation phase and the forthcoming adjustments.

4.3.4. Experimentation Plan

The experimentation plan was developed following a progressive and structured approach to test the modeled processes and assess their relevance under real-world conditions. The implementation was carried out in three stages:

• Test Project and dedicated development environment: A test project was set up to centralize all preparatory developments, serving as a space to configure folder structures in ACC, create standard forms, simulate workflows, and model practical use cases. It also helped identify potential technical issues, such as interoperability, permissions, and ergonomics, while assessing how the system would integrate with other platforms.
• Presentations and validation exchanges: At the conclusion of the initial developments, presentation sessions were organized with the concerned teams, particularly quality and document management, the key decision-makers for the processes. These exchanges aimed to present the proposed operating logic, confront the scenarios with the reality of practices on-site, and gather targeted feedback, critiques, and adjustments before the test in real conditions. Since Document Management was responsible for Aconex, these exchanges allowed for a better understanding of the interface between ACC and Aconex to optimize the information exchange.
• Progressive deployment: Finally, the experimentation was deployed progressively. Initially, for processes involving the construction team, a construction site was selected as the “pilot” site, due to the advanced state of its works. For other processes, a group of individuals was selected to test with participants who were expected to use the process. Next, for the construction processes, the experimentation was extended to another construction site, stemming from another contract, in order to test the processes in a different operational context while maintaining a monitoring logic. The second site was selected based on three main criteria: (1) the use of a CDE platform that was actively adopted by project stakeholders, (2) the involvement of multiple disciplines requiring intensive coordination, and (3) the availability and willingness of the project team to participate in interviews and provide access to project data. This complementary case allowed us to strengthen the robustness of the analysis and demonstrate the broader applicability of the framework. For the remaining processes, the group of individuals concerned was expanded. Finally, a phase of generalization to all sites and all relevant personnel on the project was initiated, based on the adjustments derived from the initial feedback. This progressive deployment allowed for the approach to be secured and for identified gaps to be corrected in real time.

This stage allowed us to transition from a general diagnosis to a concrete plan for the proposed solution. We clearly defined the improvement objectives, selected the platforms based on their complementarity, and modeled the essential processes to organize document flows in an environment using multiple tools. Our approach relied on active participation from the teams and an evaluation of the tools used by the construction consortium. The experimentation plan that was developed allowed us to test the information circuits in an experimental phase before broader deployment.

This phase allowed us to structure the use and guarantee testing conditions. In the following section, we will present the results of the implementation phase, detailing how the workflows were tested under real-world conditions.

4.4. Implementation of Solutions

All workflows modeled during the planning phase were presented to key stakeholders, including the quality, document management, and project management departments. Despite the proposed optimizations and risks, most of the processes were not selected for experimentation. However, three exceptions were validated for implementation:

• The management process for Technical Questions (TQ), deployed in ACC;
• Internal processes developed for the technical department and methods, aimed at structuring document reviews and monitoring the production of drawings;
• The process for testing requests up to the submission of reports by the laboratory.

The decision to maintain the other existing processes was based on a desire to keep the current processes and platform in place. In the case of TQ, the benefits of managing them in ACC quickly became evident, such as the ability to position them directly on plans, functional links to other documents, better visibility for all stakeholders, and a streamlined process compared to the initial workflows. For the technical department, the introduction of internal workflows in ACC helped organize review and coordination work around technical plans and documents, in collaboration with the methods teams. Regarding test requests, these were previously made informally by email or phone to the laboratory, often missing information such as quote requirements, volumes, durations, or technical data sheets. Additionally, the quality team was unable to track the tests conducted, which elements were tested, and what was expected from the laboratory. With ACC, we were able to standardize these requests and ensure that all the necessary information was included. It is around these three validated processes that the implementation phase was conducted.

4.4.1. Implementation of the Technical Questions (TQ) Process in Real Conditions

The TQ module was first configured in ACC and then tested in a dedicated environment, Consortium–Sandbox. This phase allowed us to simulate several use cases, validate the logical flow of the process, and align its structure with the consortium’s specific needs in information management and technical coordination. Once this preparation phase was validated, the process was deployed at the first construction site, selected as the pilot site. The objective was to assess the alignment of the process with field practices. The placement of the TQs on plans, their cross-functional visibility, and their association with other documents (plans, tests, sheets) allowed for seamless integration into the teams’ routines. The transparency of information and the reduction in email exchanges were noted from the first uses. This initial deployment was later extended to the second construction site in a different context. This second phase confirmed the robustness of the process and its ability to adapt to varied teams and constraints.

The final TQs management process (Figure 9) was implemented during the first week at first construction site, followed by the second week at the second construction site. The process quickly proved its value and was generalized to all sites. Several adjustments were necessary during the experimentation phase, such as:

• Filters were added to facilitate the search and management of Technical Questions (TQs). Since TQs are processed by the client in Unifier, there can be a gap between the reception date and the processing date. To address this, we added both the sending and actual receipt dates. This improves the tracking of the TQ lifecycle and ensures more accurate management.
• The default stakeholders were modified to better meet the specific needs of the experiment. The technical department managers needed to view all TQs to assess their impact on design and temporary works. This ensured that the right people were involved from the start, enhancing the efficiency and relevance of interventions.
• Certain steps in the process were simplified to make it more fluid. For example, a step initially required in Aconex was removed, as it became redundant with the introduction of ACC. Specifically, the technical department was an entire step in Aconex, whereas making them observers in ACC was sufficient. This helped reduce delays and streamlined the process, improving overall efficiency.
• Targeted reminders were implemented to encourage good practices and proper information sharing within ACC. These reminders ensure that all stakeholders follow the established protocols and use the tools optimally, enhancing the quality and consistency of shared information.

These adjustments were made based on user feedback, following a continuous improvement approach. They made the process more accessible without altering its logic or objectives. Despite the quickly observed benefits, several resistances emerged during the experimentation:

• Initially, there was confusion regarding the platform to use for creating TQs, due to the historical use of Aconex for formal document exchanges.
• There was reluctance to change established practices, especially among users who had previously managed TQs via email or shared files. This was exacerbated by the lack of clear directives from the management during the first weeks, which led to a temporary coexistence of the process in both ACC and Aconex. This situation resulted in double entry of Technical Questions and operational confusion.
• Additionally, the document management technicians, the primary users of the process, were unfamiliar with ACC, as they had exclusively worked with Aconex until then. The switch in platforms was perceived as a significant break from their familiar methods.

These resistances were gradually overcome through regular communication with field teams and office personnel, providing concrete examples and best practices, targeted support during the first uses for all stakeholders, and a progressive clarification of each platform’s role within the processes.

The experimentation of the TQ management process demonstrated its operational relevance in ACC. Despite initial resistance due to work habits and a lack of clear directives, the process was progressively stabilized through targeted adjustments and active involvement of the teams. The centralization of information, reduction in informal exchanges, visibility of interventions, and adaptation to the specific needs of stakeholders brought tangible and immediate benefits, meeting the objectives identified during the diagnosis. To date, the TQ process is one of the most successful examples of an inter-platform process designed to meet production constraints while integrating contractual requirements.

4.4.2. Implementation of Internal Processes at the Technical Department

The experimentation began with the method coordinator, and his two designers. It was built around a structured document management approach based on the ISO 19650 standard. This method relies on separating work environments into three statuses: ongoing, shared, and published, enabling the tracking and control of document distribution. This established approach was adapted within ACC to structure internal document production while remaining flexible. The experimentation naturally aligned with the team’s existing practices, utilizing the collaborative tools of the platform to formalize exchanges and reinforce document rigor.

Designers worked in the “Ongoing” environment, their production space where they prepared working documents before sharing them with other stakeholders. Once completed, the deliverables were passed to the methods coordinator for formal review using ACC’s integrated review module. If approved, the document transitioned to the “Shared” status, with exchanges tracked, comments centralized, and annotations made directly on documents. Finally, before being shared with the client, a final review took place between the methods coordinator, the construction team on-site, and the HSE (Health, Safety, Environment) team, again using the review module. After this step, the document was approved and moved to the “Published” status, accessible to all and considered valid for execution. To ensure process rigor from the production phase, clear file coding was required, achieved through a request for a number in Aconex. At the end of the review process, metadata entry became mandatory, optimizing document searchability and maintaining a proper record of deliverables. Metadata was also necessary to create automations and ensure consistent tracking.

The process began by creating folder structures compliant with the ISO 19650 statuses (Ongoing, Shared, Published) to organize document production, review, and distribution stages. Additionally, a revision tracking system was integrated to identify documents needing comments, validation, or archiving. This allowed teams to always know the status of each deliverable in the internal validation cycle. Finally, the use of ACC’s review module centralized exchanges, allowed comments directly on documents (annotations), and tracked all actions during the review (who commented, validated, or modified what, and when). This module ensured complete traceability, smooth exchanges among stakeholders, and document consistency at each stage.

During usage, several adjustments were made to adapt workflows to the realities of the field. First, review templates were added based on document types to integrate the necessary stakeholders for each document requiring review. The processes were also optimized to allow or disallow the re-sending of revised documents at specific stages of the review. This was achieved through clearer role definitions. Review contributors were better identified for each document type, something that could not be clearly defined during small-scale experimentation. These adjustments were made in real time with the end users, following a test-and-improvement approach. Resistance was much lower compared to the TQ process, mainly because there was no modification to a contractual or official process, and document management had not been previously standardized. Teams were seeking solutions to better manage interactions among the different technical departments.

Nevertheless, some limitations slowed down rapid adoption, including the fact that initial habits of working on shared networks or locally persisted, some stakeholders lacked prior training on advanced ACC functionalities, such as reviews and annotations, and a need for clarity on responsibilities for internal validation sometimes delayed decisions. These resistances were gradually reduced through support and the integration of these tools into daily practices. Implementing internal workflows for the technical department and methods helped structure previously informal and scattered processes. By centralizing technical document exchanges in ACC, these workflows improved review coordination, better tracked internal validations, and reduced the risks of errors caused by multiple versions or email exchanges. This approach directly addressed several objectives set during the diagnostic phase, such as centralizing information, reducing manual tasks, and improving document continuity. Although not formalized within a contractual framework, these workflows have become effective operational management tools, well-suited to the project’s requirements and easily adaptable to other internal documents.

4.4.3. Implementation of the Laboratory Test Request Process

To complement the previously deployed workflows, a dedicated process for managing laboratory test requests was developed in ACC, in response to needs expressed by the quality team and a subcontractor (Figure 10). Previously, such requests were handled informally—by phone or email—without a standardized procedure, leading to missing information (e.g., specification requirements, volumes, durations, technical datasheets) and a lack of traceability for completed tests. Reports were also sent by email, with no structured link to inspected elements or inspection reports. The goal of the experiment was to formalize the process from the outset by introducing a single ACC-based form consolidating all necessary data. The process began with the creation of material-specific forms, followed by an automated system that generated properly coded empty envelopes for report uploads. These envelopes were linked to the test requests, which were in turn connected to inspection reports and field tests. This linkage was achieved via the ACC API, with a script running every five minutes.

To ensure standardized report naming, drop-down menus and fixed fields were added to the forms to enforce clean data input. This enabled automatic codification based on rule-based logic. The forms and script were first tested in a sandbox environment. Field visits were then conducted to explain the purpose of the tool and the need for a more structured process. While this added workload for construction teams, presenting the associated risks helped secure buy-in from stakeholders. A hybrid test phase followed, where requests were submitted both via ACC and by email, across all sites. Several adaptations were made to better align the process with field realities, namely the fact that mandatory fields were added to the form to ensure complete and standardized information (e.g., test location, technical requirements, material type), and a status tracking system was implemented, including response fields from the lab to reflect the request’s progress (sent, pending, confirmed, completed), as well as technician contact details. These improvements enhanced process reliability while simplifying daily use.

Although resistance was less significant than in other workflows, some challenges emerged, including the need for meticulous form completion was initially seen as burdensome by construction teams, who preferred informal methods (calls, direct exchanges) due to their speed and flexibility in urgent situations, and the transition to a new tool temporarily created confusion around responsibilities—who should fill out, approve, or send the requests. These issues were progressively mitigated through support from the quality team, which guided users, partial automation, particularly for generating the envelope, and maintaining informal channels for urgent situations, while ensuring all formal requests were submitted through the platform. This reassured construction staff and clarified the lab’s dual role in responsiveness and compliance.

The implementation of this laboratory test request workflow structured a previously informal and uncontrolled process. Centralizing the data in ACC improved the reliability and traceability of requests, reduced reliance on untraceable exchanges, and ensured each test was properly linked to technical documents. The quality team could now monitor progress, associate test results with specific construction elements, and manage test reports in a centralized manner. This process met key diagnostic-phase objectives, including better information structure, reduced data loss, and improved continuity between production and quality control. It contributes to more secure and efficient document handling while remaining workable for field teams.

4.5. Evaluation

4.5.1. Comparison of Processes Before, During, and After Implementation

A comparative analysis of the processes—those in place prior to the project, those designed during the planning phase, and those actually implemented—has objectively demonstrated the benefits of the initiative. This assessment drew on flowcharts developed at various stages, field observations, and user feedback. The Technical Questions (TQ) process underwent substantial transformation. Initially informal and fragmented across emails, manual uploads, and multiple platforms, the process lacked validation, traceability, and visibility. The implemented workflow introduced structured handling in ACC, formalized transmission via Unifier, and contractual archiving in Aconex. This reorganization improved information coherence, reduced manual tasks, clarified responsibilities, and enhanced overall process traceability and efficiency.

The internal methods process, previously non-existent, structured technical document production using standardized work environments and a formal review circuit. Inspired by ISO 19650, this approach improved documentation rigor and collaboration within technical teams. The laboratory test request process introduced a complete tracking system—from request initiation to report receipt. Standardized forms and automated report codification ensured reliable data exchange and maintained traceable links between tests, deliverables, and quality inspections.

4.5.2. Achievement of Objectives

Objective achievement was assessed by comparing observed implementation outcomes with the goals defined during the diagnostic phase. The first goal—to centralize access to information via a common data environment—was partially achieved. ACC served as the central platform for TQs, technical documents, and lab requests, improving accessibility and internal coordination. However, full centralization remains incomplete due to continued use of platforms like Aconex and SharePoint.

Regarding the goal of reducing duplication and enhancing data reliability, results were mixed. Structured workflows and standardized forms improved version control and reduced redundant documentation. Nonetheless, the rejection of two proposed standard workflows and a lack of directive support hindered full achievement of this objective. The goal of formalizing exchanges and transmissions was only partially met. While implemented processes helped formalize steps and reduce informal communication, the absence of finalized document management plans prevents wider enforcement and adoption of standardized practices. Manual task reduction showed clear and immediate benefits—though limited to the scope of the implemented tools. Low-value tasks were streamlined through automation (e.g., pre-coded folders, scripts, embedded forms), easing the burden on both document controllers and field teams. The objective of linking production with quality control was most successfully achieved. The new lab request process, in particular, enabled end-to-end tracking and alignment with quality inspections. While the implementation achieved several operational goals, the results remain partial due to limited organizational buy-in and the absence of a formal governance framework. Without document management planning or broader integration of proposed workflows, improvements are currently restricted to specific pilot cases. This outcome validates the solutions tested but also highlights the need for a more coordinated and top-down deployment strategy to extend these benefits across the entire project.

5. Discussion

5.1. Summary of Results

The implementation of the Common Data Environment (CDE) has yielded tangible results, although limited to certain parts of the project. While the most critical processes were successfully identified, analyzed, and modeled, their actual deployment was hindered by a lack of commitment at the decision-making level. Despite the warnings issued and the clearly identified risks, no structural action was taken. As of today, several of these risks have begun to materialize, placing the document management team under significant strain and exacerbating the deviations previously highlighted. Conversely, notable progress has been achieved in processes deemed less critical yet essential to the day-to-day operation of the construction site. The formalization of these processes within the platform facilitated information flow, clarified responsibilities, and reduced the workload for various stakeholders.

From a collaborative standpoint, several positive developments have been observed. The DT methods teams no longer upload their files to SharePoint, eliminating duplication and versioning issues. Designers can now exchange models directly through the platform, ensuring they always work with the most up-to-date version with minimal effort. More broadly, several internal departments have progressively adopted the platform as their main communication hub. It is now widely used across departments for sharing production-related documents, effectively becoming a common working environment. This shift has fostered improved information flow and smoother alignment among internal teams. In terms of quality monitoring, centralized information has allowed for better operational control. Construction and quality teams now rely on a shared platform, thereby avoiding parallel tracking in separate Excel files. This consolidation has enhanced the coherence of tracking efforts and minimized information loss.

Finally, the platform has helped partially address the shortcomings of Aconex, particularly regarding exchanges between the consortium and subcontractors. Rather than managing numerous downloads and email exchanges, subcontractors are now invited to directly access and upload their deliverables within the CDE. This not only eliminates unnecessary handling but also holds each stakeholder accountable for maintaining their own source of truth, anchored in a single, shared repository.

5.2. Key Success Factors for Sustainable Adoption

Team buy-in to a new digital solution relies not only on the tool’s quality but, more importantly, on the conditions under which it is deployed. This project has helped identify several essential factors for the success and long-term sustainability of a Common Data Environment. First and foremost, regular, personalized on-site support fostered a direct connection with teams, enabling timely responses to practical questions and adapting practices to real-world contexts. This proximity facilitated the identification of obstacles as well as opportunities for improvement. Similarly, active listening to user needs made it possible to offer solutions genuinely aligned with actual use cases. The automation of certain tasks greatly eased adoption by reducing manual workload and offering users tangible added value. When tools help save time or reduce errors, they naturally become more attractive. One of the key benefits of digital tools and CDEs is the generation of clean, structured data, which serves as a foundation for automation.

Moreover, it is essential to invest time in explaining—clearly and pedagogically—the risks and limitations of current practices, as well as the benefits of the proposed solution. The backing of influential figures in the project—whether technical leads, department heads, or members of senior management—is crucial to legitimizing the approach and reinforcing its credibility. Finally, process clarity would have been a significant lever in encouraging adoption. Defining simple, readable, and repeatable workflows from the outset would have helped establish a common routine early in the project. It would also have been necessary to implement a clear framework, apply it consistently, and embed it into daily practices.

5.3. Project Limitations and Areas for Improvement

Several obstacles were encountered throughout the deployment, significantly affecting the efficiency and scope of the CDE’s implementation. First, deeply ingrained work habits posed a major challenge. Despite the availability of suitable tools and demonstrated benefits, many individuals favored short-term, seemingly easier methods—often mistakenly perceived as more effective. This cognitive bias, compounded by a siloed organizational structure, limited information circulation, even though cross-functional collaboration is critical in a project of this magnitude.

Another key barrier was the lack of risk awareness regarding poor data management among certain decision-makers. This inertia delayed the implementation of formalized processes to govern information flows. Furthermore, insufficient initial preparation had a direct impact: the mandate began in mid-October, while construction at the metro station had already started. This delay left little room for analysis, structuring, and testing of solutions before teams settled into established routines. An intervention two months earlier would have allowed practices to be framed from the start and ensured better team buy-in. The complexity and scale of the project, along with multiple concurrent contracts, further intensified the challenges. Managing analysis, implementation, training, and support single-handedly across several contracts diluted efforts and reduced deployment impact. The lack of support from influential project figures exacerbated this issue: no additional resources were allocated for fieldwork, no official communication was provided, and the absence of hierarchical relays undermined the legitimacy of certain decisions.

Moreover, the lack of initial documentation—particularly the absence of a data management plan—led to unstandardized practices. This gap not only rendered early project data unusable but also made onboarding subcontractors difficult, due to a lack of clearly defined obligations. The document management team’s exclusive focus on the consortium deliverables to the client created significant deficiencies in communication traceability and structure. Lastly, the late introduction of the Unifier platform in January, mandated by the client, added another layer of complexity. This new interface required rapid adaptation to new processes in an already saturated environment. These limitations highlight the critical need for early planning, clear governance, and strong organizational support to ensure the successful implementation of a CDE in large-scale projects.

5.4. Lessons Learned

Our results corroborate earlier studies highlighting that the deployment of CDEs in large infrastructure projects continues to face substantial interoperability challenges, technological heterogeneity, and fragmented document management practices [6,16,17]. Similar to the findings of Preidel et al. [6], we observed that the absence of a unified environment often leads to data redundancy, version inconsistencies, and difficulties in establishing transparent information flows. Likewise, Guo [16] emphasized the necessity of centralized platforms to improve collaboration, which resonates with the coordination difficulties reported in our case study. These parallels suggest that the barriers to effective CDE implementation remain persistent, despite the increasing adoption of digital platforms across the construction sector.

At the same time, our study provides a distinct contribution by going beyond descriptive accounts of CDE-related challenges. While the BIM Handbook [27] and ISO 19650 guidelines [12] outline the principles of structured information management, they stop short of offering detailed operational frameworks to guide practitioners in practice. Our findings extend this body of knowledge by proposing a structured framework for CDE deployment that integrates three critical dimensions: workflow standardization, interoperability management, and stakeholder coordination. This framework not only addresses the technical configuration of platforms but also emphasizes governance, role definition, and user adoption dynamics as prerequisites for successful deployment.

In this respect, the study contributes to both theory and practice. From an academic standpoint, it enriches ongoing debates on Construction 4.0 by linking digital infrastructures with organizational change processes, thereby clarifying how CDEs function as more than just technical repositories [14,21,22,23,24]. From a practical perspective, it provides actionable guidance that practitioners can apply in real projects to minimize redundancy, improve traceability, and streamline workflows. This dual contribution strengthens the persuasiveness of the conclusions, demonstrating how the proposed framework addresses well-documented barriers while also advancing the operationalization of digital transformation strategies in construction.

6. Conclusions

The project documented in this paper demonstrates both the importance and the complexity of implementing a Common Data Environment (CDE) within a major infrastructure construction site. In a context characterized by a multiplicity of stakeholders, platforms, and contracts, structured information management emerged as a key lever to ensure coordination, traceability, and operational efficiency. Despite significant constraints—particularly related to scheduling, insufficient initial preparation, and the lack of clear document governance—several tangible outcomes were achieved. The organization of certain processes, the partial centralization of exchanges, and the increasing use of collaborative tools by internal teams have laid the foundations for a more structured dynamic. Importantly, this work highlights that the adoption of a digital solution depends not solely on the technology itself but also on stakeholder engagement, active support, and the reinforcement of governance structures.

From a theoretical perspective, this study contributes to the literature on digital project delivery and Construction 4.0 by proposing a structured framework for CDE deployment that explicitly links interoperability, workflow standardization, and stakeholder coordination. Unlike previous studies that discuss these dimensions separately or focus primarily on technological solutions [6,13,16,27], this work integrates them into a cohesive model, providing both conceptual clarity and actionable guidance for practitioners. By formalizing how organizational practices, governance mechanisms, and digital platforms interact to influence project performance, the study offers a lens through which future research can assess the effectiveness of CDE implementation across diverse construction projects.

The upcoming phases of the project offer several concrete opportunities to enhance document structure and consolidate progress made thus far. Key areas of improvement include assisting the document management team in drafting a comprehensive plan, regulating informal use of SharePoint to ensure a single source of truth, and restructuring previously unvalidated processes based on operational examples and positive field feedback. Automation features and inter-platform flows could further streamline data exchanges while maintaining traceability and accountability. Subcontractor involvement should be more rigorously framed, with clear procedures for access, submission, and validation introduced from the outset. Finally, tailored support for construction teams can improve work tracking, structure data, and connect it to quality control, progress monitoring, and testing systems, enhancing operational management while reducing repetitive tasks. Collectively, these measures illustrate how the theoretical framework can guide practical improvements, bridging the gap between conceptual understanding and on-site implementation.