7 Precautions to Avoid Failure When Introducing i-Construction

Contents

• Reasons why failures tend to occur when introducing i-Construction

• Precaution 1 Do not introduce it while leaving the purpose vague

• Precaution 2 Do not start with devices or software without整理ing the site workflow

• Precaution 3 Do not leave it to only a few people and create person-dependence

• Precaution 4 Do not postpone deciding how to create data and handover rules

• Precaution 5 Do not roll it out across the whole project without trying small pilots first

• Precaution 6 Do not underestimate training and operational stabilization

• Precaution 7 Do not proceed without deciding evaluation criteria after introduction

• What is needed to avoid failure is design ability more than technology

Reasons why failures tend to occur when introducing i-Construction

i-Construction has been spreading as an indispensable approach to improve productivity, ensure quality, enhance safety, and address labor shortages at construction sites. Because it requires connecting processes such as surveying, measurement, design, construction, inspection, and maintenance with data and improving the overall site workflow, it differs from simply introducing new devices or achieving temporary efficiency gains. For that reason, even if the introduction itself succeeds, failures often occur in the form of not achieving the expected results.

When practitioners search for "iconstruction", they are often anxious about what they need to prepare, where to start, and whether it will actually work on site. In many actual sites, although the necessity of introduction is understood, preparations that consider operation are insufficient and things proceed anyway. As a result, issues surface such as: people have learned how to use the devices and software but the work has not become easier; data has increased but processing effort has risen; methods differ by site so data cannot be reused.

What should really be avoided when introducing i-Construction is not the technical difficulty itself. Rather, the biggest cause of failure is advancing partial introductions without first establishing purpose setting, organizational structure, data handling, training, and evaluation mechanisms. In other words, to avoid failure you need a perspective of redesigning the site’s workflow, not just adding new means to the site’s existing work.

Also, i-Construction does not produce immediate results just because it is introduced. Old and new methods will coexist for a while, and there may be periods where the workload actually feels heavier. How you navigate this transition phase largely determines whether the approach becomes established or becomes a mere formality. The busier the site, the more likely immediate tasks are prioritized and framework creation is postponed. If you underestimate this, the effects of the introduction will be hard to achieve.

This article organizes and explains seven precautions to keep in mind to avoid failure when introducing i-Construction. None of them are special theories; they are typical practical issues where people tend to stumble. These points are useful as review criteria not only for those about to advance introductions, but also for those who have already started yet feel the results are weak.

Precaution 1 Do not introduce it while leaving the purpose vague

A common early failure in introducing i-Construction is that the introduction becomes an end in itself. If you proceed only because others are doing it, because your company seems to need to respond, or because it might be necessary in the future, the improvements sought at the site will remain vague. If you begin introduction in such a state, decision criteria will fluctuate along the way and, in the end, each measure tends to be half-baked.

The true starting point for an introduction is to verbalize what is causing trouble in which process. For example, is current condition verification taking too long? Are there many reworkings for as-built confirmations? Is a lot of manpower spent on creating forms? Is information sharing between the site and the office slow? Depending on these, priority actions differ. If you advance without clarifying the purpose, the site’s problems and the introduced content will not align, and you may end up having added features that only look useful.

What matters in setting the purpose is not to leave it as an abstract expression. Phrases like “we want to increase productivity” or “we want to reduce labor” alone cannot guide on-site decisions. Only when you break them down to which task time you want to reduce, which process errors you want to reduce, or which staff burdens you want to ease does the introduction content gain meaning. If site and management do not align on objectives, management may require data utilization while the site seeks workload reduction, creating a mismatch that hinders operational establishment.

Moreover, you do not have to limit the objective to a single item, but you should set clear priorities. Trying to solve everything from the start expands the introduction scope and makes preparation and training unmanageable. First, identify which basic actions—measuring, recording, sharing, or confirming—you want to improve, and create an initial success pattern. When the purpose is clear, it becomes easier to judge results after introduction and to connect to the next expansion.

