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

Many practitioners interested in i-Construction focus on the positive effects such as productivity improvement, labor reduction, and quality assurance, but when they actually try to implement it they face more obstacles than expected. Among those who search for "iconstruction", there are many who understand the制度 and concepts yet want concrete answers to whether it will actually work on site, whether the current organization can handle it, and where to start to minimize the risk of failure. i-Construction is not simply an effort to add new equipment or methods; it requires rethinking the entire workflow — from surveying, design, construction, as-built management, and inspection to maintenance. Therefore, the barriers to implementation extend beyond technical issues to organizational, operational, and educational aspects.

Also, 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," "data management is worrying" — but when translated to the site level they become concrete operational issues such as "who will verify the reference data," "where will measurement results be integrated," and "in what format will we exchange data with subcontractors." In other words, the success of i-Construction is not determined solely by whether you know advanced technologies, but greatly influenced by how many realistic obstacles you anticipate before implementation and how well you prepare for them in a stepwise manner.

This article organizes and explains six representative walls you should know before introducing i-Construction from a practical perspective. It also introduces approaches for overcoming each wall and ideas for incorporating them into the site without undue burden. By grasping not only ideal scenarios but also the points where operations tend to stumble in practice, you can reduce confusion and detours after introduction.

Table of contents

• Why challenges tend to appear large with i-Construction

• Wall 1: Implementation often starts with vague objectives

• Wall 2: Training and role allocation lag behind

• Wall 3: Data preparation and handover are difficult

• Wall 4: Effectiveness varies depending on site conditions

• Wall 5: Rebuilding cooperative structures is time-consuming

• Wall 6: Post-introduction operational embedding is not foreseen

• How to proceed to overcome the six walls

• Summary

Why challenges tend to appear large with i-Construction

i-Construction is widely recognized as an initiative aiming to improve productivity and working styles on construction sites, but for site personnel it can feel less like a "system that makes things more convenient" and more like "a system that adds new tasks." This is because it is not enough to simply replace existing tasks; you must change the way work is conducted. For example, you need to think of the data acquired during surveying as part of a series that connects to design and construction, and consider how information gathered during construction will be recorded and ultimately reflected in as-built results and inspections. Even if individual tasks are optimized, if they do not fit together in the whole process the expected benefits are hard to realize.

Furthermore, i-Construction cannot progress if only a few specialists understand it. Site supervisors, survey staff, construction staff, documentation staff, and managers — multiple roles need to face the same direction. In reality, however, each role emphasizes different perspectives. Site supervisors worry about schedule impacts, survey staff emphasize accuracy and procedures, and managers look at overall cost-effectiveness and reproducibility. If these differences in awareness are not bridged, meetings before implementation may seem positive but during execution you often end up with the situation of "we don't know who this is for."

Information about i-Construction tends to center on制度 overviews and technical potentials, and detailed operational issues at the practical site level are not always well shared. On the surface, digitization looks like efficiency, but in practice you need steady coordination on data verification, recording rules, operational procedures, training, and internal approvals. If these behind-the-scenes tasks are neglected, sites can end up with "more work than expected" or "we returned to the old way after all." That is why correctly understanding the walls before implementation and aligning expectations with reality are important.

Wall 1: Implementation often starts with vague objectives

The first common wall in i-Construction implementation is that discussions proceed while the objectives remain vague. On site, evaluation may start because "it's the trend," "others are doing it," or "it might be necessary in the future." Those motivations are not wrong per se. However, if objectives are vague, it becomes unclear which tasks to start with, how far to scope the effort, and what constitutes success. As a result, even if equipment or systems are introduced, usage does not become established and variation widens across sites.

For example, within i-Construction one site might mainly aim to reduce labor in surveying, while another site may prioritize improving efficiency of as-built management or digitizing construction records. Trying to do everything at once without narrowing objectives suddenly increases the burden on the site and tends to produce half-baked results across tasks. In practice, rather than aiming for ideal overall optimization from the start, it is often more successful to first define what you want to improve and then choose methods that align with that objective.

