Lesson 3.4Lesson 3.4 · The Model & Its Objects
Model Uses & the Right Level of Effort
Decide what the model is for — then model exactly that much, and no more
The most expensive words in BIM: 'model everything, to the maximum, just in case'.
It sounds responsible — model it all, in full detail, to the highest level, so you are covered. It is actually one of the most expensive mistakes a team can make: weeks spent developing objects nobody will ever query, detail that clogs the model and slows everyone, and a false confidence that 'everything is modelled' when what was needed was never asked.
The cure is a single, disciplined habit done *before* you model: name the model uses — the specific things this model must actually do — and then apply exactly the level of effort each use requires. Not more, not less. Purpose decides development. Get this right and the model is lean, trustworthy and fast; get it wrong and you either drown in needless detail or discover, too late, that the one thing you needed was never modelled well enough to rely on.
Ask 'what is this model for?' before 'how do I model this?' — and you will never over-build again.
Start from the use, never from the object
The instinct is to open the model and start building walls. The discipline is to stop and ask: what will this model be used for? A model use is a specific, nameable job — design coordination, clash detection, quantity take-off, energy analysis, construction sequencing, facility management, a planning visualisation. Each is a real purpose with real requirements.
Uses matter because *they* decide everything downstream: which objects must be modelled, to what LOD, carrying which data. Energy analysis needs reliable thermal data and correct spaces, but not every bolt. Quantity take-off needs complete, correctly classified objects, but not photoreal finishes. Clash detection needs accurate geometry and the connections between systems (LOD 350), but not verified as-built data. When you start from the use, the required level of effort falls out almost automatically. When you start from the object, you have no principled way to decide how far to develop it — so you either guess, or you default to 'maximum', which is the expensive mistake.
Level of effort: match development to need, in both directions
Level of effort is the practical partner of LOD: it is the decision to develop each object only as far as its uses require — and it errs in *both* directions. Over-modelling is developing beyond need: modelling a ceiling void's every clip when nobody will fabricate from the model, or pushing everything to LOD 400 during concept design. It wastes time, bloats the file, slows coordination, and — most insidiously — dresses up fluid ideas as settled fact. Under-modelling is the opposite: leaving an object too crude or data-poor for a use that depends on it, so the quantity is wrong, the clash is missed, or the analysis is starved.
The skill is calibration. For each object, the question is not 'how good can I make this?' but 'what is the least development that lets every use of it succeed?' That least-sufficient level is the target. It changes over the project — an object developed to LOD 200 for early coordination is pushed to 300 for documentation and perhaps 400 for fabrication — so level of effort is not a one-time setting but a moving match between what the model must do *now* and how far its objects are developed.
Over-model and you pay in time. Under-model and you pay on site. The target is 'just enough for the job'.
Where this gets written down: the BIM Execution Plan
This is not meant to live in each modeller's head. On any managed project the model uses and the level of effort are agreed and recorded — most formally in the BIM Execution Plan (BEP), which we meet properly in Module 5. The BEP names the uses the project requires, and sets, for each object type and each milestone, the LOD it must reach and the data it must carry. That is what turns 'model sensibly' from a hope into a checkable requirement.
On Indian public projects this is explicit and contractual: the CPWD framework expects a BEP and ties coordination to a defined LOD (commonly 300), precisely so that effort is governed rather than guessed. The deeper point is that level of effort is a shared decision, not a personal style. If one modeller develops to fabrication level and another leaves placeholders, the model is neither lean nor trustworthy. Naming the uses and agreeing the effort up front is what lets a whole team develop the model to the same, purpose-fit standard — and lets a client know they are paying for exactly the information they need, and not for detail they will never use.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn the order: use first, effort second. A model use is a specific job the model must do — coordination, clash detection, quantity take-off, energy analysis, sequencing, facility management. The use decides what to model, to what LOD, with what data. Level of effort means developing each object only as far as its uses need — no more, no less. Over-modelling wastes time and hides design intent; under-modelling starves a use that depends on the object. The target is always 'the least development that lets every use of this object succeed'.
Model to the job in front of you. Before developing an object, know which uses touch it and what each needs, then develop to the least-sufficient level — and re-develop as the project moves (LOD 200 for early coordination → 300 for documentation → 400 for fabrication). Resist 'just in case' detail: it slows everyone and disguises unsettled decisions as fixed. Equally, do not under-serve a use you know is coming (if quantities will be taken, classify and complete the objects). Your efficiency and your model's trustworthiness both come from matching effort to purpose, continuously.
Make level of effort a governed decision, not a personal habit. In the BEP, name the model uses the project requires and set, per object type and milestone, the LOD and data each must reach — tied to real uses, not a blanket maximum. This is how you stop paying for detail no one will use and stop being surprised by a use that was never modelled for. On Indian public work, align to the CPWD expectations (a BEP; LOD 300 at coordination). The message to the team and client is the same: we model exactly what the purposes need — which is leaner, faster and more trustworthy than 'model everything to the max', and far cheaper.
“To be safe, model everything in full detail to the highest LOD.”
Do it yourself
Practise deriving effort from purpose on a single object.
- 1Pick one object — say an internal partition wall. List the uses that will touch it over the project: early coordination, clash detection, quantity take-off, documentation, maybe acoustic analysis.
- 2For each use, write the least the wall must be for that use to succeed: approximate size and position (coordination) → accurate geometry and connections (clash) → correct construction and classification (quantities) → verified data (documentation) → real acoustic properties (analysis).
- 3Now find the *driving* use — the one that demands the most — at a given stage. That sets the wall's target development for that stage. Notice you derived the effort from the purposes, not from 'how good can I make it'.
- 4Finally, imagine developing the wall to full fabrication detail during concept design, before the layout is even fixed. Write one line on what that costs — in time, in file weight, and in mistaking an unsettled idea for a decision.
The one line to carry out
That completes the model and its objects — how they are structured, what they carry, and how far to develop them. But a model only delivers when its information can move between the many tools a project uses. Module 4 opens interoperability and openBIM: the problem, and the open standards that solve it.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →