What are the challenges of i-Construction 2.0? Six barriers to on-site implementation

Table of Contents

• Reasons why the challenges of i-Construction 2.0 are attracting attention

• Barrier 1: Implementation tends to begin with unclear objectives.

• Wall 2: prerequisites for data acquisition are not met on site

• Rework occurs due to insufficient understanding of the coordinate system and accuracy requirements for Wall 3.

• Wall 4: Data isn't being utilized because of the separation between on-site and office work

• Barrier 5: It takes time to develop human resources and to embed operational practices.

• Wall 6: Unable to design for starting small, resulting in loss of overall optimization

• How to Successfully Implement i-Construction 2.0 On-Site

• Summary

Why the challenges of i-Construction 2.0 are drawing attention

i-Construction 2.0 is attracting attention as an unavoidable theme for improving productivity, achieving labor savings, ensuring quality, and enhancing safety on construction sites. It is not merely about introducing new equipment or systems; at its core is the idea of digitally linking site information across investigation, surveying, design, construction, as-built management, and maintenance to reduce waste in decision-making and operations. For that reason, it is also a field in which many stakeholders tend to feel, "We understand the momentum to implement it, but it becomes difficult when actually applied on site."

What particularly troubles practitioners is that the concept of i-Construction 2.0 is broad and cannot be completed by a single technology or a single document response. On site, multiple processes occur in sequence — acquiring positional information, creating 3D data, measuring and tracking quantities, construction planning, sharing progress, handling inspections, and handing over to maintenance management. Even if only part of this chain is enhanced, if it cannot be connected to the overall workflow, the expected benefits are unlikely to materialize.

Also, at implementation sites it's easy to adopt a solution for reasons like "it looks convenient," "we'll follow what others have started," or "we need to hurry and prepare it to meet orders," which can lead to selecting the means before clarifying the objectives. This inversion of priorities is a major cause of failed operational adoption and increased burden on the field. Problems such as data collection ending up as the only outcome, inability to fully process data in-house, inability to explain the accuracy of deliverables, and only the assigned person being able to handle the system often stem from insufficient planning during the initial design phase.

Furthermore, i-Construction 2.0 is not a mechanism that delivers results the moment it is introduced. For work that has traditionally been paper-centered and experience-driven, it is necessary to shift to a way of working that assumes data linkage, standardization, and reuse. This is not simply a change of tools, but a change in the way site operations are managed. Therefore, non-technical factors such as the site’s busyness, staff composition, division of responsibilities with partner companies, in-house processing capacity, and training systems strongly influence outcomes.

Many practitioners who search for "iconstruction 2.0" want to know not just explanations of the framework and concepts, but also "what will be the barriers on site," "where failures are likely to occur," and "what they should fix first." Therefore, in this article I organize the issues that commonly trouble on-site introduction of i-Construction 2.0 into six walls, and explain from a practical perspective why each arises and how to deal with it. Not content with mere generalities, I dig into these topics based on the frequent rework and misalignments that occur on site, including perspectives meant to help move implementation forward.

Barrier 1: Implementation tends to start with unclear objectives

The first barrier to i-Construction 2.0 is that discussions tend to move forward while the purpose of implementation remains unclear. On site, various expectations are expressed simultaneously—3D modeling, data utilization, labor reduction, remote verification, and streamlining of as-built management, among others. However, if the question “what do we want to improve at this site?” is not clarified as the starting point for implementation, stakeholders’ understanding will become misaligned.

For example, one person in charge may be aiming to shorten the time required for surveying tasks, while another may prioritize improving the efficiency of drafting. Managers may emphasize visualizing progress, and field personnel may put reducing rework above all else. These are all valid concerns, but if you implement without deciding priorities up front, the necessary data, required accuracy, and operational methods will not be determined, and the result will be a half-baked system.

A common on-site approach is “let’s just collect some data first.” That attitude itself isn’t bad, but data collected without a decided purpose becomes harder to reuse later. Whether discrete point data is sufficient or area coverage is required, whether the data will be used for daily progress comparisons, for as-built verification, or handed over for maintenance management will change both how you acquire and how you organize it. Data obtained with an unclear purpose tends to be large in volume yet unusable for decision-making.