Also, vague objectives make internal explanations difficult. Site staff may see increased work, managers may find it hard to see tangible results, and subcontractors may feel they are being asked to do extra work. This makes consensus-building for implementation slow. i-Construction should be advanced not merely as a decision on whether or not to introduce technology, but as a project for sharing what problems you want to solve.

To overcome this wall, it is important before implementation to concretize questions such as "which processes do we want to reduce labor in," "which tasks do we want to reduce errors in," and "where are the wastes in recording and verification." Once objectives are clear, necessary preparations become more visible. Conversely, when objectives remain vague, dissatisfaction and confusion after introduction are almost inevitable. It is not an exaggeration to say that the first wall is not a lack of technology but a lack of goal setting.

Wall 2: Training and role allocation lag behind

While i-Construction is often discussed as technology adoption, in actual sites human factors can become a more serious wall. Common problems include a limited number of people who can use the tools and unclear responsibility boundaries. If a new method is introduced but only specific individuals understand it, it will not translate into site-wide operations. The moment that person is absent, tasks stop, handovers cannot be made, and expansion to other sites becomes impossible.

In practice, daily duties are busy, so securing concentrated training time is difficult. As a result, even after a new operation starts, training may end with only a one-time distribution of procedure manuals. But tasks related to i-Construction require more than simple operational learning: staff must understand the meaning of data, judge errors and conditions, and handle data in ways that do not affect downstream processes. In other words, it requires practical decision-making beyond appearances. If staff only learn superficial operation, they cannot adapt in the field and the practice will not stick.

Moreover, if role allocation proceeds while still vague, responsibility becomes unclear. For example, if it is unclear who verifies reference data, who manages storage rules for on-site acquired data, or who decides on re-measurement when outliers appear, responses are delayed when issues occur. Because data in i-Construction is used across multiple processes, a single decision mistake can affect downstream tasks. Therefore, leaving role boundaries ambiguous tends to leave sites feeling insecure.

Also important is reconciling veterans' experience with new methods. Highly experienced staff in traditional tasks may be cautious about new approaches. This is not necessarily resistance; it may reflect a sense of responsibility for quality and safety. What the site truly needs is not denying experience but organizing how to combine experience with data. i-Construction should be positioned not as a replacement for people but as a system that supports human judgment and improves reproducibility.

To overcome this wall, proceed on the premise of deepening understanding by repeatedly using the methods within daily work rather than relying on one-off training. It is also effective to differentiate the depth of understanding required by role. Not everyone needs the same level of detail, but at minimum the overall workflow and each person’s role must be shared. If training and role allocation are postponed, technology will not make the site operate. Understand that the real difficulty of i-Construction lies in redeploying and retraining people.

Wall 3: Data preparation and handover are difficult

At the core of i-Construction is the idea of leveraging data in operations. In practice, however, the "connecting data" part becomes a major wall. To use information collected on site correctly in the next process, you need to organize data formats, naming conventions, coordinates and reference systems, revision histories, and storage locations. If these are unclear, valuable data will not be utilized and will become mere archives.

Data handover is especially problematic. When information obtained during surveying is passed to design or construction, differences in format, interpretation, and update timing can cause rework and duplicated work. One person may think they have the latest data while another sees an older version. Also, because site work is ongoing, both paper drawings and digital data often coexist. Without clear management rules in this situation, it becomes ambiguous which is authoritative.

Furthermore, data does not end with acquisition. Metadata such as the precision at which data was collected, the conditions under which it was recorded, and the range of applicability are important. Without these, those who view the data later cannot judge it appropriately. Practitioners often struggle not because of the sheer amount of data but because they cannot extract the necessary information in the necessary form. More information does not always mean more convenience; poorly organized information increases site burden.

Also, solving data preparation issues at the site level alone is difficult because it requires company-wide rules, agreements with subcontractors, and shared understanding among roles. If each site creates its own practices, it may work temporarily but cannot be reused for the next project, forcing adjustments from scratch every time. To continue advancing i-Construction, at least minimum standardization is essential beyond individual responses.

To overcome this wall, document in advance "which data, by whom, where, how it will be stored and updated." You do not need a perfect system from the start, but you do need rules that prevent confusion on site. i-Construction demands an information management mindset before technology. If data preparation is weak, the site will see more verification work rather than becoming more efficient.

