Before a single trade mobilizes on your project, it gets a pre-install meeting, am I right? The scope gets walked, the sequence gets argued, the people doing the work get to say the thing the drawings missed. Nobody skips this. Skipping it is how people get hurt and schedules die, and every reader of this newsletter knows it in their bones.

Now name the one scope on your last project that never got a pre-install: the software. The platform your field crews will open every morning for the next five years was scoped, demoed, evaluated, and signed in a room that did not contain a single person who will use it with gloves on. This is so normal that it takes a minute to hear how strange it is. We would never buy a crane this way. We buy the field’s daily tools this way almost every time.

Here is the part most commentary gets wrong: the room is not arrogant. The room is afraid, and its fears deserve a fair hearing. Invite the field into a technology decision and the decision slows down. It opens itself to veto, to complaint, to the very real possibility that the field simply says no to everything, and now you have a stalled evaluation and a paper trail of objections. And underneath those sits the fear nobody says out loud: asking the field what they need is an admission that the office no longer knows the daily work well enough to choose alone. Go up one more floor and the pull gets stronger, because the people funding the stack want what a stack is for at their altitude, rollups, dashboards, reporting, and so the higher a decision lives, the more the questions sound like a conference room and the less they sound like a Tuesday.

The field’s side of the table is just as rational and twice as quiet. From a crew’s seat, new software rarely arrives looking like help. It arrives looking like surveillance, timestamps and locations and photographs, data that can be read back later as evidence against the person who entered it. It arrives as hours, entry screens and dropdown menus serving somebody else’s dashboard while the actual work waits. And it arrives in a sequence the field has memorized: never consulted, then measured, then blamed. The office buys, the field pays in time, and when adoption stalls, the stall gets filed as a field attitude problem and answered with more training. That is the moment the resentment sets, because the field was not confused. The field was never asked.

Both fears are reasonable. The silence between them is the only unforced error, and the silence has an invoice. When the field does not adopt, the company does not get a refund; it gets shelfware and idle licenses, shadow spreadsheets doing the platform’s job in secret, the same information entered twice by people who trust neither copy, and downstream rework flowing from data nobody owned. None of those line items appears on the software bill, all of them land on the job, and what they add up to depends entirely on your baseline, anywhere from a nuisance you absorb without noticing to a number that quietly eats the margin the platform was bought to protect. Meanwhile the cure costs a meeting. That asymmetry is the entire argument.

Because adoption was never a training problem. It is an ownership problem. People do not comply with tools; compliance is what we call it when they use something they had no hand in choosing. People use what they part-own, and ownership is manufactured in exactly one place: the room where the decision gets made, before it gets made.

So run the purchase like a pre-install, because the mechanics already live in your company’s muscle memory. Put one superintendent and one field engineer in the demo, chosen the way you would choose who walks a scope, respected voices, not available ones. Give them voice, not veto, and say that plainly to everyone, because the office’s fear of veto and the field’s fear of tokenism die in the same sentence. Let them bring the ugly daily report, the contested checklist, the dead zone, and watch how the product and the vendor handle a real Tuesday. Readers of last week’s issue will recognize this as the punch-list walk, and the field is who you walk it with. Then, whatever gets bought, the people who were in the room become the people who introduce it, and the rollout stops being an announcement from the office and becomes a decision the field already touched.

Vendors are not bystanders here, and the good ones know it. A vendor demos to whoever the buyer seats in the room, so an office-only audience is a buyer’s decision wearing a vendor’s face. But a vendor confident in their product should be asking for the field, requesting the superintendent by role, building the demo for a Tuesday instead of a boardroom, because they are the ones who eventually eat the renewal when adoption dies. The vendors who ask for your hardest audience are telling you something about their product. So are the ones who prefer the conference room.

Validating that the room was right, before the signature makes it permanent, is the decision-level work Building Briefs™ exist for.

The industry keeps calling this a technology adoption problem, and it has never been one. It is an invitation problem with a technology bill. Every scope on your job gets a pre-install because the people doing the work see what the drawings cannot. The software is a scope. The field are its tradespeople. Hold the pre-install, and adoption stops being a program you run after the purchase, because the invitation is the implementation.

👁This Post Caught My Eye

Full disclosure before this one: I am in the room I am about to describe. Jesse Hernandez, who spends his days helping construction leaders out of what he calls sink or swim training, posted about a morning spent with a cohort of builders who treat leadership as a learned skill, and one line in it belongs in this issue. Everyone in that room, he wrote, knows the reality of developing the leadership skills their promotions did not come with, and knows the industry has to do better at it.

Sit that next to everything above. The pre-install meeting your software never got does not fail to happen because leaders are arrogant; it fails because asking the field is a leadership skill, and nobody’s promotion came with it either. The office’s quiet fear in this issue, that inviting the field admits the office no longer knows the work alone, dissolves in exactly the kind of room Jesse builds, where saying I am still learning this is the price of a seat, paid gladly, by people at every level of the org chart. I joined his Construction Leadership Lab this year, and the builders I have met there are the reason this issue exists in the form it does. The invitation is a skill. Skills can be learned. That is the good news hiding in this whole piece.

Before You Buy™: Hardlineapp

The Critical Path

This week’s category is voice-first field documentation, the newest answer to construction’s oldest paperwork problem: platforms that listen to the jobsite’s phone calls and conversations and turn them into structured records automatically. The specimen is Hardline (hardlineapp.com), which captures a superintendent’s ordinary calls and site walks and converts them into daily logs, requests for information, punch lists, change orders, and tasks, syncing into Procore, Autodesk, Fieldwire, Buildertrend, and JobTread, in English and Spanish, with no new app for the crew and, in the category’s own favorite phrase, no behavior change.

Read that promise against this week’s editorial. This is the category that claims to solve field adoption by removing the ask entirely: the field changes nothing, the documentation writes itself from calls they already make. That is a real and clever answer to a real problem, superintendents burning their evenings reconstructing the day from memory. And it is also, at the same time, the most surveillance-shaped purchase in construction technology, because the product’s best feature and the field’s oldest fear are the same sentence. Hardline’s own material promises that every verbal approval and field directive is captured and timestamped, no more I never said that moments. At the company level, that is dispute protection. At the personal level, that is a record of everything you said on the phone. Which one it becomes on your jobsite is not decided by the software. It is decided by how it arrives: announced from the office as a monitoring layer, or introduced by a superintendent who sat in the demo and can tell the crew what it captures, what it ignores, and who sees it. To the product’s credit, Hardline publishes that its artificial intelligence filters out personal conversation, the talk about someone’s kid’s baseball game stays off the record, and that credit belongs in the decision. But no filter can introduce the tool to your crew. Only your guest list can do that, which makes this category the purest test of the pre-install discipline this issue just argued for.

Three questions to settle before anyone talks contract. First, consent: rules for recording calls vary by state and province, your subcontractors and owners are on these calls too, and someone at your company, named, with it in their job description, must own that question before day one. Second, access: decide in writing, before purchase, who can search and read transcripts and whether they can ever be used in performance management, and tell the field the answer, because the field will assume the worst answer until told otherwise. Third, fit: Hardline is young, founded in 2025 with a pre-seed round closed this spring, and its stated sweet spot is contractors of roughly 30 to 100 employees with lean administrative teams, which sits below much of this newsletter’s readership, so ask the maturity question fairly: is their current target profile your profile, and who at your scale can they name.

On price, no public list exists at the time of this review, which is standard for the category and part of the decision as always: you will price this in a sales conversation, so settle your consent owner and your access policy before that conversation, not after. The platform’s reported time savings, on the order of one to two hours per field manager per day, are vendor-reported figures, and what they translate to at your company depends entirely on your baseline of calls made, reports written, and evenings lost.

None of this responsibility sits with the buyer alone. Vendors in this category owe the buyer more than a feature list, because they are selling a product that listens. They owe a consent playbook by jurisdiction, a recommended script for introducing the tool to a crew, plain answers about transcript access and retention, and a demo built around a real call rather than a clean one. A vendor who arrives with those in hand is protecting their own renewal, because in this category more than any other, the platform that gets introduced well gets used, and the platform that gets announced gets worked around.

The most important moment in your last software demo was not a feature. It was the first time somebody on your side of the table asked a question the product couldn’t answer directly, and the person on the other side said, without missing a beat, that there’s a workaround for that.

Nobody took a note. Demos are graded on answers, and a workaround sounds like an answer. It has the shape of one, the confidence of one, and it arrives in the same friendly voice as the real ones. So the meeting moved on, the question got a checkmark in the decision maker’s evaluation spreadsheet, and the most useful piece of information the demo produced that day evaporated by the end of the demo.

Here is what a workaround actually is, and once you see it you cannot unsee it. A workaround is a truism in the vendor’s world that is likely false in yours.

That is not an accusation. Stay with me, because the fairness of this matters. The person giving your demo is not lying to you. Every workaround they offer is true where they live. The problem is that they do not live where you live, and neither does the workaround.

Take the three you have already heard many times over.

Number one. It’s an easy Application Programming Interface, or API, connection. True. Their API is documented, clean, and their best customers use it every day. Now walk that same sentence onto your side of the table. An API connection is not a thing you buy, it is a thing somebody builds, then owns, then monitors and may have to fix at 6 a.m. when it stops syncing the platform. So ask the question the demo never asks: who at your company is that somebody? Not who could do it. Whose job is it? At most mid-sized contractors with your limited budgets for technology, the honest answer is nobody, so the request lands in the general information tech queue, behind every password reset and server problem your company already generates, and it may sit there for weeks before anyone notices. The sentence was true. Easy for someone whose job it is. You just don’t employ that someone.

Number two. Our development team can write some custom code for that. Also true. They can, and they might even do it well, and none of it is free. Custom code is professional services, a separate line priced outside the license fee and usually quoted after the demo warmth has worn off, and what it costs depends entirely on your scope, anywhere from a rounding a number up a zero or two that makes the software subscription on its own look cheap, with every future modification due to this coding, billed again when the subscription renews. And the question nobody asks in the demo still arrives later: what happens when your request falls behind their product roadmap, which it will, because custom code written for one customer loses to features built for all of them every time the two compete for the same sprint. You will not find out exactly which release breaks your customization until it breaks.

Number three. We include custom onboarding. This one deserves the most respect and the most suspicion, because it is a real offer made by people who intend to keep it. Then the first week of onboarding collides with the first real problem on one of your jobs, and site priorities eat the calendar, because site priorities eat every calendar. Your superintendent is not skipping a concrete pour problem to attend a training session, and nobody in this industry would want them to. Everyone at the table knows this. Everyone except the onboarding plan, and the customer success team waiting in the wings.

Notice what all three have in common. Each one is the product telling you, out loud, in a friendly voice, that it does not fit your company yet. The vendor built something real that solves a real problem, and somewhere between their world and yours, a gap opened that the workaround is papering over. The workaround is not the answer to your question. It is the product’s answer to a different question, which is: how big is the gap between the company this was built for and the company sitting in this room?

Which is why the discipline is not to argue with workarounds. It is to count them.

One workaround in a demo is normal. No product fits any contractor perfectly out of the box, and a vendor who claims otherwise is the one to worry about. Three workarounds is a translation problem: the product and your operation are describing the same work in different languages, and somebody is going to pay for the translation, in configuration, in custom code, in habits your field team is asked to change. Five workarounds means the demo has quietly changed subjects. You are no longer evaluating the software. You are evaluating a construction project made of workarounds, with your company as the general contractor and no drawings.

And here is the line your evaluation spreadsheet has no row for: the software comes with a warranty, a contract, a support line, and a roadmap. The workarounds come with none of that. The API connection nobody owns, the custom code that loses to the roadmap, the onboarding that dissolved into a Tuesday, that is the part of the purchase you build and maintain yourself, forever, and it is the part most likely to fail. When it does, it will not be the vendor’s fault, and it will not be the product’s fault. The tool was never the problem. The number of workarounds was, and nobody kept track.

So do this. In your next demo, assign one person a single job: write down every workaround, word for word, the moment it is offered. Not to catch anybody. To price the gap. After the demo, take the list and put a name from your own company next to each item, the person who will own that workaround for as long as you own the software. If you cannot fill in the names, you have your answer, and it arrived for free, before the contract did. What that workaround inventory costs you if you skip it depends entirely on your baseline, but the range runs from a few awkward months of shadow spreadsheets at the small end to cancelling your contract altogether, paying a likely penalty, and having to source the entire category all over again at the large one, and every contractor reading this can place themselves on that line without any help from me.

This is the kind of decision, not the software, the decision, that Intelligent Construction Opportunties, Building Briefs™ was built to validate before your signature instead of after it.

The vendor told you the truth all the way through the demo. The product told you the truth too, every time it needed a workaround to reach you. Workarounds aren’t answers. They are serious considerations. More than three, the demo is telling you no in the politest language it has, and the only question left is whether anyone in the room heard and noticed.

👀This Post Caught My Eye

Karina Delcourt, Director of Strategic Initiatives at ETRO Construction in Vancouver, posted earlier this year about where process improvement actually hides, and one line resonated on the exact phrase this issue is about. Her argument, paraphrased: the big innovation home run is overrated, and the real gains come from reading your operation’s internal distress signals, recurring workarounds announced by the phrase “we usually just,” as it concerns information entered twice, handoffs that need the context re-explained, and the heroics of a few people quietly keeping jobs from stalling. Rework, she says, is the loudest signal of all, and the fix is almost always earlier in the process, not faster at the end.

Best of all is her frame for the whole exercise: treat the pain points as design flaws in your SOPs and process. Delcourt is counting the workarounds already inside your walls.

This newsletter issue counts the ones being offered across a demo table. It is the same kind of count, and here is the uncomfortable connection: a company that cannot hear “we usually just” in its own trailer cannot hear it in a conference room demo either.

Her question worth asking; where are your best people spending energy your systems should be handling?

🛒 Before You Buy™: Array

The Critical Path

This week’s category is field data capture: the no-code forms and workflow platforms that promise to turn daily reports, inspections, and observations into structured data the office can actually use. The specimen is Array (array.so), whose construction offer includes mobile forms with offline capture, automated workflows, live dashboards, ready-made integrations alongside web-hooks and an API, and a dedicated applications manager to run implementation.

Read that list against this week’s editorial and notice something: this is the category that claims to end the workaround. Where other platforms offer workarounds to reach your operation, a no-code platform offers to let you build the fit yourself. That is a real and honourable pitch, and it does not remove the decision, it relocates it. The question stops being whether the product can fit and becomes who at your company does the fitting. Somebody has to build the forms, own the form library, and maintain it as your operation changes. If that somebody is a name with a job description, this category can pay you back fast. If that somebody is “we’ll figure it out,” you have not bought the end of workarounds. You have hired yourself as the integrator without noticing.

So bring the newsletter’s editorial into this category’s demo, and put a name against each of three claims before anyone talks contract. The ready-made integrations, web-hooks, and API: who owns the connection, whose job description says so, and what happens at 6 a.m. when it stops syncing. The custom forms: who owns the library when the person who built it changes jobs, which readers of the July 8 issue will recognize as the same fragility that kills continuous improvement programs, wearing a login. And the dedicated applications manager, which is this category’s version of custom onboarding: a real offer from people who mean it, measured against the first week a jobsite emergency eats the training calendar.

On price, the honest report is that we found no public price list at the time of this review, which is common in this category and is itself part of the decision: you will price this platform inside a sales conversation, which means your workaround count and your ownership names should be settled before that conversation starts, not after. Array’s own published claims, productivity gains in the range of 14 to 15 percent per project and time savings of 5 to 11 hours per person per week, are vendor-reported ranges, and what they would translate to at your company depends entirely on your baseline volume of paper, re-entry, and chasing.

None of this responsibility sits with the buyer alone. Vendors in this category owe the buyer a scoping conversation that names the internal owner before the contract does. A vendor confident in the product should ask who will own the form library, insist on hearing a name, define onboarding around job site reality instead of a calendar that pretends there isn’t one, and put directional pricing on the table earlier than the category’s habit. The vendors who do this are not being generous. They are protecting their own renewal, because the platform that gets an owner gets used, and the platform that gets used gets renewed.

Every continuous improvement manager in construction carries the same quiet wound. You know the discipline works, because you have watched the loop close. In the Monday pull plan, a superintendent flags that the rebar inspector can’t come this Thursday, the day you thought your crew could pour. The constraint gets logged and cleared and the next lookahead is built acknowledging this.

That is the whole engine in one turn: a problem made visible early, fed back into the plan, and not repeated.

On the projects where you fought for this type of process to be implemented, you saw the schedule quietly get more honest. Alternatively you know exactly how it dies, because you know the learning lives in people and in a room.

It lives in the superintendent who trusts the huddle enough to say the awkward thing, and who has developed the habit of writing the constraint down before it gets forgotten. Why? Because you, the continuous improvement role stand at the front keeping this loop honest. Pull any of these elements and the practice can begin to leak. You get moved to another site and the huddle thins inside a month. The log fills up and then quietly stops. The whiteboard where problems were supposed to become visible turns into the place somebody hangs a hard hat. And here is the part that stings: six months later a different crew hits the same Thursday inspector gap, loses the pour, and pays again for a lesson the company should have already clocked, and be prepared to work around.

Continuous improvement is real, its memory is fragile, and you have watched both come true more times than you might ever admit at a conference.

Which is why you are the least surprised, and the most exposed, when a vendor puts continuous improvement on slide four and explains that the machine does it now. Automatically. It does not get pulled to another site. It does not forget the rebar inspector. And the uncomfortable part is that the pitch is not wrong on the face of it. Strip your own discipline back and in the end it is a learning loop: something happens, the superintendent records it, the situation gets fed back to operations, and the next job running this similar scenario should run better.

Machine learning is pretty much the same learning loop: something happens, the data records it, the model feeds it back, and the next prediction runs a little better. Same shape. And the machine’s version fixes the flaw that has haunted yours for forty years, because its memory does not leave the job. So when a smart leader turns to you the second the demo ends and asks whether continuous improvement was just machine learning all along, finally built well enough to work, it is a fair question. It is also the exact wrong one to answer with a yes.

Start with where continuous improvement came from, because it did not come from a software company and it did not come from America. It came out of post-war Japan, off the factory floor at Toyota, where kaizen meant change for the better and meant it as a daily habit rather than a slogan. In 1992 a Finnish researcher named Lauri Koskela argued that this same production thinking belonged in construction, that a job site had more in common with a factory then the construction industry wanted to admit.

A few years later Glenn Ballard and Greg Howell turned that theory into the Last Planner System, and the international group that grew up around it held its first meeting in 1993.

So the discipline your newest artificial intelligence vendor is quietly borrowing its vocabulary from is about forty years old, and its passport is Japanese and Finnish. Worth remembering the next time someone sells it back to you as brand new.