Also, introducing something with an unclear purpose creates the problem that it is difficult to obtain cooperation from on-site personnel. On-site staff are always pressed by processes, quality, safety, and coordination with surrounding operations. To add a new procedure in that context, you must clearly communicate "why it is necessary," "what will become easier," and "which burdens will be reduced." If the purpose is not conveyed, those responsible will feel that new tasks have simply been added, and the operation will tend to become a mere formality.

Moreover, if the objective is vague, the evaluation of outcomes will be vague as well. After implementation you won’t be able to judge whether it worked or not, and you’ll have no basis for rolling it out to the next site. If you aim to reduce labor, you need to compare working times; if you aim to improve quality, you need to look at changes in errors and the number of reworks. If you aim to improve information sharing, you must examine how reporting and confirmation time lags have changed. In short, with an unclear objective you cannot create evaluation metrics, and the improvement cycle will not run.

To overcome this barrier, it is important that, before implementation, you can state in one sentence "what you want to change on-site." For example, specify concrete improvement targets such as wanting to connect the pre-construction survey through as-built management using the same coordinate system, speeding up progress tracking during construction, or reducing the time required to prepare coordination documents. By then organizing the target processes, target data, required accuracy, deliverables, responsible personnel, storage locations, and timing of use, implementation will be tied to on-site work.

i-Construction 2.0 is appealing in principle, but on-site it quickly loses momentum if the objectives are defined with low resolution. The first barrier is not a lack of technology, but insufficient design of the objectives. Whether you can carefully organize this will determine all subsequent operations.

Wall 2: Prerequisites for data acquisition are not met on-site

The second barrier is that the prerequisites for data acquisition are not met on-site. In i-Construction 2.0, it is important to digitally capture positional and geometric information and link it to subsequent processes. However, in actual field conditions, ideal circumstances are not always present. Terrain, structures, the surrounding environment, working hours, weather, and work zone constraints often overlap, making it difficult to collect data as intended.

For example, in locations with poor visibility, where the overhead view of the sky is obstructed, where there is heavy traffic of construction machinery or vehicles, or where scaffolding is unstable, it becomes difficult to obtain stable positional information. Furthermore, daytime working hours are limited, and because of interference from other trades, it may not be possible to secure the ideal measurement time. Even if site personnel understand the need for digitization, if actual working conditions do not keep pace, the quality of the acquired data will vary.

What matters here is not the equipment or the techniques themselves, but whether you have beforehand clarified "under which conditions, at what level of quality, and what can be acquired." At sites where the introduction of i-Construction 2.0 does not go well, it is common to decide only what to acquire and be lax about confirming the acquisition conditions. For example, even when the purpose is clear—such as checking terrain before paving, tracking excavation progress, or inspecting as-built condition—if the required on-site visibility, reference points, measurement routes, the impact of obstacles, and the need for re-survey are not organized, the data will become unusable later.

Another major problem is the lack of established acquisition rules. If it is not decided who will save data, when, over what range, by which criteria, and under what name, data quality will not be consistent even within the same site. Small differences—such as varying data capture density between staff, different storage locations, different ways of assigning dates, and no rules for file names—accumulate and make integration in downstream processes difficult. It is more important to preserve data in a form that can be reused than merely to acquire it, but this perspective is easily overlooked in the field.

Furthermore, ambiguity in the priority of acquisition targets also becomes a barrier. On-site, it may seem ideal to capture everything in detail, but time and processing capacity are limited. If you do not clarify whether it is necessary to capture the entire site every day, whether it is sufficient to capture only areas with significant changes, or whether it is enough to cover only the checkpoints, the burden of acquisition will only increase and utilization will fall behind. i-Construction 2.0 is not about aiming for mass acquisition; its essence is to create a state in which the necessary information can be continuously handled at the required quality.