Wall 4: Effectiveness varies depending on site conditions

When considering i-Construction, viewing only success stories can create the impression that the same benefits can be obtained at any site. In reality, however, scale, terrain, surrounding environment, nature of the schedule, and staffing composition all produce significant differences in actual gains. Overlooking this reality can lead to disappointment after implementation when "it was not as efficient as expected."

For example, in large-area sites with many repetitive tasks the benefits of data utilization and measurement efficiency are more apparent, whereas in small-scale sites with frequent condition changes the burden of preparation and adjustments may outweigh the benefits. Surrounding environments can also impose constraints on acquiring positional information or operating equipment. Additionally, some construction tasks are well-suited to digitization while others still rely heavily on traditional experiential judgment. In short, i-Construction is not万能; there are parts where it is easy to apply and parts that require cautious assessment.

The reason this wall grows large is that pre-implementation attention tends to focus on "what can be done" rather than "under what conditions will it be effective." In practice, adopting new methods can become an end in itself and the compatibility assessment with the site is postponed. But implementing without checking compatibility with site conditions leads to usability issues and additional adjustment burdens. As a result, site personnel may conclude "the old way is faster after all," undermining future rollout.

Also, differing levels of effect mean you cannot use a single evaluation metric. At one site shortened work time may be the outcome, while at another improved record accuracy, fewer re-measurements, or easier handover may be the value. If you judge implementation solely by simple time savings, you may overlook benefits actually being generated.

To overcome this wall, carefully inventory site conditions before implementation and determine "which processes are likely to benefit" and "under what conditions is combining with traditional methods appropriate." i-Construction is more likely to succeed when applied selectively rather than uniformly. What matters is not whether you introduce it, but whether you can tailor it to your company’s sites.

Wall 5: Rebuilding cooperative structures is time-consuming

i-Construction becomes more difficult when multiple stakeholders are involved than when it is completed within one company. Construction operations rely not only on internal personnel but also on subcontractors, external surveying support, and various parties involved in construction. Therefore, even if one company proactively promotes implementation, operations across the entire site can stop if surrounding structures are not prepared.

A common issue is that assumptions for work and data handover rules are not shared. Even if your company believes it has standardized, if subcontractors differ in procedures and understanding, things will not progress as expected. Data verification can take time, resubmissions may be required, and verbal confirmations may increase, paradoxically increasing the workload. This is not primarily a problem with the new method itself but a lack of collaboration design.

There are also psychological barriers in reconstructing cooperative structures. Those asked to follow new operational rules bear the burden of changing familiar ways. If expected quality and submission formats are unclear, anxiety arises first. A typical situation on site is "I thought I did it as instructed, but later corrections were needed." Repeated occurrences of this kind of misalignment create fatigue among stakeholders and reduce enthusiasm for i-Construction.

Moreover, company-wide policies may not be sufficiently disseminated at the site level. Managers may want to push implementation, but without concrete operational instructions on site, adjustments with subcontractors are left to individual staff. This leads to person-dependent practices at each site and does not foster continuous improvement.

To overcome this wall, clarify what and to what level must be prepared before asking stakeholders to adopt new practices. Share concrete operational items rather than ideals. Specify which stage checks are made, in what format data is handed over, and who to return issues to — organize these into practical workflows. Because i-Construction cannot be completed by a single company’s efforts alone, designing cooperative structures is the key to success.

Wall 6: Post-introduction operational embedding is not foreseen

The last commonly overlooked wall in i-Construction is a failure to foresee embedding operations after introduction. A new system does not produce results the moment it is introduced. Rather, immediately after introduction you may experience increased workload due to operation checks, procedure revisions, data preparation, and trouble resolution. If you do not anticipate this initial load, the evaluation will be "only more work" and operations may stop before embedding.

Many reasons systems fail to stick on site relate to the initial enthusiasm not being carried into subsequent operations. Even if a few staff are enthusiastic at first, when daily work becomes busy recording rules may erode, verification steps may be skipped, and the operation may gradually become a mere formality. Then data quality becomes unstable and its utility declines. Ultimately you risk reaching the state of "we introduced it but we’re not using it."

