Visual Management Requirements to Support Design Planning and Control within Digital Contexts

Abstract

Difficulties in managing the construction design process are strongly related to its nature, as a large number of interdependent decisions are involved, which need to be made by many different stakeholders, in an environment that has a high degree of uncertainty. Moreover, there is a growing use of digital tools to support design. Traditional communication approaches used in design management only partially comply with the requirements of digital contexts, and new methods and tools are necessary to address these challenges. Visual Management (VM) has the potential to increase process transparency in the design stage, in order to support collaboration and communication and facilitate the transfer of information. However, the literature on the implementation of VM to support design management is still scarce. Moreover, there is limited understanding of the connection between VM and information and communication technologies (ICT). This investigation aims to propose a set of requirements to support VM applications for design planning and control within digital contexts, which can potentially contribute to improving the effectiveness of VM. This set of requirements were initially identified within the literature, considering different fields of knowledge, and then refined in an empirical study that was developed in collaboration with an infrastructure design and consultancy company in the UK. The Design Science Research approach was the methodological approach adopted in this investigation, which involved incremental learning cycles for devising the artefact, carried out in three different projects. The main findings include (i) the definition of a set of VM requirements that are applicable to the context investigated in this research study; (ii) an assessment of the relevance of the requirements for different types of visual practices, hierarchical planning levels, and stakeholders that are involved; (iii) the identification of some current limitations and challenges of implementing digital VM in construction design. From a practical perspective, this set of requirements may guide practitioners and academics in devising and assessing digital VM practices.

1. Introduction

The lack of effective design planning and control systems has been pointed out in the literature as a central reason for time and cost overruns [1,2]. Design management, in general, has also been criticised for involving poor communication and coordination [3] and lack of trust [4], despite the importance of design for the performance of construction projects [5,6]. Managing stakeholders’ interdependencies may be very challenging due to the large number of parts that need to be integrated and coordinated [7]. Moreover, new managerial approaches are needed to address the increasing complexity in construction projects [8,9], and the growing adoption of digital technologies [10,11].

Visual Management (VM) is a sensory strategy for information management, in which an information field is created, extending access to timely information to different people [12]. It is strongly related to the Lean Production core principle of improving process transparency, which can be defined as the ability of a production process, or its parts, to communicate with people and make their processes observable [13]. Visualisation techniques can also be used to avoid information overflow, in supporting communication among different stakeholders, as well as to assist in managing ambiguity and uncertainty [14], which are typical problems that are faced in construction design.

In fact, VM applications can potentially contribute to the achievement of the United Nations’ sustainable development goals, such as “build resilient infrastructure, promote inclusive and sustainable industrialization and foster innovation” (Goal 9) and “ensure sustainable consumption and production patterns” (Goal 12) [15], by improving information transparency for different stakeholders, and reducing waste [16] caused by design uncertainty, novelty, and complexity.

The literature on the implementation of VM to support design management is scarce [17,18]. By contrast, there are many examples of VM devices in construction sites, although these are often limited to isolated applications [19]. Moreover, visual devices are usually devised in an intuitive way, based on common sense [20]. Brandalise et al. [21] state that the benefits of VM strongly depends on how well VM practices are incorporated in process management.

In addition to this, few studies have investigated the adoption of VM devices combined with digital technologies, which can potentially improve visual representations in project management [22]. According to Tezel and Aziz [23], the combination of VM and information and communication technologies (ICT) contributes to an increase in the degree of automation in project control, increasing efficiency in the data collection and processing, and reducing the feedback time. Moreover, digital VM represents an opportunity to improve design management, by providing visibility to key information that support decision making [20] and supporting collaborative processes [24]. Nevertheless, the implementation of digital VM devices may also have negative impacts, such as the limited transparency of information flows, inadequate information exchange processes, and limited communication [10].

Therefore, this investigation addresses two main gaps in knowledge. Firstly, there is a need to understand how VM can support design management, exploring potential solutions across different hierarchical planning and control levels. Secondly, there is a lack of understanding of how VM can be supported by ICT in this context. Thus, the study addresses the following research question: how can visual management support design management in a digital environment?

The aim of this research is to propose a set of requirements to support the development of VM applications for design planning and control within digital contexts. From a theoretical perspective, this set of requirements extends the body of knowledge related to the application of VM in construction design within digital environments. The findings have a prescriptive character and can guide practitioners and academics in the development, implementation, and assessment of VM systems for design planning and control in infrastructure projects.

It is worth mentioning that the digitalisation of design planning and control has become even more relevant due to the COVID-19 pandemic. Many companies have been encouraged their workers to work from home by accelerating the adoption of several digital devices and platforms to support virtual communication and collaboration. Such changes are likely to be maintained to some degree even after the end of the pandemic.

2. Design Planning and Control

Mäki and Kerosuo [25] suggested that design management still presents grey areas in respect of quality requirements and achieving goals. Cross [26] pointed out that a major reason for neglecting the design process is the focus of design on the final product, i.e., drawings and product specifications. In addition, the nature of design activities is not well understood when one is devising planning and control systems, especially regarding the consideration of project uncertainty and variability [6]. Hamzeh et al. [27] highlight the importance of standardising design planning and control, making it possible to measure and improve this process.

Principles, methods, and tools have been introduced in this context to support and facilitate the design management, including the Last Planner System^® (LPS), and its related technologies [28]. The LPS is a production control method based on a collaborative and hierarchical process, that is used in order to deal with uncertainty [29]. It has been adapted and effectively used in design management [6,25,27], and has contributed to the improvement of the reliability of design plans, making design meetings more effective in terms of setting future tasks [25].

Design is an activity in which a team should work collaboratively towards a final solution, and it emerges as a result of the interaction between design team members, the artefact, other professionals, and the environment [30]. Wood and Gray [31] describe collaboration as an interactive process which should engage autonomous stakeholders that are addressing the same problem. In this context, there is much interdependence between stakeholders, which places pressure on the capability to communicate, transfer, and share knowledge and information between them [32]. Therefore, communication and coordination among the stakeholders are key aspects for improving design [28,33,34,35].

Different communication and collaboration approaches can support project managers in order for them to cope with unexpected events when managing a project. Collaboration is classified by Ugwu et al. [36] and Anumba et al. [37] by four different types, considering that collaboration depends on the nature of separation (i.e., same place or different place) and the timing of communication among participants (i.e., same time or different times) in a project: (i) face-to-face collaboration, which is described as a face-to-face meeting attended by stakeholders in a common space; (ii) asynchronous collaboration, in which a medium for communication such as bulletin or notice is used to enable collaboration; (iii) synchronous distributed collaboration, involving real-time communication with the support of the ICT, e.g., the virtual co-location of team members; (iv) asynchronous distributed collaboration, in which communication is carried out by using post, mail transmissions, among others. Design teams must develop different skills to deal with different types of collaboration.

However, despite the large number of stakeholders involved in a project, the development of the digital systems for construction design does not provide enough attention to coordination and collaboration requirements [3,38]. Thus, those systems may fail without the cognitive work, that is people engaging with each other [39].

3. Visual Management