To overcome this hurdle, an acquisition plan that takes on-site conditions into account is indispensable. Rather than a measurement method based on ideal theory, you need to design operations that can be run reliably at that site. If you decide in advance when to acquire what scope, at what level of accuracy, and to which process to hand it off, you will be less likely to be uncertain on-site. Also, by identifying conditions that are likely to require reacquisition, you can prevent unnecessary rework.

Introducing i-Construction 2.0 cannot be achieved by simply selecting superior technologies. What matters is whether you can establish a data acquisition system that can be sustained without strain, after incorporating the variability of site conditions. If data cannot be collected on site, any subsequent digital utilization cannot begin. That is why aligning the assumptions for acquisition is an often invisible but very large barrier.

Wall 3: Rework caused by insufficient understanding of coordinate systems and accuracy requirements

The third barrier is a lack of understanding of coordinate systems and accuracy requirements. This is particularly easy to overlook when implementing i-Construction 2.0, and it is a barrier whose cost of backtracking is large. On site, things are sometimes treated with the intuitive notion that "as long as the positions match it's fine," but in practice, unless you clearly specify which reference standards are being used and what level of error is acceptable, you cannot correctly link data together.

Problems caused by insufficient understanding of coordinate systems are diverse. Whether a site is operated using its own local datum or aligned to an official standard, how elevation is treated, and whether the correspondence between drawings/design data and on-site reference points is organized can all change the meaning of the same positional information. Even if no issues are apparent at the surveying stage, discrepancies can surface when overlaying design data, verifying construction positions, performing as-built evaluations, connecting with other construction sections, or handing over data for operation and maintenance.

One problem that often occurs during on-site implementation is that the handling of coordinates exists only in the heads of the people responsible. If you rely on past practices and verbal confirmations, operations will collapse the moment the person in charge changes. If information such as which origin is being used, what the design drawings and the field are using as their reference, and whether any conversions or corrections are applied is not documented, data linkage becomes extremely unstable.

The same applies to accuracy requirements. Because i-Construction 2.0 emphasizes the use of 3D data and positional information, there is a tendency to expect high accuracy by default. However, in practice the required accuracy varies by use. The level of strictness needed for information used to monitor daily progress differs from that needed for as-built verification. Nevertheless, if you proceed with a mindset of “just digitize” or “just add positional information” without making this distinction, you may increase on-site burden through excessive quality demands, or conversely find the outputs unusable due to insufficient quality.

Furthermore, accuracy is not determined solely at the moment of acquisition. Unless you manage everything — verification of control points, observation conditions, acquisition procedures, post-processing, and checks for consistency with other data — you will not achieve accuracy that is usable in practice. On site, people tend to be reassured by the figures recorded at acquisition, but in reality discrepancies often become apparent once the data are converted into deliverables. If consistency is lost when transferring point clouds, drawing data, construction management data, and so on to downstream processes, rechecks and rework will be required, greatly undermining the benefits of implementation.

An important measure against this wall is to first make the assumptions about coordinates and accuracy a shared language. It is insufficient for only specialists to understand; it is necessary to organize things so that the site supervisor, construction staff, and office staff can treat them with the same meaning.

There is no need for everyone to memorize difficult theories in detail, but on this site they should share what will be used as the standard, which accuracy is required for which purpose, and where to perform checks.

It is also effective to front-load the verification process. It is too late to notice inconsistencies after processing the entire dataset once it has been acquired. By piloting on a small scale and first confirming consistency with design data, existing drawings, and control points, you can more easily prevent major failures. In i-Construction 2.0, data only becomes meaningful when it is integrated. In other words, coordinate systems and accuracy requirements are not merely technical topics but common rules that tie operations together. If these remain ambiguous, on-site implementation will not last.

Barrier 4: Data isn't utilized due to the disconnect between field operations and back-office work

The fourth barrier is the divide between the field and back-office work. In i-Construction 2.0, the ideal is that data collected on site is organized in the office, from which it leads to construction decision-making, reporting, verification, and sharing. However, in reality the field side is often limited to "collecting" and the back-office side to "processing," and the subsequent intended uses frequently fail to connect.