It helps to be precise about what that discipline is, stripped of the certification badges, because the vendor may not know you know all this.

The Last Planner System keeps score with a measure called Percent Plan Complete, which is a polite way of asking how often the crew actually did what it said it would.

That number is not really the point, though. The point is everything that has to be true for it to mean anything: a crew that will commit out loud, a foreman who will admit when the drywall job went wrong, and a culture that treats these misses as lessons rather than a stick to hit someone with. None of that is technology. It is a set of human habits, and like every habit it is easy to describe and hard to keep alive.

So watch what happens when a contractor bolts a real machine onto that same loop. Pomerleau, one of Canada’s largest builders, put the problem in words your estimators will feel in their bones: you finish a bid, you win it or lose it, and you learn almost nothing, and the hundreds of estimates behind it may as well have never happened. Every new job starts from a reset.

Working with a Montreal artificial intelligence firm called Zetane, Pomerleau built something that reads its own mountain of past bid documents and lets the estimate finally learn from history instead of starting blind. That is the machine doing the thing your discipline always wanted to do, at a speed no human team can match, and without a huddle to keep alive.

You can see the same engine running south of the border, on safety instead of estimates. A group of large American contractors led by Suffolk pooled more than ten years of project photos and records and fed them into a model that learned to flag the conditions that tend to come before an incident. The more data went in, the sharper it got, which is the entire idea. Over a three-year stretch it predicted roughly one in five incidents at about eighty percent accuracy, and the honest footnotes rode along with it: it threw false alarms, and on at least one large tower the team had to mount more cameras just to feed it. These are reported figures, not laws of physics. But the shape is unmistakable: a loop that improves as the work teaches it, which is continuous improvement wearing a faster engine.

And this is the case you are suddenly the right person to make, because you are the one who knows what the machine cannot supply. The machine is worth real money only where the discipline it accelerates already exists, or is being seriously implemented. Bring in machine learning to rescue a company that does not already have a learning culture, and you have bought a very fast way to confuse the project, at a cost that lands somewhere between disappointing and expensive depending on how much of your software investment ends up as shelf-ware. The contractors that get value out of this are not the ones with the fanciest automations. They are the ones who already ran the huddle, already measured the plan, already made their problems visible cause their culture doesn’t play the blame game, and ONLY then handed the machine learning automations over to a culture ready and primed. Your unglamorous, fragile, forty-year-old habit is the thing that makes the shiny purchase pay off. Say that in the vendor room, before the signature.

That gap, between the thing people buy and the readiness to use it, is the whole reason I build Building Briefs™, a way to pressure-test the decision and the readiness rather than the product before the money moves.

A machine that learns is only ever as valuable as the organization that was already trying to improve.

So no. Continuous improvement is not just another word for machine learning. One is the human discipline of learning from the work. The other is a machine that learns from the exhaust the work throws off. Put the two together on purpose and you have something this industry has wanted for forty years. Skip the first and buy the second, and you have paid a premium for a faster way to repeat yourself. Same lesson. Faster machine. The machine was never on trial. Whether or not your culture was designed to be constantly learning is.

Subscribe now

👁This Post Caught My Eye: Patrick Dupin

This particular post caught my eye because it endorses the argument of this editorial. Linkedin Post

Patrick Dupin, a Lean specialist, ranked where the learning on a job site really comes from. Theory teaches you the least. Practice teaches you more. Your own costly mistakes, the rework and the blown dates, teach you the most of all. Then he made the move that matters. The point of Lean, he argued, is to stop letting the mistake be the teacher and instead build a system that catches the lesson before the failure arrives, and he named the usual machinery for it, pull planning, daily huddles, root cause analysis, the whole continuous improvement kit.

Read that with this week’s question in mind. A system that learns without living through every failure is precisely what the software now promises too. The difference is that Dupin is describing the human version, the discipline somebody has to build and defend. That is why it landed for me. He named the thing the machine quietly borrows and rarely credits. The loop was always the point, and the loop was human first.

Before You Buy™

Touchplan by MOCA Systems

The thing to put under the lens this week is not a device, it is a planning platform, and Touchplan is a fair one to name. It digitizes the Last Planner System and supports Takt planning. EllisDon runs it company-wide, including on the Thunder Bay Correctional Complex, and Jacobsen ran it building the tallest tower in Utah, so the adoption is real on both sides of the border. The platform is good. That is not what this discussion’s objective is.

The decision that loses the critical path is the one that buys the software expecting it to supply the discipline. Touchplan will digitize your pull plans, score Percent Plan Complete, and make constraints visible, but it cannot make a foreman and his crew work faster than they can, or a superintendent admit the effect this has on the schedule. It reinforces the habit, it does not create it. So the real questions are whether this loop can already be absorbed into your jobs and projects, or whether you are committing to build the culture that will need to. This includes whether your teams keep the plan current when you are not in the room, and who owns that practice the way the editorial just described.

On price, do not expect a clean number early. Planning platforms in this category rarely put real pricing on the table until you are close to a contract, and that reluctance is itself part of what you are evaluating, so make them quote your actual seat count and treat any early figure as directional. Whatever you land on, judge the return as a range tied to your own baseline, the slippage and rework you can actually prevent, and never a number carved in stone until you’re ready to sign on the dotted line.

Ask anyone who has spent twenty years in the trades what the hardest work in construction costs them, and they’ll never be talking about the software. They will tell you about that bum shoulder that does not lift the way it used to, their lower back that slowly aches its way through their day, and knees that can tell them the weather. Their bodies keep the true daily reports. And for all the technology we have poured onto the jobsite in the last decade, almost none of it has done a single thing for that report. Most of it makes the office’s job easier, and efficient, while handing the field one more thing to keep track of, and accounted for.

Here is a question I have been sitting with for a while. Does any of the technology we buy actually make the work feel better for the person doing it, or do we just gloss over the way this all works, and convince ourselves we’ve considered the full picture.

I read an article recently where researchers put a back-support exosuit on sixteen frontline workers across two active job sites and were asked in their own words, what wearing it was like. The crews warmed to it once they had worn it, and were blunt about what still bothered them, straps that dug in, an awkward reach to the tool belt, the heat. Ask a crew cold and plenty start with arms crossed, waiting to see whether this lives in the gang box by Thursday. That skepticism is not the enemy of the question. It is the question. Does anyone in construction technology asks it that plainly about their own product?

If you have not been paying attention, exosuits are the part of construction technology that doesn’t look like the average technology. No dashboards, no logins, no data for the office to review, and apply. They are wearable frames and soft harnesses that take the load off a worker’s shoulders, back, and arms and move it somewhere the body can carry it. They were a lab curiosity a few years ago and they are on real job sites now, and the numbers the makers and early adopters report are not small. Depending on the device and the task, they describe taking somewhere between 40 and 70 percent of the load off a shoulder or a back. Those are reported figures, not independent measurements, the leaner numbers from manufacturers like Hilti and the high end from a masonry crew in Quebec, so I hold them loosely and you should too. Even hedged, for a trade where overexertion is the leading cause of injury and nearly nine in ten jobs mean handling material by hand for about half the day, that is not a gadget. It is somebody’s career staying intact a few years longer.

And this is what makes the exosuits worth your attention even if you never buy one. It is the rare piece of construction technology whose entire reason to exist is the person doing the actual constructing. This is a BIG DEAL. It does not surveil, or cost the site time in keystrokes, and data input. It asks one thing, wear it, and then gives back something they can feel by the end of the shift.

On a Massachusetts job site a contractor described one of his guys running a thirty-six pound hammer drill one-handed, because the frame carried the weight his arm used to. Put that next to the last platform you rolled out, the one that served the office and handed the field an hour of logging, and you can see the question underneath it all. Not is it advanced. WHO IS IT ALL FOR?

Which is the real answer to the oldest objection in the business, why not just do it the way we always have, by hand. Sometimes that is the right answer, and the whiteboard wins because the crew already trusts it and it costs them nothing. But the exosuit is the cleanest example of technology that earns its place, because it does not replace the work or the person. It just makes the work survivable. That is the bar. A tool is worth it when the person doing the work ends the day better, not only when the dashboard does.

And if you are the one signing the purchase orders, a Director of Operations weighing this against ten other line items, here is the part that should land for them. The benefit to the worker is not separate from the business case. It is the business case. A body that lasts longer is a skilled craft worker who stays on the tools another few years, and in a labor market this tight, keeping that person is worth a multiple of what the suit costs. Overexertion is the leading driver of injury spend, so even a handful of prevented back and shoulder claims across a crew over a few years is real money, and it lands well past the price of the gear. I will not hand you a single number, because the honest figure is a range that depends on your own baseline. But the direction is not in doubt.

It does not stop at the crew. A worker who is not fried by hour seven holds a steadier pace and makes fewer of the tired mistakes that turn into rework, and that is schedule protection, which is the language the owner speaks. The owner does not care about your exosuit. The owner cares about on time, on budget, and an incident log that stays quiet, and a crew whose bodies are not failing at the end of the day serves all three. So the case stacks. Good for the person holding the tool, good for the contractor carrying the risk, good for the owner signing off on the result. That alignment is rare in this business, and worth naming when you see it.

Now the part that keeps this from being a trite advertisement. An exosuit is not automatically good, and the difference is entirely in the decision behind it. The wrong device on the wrong task can trade an old strain for a new one. Hand it to a crew as a mandate with no training and no say, and it lives in the gang box by Thursday. The contractors getting this right are not buying on the strain percentage. They run a pilot, two or three devices on an actual trade for a few weeks, and let the people who would wear it tell the truth about fit and limits before a purchase order goes out. The technology is never the question. Whether you chose the right one, for the right body, and let them try it instead of forcing it, that is.

That is the same question I keep landing on no matter which technology is on the table, and it is the whole reason I build the Building Briefs™ system, a way to pressure-test the decisions and the readiness of the technology, not the product, before the money moves. A device built to lift the worker can still grind them if the decision behind it was hurried and off the shelf.

I have spent my career around technology that promised to help people, and a fair amount that has really only helped the back office. So I notice when something is actually pointed at the person. Exosuits are not the future of construction technology. They are a test of it. They ask the question we should have been asking about a lot of the digital tools we ever bought. Does the person responsible for the input of this device, going to end their day better? If the answer is always no, it doesn’t matter how advanced the data points get for the project owners, contractors, and the back office. And if the answer is yes, you have found the rarest thing in this industry, a piece of technology that is actually on the worker’s side, literally.

👀 This Post Caught My Eye featuring Mark McCormick

This one caught my eye because it came from the last person you would expect to gush about a new toy, an insurance man. Mark McCormick works in risk control at Starr, and he posted about a four-week pilot on a Philadelphia hospital project, two exoskeleton models on real workers, with those workers handing back honest notes on fit, on limits, on what helped and what got in the way.

Here is why it landed for me. An insurer has every reason to oversell a tool that lowers claims, and instead Mark let the limitations show. That is the decision-and-readiness frame in the wild, a real pilot on a real trade with the people who wear it telling the truth before anyone scales it. It also sits on the tension this issue is about. An insurer cares about injuries and dollars, the worker about whether the shift feels survivable, and those are not always the same conversation. The only way you find out is to do what McCormick did, try it small and listen.

Before You Buy™ - HeroWear Apex 2

The Critical Path

The natural device to put under the lens this week is a soft back-assist exosuit, and HeroWear’s Apex 2 is a fair one to name, because the platform is good. It is light, it has a clutch that lets a worker switch the assistance off when they do not need it, and the company has put it through peer-reviewed testing rather than a hero number. None of that is the thing on trial. You are.

The decision that can lose the critical path is the one that buys on the spec sheet. Reported strain relief of 20 to 40 percent per lift is a reason to look, not a reason to sign. What matters is which trade carries the back-loading the suit is built for, whether you trial two or three for a few weeks instead of mandating it crew-wide, whether the fit works for the bodies you actually employ including the women on your crew, and whether the heat and reach hold up in your conditions, not a demo. Get those right and the savings are real, but they live in a range, the cost of a handful of prevented back claims over a few years, not a single tidy figure anyone can promise you.

And the vendor carries weight too. HeroWear's job is of course not done at the sale. It owes you fitting across body types, training that is more than a handout, change management for crews who did not ask for this, and claims it can stand behind. To their credit, they warn against the human-forklift hype themselves, the kind of restraint you want from the people selling you the thing.

Heather Adkins, who runs marketing at Trimble, posted something this week that most software companies would never let their CMO say out loud. She asked her own sales chief what their best customers actually have in common, and the answer was not how many seats they bought, or how long they had been on the platform, or which products they ran. It was that the best ones mandate the software, build their own workflows on top of it, and keep paying to have their people trained long after the contract was signed. Her point was that the best customers do not buy software, they buy partnership. I read that and thought, a vendor just said out loud the thing I spent a decade in technical learning and development trying to get companies to see. The tool was never the hard part. The learning was.

Here is the diagnosis nobody in construction wants to hear, because it costs money and it is less fun than buying something. The reason your last piece of software underdelivered is almost never the software. It is that you bought a tool and skipped the part where your people actually learn to use it. Not the two-hour onboarding webinar. The real thing, the weeks of fumbling, the workflows rebuilt around how your crews actually work, the person whose job it is to keep the thing alive after the rep stops calling. That part got cut, because it has no logo and you cannot demo it, and so the tool got blamed for a job it was never set up to do.

The data is not subtle about it. In one survey of more than four hundred technology leaders across eight countries, the most-named barrier to digital adoption was not cost and not the tools, it was lack of training. Seventy percent of US contractors do not even have a formal technology roadmap, which means most firms are buying tools one panic at a time with no plan for absorbing any of them. The tools are fine. Most of them are very good. The firms keep stalling anyway, and they keep stalling at the exact spot Trimble’s own marketing chief just pointed at, the learning.

I spent years on the selling side of technical learning and development, which means I watched a lot of companies treat training as a thing you buy once, at rollout, in a box, and then never think about again. Construction does this worse than most. It will spend six figures on a platform and then hand the crew a login and a recorded video and call that adoption. But learning a tool that changes how people work is not an event. It is a capability you build and keep building, the way you would never train a foreman once and assume he is set for a career. The firms that win with software are not the ones who bought the best one. They are the ones who decided, before they signed, that they were going to build the muscle to absorb it.

The whole industry keeps calling this a skills gap, as if the fix is more training hours poured into the same broken approach. It is not a skills gap. It is a decision failure. Somewhere a firm decided to buy the tool and decided, usually without ever saying it out loud, not to build the thing that makes the tool stick. The gap is not in your people. It is in the decision you made before your people ever touched it.

Which leaves the only question that actually matters, and it is one you can answer before you spend a dollar: will my shop actually absorb this, or am I about to buy another login nobody opens? That question, asked up front instead of discovered painfully after the purchase, is the entire reason I build Building Briefs™, a way to pressure-test the readiness, not the product, before the money is gone. The software is rarely the thing that fails you. The decision to buy it without preparing to learn it is.

So before you buy the next thing, sit with the unglamorous truth a software company’s own marketing chief handed all of us this week. The best customers do not buy software. They buy the commitment to learn it, and they keep paying for that commitment long after everyone else has moved on to blaming the tool. The tool was never the hard part. It is time we stopped pretending it was.

👁 THIS POST CAUGHT MY EYE

The line in this post that stuck with me this week came from Benny Baltrotsky: construction doesn’t have a software problem. He is right, and it is the same point from a different door than the one I walked through up top. The tools are not the thing holding the industry back. He ends on a question, whether the real barrier is technology, process, or people, and he treats all three as live options. I would close the question harder than he leaves it. It is people, but not in the way that sounds like blame. It is the decision to buy the tool and then skip the work of helping people learn it. Same diagnosis I keep landing on, said by someone standing somewhere else.

BEFORE YOU BUY™

The Critical Path

In plain terms, Procore is the platform a lot of GCs, and a growing number of specialty contractors, run the whole project on: RFIs, submittals, drawings, daily logs, financials, the field and the office finally looking at the same record. It is one of the most widely adopted construction platforms there is. For this week’s topic it is the most interesting one I could put in front of you, and not because of a feature. Because of what it does about learning.

Most software companies treat training as an afterthought. Procore did the opposite, and it is worth knowing why. When the company was growing fast, it found that onboarding thousands of new users was its own biggest bottleneck, so it built one of the most complete learning ecosystems in the industry. Free, self-paced, role-based certification courses for project managers, superintendents, subcontractors, owners, and admins. Mobile task simulators. An implementation roadmap with a dedicated training phase. Verifiable certificates people add to their LinkedIn profiles. Even the vendor, the one with every reason to say the product sells itself, concluded that the tool was not the hard part. The learning was.

Which is exactly why the readiness question here gets sharp. The objection most buyers reach for, we do not have time to train everyone, does not apply, because the curriculum is already built, already free, and already waiting. So the only thing standing between you and adoption is not the existence of training. It is whether anyone in your shop is assigned to make your people actually go through it, and to rebuild your workflows around how your crews really work. Procore can hand you the classroom. It cannot make your team show up, and it cannot decide for you that learning the platform is somebody’s actual job.

So before you sign, the question is not whether Procore is good, it is, or whether it has training, it has more than almost anyone. It is whether you will treat adoption as a role or as a hope. Name the person who owns it. Give them the hours. Decide that getting your team certified is part of the rollout and not a nice-to-have for whoever has a slow week. If you cannot say who that person is, you are not buying a platform. You are buying a very well-built login that most of your team will never really open.

The bottom line. Procore is an excellent platform that has done more than most to remove every excuse you have for not learning it. That is what makes it the cleanest test of this week’s point. The tool is not on trial, and the training is not missing. Even the best training program in the industry cannot make this decision for you, which is the one thing worth getting right before you spend. The only variable left is whether you decided, before the money moved, to build the muscle to absorb it. Start with that conversation first.

Ask a Digital Solution Manager, the Site Super, a VP of Operations, or your VDC lead how they feel about their tech stack, and you will get four answers and at least one argument. The Digital Solution Manager loves it, because choosing it was their idea and defending it is now their whole job. The Superintendent judges it by exactly one thing, whether the job runs smoother on Friday than it did on Monday. The VP sees a line item that had better turn into margin, (and stays privately unconvinced). And the VDC lead, who lives inside the BIM models, has opinions about file formats that could clear a room, because they are the one who notice, usually at the worst possible hour, the exact moment two of your tools quietly stop talking to each other. Four jobs, four opinions, four completely different love languages. And yet lately, across every one of them, I keep hearing the same nervous little sentence, and it has nothing to do with whether the software is any good. It’s what happens to this thing IF they get bought?

Because this keeps happening more, and faster than usual.