Visual Management (VM) can be defined as a set of practices that support visual communication through the adoption of different visual devices [40]. A visual system is defined by Galsworth [41] as a set of visual practices that are designed to facilitate the sharing of information between different stakeholders, providing information, at a glance, to support specific tasks or processes. A VM practice refers to both visual and non-visual work, considering the invisible effort related to managerial tasks, as highlighted by Nicolini [42], whereas a VM device refers to the perceptible visible portion of the practice [43].

VM supports information management in a wide range of functions for an organisation, such as filtering, monitoring, simplifying, and effectively presenting relevant information, as well as considering some information aspects, such as relevance, accuracy, immediacy, and location that is as close as possible to the relevant places or integration with the workplace or process [44]. According to Saurin et al. [45], simplicity plays a key role in the functioning of a VM device, with it being associated with easy understanding [43]. Viana et al. [46] and Murata [47] argue that VM makes information explicit and available, supporting front-line workers to understand and quickly solve potential abnormal and hidden conditions in the system. The information delivery time must as short as possible when an action is required [48]. Information should be visible at the right time, to the right user, and in the right place [49].

The use of standardised information helps to reduce the time spent searching for information, to improve consistency in information delivery, and to limit the amount of information to what is needed [50]. VM has the role of providing information clearly and can be used to assist in the coordination of processes between interdependent parties, especially in complex environments [46], to stimulate creativity and collaboration among users [24,43], and to encourage the development of a sense of shared ownership [40].

Brandalise et al. [21] proposed a typology of concepts related to VM that extends the contribution of taxonomies that were previously proposed in the literature, by emphasizing the role of collaboration and communication, as well as the need to integrate VM practices into managerial routines and other practices. Regarding the role of communication, Brandalise et al. [21] proposed four categories: (i) one to one, in which there is a clear channel of communication between a sender and a receiver; (ii) one to many, in which information is usually shared as part of coordination activities involving different stakeholders; (iii) many to one, involving many senders but with only one receiver; (iv) many to many, enabling communication and decision making among many users, which is typical of collaborative processes.

According to Tezel and Aziz [23], the use of digital systems creates opportunities for devising dynamic VM devices, in which information is quickly updated at a relatively low cost. This allows the perspectives from different stakeholders to be considered, in response to the dynamics of their interactions [51]. This is particularly important when using VM to disseminate performance metrics, so that changes in status or results of continuous improvement can be widely disseminated in real time [52].

By contrast, digital VM devices can potentially have negative impacts and hidden problems [47,53]: (i) excess of information can represent waste, due to misunderstandings and errors of judgment and interpretation; (ii) omission of information may be caused by problems in maintaining updated information and in selecting information relevant. Moreover, organisations have to deal with process changes, high costs of system implementation and maintenance, and the need for data protection and security [11,23,47]. The technical issues identified are mostly related to the lack of interoperability and standards for the variety of technologies, requirements for computing equipment and lack of trained workforce to deal with those requirements, and increasing demand for improved communication networks [11,23]. Murata [47] suggests that VM will not be fully digitalised in the future, whereas informal and verbal communication are still considered important in early design, supporting the creation of a mindset about design [54].

Regarding design planning and control, VM can be used to improve communication among team members [19], support collaboration in planning meetings [40], and highlight opportunities for cost and time savings as the access to relevant information is quick, easy, and accurate [23].

4. VM Requirements Identified in the Literature Review

Based on the literature review, an initial set of five requirements for visual management practices were identified.

Table 1. Initial set of VM requirements for design planning and control within digital contexts.

Requirements	Brief Description
Simplicity	Simplicity is related to the use and functioning of a VM device [45]. It is associated with an easy and rapid understanding of information [43]. It is an essential requirement for VM [48,55], allowing effective interpretation and understanding of the information provided [56].
Standardisation	Information standardisation can reduce time spent searching and processing data [50], providing, consistently, the information that is required. According to Murata [48], visual devices must have a structure in order to clearly monitor the conditions of the system, so that special situations can be identified as they arise [55].
Availability	VM must provide information that is as close as possible to the workplace or process [44]. Information should be visible at the right place to all stakeholders that are involved in the process [49]. Relevant and accurate information must be made available for specific purposes [44,57]. The information delivery duration must be the speed at which the information is required by an action [46,48]. Availability is particularly important for mandatory information [56].
Flexibility	Flexibility is concerned with making changes in the devices as they are needed [52]. VM devices must be modified in response to the dynamics of the interactions [51]; digital scenarios can make VM even more dynamic [23]. VM is related to mobility, dynamic information display within complex information flows, and shorter information feedback [23]. Digital solutions can support more flexible and less time-consuming measurement techniques [58].

presents the definitions that were extracted from the literature for those requirements, which are based on 17 publications on VM. Those requirements can be considered as the point of departure for the empirical study carried out in this investigation, considering that the body of knowledge on the implementation of VM in design management within digital contexts is highly fragmented. In fact, these five requirements emerged from different types of studies and not all of them were carried out in the construction industry. VM concepts used in other fields were considered, such as manufacturing, safety management, product-service systems, and knowledge management. These requirements need to be refined, considering the specific demands of construction design, and the current set of technologies available in that context. Moreover, the possible interactions between the different requirements need to be considered in the design of VM systems.

5. Research Method

5.1. Research Approach

Design Science Research (DSR) was the research approach adopted in this investigation. The main results of DSR are prescriptions or artefacts that embody those prescriptions [59]. This research approach is characterised as an iterative process with incremental learning cycles [60], in which a class of problems is understood, and a solution concept is devised, and it is limited to a certain field of application [61]. The development of empirical studies in a certain context, considering organisational and contextual factors [61], allows for an in-depth understanding of the problem from a holistic perspective. The main artefact proposed in this investigation is a set of requirements to support the development of VM applications for design planning and control within digital contexts. These requirements can be used by construction management professionals in charge of assessing or devising VM systems for design planning and control in infrastructure projects.

The set of requirements was initially identified from the literature (see Section 4), and then were assessed and refined on an empirical study that was carried out in an infrastructure design company from the UK. The main reason for choosing this company was the fact that it was facing a transformation of its processes through the development of a Lean-based design management system, which had to be flexible to address the variety and complexity of projects that were involved. Furthermore, the COVID-19 pandemic also required the company to adapt working routines to digital environments, by using digital devices and collaboration platforms, instead of using the traditional approach of face-to-face meetings and paper-based visual devices. This study was developed between August 2019 and May 2020. As in any DSR, understanding the practical problem faced by this company played an important role in the definition of the scope of this investigation.

Data from three projects were used in this empirical study. Those projects were chosen according to the following criteria: (i) the design teams had the availability to participate in this research study; (ii) the set of projects represented a variety of project scope and size that existed in the company; (iii) they all offered opportunities to investigate good practices regarding VM, and digital technologies to support design planning and control.

Project I involved a highway that was part of a large new railway construction project. During the data collection process, the project moved from the preliminary design to the detail design stage. Design was undertaken as a joint venture between three design companies. Project II involved a national and regional strategic railway link in the North of England. It was in the conceptual phase when data were collected, which was named as “options selection and development phase”, when recommendations for preferred route announcements were made. Project III involved a highway infrastructure project connecting the North to the South of London through a tunnel under a river. It was at the preliminary design phase when data were collected and analysed, at which time, the options selected at the previous phase were revisited and refined.