To avoid on-site failure, before introduction you should be able to explain in one sentence “what you want to change with this initiative.” If that sentence remains vague, policies will swing midway and the introduction will depend on individual interpretations. i-Construction is a means; defining the purpose first is the first step to avoiding failure.

Precaution 2 Do not start with devices or software without整理ing the site workflow

When people become interested in i-Construction, they tend to focus on the selection of devices and software first. However, considering devices or software before整理ing the site workflow increases the risk of choosing solutions that do not fit the site. In particular, products that seem convenient in exhibitions or explanations may have limited practical uses on the actual site or may connect poorly with existing tasks, preventing widespread utilization.

To avoid failure, you must first整理 site operations by process. It is important to visualize who acquires what information, when and where, to whom they hand it over, and what it is used for. Without understanding this flow, you cannot see where digitalization will be effective or where new overheads will appear. On site, tasks do not exist in isolation but within links between upstream and downstream processes. Ignoring this and pursuing only local optimization can make the whole system inefficient.

For example, even if measurement tasks on site become faster, if subsequent organization, conversion, or confirmation takes extra time, overall efficiency will not improve. Conversely, small changes in on-site acquisition methods can greatly improve processing and sharing in the office. Thus, the important question is not the excellence of individual functions but whether they work within the entire workflow.

Also,整理ing the site workflow reveals the necessary level of introduction. Often there is no need to aim for highly advanced systems at the outset; substantial improvements can come from basic preparations such as increasing recording accuracy, stabilizing the handling of positional information, or speeding up stakeholder sharing. Nevertheless, choosing a multi-functional configuration from the start can complicate operations and result in staff being unable to master it.

In practice, before selecting devices or software, it is important to inventory a day’s flow at the site, the flow of a single trade, and the flow until a single deliverable is completed. Based on that, identify which parts to change to achieve the greatest overall effect—this leads to an introduction that avoids failure. Functionality that looks attractive is far less important than what can be seamlessly integrated into daily work.

Precaution 3 Do not leave it to only a few people and create person-dependence

At sites where i-Construction introductions fail, it is often the case that work concentrates on one knowledgeable person. It is not bad per se for people skilled in new technologies, adept at data processing, or familiar with device operation to lead the effort, but if only that person understands the system, the introduction becomes volatile. If the responsible person gets busy, is transferred, or is absent, operations stop.

The problem of person-dependence is not merely about lack of manpower. The issue is that operational procedures, decision criteria, and troubleshooting knowledge exist only in individuals’ heads. In this situation, methods vary by site and reproducibility is lost. When similar projects vary in quality or speed depending on the person, the organization cannot build cumulative capability. One of the core values of i-Construction is stabilizing the site with data and systems rather than relying excessively on individual skill. If the introduction itself becomes personally dependent, it defeats the purpose.

To avoid failure, while assigning promotion staff, create a structure in which site personnel, management personnel, and confirmation personnel share at least a common understanding. Clarify what each role needs to be able to do; although not everyone needs the same depth of knowledge, the basic workflow should be shared at minimum. Simply having common knowledge about how on-site collected data will be used, what must be checked to avoid problems downstream, and where to look when anomalies occur will greatly stabilize operations.

Also, preventing person-dependence requires more than just creating manuals. In practice, there are many exception cases and judgment points that paper manuals cannot keep up with. What matters is sharing typical stumbling blocks in a manner tied to actual practice and making sure they can be handed over along the real workflow. Commonize details that affect operational quality—how to handle site photos, how to verify coordinates, where to save deliverables, naming rules, and pre-submission checks.

In the early stages of introduction, it may seem faster for one expert to proceed alone. However, that approach will not last. Stability and sustainability are more important than speed of introduction. To root i-Construction as a standard site operation, consciously build systems that do not depend on individual abilities.

Precaution 4 Do not postpone deciding how to create data and handover rules

In i-Construction, data becomes the core of operations. For that reason, if you proceed with unclear rules for how to create data and how to hand it over, the site quickly falls into confusion. The site may be able to measure but the data is unusable later; data thought to be acquired cannot be found; inconsistent names make organization time-consuming; it is unclear which file is the latest. These issues usually arise not from device performance shortfalls but from lack of operational rules.