Field personnel collect data while being pressed by daily schedules and safety management. As a result, they may not have the capacity to pay attention to how the data should be organized afterward, the naming conventions, or the ancillary information required for office work. Conversely, office staff process the handed-over data into drawings and documents but may not fully grasp the on-site conditions or the constraints present at the time of data acquisition. When this mismatch occurs, field teams say, "We collected it properly, but we're told it's unusable," while office teams say, "We don't have the necessary information and need to recheck."

This separation is not merely a lack of coordination, but a problem of business/process design. The essence of i-Construction 2.0 lies in reusing data across workflows. Nevertheless, if the conditions for on-site data capture and the conditions for its use in office processing are considered separately, the effort of digitization will end up being reduced to a data handover task. If information collected on-site is not made available in a form that can be immediately used in the office as decision-making material, the situation is essentially no different from organizing paper photos or manually transcribing data.

An even bigger problem is that the evaluation criteria differ between on-site and office work. On-site personnel prioritize making steady progress in a short time, while office personnel prioritize consistency and explainability. That difference itself is natural, but if operations are run without understanding each side’s priorities, the burden will be skewed toward one side. If you demand overly strict organization from the field, actual work will not be able to proceed, and if you leave too much correction to the office, processing times increase and timely use becomes impossible.

Also, on sites where data is not being utilized, operations are run while "who will ultimately use it" remains ambiguous. Whether it will be used for progress checks, for meeting materials, for as-built verification, or handed off to the next process changes what kind of organization is required. If the end user is unclear, neither the items to be collected nor the criteria for organizing them can be determined. As a result, although data accumulates, on-site decision-making continues to rely on traditional experience and phone calls.

To overcome this barrier, it is necessary to design on-site and back-office work as a single workflow. Specifically, measures such as deciding on the minimum ancillary information required at acquisition, standardizing storage rules, setting verification frequency, and tailoring post-processing output formats to be easy for on-site decision-making are important. Finding a middle ground that does not overburden on-site staff nor force excessive corrections on back-office work is the key to achieving operational adoption.

Furthermore, feedback after delivering the data is important. By sharing which data acquisitions were useful, what information was lacking, and which expressions were easy for the site to understand, the quality of the next data acquisition will improve. i-Construction 2.0 is not something that fixes operations once decided; it should be improved through ongoing back-and-forth between the field and office work.

At many sites where digital adoption fails, the issue is not the performance of the equipment but the connection between field operations and office work. As long as data collection and data use remain separated, the benefits of implementation are limited. Conversely, simply bridging this divide can greatly increase the effectiveness of i-Construction 2.0.

Barrier 5: Talent development and operational adoption take time

The fifth barrier is human resource development and operationalization. i-Construction 2.0 does not deliver immediate results simply by introducing an excellent system. To keep it running continuously on-site, to use it for decision-making and reporting, and to link it to subsequent processes, the persons in charge need to have a certain level of understanding and be able to handle it easily within their daily work. However, in actual worksites, staffing is tight and time for training is limited, so this becomes a major barrier.

Particularly problematic is when only a single person understands the system. In the early stages of implementation, an enthusiastic staff member may take the lead in running operations, but if knowledge and procedures become concentrated in that person, the moment they take vacation, are transferred, or their responsibilities change, operations are likely to stop. Operations that depend on individuals may seem to be working in the short term, but they have low continuity and are difficult to scale or replicate across the organization.

Also, the difficulty of developing human resources is not simply learning how to operate equipment. Under i-Construction 2.0, it is important to work with an understanding of why the data is needed, which process it will be used in, and what level of accuracy is required. Teaching only the operations leaves people unable to respond to unexpected site conditions, and operations will break down if conditions change even slightly. In actual practice, understanding the way of thinking is required more than memorizing procedures.

Another difficulty is the wide range of people who need to be trained. Alignment is required not only among on-site personnel but also managers, back-office staff, partner companies, and sometimes the client. It isn’t necessary for everyone to understand things to the same depth, but if you don’t clarify the minimum level of understanding required for each role, the burden of explanations will only increase. On site, communication easily breaks down—either because there are too many technical terms to convey, or because things are oversimplified and misunderstood—which makes operational adoption difficult.