The projects undertaken by the company had a high level of complexity, due to the multitude of internal and external stakeholders, and a large number of interdependencies between them. There was also a high degree of uncertainty, as the process had to be adapted according to the client’s requirements and to the process specifications related to the organisations involved. Moreover, the planning and control systems and the VM practices were different due to the different stakeholders involved in the joint venture and also to the different scope of each project. All projects were analysed from the perspective of an infrastructure design company, even when there was a joint venture with partner organisations.

5.2. Research Design

This research study was divided into three main phases (Figure 1), which correspond to the three main tasks in design science research, as suggested by Holmström et al. [62].

(i)

Phase 1—consisted of an overall assessment of the problems faced by the company within design planning and control. Moreover, a literature review was carried out to identify a knowledge gap. An initial set of VM requirements were identified from the literature, considering different contexts, e.g., design, construction, and manufacturing. At the end of this stage, the initial scope of the investigation was defined;

(ii)

Phase 2—consisted of the development of the empirical study, in which the existing design planning and control system was assessed, as well as visual management practices from each project investigated, based on the set of requirements that were identified in the literature. Improvement opportunities for the company were also identified. The scope of the investigation was refined in Phase 2. Project I data supported the analysis of the context through a broad perspective of the design process. Project II was focused on the design management, i.e., design planning, control, and coordination. Project III also focused on design planning and control, but provided an opportunity for an in-depth understanding on the topic, based on discussions related to the implementation of new digital VM practices to support planning and control;

(iii)

Phase 3—consisted of the assessment and refinement of the set of requirements, and a reflection on the practical and theoretical implications of this investigation.

Therefore, the final set of requirements emerged along this investigation, and it was not possible to do an evaluation of its utility and applicability by implementing them in an additional empirical study. This is a limitation of this research study.

5.3. Detail Description of Research Activities

The empirical study adopted a holistic approach for data collection and analysis, for which, understanding the context of the company and of each project was necessary. Multiple sources of evidence were used, including open and semi-structured interviews, participant and direct observation, and an analysis of documents. This allowed data triangulation to be undertaken with the aim of increasing the validity of the research findings [63]. All semi-structured interviews were recorded and based on protocols for data collection. The most relevant parts were also transcribed. Key insights and interviewers’ notes were stored in a database after each interview. Furthermore, the observation of the meetings were classified as either direct or participant, as suggested by Yin [64]. Direct observation was undertaken in virtual meetings when the researcher did not have any kind of interference. Data analysis was performed through a qualitative approach in which the presence or absence of digital VM requirements in different planning meetings was identified.

Table 2. Phase 1—Sources of evidence.

ID	Source of Evidence	Number	Duration	Participants	Description
1	Workshops	2	90–180 min	Professor with experience in Lean Construction, Professors, and researchers with experience in VM and in digital technologies for design, Master and Ph.D. students	General discussion of VM requirements with academic experts (Evaluation activity)
		2	120–240 min	Associate Technical Directors and Senior Technical Director	Discussion about the design management process and general visual management practices with the company
2	Open interviews	3	15–60 min	Associate Technical Directors, Highways Sector BIM Manager, and Business Director	Presentation of Research Plan, general understanding about the company context and evaluation of requirements (Evaluation activity)
		5	25–60 min	Project Manager, Senior Consultant, Sector BIM Manager, team member, and Associate Technical Director	Identification and evaluation of design management processes, Lean strategies, VM practices, and BIM processes
3	Semi-structured interviews	2	25–60 min	Associate Technical Director and Senior consultant (GIS specialist)	Identification of Lean practices, and discussion about Type B VM practices
4	Participant observation	1	120 min	Company A team, External Company team, and Client Lean team	Benchmarking of good practices with another company from the civil engineering sector

Note: Evaluation activity—Activities involved in the assessment and refinement of the solution.

presents the main sources of evidence used in Phase 1 for obtaining an overall assessment of the problems faced by the company. This was done through interviews, observation, and workshops.

Data collection for Project I started simultaneously with Phase 1, being carried out in two different periods. In August and September 2019, most of the data was related to the challenges related to design management faced by the company. Additional data collection was carried out between February and March 2020 and the focus of analysis was design coordination activities.

Table 3. Phase 2—Project I—Sources of evidence.

ID	Source of Evidence	Number	Duration	Participants	Description
1	Participant observation	1	390 min	Project Manager, Subcontracted Company leaders (drainage, embankment, landscape), Contractors, Client, Advisor, BIM Manager, Team Leaders, and Members	Planning and control meeting: Collaborative planning session (Face-to-face meeting)
		2	180 min	Team Leaders, Project Manager, and Directors	Design coordination meeting (Face-to-face and virtual meetings)
2	Open Interview	1	60 min	Project Information Manager	Understanding the BIM process
3	Document analysis				Design planning, control, and coordination VM practices analysis (Collaborative Board 1, Whiteboard 1, Navisworks model visualisation), planning and control documentation (Long-term plan, project summary report)

present the sources of evidence used in that project. Participant observation was carried out in two types of design management meetings, named “collaborative planning sessions” and “design coordination meetings”.

Project II was the one in which it was possible to collect the largest amount of data, allowing the mapping of planning, control, and coordination activities and VM practices. It was developed in parallel with Project I’s activities, between August 2019 and March 2020.

Table 4. Phase 2—Project II—Sources of evidence.

ID	Source of Evidence	Number	Duration	Participants	Description
1	Participant observation	1	360 min	Project team	Planning and control meeting: Collaborative planning meeting (Face-to-face meeting)
		2	30–45 min	Project Manager, Practitioner of Risk Manager, Technical Director/Senior Project Manager, and Team Lead	Planning and control meeting: Monthly risk review meeting (Project management and traffic) (Virtual meeting)
		1	45 min	Project Manager, Technical Director, Team Leaders	Planning and control meeting: Stand-up weekly progress meeting (Face-to-face and virtual meeting)
		1	60 min	Project Manager, Client Representative, Technical Directors, Project Director, Risk Manager, and Team Leaders	Planning and control meeting: Monthly progress meeting (Face-to-face and virtual meeting)
2	Direct observation	1	30 min	Digital Devices Developer, Performance Manager, and Associate Director	Continuous improvement meeting: Development of devices and continuous improvement meeting (Virtual meeting)
		8	30–60 min	Project Manager, Technical Director, and Team Leaders	Planning and control meeting: Weekly progress meeting (Virtual meetings)
3	Open Interview	3	45–60 min	Senior Consultant, Technical Director/Principal design manager, Associates Technical Directors, and Project Manager	Understanding of the project, design management process, design coordination devices, and partial evaluation of the requirements (Evaluation activity)
		1	90 min	Associates Technical Directors	Partial evaluation of results (Evaluation activity)
4	Semi-structured interview	4	30–45 min	Deputy Customer Manager, Technical Consultant, Technical Director, and Risk Manager	Understanding of design management activities and its interface with stakeholders’ team, discussion and evaluation about the design process, design management activities and VM practices for design coordination, and planning and control
5	Workshop	1	60 min	Associate Technical Director and Professor with experience in Lean Construction	Presentation of a Technical Report and partial evaluation of results with the company (Evaluation activity)
6	Document analysis				Design planning, control, and coordination VM devices analysis (Collaborative Board 2, Whiteboard 2, Performance Dashboard 1, Activity Tracker 1, GIS model visualisation, Risk dashboard) planning and control documents (Long-term plan, project summary report)