Particularly important is realizing that having data and having usable data are different things. With i-Construction, more data acquisition can give a false sense of security, but unorganized data becomes a burden. Data lacking metadata such as acquisition date and time, location, target, person in charge, and purpose are difficult to reuse and often end up being one-off. Even after digitization, repeating the same checks prevents productivity gains.

To avoid failure, decide minimum data rules before introduction. Specifically, organize what data to retain at which stage, where to store it, how to name it, how to manage revisions, and who performs final verification. This may seem mundane, but it actually determines introduction success.

Also, rules that end within the site are meaningless. Make the operation feasible for all stakeholders including office staff, subcontractors, and management. If it is easy to save data on site but hard to find in the next process, its value is limited. Conversely, rules that are too detailed to suit management convenience can lead to perfunctory records the site cannot maintain. The key is a balance: executable at the site while preventing confusion downstream.

You do not need to aim for perfection in data operations from the start, but beginning with no rules is dangerous. Smaller sites may initially rely on verbal or tacit knowledge, but as introduction scales, this approach will fail. Deciding how to handle data is not merely for control; it is to make assets usable on future sites. To prevent i-Construction from becoming a one-off effort, organize how data is created and flows at an early stage.

Precaution 5 Do not roll it out across the whole project without trying small pilots first

The stronger the intention to advance i-Construction in earnest, the more you may want to expand it across the entire project from the beginning. However, if you simultaneously introduce it to multiple sites or processes before preparations are ready, it becomes hard to separate and diagnose issues and failure becomes more likely. If only a sense of burden remains without knowing where you stumbled, the site’s impression will be negative and further expansion will be difficult.

To avoid failure, first test in a limited scope to verify whether it fits actual work. Narrow down the target process, run it in a single workflow, and check where time is spent, who is troubled, and what is lacking. At this stage, finding problems early is more important than producing impressive success stories. Exposure to burdens and failures during trial is not bad; it is a valuable opportunity to fix things before full-scale introduction.

Starting small makes it easier to concentrate training and support. If you involve many people from the first time, differences in understanding will consume time just on basic operations. Running with a limited team reveals the explanations needed and common on-site mistakes. Using these insights to refine procedures before wider rollout speeds adoption at the next site.

Also, phased introduction helps assess return on investment. If you can see what works and what doesn’t, you can judge which areas to expand next. Conversely, an immediate full rollout mixes introduction effects and costs together, making them hard to evaluate; the site may then feel “it just became harder,” and the technology may be unfairly judged. This undermines positive organizational assessment even if the technology itself is fine.

When advancing step-by-step, choosing which site to pilot is also important. Sites that are too difficult make problems overly complex; sites that are too easy may obscure practical issues. Choose a moderately standard site and verify operations under conditions close to real work. Always document the trial results in words and reflect them in subsequent introductions. Starting small is not detouring; it is the shortest route to reducing total failure.

Precaution 6 Do not underestimate training and operational stabilization

When device and software preparations for i-Construction are complete, it may feel like half the job is done. However, the aspect that actually determines results is the subsequent training and operational stabilization. If these are insufficient, the introduced system will either not be used or will be used but remain ineffective. In particularly busy sites, reverting to old methods is a strong tendency, and new operations will not take root unless adoption is intentionally reinforced.

A common training failure is stopping at operation explanation. Basic operation is of course necessary, but that alone does not convey why the site should continue using it. If people cannot understand why a task is necessary, how an input helps downstream, or what is better than the previous way, they will be prone to omit steps in busy situations. People find it hard to keep doing tasks that lack apparent meaning. Therefore, training must convey not only operating methods but also the position of that work within the overall workflow.

Training is not a one-off. Even if participants understand initially, practical use brings up many detailed questions. Without a system to consult, self-directed methods increase and site-to-site differences widen. During the initial uses, it is important to support on-site usage, observe, and correct common stumbling points. For operational stabilization, initial hands-on support often works better than a one-time briefing.

