How should i-Construction 2.0 be advanced? Five perspectives to consider when implementing it

In the construction industry, multiple challenges are progressing simultaneously, such as labor shortages, skills transfer, ensuring safety, work style reform, and increasing demand for maintenance and management.

Against this backdrop, i-Construction 2.0, as a concept for further advancing the digitalization of construction sites, is attracting attention. Rather than pursuing partial optimizations like simply introducing equipment or merely streamlining surveying, it is important to review construction, construction management, and data integration as a whole and transition to a system that can reliably run worksites with fewer personnel.

On the other hand, from the perspective of practitioners, hearing "i-Construction 2.0" often does not make it clear where to start. If introducing a new framework becomes the goal in itself, it can actually increase on-site workload, create duplicate operations with existing tasks, and make results harder to see. To succeed in implementation, you need not merely to follow the terminology of the system, but to adapt it to your company's operations and concretely specify which processes to change, in what order, and at what level of granularity.

This article outlines five perspectives that practitioners who are gathering information by searching "iconstruction 2.0" should keep in mind when advancing i-Construction 2.0. It provides clear, practical explanations of points that are easy to stumble over during on-site implementation, points that are easy to overlook during internal rollout, and operational points that tend to create differences after implementation.

Table of Contents

• Basic Points to Grasp Before Understanding i-Construction 2.0

• Perspective 1: Define the purpose as business transformation rather than equipment introduction

• Perspective 2 Design the data flow first

• Perspective 3: Decide the scope of deployment by operational unit rather than by site

• Perspective 4: Build a system that can achieve both labor reduction and quality assurance

• Perspective 5: Have evaluation metrics that can be started small and continuously improved.

• Summary

The basics to grasp before understanding i-Construction 2.0

What you should first understand when advancing i-Construction 2.0 is that this is not a one-off technology introduction measure. Conventional site improvements tended to focus on individual changes—speeding up measuring tasks, making photo organization easier, and streamlining as-built verification. What i-Construction 2.0 demands, however, is a comprehensive review of how construction is carried out, how information is handed over, and how management is conducted, so the entire site can be operated with less burden.

In other words, the scope of implementation isn’t limited to equipment and software. It should also include business procedures, allocation of responsibilities, record-keeping methods, verification methods, and training. If you misunderstand this and only partially digitize while leaving traditional paper-based operations and person-dependent communication systems intact, you won’t achieve the expected results. Instead, you’re likely to end up in an inefficient situation where records are kept both on paper and as data and verifications are performed twice.

Also, while i-Construction 2.0 tends to attract attention mainly for labor reduction, improvements in safety, reproducibility, and explainability are just as important in practice. The ability for work to be performed with consistent quality even when personnel change, the reduction of entry into hazardous areas, and the ability to trace records later to explain the basis for decisions are major factors that support the benefits of adoption. Therefore, it is important to view it not simply as a mechanism to reduce headcount, but as building a foundation that makes site operations sustainable while maintaining quality.

Perspective 1: Define the Objective as Business Transformation, Not Equipment Deployment

The first perspective to look at when introducing a system is goal setting. What matters here is to think not about “what to buy” but about “which operational challenges to change and how.” On-site, the more a new system is introduced, the more people tend to start by talking about device performance and features. However, what will determine the success or failure of i-Construction 2.0 is not the equipment’s specifications but whether the objectives for introduction are defined in terms of operational improvement.

For example, simply saying you want to speed up surveying is not enough. You need to break down which step of the surveying process is taking time: on-site time, rework checks, organizing coordinates, or the task of matching with photos. Similarly, even when you want to streamline construction management, the measures required will vary greatly depending on whether progress tracking takes a long time, organizing records for as-built verification is burdensome, or there is waste in creating internal reporting materials.

If you proceed with implementation while leaving this unclear, you are likely to end up in a situation where useful functions have increased but the burden felt by frontline staff has not decreased. From the perspective of those responsible for operations, it is important to first write down where in current processes there is waste, variability, reliance on specific individuals, waiting time, and rework, and then clarify what you want to reduce, what you want to speed up, and what you want to standardize.

Furthermore, make the implementation objectives as much as possible in terms that can be measured on site, as this makes operations easier. For example, reduce the number of on-site checks, shorten the time spent organizing records, reduce rework in as-built verification, suppress variability in coordinate checks, and reduce the burden of managers' patrols. If you can express them this way, it will be easier to verify effectiveness after implementation and to obtain internal approval.