Note: Evaluation activity—Activities involved in the assessment and refinement of the solution.

presents the main sources of evidence that were used in Project II. Data collection was initially focused on design management. After the first round of data collection and analysis, the research problem was refined, emphasising design planning and control and design coordination.

Eleven different design management meetings were identified in Project II, through interviews. These were divided into three categories: planning and control meetings, coordination meetings, and continuous improvement meetings. Four types of meetings were analysed in more detail through direct or participant observation: collaborative planning session, monthly progress meetings, weekly progress meetings, and design coordination meeting.

A workshop was undertaken, for discussing problems and improvement opportunities in Project II, with the representatives of the company. Moreover, open interviews with some stakeholders were undertaken with directors and senior engineers, as described in Table 4.

Regarding Project III, data collection was carried out between February and April 2020, therefore it was a shorter study than the two previous ones were. Five types of planning and control meetings were identified. Direct observation was carried out in two types of meetings: weekly progress meetings and management performance review, as shown in

Table 5. Phase 2—Project III—Sources of evidence.

ID	Source of Evidence	Number	Duration	Participants	Description
1	Direct observation	1	45 min	Project Manager, Lean Manager, Team Leaders, and Members	Planning and control meeting: Weekly progress meeting (Virtual meeting)
		1	45 min	Project Managers, Risk Manager, Lean Manager (Facilitator), Team Leaders, and Members	Planning and control meeting: Management performance review meeting (Virtual meeting)
2	Open interviews	5	15–90 min	Business Director, Associate Technical Directors, and Lean Managers	General understanding of the project, VM practices and design management processes, Discussion and evaluation of Visual Management, considering manual and digital devices
3	Document analysis				Design planning, control and coordination VM devices analysis (Performance Dashboard 2, Activity Tracker 2), planning and control documentation (project summary and existing system), photographic records of manual VM devices (Planning and Control VM room)

. Similar to Project I, there was no external evaluation on the results at the end of the study was formally carried out with stakeholders.

5.4. Analysis, Reflection, and Evaluation of the Solution

The set of requirements was preliminary assessed according to the criteria of utility and applicability. The key sources of evidence related to the final reflection and refinement of the artefact are defined as internal, i.e., researcher’s perception, and external evaluations, which are described as: (i) workshops, which had presentations and discussions with key stakeholders in the project, as well as academics; (ii) open interview with representatives of the company (see

Table 6. Phase 3—Source of evidence.

ID	Source of Evidence	Number	Duration	Participants	Description
1	Workshops	2	30–60 min	International professors and Ph.D. students from the United Kingdom, United States of America, Brazil, New Zealand, and Israel	Presentation and discussion about the requirements and its connections with experts in the topics
		5	60–120 min	Director, Associate Technical Directors, and Senior Engineer	Report the diagnosis and improvement opportunities proposed, evaluation of VM, and design management practices in the company, development of new digital VM devices and discussion about the requirements
2	Open interview	1	60 min	Associate Technical Director	Report the diagnosis and improvement opportunities proposed, general discussion, and evaluation of the requirements

). These sources of evidence were added to those that were already presented in the previous sections and highlighted as ‘evaluation activity’, considering the insights obtained during the entire research process also contributed to the evaluation.

6. Results

Existing Design Planning and Control System

Figure 2 presents an overview of the existing design planning and control system, which was divided into three hierarchical levels: strategic, tactical, and operational. This figure also represents the main flows of information between the different hierarchical levels, which aim to keep consistency between plans, such as between the ones produced in the collaborative planning session and in the weekly progress meeting.

Table 7. Detail information about each hierarchical planning level.

	Strategic Level	Tactical Level	Operational Level (Within and between Disciplines)
Stakeholders involved	Project Manager; Technical and Project Directors; Client representative	Team Leaders; Project Manager; Client representative	Team Members; Team Leaders; Project Manager; BIM manager, GIS Manager
Reach of decisions	Between relevant stakeholders	Between relevant stakeholders of each discipline	Each discipline or between disciplines
Level of planning	Long-term	Medium-term	Short-term
Meetings	1. Stakeholders meeting with client (weekly) (Project II) 2. Stakeholders meeting with general stakeholders, i.e., end users (quarterly) (Project II)	3. Collaborative planning session (Project I and II) * 4. Monthly progress meeting or Management performance review (Project II and III) * 5. Risk review meeting (Project II) 6. Multidisciplinary Design Review Meetings (Project II)	7. Weekly progress meetings (with diverse design disciplines) (Project II and III) * 8. Design coordination meetings (with diverse design disciplines) (Project I and II) * 9. Daily meetings (one design discipline) (Project II)

Note: (*) Meetings analysed. The company also had lessons learnt meetings (10) and workshops (11), e.g., at the end of each design stage or end of the project. Those activities are not classified according to the organisational levels, as they are concerned with all processes.

presents some additional information about each planning level, including the main stakeholders involved, and the types of design meetings.

The meetings that were analysed in this investigation were: the collaborative planning session, the monthly progress meeting or management performance review, and the weekly progress meetings (highlighted in red in Figure 2). The meetings were chosen due to fact they adopted VM practices to support decision-making and collaboration. Some VM practices that were identified and analysed are illustrated in the figure below: Collaborative Board (A1), Whiteboard (A2), Performance Dashboard (A3), and Activity Tracker (A4).

Three key types of visual devices were identified in the planning and control system: (i) for design planning and control (type A); (ii) for design coordination (type B); (iii) for continuous improvement (type C). However, only type A devices were analysed in this investigation, as the focus was on the support given to design planning and control. Status dashboards (e.g., Activity Tracker) and Performance Dashboards were identified as the devices associated with Type A, whereas product models were associated with type B. Monitoring status is a very important function in planning and control systems, based on the Lean philosophy, as this allow the execution of tasks to be pulled, as suggested by Hopp and Spearman [65].

This research work also classified the VM practices according to different criteria: (i) digitalisation level; (ii) communication and collaboration approaches, adapted from Ugwu et al. [36] and Anumba et al. [37]; (iii) role of communication [21], as shown in

Table 8. Classification criteria for the VM practices.

Classification Criteria	Description
Type of VM devices	Type A (design planning and control), Type B (design coordination), Type C (continuous improvement).
Digitalisation Level	Digital (D) or Manual (M) VM devices.
Managerial Levels	Strategic (S), Tactical (T), Operational (O).
Communication and collaboration approaches [36,37]	Face-to-face Collaboration (FFC), Asynchronous Collaboration (AC), Synchronous Distributed Collaboration (SDC), Asynchronous Distributed Collaboration (ADC), Synchronous, Distributed, and Face-to-face Collaboration (SDFFC).
Categories of communication and integration [21]	One to one, one to many, many to one, and many to many interactions.

. The empirical study has contributed to the identification of a new category, merging two of the communication and collaboration types described in the literature, i.e., Synchronous Distributed Collaboration (SDC) and Face-to-face Collaboration (FFC). The new category can be described as synchronous, distributed, and face-to-face collaboration (SDFFC). Meetings were carried out both virtually and when face-to-face because some team members and stakeholders were based in the same office and some were in different offices, cities, or countries.