Post-introduction reviews for improvement are also indispensable. You must organize where burden increased, where benefits appeared, and what was hard to understand; otherwise the same problems will recur at the next site. In practice, however, running construction is prioritized and it is difficult to secure time for reviews. As a result, issues are not shared and they get buried in individual experience.

Further, embedding operations requires room for corrections that assume failures. If you try to create a perfect flow from the start, you cannot respond when minor deviations occur on site. i-Construction is strongly characterized by trying things on site and improving them, so you need a mechanism that allows flexible revision. Once you decide to introduce it, do not fix it permanently; adopt an approach of adjusting as you use it.

To overcome this wall, treat introduction as the start rather than the goal. Share that initial workload may increase at any site and prepare support systems and review opportunities until embedding. The success of i-Construction is judged not by the flashiness at introduction but by how naturally it is used six months or a year later. Without design for embedding, no matter how promising the system is, it will not continue on site.

How to proceed to overcome the six walls

The six walls described above may seem independent, but in reality they are deeply interconnected. Vague objectives lead to unclear training policies, insufficient training undermines data operations, unstable data operations delay coordination with subcontractors, and as a result embedding fails — this sequence is common. Therefore, solving i-Construction challenges requires organizing the order of implementation rather than addressing individual problems ad hoc.

First, avoid proclaiming an overly grand company-wide ideal at the outset. While future overall optimization is important, in initial practice it is more realistic to narrow the improvement target. For example, if record organization in surveying is an issue, design the introduction focusing on that process and clarify who will verify what. If as-built management verification is a heavy burden, organize information use for that part first. Defining the scope from problem origins makes it easier for the site to understand the objective.

Next, keep operational rules concise. Complex rules are hard to follow in busy sites. Even if you want to define detailed items ideally, it may be better to start with the minimal rules the site can realistically follow. For instance, if basic items such as storage locations, naming conventions, verification responsibility, and handling of the latest version are unified, confusion will be greatly reduced. It is more effective to establish rules that can be followed than to pile up advanced rules from the start.

Also necessary is a mechanism to apply trial results to the next case. If you record where the burden concentrated, where it was convenient, and what misunderstandings occurred in the pilot site, preparation quality improves for the next project. To truly make i-Construction a company capability, it is more important to create a state that accumulates failures and improvement points than to produce a single success story.

Finally, arrange operation of site data and positional information so practitioners are less likely to be confused. A complex system may seem high-function but become a burden in daily use. Especially when quick positional confirmation or recording is needed on site, ease of operation and reproducibility are important. To advance i-Construction while reducing site burden, choose methods that balance required accuracy and practicality rather than overly specialized operations.

Summary

The challenges of i-Construction are not simply about whether you can master new technologies. Implementation success depends on multiple overlapping factors: setting implementation objectives, personnel development, role allocation, data preparation, compatibility with site conditions, cooperative structures, and operational design through to embedding. Conversely, understanding these walls in advance can greatly reduce failures at introduction. The important point is not to look only at an ideal future but to proceed in a feasible sequence that fits site realities.

Many practitioners searching for "iconstruction" want to know not the制度 meaning itself but whether it can really be used on site and where they will stumble. The answer is that i-Construction can indeed deliver benefits, but there are walls to overcome before introduction. Those walls are not invisible. By clarifying objectives, narrowing application scope, organizing training and operational rules, and expanding gradually in a way that fits the site, the walls can be overcome.

In particular, if you want to streamline on-site positional confirmation, positioning, and recording tasks, measures that are easy to incorporate into daily operations are more important than overly complex systems. To translate i-Construction from a desk concept to practical operations, choose devices and operational methods that are easy to handle on site while ensuring necessary accuracy. From that perspective, if you are considering using smartphones in site operations, iPhone-mounted GNSS high-precision positioning devices like LRTK are a promising option. They can make coordinate acquisition and position confirmation feel more familiar on site, are relatively easy to adopt as a first step in i-Construction, and are worth checking for practitioners who want to realistically lower the barriers to implementation.