What are the challenges of i-Construction? 6 barriers you should know before implementation

Many practitioners interested in i-Construction focus on its positive effects such as productivity improvement, labor saving, and quality assurance, but when they actually try to implement it they encounter far more barriers than expected. Among those who search for "iconstruction", there are many who understand the system and concepts but want to know concretely whether it will actually work on site, whether their current setup can handle it, and where to start to avoid failure. i-Construction is not merely an initiative to add new equipment or methods; it requires a rethinking of the entire workflow—from surveying, design, and construction to as-built management, inspection, and maintenance. Consequently, the hurdles to implementation extend beyond technical aspects to organizational, operational, and educational areas.

Moreover, the challenges of i-Construction differ in nature between those visible before implementation and those that surface after operations begin. Before implementation, concerns may appear abstract—“it looks difficult,” “we don’t have enough people,” “we’re unsure about data management”—but when put into practice they become concrete operational issues such as “who verifies the reference data,” “where are measurement results integrated,” and “in what format do we hand off data to subcontractors.” In other words, the success or failure of i-Construction is not determined solely by whether you know advanced technologies, but largely by how realistically you anticipate practical obstacles before implementation and how methodically you prepare for them.

This article organizes and explains six representative barriers you should know before introducing i-Construction from a practitioner’s perspective. It also introduces how to overcome each barrier and approaches to incorporate i-Construction into the field without undue strain. By understanding not only the ideal theory of implementation but also the common stumbling points in actual operations ahead of time, you can reduce post-implementation confusion and detours.

Table of contents

• Why challenges tend to appear large with i-Construction

• Barrier 1: Implementation often starts with unclear objectives

• Barrier 2: Human resource development and role allocation lag behind

• Barrier 3: Data preparation and handover are difficult

• Barrier 4: Effects vary greatly depending on site conditions

• Barrier 5: Rebuilding cooperative relationships takes time

• Barrier 6: The post-implementation operational stabilization is not anticipated

• How to proceed to overcome the six barriers

• Summary

• Why challenges tend to appear large with i-Construction

i-Construction is widely recognized as an initiative to improve productivity and working conditions on construction sites, but for site personnel it can feel less like a “system that makes things convenient” and more like a “system that increases new tasks.” This is because it does not simply replace conventional tasks; it requires changing the way work is carried out. For example, you must consider as a continuous flow how data acquired during surveying links to design and construction, how information during construction is recorded, and how it is ultimately reflected in as-built results and inspections. Optimizing individual tasks alone will not produce the expected effects if they do not fit together as a whole.

Furthermore, i-Construction cannot advance if only a few specialists understand it. Site supervisors, surveyors, construction personnel, document preparers, and managers must all face the same direction. In reality, however, each role emphasizes different perspectives. Site supervisors worry about impacts on the schedule, surveyors focus on accuracy and procedures, and managers look at overall cost-effectiveness and reproducibility. If these differences in awareness are not bridged, pre-implementation meetings may appear positive while in the execution phase you end up with the feeling “we don’t know who this implementation is for.”

Also, information about i-Construction tends to focus on the system overview and technical possibilities, and detailed operational issues from the field are not always sufficiently shared. On the surface, digitalization looks like it will improve efficiency, but in practice you need careful adjustments for data verification, recording rules, operational procedures, training, and internal approvals. If these behind-the-scenes tasks are underestimated, the site may find that “the workload increased more than expected” or “we ended up reverting to the usual methods.” That is why it is important to correctly understand the barriers before implementation and align expectations with reality.

Barrier 1: Implementation often starts with unclear objectives

The first common barrier in introducing i-Construction is that the process advances while the objectives remain vague. At sites, considerations may begin for reasons like “because it’s the trend,” “because others are doing it,” or “because it may be needed in the future.” Those concerns themselves are not wrong. However, if the purpose of implementation is vague, you cannot see which operations to start with, how broadly to standardize, or what constitutes success. As a result, even if equipment or systems are introduced, utilization does not become established and variations increase across sites.

For example, even within i-Construction, one site may primarily aim to reduce surveying labor, while another may prioritize streamlining as-built management or digitizing construction records. But if you try to do everything at once without narrowing the objectives, the site’s burden can spike and every task tends to be half-baked. In practice, rather than aiming for ideal overall optimization from the outset, you are more likely to succeed if you first define what you want to improve and then choose methods aligned with that objective.