Another factor that prevents operational adoption is expecting too much idealism during the early stages of implementation. If you aim for perfect data capture, perfect organization, and perfect integration from the outset, those on site will become exhausted. To embed a new operation into daily work, it is important to start by accumulating minimal successful experiences. For example, regularize only the scope used for progress checks, organize only the items used for as-built verification, or standardize the operation for only specific trades — demonstrating results in small units is effective.

Also, there are cases where training materials and operational procedures are not tailored to the field. If explanatory materials are too concept-centered, staff cannot translate them into their own tasks. Conversely, if they only provide detailed operational instructions, people will not understand why the procedures are necessary and will lack flexibility in applying them. What is needed is documentation organized in the context of actual work—step-by-step procedures aligned with on-site workflows, common failure examples, checkpoints, storage rules, decision criteria, and so on. It is important that these be in a form that can be referenced on site, even if brief.

In personnel development, designing to tolerate failure is also essential. In new operations, it is rare that everything goes well from the start. The more a workplace treats small failures—omissions, storage errors, inconsistencies, and insufficient explanations—not as occasions for blame but as material for improvement, the more likely the change is to take root. Conversely, if a single failure leads to the conclusion "it's too difficult after all" or "the traditional way is faster," the opportunity to implement it is lost.

The real challenge of i-Construction 2.0 lies not in introducing technology but in embedding it into on-site practices. Training does not end with a single briefing; it is a continuous effort to deepen understanding while running operations. It is natural that developing personnel and achieving operational adoption take time, and if you implement it without including that in the plan, the site will inevitably struggle.

Barrier 6: Inability to design for starting small causes loss of overall optimization

The sixth barrier is the inability to design for starting small. Because i-Construction 2.0 covers a wide scope, people tend to think at implementation, "I want to put everything in order at once." From initial surveys, construction management, as-built results, progress sharing, reporting materials, to maintenance coordination, it would be ideal to upgrade everything in one go. However, considering actual site conditions, optimizing all processes simultaneously from the start is extremely difficult.

At sites where implementation falters, an overly grand ideal multiplies preparatory items, prolongs stakeholder coordination, and ultimately prevents any area from being executed thoroughly. An overall design is necessary, but the entry point for execution must be narrowed. If you target all work types, the entire scope, and all deliverables from the start, acquisition rules, training content, and verification methods become more complex, and those responsible cannot keep up with understanding.

Also, at sites where you can’t start small, it becomes difficult to see the cost-effectiveness. While the initial implementation burden is large, it’s unclear which parts produced the effect, making it hard to decide whether to continue. From the on-site staff’s perspective, all that remains is the impression that their workload has increased, and they don’t feel any improvement. As a result, even if you try to roll it out to the next site, it’s difficult to obtain a positive evaluation.

Designing to start small doesn't simply mean shrinking the scale. It means, with the big picture in mind, beginning with the parts that are most likely to deliver impact and to become established. For example, you might limit the scope to what is used for daily progress checks, target only processes that frequently require rework, or start with trades that involve few stakeholders—choosing an entry point that balances on-site burden and effectiveness. With this mindset, it becomes easier to expand the insights gained from the initial rollout to subsequent stages.

Moreover, starting small does not mean abandoning overall optimization. Quite the opposite. Rather than expanding abruptly and risking failure, it is better to lock down operational rules, handling of coordinates, storage formats, training content, and verification procedures within a limited scope, as this increases reproducibility when scaling up later. Overall optimization is not something you create all at once; it is approached by accumulating small successes.

Behind this barrier there is also the implementer’s sense of responsibility. Because they want to show significant results and visible change both inside and outside the company, they sometimes expand the scope too widely. However, for i-Construction 2.0, continuity is more important than presentation. If it is not a system that actually runs on site, no matter how grand the initial plan, it is meaningless.

What matters in practice is not "how far you go" but "what you can reliably manage." Only by narrowing the scope, verification frequency, output content, responsible personnel, and storage method will operations on the ground become sustainable. If you cannot design to start small, implementation will remain an ideal. Conversely, workplaces that can build up small, focused successes are more likely to achieve significant change.

