Your superintendent is managing 40 subcontractors, interpreting drawings under time pressure, making sequencing decisions in real time, and responding to field conditions that were not in the plan. That is genuinely demanding work.

Then someone asks them to log into three different systems, reconcile cost codes across platforms, enter the same change event in both the project management software and the owner’s reporting portal, and generate a status report before Friday.

And then questions arise about why problems slip through.

The cognitive load problem that remains poorly understood

In the 1980s, an educational psychologist named John Sweller developed cognitive load theory to explain why students struggle to learn complex subjects. The core insight was straightforward: working memory, the mental workspace where active thinking happens, is severely limited. Most research suggests it can hold roughly four to seven chunks of information at once before performance degrades.

Beyond that threshold, people do not simply slow down. They make errors. They miss signals. They defer decisions. They fall back on habit rather than analysis.

This model turned out to be useful not just for education but for understanding how construction projects go wrong.

Three types of cognitive load on your project

The first type is intrinsic load, the inherent complexity of the work itself. A superintendent managing a complex site carries a high intrinsic load before they ever open a laptop. The work is genuinely difficult. This is real and unavoidable.

The second type is extraneous load, friction created by poor system design. Duplicate data entry across platforms. Hunting for the correct document version. Reconciling cost codes that do not align between systems. Toggling between tools that do not communicate with each other. This is where most construction technology fails. It adds administrative burden without reducing mental tax. It consumes cognitive bandwidth that could otherwise be directed at the actual project.

The third type is germane load, the productive mental effort of interpreting what the data means and making decisions. This is the only category worth investing in. The goal of any data system should be to reduce the first two types so that people can invest more cognitive energy here.

Every hour a superintendent spends generating a report is an hour they are not spending thinking about what the report should be telling them.

Why construction software keeps getting this wrong

Most construction software was designed by people who understood the information problem but underestimated the cognitive cost of adding one more system to an already overloaded environment.

The pitch is typically: “Our platform gives you better visibility into X.” The implementation reality is: “Our platform requires your team to learn new workflows, enter data in new formats, and attend training sessions, before it delivers any visibility at all.”

The intrinsic complexity of a $200 million hospital project with 80 subcontractors is already pushing the limits of what a project team can manage effectively. Adding extraneous load does not help. It displaces the germane processing, the actual thinking, that would have prevented problems from developing.

This is why the most effective technology interventions in construction are those that require the least behavior change from the people using them. Not another platform. A layer that works with existing tools. Not more data entry. Better synthesis of data that already exists.

What this means for how you evaluate your project team’s tools

As an owner, you probably evaluate whether you are getting the information you need, not whether the technology your project team uses imposes an unreasonable cognitive burden. Those are different questions.

A project team buried in administrative overhead (managing information across six platforms, reconciling reports for five different stakeholders, generating the same status summary in three different formats) is a project team with diminished cognitive capacity for actual project management.

The more productive question is not “does your team have good software?” It is “what does your team spend most of their time doing, and how much of that is analysis versus data administration?”

The information that should reach you without effort

You should not need to request project status. It should surface to you automatically, in a format that is interpretable, without your project manager spending half the week compiling it.

The technology to deliver this exists. It requires integrating the data sources your project already uses, not adding new ones, and synthesizing that data into the specific signals that matter: cost trend, schedule risk, open decisions, coordination gaps.

When your project team has that infrastructure in place, they recover cognitive bandwidth. They are no longer maintaining the reporting apparatus. They are thinking about the project. They identify problems earlier. They make better decisions.

That is the version of construction technology worth asking your team about. Not the platform with the most features, the system that reduces the administrative burden so that the people managing your project can actually think.