Twenty VM practices were identified in the empirical study, which are briefly described in

Table 9. VM practices identified.

ID	VM Practices Name	Description	Project	VM Type	Digitalisation Level
1 *	Collaborative Board 1	Collaborative planning board with milestones and deliverables. The board was updated in real time during the face-to-face meetings, which were held every three or four months. This information was updated into the master schedule after the meeting.	I	A	M
2 *	Whiteboard 1	Assumptions, key actions, risks, and opportunities were identified, understood, and logged during the meeting for continuous review and management. The meetings were held every three or four months. The information was shared with the teams and used to support the weekly discussions.	I	A	M
3	Model Visualisation	Model visualisation was used for clash detection, quality control, and control of changes. This was used to review the status of the federated model and design progress, and also to identify issues during virtual and face-to-face weekly or fortnightly meetings.	I	B	D
4 *	Collaborative Board 2	Collaborative planning board with milestones and deliverables, in which the master schedule (a very detailed plan) was displayed to support meetings. Sticky notes were also used to highlight key milestones and deliverables.	II	A	M
5 *	Whiteboard 2	Whiteboard with objectives, assumptions, key actions, deliverables (surveys), and other topics (e.g., overview of the project), was used in meetings and shared with the teams afterwards.	II	A	M
6 *	Performance Dashboard 1	Dashboard with key performance metrics, such as reasons for the non-completion of work packages, Percent Plan Complete (PPC), and the 3C’s (3C’s is a problem-solving methodology, which is used to document concern, cause, and countermeasure, encouraging employees to discuss problems and actions). It was used to support decision-making within the monthly progress meeting, and it was based on the data collected through the Activity Tracker 1.	II	A	D
7 *	Activity Tracker 1	Activity Tracker 1 was used to monitor activities by design discipline, and update tasks by displaying the status, supporting weekly progress meetings. It had two main interfaces: activity details and summary of status.	II	A	D
8	GIS Model Visualisation	GIS model visualisation for health and safety coordination. It helped in gathering and analysing data, mainly related to the pre-construction information, focusing on health and safety aspects. It started to be implemented recently at the company as a coordination device.	II	B	D
9	Risk Dashboard	Risk dashboard, also named balance scorecards. It aimed to support the monthly risk discussions within the project. It was under development during this investigation.	II	A	D
10 *	Performance Dashboard 2	Dashboards had three different interfaces, containing (i) the agenda and the meetings’ structure; (ii) PPC and reasons for the non-completion of activities; (iii) analysis of the planning failures for each discipline. It was based on the data collected through the Activity Tracker 2.	III	A	D
11 *	Activity Tracker 2	Activity Tracker 2 contained the weekly lookahead plan, including activities, disciplines, activity owner, finishing date, status, weekly work plan, and PPC. It was adopted in the weekly meetings and updated in real-time. It was also available both before and after meetings.	III	A	D
12	Project Milestones board	Milestones Heatmap containing deliverables by discipline and month, as well as the delivery date. It was displayed in the Planning and Control VM room.	III	A	M
13	Lookahead board	It showed a 4-week lookahead plan, being displayed in the Planning and Control VM room.	III	A	M
14	Activity Tracker 3	It contained activities completed, showing the activities per team/discipline, being available in the Planning and Control VM room.	III	A	M
15	Reasons for Non-Completion Board	It showed the reasons for non-completion and key disciplines involved. It was displayed in the Planning and Control VM room.	III	A	M
16	Performance board 3	Overall performance, PPC, key reasons for non-completion. It was displayed in the Planning and Control VM room.	III	A	M
17	Action board	The 3C’s (Concern, Cause, Countermeasure) and Risk management boards, in which the concerns and risks were captured and analysed. It was displayed in the Planning and Control VM room.	III	A	M
18	Overview board	Project overview board, including the master plan, key design processes, and deliverables. It was displayed in the Planning and Control VM room.	III	C	M
19	People’s board	People’s board contained information related to the team, the successes and news. It was displayed in the Planning and Control VM room.	III	C	M
20	Improvement Board	Improvement ideas and lessons learnt were captured and analysed in this board. It was displayed in the Planning and Control VM room.	III	C	M

Note: (*) VM practices that were analysed in-depth.

. Eight practices were chosen for an in-depth analysis: ID 1, 2, 4, 5, 6, 7, 10, and 11 (Table 9). Those practices (i.e., Collaborative Boards, Whiteboards, Performance Dashboards, and Activity Trackers) were chosen due to the fact they were well integrated into the design management, as well as for being classified as type A. Similar VM practices, with similar purposes, were observed in more than one project, e.g., Collaborative Board 1 and 2. However, the VM practices were adopted in different ways, i.e., there were differences both in visual and non-visual aspects between the projects.

The collaborative planning sessions (Project I and II), also named phase scheduling in the LPS, were undertaken along the whole design stage to develop a high-level schedule that was revised every three or four months. It was focused on the agreement of deliverable dates that were already defined in the long-term plan (also named master schedule); the purpose was to ensure that all parties understood the timeframes, their responsibilities, and consequently, the impact of not delivering their tasks.

The teams adopted two different collaborative visual boards to support the discussions and agreements within the collaborative planning session, Collaborative Board (ID 1 and 4 in Table 9) and Whiteboard (ID 2 and 5 in Table 9). Those practices supported the development of a high-level design plan to match client priorities, as well as the identification and management of key constraints.

In Project I, Collaborative Board 1 (ID 1 in Table 9 and Figure 3) was the main VM practice supporting meetings, although Whiteboard 1 (ID 2 in Table 9 and Figure 4) also supported discussions related to assumptions, key actions, risks, and opportunities emerging during meetings. Collaborative Board 1 was developed prior to the meeting, based on the master schedule milestones. To begin with, each discipline used the board for initial planning, developing a high-level programme to fit client and procurement requirements. After that, all discipline representatives used the board simultaneously for collaborative planning, collectively reviewing, challenging, and improving the plan. After the meeting, the information was updated into the master schedule, also feeding and guiding the other planning levels. A practitioner, who was part of the continuous improvement team, chaired the meeting as a facilitator with a mediating role, supporting the decision-making and keeping the meeting focused. The main challenge was related to the difficulty in maintaining that the information was up to date by properly recording and sharing the information with geographically distributed teams. There was also a lack of space to display the VM devices in the office, so the devices were used at specific points in time and for specific activities.

The Project II collaborative planning session adopted the master schedule, which was a very detailed plan, as a visual device and a reference to make decisions (ID 4 and 5 in Table 9 and Figure 5). Collaborative Board 2 as well as Whiteboard 2 had the same functions as is described in Project I. The Whiteboard was used to display objectives, assumptions, key actions, deliverables (surveys), and other topics (e.g., overview of the project). Collaborative Board 2 was not effectively used, as very detailed information from the master schedule (a CPM network) was displayed. Thus, some team members did not fully engage in the meeting, as the structure of the session and the VM device were not clear.