Approach to Successfully Implementing i-Construction 2.0 on Construction Sites

So far, we have examined the six common barriers encountered when introducing i-Construction 2.0 on site. So, what mindset is necessary to actually move the implementation forward? The important point is to view i-Construction 2.0 not as a competition to adopt the latest technology, but as a business process improvement to make on-site decision-making faster, more accurate, and highly reproducible.

The first important step is to break down the purpose of the implementation to the level of individual processes. The broad phrase "improving productivity across the entire site" does not translate into concrete actions. In which process, which checks, and how much faster do you want them to be carried out? Which document-preparation burdens do you want to reduce? Which rework do you want to cut down? Only when you make it that specific will the necessary data and operational rules become clear.

Next, it is important to consider data acquisition and utilization together. Rather than collecting data just because it can be collected, you need to shift to a mindset of collecting data in order to use it. To that end, it is effective to decide at the point of acquisition the storage format, naming conventions, how to handle coordinates, verification methods, and the intended recipients for handover. If you can create a workflow in which data acquired on site directly feeds into office work and management decisions, the value of i-Construction 2.0 will be greatly increased.

Also, clarifying accuracy requirements is essential. If you try to treat everything at the highest level, the burden on the field increases and operations become unsustainable. It is realistic to determine the quality needed for each application and design without excess or shortfall. What matters is whether it is sufficient for the purpose, not high precision for its own sake.

Moreover, it is necessary to aim for operations that continue to function even when the person in charge changes. Document procedures, naming rules, storage locations, verification frequency, role assignments, and so on; reducing dependence on specific individuals is a condition for continuity. Training should include not only operational instructions but also the background understanding of why those operations are necessary, which enhances on-site adaptability.

And the implementation should always start small. It is realistic to begin with the parts where the impact is most visible and stakeholders can most easily understand, and to expand while organizing outcomes and challenges. Keep the overall picture in mind, but make the entry point small. This approach will ultimately lead to overall optimization.

On site, the ability to handle position information accurately forms the foundation of many processes. In investigation, surveying, construction, as-built verification, and maintenance management alike, positional deviations lead to differences in judgment. In that sense, for i-Construction 2.0 to function on site, it is important to establish a position information acquisition environment that is easy to use, easy to carry, and easy to integrate into practical work. Rather than forcing complex mechanisms, preparing tools and procedures that site personnel can handle within their daily workflow makes adoption outcomes more stable.

Summary

The challenges of i-Construction 2.0 are not simply about whether new technologies can be mastered. There are six major barriers faced when introducing it on-site: the tendency to begin implementation with unclear objectives; the difficulty of meeting the prerequisites for data acquisition in the field; rework caused by insufficient understanding of coordinate systems and accuracy requirements; the division between on-site work and office work that prevents data from being effectively used; the time required for human resource development and operational adoption; and the ease with which overall optimization is lost because projects cannot start with small-scale designs.

What these barriers have in common is that they raise questions about how workflows are linked and how operations are designed, rather than the performance of equipment or software. i-Construction 2.0 will not become established merely by swapping out tools. It is important to clarify what you want to improve on-site, acquire the necessary data at the required quality, format it so it can be used for decision-making and sharing, and put operations in place that will continue to run even when personnel change.

Especially in practical work, not leaving the handling of location information ambiguous is the starting point for successful adoption. If the basic actions of measuring, recording, sharing, and verifying are not accurate, no matter how advanced the initiatives, they will not be effective in the field. That is why creating an environment where location information can be handled seamlessly in daily operations is crucial.

If you are going to proceed with on-site implementation, it is recommended to first review and ensure reliable position acquisition and sharing. LRTK, as an iPhone-mounted high-precision GNSS positioning device, is a good option for situations where you want to advance the use of high-precision location information in a form that is easy to handle on-site. For field personnel who want to streamline daily workflows of positioning, recording, and verification before deploying a large-scale system all at once, it can serve as an effective first step to steadily establish i-Construction 2.0 on-site.