i-Construction 2.0 is not an achievement in itself. The real outcomes are how existing operations have changed, which on-site burdens have been reduced, and what has become more stable. That is precisely why setting the initial objectives from the perspective of operational transformation is the most important first step.

Perspective 2: Design the data flow first

The second perspective is to avoid putting off consideration of the data flow. On site, the tendency is to enable measurement, photography, and as-built verification first, and only afterward think about how to organize the data. However, under i-Construction 2.0, if it isn’t clear who will use the data, where, in what format, and how after the data are acquired, the hard-won digitization will stall on site.

For example, even if you have on-site location data, photos, point clouds, and progress records, if they are in formats that are hard to share internally, difficult for reviewers to view, or cannot be reused in other processes, the information will accumulate without being put to use. Data that only field staff understand, or data that remains only on staff devices, will not directly lead to improved productivity across the organization.

Therefore, at the time of implementation, you need to first map out the entire flow of acquisition, storage, sharing, validation, and reuse. Clarifying when data will be collected, who will perform the initial verification, which units to use for naming, where data will be consolidated, and what it will be used for in downstream processes reduces operational uncertainty. Conversely, if this is left unclear, storage locations and naming conventions will vary by site, creating problems such as being unable to find, compare, or leverage the data later.

Also, when designing data flows, it is important not to try to create a perfect system from the outset. In practice, it is easier to achieve adoption if you first decide on the minimum fields to collect, keep the recording rules concise, and design the process so it can be continued on-site without undue effort. If there are too many recording items, the data entry burden increases and omissions ultimately rise. A design that reliably preserves the necessary information has more practical value than one that merely looks sophisticated.

i-Construction 2.0 is not about collecting data for its own sake. Data only becomes meaningful once it is put into a state that can be used for subsequent decision-making, management, and explanations. For that reason, it is important to design the flow of data from the early stages of implementation and to avoid creating breaks in information between the field and management.

Perspective 3: Determine the scope of implementation by operational unit rather than by worksite

The third perspective is how to determine the scope of implementation. A common failure is optimizing by looking at only a single site, which may work at that site but cannot be reproduced at other sites. If you truly want to advance i-Construction 2.0, you should not stop at site-level ingenuity; you need to consider the scope of implementation in operational units that can be standardized across multiple sites.

It is natural that conditions differ from site to site. Terrain, scale, type of work, and contract conditions vary. Nevertheless, there are parts that can be standardized. For example, how coordinates are handled, how records are kept, the frequency of progress checks, how photos are linked with location information, preparations for as-built verification, and the format of internal reports can be standardized to a certain extent. Leaving these matters up to each site causes methods to change whenever the person in charge changes, increasing both training costs and handover costs.

When considering the scope of implementation, first divide your company’s operations into operational units such as measuring, checking, recording, sharing, and reporting — this makes it easier to organize. On that basis, it is important to determine which units can be operated commonly across multiple sites. If you standardize the parts that can be shared first, it becomes easier to maintain operational quality even if equipment changes or personnel change.

Also, deciding the scope of implementation by operational unit makes investment decisions easier. Improvements that only work at a specific site may be difficult to approve, but operational improvements that are expected to deliver the same effect across multiple sites are easier to gain internal agreement on. In particular, for initiatives that assume continuous operation, such as i-Construction 2.0, creating mechanisms that can be deployed across sites is more valuable than one-off success stories.

As a practitioner, even if you try it out at a single site, it is important to be mindful of horizontal rollout from the start. Whether it will be a special-case operation only for this site or a prototype for future standard operations will change how you keep records and how you evaluate them. To steadily advance i-Construction 2.0, it is essential to adopt a perspective that considers site implementation and standardization together rather than separately.

Perspective 4: Build a system that can achieve both labor reduction and quality assurance

The fourth perspective is building the organizational structure. When it comes to i-Construction 2.0, attention tends to focus on running sites with fewer people, but what matters in practice is reconciling labor reduction with quality assurance. Even if you reduce headcount, if insufficient checks or judgment errors increase, you will stray from the original objective.

What is needed here is not a design that reduces personnel, but a design that narrows down the points people should check. Instead of having people go see everything on site, replace parts that can be substituted by data and records, and make clear the situations where human intervention is necessary. For example, if routine record collection and the standardization of location-tagged record organization can be achieved, managers will find it easier to focus on handling exceptions and quality checks. Achieving this state is labor-saving in the true sense.