The aim of the monthly progress meeting (Project II), also named the management performance review meeting (Project III), was to discuss project progress, reviewing it against the master schedule, as well as to identify and remove constraints. The meeting was carried out both face-to-face and virtually, involving the project manager, team leaders, and the client. Any relevant schedule or technical issue that was identified was escalated to other meetings.

A digital dashboard, i.e., Performance Dashboard 1, containing performance metrics was used to support decision-making within the monthly progress meeting of Project II (ID 6 in Table 9 and Figure 6). The input data that were used for producing metrics came from information available in the Activity Tracker device (ID 7 in Table 9), which was easily updated by discipline design team leaders during the weekly progress meeting. Performance Dashboard 1 was developed to fulfil the user’s needs and company expectations by an internal company member, who also developed Activity Tracker 1. Figure 6 presents the metrics displayed on the board: reasons for the non-completion of work packages, Percent Plan Complete (PPC), and the 3C’s. Performance Dashboard 1 also identified the status of the actions which could be filtered by team member, category, or discipline, as well as a control chart, which on a weekly basis, monitored PPC and the reasons for the non-completion of work packages. The information was available to project managers, directors, and discipline leaders. However, the dashboard had limited accessibility due to it having technical issues (to be discussed in Section 7).

Performance Dashboard 2 (ID 10 in Table 9 and Figure 7) which was adopted in Project III was also based on the data collected through Activity Tracker 2 (ID 11 in Table 9), and it was distributed to the team prior and after the meetings. It had three different interfaces, which were adopted to support different discussions. The first interface had the agenda and the weekly meeting structure, to make explicit the aim of each meeting. The second interface was a dashboard containing PPC, as well as the identification of the reasons for the non-completion of activities. The last interface was developed for each discipline, so the number of boards could vary according to the number of disciplines that were involved. It also included a detailed analysis of the planning failures, such as the comparison between planned and real completion, the identification of whether the activity was in the critical path, and a risk assessment.

The weekly progress meeting (Project II and III), named as weekly planning in the LPS, supported the control of weekly and daily actions through an update of activities, the control of deadlines, and the identification of reasons for overdue tasks. It was a very short meeting, with an average duration of 30 min.

Activity Tracker 1 (ID 7 in Table 9 and Figure 8) was the device adopted to support the weekly progress meeting in Project II. The aim of Activity Tracker 1 was to monitor activities by design discipline, update tasks, and display status. The device presented two interfaces, one which was focused on the activity details and another with a summary of the status. The device development process occurred through iterative learning cycles, as a way to improve the device interface during its use. There was an internal employee in charge of collecting feedback during the improvement process. The discussion in the meeting was focused on task completion, as well as the identification of reasons for overdue tasks. This practice was used at the operational level, for supporting meetings between disciplines, but it could be also used to support operational activities inside each discipline. All team members had permanent access to this digital device through diverse displays. During the meetings, the device was displayed on the project manager’s screen, enabling information to be shared among team members. The discussion was facilitated by the project manager.

Activity Tracker 2 (ID 11 in Table 9 and Figure 9) was used to support the design planning and control in Project III, being easily accessible to team members all of the time. This device had only one interface. However, the information was very similar to the information showed by Activity Tracker 1, including activities, disciplines, activity owner, finish date, and status. It also showed the weekly work plan and the PPC. It was used to track non-completed activities and their reasons for non-completion, being able to store and process the information very quickly, as pointed out in direct observations and open interviews. Activity Tracker 2 also had a weekly lookahead and supported real-time information updates.

7. Refinement and Assessment of Requirements

7.1. Refinement of the Requirements

Based on the analysis of the data from the three projects, the set of VM requirements was refined, considering the context of the design planning and control of infrastructure projects, and the support of digital technologies.

Table 10. Refinement of the VM requirements.

VM Requirements (Table 1)	VM Requirements for Design Planning and Control	Source of the Requirement	New Definition
Simplicity	Simplicity (R1)	Literature review	It is concerned with how easy it is to use a VM practice, based on a clear understanding of its objective or function
Standardisation	Standardisation (R2)	Literature review	It is related to whether there is repetition in the use of devices, i.e., regularity of information units, which can support accurate information delivery
Availability	Availability (R3)	Literature review	It is related to making updated information available at the right time and in the right amount, making easy to prioritise information
	Accessibility (R4)	Empirical study	It considers how easy it is to access the information, i.e., if the information is located in the right place
Flexibility	Flexibility (R5)	Literature review	It is related to: (i) how easy it is to make changes, i.e., possibility of adapting devices and practices according to the users’ needs over time; (ii) how easy is to update the information, i.e., changes can be quickly displayed in the device
	Traceability (R6)	Empirical study	It is associated with easy storage of information and easy tracking of the origin of the information

presents the new set of requirements, and the definitions that were considered for each of them. Two new requirements were introduced: (i) traceability, which is strongly related to the capability of digital VM devices for storing and tracking relevant information; (ii) accessibility, which is an extension of availability, i.e., information must be not only available, but also to be easily accessible. The other requirements’ definitions were revised and adapted to the context that was investigated (see discussions in Section 8).

7.2. Assessment of the VM Practices

The revised set of requirements (Table 10) was used to assess the VM practices, considering three different levels of adoption: full, partial, and non-adoption (

Table 11. Classification of VM practices according to VM requirements.

VM Requirements	Type A
	Digital				Manual
	Activity Tracker 1	Activity Tracker 2	Performance Dashboard 1	Performance Dashboard 2	Collaborative Board 1	Collaborative Board 2	Whiteboard 1	Whiteboard 2
R1	A	A	A	A	A	PA	A	A
R2	PA	A	PA	A	A	PA	NA	NA
R3	A	A	PA	PA	PA	NA	PA	PA
R4	A	A	PA	PA	NA	NA	NA	NA
R5	A	A	A	A	PA	PA	PA	PA
R6	A	A	A	A	NA	NA	NA	NA

Note: Levels of adoption: Adopted (A), Partially adopted (PA), Not adopted (NA). VM requirements: Simplicity (R1), Information standardisation (R2), Information availability (R3), Information accessibility (R4), Flexibility of devices (R5), Information traceability (R6)

), based on the perceptions of the research team. This assessment is not absolute, as the relevance of the requirements can vary according to the different types of VM practices. This is discussed in the qualitative analysis of each practice that is presented below.

The use of some digital VM practices, such as Performance Dashboards, was limited due to difficulties faced by team members in accessing the right information or the devices (R3 and R4). The company recently started to encourage the use of digital performance dashboards, but those practices were in the early stages of implementation across the company. Their outcomes were based on information stored in a cloud system, and users had not enough skills and knowledge in using it effectively. There was no clarity about how to use the device and where to find the information. The difficulties were also associated with a lack of ownership in the adoption of those digital devices. Achieving a sense of shared ownership is one of the key VM purposes of the traditional approaches, as suggested by Tezel et al. [40], which can also support the achievement of the company’s strategic goals.

There was also a need to decentralise the use of Performance Dashboards, which can be achieved by enabling project teams to have more responsibility to control and evaluate their activities. Their integration in the weekly meetings had the potential to support the adoption of the devices, whereas initial training to introduce their functionalities and aims to all stakeholders could provide an understanding of how to use and access them. Thus, the information accessibility requirement (R4) was partially adopted in Performance Dashboards. Furthermore, some specific metrics were sent in reports to the team members as static information, providing evidence of the lack of real-time information availability.