When objectives are unclear, internal explanations also become difficult. For site staff it may look like extra work, for managers the outcomes may be hard to see, and for subcontractors it may simply feel like new demands. This stalls consensus-building for implementation. i-Construction should be advanced not merely as a decision about whether to adopt a system, but as a project for sharing what you want to solve.

To overcome this barrier, it is important before implementation to concretize questions such as “which processes do we want to reduce manpower in,” “which tasks do we want to reduce errors in,” and “where are there wastes in recording and verification.” Once objectives are clear, the necessary preparations become easier to identify. Conversely, if objectives remain vague, dissatisfaction and confusion after implementation are almost unavoidable. It is not an exaggeration to say the first barrier is not a lack of technology but a lack of goal setting.

Barrier 2: Human resource development and role allocation lag behind

Although i-Construction is often talked about as a technology introduction, people-related issues can become more serious barriers on actual sites. Common problems include having only a limited number of capable personnel and ambiguity about who is responsible for what. Even if a new method is introduced, if only specific individuals understand it, it will not translate into site-wide operation. The moment that person is absent, tasks stop, handovers fail, and it cannot be deployed to other sites.

In practice, daily work is busy and securing dedicated training time is difficult. Therefore, even after new operations begin, training sometimes ends with a single distribution of procedural documents. However, tasks related to i-Construction require not only mastering operations but also understanding the meaning of data, judging errors and conditions, and handling data in ways that do not affect downstream processes. In other words, more practical judgment is required than it might appear. If people only learn surface-level operations and cannot apply them on site, the practices will not become established.

In addition, proceeding with unclear role allocation leaves responsibility ambiguous. For example, if it is unclear who verifies reference data, who manages the rules for storing data obtained on site, or who decides on re-measurement when anomalies appear, responses will be delayed when problems arise. Since data in i-Construction is used across multiple processes, one mistaken judgment can easily affect downstream steps. Therefore, leaving role boundaries vague tends to leave the site feeling insecure.

Also important is reconciling veteran experience with new methods. Experienced personnel who are well-versed in traditional operations may be cautious about new approaches. This is often not resistance but a sense of responsibility for quality and safety. What the site really needs is not to dismiss experience but to organize how to balance experience and data. i-Construction should be presented as a system that assists human judgment and improves reproducibility, not as a replacement for people.

To overcome this barrier, it is important to proceed on the assumption that understanding will deepen through repeated use within actual work, rather than one-off training. It is also effective to differentiate the depth of understanding required by role. Not everyone needs to become equally expert, but at minimum the overall flow and each person’s role must be shared. If training and role allocation are postponed, technology alone will not make the site operational. Understand that the real difficulty of i-Construction lies in reallocating and retraining people.

Barrier 3: Data preparation and handover are difficult

At the core of i-Construction is the idea of leveraging data in operations. However, in practice the “linking of data” becomes a major barrier. To correctly use information acquired at the site in the next process, you need to organize data formats, naming conventions, coordinates and references, update histories, and storage locations. If these are unclear, data that was carefully captured will not be used and will merely become stored files.

Data handover is particularly problematic. When surveying information is passed to design or construction, differences in formats, interpretations, and update timing can create rework and duplicate work. One person may think they have the latest data while another is looking at an old version. Also, because construction is ongoing, paper drawings and digital data often coexist. Without clear management rules, it becomes ambiguous which should be considered authoritative.

Moreover, data acquisition is not the end. Preconditions such as the accuracy level at which data was obtained, the conditions under which it was recorded, and the scope where it is valid are also important. If these are not organized, people reviewing the data later cannot make correct judgments. Practitioners often struggle less with the sheer volume of data than with being unable to extract the necessary information in the necessary form. More information does not always mean more convenience; unorganized information can increase the site’s burden.

Additionally, data preparation issues are difficult to solve at the individual site level. This is because solutions require company-wide rules, agreements with subcontractors, and common understanding among stakeholders rather than being confined to one site. If each site develops its own practices, even if it works temporarily, it cannot be reused for the next project and adjustments must be made from scratch each time. If you want to advance i-Construction continuously, at least minimal standardization is indispensable.

