The only standardization that survives contact with a construction project is the one nobody has to be retrained for.
A decade of standardizing people
Most innovation teams in construction have run the same play for ten years. Survey the business. Find the team that does takeoff, or bid leveling, or closeout best. Name their tools and their practices "the standard." Then roll it out: every other team migrates, retrains, and retires the stack it built for itself. A dashboard tracks adoption. Champions get appointed. Eighteen months later adoption has plateaued, the best team is quietly doing what it always did, and everyone else is a little worse at their job than before the program started.
The reason is not that construction people resist change. It is that there is no single best teacher for every student in a classroom, and there is no single best tool or practice for every estimator on a team, let alone across business units, regions, and project types. The "best practice" was best for the people who evolved it, on the projects they ran, with the subs they knew. Transplanted onto a different team it is just a foreign process with a training deck attached.
Standardizing at the people level is, by definition, a change-management program. It means retraining, data migration, broken muscle memory, and a productivity dip that lands exactly when the project is busiest. And it upsets the majority by the very nature of the change: you have told most of the company that the way they work is wrong, and asked them to get slower for a quarter so a chart turns green.
It does not stop at your company line
Even if a general contractor could standardize every team inside its own walls, most of the work happens outside them. A project is a GC, its subs, the engineer of record, the architect, the owner's rep, and a long tail of suppliers. Each of them has an optimal way of working, and it is optimal for their business, not yours.
A mechanical sub that sends bids as a PDF attached to an email is not behind the times. That workflow is the right one for a twelve-person shop bidding forty GCs a month, each with a different portal and a different login. An engineering firm that answers RFIs in its own tracker is doing what its liability insurer and its other thirty clients expect. The owner wants the monthly report in the format their board already reads.
Tool mandates across this ecosystem have never worked. "You must submit through our portal" gets ignored, or, worse, it quietly shrinks your bid coverage because the best subs have enough work to skip the GCs that make them jump through hoops. The ecosystem is where most of the information on a project lives, and the ecosystem will not standardize for you.
The industry has already run this experiment
None of this is theoretical. The industry has tried standardizing at the people level at every scale, from a single owner to a national government, and the results are on the record.
Owners mandated a platform. Contractors got double entry. In a 2019 Dodge Data & Analytics study for e-Builder, seven in ten owners with a project management system required their contractors to use it. Only 16% of contractors said the owner's system matched their own, and only 14% could integrate the two. Roughly two in five contractors ran both systems in parallel, and almost three quarters said the double entry hurt their productivity. The mandate did not produce one system. It produced two, with a person in the middle re-keying (Dodge / e-Builder, 2019, ENR).
A national government mandated BIM. Enforcement quietly lapsed. The UK made BIM Level 2 a condition of centrally procured public work in April 2016, the most ambitious top-down standardization the industry has seen. Two years later the NBS National BIM Report found a growing share of firms saying the mandate was not being enforced at all, and the barriers it listed were the people-level ones: no in-house expertise, no training, no time to get up to speed (NBS 2018 via PBC Today, Building). Even a government cannot retrain an industry by decree.
Firms standardized on one authoring tool. Then the tool owned them. In 2020, Zaha Hadid Architects, Grimshaw, Rogers Stirk Harbour, Wilkinson Eyre and others published an open letter to Autodesk. Their Revit costs had risen by up to 70% between 2015 and 2019 while, in their words, practices were "paying more but using Revit less because of its constraints." More than 116 firms signed or supported it, 32 of them privately, out of fear of repercussions from a vendor they could not leave (Dezeen, The Architect's Newspaper). That is what a decade of people-level standardization looks like from the inside: the switching cost is now so high that the world's best design firms write letters instead of switching.
And in the meantime, the status quo is manual. The 2020 JBKnowledge ConTech survey found that only 5% of construction firms had all of their apps integrated. When the apps did not connect, 49% moved the data by manual entry and 44% by spreadsheet (Construction Dive). The connective tissue of this industry is a person with two windows open.
One case from outside the industry is worth a line because it is the purest version of the pattern. Lidl spent seven years and a reported €500 million trying to move onto SAP, then cancelled it in 2018. The core conflict was that Lidl ran inventory on purchase prices and the standard software assumed retail prices. Lidl refused to change how its people worked, the system could not bend far enough, and the project collapsed (Consultancy.uk). Both answers on the table were wrong: retrain 1,000 people into a practice that would cost the company its edge, or buy a system that could not absorb the practice they had. The right answer was a system built to absorb it.
Standardize the system instead
What should be different is where the standard lives. Let people keep their practices and their favorite tools. Put the standard in the system that connects them: one layer whose only job is to make every tool compatible with every other, and to present the information to each person in the format they want to see it in.
An estimator who is fast in On-Screen Takeoff should work in On-Screen Takeoff, even if the estimator two desks over does the same scope in Bluebeam. Both are marking up the same drawings. The quantities should flow into the same estimate either way, and neither person should have to know which tool the other used. If subs are comfortable sending bids by email, let them. If the precon team wants to see those bids leveled in BuildingConnected, a system should pick the bid up out of the inbox, structure it, and put it where the precon team is looking, without anyone re-keying numbers and without the sub ever being told to create an account.
This was always the right idea. It was not possible until recently. For twenty years "a system that connects everything" meant integrations: point-to-point connectors, brittle on every version change, and available only when two vendors' roadmaps happened to agree. Whether your takeoff tool talked to your estimating tool was a decision someone else made.
AI changes the economics. An agent that can read an email, a PDF bid form, a takeoff file, or a scanned RFI response, understand what it is looking at, and write the result into the target system is connective tissue that adapts to the humans instead of the other way around. With an open protocol layer underneath it, so that every tool exposes what it knows in a common way, the system stops being a web of integrations and becomes a single fabric the whole project runs on. The tools stay. The people stay. The fabric does the translating.
Fluidity, not sunk cost
There is a second effect, and it may matter more than the first. Once the standard sits at the system level, switching tools becomes cheap.
Today an estimator with eight years in one takeoff tool will not move to a better one for any amount of benefit, and they are right not to. The switching cost is not the license. It is the retraining, the lost history, the handoffs that break downstream, and the three weeks of being the slowest person in the room. Construction has institutionalized the sunk cost fallacy, one tool at a time, because every tool is also a silo.
If the system carries the information regardless of which tool produced it, that cost collapses. A person can try a new tool on Monday and go back to the old one on Tuesday, and nothing downstream notices. Better tools win the way they should, on merit, one user at a time, instead of by mandate. And the question an innovation team asks about new technology changes from "can we roll this out to four hundred people" to "does our system let the people who want this use it." The second question is the one a frontier firm asks.
Change management is the problem, not the solution
Ask anyone who has tried to put new technology into a construction company what the hardest part was. It was not the technology. Change management is the single biggest obstacle to adoption in this industry, and there are only two ways through it.
- Get very good at change management. Long rollouts, executive sponsors, champions on every project, training calendars, incentive plans, and the patience to repeat all of it when the next tool arrives.
- Eliminate the need for it. Build the system so that nobody has to change how they work for the organization to get the benefit.
The industry has run the first play for twenty years, and the resistance has won every time. Not because the people are stubborn, but because the play asks them to get worse at their jobs for a while in exchange for a benefit that mostly accrues to someone else. That is a bad trade, and field and precon people are good at spotting bad trades.
The second play has only recently become available, and it is the one worth running. If no one has to change, there is nothing to manage. The target is adoption that does not require anyone to adopt: the sub keeps emailing, the estimator keeps their tool, the engineer keeps their tracker, and the firm still ends up with one leveled bid tab, one estimate, and one RFI log.
Nonstandardization is the new standardization
This is what Muro is built to be: the operating system underneath a construction firm that lets every person keep working the way they already work, in the tools they already know, while the firm still gets one coherent picture of every project.
Muro connects to the systems a project actually runs on, including the estimating and takeoff tools, the bid platforms, the document and BIM repositories, the ERP, and the inbox, through an open protocol layer (MCP) so that each one exposes what it knows in a common way. On top of that layer, domain-trained agents do the translating: they read a bid that arrived as a PDF in someone's email, structure it, and put it where the precon team is looking; they reconcile quantities whether the takeoff was done in On-Screen Takeoff or Bluebeam; they keep the RFI log current whether the engineer answered in a portal or in a reply-all. Nobody is asked to migrate. Nobody is asked to retrain. The standard lives in the system, and the people, processes and products stay exactly as varied as the work requires.
That is the inversion the industry has been waiting for. The firms that win will not be the ones that finally got everyone onto one tool. They will be the ones that stopped trying, and built, or bought, the layer that made it unnecessary. Nonstandardization is the new standardization.
Building frontier construction firms
The frontier construction firms of the next decade will not be the ones with the most standardized people. They will be the ones whose systems absorb the most variety, any tool, any sub, any format, any geography, and return a single coherent picture of the project to whoever needs it, in the shape they need it in.
That changes the job of the innovation team. It stops being the enforcer of a standard and becomes the builder, or the buyer, of the system that makes the standard unnecessary. It is a harder problem than picking a tool and writing a rollout plan. It is also the only version of the problem this industry has ever shown any willingness to solve.
It is time to think radically differently about standardization. Not fewer tools and more training, but any tool, no retraining, and a system underneath that holds it all together. That is the thesis Muro is built on, and it is how frontier construction firms get built.