This spring Nemetschek agreed to buy HCSS, the estimating and field suite that heavy civil contractors basically live in, for about 2.4 billion dollars. Trimble closed its purchase of Document Crunch for contract review. Autodesk picked up Rhumbix for field data, then agreed to buy MaintainX to push into operations. PwC’s read on 2026 says the year will be shaped by exactly this, consolidation, and it names the reason out loud: the same margin squeeze hammering contractors, rising costs and a thin labor market, is squeezing the vendors too, and their answer is to merge. So the volatility that is making your jobs harder is also quietly redrawing the map of the tools you run those jobs on.

Here is what I want to say before anyone reads me as sounding an alarm. Consolidation is mostly good news. A point tool with a real owner behind it usually gets more resources, better integration, more stability. I am not here to root against it, and neither should you. This train is not stopping, and most of the time you do not want it to.

Take HCSS, since it is one of the newest. If you run HeavyBid or HeavyJob, you did not choose them because they were part of something bigger. You chose them because they were built by people obsessed with heavy civil, who spoke your language and nothing else. That focus is the whole product, and the day the deal closed it became fair to ask whether that focus survives inside a global portfolio run out of Munich. So I did the thing everyone who uses these tools should do. I looked at how the new owner actually behaves. Nemetschek bought Bluebeam back in 2014 and has let it run as its own brand, with its own name and its own team, for eleven years and counting. That is the pattern across their entire house of assets, sixteen or so brands that mostly stay themselves. So the likely read on HCSS is the reassuring one. It probably keeps its focus, probably gets more resources behind it, and probably does not get blended into anything soon, because blending is not how this owner operates. That is not a guess. It is a read you can take to the renewal table, and the only reason I can hand it to you is that somebody actually checked. Which is the whole point, because almost nobody does, and the next deal you care about might land on an owner who plays it nothing like this.

You do not have to look far for other models. Around the same time, Hexagon took three tools it owned, Voyansi, LocLab, and Construction Analysis, and folded all of them into one brand called Multivista. According to Hexagon customers were juggling separate providers for capture, modeling, and analysis, so Hexagon collapsed them into a single portfolio with one point of contact, organized as capture, create, and analyze. One brand to manage instead of four. It did not let them run separately with Hexagon. It did not keep their names. It absorbed them, rebranded them, and moved on. Same wave, different playbook. If your tool gets bought by a company that operates like Hexagon instead of like Nemetschek, the focus you signed up for may not necessarily be what you signed up for, and might in fact make your experience better but more costly. Neither approach is good or bad. They are just different, the difference is knowable before you sign, and which one your vendor just married is the most useful thing you can learn the week the deal lands.

Because every acquisition quietly changes the one thing that never shows up on the demo screen, the roadmap. The tool you chose for one sharp reason now answers to a portfolio strategy, set by people who certainly don’t run your jobs. And the features you fell in love with, the reasons you signed, may or may not be the features the new owner cares about. I have watched this from both chairs. I have recommended tools that later got acquired, and I have had a few of these companies on livestreams back when they were independent and still telling one clear story about where they were headed. After a deal, that story gets rewritten by someone else, and you usually have to do some digging to get to the new draft.

The mistake I see buyers make sits at the two extremes. One camp panics and considers ripping out the tool the deal has announced, risking eating a migration they did not need to cook. The other camp does nothing, assumes the product they bought is the product they will keep, and finds out a year and a half later that their favorite feature got consolidated into a suite they never wanted. Both are guessing. Neither asked the questions that would have told them which camp they were actually in.

So here is what I would ask, and what I tell the people in those demo rooms to ask, the week any vendor of theirs gets bought, and ideally long before.

✅ Ask what the acquirer actually wants this product to become: a strategic core they will invest in, a feature they will absorb, or a customer list they will harvest.

✅ Ask whether your product line stays intact and under its own name, and on what timeline.

✅ Ask what happens to the integrations you depend on, especially the ones with the new owner’s direct competitors, because those are the first connections to quietly disappear.

✅ Ask who is staying, the founders, the product leads, your own support reps, because people leaving is the earliest sign the roadmap is about to move.

✅ And ask whether your price, your terms, and your service levels are locked through your renewal, or whether they can change on the new owner’s schedule.

None of these questions are hostile. You can ask every one of them and still love the tool and still be rooting for the deal. They are not about whether the software is good. They are about whether you did your homework on who owns it now.

The deeper thing, the part I keep coming back to, is that you never controlled the roadmap. You did not control it before the acquisition either. You just had the comfortable illusion that the people building your tool wanted the same thing you wanted, and generally speaking they do. An acquisition does not take your control away. It removes the illusion that you had any. What it leaves you with is the only thing you ever actually held, which is the quality of your own decision, made with your eyes open about who you are really betting on.

Consolidation is going to keep coming. More of your tools are going to get bought, probably ones you count on, probably sooner than you would like. The contractors who come through it in good shape will not be the ones with the best software or the loudest opinions about mergers. They will be the ones who asked the boring questions early, wrote down the answers, and decided what they would do before anyone forced their hand. The roadmap was never yours. The decision always will be.

👁️ THIS POST CAUGHT MY EYE

One of the sharpest things I read this week came from Aaron Kreymer, who looked at the same Nemetschek and HCSS deal I wrote about, and asked the only question that matters: are these acquisitions actually good for the industry, or not. His answer is the right one, that it depends, and he names both sides fairly, the better information flow on one hand, the buried roadmaps and the lock-in on the other. I would only add the part he leaves open. It is not really good or bad for the industry. It is good or bad for you, depending entirely on whether you saw it coming and asked anything before it landed.

BEFORE YOU BUY™

HCSS (HeavyBid / HeavyJob)

The Critical Path

In plain terms, HCSS is the system heavy civil and infrastructure contractors run their business on. HeavyBid handles the estimating and the bid. HeavyJob runs the field and the job costing. Around those sit fleet, equipment, and safety. It has been doing this since 1986, it serves more than four thousand companies, and its churn is under two percent, which is the number that matters most: its users do not leave, because they love it. In the demos I have sat through, HCSS is the rare tool the users defend before anyone can criticize it.

This spring, Nemetschek, the Munich-based owner of Bluebeam and GoCanvas, agreed to buy HCSS from Thoma Bravo for about 2.4 billion dollars, its largest acquisition ever, with the deal expected to close in the second half of 2026. On paper that is a strong home for it. Nemetschek has real scale and a serious construction portfolio, and HCSS could come out of this better resourced than it has ever been. That is the optimistic case, and it is a real one.

Here is where the buyer’s readiness, not the product, comes under the light. HCSS users chose it for a focus so narrow it borders on stubborn: heavy civil, and nothing else. The open question after any acquisition is whether that focus survives contact with a global platform that has a dozen other priorities, or whether it slowly gets generalized to fit the suite. If you run HeavyJob, the work is not to panic. It is to find out, in writing where you can, what Nemetschek wants HeavyJob to be in two years, and to lock your terms while you still have the leverage of a renewal in front of you.

The one question worth asking before your next renewal is not whether HCSS is good. It is. It is this: do I know what the new owner wants this tool to become, and have I gotten anything about my price, my roadmap, and my integrations in writing since the deal. If you cannot answer that, the quality of the product will not save you from a roadmap you never agreed to.

The bottom line. HCSS is one of the best-loved tools in its corner of construction, and the acquisition may well make it stronger. Whether you are ready for the day its priorities are set by someone other than the people who built it, that is the question. YOUR question TO ASK.

No software was built for numbers that won’t sit still.

I’ve spent a lot of my time in demos sitting in on software contractor’s interests that are genuinely excited by the demo in action, help them ask the questions they’re too polite to ask or don’t know what they don’t know to ask themselves. And lately, dependent on the room, the same conversation keeps surfacing, even adjacent to the what the app in front of them can do capably. The procurement schedule.

Somewhere in your office there’s a procurement schedule that was true in January. Lead times confirmed, a metals package bought out, a color-coded log someone was quietly proud of. It survived the first re-baseline in February and the second in March. By now it’s been rebuilt enough times the file carries a version number in the double digits, and nobody opens it without bracing first. I watched a purchasing manager scroll through one of these on a shared screen last month and apologize for it, like the mess was hers. It wasn’t.

Here’s the part worth sitting with: not one of those re-baselines happened because someone got it wrong. The numbers were right when they went in. The inputs just won’t hold still. Associated Builders and Contractors wrote about this this Spring. Construction input prices have risen more in the first four months of 2026 than in the previous three years combined, with metals doing most of the damage. Steel and aluminum are carrying a 50% duty now, and copper has been on the same ride. Ask any electrical contractor what that’s done to their year. The wire is the job, and the margin moves with the metal.

And it’s happening in the strangest market I’ve seen in a long time. Data-center work is booming. More mega projects keep getting announced, and the contractors that touch that work are sitting on the healthiest backlog in our industry. At the same time, the contractors feeding all of it can’t get a material price to sit still long enough to buy against. Plenty of work, no stable inputs.

*So contractors do the reasonable thing. They go shopping for control. And this is where I come in, because I’m usually the one in the room when a very competent salesperson says “real-time visibility” and “procurement intelligence,” and a row of smart, poker-faced people start nodding. Because visibility is exactly what they don’t have and would love to buy. They’re right to want it. The mistake is quieter than that. It’s in what they think they’re buying.

Here’s what I usually end up concluding, after the meeting is over. No software on earth can tell you what steel will cost in September. Not because these types of softwares aren’t excellent. But because this was never a software problem. The price gets set far upstream of your Gantt chart, by forces that have never once consulted your schedule. A tool can’t model its way around that. Nobody’s can to my knowledge.

What good procurement software actually does is narrower, and more useful than some of the demos let on. It tells you fast where you’re exposed. It tells you which packages sit on a single supplier, which buyouts are still open, what moves the second a price does. It turns a three-day scramble into a three-hour one. But that speed is only worth something if a decision is waiting at the end of it. The tool can tell you in ten minutes that your switchgear is exposed to a metal that just jumped. It can’t tell you that you qualified a second supplier last quarter, because you didn’t. It can’t pull an escalation clause out of a contract that doesn’t have one. It hands you the problem faster, and then it waits for you.

The same fiction runs the other direction, on the bid. I’ve watched estimators carry a material-escalation contingency and then have to defend a number that’s really a guess about the next twelve months. Carry too little and you eat the swing. Carry too much and you lose the job to someone who carried less and will eat it later. There’s a whole shelf of software sold to make that number more precise. Precision was never the problem. The number is unknowable, and no amount of dashboard resolution makes an unknowable number known.

So here’s where it comes apart on real jobs, and I’ve seen it more than once. A firm buys the platform expecting it to make the cost problem stop. Six months later the cost problem hasn’t stopped. It was never theirs to solve. And guess what the platform takes the blame for a job it was never hired to do. It becomes the tool that “didn’t work,” gets half-used, and joins the little graveyard of software every contractor keeps: the ones that were going to change everything. The tool didn’t fail. The decision behind it did. Somebody bought a crystal ball and got a mirror, and didn’t love seeing their own operation looking back.

The firms riding this out aren’t the ones with the best procurement software. They’re the ones who decided, before they bought anything, to be hard to surprise. More than one qualified supplier on the packages that matter. Contracts that price the volatility in instead of wishing it away. Buyouts run on a cadence that assumes the number will move, because it will. For those firms the software is a multiplier, absolutely. It makes a good reflex faster. For everyone else it’s an expensive way to watch yourself get caught flat-footed in higher resolution.

That’s the whole thing I wish I could say in the demo, before anyone signs. The price will move again, probably before the quarter is out. It has never once waited for a procurement schedule to be ready, and it isn’t going to start now. The only thing that was ever in your hands is whether your operation was built to move when the market did. And we all know that gets decided long before anyone books a demo. The software can only ever be as good as the decision you made before you went looking for it.

THIS ONE CAUGHT MY EYE 👁️

The best thing I read on procurement this week didn't come from construction at all. A strategic-sourcing guy named Abdulaziz Alghamdi drew the line I keep trying to draw for contractors: buying executes a transaction, procurement creates value.

“Anyone can place an order, and most software is very good at helping you place one faster. The part that protects your margin when the price moves is everything underneath the order. The supplier relationships, the risk assessment, the contract terms and that isn't a tool you buy. It's a discipline you build.”

BEFORE YOU BUY™

Trimble Materials (formerly StructShare)

The Critical Path

In plain operational terms, this is the system that runs the material-buying cycle for a trade contractor or self-performing GC. A field crew requests material from the job, the request runs through approval, becomes a purchase order or an RFQ out to suppliers, gets received against, and reconciles against the invoice. This is all in one place, connecting the field, the office, the warehouse, and the supplier instead of the usual chain of texts, spreadsheets, and a purchasing manager’s memory. It was built for MEP and specialty contractors, which is exactly the audience the tariff squeeze hits hardest, and it gives you something most firms genuinely lack: a live view of what you are spending and what you are exposed to, by job and by package.

For that to be worth the line item, a few things have to be true about your operation before the software ever arrives. The field has to actually requisition through it rather than around it, because a materials platform that the crew bypasses is an expensive PO logger. You need more than one qualified supplier loaded on the packages that matter, or the visibility shows you an exposure you can’t do anything about. Your cost codes have to be clean enough that the data means something. And someone’s job has to be to act on what the system surfaces super fast or the speed it gives you drains out the bottom.

Where it comes apart is rarely the product and almost always the readiness behind it. The real-time exposure view only pays off if you have already built the supplier optionality and the contract terms to respond when the number moves; the tool makes a prepared firm faster and leaves an unprepared one watching the same problem in sharper focus. There is also a newer wrinkle worth naming: StructShare was acquired by Trimble in 2025 and now sits inside Trimble Materials, part of a much larger portfolio. That brings real integration upside with Trimble’s construction stack, and it also means the roadmap and the support priorities now answer to an ecosystem, not to a single product you fell for in a demo. That is not a strike against it. It is a question to ask out loud.

The one question worth asking before any demo is not whether it can track your purchase orders we know everything tracks purchase orders. It is this: when copper moves next week, how many clicks until I can see every open package exposed to it, and is there a person on my team whose actual job is to act on that view? If you can’t answer the second half, the first half won’t save you.

The honest bottom line: this is a really strong, well-built materials platform, and for an MEP firm or a self-performing GC that has already decided to be hard to surprise, it is a real multiplier on a good reflex. It will not manufacture a reflex that isn’t there. The tool is not the question. Whether your operation is built to move when the number moves that is.

Last week I described the meeting that happens in construction firms just about every six months. You know it. That software that has been running on that one project for eighteen months. You hear the results are acceptable. Nobody calls it a failure. Nobody calls it a success. You hear their scheduling another review.

That meeting has two sides of the table.

This week I’m looking at this from the other one. Because the other side of the table has something worth hearing and because the wall between construction professionals and the technology built to serve them, (at least in my experience), won’t come down by accident.

The number nobody posts openly on the wall. 95%.

That is the share of generative AI pilots that deliver zero measurable financial return, according to MIT’s 2025 GenAI Divide report. A study I came across based on 150 executive interviews, 350 employee surveys, and analysis of 300 public AI deployments. S&P Global confirmed it from a different angle: 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before. Nearly half of all proof-of-concepts get scrapped before they ever reach production.

Source: MIT GenAI Divide Report — reported Fortune CFO Daily August 18 2025.

A survey by Bain & Co. reveals that many companies are falling short of anticipated cost savings from AI, with 40% showing reductions of just 10% or less, Bloomberg reports. Conducted in April, the survey of 951 respondents at companies generating over $100 million in revenue found that only a small minority — 4% globally — reached AI-related savings greater than 30%. The underperformance “should be making executives uncomfortable,” Bain says, given that many are approving AI budgets in anticipation of cost reductions.

Every vendor with a pipeline report and a customer success team understands the realities. They live it. They watch it happen across their entire customer base simultaneously. They know which pilots are going to stall before the contractor does.

And then they file the proposal anyway.

Here is what I want to say about that. And I want to say it without turning vendors into the villain, because the villain framing is exactly what keeps the wall standing.

Taking that deal is rational. Short-term revenue is real. The cost of a failed deployment lands on both the contractor’s operation AND the vendor’s balance sheet. The customer success manager absorbs the relationship. The renewal holds, sure. From a purely commercial perspective, accepting a pilot from a firm that is not ready for full deployment seems like not a bad decision. It is just not a good one either. I think this is actually how some of that wall got built up to begin with.

And the construction industry deserves better than a technology ecosystem that optimizes for deals over deployments. This is the kind of example scenario that made me start my own company, Intelligent Construction Opportunities.

What a good flight plan actually is

Nobody questions the need for a hand tool, a power tool, or a piece of heavy machinery. Nobody stands at the gate of a construction site and debates whether a concrete pump serves a purpose. The tool exists. The application is understood. The crew knows how to use it because the conditions for using it correctly have been long established long before anyone shows up.

Technology has to work the same way. Not because construction professionals are resistant to change. That narrative is tired and wrong and frankly insulting to an industry that builds things that outlast everyone involved in building them. But because no tool works without the conditions that make it useful. And right now those conditions are being treated as someone else’s problem.

A pilot is not a form. It is not a compliance document. It is the agreement between every party involved about what success looks like before the pilot leaves the ground. I’m talking a living strategy. The fuel. The conditions that will ground the pilot before it departs. And the criteria that confirms you are starting to see the changes and outcomes the tech is capable of producing.

Most construction technology pilots never do the reconnaissance!

The vendor executes a proposal. The contractor signs the contract. A project gets selected for the pilot. A timeline gets agreed. And then the pilot begins with everyone assuming that success is self-evident. That results will speak for themselves, that adoption will follow performance, that a technically impressive pilot will naturally become a deployment when the time comes.

It doesn’t happen often enough. Not because the technology failed. Because nobody agreed on what the technology was supposed to prove, who would make the call when it proved it, or what would happen if the conditions for success were never met.

The question the vendor should be asking

There is a practitioner working in AI and data in construction named Omkar Jedhe who posted something recently that I happen to agree with. He described why most AI pilots in construction succeed. His quotation marks around succeed, not mine — and then quietly stall.

His diagnosis: the reason is usually not the model. It is what happens around it. No clear owner for acting on AI insights. Signals arriving too late to influence decisions. Outputs that do not align with how site teams actually work. Unclear accountability when the technology is advising rather than deciding.

His conditions for when a pilot actually becomes adoption: it fits existing workflows. Responsibility is clear. It reduces cognitive load instead of adding to it. Teams trust when and why a signal appears. Read that last one again. Teams trust when and why a signal appears.