To do that, it is necessary to clarify the division of roles from the outset. If it is unclear who collects the data, who performs the initial verification, and who makes the final decision, the locus of responsibility becomes ambiguous, and ultimately decision-making concentrates on experienced staff. As a result, even if the system appears to have reduced labor, in reality the workload is simply biased toward a few people. This cannot be considered a sustainable arrangement.

Furthermore, from a quality assurance perspective, standardizing training is also important. Even if a new system is introduced, variations in individual operators' levels of understanding will lead to differences in the accuracy of records and decisions. In tasks that handle location information in particular, a basic operational understanding is indispensable: understanding coordinate systems, handling correction information, checking acquisition conditions, and the criteria for deciding whether to remeasure. The more convenient a device is, the simpler its operation may be, but prerequisite knowledge is necessary to use it correctly.

Furthermore, to maintain quality, rules for responding to abnormal situations are also necessary. For example, when communications are unstable, satellite reception conditions are poor, the field environment is harsh, or the acquired data seems questionable, deciding in advance when to stop work, what to check, and how to record it makes it easier to reduce variability in on-site decision-making. Organizing procedures not only for normal operations but also for exceptional cases is the key to making i-Construction 2.0 function in practice.

Perspective 5: Have evaluation metrics that can start small and be continuously improved

The fifth perspective is the approach itself. With i-Construction 2.0, trying to change all processes at once from the start tends to increase the burden on sites and makes it harder for changes to take hold. That is why a realistic way forward is to start small and accumulate improvements incrementally. What is important is not to let pilot implementations remain mere trials, but to have evaluation criteria that lead to the next steps.

When testing a new system on-site, judging whether it succeeded based only on impressions weakens the case for rolling it out company-wide. Evaluations such as “the person in charge found it convenient” or “the site’s impression was positive” are hard to convey to other departments and to management. Therefore, it is important to have metrics that can be compared before and after implementation.

For example, time spent on site, number of revisits, time spent organizing records, time spent preparing report materials, number of missed confirmations, number of rework cases, and number of administrator movements are indicators that are easy to compare. You do not need to measure all of these precisely, but if you at least decide what the target for improvement is and what will be regarded as effective, a trial implementation will lead to the next improvement.

Also, the evaluation criteria should include not only efficiency but also quality and degree of adoption. Focusing only on time savings can lead to a decline in the quality of records and allow a lack of understanding at the site to go unnoticed. Adding perspectives such as whether on-site personnel can continue to use it, whether it is easy to hand over, whether it is easy to train, and whether it is reproducible makes it easier to evaluate it not merely as labor-saving but as strengthening the operational foundation.

Furthermore, the smaller you start, the more clearly you should define the scope of implementation. Instead of covering the entire site, begin by limiting the target tasks—such as positioning record-keeping, progress checks, and as-built verification assistance—so issues become easier to identify. Once issues are visible, the next points to fix also become clear. Repeating this cycle will turn i-Construction 2.0 into on-site implementation.

The approach that succeeds in practice is not a flashy, wholesale rollout but carefully following the sequence of pilot implementation, measuring effectiveness, standardization, and horizontal deployment. In times of rapid change, a mechanism that can be continuously adjusted is stronger than a perfect initial design. The same applies to i-Construction 2.0: it is important to proceed with evaluation metrics on the premise of refining things as you go.

Summary

What matters in advancing i-Construction 2.0 is not increasing the number of new tools but clarifying how to change on-site work. Define the objective as business transformation, design the data flows first, consider standardization by operational unit rather than by site, establish a system that can achieve both reduced staffing and quality assurance, and start small while continuously improving. By keeping these five perspectives in mind, implementation will shift from a one-off initiative to a mechanism rooted in day-to-day practice.

In particular, on future construction sites, the accuracy of location-based records and verifications will increasingly influence both operational efficiency and transparency. Whether you can quickly and accurately capture positions on site and directly leverage that information for construction management and reporting will show up as differences in daily operations. To advance i-Construction 2.0 in the field, it is important to be able to seamlessly integrate these fundamental measurement and recording methods into everyday work.

In that sense, iPhone-mounted GNSS high-precision positioning devices like LRTK are one option that can make on-site handling of location information more accessible and make it easier to take the first step toward adoption. Rather than confining the system to a few dedicated personnel, if it can be used in ways that lead to routine checks, records, and sharing, the concept of i-Construction 2.0 can be more readily embedded into on-site practice. Not merely stopping at following the wording of regulations, changing things one on-site task, one record, and one check at a time will, as a result, bring successful adoption closer.