Bits of Data: how Harlan Charles thinks about cognitive load in the MEP trades.

You already know what this feels like.

It's 1:47 PM Pacific. There's a piece of equipment that needs to be ordered today, not tomorrow, today. The vendor's order desk is in Philadelphia and they stop processing at five Eastern. That gives you three hours and thirteen minutes to get an RFI answered, a change order signed, and a PO into the system before the cutoff.

If you make it, the equipment ships on schedule. If you miss it by an hour, if that RFI sits unsigned because the GC's PM was in a meeting, the order doesn't get received and processed until Monday. Maybe Tuesday. That pushes delivery by a full week, which means the crew you had scheduled for install is now standing around, which means someone is going to ask why you're behind, which means you're writing an explanation for a schedule slip that started because one signature took four hours longer than it should have.

While you're chasing that signature, you're also holding a procurement question on a spec that changed last Thursday, a coordination conflict between your ductwork and the electrical contractor's conduit run, a submittal that came back with comments you haven't read yet, and a foreman in the field who needs to know right now whether the hangers on the third floor are twelve-foot or sixteen-foot spacing.

Every PM in the MEP trades has lived some version of this day. Most have lived it hundreds of times.

What nobody in this industry has done is count it. Not the stress. The actual decision load.

What nobody has counted is how many independent, interacting, decision-relevant variables a project manager is holding at any given moment, and how that number compares to what the human mind can actually manage.

That's what Harlan Charles set out to do. This article is about what we found.

Counting the load.

We started with a simple question: how much structured information actually exists on a mid-sized commercial MEP project?

Not vague information. Not emails and phone calls and hallway conversations. We're talking about the discrete, addressable, value-bearing data elements that participate in project workflow, the things that live in drawings, specs, submittals, schedules, budgets, RFIs, change orders, and closeout documents. The information that someone on the project team has to track, verify, and make decisions about.

We developed a term for this: the Structured Data Element (SDE). An SDE is the foundational unit. One data point that occupies a defined position in the project's information system, carries a specific value, and participates in a documented workflow. A spec clause requirement is an SDE. A submittal voltage field is an SDE. An RFI response date, a pay app percent-complete cell, a schedule activity predecessor, each one is a single structured data element.

When you count across all seven categories on a mid-sized commercial MEP scope, the total is large. A single closeout document package of a thousand pages can contain an estimated fifteen thousand structured data elements. Across a full project lifecycle, the total information mass is enormous.

But here's the critical point: most of those elements, at any given moment, are settled. The number that matters is smaller, and more dangerous.

From data to decisions.

Not every SDE matters to a live decision. A pipe diameter that's been specified, submitted, approved, and installed is a structured data element, but it's not keeping anyone up at night. It becomes a problem only when it conflicts with a beam depth and requires resolution, when it carries uncertainty, when its state can change an action, when it affects cost, schedule, safety, or contractual position.

We call that subset the Decision-Relevant Variable (DRV). A DRV is an SDE whose current state can alter the project's trajectory. It's non-final. It carries risk. It demands judgment.

But even the full set of DRVs on a project isn't what competes for a PM's attention at 1:47 on a Thursday afternoon. Some DRVs are weeks away from needing action. The ones that matter right now are the variables competing for attention simultaneously.

We call that set the Active Decision Surface (ADS). The ADS is the real-time cognitive demand on the person running the job. It fluctuates daily, sometimes hourly. On a quiet Wednesday morning it might be manageable. On a Thursday afternoon with an East Coast deadline closing, it spikes.

The ceiling.

The science on human cognitive capacity is not new and it's not controversial.

In 1956, the psychologist George Miller established that working memory, the mental workspace where you hold and process the things you're actively thinking about, handles roughly seven items, plus or minus two. Later research by Nelson Cowan refined that: without external support, the real baseline is closer to four independent chunks. Four things you can genuinely hold in mind and reason about at the same time.

That number stretches with expertise. Experienced professionals develop chunking, the ability to compress multiple data points into a single mental unit. A veteran PM doesn't think about fifteen pipe attributes; she thinks about "that problem spec on the fourth-floor riser," one chunk that holds the whole situation. Under ideal conditions, research by Ericsson and Kintsch shows skilled professionals can extend their effective capacity to twelve to twenty items.

