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 p.m. Pacific on a Friday. 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 thirteen minutes to get the final approval and a PO into the system before the cutoff.

If you make it, the order gets processed today. If you miss it, it waits until Monday. Maybe Tuesday. Depending on the supplier's production and shipping schedule, that can cost you the delivery window.

Now the crew you scheduled for install needs something else to do. The sequence changes. Someone asks why you're behind. You're writing an explanation for a field impact that started with an approval that didn't arrive in time.

While you're chasing that approval, 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 who needs an answer right now.

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

We count the labor. We count the material. We count the days.

How do we count the decision load?

How many changing, interacting conditions does a project leader need to keep track of? Which ones need attention now? How much work does it take to pull the context together before that person can act?

That's what Harlan Charles set out to examine.

Counting the load.

We started with a simple question: how much structured information actually exists on an MEP project?

Not vague information. 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.

We use the term Structured Data Element, or SDE.

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 structured data element.

Count across the project and the information adds up fast.

But here's the critical point: most of those elements, at any given moment, are settled or do not require your attention.

The number that matters is smaller, and more consequential.

From data to decisions.

A pipe diameter that's been specified, submitted, approved, and installed is a structured data element. It is not keeping anyone up at night.

It becomes a live issue when it conflicts with a beam depth. Now someone has to resolve it. The answer can change an action and affect cost, schedule, safety, or contractual position.

We call that a Decision-Relevant Variable, or DRV.

A lead time that is slipping. A routing conflict. A failed pressure test. An approval holding up fabrication.

But even the full set of DRVs on a project isn't what competes for a PM's attention at 1:47 on a Friday afternoon. Some are weeks away from needing action. Others are assigned to someone else.

The ones that matter right now are the variables requiring monitoring, evaluation, or action within the current time window.

We call that set the Active Decision Surface, or ADS.

On a quiet Wednesday morning, it might be manageable. On a Friday afternoon with an East Coast deadline closing, the demands can pile up fast.

The framework.

The ceiling.

Working memory is the mental workspace where you hold and process the things you're actively thinking about.

Research by Nelson Cowan puts its capacity at roughly four chunks under particular experimental conditions. That is useful background. It is not a rule that says a PM can manage only four open issues.

A chunk is not the same thing as a project variable.

Experienced professionals compress related information into meaningful patterns. A veteran PM doesn't think about fifteen pipe attributes separately. She thinks about "that problem spec on the fourth-floor riser," one familiar situation that holds much of the context.

Research by Ericsson and Kintsch describes how expertise and access to long-term memory support that performance. Schedules, notes, checklists, and other people help carry the load too.

But consider what happens when the context keeps changing.

The delivery date moves. The approval is still missing. The foreman calls. The GC wants an answer. The schedule says one thing and the field says another.

Now you have to reconstruct the situation while it is moving.

Five active variables do not automatically prove overload. The question is whether the person can reliably track what matters, understand how it connects, and act within the time available.

That is where we need to measure the work.

What was missed? What was delayed? What information was available? How long did it take to find it? What happened next?

When capable people repeatedly lose track of consequential changes, examine the demands and the support available before blaming the person.

Where it hits.

The burden 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. A problem on one job can change decisions across the shop.

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 attention. A delayed decision can leave several other people waiting.

At the superintendent and foreman level, the load is immediate: translating decisions into field reality while managing crews, material, access, safety, and coordination with other trades on a loud, active jobsite.

At the crew level, clear direction and attention to changing conditions matter. Research on construction fatigue and mental workload gives us reason to take that burden seriously, including its effects on safety.

An unresolved condition can travel through the whole organization before anyone recognizes what it is costing.

What a cognitive tool does about it.

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 lifting and moving so the worker can apply that knowledge.

A cognitive tool does the same for information. It handles retrieval, connection, and presentation so the project leader can apply judgment to the decision.

In the equipment example, the tool should connect the approval, vendor cutoff, delivery commitment, installation window, and crew plan.

Those conditions should be visible together, early enough to act.

An alert that says "approval overdue" handles only part of the job. Show me what that approval is holding up. Show me when the delay reaches the field. Help me evaluate the options while I still have them.

That is useful support.

It also has to earn its place. Wrong connections, unnecessary alerts, and unreliable answers add to the load.

Start with one workflow. Measure the outcome. Did the team catch the issue earlier? Did it take less effort to reconstruct the context? Did the decision keep the crew on productive tasks? Did it reduce rework?

If it didn't, find out why. Adjust. Test again.

The value is in what improves on the job.

Lead or be led.

Construction should help define what good cognitive support looks like.

The people doing the work know which conditions matter. They know which deadlines can move and which ones cannot. They know how a missing answer on Friday becomes a crew problem on Monday.

That knowledge needs to shape how the tools are built and tested.

If we leave those decisions entirely to people outside the work, we should expect tools built around their understanding of the problem.

We can participate now. Bring a real workflow. Define the outcome. Test the support against what actually happens.

Where we stand.

Harlan Charles built the SDE → DRV → ADS → CC framework to give us a practical way to examine decision load.

We are not claiming that a count of open variables proves overload. We are asking which conditions require attention, how much work it takes to evaluate them, and whether the support available is enough to help people act in time.

The PMs, superintendents, foremen, coordinators, engineers, and crews in this industry show up every day and manage critical infrastructure. They do it with skill, grit, and commitment to craft.

They deserve tools as sophisticated as the work they do.

If you're running a mechanical scope, ask yourself whether the tools you have today help your team connect the conditions that matter before the decision is made.

If your people are still spending hours hunting for information and rebuilding context, that is a place to start.

tellus@hc-build.com