Building a Revit Project Template: The Office BIM Standard That Scales

The template is the container, everything else is the contents

Most firms have a Revit template. Fewer have one anybody trusts. The usual story runs like this: someone built an .rte three years ago from the last good project, it was genuinely useful, and then it stopped being maintained. New projects still start from it, but the first thing every project lead does is delete half of it and drag in views from a different job. That is not a template. That is a starting point with a reputation problem.

The confusion is worth naming early, because it changes how you approach the work. A project template is a container. The things people usually mean when they say “our Revit standards” are its contents: view templates, object styles, naming rules, browser organisation, schedules, sheets, and families. Those are separate disciplines with their own decisions, and this site covers several of them in detail already. Our guide to Revit view templates and graphic standards covers how a drawing should look. Our post on BIM naming conventions and file standards covers what things are called. Our walkthrough of project browser organisation covers how a team navigates a large model.

The template is where all of those decisions get frozen into a file that a new project inherits on day one. Getting the container right is a different job from getting each of the contents right, and it is the job that BIM managers most often skip.

What actually belongs in a project template

A good .rte carries settings that every project of that type will need, that are expensive to recreate, and that are painful to change once modelling has started. That last criterion is the useful filter. Object styles are painful to retrofit across 200 views. A door family is not painful to load later. One belongs in the template and one does not.

Here is the working list:

Category	What to include	Why it belongs
Graphics	Object styles, line styles, line patterns, line weights, fill patterns, material graphics	Retrofitting these across an in-flight project is a day of work and a source of drawing inconsistency
Views	View templates, view types, filters, scope box conventions	The mechanism that makes graphics reproducible
Browser	Project browser organisation, view naming parameters, sheet grouping	Sets navigation habits before there are 400 views to rename
Data	Shared parameter bindings, project parameters, classification fields, key schedules	Parameter bindings created mid-project produce empty columns on existing elements
Documentation	Titleblocks, annotation families, tag families, dimension styles, text types, arrowheads	Annotation type sprawl is the single most common source of drawing drift
Schedules	Empty schedule templates with the right fields, filters, and formatting	The scaffolding costs hours to rebuild and nobody rebuilds it identically
Setup	Units, snaps, phases, phase filters, worksets, view discipline defaults, print settings	Cheap to set once, invisible and annoying when wrong
Content	Only the system families and the handful of loadable families that appear on every single project	System families cannot be loaded later the way component families can

Everything on that list shares one property: a project that starts without it will either recreate it badly or ship inconsistent drawings. That is the bar.

What does not belong, and why it costs you

The harder discipline is subtraction. Template bloat is not a cosmetic problem. It is a performance problem, a file size problem, and an adoption problem, and it compounds every time someone starts a project.

Keep these out:

• Model geometry. Levels and grids are the arguable exception, and even then keep them to a generic two-level setup that gets replaced immediately. A template carrying leftover walls from the project it was harvested from is a template nobody cleans.
• The full content library. Loading 300 families into the template so “everything is there” adds tens of megabytes to every project file, most of it never used. Families belong in a managed library that people pull from, not in the container.
• Project-specific anything. Sheet numbers, real room names, a real client’s titleblock text, the last project’s shared coordinates. All of it survives longer than you expect and shows up on a deliverable eventually.
• Imported CAD. A single stray DWG import brings its line patterns and text styles with it, and those propagate into every project started from the template. This is a leading cause of the mysterious line pattern list that nobody can explain.
• Unused types. Twelve wall types that the firm has not specified in four years are twelve wall types that a junior modeller will pick from at random.

Run Purge Unused repeatedly before every template release, and read the list before you accept it rather than clicking through. If purging removes something you needed, that is information: it means nothing in the template referenced it, and the template is not the right home for it. The performance logic here is the same one covered in our guide to fixing slow Revit models, applied at the point where the bloat originates rather than after it has spread across a live job.

Start with an audit, not a blank file

The instinct is to open a fresh Revit default template and build up. This produces a technically clean template that nobody uses, because it does not match how the firm actually draws.

Do the reverse. Take the three most recent projects that went out the door and shipped well, and audit them:

1. Export the object styles and line patterns from each and compare them. Where all three agree, you have found a real firm standard. Where they disagree, you have found a decision that needs making rather than harvesting.
2. List every view template in use and how many views each one drives. View templates applied to two views are personal preferences. View templates applied to sixty views are standards.
3. Collect the annotation families and text types actually placed on sheets. You will typically find eight text types where the firm needs three, and that is the number the template should carry.
4. Pull the schedules that appeared in the issued set, not the ones sitting in the browser unused.
5. Ask the three project leads what they deleted from the old template on day one, and what they dragged in from elsewhere. This conversation is worth more than the file audit.