To overcome this barrier, it is important to document before implementation “which data, by whom, where, how it will be stored, and how it will be updated.” You do not need a perfect system from the start, but you do need rules sufficient to prevent confusion at the site. i-Construction requires the concept of information management even before the technology is introduced. If data preparation is weak, the site will not find things more convenient; it will find that verification tasks increase.

Barrier 4: Effects vary greatly depending on site conditions

When considering i-Construction implementation, if you only look at successful cases you may get the impression that similar benefits can be obtained across all sites. In reality, however, the effects vary significantly depending on site scale, topography, surrounding environment, the nature of the schedule, and personnel composition. Overlooking this reality leads to post-implementation disappointment that “it wasn’t as efficient as expected.”

For example, wide-area sites with many repetitive tasks tend to benefit more from data utilization and measurement efficiency, whereas small-scale sites with frequent condition changes may feel that the burden of preparation and adjustment outweighs the benefits. Depending on the surrounding environment, there may also be constraints on acquiring positional information or operating equipment. Furthermore, depending on the type of construction, some processes lend themselves to digitalization while other processes still rely heavily on empirical judgment. In short, i-Construction is not a panacea; there are parts where it is easy to apply and parts that require careful assessment.

This barrier grows when pre-implementation focuses on “what can be done” rather than thoroughly confirming “under what conditions will effects emerge.” In practice, adopting a new method can become an end in itself, and compatibility with the site may be left until later. But implementing without evaluating site compatibility invites usability issues and extra adjustment burdens. As a result, site personnel may conclude “the traditional way is ultimately faster,” which negatively affects further deployment.

Also, variability in benefits means you cannot use a single evaluation metric. In one site time savings may be the outcome, while in another the value may be improved recording accuracy, reduced remeasurement, or easier handovers. If you judge implementation solely on simple time savings, you may overlook benefits that are actually being achieved.

To overcome this barrier, you need to inventory site conditions before implementation and determine “which processes are likely to benefit” and “under which conditions is it reasonable to combine with traditional methods.” i-Construction is more likely to succeed when applied selectively where appropriate than when applied uniformly. The key is not simply implementing, but fitting the approach to your company’s sites.

Barrier 5: Rebuilding cooperative relationships takes time

i-Construction becomes more difficult when multiple stakeholders are involved than when it is contained within a single company. Construction work relies on coordination among not only internal staff but subcontractors, external surveying support, and other parties involved in construction. Therefore, even if one company proactively implements i-Construction, operations at the overall site may stall if the surrounding structure is not prepared.

A frequent issue is the lack of shared assumptions about work prerequisites and data handover rules. Even if your company believes it has standardized processes, if each subcontractor has different procedures and levels of understanding, things will not proceed as intended. This can lead to longer data verification times, repeated resubmissions, and increased verbal confirmations, ultimately increasing workload. This is less a problem of the new method itself and more a problem of insufficient cooperation design.

There is also a psychological barrier to rebuilding cooperation. Parties asked to adopt new operational rules must bear the burden of changing familiar practices. If expected quality and submission formats are ambiguous, anxiety arises. A common on-site outcome is “I thought I did it as instructed, but later corrections were needed.” Repeated miscommunications like this create fatigue among stakeholders and reduce enthusiasm for i-Construction.

Furthermore, company-level policies may not be fully disseminated at the site level. Managers may want to push implementation, but without concrete operational instructions at the site the coordination with subcontractors becomes left to individual staff. That leads to ad hoc, person-dependent responses and does not foster continuous improvement.

To overcome this barrier, before asking stakeholders to adopt new practices clarify what needs to be aligned and to what level. What must be shared is not the philosophy but the operational specifics. Specify at what stage what will be checked, in what format things will be handed off, and to whom issues should be returned, and organize these into practical workflows. Because i-Construction cannot be achieved by company efforts alone, designing cooperative structures is the key to success.

Barrier 6: The post-implementation operational stabilization is not anticipated

The final common barrier often overlooked in i-Construction implementation is failing to foresee operational stabilization after introduction. A new system does not produce results the moment it is installed. In fact, immediately after introduction, operation checks, procedural revisions, data organization, and troubleshooting overlap, and the workload may temporarily increase compared to before. If this initial burden is not anticipated, the evaluation may become “only extra work” and operations are likely to halt before stabilization.

