Hi Don, I think you want to keep the submitted record model for each scope with all its sheets and 2d information, but use those recordays models to update and maintain an as built model perhaps even at a higher LOD. This updated model will then be used as a base for any new work. You can still have views and sheets in that model, just not all the dimensions and noted that are typically found in a complete set of cd'soI'm interested to see other ideas.

Yes we need to keep a "record model" for each project. We have a project number structure and everything related to a specific project is stored under that Project folder.

We're tying to figure out the best way to maintain the main model to ensure that it reflects the work that is done within these individual projects.

with the limited information I have I think what I suggested could work, makes sense and is what I would do. But let me ask this? What is the "Main model" where did it come from? what is its overall current and desired use. If you can answer those question then I think you may on the better path to a solution or workflow.

Depending upon the project, it doesn't exist (yet) (most cases) or we just finished a project in which a bldg. was constructed. We're relatively new to the Revit world and we're trying to develop "best practices" now rather than later.

Moving forward, if a bldg. is to have some sort of major remodel, they're going to have it 3d scanned and a model created. The remodel plans will use the scanned model as its existing phase. The remodel work will be added in a construction phase. That will be retained in the specific project as-is.

But then we also want to keep an up-to-date model representing its "new existing phase" which would in turn be used as the basis for the next project on that bldg.

We also need to keep in mind that after we do a project, the commissioners might elect to NOT move forward with a project for a few years. During that on-hold period, it's possible that other projects might take place. Now the "existing phase" from the held project no longer represents the true current conditions of the bldg.

this is an interesting challenge to solve. i'm sure someone on revitforum.org, must have already done this.

'Big Picture' - i'm thinking your 'main' model (of some bldg), and all of it's various 'project models' could be compiled in an environment like Navisworks. Navisworks because it's does pretty well at being agnostic to file types. it will link-in .dwg, .dgn, .rvt, .ifc, 'point-clouds', and others. this brings another issue to be dealt with - origin point. all models of the bldg must use the same origin point in order for all the model to be aligned in Navisworks, although maybe that's not an issue in your case.

what i like about using a Navisworks model, is that it could be built to accommodate all possible phases and as-built conditions (with all the associated data) and be made accessible to all facilities staff (and/or design/construction staff), on the Internet, via pretty much any smart-device.

a while ago, i tested a couple of these scenarios for a health-care facilitiy, using Navisworks (and it worked), although your requirements are probably different than the ones i was working with.

hope this helps and let us know what you discover to solve this issue.

I have been thinking of how to work out a similar scenario; it's definitely a challenge. This diagram represents my current thoughts on how something like this might work:

I think you will need (3) levels of model hierarchy: Master, Record, and Project. The Master-level models are your "up-to-date" models, the Record-level models are compiled, versioned, and issued by you (at milestones of your choosing) - these are what you issue and use as "base files" for projects (each project / scope / contract can be based on a known Record model version). The Project-level files contain and generate the CDs for that project. Upon project completion, you bind the Project model into the Record model, do any necessary cleanup, and prepare to version that model at the next milestone.

Again, these are just my current thoughts; I haven't implemented this strategy yet, but looking forward to any comments.

It is an intereting situation.
We have something similar going on in our projects (we do retail). At any stage there may be 2-3 small upgrades occurring while a major contract is being executed as well, leaving documentation issues.

We use design options for the smaller works and project phasing for the main contract. Perhaps you could consider that.
Have a "model of record" on your server, essentially archived as built model. Any new projects / work can be generated in a "detached copy" of that model using design options. This way you can chose what to show and what not to if / when the Construction is completed.
If the work is actually built, you can accept that option, the "old existing & demo" elements are removed and you have a new "as built" model. This can then replace your model of record. Rinse and repeat for each new stage or portion of work. Of course, like anything it will take some planning and management.

Hope this makes sense.

I think the best approach (similar to cellersick) is to use a federated model, which contains links of other models (original site-landscape-topography, existing buildings "as-built", etc.). Every file or link in that federated model would have a separate folder (or job number) with copies to be altered according to the purpose (as-built, future phase renovations, etc.). Depending on the different project stages (accepted renovation jobs), the federated model will update its links to always reflect the current development stage.

It is crucial that you use worksets in a good and consistent way on every model, so you can manage visibility of components in your federated model... otherwise it can be a nightmare!

Thanks for all the advice and sorry for the long delay in responding. I've been working on other higher priority tasks and haven't had time to look at this.

We're still trying to find a good fit.