I’m often doing ‘forensic analysis’ on project files – either for new clients, or in some cases, reviewing past project files before an upcoming new scope of work. A primary aspect of reviewing models is not just finding issues, but communicating to the team the following:
a) What the issue is
b) Why it’s an issue (what’s the downside/repercussions, etc)
c) What is the recommended approach (if one of several options, why this particular method)
I use snapshots of the model as the primary means of identifying the issue, and write up a summary to accompany it. This is usually distributed to the entire office as a ‘Revit Revelation’* so it can be a learning opportunity for all project teams, not just the one who needs to resolve it. These are also documented for future reference.
This kind of training approach does require that an office be willing to have their errors (or just less-strategic decisions) aired to the rest of the team(s). It should not be seen as finger-pointing, but as a directly applicable learning opportunity – the kind that really stick! Another great benefit? The model snapshots give a visual clue as to how to conduct similar QA/QC checks on project models on their own.
More power to the team!
*That is SOOO trademarked, my fellow Revit bloggers! ;^D