Activity Tracker practices adopted or partially adopted most of the requirements. They fulfilled the availability (R3) and accessibility of information (R4) requirements, as the team had access to the information, which was available at the right time, in the right amount, and in the right place, while being filtered by the different disciplines that were involved in meetings. The information was easily accessible by all team members, allowing them to use and update the weekly plan before the meetings, which is also connected with the flexibility requirement (R5).

The manual practices, such as Collaborative Boards and Whiteboards, had a limited adoption of the requirements, as expected, considering that the set of requirements was devised for VM practices that were supported by digital technologies. Whiteboards performed very well in relation to the simplicity requirement (R1), allowing a strong engagement of stakeholders during the collaborative planning sessions. Furthermore, there was a clear understanding of the VM practice function by all users, which facilitated collaboration, such as in the Collaborative Board with milestones and deliverables to support phase scheduling. The Collaborative Board was more integrated in Project I as the stakeholders had previous experiences with collaborative practices. Furthermore, there was a lack of understanding of how to use those devices in Project II due to the overload of information, which is related to the lack of information prioritisation (R3) requirement, also creating difficulties in maintaining that the information was up to date. There was a lack of accessibility (R4) of the device after the meeting, as there was a lack of space to display VM devices in company A offices, as the meeting rooms were shared between different projects. Therefore, there were issues in properly recording and sharing the information with geographically distributed teams. There was no information traceability for the manual VM devices (R6); team members highlighted that there was a rework in the information transfer between Collaborative Boards and other devices.

Most of the practices that were identified were used in meetings at a tactical planning and control level, i.e., collaborative planning sessions and monthly progress meetings. VM practices at this managerial level were more embedded within the company, as the stakeholders were familiar with practices from previous projects. The tactical level was supported by both manual and digital devices, whereas the operational level had only digital devices implemented in it. For example, the decisions made at face-to-face (FFC) collaborative planning sessions were supported by the manual collaborative visual boards. Activity Tracker 1 and Performance Dashboard 1 implemented in weekly and monthly progress meetings were mostly adopted through synchronous distributed and face-to-face collaboration (SDFFC), as a part of the team was co-located and the other part was working from different offices in the UK.

Table 12. Classification of the VM practices according to collaboration and communication approaches.

	Same Time	Different Times
Same place	Face-to-face Collaboration (FFC): Collaborative Boards 1 and 2, and Whiteboards 1 and 2	Asynchronous Collaboration (AC)
Different places	Synchronous Distributed Collaboration (SDC): Activity Tracker 1 Activities Tracker 2, and Performance Dashboard 2	Asynchronous Distributed Collaboration (ADC): Performance Dashboard 1 and 2, Activity Tracker 1 Document, and information management systems (e.g., SharePoint, ProjectWise, and Microsoft Teams) **
Both same place and different places	Synchronous Distributed and Face-to-face Collaboration (SDFFC) *: Performance Dashboard 1

Note: * Category proposed in this investigation. ** provided means for distributing information, enabling the creation of a common environment.

presents a classification of the VM practices according to the collaboration and communication approaches that were adopted to support the managerial routines described above.

Digital type A VM devices were adopted as a common reference point between users, as argued by Nicolini [42], responding to different concerns simultaneously, in order to allow greater interaction and coordination. The most relevant approaches to support the transfer of information of digital VM practices were synchronous distributed collaboration (SDC), asynchronous distributed collaboration (ADC), and synchronous distributed and face-to-face collaboration (SDFFC). Most of the collaborative VM practices were classified as many-to-many interactions; however, it did not represent a decentralised practice, as it still needed to rely on different steps to be adopted, e.g., the information needed to be filtered and prioritised before sharing it with the whole team, which could result in a kind of information fragmentation.

Digital VM practices engaged more users than the manual ones did, as there were more stakeholders involved in the information input and output process, considering that the distributed teams were able to easily communicate and access the digital devices. Some of the manual practices, such as Collaborative Board 1 and Whiteboards 1 and 2, were also characterised as ‘many-to-many’ interactions. However, those practices did not fulfil the traceability, availability, and accessibility requirements. By contrast, manual VM practices tend to be much more effective in supporting collaboration through face-to-face communication than digital practices do through virtual interactions.

Digital VM practices still have issues regarding their simplicity, the excess of information, and the lack of relevant information prioritisation, which are mostly related to the requirements of simplicity (R1), standardisation (R2), and availability (R3). In fact, there is still a lack of effective use of information and the selection of the right information for the right purpose. The implementation of digital VM devices, e.g., digital planning boards used with a face-to-face communication approach emerged in the open interviews as a potential new approach for the company. Such a hybrid implementation of VM can potentially support new ways of information transfer by improving information availability and traceability, and extending the existing capabilities, but still considering the traditional approaches for collaboration and communication.

The analysis of the different types of manual and digital VM practices indicated that the importance of the requirements can vary across different types of VM devices, hierarchical planning levels, and the stakeholders that were involved. External stakeholders are considerably involved in the design process and usually become involved in the adoption of VM practices, mostly in high-level decisions. Both perspectives, internal and external, have connections at all levels, having different requirements according to the involvement of the stakeholders in the process.

Figure 10 outlines the relevance of the VM requirements (R1–R6) according to the hierarchical planning levels, i.e., strategic, tactical, and operational, by classifying the requirements as ‘must have’ (essential) and ‘should have’ (desirable).

Flexibility (R4) plays a key role at the operational level, as actions change more quickly than they do at other levels, usually along a weekly or daily timeline for capturing, analysing, and processing information. All six requirements (R1–R6) are considered as essential to this planning level. Information standardisation (R2) must be considered as very important at the operational level, guiding team members on how to use them and allowing the correct use of the device, and therefore, increasing their autonomy to plan and control at a discipline level by reducing the complexity of the practice. In addition to this, simplicity of information (R1) is also strongly related to the need of giving autonomy to the users of the devices. Information availability (R3) enables information prioritisation according to the hierarchical planning level, as well as filtering the information according to the stakeholders that are involved or the key topics to be discussed. Likewise, it is essential to have the information located at the right place, enabling easy access (R4) to the required information for all team members. Traceability (R6) is also required to support easy storage and tracking the reasons for success or deviations.

The requirements that are related to information simplicity (R1), standardisation (R2), availability (R3), and flexibility (R5) play a key role in the VM implementation at a tactical level. The cycles of planning, control, and coordination of the design process at the tactical level are shorter than they are in production, requiring simple (R1) and flexible (R5) VM practices as a way to adapt and change as needed; the information standardisation (R2) can also support that. However, standardisation is not required to support the VM practice implementation of Whiteboards, as this practice should be flexible in order to adapt to the users’ dynamic interactions and needs. The external stakeholders’ perspective focuses on simplicity (R1), accessibility (R4), and traceability (R6), allowing them to understand, access, and track information at this planning level.