But ideal conditions are not a Thursday afternoon with four active problems and a closing deadline. Most PMs operate under interruption, fragmentation, and competing demands. For them, the practical ceiling is closer to Cowan's four than to Ericsson and Kintsch's twenty.

If CC < ADS, structural overload exists. Not personal failure. Not weakness. A structural condition, as predictable and diagnosable as an overloaded electrical circuit.

Where it hits.

Cognitive overload doesn't land evenly. It shows up differently at every level of a project organization, and the cascade connects them all.

At the ownership and leadership level, the load is strategic, portfolio risk, bonding capacity, cash flow timing, workforce allocation across jobs. When the information picture fragments, margin exposure accumulates invisibly until it's already on the books.

At the PM level, the load is the daily collision of procurement deadlines, coordination conflicts, submittals, RFIs, change orders, schedule pressure, and cost tracking, all interacting, all competing for the same limited working memory. The PM is the information bottleneck. Every delayed decision cascades.

At the superintendent and foreman level, the load is immediate, translating decisions into field reality while managing crews, materials, safety, and real-time coordination with other trades on a loud, active job site where focused attention is hardest to maintain.

At the crew level, the load shows up as hazard recognition or the failure of it. The research is clear: when workers are fatigued and overloaded, they miss things. The things they miss can kill them.

What a cognitive tool does about it.

Every major tool adoption in the building trades has followed the same pattern: initial resistance grounded in legitimate concerns about craft, followed by recognition that the tool amplifies skill rather than replacing it. Solvent cement didn't make plumbers less skilled. Robotic total stations didn't make layout technicians obsolete. Each handled the part of the job that was below the worker's expertise so the worker could focus on judgment.

A cognitive tool operates at the same principle, but on information.

Think of it as a cognitive forklift. A physical forklift doesn't replace the warehouse worker's knowledge of inventory and logistics. It handles the part that exceeds human physical capacity, lifting and moving heavy loads, so the worker can apply expertise to the parts that require judgment. A cognitive forklift does the same for information: it handles the retrieval, correlation, and presentation of decision-relevant data, so the project leader can apply their judgment to the decisions themselves.

A cognitive tool doesn't pull the top down. It raises the floor while extending the ceiling. The best PMs, the sharpest superintendents, the foremen who carry entire scopes in their heads, they get amplified, not diminished.

Lead or be led.

There is a pattern in industries that resist technological transformation: the transformation happens anyway, but on terms set by financial interests rather than practitioners. When an industry's productivity gap gets large enough, capital markets notice. PE firms, insurance underwriters, surety companies start pricing that gap into their models. The question shifts from "are these tools good for the work?" to "is this contractor investable?"

The building trades are not immune. If the industry doesn't develop its own frameworks for cognitive load, its own standards for what good cognitive support looks like, its own voice in how these tools are designed, someone else will make those decisions. Financial instruments don't care about craft, culture, or the people doing the work.

The window for practitioner-led adoption is open. It won't stay open indefinitely.

Where we stand.

The information volume on modern MEP projects has outgrown unassisted human cognition. That's not a criticism of the people doing the work. It's a structural observation about a mismatch between the information environment and the cognitive architecture we all share.

Harlan Charles exists because we believe cognitive tools are the right response. We built an SDE → DRV → ADS → CC framework because nobody else had counted the decision load. We build cognitive tools because the people carrying that load deserve something better than another app that adds to the pile.

The PMs, the superintendents, the foremen, the coordinators, the engineers, and the crews in this industry show up every day and manage critical infrastructure under conditions nobody has bothered to measure. They navigate complexity that would overwhelm professionals in fields with ten times the institutional support. They do it with skill, with grit, and with commitment to craft.

They deserve tools as sophisticated as the work they do.

If you're running a major mechanical scope, ask yourself whether the tools you have today are carrying the cognitive load your team actually faces. If the answer is no, if you recognize the wall we've been describing, we'd like to hear from you.

tellus@hc-build.com