Also, do not limit training targets too narrowly. Not only the operators but also those who confirm, receive, and make decisions need a certain level of understanding. Even if the site struggles to prepare data, if receivers do not understand how to use it, they may still demand conventional documents, causing duplicate work. Such a situation prevents the site from positively embracing the new operation. Company-wide understanding is indispensable for adoption.

To stabilize operations, adjust the process so it is maintainable by the site rather than imposing an undue burden. Regularly review whether input items are too many, whether confirmation procedures are too complicated, or whether storage methods are confusing, and simplify to a level the site can naturally continue. i-Construction does not generate value the moment it is introduced; its effects appear only after repeated on-site use. Underestimating training and stabilization halts progress at the gateway.

Precaution 7 Do not proceed without deciding evaluation criteria after introduction

It is not uncommon for high expectations before introduction to be followed by the feeling “I’m not sure if it went well” afterward. One cause is proceeding without deciding evaluation criteria. Without metrics, the impression that on-site burden increased can dominate and improvements become hard to see. Conversely, some measures may increase temporary effort but show mid- to long-term effects, but without criteria you cannot judge this.

To avoid failure, decide before introduction what will constitute success. For example, consider whether on-site confirmation time shortened, whether re-measurements and rework decreased, whether record-creation time reduced, whether time to share information shortened, or whether staff travel and waiting decreased. Important is having both indicators that the site can feel and indicators that management can explain.

Evaluation by simple work time alone is insufficient. The value of i-Construction includes quality stabilization, faster decision-making, easier information sharing, and future reuseability. Even if the same time is required in the short term, improved confirmation accuracy and fewer backtracks are meaningful. Conversely, if on-site tasks appear faster but downstream corrections increase, it is not a true improvement. You need an evaluation that looks at the entire process.

Another meaning of deciding evaluation criteria is clarifying improvement priorities. When issues are found after introduction, it becomes easier to judge where fixing will have the greatest effect. If evaluation is vague, improvements are swayed by the loudest voices or immediate impressions, causing direction to wobble, and valuable experience will not feed into future introductions.

Moreover, share evaluation results with the site. Site personnel are sensitive to immediate workload but may not see overall improvements. Therefore, it is necessary to share what has improved and what still remains an issue, and to take an attitude of developing operations together. Having evaluation criteria is not merely for reporting; it is the foundation for turning introduction into a continuous improvement activity.

What is needed to avoid failure is design ability more than technology

We have reviewed seven precautions to avoid failure when introducing i-Construction, and a common theme is that many failures arise not from lack of technology but from inadequate introduction design. Starting without a clear purpose, failing to整理 workflows, allowing person-dependence, not deciding data rules, not piloting small, underestimating training, and lacking evaluation criteria—these all tend to occur when pre- and post-introduction design is weak.

i-Construction is not simply bringing new devices or digital methods to the site. It is an initiative to change how information is handled across surveying, construction, inspection, and maintenance. Therefore, the key to success is not flooding the site with advanced technology but building a mechanism that runs smoothly in a form suited to your company’s sites. What matters most is that it continues at the site, is reproducible, and can be applied to the next project.

For practitioners, creating a big-looking introduction is less valuable than reducing site problems one by one. Reducing the burden of repeatedly returning to the site for confirmations, cutting the toil of records and sharing, reliably preserving data including positional information, and speeding up decisions—these daily improvements cumulatively approach the essence of i-Construction.

When considering on-site use, the reliability of positional acquisition and recording is also an important element. Especially in tasks involving positioning and position verification, it is not enough to merely record data; the quality of records in terms of usable accuracy later determines operational quality. In such cases, choose means that are easy to handle on site and that can be incorporated into daily workflows. iPhone-mounted GNSS high-precision positioning devices like LRTK are well suited to situations where you want to manage photos and positional information together on site, and represent one practical option to advance i-Construction at the operational level. Rather than starting from large-scale systems, first equip tools that can be reliably used on site—this leads to an introduction that avoids failure.