The VM practices that are implemented at the strategic level must fulfil the simplicity (R1) and information accessibility (R4) requirements for the internal stakeholders. The update of the master planning is more scattered, requiring simplicity with the use the devices and, consequently, easy information access. Simplicity is mostly required as usually there is an excessive level of detail in long-term plans, making them difficult to be updated. The adoption of the practice by external users can be facilitated with information standardisation (R2), information traceability (R6), and simplicity of functioning (R1). The client, contractor, subcontractors, or other stakeholders must be able to easily understand the information through the standardisation of the information to avoid misunderstandings and preventing loss of time to interpret information, as well as to track the main decisions.

8. Discussion and Evaluation of the Requirements

This research work has initially selected a set of VM requirements from the literature, which were considered to be relevant, and then we revised their definitions by considering the context of the design planning and control in infrastructure projects with the support of digital tools. Furthermore, two additional requirements (traceability and accessibility) were added to this set.

Table 13. Characteristics of the design planning and control with the support of digital tools.

VM Requirements for Digital Context	Characteristics of Design Planning and Control with the Support of Digital Tools
Simplicity (R1)	There are many iterations in the design process, and a high degree of uncertainty. Considering the complexity of infrastructure projects, designers need to deal with a large amount of information that needs to be updated often. In this context, simplicity of visual devices is even more relevant.
Standardisation (R2)	Design has several planning and control cycles (strategic, tactical, and operational) that should be supported by VM practices. ‘Standardisation’ contributes to delivering accurate information in every planning and control meeting.
Availability (R3)	‘Availability’ is also very relevant in design planning and control, due to the large amount of information that needs to be managed. Availability was defined as the right amount of time taken for delivery and the right amount of information, while ‘Accessibility’ was concerned with whether information was in the right place.
Accessibility (R4)
Flexibility (R5)	Flexibility is an essential requirement as it is necessary for the users to easily navigate across different devices, as well as access and update the information needed for the different planning levels, considering the need for continuous improvement.
Traceability (R6)	Traceability has become more important due to the adoption of digital technologies [66]. The new definition extends the definition from the literature: it includes information storage and tracking.

points out some characteristics of the context of the design planning and control with the support of digital tools that must be considered in the definition of the set of requirements.

Some existing VM requirements, such as simplicity (R1), standardisation (R2), and flexibility (R5), had their description revised after considering the digital perspective. Simplicity (R1) emerged as one of the main requirements to engage all stakeholders by making easy the understanding of the purpose of the devices or practices, as was also argued by Saurin et al. [45] and Valente et al. [43]. Simplicity is also concerned with how to use the device [45]. Thus, it is one of the most essential concepts of VM, as the devices are developed to be simple to use and understand so that the information transfer provides autonomy to the stakeholders.

Information and procedures standardisation (R2) and information availability (R3) emphasised the relevance of providing only the information that was required to facilitate the user’s understanding and the control of repetitive tasks, as suggested by Tezel et al. [40,67]. The Standardisation (R2) requirement had its relevance assessed for the context analysed, and new definitions were suggested. This investigation suggests that this requirement is associated with the extensive use of devices and information, regularity, i.e., the repetition of information units. By contrast, the previous literature focused on the impacts of standardisation, such as support given to data searching and processing actions, as well as monitoring system conditions [48,50].

Furthermore, flexibility (R5) was even more relevant to the digital VM devices and their practices than the manual or traditional ones, supporting modifications of the VM practices through dynamic interactions, as discussed by Eppler and Bresciani [51]. The refinement of the definition emphasised the need to consider the adaptability of information to meet different users and the needs of specific contexts, e.g., different planning levels, considering continuous improvement aspects. It is also relevant how easy it is to update the information [52]. For instance, customisable interfaces can effectively deal with context-related specifications or with unexpected changes in the environment. In the case of digital VM devices, information can be updated by introducing some degree of automation, such as in the case of performance dashboards which should display accurate and up-to-date metrics.

This investigation proposed information traceability (R6) as a new requirement, which was not previously suggested in the literature. The requirement is commonly adopted when discussing digital technologies [66], but it is not widely discussed in the VM area. Based on the empirical studies, this requirement was considered to be more relevant due to the introduction of digital environments in design, as suggested by Whyte et al. [68]. However, in this investigation, traceability is concerned with systematic approaches to store, track, and report information across the project process, potentially allowing fast feedback during design development. Tracking down the information origin is particular important in in this context due to the need to learn who made design changes, and when these happened.

The difference between information availability and accessibility was also introduced due to the importance of digital VM practices to deliver information at the right time and in the right amount, and in the right place. The previous literature assumes that accessibility and availability are similar concepts. In this investigation, availability is concerned with having updated information available at the right time and in the right amount, whereas accessibility is associated with how easy is to access the information, i.e., if the information is located in the right place.

The preliminary evaluation of the artefacts in terms of their applicability was limited to the simplicity of the structure and definition of the requirements for the users. In general, the fundamental ideas of the requirements were easily understood by the professionals involved in the workshops and discussions. In fact, some of the requirements, e.g., simplicity, standardisation, and flexibility, were often mentioned when assessing the existing design planning and control system and VM practices.

9. Conclusions and Suggestions for Further Work

The main contribution of this investigation is the development of a set of VM requirements for the design planning and control of infrastructure projects, that are supported by digital technologies. An initial set of requirements was identified in the literature review, and these were refined in an empirical study that was carried out in a company in that was charge of the design of infrastructure projects. In that study, the relevance of the initial set of VM requirements was assessed, as these were mostly based on the context of production management in the manufacturing and construction sectors, and a revised set of requirements was proposed. Thus, the theoretical contributions of this investigation are related to the requirements that are considered to be relevant to the context that is investigated, contrasting with the existing literature on that topic, which is highly fragmented.

There are some requirements that are clearly emphasised by the adoption of digital VM, such as information traceability, accessibility, and availability. By contrast, the adoption of other requirements, especially simplicity, is still challenging. Therefore, the research work also contributed by pointing out the current limitations and challenges of digital VM. The results also show that the relevance of some requirements varies across different types of VM practices, hierarchical planning levels, and stakeholders that are involved. For instance, flexibility is essential for the operational level due to the daily or weekly changes that are required, whereas simplicity is mostly required for the strategic level, e.g., for avoiding the excessive level of detail in long-term plans. The implementation of digital VM practices through different approaches of communication and collaboration also emerged as a contribution within the investigation, supporting an initial characterisation for hybrid VM systems.

Regarding the limitations of this investigation, it must be pointed out that this research work was mostly focused on the stages of problem identification and understanding of the design science research cycle. The proposed set of requirements emerged during the investigation and, for that reason, its evaluation in terms of utility and applicability is limited. The context that was analysed can also be considered a limitation, as the empirical study was carried out in three different projects of a single company. Nevertheless, this investigation points out the underlying ideas behind the digital and manual VM practices that were successfully adopted by the company and highlights the challenges faced in implementing VM practices that are supported by digital technologies. Therefore, the set of requirements that are proposed in this investigation can be considered as a point of departure for future studies.

Finally, some opportunities for further research have been identified in this investigation: (i) evaluate and refine the set of requirements and assess their utility by considering a wide range of VM practices and contexts, as well as different levels of IT implementation; (ii) further explore devices for design coordination (type B) and for continuous improvement (type C); (iii) further explore the adoption of digital VM practices to support collaborative processes in design; (iv) explore the VM role in linking the digital with manual systems, as well as hybrid VM systems.