Many reasons sites fail to stabilize systems stem from the initial enthusiasm not being carried into sustained operations. Even if some staff are enthusiastic at first, as daily work becomes busy recording rules break down, verification steps are skipped, and the practice gradually becomes only a formality. As a result data quality becomes unstable and its usefulness declines. Ultimately you may reach a state of “we introduced it but don’t use it.”

After implementation, reviews for improvement are indispensable. You must organize where burdens increased, where effects appeared, and what was unclear; otherwise the same problems will repeat at the next site. In practice, however, keeping construction moving is prioritized and it is often difficult to secure time for reflection. Consequently, issues are not shared and become buried in individual experiences.

Moreover, operational stabilization requires room to correct based on the assumption of failure. Trying to create a perfect flow from the start makes it impossible to respond when small deviations occur on site. i-Construction has a strong nature of being trialed and improved on the ground, so you need a system that can be flexibly reviewed. Implementation should not be fixed once decided; it should be refined through use.

To overcome this barrier, treat implementation as a start rather than a goal. Share that initial increased burden is possible at every site and prepare support systems and forums for review until stabilization. The success of i-Construction is judged not by the initial splash but by how naturally it is used six months or one year later. Without a design for stabilization, no matter how promising the system, it will not continue on the site.

How to proceed to overcome the six barriers

The six barriers discussed so far may seem independent, but in reality they are deeply interrelated. If objectives are unclear, training policy is not determined; if training is insufficient, data operations collapse; if data operations are unstable, coordinating with partners takes time; and as a result, stabilization does not occur. To solve i-Construction challenges, you need to arrange the order of implementation rather than treating individual problems ad hoc.

First, it is important not to present an overly grand corporate ideal at the outset. While future overall optimization is important, in initial practical steps it is more realistic to narrow the improvement target. For example, if record organization in surveying is an issue, focus implementation design on that process and clarify who checks what. If as-built management verification is burdensome, prioritize information utilization in that area. Defining the implementation range from the problem perspective makes the purpose easier for the site to understand.

Next, keep operational rules simple. Complex rules are hard to follow when the site is busy. Even if you want detailed rules ideally, starting with a minimum set that the site can implement is often better. For example, if basic items such as storage location, naming method, verification person, and handling of the latest version are unified, confusion will be significantly reduced. It is more effective to establish rules that can be followed than to pile up sophisticated rules from the start.

You also need a mechanism to leverage trial results. If you record where the burden concentrated, when it was convenient, and what misunderstandings occurred at the pilot site, preparation accuracy will improve for the next project. To truly make i-Construction your company’s capability, it is more important to create a state where failures and improvement points can be accumulated than to create a single success story.

Furthermore, the operation of data and positional information used on site should be organized so that practitioners do not get confused. Complex mechanisms may look high-function but often become burdensome in daily operations. Particularly when quick position checks and recordings are needed on site, ease of operation and reproducibility are crucial. To move i-Construction forward while reducing site burden, choose means that balance necessary accuracy and practicality rather than overly specialized operations.

Summary

The challenges of i-Construction are not simply about whether you can master new technologies. Success depends on multiple overlapping elements: setting implementation objectives, human resource development, role allocation, data organization, compatibility with site conditions, cooperative frameworks, and operational design through to stabilization. Conversely, understanding these barriers in advance can greatly reduce implementation failures. The important thing is not to look only at the ideal future, but to proceed in a realistic sequence that fits the site’s circumstances.

Many practitioners who search for "iconstruction" want to know not the meaning of the system itself but whether it can actually be used on site and where they will stumble. The answer is that while i-Construction can indeed deliver benefits, there are real barriers to overcome before implementation. Those barriers are not invisible. By clarifying objectives, narrowing the scope of application, organizing training and operational rules, and gradually expanding in forms that fit the site, the barriers can be overcome.

Especially when you want to improve position checks, positioning, and recording tasks on site, measures that can be naturally incorporated into daily operations are more important than overly complex systems. To put i-Construction into practice rather than leaving it as a theoretical concept, choose devices and operational methods that are easy to handle on site and can reliably secure the required accuracy. From that perspective, if you are considering smartphone-based site operations, iPhone-mounted GNSS high-precision positioning devices such as LRTK are a promising option. They can make coordinate acquisition and position checks on site more accessible and are relatively easy to adopt as a first step in i-Construction, so practitioners who want to realistically lower implementation barriers should consider reviewing concrete ways to use them.