That is not a technology problem. That is a relationship problem. And it is one that a vendor could identify and help solve before a single line of contract is signed. The vendor who walks into a pilot qualification conversation and asks: do your field teams currently trust the signals your existing systems generate? That vendor is not slowing down the sale. They are preventing the deployment failure that makes everyone in this industry a little more cynical about technology next time around.

The vendor who asks those questions is filing the flight plan, and the pilot strategy. And they are doing something this industry desperately needs more of. Treating construction professionals as partners in solving a problem rather than accounts to be managed through a failure cycle.

The contractor’s half of this

The contractor who enters a pilot without having done the organizational work that deployment requires is also making a choice. They are choosing the appearance of progress over the harder conversation about whether the data environment, the change management capability, and the leadership commitment are actually ready.

I realize this conversation is uncomfortable. It is also the only one that matters.

Because here is the thing. The technology that could genuinely help transform how construction gets delivered is real. It exists. There are platforms that have changed how contractors operate, how crews communicate, and how projects close. The problem is not that the technology is not good enough. The problem is that the conditions for using it correctly are being treated like someone else’s job to create.

They are not. They belong to both sides of the table.

The contractor who says we are not ready yet is not admitting failure. They are doing the most valuable thing either party can do before a pilot begins — telling the truth about where the operation actually is. That honesty is the foundation of every deployment that actually works.

What both parties actually want — and could have

The vendor wants a deployment. Not a reference account. Not a pilot on extended renewal. A deployment that generates case studies, product feedback, real user data, and the proof that the platform works in actual field conditions. That outcome is better for the vendor’s product, their reputation, and their long-term relationship with an industry that has a long memory for promises that did not land.

The contractor wants a platform that performs. Not a controlled evaluation. Not a technology that works beautifully in the demo and stalls in the field because the crew doesn’t trust what it makes their hard work look like, and the super that has his own system that he feels is more secure, and he is comfortable using.

Both parties want the same thing. The wall between them is not made of hostility. It is made of assumptions. The assumption that the vendor cannot understand field reality. The assumption that the contractor will not do the organizational work. The assumption that the pilot is a low-risk way to evaluate something when it is actually a high-cost way to defer a decision. Tear down the assumption and the wall comes with it.

The question worth asking on both sides of the table

For contractors: before you agree to a pilot, can you name the specific conditions that would cause you to commit to full deployment. And who in your organization has the authority to make that call when those conditions are met?

For vendors: before you accept a pilot, have you asked whether the contractor’s operation is actually ready for what your deployment requires? Are you willing to have that conversation even when it slows down the deal?

If neither party can answer both questions, the pilot is already drifting. The pilot will produce results. It will not produce a deployment. And in six months there will be another review.

The tools exist. The talent exists on both sides. The only thing missing is the conversation that should happen before the pilot leaves the ground.

File the flight plan.

👀 This One Caught My Eye

This one came from a practitioner working in AI and data in construction. Not a vendor. Not a consultant with a product to sell. Someone building systems inside a real construction operation and watching the deployment gap from the inside.

He posted about why most AI pilots in construction succeed — his quotation marks, not mine — and then quietly stall.

“Many AI pilots in construction don’t fail technically. They produce insights, dashboards, even early wins. And yet, a few months later, they’re rarely part of day-to-day decisions on site. The reason is usually not the model. It’s what happens around it. No clear owner for acting on AI insights. Signals arriving too late to influence decisions. Outputs that don’t align with how site teams actually work. Unclear accountability when AI is ‘advising.’”

His conditions for when a pilot becomes adoption:

“It fits existing workflows. Responsibility remains clear. It reduces cognitive load instead of adding to it. Teams trust when and why a signal appears.”

And his closing line — which I think is the most important thing in this post:

“The real challenge isn’t proving that AI can work. It’s designing systems that teams are willing to rely on, day after day. That’s where most of the work still lies.”

He is describing exactly what the flight plan is supposed to produce. Not a technically successful pilot. A system teams are willing to rely on. Day after day. In the conditions where the work actually happens.

That is the standard both sides of the table should be holding each other to. And it starts with a conversation nobody is having before the pilot begins.

Post by Omkar Jedhe, AI and Data in Construction, Member Data Leadership Team. LinkedIn — search Omkar Jedhe.

BEFORE YOU BUY™

Every week this section does one thing: asks the questions the demo didn’t.

Before You Buy™ is not a product review. It is not a ranking. It is not affiliated with any vendor. It is a structured look at what has to be true about your operations your crews, your data, your culture, your project conditions, long before a technology purchase has a real chance of delivering what it promised in the conference room. The tool is rarely the problem. The decision behind it almost always is.

Before You Buy™ — Fieldwire by Hilti

What it actually does in plain language

Fieldwire is a mobile-first field execution platform owned by Hilti Group since 2022. Used on more than one million projects worldwide. In practical terms it gives field teams digital access to drawings, task management, punch lists, and site communications directly on a mobile device, truly designed for the realities of construction site use. Fast. Reliable on mobile. Functional offline. Intuitive enough for crews without technical training.

Hilti’s acquisition brought serious resources behind the platform. Fieldwire is not a scrappy startup with onboarding problems. It scores 8.7 out of 10 on G2 for ease of setup even ahead of Procore at 8.2. The onboarding is not the issue.

The issue is what happens when the pilot ends and the plan to roll it out was never filed. A platform that is easy to start is easy to pilot. And a platform that is easy to pilot is easy to run indefinitely in permanent evaluation mode just because the pilot never surfaces the harder question about what full deployment actually requires.

What has to be true for this to actually work

Your primary project management platform has to be defined and stable. Fieldwire is a field execution layer. It’s meant to sit alongside a system that manages RFIs, submittals, contracts, cost, and schedule. If that system doesn’t exist or is not formally and consistently used, Fieldwire will be deployed into a coordination gap it was not designed to fill alone. The pilot will succeed. But full deployment is what will reveal the gap.

Your field teams have to trust their signals before they rely on it. Fieldwire generates status updates, completion flags, and issue notifications. For those signals to influence daily decisions the field team has to trust that what they enter is being acted on. A motivated pilot team creates that trust. A full deployment rolled out to crews who were not part of the pilot does not obviously inherit it.

You have to already have standard processes implemented that you already use and apply to your projects. A hospital, a data center, and an office renovation don’t share the same punch list workflow. If your pilot ran on one project type you have not tested the platform. You have tested a favorable version of it.

Losing the Critical Path

The pilot runs well. The field team adopts quickly. The project closes cleanly. Leadership approves full deployment. Then the second project team uses it inconsistently. The third has a superintendent who considers it an administrative burden. By the fourth project the VDC team is updating drawings in Fieldwire and the field trades are working from a shared drive folder because the super knows where everything is and frankly for him it’s just faster.

The coordination problem Fieldwire was supposed to solve is now larger than before the platform arrived, because from the field’s perspective at least the shared drive folder was consistently wrong in the same way. That is not a Fieldwire failure. That is what happens when a platform is deployed into a field execution culture the pilot was never designed to test.

The one question worth asking — on both sides of the table

Before Fieldwire accepted your pilot, did they ask you about how your current field teams receive, trust, and act on drawing updates and task assignments?

If the answer is they ran a great demo, offered a trial on your next project, and assigned a customer success manager I’m going to say the flight plan for this mission was not properly filed. The pilot was a commercial decision not a readiness assessment. And if you accepted without asking those questions yourself, both parties departed without a plan.

On the hand, if you got the answers to the right questions, then I don’t have to tell you are clearly getting the results you signed up for! Good on ya!

The vendor’s side of this

Hilti and Fieldwire have the resources, the methodology, and the construction industry depth to ask the right questions before a pilot begins. Some of their customer success conversations do exactly that. The pattern described above is not inevitable. But it is what happens when commercial pressures to close the deal outweighs the organizational discipline to qualify the readiness behind it. The vendor who ask those questions are not losing deals. They are losing the deals that were going to fail anyway.

Bottom line

Fieldwire is a serious platform backed by one of the most respected companies in construction. For firms with a stable primary project management platform, standardized workflow practices across the project portfolio, and the organizational discipline to drive adoption beyond the motivated pilot team, it deserves serious evaluation and delivers on what it promises.

If those conditions are not in place, the pilot will succeed and the deployment will stall. Not because of the platform. Because the flight plan to go along with the pilot was never filed.

👷‍♀️There is a meeting that happens in construction firms approximately every six months. It is not on any official calendar. It has no formal agenda. But everyone in the room knows why they are there.

The platform being discussed has been live on one project for somewhere between eight and eighteen months. The results are acceptable. Not transformative. Acceptable. The vendor relationship is fine. The project team that ran the pilot has moved on to other work. The question on the table, I’m talking about the the one nobody quite says out loud, is whether to roll this thing out company-wide or quietly let it expire.

Nobody calls it a failure. Nobody calls it a success. They schedule another review in six months.

That meeting may be the most expensive thing happening in construction right now. Not because of what the platform costs. Because of what the decision not to decide is costing you every quarter you run the pilot again.

The numbers are worse than you think

The construction industry has developed a specific relationship with technology pilots.

According to a RICS research in 2025 surveying over 2,200 construction professionals, 34% of firms were in early pilot phases for AI and digital technologies. Less than 1% had achieved fully embedded organization-wide deployment. Read that again. Thirty-four percent were piloting. Less than one percent actually deployed at scale. That gap is not a technology problem. That is a decision problem wearing a technology problem’s clothes.

Source: RICS Global Construction Monitor Q1 2025, survey of 2,200+ construction professionals. rics.org

A separate industry analysis confirmed 78% of construction firms describe themselves as stuck in pilot phase, actively running technology experiments that have not converted into operational commitments. Meanwhile 70% of contractors report having no formal technology roadmap. No roadmap means the pilot has no defined path to become anything else. It just runs until someone cancels it or the vendor raises the renewal price enough to force a conversation.

The pilot was supposed to be the beginning. For many contractors it has become the destination.

How the perpetual pilot happens

It starts with the right intentions.

Usually a senior project manager, or digital solutions manager role identifies a platform worth evaluating. Eventually throughout the vendor process, leadership approves a controlled pilot on a specific project. The conditions are carefully chosen with a cooperative project team, a manageable scope, a vendor’s customer success team who show up for check-ins. The pilot produces results. Not transformative results, but defensible ones. The vendor case study practically writes itself.

Then the pilot ends and the real conversation begins.

Full deployment requires things the pilot did not. It requires standardizing data practices across every project, not just the pilot project. It requires retraining crews who were not part of the pilot and who have no emotional investment in its success. It requires integrating the platform with existing systems that were never designed to talk to each other. It requires someone to own the rollout organizationally and not the vendor, not the digital solutions manager alone, but a leadership-level commitment that this is how the firm operates now.

That organizational commitment almost never materializes. Not because leadership does not want the platform to succeed. Because the cost of commitment is visible and immediate while the cost of delay is diffuse and slow. So the pilot gets extended. The vendor gets a reduced renewal rate in exchange for patience. The platform lives on one or two projects indefinitely. The digital solutions manager manages the relationship. Nobody makes the call.

This is not a technology failure. This is risk management masquerading as evaluation.

What the pilot is actually protecting

The perpetual pilot exists because it serves some people’s interests.

The vendor gets recurring revenue and a reference account without the support burden of a full enterprise deployment. The project team that ran the pilot gets to keep using a tool they like without being responsible for rolling it out to crews who did not ask for it. Leadership gets to say they are investing in technology without making the organizational changes that real investment requires. And the digital solution manager gets to keep managing a controlled relationship without the exposure that comes from a company-wide failure.

The only party the pilot does not serve is the firm trying to get better at delivering work.

Because here is what the perpetual pilot actually costs. Every quarter a platform sits in permanent evaluation mode is a quarter where the data it should be generating is incomplete, inconsistent, and unusable at scale. The firm is not building the data discipline that full deployment requires. It is not developing the internal capability to support the platform when things go wrong on a real project under real pressure. It is not closing the adoption gap between the project teams who ran the pilot and the project teams who will eventually inherit the platform without context or ownership.

The pilot looks like progress. It is actually a very expensive way to avoid making a decision.

The organizational commitment nobody wants to name

Full deployment of any meaningful construction technology platform requires three things that pilots almost never test.

It requires a data environment that the platform can actually use. Most pilots succeed because the pilot project team manages the data carefully. Most full deployments stall because the data discipline that made the pilot work does not exist at the firm level. The platform did not fail. The data governance that should have preceded the pilot was never built.

It requires a change management process that treats the rollout as an operational transition, not a technology installation. The crews who were not part of the pilot are not resistant to technology. They are resistant to having a decision made for them without their input. That is a different problem and it requires a different solution than better training materials.

It requires someone in leadership whose job it is to make the call. Not to evaluate indefinitely. To decide. The digital solutions manager can recommend. The vendor can demonstrate. The pilot can prove. But until someone with organizational authority says this is how we operate now and means it, the platform will live in permanent evaluation mode regardless of how good the results are.

Most firms do not have that conversation. So the pilot runs another six months.

The question worth asking this week

Go find your longest-running pilot. The one that has been in evaluation for more than twelve months. The one with the acceptable results and the vendor who keeps offering to extend the trial terms.

Ask one question. Not whether the platform works. Not whether the results justify the cost. Ask whether your firm has done the organizational work that full deployment actually requires — the data standards, the change management process, the leadership commitment.

If the honest answer is no, the platform is not the problem. The pilot is.

And the six-month review you have scheduled is not going to change that.

👀 This Post Caught My Eye!

This one came from a construction technology professional based in Finland. Someone I know and who knows the landscape of construction very well. Someone who has watched this pattern long enough to say what he said plainly.

His post opened with three words that most digital solution managers have thought privately and but will rarely say in a meeting.

“Pilot projects in construction suck.”

What follows is not a complaint. It is a diagnosis. He argues that pilots fail not because of the technology but because firms never define what success actually looks like before they start. If you cannot name the criteria that would cause you to hit the gas and scale like measurable, confirmable criteria, then the pilot has no defined path to become anything else. It just runs until someone cancels it or the vendor offers a better renewal rate.

His challenge to vendors is the sharpest line in the post.

“If we agree to a pilot, it’s your job to make sure there is enough support and presence to show us clear results. What can you promise us?”

That question reframes the entire vendor relationship. The pilot is not a favor you are doing the vendor. It is a test they should be competing to pass. Most firms never ask it. Most vendors never hear it. And most pilots run endlessly as a result — taking a life of their own from project to project, as he puts it, until nobody can remember why they started.

Post by Eetu Heiska, construction technology professional at Production Flow Oy in cooperation with Sitedrive. LinkedIn

🔎 BEFORE YOU BUY™

Every week this section does one thing: asks the questions the demo didn’t.

Before You Buy™ is not a product review. It is not a ranking. It is not affiliated with any vendor. It is a structured look at what has to be true about your operations. Your crews, your data, your culture, and your project conditions all long before a technology purchase has a real chance of delivering what it promised in the conference room. The tool is rarely the problem. The decision behind it almost always is.

Before You Buy™ — Autodesk Forma

(formerly Autodesk Construction Cloud, formerly Autodesk Build)

What it actually does in plain language

Autodesk Forma is one of the two platforms that dominate construction project management alongside Procore and is the platform of choice for firms with significant investment in Autodesk’s design and BIM ecosystem. In March 2026 Autodesk rebranded Autodesk Construction Cloud as Forma, the latest in a series of name and architecture changes that have followed the platform since its origins in BIM 360.

In practical terms Forma consolidates document management, RFIs, submittals, daily reports, issue tracking, cost management, and model coordination into a single cloud environment accessible from desktop and mobile. The demo is genuinely impressive. One platform. One data environment. Full project visibility from preconstruction through closeout.

It is also one of the most evaluated platforms in mid-market construction right now. And the gap between what firms experience in a controlled evaluation and what they encounter in a full deployment is where this conversation actually begins.

What has to be true for this to actually work

Three conditions that pilots almost never test honestly.

Your field connectivity has to hold up in the conditions where your projects actually run, not the well-connected urban site where you ran the evaluation. Based on analysis of over 2,200 verified user reviews, slowdowns in low-connectivity environments are some of the field complaints. If your project mix includes rural sites, below-grade work, or any job site where cellular coverage is inconsistent, you have not tested the platform thoroughly. You have tested a favorable version of it.

Your workflows have to fit inside Forma’s architecture. On G2, 554 verified user reviews identify rigid predefined workflows as a primary limitation. A GC with standardized project delivery across similar project types will manage. A GC whose projects vary significantly in type, size, and scope will spend considerable time and money working around a platform that was not designed to flex easily.

Your integration costs have to be scoped before the purchase. The average contractor runs 11 discrete applications and only one-third exchange data without manual workarounds. Custom middleware can cost $50,000 per connection. What it costs to make it work in your specific environment is a separate conversation that rarely happens before you sign.

Losing the Critical Path

Generally speaking Autodesk, or not, your average implementation runs on a motivated team with adequate connectivity and a digital solutions manager managing adoption personally. Leadership approves full deployment. By project five the platform is being used inconsistently across the portfolio with some teams fully adopted, and then some teams logging in because someone is checking whether they logged in. The data environment shows partial information from compliant teams and nothing from resistant ones. The reporting is worse than before because at least the old system was consistently incomplete. That is not a technology failure. That is what happens when full deployment reveals the organizational conditions the evaluation was too controlled to expose.

The one question worth asking before any demo

On your last platform rollout and not the evaluation, but the full deployment, what percentage of your project teams adopted consistently within ninety days, and what happened to the teams that did not?

If you do not have a clear answer to that question it means your firm does not yet have the adoption infrastructure that full deployment of Forma requires. The platform will surface that gap. It will not close it.

Bottom line

Autodesk Forma deserves serious evaluation if your firm has reliable field connectivity across your project mix, standardizable workflows, a dedicated implementation function, and a track record of consistent adoption on previous platform rollouts.

If any of those conditions are missing, the evaluation will produce results you cannot replicate at scale. The question is not whether Forma works. Obviously it does. The question is whether your operation is built for what full deployment actually demands.

The $343 billion in Canadian public infrastructure now in active procurement is not a forecast. It is not a pipeline projection from an optimistic industry report. It is confirmed, and funded work. The largest year-over-year jump in twenty years of tracking, a $43 billion increase in a single year. Transit corridors. Hospitals. Energy infrastructure. Water systems. Projects that will define the physical landscape of this country for the next fifty years.

Source: ReNew Canada 2026 Top100 Projects Report, January 13, 2026. renewcanada.net

And right now, this quarter, the firms that will win meaningful portions of that work are making technology decisions that will determine whether they can actually deliver on what they win. Not whether they can win it. Whether they can deliver it.

That distinction is where most firms stop thinking carefully. And it is exactly where the gap opens.

What the data says about how firms make technology decisions

