Why Construction Management Can’t Trust Manually Collected Data

[ad_1] As someone who has developed management software, I know how challenging it is to motivate knowledge workers to manually ...
builderkp

[ad_1]

As someone who has developed management software, I know how challenging it is to motivate knowledge workers to manually enter data accurately and on time, or even at all. On a construction site, the challenge is even greater, and quite understandably so.

These were my initial thoughts after reading the latest research report from the Building 2030 consortium, “Measuring the performance of takt production,” by Aalto University researcher Jaakko Riekki and professor Olli Seppänen.

More data, better control?

Finland is a global leader in takt production in construction. The Building 2030 has, for 10 years now, been a leading researcher and promoter of takt. Consequently, hundreds of projects have implemented the lean construction method, and with great results: better control, shortened lead times, and consistent quality. However, situational awareness of takt projects still needs improvement.

Construction companies investing in takt production often assume that more data automatically means better control. The Aalto University study suggests otherwise. The researchers examined data quality across eight real-world takt construction projects and found that most sites still cannot produce reliable performance metrics, even when takt scheduling software is in place.

The study’s premise is well known in management theory. You cannot manage what you cannot measure, and you cannot measure what your data doesn’t capture. The eight cases varied in size, takt time, building type, and the experience level of site management, providing the researchers with a useful cross-section of current practice rather than a single best-case example.

The schedule data paradox

Schedule monitoring data was the most readily available data type across all eight projects, which makes sense given that it requires the least additional effort to collect. Yet even this best-case data source had real limitations. Software systems typically log the timestamp when a task was marked complete in the system, not when the work physically finished on site.

This distinction matters a great deal in this case. If a task wraps up in the afternoon but isn’t logged until the following morning, every downstream metric inherits that distortion.

The researchers also identified a trade-off between granularity and accuracy. Shorter takt times enable finer-grained tracking, but they increase the risk of logging errors and cause metrics to fluctuate unpredictably. Larger batch sizes stabilize the numbers, but they smooth over the very deviations a site manager would want to catch early.

Resources, quality, and improvement data were barely usable

Beyond schedule tracking, the picture got considerably worse. Actual resource use, meaning who worked on what and for how long, was rarely logged consistently enough to calculate any resource performance metrics. This was true even though most takt software technically supports detailed, time-stamped logging through individual user accounts.

Quality and deviation data existed in every case, but it was scattered across disconnected tools, spreadsheets, to-do apps, sticky notes, and personal notebooks, with weak links back to the actual takt schedule. All eight projects used the same tool for quality management, yet the information stored there proved difficult to connect to takt area data and hard to analyze in a structured way.

Continuous improvement data was the weakest category overall. None of the eight cases had systematic records of improvement actions, even though workshop participants assumed informal improvement was occurring on site in various forms.

When learning isn’t documented in a structured way, it remains locked in individual experience and never becomes organizational knowledge. That’s a significant loss for companies that run similar projects repeatedly, since each new site effectively restarts the learning process from scratch.

A sobering assessment

The researchers rated each project’s data-driven management maturity on a scale of 1 to 5, using subjective judgment. The results were stark. Across all eight cases, the statement “metrics were used in decision-making” received a 1 out of 5, the lowest possible rating, with no exceptions.

Production forecasting based on data also scored 1 across all projects. Only the most experienced and well-resourced site, a 95,000-square-meter new-build with a one-day takt time and a seasoned management team, showed meaningfully higher scores in planning discipline, integrated technology platform use, and staff training. Even there, metrics-driven decision-making and forecasting still failed to materialize in practice.

Metrics that looked useful, until you tried to use them

The researchers tested three schedule-based metrics across four cases: completion rate of the previous takt cycle, cumulative completion versus plan, and the punctuality of task starts and finishes. Each told a slightly different story, and none told the full story. A project could show a healthy cumulative completion curve while its previous-cycle completion rate looked chaotic, simply because of how and when workers logged their progress.

Punctuality metrics often painted a calmer picture than other indicators, showing average delays of just a few takt cycles, while individual task-level data concealed much larger outliers buried in the averages.

This pattern repeated across cases. Aggregate metrics appeared reasonably stable, but the underlying spread at the individual task and takt area levels was often wide, masking real problems in specific zones or work types.

The chicken-and-egg problem

The report identifies the core obstacle directly: a chicken-and-egg problem. Site teams won’t invest effort in detailed data collection if they don’t see clear value in the resulting metrics, yet metrics can’t be developed, validated, or trusted without a sufficient base of good data to begin with.

Logging is extra work for takt leaders already managing a demanding daily schedule, and the benefits of that extra effort rarely appear within the short-term horizon that drives daily site decisions.

This isn’t primarily a software limitation. It’s a process and incentive problem, and better tools only help if accurate data collection is built into normal takt control rather than an optional add-on nobody has time for.

What this means for decision-makers

The practical implication is sobering for anyone buying or selling takt software on the promise of real-time dashboards. The report found that even when interactive dashboards existed, including a prototype built during this research, their usefulness depended entirely on the quality of the underlying data and the organization’s willingness to act on it. A polished interactive view built on incomplete or inconsistent logs offers false confidence rather than real insight.

If your organization wants genuine data-driven takt or any form of project management, the starting point isn’t analytics software. It’s disciplined data collection at the takt area and takt time levels, paired with software designed to make accurate logging effortless rather than optional. Without that foundation, every metric built on top of it remains, at best, a rough approximation of what actually happened on site, and, at worst, a confident-looking number that misleads decision-makers.

Where this is headed

My take on the results is also noted in the report: automate data collection and free people to do the value-adding work, rather than document everything manually. We already have the technology to do that: cameras, sensors, robots, and so on. AI will help tremendously in getting there.

The research report is available for download in Finnish.

[ad_2]

This article was originally posted at Source link

Leave a Comment