The audit gives you an evidence-based starting list, and just as importantly it gives you the argument you will need later when someone insists their preferred wall type is a firm standard.

The build sequence that works

Order matters, because later steps depend on earlier ones and reworking is expensive.

1. Units, snaps, and project settings first. Everything downstream inherits them.
2. Object styles, line styles, patterns, and materials. The graphics foundation. Nothing above this layer is stable until this is agreed.
3. Shared parameters and project parameters. Bind them before you build schedules or tags, because tags reference parameters and schedules reference bindings.
4. Annotation and text types, then tag families, then titleblocks. Documentation reads bottom-up.
5. View types and view templates. These consume the graphics and filter layer you just built.
6. Project browser organisation. Set it once the view types exist so the grouping parameters actually have values to group on.
7. Schedule scaffolding. Empty schedules with the right fields, sorting, and formatting.
8. Sheets and the starting view. A single sample sheet plus a starting view carrying the template version and instructions.
9. Worksets and phasing. Only the ones every project uses, typically Shared Levels and Grids plus a discipline split.
10. Purge, audit, compact, and save. Then do it again after any edit.

The starting view deserves a specific mention because it is the cheapest high-value item on the list. Create a drafting view named something like START HERE, put the template version number, release date, owner, and a short “what changed” note on it, and set it as the starting view under Manage. Every person who opens a project from this template sees it first. It is the only piece of documentation that reliably gets read.

One template or several

The question every firm hits around the second year. The honest answer depends on how different the project types really are, not on how different they feel.

Approach	Works when	Breaks when
Single template	Project types share graphics, annotation, and documentation conventions; differences are mostly content	Sector requirements genuinely diverge, and people start stripping half the template on every job
Template per discipline	Architecture, structure, and MEP have genuinely different view, filter, and schedule needs	Nobody keeps the shared graphics layer in sync across the three files
Template per sector	Healthcare, residential, and fit-out have distinct deliverable standards and parameter sets	Maintenance cost multiplies, and the versions silently drift apart

The failure mode is always the same: multiple templates, one maintainer, and no mechanism to propagate a shared change. If you split, decide up front how a change to object styles reaches all of them. In practice most firms under fifty people are better served by one well-maintained template plus documented per-sector setup steps than by three templates that are each eight months out of date.

Families and the content library are a separate problem

Resist the pull to solve content inside the template. A managed library with a clear folder structure, a naming convention, and a vetting gate for anything downloaded from a manufacturer is a different piece of infrastructure, and it scales better because families can be updated without reissuing the template.

What the template should carry is the system families that cannot be loaded later, plus the small set of loadable families that genuinely appear everywhere: the titleblock, the tags, the annotation symbols, the section and elevation marks. Everything else lives in the library.

If your families themselves are inconsistent, the template will not save you. Our guide to Revit family creation fundamentals covers the parametric discipline that makes a library worth maintaining, and the vetting gate for third-party content is covered in our post on manufacturer BIM content and product data templates.

Shared parameters and the schedule scaffolding

This is the part of the template with the longest tail of consequences, because parameter bindings behave differently from graphics. A view template applied late still works. A shared parameter bound late leaves every existing element with an empty value, and somebody has to go and fill 4,000 of them.

Three rules:

1. One shared parameter file, stored centrally, backed up, and never regenerated. Regenerating the file creates new GUIDs, and new GUIDs mean the parameter is a different parameter as far as Revit and IFC are concerned. This quietly breaks schedules, tags, and exports on every project that used the old file.
2. Bind the parameters the firm always needs, and only those. Classification codes, asset tags, fire rating, acoustic rating, cost codes, whatever your deliverables actually require. If a client asks for it on one job, that is a project-level binding, not a template one.
3. Build the schedules empty but complete. Right fields, right sorting and grouping, right formatting, right filters. An empty schedule that populates itself as the model grows is one of the strongest quality signals a template can carry, because it makes missing data visible instead of invisible.

The mechanics of getting this right are covered in our guide to Revit shared parameters and schedules. If your projects carry classification codes, decide the system before you bind the fields, because the parameter structure follows from it. Our overview of BIM classification systems covers the choice.

Governance: the template needs an owner

A template without a named owner degrades. Not gradually, and not because people are careless, but because every project has a legitimate reason to want a change, and with no owner those changes land as forty personal variants instead of one release.

The minimum viable governance:

• One named owner. A person, not a committee and not a role that nobody currently holds. The owner is the only person who edits the master file.
• A change request route. Even an email address or a shared list works. The point is that requests are visible and get answered rather than solved locally.
• A version number on the file and in the starting view. Firm-Template-v4.2.rte beats Template_FINAL_new_v2_USE_THIS.rte by a wide margin.
• A release note. Three bullets on what changed is enough. People adopt changes they understand.
• A scheduled review. Twice a year, or after any Revit version upgrade, whichever comes first.

The other half of governance is knowing when to say no. Most requests are genuine but project-specific. Adding all of them is exactly how a template becomes the bloated file people strip on day one.

Version upgrades and live projects

Two migration questions come up constantly, and they have different answers.

Revit version upgrades. When your firm moves to a new Revit release, do not simply open and save the template. Open it, run an audit, check that no add-in-generated content came along, review the object styles for anything the new version added, purge, and then save as the new version with an incremented template number. Keep the previous version file available, because projects already running in the old release still need it. Realistically you will maintain two template versions in parallel for a year, and that is fine as long as both are numbered and only one is the current default.

Live projects. You cannot retrofit a template onto a running project, and you should not try. What you can do is transfer specific pieces. Transfer Project Standards moves object styles, line patterns, view templates, materials, and type properties from the template into an open project. Use it deliberately, one category at a time, and always on a detached copy first. Transferring everything in one pass on a live model is how firms discover that “Overwrite” quietly changed 60 wall types.

For anything shared across a team, remember that the template also sets the worksharing starting position. Our guide to Revit worksharing for teams covers the workset conventions worth baking in.

Test before you release

A template release is a deployment, and deployments get tested. The test is straightforward and takes about an hour.

Start a genuinely new project from the candidate template and model a small but complete vertical slice: a few walls, a door, a window, a room, a level change, one section, one elevation, one plan, one sheet. Then check:

• Does every view open with the intended view template applied, without manual intervention?
• Do the tags find their parameters and read correctly?
• Does the sample sheet print at the right scale with the titleblock populated?
• Do the empty schedules populate with the elements you just modelled?
• Do the browser groups sort the new views where you expect?
• Does the file open in under the time your team will tolerate?
• Does Warnings show a clean list on a model this small?

Anything that fails here fails on every project started from this template, multiplied. The broader model checking discipline in our BIM model quality assurance workflow applies to the template itself, and running those checks on the container rather than only on projects catches problems at the source.

Knowing whether the template is actually being used

Adoption is the metric that matters, and it is easy to check informally. Once a quarter, open the three most recently started projects and look for the tells:

• Is the starting view still present and still showing the current version number?
• How many view templates are in use that are not in the firm template?
• How many new text types and dimension styles have appeared?
• Did anyone import a DWG that dragged line patterns in?

Drift is not automatically failure. If three separate projects all created the same missing view template, the template is incomplete and that is a feature request, not misbehaviour. If every project deletes the same six wall types, delete them from the template. The audit tells you what to build next, and treating it that way is what earns the template its credibility with the people who have to use it.

Common mistakes

• The kitchen-sink template. Everything anyone ever asked for, 180 MB, three minutes to open, stripped on day one of every project.
• No owner. Universal, and the root cause of almost every other item on this list.
• Harvesting from a live project without cleaning. Brings geometry, project-specific text, imported CAD, and stale shared coordinates.
• Regenerating the shared parameter file. New GUIDs, broken tags and exports, and a bug that surfaces months later during an IFC handover.
• Skipping the starting view. The one place people would have read the release notes.
• Version-numbering by filename suffix. _FINAL_v2_new is not a version scheme.
• Building it in isolation. A template authored by one person who has not modelled a live project in two years will not match how the firm draws, and it will lose to the last good project file every time.
• Never purging. Bloat is cumulative and invisible until the file is unusable.

How to start this month

If your firm has no template worth the name, do not plan a six-month standards programme. Nothing ships from those.

Week one: audit the three most recent good projects and list what they agree on. Talk to the leads about what they delete.

Week two: build the graphics and parameter foundation only. Object styles, line patterns, text and dimension types, shared parameter bindings. Nothing else.

Week three: add view templates, browser organisation, the titleblock, and the empty schedule scaffolding. Add the starting view with a version number.

Week four: run the vertical slice test, purge, name it v1.0, write three bullets of release notes, and release it. Then start collecting change requests for v1.1.

A v1.0 that covers eighty percent of what projects need and actually gets used beats a perfect template that arrives next year. The template earns trust by being maintained, not by being complete on the first release.

If you want to build the underlying Revit and coordination skills that a firm standard rests on, the courses at Archgyan Academy cover the workflows firms actually run, all in one subscription. And if you are weighing up where template and standards ownership sits as a career step, our BIM career roadmap covers how the BIM manager and coordinator roles differ in practice.