A couple of independent research organizations have looked at how construction firms evaluate and deploy technology. Their findings do not agree on much. They agree on this.

McKinsey calls it the tech-first approach. We’re talking about companies deploying technology tools before determining whether and how those tools can actually improve their operations. The result is what McKinsey describes as digital organ rejection: a solution that fails to deliver visible benefits, a workforce that does not adopt it, and a capital investment that produces a report nobody reads and a platform nobody trusts.

Source: Decoding Digital Transformation in Construction, McKinsey

Dodge Construction Network asked contractors directly about their data quality. The foundation that every technology investment in scheduling, project controls, cost management, and AI-assisted anything depends on. Only 26% rated their data quality as high. That is the number sitting underneath every technology decision being made right now. Not in the demo. In the operation.

Source: AI for Contractors, Dodge Construction Network in partnership with CMiC, December 5, 2025

Two sources. Two different perspectives. One structural problem: firms are buying technology capability they are not operationally positioned to use.

In a normal market, that gap produces cost overruns and shelf-ware. In a $343 billion infrastructure market with owner requirements that have never been more demanding and delivery timelines that have never been less forgiving, that gap produces something more expensive. It produces the moment when you have the contract and do not have the capability. And that moment arrives on a schedule the owner sets, not yours.

What this pipeline actually requires

The companies that will perform on this work are not the ones with the most sophisticated technology stack. They are the ones whose technology decisions were made honestly, with a clear understanding of what their operation can actually support, what their crews will actually use, and what their data environment can actually produce.

Mega-project owners are not evaluating your platform. They are evaluating your outputs. Schedule data they can trust. Cost reporting that reflects what is actually happening on the project. Change management processes that produce defensible documentation under the conditions of a live infrastructure delivery. Commissioning records that meet handover requirements that are more demanding than anything most GCs have faced on commercial work.

The technology behind those outputs does not matter to the owner. The outputs do. And the firms that will struggle are the ones who bought the platform that produces the outputs in a demo environment and then discovered that producing them in a real project environment requires data discipline, adoption consistency, and operational infrastructure they did not build before they signed the contract.

That is not a technology problem. That is a decision problem. And it is the decision problem this series has been describing, and is focussed on the most.

The companies already positioning for this work

There is a version of this that is already happening. Firms that have been building their technology and data infrastructure deliberately. And not chasing features, not responding to vendor pressure, not buying platforms because a competitor bought them. They are walking into this procurement moment with something more valuable than a demo. They have defensible answers to the questions mega-project owners will ask.

Can you demonstrate schedule performance data from comparable project types? Can you show owner-side reporting that meets the documentation requirements this project demands? Can you produce evidence that your technology investments deliver adoption rates high enough to generate the data quality these outputs require?

The firms that built toward those answers are not scrambling right now. The firms that bought technology the way McKinsey describes — tool first, operational fit second, are.

The $343 billion pipeline does not care which category you are in. It will move forward either way. The only question is which firms are in the room when the decisions get made, and whether the technology decisions they made this quarter will hold up when the project is live and the owners are watching.

This Post Caught My Eye 👁️

This one came from a Project Controls Manager. Not a vendor. Not a consultant. Someone who works inside the problem every day on capital projects.

“3 things I wish someone had told me earlier in my project controls career:

1 — The forecast matters more than the report. Anyone can tell leadership what happened last month. The value is in telling them what’s coming and giving them time to act.

2 — A schedule nobody believes is worse than no schedule at all. If the team isn’t using it to make decisions, it’s just a document. The best schedules reflect how work actually gets done.

3 — Relationships are a controls tool. The best early warning system isn’t software. It’s the site super who tells you something’s off before it shows up in the data.

Technical skills got me into this profession. But these three things are what made me better at it.”

— Rezvan Nasab, Project Controls Manager

The third point is the one that matters for this issue. Canada has $343 billion in confirmed infrastructure work moving through procurement right now. Firms are evaluating platforms, comparing features, negotiating licenses. And a Project Controls Manager with capital project experience is telling you the most reliable signal in her entire discipline is a conversation with a superintendent. Not a dashboard. Not a forecast. A relationship. The firms that understand that technology organizes the information but cannot replace the person who knows what the information is not telling you — those are the firms this pipeline rewards.

Post by Rezvan Nasab, Project Controls Manager at IO. linkedin.com

BEFORE YOU BUY™ 🛒

Every week this section does one thing: asks the questions the demo didn’t.

Before You Buy™ is not a product review. It is not a ranking. It is not affiliated with any vendor. It is a structured look at what has to be true about your operations, your crews, your data, your culture, and your project conditions long before a technology purchase has a real chance of delivering what it promised in the conference room. The tool is rarely the problem. The decision behind it almost always is.

Before You Buy™ — Oracle Primavera P6

What it actually does in plain language

Oracle Primavera P6 is the industry standard for enterprise project scheduling and portfolio management on large, complex construction and infrastructure projects. It has held that position for over four decades. When mega-project owners specify scheduling requirements in their contract documents, they are almost always describing outputs that P6 is designed to produce with critical path method schedules, resource-loaded baselines, earned value reporting, float analysis, and schedule narrative that meets the schedule quality standards major infrastructure owners require.

P6 does not make projects go faster. It makes the management of complex project schedules defensible. On a project with thousands of activities, dozens of subcontractors, and an owner who requires monthly schedule updates with variance analysis and look-ahead reporting, P6 is the environment where that work gets done. The firms that know how to use it properly walk into owner meetings with documentation that holds up under scrutiny. The firms that do not are explaining why their schedule does not match what is happening in the field.

In a demo, P6 looks like the direct answer to everything this issue described — the platform mega-project owners know, the platform contract documents reference, the platform your competitors are using on comparable work. The decision to buy it feels straightforward.

The decision to buy it is not the decision that matters.

What has to be true for this to actually work

P6 is not software that improves a bad planning process. It is software that scales a good one. Every condition that has to exist in your operation before P6 delivers anything meaningful is a condition that has to exist before you pursue mega-project work at all. The platform surfaces the gap. It does not close it.

Your scheduling function has to be a dedicated capability, not a shared responsibility. On complex infrastructure work, the P6 schedule is a live document that requires continuous updating, variance analysis, and narrative reporting. That is a full-time job on a large project. Firms that assign schedule maintenance to a PM who is also managing submittals, RFIs, and owner communications will produce a P6 schedule that reflects the project as it was planned, not the project as it is being built. Mega-project owners will identify that gap in the first schedule review meeting.

Your data has to be trusted by the people entering it. P6 is only as accurate as the field data that feeds it. If your superintendents do not believe the schedule reflects how work actually gets done and only 26% of contractors rate their data quality as high, they will not update it honestly. They will report percent complete numbers that satisfy the requirement without reflecting operational reality. The schedule becomes a compliance document, not a management tool. On a mega-project, that distinction costs money in ways that are difficult to recover from once the pattern is established.

Your team has to have the training to use it at the level the project requires. P6 is not intuitive. It is powerful, it is complex, and it rewards expertise in ways that are not available to a team learning it under delivery pressure. The firms that perform on infrastructure work with P6 have schedulers who have used it on comparable project types before. The firms that struggle have schedulers who are competent and learning on the job. That learning curve is real and the project timeline does not accommodate it.

Where this comes apart on real jobs

The failure mode for P6 on a mega-project is not that the software stops working. It is that the schedule stops being believed.

It usually starts in month two or three. The baseline was built carefully during preconstruction. The first progress update goes in. Then the second. The schedule is being maintained on time and the reports are going out. But the project team stops looking at the schedule to make decisions because the schedule does not reflect how work is actually sequenced in the field. The super has his own look-ahead on a whiteboard in the trailer. The PM has a spreadsheet tracking the critical path items that actually matter. The P6 schedule is the official record that satisfies the contract requirement.

By month six the gap between the P6 schedule and operational reality is wide enough that updating it honestly would require explaining the variance to the owner. So the updates continue to reflect optimistic projections rather than actual conditions. The schedule becomes a document that tracks what everyone hopes will happen rather than what is happening. And when the owner’s project controls team runs a schedule quality analysis, which they will, because mega-project owners have project controls teams, the credibility problem is no longer recoverable in a conversation.

That is not a P6 failure. That is what happens when P6 is deployed into a planning culture that was not ready for what it requires.

The one question worth asking before any demo

On your last three comparable projects, did your schedule drive daily field decisions or did it document the story of what happened after the fact?

If the honest answer is the second one, P6 will not change that. No scheduling platform will. The work that needs to happen first is cultural and operational, not technological. A firm that does not make decisions from schedule data on a $50 million project will not make decisions from schedule data on a $500 million project. It will produce better-formatted reports of decisions it made for other reasons.

The infrastructure pipeline does not require you to own P6. It requires you to produce scheduling outputs that mega-project owners can trust. Whether P6 is the right tool to produce those outputs in your operation depends entirely on whether the conditions that make P6 work actually exist in your firm right now.

Bottom line

Oracle Primavera P6 is the legitimate standard for mega-project scheduling and the platform you will encounter in contract documents, owner requirements, and joint venture conversations as you pursue this pipeline. If your firm has a dedicated scheduling function, data practices your field teams trust, and project controls personnel with P6 experience on comparable work, it belongs in your operation and this pipeline is the moment to prove it.

If any of those conditions are missing, the decision to buy P6 is the beginning of a longer conversation about operational readiness that should happen before the contract is signed, not after the first schedule review meeting with the owner.

The infrastructure is funded. The procurement is moving. The firms that will perform are making technology decisions right now with clear eyes about what their operation can actually support. Start with that conversation first.

I was in a conversation a while ago. The kind that happens online, in public, where people say things they might not say in a boardroom. I made the observation that the field should have a say in technology decisions. I was not being provocative. I was not making a political argument. I was just saying what seems to me to be obvious: the people who have to use the tool every day, in the conditions it was never quite designed for, on schedules that do not care what the demo promised, yes I think “those” people should be in the room when technology decisions get made.

An operations executive disagreed. Strongly. And what struck me was not that he disagreed. It was what he was actually protecting. It was not efficiency. It was not process. It was control. The decision was his to make. The field’s job was to execute it.

I have been watching that dynamic play out in construction for long enough to know it is not unique to that one executive. It is baked into how the industry was built.

Construction does not have a workforce problem. It has a business model that was never designed to value the workforce it now desperately needs.

The business model of construction was built on a specific premise. Labor is a variable cost. You hire for the job. You finish the job. The crew disperses. That is not a criticism — it was a rational response to how construction work actually moved. Projects ended. Crews relocated. There was no institutional reason to build the kind of workforce infrastructure that a manufacturer or a hospital or a logistics company would build, because the relationship between the firm and the worker was never designed to be permanent or consistent.

That model worked for decades. I would argue it is breaking now in ways the industry has not fully reckoned with.

The workforce is aging out faster than it is being replaced. The industry needs approximately 439,000 additional workers between now and 2026. Roughly 41% of the current workforce is expected to retire by 2031. Construction turnover runs at approximately 5.9% which is well above the national average of 3.7%. Median attrition in some segments is closer to 20%. These are not abstract statistics. They are descriptions of an industry that is losing experienced people faster than it can develop new ones.

But here is the part that connects to every issue I have written in this series, and the part I do not think gets said directly enough.

Technology adoption requires behavioral consistency across crews. You cannot get that from a workforce model built around interchangeable labor.

This is the structural problem underneath every technology failure I have watched play out. Not the vendor. Not the platform. Not the implementation partner. The assumption that you can layer a technology requiring consistent, disciplined, daily behavior on top of a workforce model that was never designed to produce consistent, disciplined, daily behavior and get a different result than the one you keep getting.

The failure is not happening at the demo. It is not happening at go-live. It is happening in the gap between what the technology requires and what the operating model was built to deliver. And most of the industry is still treating it as a technology problem.

What the Field Is Actually Saying

I follow a number of seasoned construction professionals online. Construction professionals who have built things, run crews, carried the weight of a project that was not going the way it was supposed to go. There is a consistent thread in what they say, and it does not get heard nearly as often as it should.

The technology is not the frustration. The decision-making process around it is. The feeling that a platform gets selected in a conference room by people who have never had to use it while walking a job site, that it gets handed down with a rollout plan designed around ideal conditions and not real ones, that the people who know exactly why it is going to fail in week three are not in the room when the contract gets signed.

One superintendent put it plainly in a recent conversation about software implementation. He was talking about the reality of being expected to manage project information on a platform while physically crossing a job site that takes fifteen minutes to walk from end to end. His words, not mine: he does not have time to check for a message or chat back a teammate. Call him. He is on the move.

That is not a complaint about software. That is a description of a decision made without him. And it is the same description I have been hearing, in different words, from field professionals across every technology category in this industry for years.

The pervasive undercurrent in those conversations is this: nobody without bloody knuckles can fix our problems. Nobody who has not had to force a pipe into a trench that was not cut wide enough, who has not made a call at 6 in the morning that the schedule could not absorb, who has not stood in front of a crew and tried to explain why the tool that was supposed to make their day easier has made it harder. Nobody like that gets to decide what changes.

I understand that position. I think it is earned. And I also think it is the thing that is keeping the industry from having the honest conversation it needs to have.

The field is not resistant to change. It is resistant to decisions made without them. Those are not the same thing.

Because here is what I believe, and it is the belief that the entire system I have built is grounded in: the field is not resistant to change. It is resistant to decisions made without them. Those are not the same thing. And until the business model recognizes that distinction and I mean structurally, not just rhetorically, the technology problem is going to keep looking like a technology problem when it is actually a respect problem dressed up in a software budget.

The Role That Was Never in the Org Chart

Something else has been happening quietly inside construction firms over the last several years, and it is worth naming directly because it speaks to exactly this problem.

Firms have started hiring for it. Digital Solution Managers. Construction Technology Directors. VDC Managers. Innovation Leads. Procore has them. Autodesk has them. The largest GCs and MEP contractors have created entire departments around the function. And the firms that cannot yet afford a department have at minimum created a role.

I want to be precise about what that hiring decision actually represents. It is not a sign that the industry has solved the structural problem. It is a sign that the structural problem became visible enough, and expensive enough, that firms started reaching for a person to manage it. The business model did not produce the capability it needed organically, so it created a position to compensate for the gap.

That person, and if you are reading this in that role, I am talking directly to you now, is sitting inside an organization that hired them to solve a structural problem with a functional one. They have a technology budget. They have a mandate to drive adoption. They have an org chart that was not designed with their role in mind. The field does not report to them. The superintendents do not answer to them. The project managers have their own priorities. And they are expected to produce measurable technology ROI inside a business model that was built before their job title existed.

That is not a technology challenge. That is a structural one. And the firms that hired this role and then left everything else unchanged are going to keep wondering why the adoption numbers are not moving.

The firms that have hired a Digital Solution Manager and then left everything else unchanged are going to keep wondering why the adoption numbers are not moving.

The firms that made the bet work are the ones that gave the role actual authority. Not just budget. Authority over the decision-making process. A seat in the room before the contract is signed, not after. A structured way of bringing field input into the evaluation before the vendor is selected. A mandate that includes the right to slow down a purchase that the field is not ready for, even when leadership is excited about the demo.

That is a different kind of role than the one most firms created. And building it requires the business model to shift in ways that go well beyond a job description.

The Shift That Is Already Happening

The firms capturing the most complex, highest-margin work in construction right now are not winning because they bought better software. They are winning because somewhere in the last decade they made a decision and quietly, without much fanfare to treat operational consistency as a competitive advantage rather than a management inconvenience.

That means field leaders with real authority over process, not just production. It means technology decisions made with input from the people who will use the tools, not just the people who will sign the invoice. It means treating training not as a one-time implementation cost but as an ongoing operational investment. It means building the kind of workforce infrastructure that was never part of the original business model because the original business model did not require it.

It means, in short, that the business model has to shift. Not around technology. Around people.

The firms that have figured this out are not being rewarded for being progressive or forward-thinking. They are being rewarded for being disciplined. The ones that have not yet made this shift are not failing because they bought the wrong software. They are failing because the operating model underneath the software was not built to make it work.

That is the conversation worth having. Not which platform to buy next. Whether the organization running it has been built to support what the platform requires.

This Caught my Eye

One post that stopped me while I was writing this issue.

This one came from an investor and principal’s representative perspective — which is exactly why it caught my attention. Because the frustration I hear most often comes from the field looking up. This one is looking down and seeing the same problem from the other direction.

The post, in part:

“Many viewed [the Superintendent role] as a ‘paper pusher’ — reviewing extensions of time, assessing claims, recording minutes. But that’s just one layer. Beyond documentation, Superintendents can drive project success… The best ones think several steps ahead — not just to keep things moving, but to prevent inefficiencies and out-of-sequence work. They don’t just track what’s needed — they constantly review drawings, clarify information, and help reduce RFIs and escalations.”

The argument here is that the Superintendent role has been flattened into a documentation function when its real value is foresight. Getting ahead of approvals. Reducing RFIs before they happen. Thinking several steps ahead while everyone else is reacting to what is already on fire.

Sound familiar? It should. Because the technology decisions that fail in construction fail for exactly the same reason. Someone was managing the paperwork when they should have been asking what comes next. The role gets defined by its administrative layer and the operational intelligence underneath it goes unused.

What I want you to notice is the line about personality and drive — whether the Superintendent is genuinely invested in the project. That is not a skills question.

That is a culture question. And no platform, no dashboard, and no implementation plan has ever answered it.

An investor can see it clearly from above. The field feels it clearly from below. The people in the middle. The ones making the technology decisions are the ones still trying to figure out why the gap keeps existing.

Before You Buy™

The Question No Software Can Answer

This week I am not going to name a platform. Not because there are no relevant platforms because there are several worth examining in this category. No but because the question that needs to be asked this week is one that belongs before the software conversation, not inside it.

Before you buy any workforce management, field execution, or operational standardization technology, sit with this question honestly. Not in a planning meeting. Not in a budget review. Alone, with the actual answer.

Does your contracting business have a structured way of finding out what the field actually thinks before you ask them to adopt new technology?

Not a survey distributed after the decision is made. Not some internal town hall where the rollout is announced and questions are invited. A genuine, structured process for gathering field input before the technology is selected, before the vendor is engaged, before the budget is allocated.

If the honest answer is no, and for many this is, then the question is not which technology to buy. The question is what has to be true about how your firm makes decisions before any technology you purchase has a real chance of working.

The business model produced the decision-making process. The decision-making process produced the technology failures. No software fixes that sequence. Only a deliberate choice to rebuild it does.

That is the only question worth asking this week. And it is the one most evaluation processes never get close to.

This moment, I mean the moment where your recommendation meets someone else’s accumulated experience, and loses, is the most professionally exposed place a Digital Solution Manager can be. You can’t outrank it. You can’t out-logic it. The only currency that works in that room is field credibility, and if you don’t have it, someone will surely let you know.

Now ask yourself this. What happens to your next recommendation when that superintendent retires? The answer most contractors aren’t ready for is this one. It doesn’t get easier. It gets quieter. And trust me, quieter is worse.

The retirement math doesn’t math

By 2031, roughly 41% of the current construction workforce is projected to retire. One in five workers is already over 55. The industry has been treating this as a labor supply problem. And not enough bodies are coming in behind the ones walking out. Workforce development programs, apprenticeship pipelines, AI-assisted onboarding. All of it clearly aimed at the headcount gap.

But who is doing the math on the credibility gap?

Every senior superintendent, every veteran PM, every lead foreman who retires takes at least these three things with them. Their labor hours which we know the industry is counting. Their field judgment, which is what the industry is ignoring. And their organizational authority. Yes THAT. The unspoken ability to validate or kill a technology decision before it ever gets to rollout.

That third one is the one that will cost Digital Solution Managers the most. And almost nobody talks about it.

What’s actually being done about it. Sort of.

To be fair, something is happening. The AI-generated Standard Operating Procedures (SOP) library has become the standard response to the retirement wave. Training modules. Video documentation of standard processes. Even the North America’s Building Trades Unions just partnered with Microsoft to push AI literacy through apprenticeship programs that starts with instructors using AI to build lesson plans faster so they can spend more time actually working with apprentices. Genuine progress, I agree.

But here’s what all of it is producing: documentation. And documentation captures the explicit. The sequence. The procedure. The checkbox. What it almost never captures is the judgment underneath it. Or the organizational weight that comes from 22 years of being right when it mattered.

An AI-generated SOP can tell a new hire what steps to follow. It cannot tell a Digital Solution Manager whether a technology recommendation will survive contact with the field. That requires a different kind of knowledge.

NASA still has the Saturn V blueprints. It doesn’t mean they can build one.

When the Apollo program ended, the engineering team scattered. The blueprints stayed. The knowledge didn’t. What those documents couldn’t carry was the accumulated field intelligence and all the workarounds, the judgment calls, the hard-won understanding of why a certain tolerance mattered more than the specs suggested. It took decades and hundreds of millions of dollars to begin reconstructing what a handful of engineers once carried in their heads.

Some construction firms trying to get ahead, are building their equivalent of the Saturn V blueprint libraries right now and calling it knowledge transfer.

To be fair, the libraries look great. Very organized. Can be useful, and always great on paper.

The closer-to-home version: in the early 2000s, the United States discovered it could no longer manufacture a critical component for nuclear warheads. The engineers who knew how had retired. The documentation existed. But the practical knowledge, I’m talking the feel, the sequence of decisions under real conditions, and the essential judgment of when to deviate was all gone. It cost $69 million and five years to relearn what a few people once knew from experience.

Granted contractors aren’t building warheads. But the same principle holds. When undocumented expertise walks out the door, you cannot just Chat/Google it back. And when the person whose field authority gave your technology recommendations their legitimacy walks out the door, what replaces them is not a training module. It’s a vacuum.

What this costs you specifically

The superintendent who challenged your recommendation wasn’t an obstacle. He was your stress test.

When an experienced field leader pushes back on a technology decision, they’re running a validation process that no vendor demo can easily replicate. They’re asking whether this tool actually fits how work gets done here, on this type of project, with this crew composition, under these conditions. That question is worth more than the RFP response. And the firms that lose their experienced validators whether to retirement, turnover, or simply never having had them in the room, are the contractors that find out the hard way whether their technology decisions were right.

The failure mode isn’t dramatic. The platform doesn’t crash. The rollout doesn’t visibly collapse. What happens is subtler and more expensive. The tool gets deployed. The field works around it because field crews always work around things that don’t fit. It’s in their nature born from their experience as the builders they are. Within sixty days it becomes something people log into because someone is checking whether they logged in. Which is a different thing entirely. And the Digital Solution Manager who recommended it is now defending a decision in a vacuum, without the field authority that might have caught the problem before it became one.

This IS NOT a technology failure. That’s what knowledge loss actually costs.

The uncomfortable truth about what firms are losing

The knowledge that makes or breaks a technology decision in construction is relational, contextual, and stubbornly human. It lives in pattern recognition built over years of specific projects, specific crews, specific failures. It transfers through conversation and observation, not documentation. It compounds slowly and evaporates really fast.

The firms getting ahead of this aren’t just building training libraries. They’re being honest about who their knowledge holders actually are. And not just in the field, but in the organizational decision chain. They’re identifying whose credibility has been quietly validating technology recommendations for years, and they’re having deliberate conversations with those people before those people start thinking about their exit. Not to document what they know. To understand what they see. There’s a difference.

The firms that don’t have that conversation will make the same technology recommendations they’ve always made. They’ll just have fewer people in the room who know why those recommendations are right or wrong. And they won’t know what they lost until they’re standing in a field meeting, their recommendation on the at the ready, with no one left in the room who’s been here long enough to tell them.

A thought I keep coming back to

Every Digital Solution Manager I’ve talked to over the last eighteen months has a version of this story. The veteran who saw through a bad technology decision before it cost the firm real money. The superintendent whose field authority made a rollout work when the conditions weren’t right on paper. The PM who knew which parts of a platform actually mattered in the field and which ones were just demo theater. Every one of them thinks their version is unique. It isn’t. It’s the pattern.

What bothers me is there’s no place in this industry where those stories get traded honestly. And I don’t mean in a vendor webinar, in a conference keynote, or a case study where everything worked out in the end. I mean the boots on the ground ones. The ones where the knowledge almost didn’t make it. The ones where you’re still not sure what it cost.

I think that place should exist. I’m calling it the Builders Trust™ A vision I’m shaping up of a practitioner community built for the exchange that doesn’t happen anywhere else. Not best practices. Not benchmarking. The actual post-mortems. The parking lot conversations. The stuff that never makes it into a presentation. I don’t know yet exactly what it looks like. But I know who belongs in it. If you’re reading this, you probably do too.

I’ll be writing more about this. Stay with me.

BEFORE YOU BUY™ Every week this section does one thing: asks the questions the demo didn’t.

Before You Buy™ isn’t a product review. It’s not a ranking. It’s not affiliated with any vendor. It’s a structured look at what has to be true about your operations first. I mean your crews, your data, your culture, your project conditions etc. Long before a technology purchase has a real chance of delivering what it promised in the conference room. The tool is rarely the problem. The decision behind it almost always is.

Dozuki - The Leading Connected Worker Platform

What it actually does in plain language

Dozuki is a connected worker platform that digitizes institutional knowledge. Standard operating procedures, training content, step-by-step work instructions etc., and makes it accessible to frontline workers on any device, on any shift, in over 100 languages. The core idea is pretty straightforward. Instead of knowledge living in binders, in someone’s head, or in a six-hour orientation that nobody remembers by week two, it lives in a structured digital system that workers can access at the point of need and managers can actually track. This is a tool primarily used in manufacturing by some of the biggest enterprises in the world. I’m talking Coca-Cola, Kubota, General Mills. You get the drift…

The platform has three functional layers that work together. Knowledge capture so subject matter experts record how work actually gets done, and Dozuki’s AI tool that converts those recordings into structured, visual work instructions. Training delivery and role-based learning pathways fill out these workflows that assign the right training to the right person at the right time, with progress tracked and visible to managers. This includes operational feedback workers can use to flag issues, suggest improvements, and contribute to the knowledge base from the manufacturing floor, creating what Dozuki calls a continuous improvement loop.

The results in manufacturing are not modest. Airstream replaced paper-based tribal knowledge with digital standard work and structured onboarding, and new hire turnover dropped from 30% to 5% while the workforce scaled from 500 to 1,200 people. General Mills reduced overall training time by 62% using Dozuki’s structured digital training program built on actual work processes rather than generic theory. These are not pilot results. These are operational outcomes at scale.

In a demo, Dozuki looks like the direct answer to everything this week’s editorial described earlier. A platform built specifically to catch institutional knowledge before it retires, digitize what experienced workers know, and make it accessible to the crew that replaces them. It is worth a serious look. And then it is worth the harder questions.

What has to be true for this to actually work

Dozuki’s results come from manufacturing environments with a specific set of conditions. Before you evaluate whether those results translate to construction, you need to be honest about whether those conditions exist on your projects.

The work has to be repeatable enough to document. Dozuki is designed for standard work. Processes that happen consistently enough that a step-by-step guide is meaningful guidance rather than a rough approximation. Manufacturing lines have this. Construction projects have some of it too for sure. Safety protocols, equipment operation, certain installation sequences but a significant portion of construction work is project contextual, variable, and condition-dependent in ways that resist standardization. The veteran superintendent’s value isn’t that he follows a standard sequence. It’s that he knows when the standard sequence doesn’t apply. Dozuki captures the former. It to my knowledge can’t capture the latter.

Your knowledge holders have to be willing and available to record. Dozuki’s AI-powered CreatorPro tool can convert a recorded video of an expert doing their work into structured documentation. That’s genuinely impressive. What it requires is an experienced worker sitting still long enough to record, in an environment where that’s possible, with enough operational bandwidth to participate. In manufacturing, this is manageable. On an active construction site with a superintendent running three subcontractors and a delivery problem before 8am, the participation assumption needs to be examined honestly before you build a program around it.

Someone has to own the system. User reviews note that Dozuki’s mobile app is underdeveloped and the interface can be clunky, which slows adoption and may require additional training investment beyond the platform itself. More critically, connected worker platforms require an internal owner. Yes someone whose job includes keeping content current, managing version control as procedures change, and ensuring that what’s in the system reflects how work is actually being done today, not how it was being done when the content was first created. In a GC without a dedicated L&D function, that role usually gets assigned to someone who already has a full job. That’s how platforms become expensive archives nobody trusts.

The content has to stay current or it becomes the problem. This is the failure mode that doesn’t get discussed in demos. An outdated standard operating procedure (SOP) in a binder is harmless cause nobody reads it anyway. An outdated SOP in a digital system that workers are directed to trust is actively dangerous. If your firm doesn’t have a defined process for reviewing, updating, and versioning documentation as conditions change, Dozuki will eventually produce the construction technology equivalent of a confident wrong answer.

Where this comes apart on real jobs

The failure mode for Dozuki in a construction context isn’t dramatic. The platform doesn’t crash. The documentation doesn’t obviously fall apart. What happens is quieter and harder to diagnose.

The initial knowledge capture goes well. The experienced superintendent participates in a recording session. The AI generates clean documentation. Everyone is impressed. The platform launches with genuine organizational enthusiasm.

Then the project ends. The superintendent moves to the next job. The conditions on the new project are different enough that the documentation from the last one requires translation, not application. The person who could translate it is now managing a different crew on a different site. The digital guides sit in the system, accurate for a project that no longer exists, and new workers learn from the superintendent on the current project the same way they always did — by watching and asking questions. Within six months the platform is a library of past projects that nobody has time to update and nobody fully trusts.

That’s not Dozuki failing. That’s the conditions for Dozuki in construction being fundamentally different from the conditions that produced those manufacturing results.

The one question worth asking before any demo

Do we currently have a defined owner for the documentation and training content this platform would generate? Is this someone with the authority, the time, and the operational visibility to keep it accurate, current, and trusted as projects change and crews turn over?

If the honest answer is no, the platform will produce impressive initial content and gradually become an archive that nobody uses. The technology works. The organizational discipline required to sustain it is the actual purchase you’re making. Make sure you’re buying both before you sign anything.

Bottom line

Dozuki is a serious platform doing something genuinely useful. The manufacturing results are real and the knowledge capture capability is among the best available. For construction firms with a mature training function, a defined content ownership model, and work scopes that include enough repeatable processes to justify structured documentation including safety programs, equipment operation, prefabrication sequences, commissioning protocols on and on, it deserves serious evaluation.

The decision to buy Dozuki should be preceded by an honest answer to whether your firm’s project structure, crew culture, and internal bandwidth actually support what sustained platform adoption requires. Not whether you’d like them to. Not whether a pilot project with a cooperative superintendent and a light project load suggests they might. The conditions have to match the capability. That’s the only question that actually matters.

Some weeks this means examining the field, and analyzing where tech adoption fractures happen under actual project pressures. Other weeks, it means looking at the back office where cost codes, schedule updates, forecasts, and executive dashboards are reviewed, and therefore what leadership believes is happening on the build.

This week we’re tracing the critical path of bad data. Not the one on your CPM schedule. The unmapped data path. The path where loose daily logs can become distorted forecasts. Where fragmented systems require some human stitching. Where shadow spreadsheets can become the real integration layer. And where AI accelerates whatever operational discipline or lack of it, will persist into the future.

If implementing your tech has not gone smoothly, and or your app integrations are misaligned, AI will eventually expose both.

Let me state bluntly. If your tech stack requires workarounds to function, you don’t have an integration problem. You have an operational problem of wide-eyed clarity.

And if your crews quietly stop using a digital tool they way it was intended the moment the schedule tightens, you don’t have a resistance problem. You have an adoption governance problem.

A 2026 industry survey of roughly 1,800 contractors reported by Trimble ranked technology optimization and integration challenges alongside workforce shortages as top operational concerns. When integration sits next to labor shortage in the same sentence, that’s not a good thing.

This strain would appear to be on the increase. Industry reporting continues to flag fragmented tech stacks, siloed data, and manual reconciliation as productivity drags. We’re buying more tools and stitching them together with human effort.

Now layer in what contractors are saying publicly. In 2025–2026 Reddit threads, the sentiment isn’t anti-tech. It’s pragmatic:

• “It adds steps.”

• “We still end up in Excel.”

• “It’s too much work for the payoff.”

• “Integration problems are workflow problems.”

That last line matters. Because it’s true.

⏱ Field Reality

“Nearly half of professionals say stale or incorrect data from the back office makes it difficult to make real-time decisions on site.”

You’ve seen this all before: Leadership approves three platforms in two years. A kickoff and onboarding happens. A “champion” is named. Training is completed.

Four months later: The schedule compresses. RFI volume spikes. The crew is short.

Now: One system is “official.” Another is used for tracking. Excel becomes the reconciliation layer. A superintendent bypasses the workflow because it’s faster.

Why do we keep separating adoption and integration as if they’re different conversations? Adoption is treated as good or bad behaviour. Integration is treated as plumbing. I don’t believe they’re entirely separate. Integration determines whether adoption survives pressure. Adoption determines whether integration ever becomes real and essential. And now we’re layering AI on top of both. Here’s where this gets sharper. ... But it will accelerate fragmented data. And fragmented data accelerates bad decisions faster and in the long run. And when those decisions are wrong, they land on operations first. Not the vendor. Not the dashboard. You.

Let’s make this specific.

Poor Data Practice #1: Duplicate Entry Under Pressure

A foreman logs production in one platform. Cost codes reconcile two days later in another. The schedule is manually adjusted before the review meeting. AI forecasting pulls from all three. The model says productivity is stable. But the lived reality shows:

• Two short-staffed days.

• Equipment downtime.

• A material delay handled informally.

The AI isn’t broken. The inputs are some form of incomplete, or inaccurate. So the forecast looks stable... until it isn’t.

Poor Data Practice #2: Cleaned Data for Leadership Consumption

Field data is messy. That’s a fact of no blame. To avoid noise in executive dashboards, information inputs are “standardized”, smoothed, or delayed. AI pulls from these sanitized inputs. By the time an issue appears in a dashboard, the correction window has shrunk.

Industry analysis shows that construction reporting remains fragmented across systems, forcing leadership teams to reconcile conflicting views of project health rather than seeing real time jobsite reality. Data-Sleek

Academic case studies affirm that even well-intentioned digital environments still struggle to achieve consistent field-to-executive information flows without governance and structured processes.MDPI

Broader surveys reveal that 65% of firms still haven’t adopted predictive analytics — not because they lack interest, but because data quality and integration simply aren’t there yet.Roofing Contractor

And nearly half of practitioners admit that stale or incorrect data hampers real-time decisions on the jobsite. QuickBase

This shows up in submittals that age, RFI tracking, labor productivity changes, and equipment utilization. Acceleration of inputs without discipline doesn’t create clarity. It creates faster distortion.

Poor Data Practice #3: No Data in the Moment That Matters

A superintendent bypasses the workflow during a crunch. No entry is made explaining why. Weeks later leadership asks “Why did productivity dip in Week 14?” There is no trail. So narrative replaces data. Narrative becomes assumption. Assumption shapes the next investment decision. Sometimes that investment is another tool. That’s not a tech failure. That’s a governance gap.

Industry reporting heading into 2026 emphasizes interoperability and predictive analytics as competitive necessities. But here’s the tension not enough are clear enough on:

📉 DATA READINESS GAP

“65% of construction leaders haven’t adopted AI or predictive analytics for project planning or decision-making largely due to integration and data readiness challenges.” — 2025 Industry Survey

AI does not create operational maturity. It will expose it. If your stack requires manual stitching. If adoption collapses under pressure. If shadow systems are the real control center well then AI doesn’t fix that either. It scales it. Faster dashboards. Faster projections. Faster confidence. Confidence built on inconsistent inputs is not visibility. It’s risk with better graphics. And that risk hits operations first. Before it reaches the boardroom.

If you’re in operations, you already feel this tension. You’ve sat in reviews where the numbers looked clean but the job didn’t. You’ve sensed the gap between dashboards and dirt. That gap is not cultural resistance. It’s production logic.

If a superintendent is measured on schedule and budget, and the platform slows him down by a minute per task during peak pressure, what exactly do we expect him to do? Protect the data model? Or protect the pour?

Unless tech governance can explicitly define what work is eliminated, what friction may be caused, what human behaviours have to be enforced, and how integration gaps are being handled, of course adoption will fade, and integrations will not go smoothly.

If you want adoption and integration to survive month six, the reset isn’t technical. It’s structural.

Before your next renewal and before your next AI pilot be sure you can ask and answer (at least) these questions:

✅ What work does this technology eliminate specifically?

✅ What friction will appear between systems if implemented?

✅ Who owns that friction when data inputs are inconsistent?

✅ Who enforces behavior changes to better align technology — and how?

If you cannot answer these questions during your pilots and implementation, the tool won’t survive the first six months. And this isn’t necessarily a failure on the part of the software. It is a gap in governance.

This is the layer I work in. Decision environments. Operational clarification. Validated alignment between people behavior, systems, and data.

Technology doesn’t fix fragmented execution. Great technology should expose it. And exposure without governance is just upping your risks all the faster.

In this week’s editorial, we talked about fragmented data, quiet erosion, and what happens when adoption and integration fade under the pressures of the project. Here's your opportunity to go deeper:

