On most projects, the model shows up after the decisions are made. Massing gets explored in sketches and surface-modeling tools, the competition board gets built in a rendering software, and the first real building model opens when it is time to produce documentation.
By then the big moves are already settled, from footprint and structure to envelope and floor-to-floor height.
That sequence does not align neatly with the way the phases are actually defined. The RIBA Plan of Work expects the architectural concept to be approved and signed off at Stage 2, and it cautions that a project should not proceed to Stage 3, spatial coordination, if any spatial requirements or room adjacencies remain unresolved.
Coordination, in other words, is meant to start with an approved concept. When that concept was never a model, the first model is not the approved design. It is a translation of it.
It is tempting to blame the software. The more honest answer is that at the front end of a project, there is nothing to model with.
Schematic design moves hour by hour. You are testing a corridor width, swapping a stair, checking whether the units still fit after the setback changes. Doing that inside a building model means having doors, windows, cores, fixtures, furniture and equipment already on hand: hundreds of objects at a level of detail nobody needs yet. Building them from scratch costs more than drawing them instead, so teams draw. The model waits until documentation, when the effort finally pays for itself.
The second reason is cultural, and it is fair. Early design is supposed to stay loose, and anything that feels like commitment, like naming an element or locking in a type, reads as premature.
The cost does not land on the design team. It lands on everyone who works from what the design team hands over.
Start with the estimate. The estimate classes published by Alberta Infrastructure, built on the classification system from AACE International, put a Class 5 estimate, the one produced when a project is 0% to 2% defined, at -30% to +50%.
A Class 4 estimate, described as based on schematic layouts, tightens -20% to +30%. That gap closes when the concept carries quantities and assemblies you can count instead of assuming. A better spreadsheet does not help. A concept that exists only as geometry, with no data behind it, leaves an estimator with area, judgment, and little else.
Then coordination. If the approved concept lives in a sketch and the model is a rebuild, every question about that concept gets answered twice, once by the person who drew it and once by the person who modeled it.
Some of the discrepancies that surface in clash review originate there, several weeks before anyone traces them back to the rebuild.
Useful numbers do not require construction-level detail. They require objects that know what they are. Once the concept carries real elements, counts, areas and assemblies come out of the model, and the team can price two options instead of defending one. The estimate stops being a verdict delivered late and becomes a test you run while the design is still cheap to change.
When the concept is the model, spatial coordination does not begin with a rebuild. Engineers receive the design the client approved rather than an interpretation of it; structure and MEP systems are tested against real geometry weeks earlier, and the first coordination review no longer doubles as a reconciliation.
Furniture, fixtures and equipment data is usually the last to arrive, while the elements themselves are often the first to be substituted on site. When those elements enter the model during conceptual design as real objects carrying real parameters, the specification inherits that information instead of recreating it, and the handover documents have a chance of describing what was actually built.
None of this calls for a different tool. Instead, it means deciding, before the next project starts, what teams are allowed to use at the front end.
Framing the blank file as a governance choice is where the conversation usually stops. Decide on a concept content set, name its sources, give it an owner.
But that leaves the harder question of where the content comes from, and for most offices the honest answer is that building it is the expensive part.
Take a boutique firm in Texas that works on high-end residential. It calculated that each custom Revit family required about 24 hours of designer time, or close to US$1,200 once the hourly rate and overhead were factored in. That is one family.
A typical project included around 100 custom objects. Doing that math was reason enough to delay modeling until it became unavoidable.
After the firm brought in a ready-made content library, the same object took about 15 minutes to find and place.
Its Planning and Schematic Design phases went from three months each to about six weeks each. The team was not working faster. It had simply stopped building the library before it could start designing.
The firm's CEO put it plainly.
“Our designers are so busy that they make more money in the field. It does not make sense for our business model to have them modeling for 24 hours when they could be generating revenue.”
The interesting part is not the return on investment. It is that the team started designing before it was officially in the design phase.
The model that used to wait for documentation now begins at concept stage and carries through to the site, with no rebuild in the middle.
The months cut from the early phases had previously gone into doing the work twice: once in the sketch and once in rebuilding it as a model for documentation. That second pass disappeared.
The firm also moved from SketchUp to Revit, not so much because of a top-down decision as because the friction that used to push people toward SketchUp was gone.
This is where Blocks fits. It is a ready-made library of BIM content, not a modeling plugin or a methodology. In practice, it serves as the concept content set described here, without the office having to build it. It is closer to infrastructure than to an authoring tool.
Three caveats, because the case is easy to oversell.
Modeling too early can freeze exploration. If the first massing study arrives with types, parameters, and naming conventions attached, people stop moving walls. The content set has to stay light enough so that changing your mind is still cheap.
Heavy content punishes you immediately. Concept files loaded with high-detail objects get slow at the worst possible moment, which is why early content should be deliberately coarse.
And be careful with the rework argument. It is the easiest case to make and the weakest. Research published in the Journal of Construction Engineering and Management and summarized by ASCE puts field rework at 0.38% of contract value before completion and 0.76% once post completion corrections are included. Those figures are well below the double-digit numbers the industry likes to quote, although the same study found rework underreported by 300%.
So the argument for modeling the concept early has little to do with rework. It is about the options you get to price and coordinate while they are still open.
The blank file has nothing to do with technology. It comes from asking a team to model at one moment when nothing is ready to be modeled. Decide what can be used at the front end of the project, and the sequence corrects itself. The concept becomes the model, and everything downstream inherits a decision instead of a redrawing. That is not a software upgrade. It is a choice about what the first hour of a project has to work with.