On March 12th at 11am EST, I’m hosting a live session

Together with Tervene , we’ll examine:

⏳ The 72-hour window where fixable becomes costly

🎈 Why small issues compound before leadership can act

🚨 Where critical information dies between job site and management

📆 Why “on schedule” can quietly become fiction

We’ll use a real daily management system that includes Gemba, and Leader Standard Work to show exactly how information is captured, routed, escalated, and where it stalls.

This is not a demo. This is not a feature walkthrough. This is about governance

If you’re responsible for multi-site execution, operational excellence, or continuous improvement, this will feel familiar. If your escalation pathways are already tight and issues surface instantly across projects, this session may not be for you.

But if you’ve ever learned about a problem when it was already too expensive this livestream should make it into your calendar.

Register Here

Some weeks that means stepping into the reality of a specific role and examining where adoption breaks. Other weeks, it means examining integration like this it’s what “connected” really means when multiple teams, platforms, and priorities collide.

This week’s issue looks at integration through a PM’s lens.

When someone tells me their document control or submittal platform “integrates,” I don’t start by asking about APIs. I ask something a tad more uncomfortable.

Does the work actually flow through the tool when the project gets messy?

Because in commercial construction, the problem isn’t that teams don’t have the right systems. The problem is that when things get urgent, people revert to the fastest path to resolution. And that path often has nothing to do with the software platform leadership thinks is running the job. This is where the untracked feedback loop shows up. And it’s one of the most common integration failures I see over and over on live projects. And this is not because the technology is weak, but because the workflow reality is stronger.

What a technical integration actually is (in construction terms)

A technical integration is simple: It’s when one system pushes or pulls information from one system into another without someone retyping the same information.

This might mean an RFI created in one platform appears automatically in another. It might mean submittal status syncs across relevant parts of the software stack. It might mean comments, attachments, and revision histories stay connected without manual copy and paste. That’s the technical definition anyway.

But on a job site, technical integration only matters if one thing is true: The record reflects what people actually did.

If the tool can technically connect to everything but the team is solving real problems outside the system, then the integration is mostly decorative. And PMs know exactly what that looks like.

Here’s the untracked feedback loop (the real scenario)

And how it usually plays out: A submittal comes in. It gets routed. It gets reviewed. It’s marked up. Someone flags a critical issue. A revision is needed. And instead of the feedback being logged cleanly through the official workflow, the real conversation happens in a faster channel. Sound familiar?

• ✅ a PDF markup sent over email

• ✅ a screenshot in a text thread

• ✅ a Teams message with “use this one”

• ✅ a phone call with “don’t worry, we already handled it”

• ✅ a foreman walks in the trailer with a printed sheet saying, “this is what we’re doing”

The project keeps moving. The issue gets resolved. People feel productive as they need to. But the platform, the system that leadership agreed would be the record of truth shows inconsistencies, delays, or data that just doesn’t add up. And that’s the point where “integration” becomes a version of fantasy. And not because the tool and what it is meant to do has technically failed. Because the workflow bypassed the tool completely.

Why PMs get trapped in this situation

This is where I come in to start pressure-testing the decision boundary. Dig out the reality. Because most PMs aren’t trying to avoid the system. They’re trying to keep the job from stalling. If the tool requires five steps to log a response, tag the correct drawing, attach the right markup, assign the right reviewer, and close the loop and the field is waiting around then the PM will do what PMs are paid to do: They will keep the project moving.

And that usually means the answer gets communicated in whatever channel is fastest. This is NOT laziness. This is production pressure. But once the project begins resolving issues outside the platform, the platform becomes a lagging mirror instead of an operational tool.

The real integration question: does it preserve the chain of accountability?

This is where most “document control” tools become deceptively hard to integrate. Because the technical integration isn’t the hard part. The hard part is that these tools are expected to do something very specific: preserve accountability across multiple parties who do not share incentives. We’re talking GC, subs, consultants, architects, engineers, owners. Different organizations. Different urgency. Different risk tolerance. Different definitions of “done.” So when a decision gets made through a side channel, the question becomes:

• ✅ Who approved it?

• ✅ Which revision was used?

• ✅ Was the change captured?

• ✅ Was it distributed?

• ✅ Who saw it?

• ✅ Who is now exposed?

And if the tool can’t hold that chain of command cleanly then it can’t absorb the speed of live project communications that then naturally lead the PM to end up doing what they always end up doing: They become the human integration layer.

The hidden failure mode: “We fixed it” is not the same as “It helped the job run better”.

A superintendent might say, “We handled it.” A foreman might say, “We already fixed it.” A consultant might say, “That’s what we meant anyway.”

But PMs know the real issue isn’t whether the problem got solved. The issue is whether the decision is traceable. Because on the next job, or the next phase, or the next turnover milestone, the same question will come back: Why was it built this way? What is the value of this data? If the record doesn’t reflect the reality of how the decision happened, then the project is carrying invisible risk. Again, not because the team made the wrong call. Because the project doesn’t show how the right call was made.

Where integration actually breaks: sources of truth collide

When I test systems like these, I don’t ask whether they store documents. Everyone stores documents. I ask where they compete with existing sources of truth. Because every project already has a document control ecosystem, even if nobody admits it, or even knows how to apply the data in it:

• ✅ email threads

• ✅ shared drives

• ✅ personal desktops

• ✅ printed sets in trucks

• ✅ Bluebeam markups

• ✅ text message screenshots

• ✅ meeting minutes nobody reads

• ✅ Procore folders nobody trusts

• ✅ SharePoint libraries nobody can find anything in

So when someone rolls out a submittal or RFI tool and says, “This is the source of truth now,” what they’re really saying is: Everyone has to stop using their own system that they “trust”. Unless that tool is designed and ready for the real site pressures, it will potentially miss its opportunity to do the job it was developed for. Not in a dramatic way. Through bypass.

This is why document control is harder to integrate than people think

Document control tools are often treated like administrative technology. They’re not. They sit in a high-stakes layer of the job where the smallest mismatch can create the biggest consequences:

• ✅ procurement orders the wrong revision

• ✅ the field installs from outdated details

• ✅ submittals get approved but not distributed

• ✅ closeout becomes an argument instead of a handoff

• ✅ disputes become about “who knew what, when”

So when I hear “it integrates,” I put it through my system to test what that actually means. Because if integration depends on perfect behavior, perfect tagging, perfect metadata, and perfect discipline, it won’t survive a real project. Construction we all know is not a clean environment.

What PMs actually want in that moment

This is the decision boundary that matters most. When a PM is under pressure, they don’t want a tool that makes them slower. They want a tool that can do three things:

1. Capture the decision trail automatically Not just the final file, but who said what, when, and why.

2. Reduce duplicate work If I have to log the same response twice in two different systems, the system is not integrated—it’s bureaucratic.

3. Make the latest truth unmissable Not “available,” not “stored,” not “uploaded.” Unmissable.

If the tool can’t do those three things under pressure, then the PM will do what they always do: solve the problem first and document it later. And that’s how the job gets “handled”.

The engagement failure signals that leadership misses

• “Just call me, it’s faster.”

• “I’ll send you the markup.”

• “Don’t worry about the tool, we already handled it.”

• “I’ll upload it later.”

These comments are the moments the platform becomes optional. And once the platform becomes optional, integration rarely matters anymore. Because the job is no longer being run through the system. It’s being run around it.

The takeaway I care about

Document control tools don’t fail because they can’t store documents. They fail because they can’t keep up with how construction actually resolves problems. And that’s why integration isn’t just technical. It’s operational. It’s political. It’s behavioral. It’s a workflow agreement between people who don’t report to each other. If the tool can’t survive the moments when urgency hits, it doesn’t matter how clean the integration looks on “paper”.

Why I pressure-test integration this way

This is the kind of test I run in my working sessions. Not to critique tools. Not to “catch” teams doing it wrong. And not to pretend the solution has perfect compliance. I do this to surface where a tool’s integration claims collide with real project behaviour before the project absorbs the cost. Because once side-channel decisions become the norm, the record stops being trustworthy. And when the record stops being trustworthy, closeout, claims, and turnover stop being managed, what’s the point of the tech. That’s not a data problem. That’s a decision problem.

Some weeks that means examining system connections and data flow. Other weeks it means stepping into the reality of a specific role and asking where adoption fails.

This week’s piece looks at the superintendent, and what happens when the technology questions the authority on a live job.

When the Tech Says “Go” and the Site Says “Nope”

When I test specific construction technologies and the decisions they’re meant to support from a superintendent’s point of view, I often start with something familiar. No dramatics. Rather the ordinary. For instance when a clash gets flagged.

On paper, the model is right. Two systems occupy the same space. The issue gets logged. The workflow does exactly what it was designed to do.

But on site, the superintendent already knows the sequencing. They know which trade installs first, what tolerances are available, and why the conflict won’t exist by the time that area is built. In other words, they know it’s a condition and not a problem.

The tension doesn’t come from the clash being visible. It comes from what happens next.

Site reality vs. system reality

This is usually the first fracture point.

The technology is doing what it’s meant to do: it surfaces a condition that deserves attention. The problem is that the system itself hasn’t necessarily been designed to know when that condition matters or who should or gets to override it. I’ve tested this pattern on a few digital tools and workflows.

In this case, the model flags a clash that’s technically correct but operationally irrelevant because of it doesn’t know the realities of the trade sequencing. The schedule shows an area as ready, but inspections aren’t signed off and the trade ahead of hasn’t actually turned the space over yet.

Another scenario to consider is materials. The status reads as “delivered,” but what has arrived is actually damaged, or incomplete, or staged wrong, or tied to the wrong revision. Progress advances automatically because time or quantities suggest work should be done even though the superintendent hasn’t weighed in on the effects of these disruptions.

None of this means the technology is wrong. It means the system is operating without full context, and the superintendent is forced into the role of translator to reconcile reality after the record has already moved on. That’s where trust begins to erode from application to application.

Decision ownership boundaries

The next thing I look for is where authority quietly shifts. There are decisions that must always remain with the superintendent. And not because technology can’t improve, but because these decisions sit at the intersection of timing, safety, flow, and accountability. The human experience.

Like re-sequencing work due to weather, access, or crew availability. Choosing to accept a minor deviation to protect downstream work. Holding a trade back even when the schedule says “go.” Overriding data because lived judgment is more current than what the system can see. These aren’t anti-technology decisions. They are site leadership decisions.

When a system escalates an issue whether it’s a clash, a readiness flag, or a risk alert before the superintendent has had a chance to apply judgment, authority gets displaced. Not overtly. But it hangs in the air. And once that happens, tech adoption becomes fragile.

Accountability direction

Then I ask this next simple question: When the system contradicts reality today, who actually absorbs the consequences? Certainly not the technology. The superintendent carries the operational impact. The project manager carries the explanation. And leadership still looks at the dashboard. The system remains technically correct, while people manage the fallout.

This is where adoption problems are often misdiagnosed. It’s not that teams “resist” the tool. It’s that accountability is flowing in one direction while authority is flowing in another. This mismatch doesn’t announce itself. It just accumulates over time.

Visibility vs. control

Visibility and especially control are the adoption lines that matter more than features, training, or even rollout plans. The tech has to support the superintendent by making reality visible and not override these human decisions by deciding what’s true without them. Visibility builds trust. Control can erode it.

Good technology can surface clashes, risks, and inconsistencies. Many systems do this well. But when visibility turns into unilateral escalation when a condition becomes a blocker before human judgment is applied the system stops supporting the work and starts competing with it. That’s not a software limitation. That’s a design decision.

How disengagement actually shows up

When trust breaks, superintendents almost never say it directly. They just stop updating in real time and backfill later. They rely more other side channels like texts, whiteboards, verbal agreements that for them communicate what’s actually happening just as well. They become selective about what goes into the system. Sarcasm creeps into conversations about “what the tech says.” This isn’t resistance. It’s self-preservation. The work still gets done. It’s just no longer through the tool.

What convinces a superintendent the technology respects them

In environments where adoption holds, it’s not because the technology is less capable. It’s because authority boundaries are explicit. Progress doesn’t advance without superintendent confirmation. Context travels upstream and not just status, but why something isn’t ready. And just as importantly, the system knows when not to escalate. Not every clash needs to become an issue. Not every condition needs to become a problem.

The strongest setups I see aren’t anti-technology. They’re deliberate about where human judgment outranks automation and where the system’s job is to amplify that judgment, not replace it.

Why I walk you through situations like this

This is the kind of pressure testing I run in my working sessions.

Not to criticize tools. Not to romanticize the field. And not to pretend technology can’t adapt. I do it to surface where authority, accountability, and system behavior intersect before technology is selected, replaced or compared. So when the outcomes and data that X technology outputs from the inputs provided by the supervisor in this case, other consequences don’t also pile up.

When the boundaries between human user and the automations they’re supposed to apply are designed intentionally, technology does what it’s actually good at: supporting the work instead of competing with it. And that’s when adoption stops being fragile and not because the tech got smarter, but because the organization did.

A note for superintendents, PMs, and operations leaders

If you’ve ever felt caught between what the tech shows and what the site knows, you’re not imagining it. That tension isn’t personal. It’s architectural.

And I think it’s worth testing while there’s still time to get all this complexity “right”.

Most construction technology doesn’t fail during rollout. It fails later on, quietly and once the job speeds up. And not because the software doesn’t work. And not because the field “resisted change.” But because responsibility was never operationally redefined once the work got real.

This is not just my observation and experience talking. It’s supported by industry data.

According to the State of Digital Adoption in the Construction Industry, the average construction business has adopted about 6 technology categories which is up 20% year-over-year and yet this increase does not necessarily translate into adoption effectiveness on live projects. Deloitte

Another survey from the Royal Institution of Chartered Surveyors found that 45% of construction firms currently have no adoption of AI at all, and fewer than 1% have AI embedded across multiple processes. Construction Dive+1

Okay now it’s getting real. This points to a deeper mismatch between technology presence and technology use under pressure.

A scenario dear reader you’re already familiar with

Picture a mid-project commercial build. Any type. You name it.

The new technology has been purchased. Training has happened. And yep just like that the new system technically works. Early on, usage looks promising. And yes that project manager has more details to manage, but they’ll just have to deal.

And then the schedule compresses. And suddenly coordination meetings start getting shorter. End of day reporting gets rushed or pushed altogether. Manual work necessarily fills these gaps. “We’ll clean this up later” becomes the normal echo on the field. Nothing too dramatic happens. No one formally opts out. The tool just simply begins to fade. And no one can quite explain when or why, if it’s even noticed.

Where adoption actually breaks

So here’s the uncomfortable truth: Adoption rarely fails because people won’t use the tool. It fails because no one clearly owns what happens when it’s partially used. At the start of most on-boardings, ownership feels obvious. A “champion” is put into place to initiate set up. Someone is designated to “train” the “team”. On paper someone is “responsible”.

But once the realities of the job set in, pressure to neatly comply to the workflows of the technology are no longer anyone’s priority.

• handoffs blur such as the field logs an issue assuming the PM will review it later and yet the PM assumes it’s already been vetted

• edge cases multiply like when situations where “the tool can handle it” but only once “someone” approves some details first

• assumptions go unchallenged because everyone assumes those small inconsistencies won’t matter later to anyone

• data gets entered inconsistently as one foreman uploads photos daily, and another uploads weekly in batches

And then the most dangerous moment arrives. Everyone believes someone else is watching it. That’s when adoption stops being a decision that gradually slides into a liability. ROI? What ROI?

The misconception that keeps repeating

When adoption stalls, the default explanation is explained aways as behavioural:

“The field didn’t buy in.” “People went back to spreadsheets.” “Change is hard.”

These explanations are both convenient and wrong. What’s actually happening is failed operational responsibility.

• who notices when usage slips

• who absorbs the cleanup work

• who reconciles conflicting data

• who has authority to intervene mid-project

Without this kind of discipline, the tool isn’t necessarily rejected. It’s quietly bypassed to get to the work that everyone’s obviously measured on.

This matches industry evidence showing a persistent gap between aspiration and execution. For example, even when leaders see the value of AI or predictive analytics, a large majority don’t yet adopt them in planning or execution workflows. Roofing Contractor

Why this matters more than the tool itself

At this point, teams often focus on the wrong fix. They think, okay, let’s call the vendor and get more training. Or we’ll just be “stricter” enforcing the technology. Or maybe we need more technology to make this technology better. You know more dashboards, more features. On and on. But none of those address the real problem. If responsibility collapses under pressure, the technology is already irrelevant. Sorry to say no matter how good it is. This is why so many tools look successful in pilots and underperform in live jobs. The pilot never tested what happens when time, attention, and accountability all get strained.

🧱 Stack reality check

You don’t need me to tell you that these systems exist. You need data that shows they’re not functionally bridging work and decision making. In many firms, tech stacks spread across 6 plus categories is routine. But unfortunately the downstream use under pressure remains uneven and inconsistent. This is the real stack problem: solutions exist but coherence not so much.

The question most teams never ask

Before investing in your next tool, try asking this first: When this new tool doesn’t get adopted and this new process breaks (and it will) who realizes it first? And whose job is it to fix it? If the answers to these questions aren’t operationally crystal clear, you don’t have an adoption problem yet. You have an adoption blind spot. And this is where your tech ROI is determined one way or the other.

This is the type of adoption breakdown Intelligent Construction Opportunities examines before tools hit live projects not just by evaluating software, but by pressure-testing how real work actually gets done.

When teams run into adoption breakdowns like this, the problem isn’t usually the software. It’s that no one stopped to pressure-test how responsibility, handoffs, and edge cases would play out once the job and tech together get real.

This is where my work comes in.

I help teams slow these decisions down before rollout by mapping where tools intersect with real workflows, who actually owns what under pressure, and where adoption is most likely to decay. Not to just recommend software, but to make sure technology decisions survive live projects.

That’s the role Building Briefs™ play. Our custom frameworks surface tech adoption and integration risks early, while teams up and down the value chain still have room to understand, and have their say in how to apply them.

And I think that gap, between what people believe AI will do, and what it’s actually doing on job sites is exactly where lean thinking lives. Because if nearly everyone agrees that AI is coming for construction, the question isn’t if we’ll use it. It’s how we’ll keep it from eroding the discipline that lean well, leans on.

Lean. Always been a great idea, but sometimes a tough sell.

If you’ve ever tried to keep lean alive on a job site, you already know the drill: big kickoff, new boards, everyone’s fired up… and six months later the “lean system” is buried under binders. Not because people don’t care, but because construction eats systems for breakfast. Paper gets lost, checks get skipped, huddles turn into rushed stand-ups where half the problems never even get surfaced.

That’s why this question keeps popping up: “How do you use AI in lean construction thinking?” And no, not the kind of answer you’ll find in a glossy presentation. I mean the muddy-boots kind, radios-crackling, crane-on-standby, WTF version.

Here’s a quick refresher on what lean is supposed to be. Leader Standard Work or LSW is the daily routine and checklist that keeps supervisors honest. Daily Management Systems DMS are the boards and huddles meant to catch problems early and keep projects flowing. On paper? Perfecto. On site? Kinda fragile. Lean falls apart the minute no one’s holding the reins.

Here’s the thing: AI isn’t here to replace lean. It’s here to support lean. AI’s fundamental sweet spot is identifying patterns. Like rigging checks that might have been missed three days in a row. It can predict trouble before it throws next week’s pour off schedule. It can guide action by surfacing “check this first” on tomorrow’s supervisor agenda instead of relying on memory. Generative AI, the ChatGPT kind, might even draft your huddle notes or fill out inspection logs. But the real win is that AI puts lean discipline back in front of your crews, every single day.

Imagine this from a Continuous Improvement Leader’s perspective. Yesterday, three crane checks were missed. Today, your agenda opens with “Rigging - TOP Priority 1.” Waterproofing Non-Conformance Reports being flagged? AI tells you before the work slips. Your huddle board isn’t guesswork anymore. Nope, it’s real data. That’s Lean and AI working in tandem.

Fast-forward to 2028, and you’re seeing a job posting that reads: Continuous Improvement Architect. This person reads an AI dashboard every morning, decides where the Gemba walk actually goes, and escalates risks before they become rework. Same Lean values. Just different tools.

Here’s the blunt truth: Lean and AI are already here! Whether your crews are ready or not. The real question isn’t if, it’s who sets the terms. Will your teams know how to use it to make daily work easier, and who is going to help you write THAT playbook?

That’s the gap Intelligent Construction Opportunities closes and the one we’re here to fix. We help builders see how tech actually fits into their day-to-day jobs. And we help vendors show their tools in a way construction professionals can get behind.

The truth is AI and automation isn’t the future anymore. The next questions are how do you decide what shapes how AI works for YOU. Will it be your version, or someone else’s?

🧱 Partner Spotlight

PypeServer 🤝 DILFO Mechanical

The ROI of Data Integrity

If you’ve ever spent time trying to reconcile spool lists between Revit, Excel, and the fab floor, you already know what “data integrity” really costs.

That’s the challenge DILFO Mechanical faced before shifting to a connected workflow powered by PypeServer. By cutting pipe scrap by 10% and saving their VDC team 10 hours a week, DILFO proved that automation doesn’t have to replace your people — it just lets them do their best work faster.

Their results weren’t magic; they were the outcome of making one crucial decision: move from disconnected spreadsheets to a single, continuous data workflow. If your fabrication shop or coordination team are still stuck in spreadsheet purgatory, this fix is worth your look.

📄 See the results: Download “The ROI of Data Integrity”

Inside, you’ll see how DILFO cut waste, synced fabrication with VDC, and finally put their data to work for them.

Future Crew

🧱 Continuous Improvement Architect

Role Overview

The Continuous Improvement Architect bridges traditional lean construction practices with next-generation AI systems. This role ensures that process improvements don’t fade once the meeting ends — they’re embedded into the digital workflows, dashboards, and decision models that crews rely on every day.

Responsibilities

• Design and maintain digital lean systems that surface real-time process gaps.

• Collaborate with field leaders, data analysts, and AI tools to identify recurring issues and propose sustainable fixes.

• Translate field learnings into structured templates, dashboards, and visual standards used across projects.

• Train teams on continuous improvement methods enhanced by automation.

Skills & Background

• Lean Construction or Six Sigma credentials (LCI, LSSGB, or equivalent).

• Experience in construction operations, quality control, or VDC coordination.

• Strong understanding of data-driven tools (BI dashboards, process mapping software, workflow automation).

• Capable of bridging human communication and digital transformation.

Pivot Pathway

Ideal candidates come from roles such as CI Manager, Superintendent, or VDC Lead. Professionals who already drive process reliability and can extend those instincts into the AI.

Why This Role Matters

As construction becomes increasingly data-informed, improvement can’t just live on whiteboards. The Continuous Improvement Architect ensures every lesson learned is captured, codified, and applied so yesterday’s data inputs are turned into tomorrow’s structured workflows.

When Cynicism Costs More Than Weekends

Observe a job site late on a Friday afternoon and you’ll see it. Crews scrambling to fix the rework no one budgeted for. Superintendents burning phone minutes trying to each the back office who’ve already logged off. And trades pulling weekend overtime just to make sure Monday doesn’t start in chaos.

It’s easy for the field to get cynical. Memes online mocking the “disconnect” between the office and job sites circulate faster than RFI responses, racking up mob likes endlessly. They get likes, they get laugh emojis, but they also reinforce a kind of resignation. As if chaos is baked into the system, and the only thing to do is shrug, and continue pointing fingers.

That cynicism is a tax. It blinds us to the real opportunities which are some of the legit fixes already sitting in front of us. And we wonder why trust is gone, why margins collapse, and why younger talent doesn’t want to stick around in an industry that treats dysfunction like an inside joke.

The Constructive Rant

When Cynicism Costs More Than Weekends

Observe a job site late on a Friday afternoon and you’ll see it. Crews scrambling to fix the rework no one budgeted for. Superintendents burning phone minutes trying to reach the back office who’ve already logged off. And trades pulling weekend overtime just to make sure Monday doesn’t start in chaos.

It’s easy for the field to get cynical. Memes online mocking the “disconnect” between the office and job sites circulate faster than RFI responses, racking up mob likes endlessly. They get likes, they get laugh emojis, but they also reinforce a kind of resignation. As if chaos is baked into the system, and the only thing to do is shrug, and continue pointing fingers.

That cynicism is a tax. It blinds us to the real opportunities which are some of the legit fixes already sitting in front of us. And we wonder why trust is gone, why margins collapse, and why younger talent doesn’t want to stick around in an industry that treats dysfunction like an inside joke.

Opportunities Missed, Opportunities Waiting

At Cameo Kitchens & Custom Cabinetry , Vito Luca and his team aren’t just building cabinetry, they’re orchestrating a kind of spatial intelligence. Complex layouts, custom millwork, clever storage solutions. Sleek and on design point. All seamlessly integrated to serve the modern client’s vision. That kind of craftsmanship requires constant verification, not callbacks.

Here’s where apps like Pixly line up naturally:

• Kitchen & bath builders can tag installs and document progress without endless photo threads.

• Renovators can hand off clean visual proof to clients or inspectors.

• Small contractors can share progress shots with out-of-town owners without ten site visits.

Just as a laser level replaced the string line, Pixly replaces the shoebox of unlabeled photos with proof tied to context. It doesn’t turn Cameo’s crew into superheroes, nope. But it simply clears the noise so their work shows through, and their reputations increase.

At Mynott Construction, Michael Mynott wears the hats of General Contractor, Construction Manager, and Project Manager depending on the day. His team balances execution with early-stage advising. You know, weighing budgets, constructibility, and stakeholder coordination before the first shovel hits the ground. That’s exactly where solutions like Ressio Software prove their value:

• Centralized schedules keep GCs, subs, and designers aligned without fifteen different versions floating around.

• Real-time accountability reduces the classic “who dropped the ball” blame game.

• Coordinated workflows prevent the layering of complexity onto already stretched project teams.

The real opportunity for contractors like Mynott, isn’t to put more weight on their technology stacks. It’s to overcome increased project complexity with solutions built for modern coordination. Software solutions like Ressio translate contractor advisory roles into action without drowning in disconnected spreadsheets.

Let's look at Plan Group, where George Toth plays a role in delivering the electrical and mechanical backbone for hospitals, airports, and mission-critical facilities, the margin for error is razor thin. When your projects power smart hospitals or safeguard financial trading floors, even a single miscut pipe spool can mean lost weekends, ballooning costs, and repetitional risk that no contractor can afford.

George’s work represents the frontline of precision in complex builds where this work demands tools that are designed to keep pace with detailed mechanical pipe configurations. Digital connectors like PypeServer let you cut parts directly from your BIM or CAD models. Rather than relying on manual checks and overnight rework, PypeServer connects design models directly to fabrication shop floor machines, producing cut-to-label parts that carry QR codes into the field.

• Spools flow from Revit to Cloud+ to fab shop without losing fidelity.

• QR-coded labels keep the field and shop synced in real time.

• Crews reclaim weekends because errors and rework are reduced before they happen.

The Constructive Closer

Digital tools aren’t magic wands. They don't swoop in to erase bad design or poor planning. These tools have their place no different than a crane, skid steer, or your favourite cordless hammer drill. Each one is the right tool for the right situation solving the disconnects that cynicism loves to exaggerate.

The real choice isn’t between laughing at the problem or pretending it doesn’t exist. It’s between staying stuck in a loop or otherwise reaching for the tools that help any construction pro who wants to see the "big picture" clearly, coordinate accordingly, and reclaim their weekends. I don't happen to believe this is naive optimism.

If you work in quality control, project management, commissioning, or carry the weight of the final project delivery, don’t miss the replay of Intelligent Construction Opportunities session with Quality Control University’s Greg & Renee Glendenning.

The real stars here are the tools that keep projects on track: the Responsibility Matrix, Submittal Log, and Cx Flow Chart. The replay shows how each one protects time, trust, and reputation.

🎥 Watch the replay first — then check out the tools for yourself: https://qcuniversity.net/shop/

• QC Managers: Stop being the scapegoat. The Responsibility Matrix puts accountability in black and white.

• Project Managers: Don’t get stuck firefighting. The Submittal Log keeps approvals visible and on schedule.

• Owners & Executives: Protect trust and margin. The Cx Flow Chart prevents the final 10% from turning into chaos.

• Superintendents: Sequence trades with confidence. The Cx Flow Chart saves days instead of losing them.

• Craftspeople & Subs: Protect your reputation. The Submittal Log ensures your work isn’t questioned at turnover.

If you work in quality control, project management, commissioning, or carry the weight of the final project delivery, don’t miss the replay of Intelligent Construction Opportunities session with Quality Control University’s Greg & Renee Glendenning.

The real stars here are the tools that keep projects on track: the Responsibility Matrix, Submittal Log, and Cx Flow Chart. The replay shows how each one protects time, trust, and reputation.

🎥 Watch the replay first — then check out the tools for yourself: https://qcuniversity.net/shop/

• QC Managers: Stop being the scapegoat. The Responsibility Matrix puts accountability in black and white.

• Project Managers: Don’t get stuck firefighting. The Submittal Log keeps approvals visible and on schedule.

• Owners & Executives: Protect trust and margin. The Cx Flow Chart prevents the final 10% from turning into chaos.

• Superintendents: Sequence trades with confidence. The Cx Flow Chart saves days instead of losing them.

• Craftspeople & Subs: Protect your reputation. The Submittal Log ensures your work isn’t questioned at turnover.

Future Crew

Role Overview The Construction Data Analyst translates jobsite chaos into actionable insights. They review raw logs, costs, schedules, safety reports, and submittals, turning noise into constructive action for PMs, supers, and executives.

Core Responsibilities

• Aggregate data from field tools, scheduling apps, and financial systems.

• Build dashboards and visualizations that highlight risks, trends, or bottlenecks.

• Communicate findings in plain language for leadership and project teams.

Essential Training / Experience

• Strong background in data visualization (Power BI, Tableau).

• Familiarity with BIM models and construction workflows.

• Ability to bridge technical data with practical project realities.

Some Technologies Already Emerging

• Kroo → workforce and safety insights.

• Procore Analytics → integrated dashboards tied to project data.

• Power BI / Tableau → flexible analytics across multiple platforms.

Role Pivot (Where Talent Might Come From)

• Current Roles Likely to Pivot: Project Engineers, BIM Coordinators, Estimators, or Field Engineers who already work closely with digital tools and reporting.

• Transferable Skills: Strong Excel and scheduling experience, comfort with cloud-based platforms (Procore, Autodesk), and field/office communication skills.

• Education / Training Recommendations: Short-term data analytics certifications, applied courses in construction technology management, or specialized bootcamps in visualization tools (Power BI, Tableau).

Why It Matters As projects generate more data than teams can absorb, this role becomes more and more critical. This role ensures Owners, Owner Reps, GCs, and Subs alike can avoid costly blind spots, strengthen decision-making, and anticipate problems before they escalate.

Everyone wants a smooth turnover. Owners especially. For them, controlling quality isn’t some abstract concept. It’s about protecting their investment, minimizing their risks long after the turnover. They want assurances those warranties are enforceable.

here's the usual scenario...

The project is moving fast to call it a wrap, submittals fly, and the design team is supposed to turnaround approvals in the next two weeks. Instead, reviews drag on for another month. Nobody's tracking these details. PM shrugs, “I think we’re fine,” because the log isn’t visible. Craftspeople and subs show up ready to install, only to find their materials aren’t approved. Workers sit around waiting, crews waste hours, and the schedule loses more time.

From the owner’s seat, all they see are missed deadlines and more drawing revisals and RFIs. They don’t know the delay started upstream with late submittal reviews. They lose trust, they lose leverage, and suddenly what should have been a smooth turnover becomes a fight about change orders.

What's the cost of sidelining QC?: it isn’t just about the paperwork. It’s missed leverage, wasted labor, and reputations throughout the people value chain that are on the line.

Everyone on a job site nods when the word “quality” comes up. But when the pressure hits the fan, controlling quality is the first thing to get sidelined. And when that happens, every role feels it!

What controlling quality really means to who:

Owners - Trust on the Line

Controlling quality means protecting investments and enforcing warranties. When submittals drag, crews sit idle. Owners see missed deadlines and lose trust. QC isn’t overhead. It’s leverage against future reputations and bank accounts.

Project Executives - Margin Bleed

Controlling quality means keeping margins safe. Without defined accountability, rework eats profits. A 12% projected margin slips to 9% and no one can trace where it leaked. Not to blame but to course correct.

Project Managers - Reactive to Proactive

Controlling quality means seeing bottlenecks early. If you can’t answer whether submittals are behind, you’re already in reactive mode. One missed log can turn into weeks of wasted labor. Again not playing the blame game.

Superintendents - Days Won, Not Lost

Controlling quality means sequencing trades in the final 10%. If those fire alarm tests haven't been scheduled and verified, when the entire site work has to stop, this day alone wrecks the whole week.

QC Managers - From Sideline to Essential

Controlling quality means meaningful inspections, documentation systems, and compliance co-operation. Sure, sure. But sometimes instead misused for errands, the QC gets the blame, (yes the blame), when quality issues inevitably have slipped, and go unchecked. If you don’t empower your QC at the early stages of submittals, and the RFI process, how can you expect to control quality?

Craftspeople & Subs - Reputation, Reputation, Reputation

Controlling quality means defending good work. Without each stage of the build having the documentation they're entitled to, a drywall installer’s finished wall gets questioned at turnover. QC tools protect both the good, and inferior work along with the skilled professional’s reputation.

The KICKER - It’s about pragmatic tools used consistently: a Responsibility Matrix, a Submittal Log, and a Closeout Flow Chart.

PIXLY

📸 Snap the proof 🏷️ Tag the trade, location, or submittal and 📑 Share a brief report

Controlling quality means knowing who’s responsible, what’s approved, and how the sequence flows. That’s exactly what Renee & Greg Glendenning of Quality Control University unpacked in our recent livestream. If you work in quality control, project management, commissioning, or in some way own the final delivery of your construction projects Check out our recording!

Investors don’t care about your pitch if your pipeline looks hollow. Pitch decks with slides about “potential” don’t cut it anymore. I guarantee they'll be tossed aside faster than a cold demo.

Welcome back to another edition of The Constructive Rant!

An angel investor turned VC recently wrote:

“Raising funding is harder than any point before. It’s too easy to build an MVP now, I won’t even look at a pitch deck that doesn’t include some traction or product out in the world… Don’t tell us, show us.”

If you’re building software for GC’s, PM’s, VDC managers you need more than a polished demo that works great in your conference room. You need buyer-ready proof with applicable workflows shown in context that speak the buyer’s language. That’s pipeline. That’s currency.

ICO recently did with PypeServer. This vendor's customer, demoed PypeServer's model-to-machine workflows so another VDC manager can not only relate, but forward directly to their own shop leaders.

👇🏻 this clip speaks to the experience of this mechanical VDC manager sharing how he uses this system.

In my experience most early-stage contech decks look kinda similar:

💸 “Total Addressable Market” slide with a trillion-dollar number no one believes.

💸 “Competitive Landscape” slide with bubbles, arrows, and 10 logos.

💸 “Product Roadmap” slide promising AI, blockchain, and maybe teleportation by Q4.

What if those same slides told a sales story? What investors really want is proof of your adoption. Instead of a market size slide, show where the pipeline is already moving: demo requests booked, pilots signed, renewals pending.

Instead of a competitive grid, show an adoption snapshot. For example: a custom builder using Ressio Software that shaves two days off weekly project reporting with its real-time client summaries, so communications, and building decisions don't cause delays or a construction controller using Ressio’s budget monitoring and auto-invoicing to keep next-month cash flow crystal clear. That’s differentiation. That’s what turns a maybe into a yes. And other proof like this: how a project manager using Riskcast Solutions cut down payroll processing from three hours to thirty minutes with validated timecard data, or how a controller piloting ControlQore showed their owner a live snapshot of lien waivers cleared before releasing payments. That’s showing not telling.

Your average pitch deck whispers, “Here’s what we hope will happen.” A vivid sales-story puts your stake in the ground, “Here’s what’s already happening and here’s how fast it’s happening.” In today’s funding climate, only the second one gets you anywhere near a term sheet.

This is the value of ICO's Customer Acquisition Builder™ system. We run focused livestreams strategically drilling down to the factors that equip your customers with proof of the application(s) your platform transforms. That’s how you convert winds of interest into actual revenue to build a stronger case for your next raise.

So the lesson here is don’t just aim to raise. Aim to activate. Because in today's contech funding climate, pipeline is your new balance sheet.

🎥 Upcoming Livestream - September 9 at Noon EST

Turn Quality Control into Cash

If the last 10% of your projects are where time and money vanish, you’re not alone. That’s why in Intelligent Construction Opportunities upcoming livestream we’re tearing it up with Renee and Greg Glendenning of Quality Control University to walk through three of their most field-proven QC tools — the Responsibility Matrix, the Cx Flow Chart, and the Submittal Tracking Log.

Together, they’ll show you how to stop burning cash in the home stretch and close projects with their experience and confidence cause they're construction pros themselves! If you work in quality control, project management, commissioning, or in somehow own the final delivery of your projects.

Register Here