IT20549

Health Check for Your Revit Project Models

James E. Moore, AIA | Virtual Design Manager
Shive-Hattery, Inc.

Learning Objectives
 Discover common issues that negatively impact model file performance
 Learn how to identify what aspects of model health can be checked through
automated processes
 Evaluate options for communicating model health to the team working on the
project
 Learn how to develop project-health tracking and reporting documents

Description
Nobody is perfect. We all acknowledge it, and we are often reminded when problems with our Revit
files come up. Everyone has a list of “low hanging fruit” that they turn to when troubleshooting a
project. For example, are things on the right workset? Has another file format been imported and
exploded? Are the phases consistent between links? What if we could check these things before
the problems arose; like that annual checkup we all get at the doctor’s office? If we present the
results of these model checkups to teams, can we start to positively influence modeling practices?

At Shive-Hattery, we’ve worked to create a fitness check system for all of our discipline models. In
this session, we’ll use PowerPoint slides and live examples to show BIM Coordinators/Managers
and modeling leads the tools we have adopted or developed to track and report the general health
of project models. We’ll also explore the ways this information can be shared with a project team to
identify potential problems before they occur and encourage people to be more proactive when
putting together their projects.

Your AU Expert
James E. Moore, AIA – As the Virtual Design Manager for Shive-Hattery, Inc. his responsibilities
include developing and documenting standards to make the +/- 200 design and production
engineers, architects, and technicians as productive as they can be. As a licensed Architect, he
brings 18 years’ experience in the A/E industry on various project types (themed entertainment
venues to grocery stores to hospitals) to bear on the issues associated with getting eight offices and
a full range of A/E services working together so they can gain the efficiencies of shared
expectations, content, and delivery process. (jmoore@shive-hattery.com)
Why a “Health Check”?
At a 2015 industry conference, several of our staff attended a class by Michelle Ovelson
illustrating how her firm created a form that could be used along with some add-ins for
Revit to identify possible problems with their model files. The concept generated quite a bit
of buzz in our group as we talked about how something similar might benefit Shive-
Hattery’s design teams. Since our adoption of Revit as our primary building disciplines
production tool, we too often found ourselves responding to model file problems reactively
at moments of crisis. Once the fog from the trip home cleared and those who had attended
the conference got “caught up”, the idea of a proactive model review process was one of
the top concepts we decided to incorporate into our work flows.

As our brain trust of BIM Coordinators, Corporate BIM Specialist, and I started to discuss
what form a model review might take, we talked about the different issues we found
ourselves dealing with. We looked at the information provided with the model review
course. Ultimately we found most of what we were dealing with could be grouped into three
categories. We decided to apply healthcare related terms to the groups:

1. Emergency Room - These are the time sensitive, critical action required issues
a. “I get a fatal error when trying to open this model file.”
b. “We just noticed that sometime in the last two days we lost one building
section, 6 associated wall sections, and 34 live cut details.”
c. “We are plotting in 2 hours and all the hydronic piping disappeared.”

2. Urgent Care – Issues that are problematic, but not critical (yet)
a. “It takes 45 minutes to create a new local file and have it open.”
b. “The 3D structure model is visible through my exterior walls even though I am
in hidden line mode.”
c. “When I do a zoom all, nothing shows up in my view anymore.”

3. Health Check-up – Things that can be reviewed and flagged as potential problems
in the future
a. “You’re printing a quality control review set in 2 days and you still have 3
times as many views not on sheets as you do on them.”
b. “Your phases are different than those in the MEP model you’ve got linked in.”
c. “Structural has a different “floor-to-floor” height between the primary building
levels than MEP.”

As we discussed the different types of information we needed to help us identify the causes
of various types of issues, we realized most, if not all, of the Emergency Room type
problems required direct user interface and were not candidates for trying to automate a
response action. We looked at the Urgent Care items and felt we could script data
collection that would inform decisions on how to address certain issues. However, there
Page 2
was a fair amount of analysis needed to decide how to address the errors and complaints
we included in this category. We decided to focus on the Health Check list because most of
those items could be reported to the design teams and they could decide how to respond;
just like we decide whether or not to change our eating habits based on our cholesterol
levels.

Planning A Model Health Check

Of course, as soon as we agreed this was a good thing to have, our BIM Coordinators and
BIM Specialist started looking at the various ways we could collect information. Discussions
included add-ins from various vendors as well as Autodesk and, like seemingly everything
else these days, Dynamo. As we looked at these tools and how much their use would
contribute to an automated process we realized it depended on what information we were
collecting and how we were going to present it. From the conference class’s dataset we
reviewed an Excel worksheet that provided specific data as well as a place for feedback to
the designers. This appealed to us as it took what we were doing from a mere reporting
function to an educational tool.

Figure 1-Headers from SummitBIM Model Review form as presented by Michelle Ovelson

One of the differences between our efforts and the presentation our staff saw is that we are
an architecture and multi-discipline engineering firm. The information provided in last year’s
class was geared to architectural model files. This meant we needed to resolve how we
were going to report to different discipline groups using multiple model files on the same
project. Ultimately we wanted to develop a process that would allow us to generate
something we could email to the design team. We considered it extra credit if we could link
the reporting document into Revit so the design teams could see the results on a more
regular basis.

Ultimately we also decided to work with Excel to develop our reporting document. We felt it
gave us the following advantages:
 Consistent organization of information
 Pre-configured conditional formatting
 Option to have all discipline models results in a single document
Page 3
  Ability to populate data for reporting via Dynamo script
 With the right add-in tool, ability to “push” results into Revit

We ended up with seven worksheets in our reporting workbook:

Figure 2- Screen shot of worksheet tabs from Health Check Excel file

1. Instructions – contains links to documentation on the Health Check workflow

2. Arch, MEP, Strc Items – these three tabs are the actual reporting tabs
3. Arc_, MEP_, Str_Data – these tabs contain the data collected from the models and
pushed via Dynamo script

Items to Include in the Model Health Check

Throughout the discussions about how we wanted to organize the information we would
collect, people were suggesting different types of things we “should” include in our Health
Check. We had a pretty extensive list which included lots of items we find when
troubleshooting errors on model files. The list also included some of the basics of sound
model development. It was during this phase of development where we came up with the
medical analogy and decided to focus this process on the issues we could identify to a
team in order to promote better modeling practices. We ended up breaking our items into 3
categories:
1. Model Performance – Items that can have an impact on how fast a model loads or
responds to complex changes
2. Document Set Quality – Items we thought needed to be consistent between
different discipline models used to create a single set of documents
3. Discipline Specific Considerations – Items that are unique to the model elements
created by different disciplines

Page 4
Model Performance
The Model Performance group is the
same for all three of our discipline
reporting worksheets.
 Warnings – We have the BIM
Coordinator check the file and
report the numerical value for the
highest numbered warning in the
model. Since warnings are
assessed on the fly within Revit,
there is no table or object that can
be accessed via the API to report Figure 3- Model Performance Health Check Items
warning information.
 DWG links/imports – We look at the number of CAD objects in the model and
report the percentage of those that are imported. We strongly encourage our Revit
users to link any CAD information they may need for reference into model files.
 Unassigned View Category – “View Category” is a parameter used in our models
to organize the Project Browser. These categories relate to the organization of our
sheets and help break up the list of views we deal with. When no value is entered
into the parameter, we get a “???” category that becomes a catch-all bucket. When
the routine identifies views with nothing in the “View Category” parameter, it assigns
a value of “!Delete Me” and then reports the number of views in that category.
 % of Views not on sheets – One of the great things about modeling is that you can
quickly create views to look at almost any situation around your design. The problem
is that many of these views don’t go away. The item reports the percentage of views
in the project which are not currently placed on sheets. A high percentage early in
the project isn’t considered an issue; however, if you’re plotting next week and 65%
of the views you’ve created aren’t on sheets there are probably some views you
don’t need slowing down the file.
 % of Schedules not on sheets – This is similar to the views on sheets item in
setup. While extraneous schedules are less of an issue for us, they can account for
significant processor time at load as the data is cached for each schedule.
 Non-standard worksets exist in file – We have a standard set of worksets that
exist when a new project model file is created. While we do not restrict modeling
teams to this list, we have found certain individuals in the firm create worksets as if
they were layers from AutoCAD. This can cause confusion when other team
members need to edit the model.
 Objects assigned to proper worksets – This item could have been under either
the “Model Performance” or “Document Set Quality” header. Having elements on the
Page 5
 wrong worksets may impact object display when linked into other project models
which is a set quality issue. However, we see a bigger impact when people put
objects, especially linked files, on improper worksets and those objects load when
other people “close” the desired workset when opening the model. This can also
complicate troubleshooting “corrupt” files.
 Image Count – Images are complex elements and have significant impact on the
load and processing times associated with views where they exist. We recognize
there are times when they are necessary, but want teams to be wary of adding them
without good cause. This can also flag those instances where a scanned image of a
floor plan was loaded for reference when modeling, but not removed once the
associated elements were created.

Document Set Quality

Since these items look at consistency
between models, they are the same for all
our discipline files. The “suggested”
workflow here is to actually have all three
models open in different instances of
Revit to expedite the comparison.
 Grid, reference plane, or level
objects assigned to proper
workset – This sounds very similar
to the check performed in the Figure 4- Document Set Quality Health Check Items

“Model Performance” group;

however, this is the one time we “fix” something through this process. This item
actually reports if any of the object types mentioned were moved to the desired
worksets based on our standards. We chose to act on this information because of
preset view templates in our startup files that are dependent on these elements
being assigned to specific worksets.
 Consistent Phase naming – While inconsistency in phase naming between
projects is not a technical issue, it can lead to confusion on the design team and lost
time during production. This is also a good time to check that phases are not being
used differently in project models which could result in phase mapping display
issues.
 Consistent Design Options naming – Like the phase naming, this is more about
limiting the chances of confusion on the design team that could result in incorrect
view graphics.

Page 6
  Consistent primary level name and datum – This check is meant to verify that the
various disciplines are presenting the same information in their drawings to avoid
confusion in communications by contractors in the field.
 There are Copy/Monitor model coordination warnings – While we do not see the
copy monitor functionality used often in our projects, we do find that when it is used,
the warnings are typically ignored.
 % of Reference Planes not Hosting – This item came about with certain
individuals wanting to use reference planes as visual guides to layout building
façade patterns. They use reference planes because they do not print, but do not
assign dimensions for layout control or host objects to the planes. Since reference
planes get displayed in most views, they can be very intrusive to people who do not
need to see or reference them.
With our 2017 implementation we are planning to create reference plane
subcategories that might help address this and allow for better visibility control than
our current workset process.

Discipline Specific Considerations

As the heading implies, these are items we check specific to the different discipline models.
In discussions with our BIM Coordinators, we narrowed the list of “it would be great to
know…” to three architectural and four MEP items. We realized the few things the structural
group requested were not things we could check through an automated system at this time.

The architecture items include:

 Room Area Report – This item
reports the number of room
objects in the model with an area
of five square feet or less. It also
includes rooms not placed in the Figure 5 - Architecture Specific Health Check Items
model.
 Use of “Generic” wall types – A ratio of the number of walls with the word
“Generic” in their names compared to the overall number of walls in the model. This
is one of those things that is probably fine during early layout phases of a project,
but when a design team is approaching a deadline we would prefer they are using
our standard wall system wall types.
 Walls over 6’-0” have top constraints assigned – We use this to get an idea of
how responsive the model would be to changes in the vertical. We would prefer that
walls are tied to some level so if level-to-level dimensions change the walls adjust
accordingly. We recognize designs often incorporate partial height walls as spatial

Page 7
 bounding elements so we chose to ignore walls with an unconstrained height of six
feet or less.

We look at these MEP specific items:

 Duct Systems Connectivity – We
strongly encourage our engineering
designers to make sure there is
connectivity throughout the systems they
are modeling in order to leverage the Figure 6 - MEP Specific Health Check Items
analysis tools available within Revit. We
recognize those analytical tools may not be perfect, but they can be leveraged to
give us a general idea of how the overall assembly is working related to individual
components.
 Piping Systems Connectivity – See Duct Systems Connectivity. In addition, the
piping systems check can start to identify model elements that have not been
connected to systems and possibly prevent omissions in our documents
 Electrical Circuit Connectivity – Similar to the piping systems, we use the
electrical connectivity check to identify whether or not all the model elements with
connection capability have been accounted for in the overall system design.
 Room tags used in place of spaces and space tags – This item is based on our
desire to make sure the MEP designers are setting up our models for true BIM uses
and not just to get a set of drawings out the door. Spaces are necessary
components when design analysis is going to be used whether that is energy
modeling or lighting analysis.

Collecting Model Health Information

I have mentioned several times we wanted to automate the collection and reporting of the
model health information as much as we could. The goals for automation were to:
1. Reduce the amount of time spent checking each file
2. Make the check process consistent from instance to instance
3. Remove any subjectivity so the checkers weren’t perceived as “picking” on the
model developers

After much discussion we settled on using Dynamo as our data gathering tool. We felt it
offered us flexibility in what data we gathered while not requiring our reviewers to sift
through other information we were not necessarily interested in as part of the Health
Check. The other huge benefit was it allowed the gathered data to be pushed, in a
controlled manner, into an Excel document we wanted to use for reporting. This allowed us

Page 8
to pre-bake evaluation criteria and commentary that would further remove the BIM
Coordinators from possible allegations of favoritism.

Manual Data Entry

There is some information we simply cannot retrieve using the Revit API or requires
comparison between multiple files and thus necessitating human review. The following
items are input by the individuals running the Health Check. In all of these cases we have
limited the responses available to the checker to “Yes”, “No”, and sometimes “N/A”. I have
included the “Instructions” that exist in the reporting Excel file for each item.
 Warnings – BIM Coordinator to open file and review # of Warnings in Manage
ribbon and enter the highest warning number in cell B10. Because warnings are
“live” conditions that can change with any single command, Revit does not store
them in an accessible location and they cannot be reported via the API.
 Non-standard worksets exist in file – BIM Coordinator to open the "Worksets"
dialog box. If worksets other than the Shive-Hattery standards are in the file, then
specify "Yes" in cell B16. Discuss with project team, and make notes in cell E16; a
few different worksets are fine. Too many extra worksets can lead to confusion and
project performance issues. We can report worksets; in fact, we have another line
that reports changes made to the file associated with them. However, we recognize
teams may need to separate model elements based on any number of factors. We
elected to make this a manual check to give the team the opportunity to explain why
they may have added worksets and document those reasons.
 Objects assigned to proper worksets – BIM Coordinator to open "+Design
Validation Views" --> “Workset Check” view and turn on "Worksharing Display:
Worksets". Review objects to validate if they are on the correct worksets. Select
"Yes" or "No" in cell B17 based on what you find. While we could run a report based
on the standard worksets, since we allowed for teams to have custom worksets, it is
almost impossible to check for proper element assignment to worksets through an
automated process.
 Consistent Phase naming – BIM Coordinator to review phases (Manage ribbon -->
Phases --> Project Phases tab) in all models and denote in cell B21 if differences
exist between project models. If differences, talk to team and make notes in cell E21
if they are to stay and why. If staying, check phase mapping of linked files. This is
the first of the multi-file consistency items we ask the checkers to complete. The
recommendation in our process documentation is that they actually have multiple
instances of Revit open simultaneously, one for each file. This way they can open
the appropriate dialog boxes for the phase settings and quickly see if there are
discrepencies.
Page 9
  Consistent Design Options naming – BIM Coordinator to review Design Options
(if exist) for consistency in naming between all project model files. Denote results in
cell B22. Select "N/A" if design options are not used on the project. It is acceptable
for one file to have design options when others do not.
 Consistent primary level name and datum – BIM Coordinator to review primary
level names and datum elevations for consistency across all project model files.
Denote results in cell B23.
 There are Copy/Monitor model coordination warnings – Denote in cell B24
whether or not "Coordination Review" notifications are displayed when file is
opened. This is one of those items people see every day and most users pass right
by as their file loads. We wanted to take this opportunity to remind them that at some
point, someone thought it was important to track the relationship between two
objects and something has changed.
 Duct Systems Connectivity – BIM Coordinator to open file and review "Check Duct
Systems" found in the Analyze tab and specify either yes if there are no issues, or
no if there are connectivity issues from the dropdown menu in B26. Similar to
warnings, the Connectivity checks are live analysis functions and are not accessible
via the Revit API.
 Piping Systems Connectivity – BIM Coordinator to open file and review "Check
Pipe Systems" found in the Analyze tab and specify either yes if there are no issues,
or no if there are connectivity issues from the dropdown menu in B27.
 Electrical Circuit Connectivity – BIM Coordinator to open file and review "Check
Circuits" found in the Analyze tab and specify either yes if there are no issues, or no
if there are circuit issues from the dropdown menu in B28.

Automating Data Entry

Everything else in our reports has the information collected via automated scripts. The
examples shown in this handout were all developed with Dynamo version 0.9.2. We
continue to refine the scripts as newer versions of Revit and Dynamo become available. As
I think is true with most Dynamo development, we rely on public packages. Updating the
scripts for new versions also requires associated updates to the packages. At this time, we
are using Dynamo 1.2.0 and have not had to make substantive changes to the scripts. In
these scripts we use nodes from the following packages:
1. archi-lab.net (2016.2.10)
2. Blackbox (2016.3.28)
3. BumbleBee (2016.4.20)
4. Clockwork for Dynamo 0.9.x (0.90.7)
5. Rhythm (2016.4.4)

Page 10
 6. spring nodes (82.7.8)
7. SteamNodes (0.8.42)

The following segment of script is used repeatedly in our Health Check routines as the
mechanism we use to push data harvested from the Revit model into our Excel file. In the
snippet we provide the following information to the main node, Excel.WriteToFile:
 filePath – Fed from the File Path node, our users click the “Browse…” button and
select the report file saved to their project on the server.
 sheetName – We use a code block node to explicitly supply the name of the
worksheet (tab) within the reporting spreadsheet file.
 startRow – Another code block here supplies the explicit row assignment we wish
the data to populate. One note, the 0 (zero) here translates to Row 1 in the Excel
file.
 startCol – A third code block specifies the column where the data will go. Like the
row item, a “0” translated to column “A”. That means the “7” in the image equates to
the eighth column or “H” in the Excel file.
 data – Other Dynamo snippets collect information that is pushed into the specified
Excel worksheet cell. If the data source is a list, the information will fill the column
with the first entry going into the row specified.
 overWrite – We do not use this particular function. While we clear the data through
another method, we chose not to overwrite the data because we discovered if the
first list is longer than the second, this node only overwrites the data rows matching
the length of the second list. This was leading to false results in some of our
reporting functions.

Figure 7 - Basic Excel Export Nodes

I mentioned we use a different method to clear the data as successive Health Check
reports are generated. The BumbleBee package also has nodes that allow it to interface

Page 11
with Excel. We use the Clear Contents node. An important point to remember with this
particular node is that it requires the Excel file to be closed when it is executed.
 FilePath – The location and name of the Excel file to be modified.
 RunIt – This input can be used to determine whether or not data should be cleared
from the file. For our purposes, we always want the data cleared so we force a
Boolean “True”.
 SheetName – The name of the worksheet (tab) within the Excel file to be modified.
 ClearContent – The input is asking whether or not the data in the specified
worksheet should be removed. Since that is what we want to do, we pass a Boolean
value of “True”.
 ClearFormat – This input allows us to change the formatting of the Excel file. For
our application, we do not do any special formatting via the script so to save time we
pass a Boolean value of “False” to the node.
 CellRange – Here we are able to pass a value specifying what cells in Excel should
be cleared. While we do not always know the size of a list that may be passed into
Excel, by clearing out a huge cell range, we feel confident we won’t get left-over
data. Unlike the node where we are writing data, here we specify actual cell values
in Excel. You’ll note we start clearing in row 2; this way our headers stay in place
and we do not have to recreate them in our Dynamo export process.

Figure 8 - Script to Clear Previous Reporting Results

I should also point out in the actual script, we feed as many of the repetitive inputs for our
Excel files from single sources as possible. That is to say the “File Path” and “Sheet Name”
elements feed the Clear Content and multiple write nodes instead of having these input
elements repeated. In truth, specifying the Excel file path in a single node is the only
interaction our BIM Coordinators have with the script before it is ready to run.

Page 12
Mining the Model for Data
Now that you know how we put the information into an Excel file, it’s time to look at getting
the information we want from our models. I’m not going to include all of the checked items
in the handout as that would turn it into a novella instead of a short story. A dataset with
the referenced files will be made available with the other class materials. We will look at
two of the script segments that are representative of how we collect the data for our reports
and one where we modify model content.

Counting Images
We will start by looking at one of the simpler code snippets which reports the number of
images in the model. The nodes are pretty straight forward. We simply get a list of all the
model elements of type “ImageType”, add a header to a list, and then send it out to Excel
from the transpose node. The list only contains two items, the header and the number of
images.

Figure 9 - Image Count Snippet

Views Not On Sheets

The second code snippet we are going to look at evaluates and reports the number of
views which are not on sheets. The graphic below shows the node string that starts with
the collection of items from the Revit model and then filtering various views out of the list
based on specific criteria.

Figure 10 - Views on Sheets Code Snippet (You shouldn’t be able to read it here…)

Page 13
To start any report, you have to have information. We look at our Revit models and collect
all kinds of information about the different types of elevations, plans, sheets, schedules,
etc. This is done in a custom node created by one of our staff that simply takes a lot of the
element specific selection nodes and combines them so we have a single output block we
use to create lists. From this node we pull the specific types of views we expect to be on
drawing sheets.

The first filter we run the list through is for views that we, as a firm, create which we do not
expect to be placed on sheets. These views are things like our export views for clash
detection or drafting views which have lineweight standards. We use a parameter named
“View Category” to organize our views in projects and we don’t feel it is fair to the modeling
staff to report on these views.

Figure 11- View List Creation and Category Filter

The next step in the process is to take the sheets in the Revit model and generate a list of
the views they contain. This is then compared to the list of views from the first filter set and
any duplicates are removed leaving us with a list of views that are not on sheets.

Figure 12 - Collecting List of Views on Sheets and Removing from List

Page 14
The last bit of this code block organizes the list of views and their view categories for
reporting in the Excel file. Again, the “Lists” output on the transpose node would feed to the
write to Excel node discussed previously.

Figure 13 - List Organization for Export to Excel

The logic illustrated here of generating a list and comparing it to other lists, either generic
text based or model specific, is similar for many of the items we report. The Health Check
lines for schedules, items on correct worksets, and non-hosting worksets all use logic
similar to what is used with the views.

Updating Deadline Thermometer

The third, and last, snippet we will discuss
in the handout is really not part of the
reporting process, but something we
update when the script is run. As part of
our starting view we have a thermometer
Figure 14 - Deadline Thermometer
that is intended to convey the progress of
the current project phase. This is something we picked up from another 2015 conference
presentation by John Pierson of Dekker/Perich/Sabatini (the developer of the Rhythm
package for Dynamo). The family has three parameters for day, month, and year for each
of three different dates: phase start, phase deadline, and “today”. The start and deadline
parameters are mapped to global parameters, but the current date properties are just
instance parameters that need to be updated manually. We haven’t been able to get them
to automatically read the system information (yet). What we do know how to do is have the
system date parsed in a Dynamo script to update the three different parameters.

In this snippet, we start by specifying the family we want to modify. We then have to find
the instance of this family and select it. In the meantime, we get the system time using the
DateTime.Now node and process it through the DateTime.Components node to get the
unique year, month, and day values. The last set of nodes simply take the parsed date
values and push them into the specific parameters of the family.

Page 15
Figure 15 - Deadline Thermometer Update

Presenting Model Health to Project Teams

When we first started talking about informing teams of what we had identified during the
Health Check, there was a fair amount of discussion about what people would actually take
the time to review. Ultimately, we agreed there was not a single method we felt had a high
hit rate. That’s why we decided to use the repetition of information we see on Sesame
Street as a communication guide. We reasoned “If it works for toddlers, it should work for
Revit users.”

How Frequently Should Health Checks Occur

Whenever the word repetition comes up, the question of frequency must be addressed. We
didn’t think the medical insurance industry’s “once a year” standard was probably a good
guide for checking our project models. After a fair amount of conversation, we settled on
the base recommendation of each model should be reviewed once every two weeks. Since
the goal is to be proactive, not reactive, we felt it was important to have the Health Checks
done frequent enough that project teams could respond to identified issues in the timeline
of the design/documentation process.

Of course we acknowledge there are many reasons why the two-week cycle should be a
guideline. As part of the planning process of our projects we encourage our BIM
Coordinators to discuss the timing of Health Checks with the project team. Other
considerations that may impact how often the Health Check occurs include:
1. Small Project Size – Smaller projects with short schedules may only have one or
two opportunities for the Health Check to be run. Some really small projects may not
have the check run at all. We prefer the Health Check be run at least once per
Page 16
 phase on projects to help identify problematic habits team members may be
developing.
2. Project Phase – A question came up about whether or not all the design phases
warranted the same amount of attention. Is it worth doing Health Checks on models
in very early stages of design? Since we ask project teams to stay out of the models
as the Health Check is occurring, should we avoid checks close to deadlines? It is
our general stance that there are different aspects of the check applicable at all
phases of a project so it should be run whenever modeling activities are occurring.
3. Project Status – If the project is on hold, or in an extended review period, the
frequency of reviews should probably drop off. Even on larger projects where our
teams get “distracted” catching up on other projects after major deliverables, there is
probably not a reason to do multiple checks. The guideline we encourage people to
use is “if people are working on the file, it should be checked.” We do promote at
least one check be done right after deliverables or while a project is on hold so when
the team starts to ramp back up, they have information about the condition of the
files.

Recommendations for Action

Once the data has been collected and pushed into the “data” tabs in Excel, we need to
provide some sort of recommendation to the project teams. We decided to preset the
evaluation of the various items in order to support the idea that the Health Check is an
objective review of the model and the teams developing them.

We elected to establish three levels of evaluation. We use Good to indicate the results are
in an acceptable, normal level. Caution is the term we settled on for a mid-level result. We
chose Needs Attention in lieu of “bad” or “wrong” when the results could lead to problems
with the file.

Some reports we’ve seen made use of the conditional formatting symbology Excel has to
provide feedback. Because we wanted to incorporate the results into Revit, we chose to
stay with text because Excel’s conditional formatting does not translate into Revit. We do
use conditional formatting for the colors making the Excel generated documents easier to
read.

Similar to conditional equations in Revit content, we made use of the powerful “if” statement
to evaluate each data item. We used the same “if” statements to provide feedback to the
design team. The following are the “if” statements associated with the % of Views not on
sheets line:

Page 17
Assessment column: =IF(B14<0.35,"Good", IF(B14>0.75, "Needs Attention","Caution"))

Comment/Impact column: =IF(B14<0.35,"Less than 35% of the views in the file are not on a
sheet; this is acceptable.", IF(B14>0.75, "Over 75% of the views in the file are not on
sheets. Excessive view counts can slow model performance. The team should review the
project to see if any views can be removed from the file.","Between 35% and 75% of the
views in the model are not on sheets. The project team should watch to make sure views
created for modeling in a specific area are deleted when no longer needed."))

Examples of the three possible responses are as follows:

Figure 16 - Examples of Evaluation Results

Sharing the Results

Earlier I referenced the Sesame Street model where you put the same information in front
of people repeatedly. We took that to heart when it came to providing the results of any
single Health Check review. We provide the information in two different methods.

The first is in the form of a PDF file generated directly from the Excel reporting tabs. The
worksheets are formatted so each of the three categories of information appear on their
own page. Since we run the report for each of three discipline files, we actually create three
PDF files so we can provide feedback to the disciplines on their own files without burdening
them with information on files where they do not work.

Page 18
 Figure 17 - PDF Report Example

The second way we present the results is by linking the report file directly into Revit. I
believe it is fairly common at this point for firms to have a specific view that loads by default
whenever the project is opened. For us that view is a sheet that has a unique titleblock
family which displays certain project information. We make use of a tool which allows us to
link the reporting Excel file into Revit as a schedule we then place on the starting view
sheet next to the project information.

Figure 18- Report Imported as Revit Schedule

Page 19
Summary
Habits are hard to break and the potentially negative impact they have on a system are
rarely noticed by those exhibiting them. It is not the goal of the Model Health Check
process to pick on the people working on our project files; the intent is to educate them on
the impacts their habits have on model file performance and the deliverable set of drawings
as a whole. Hopefully this will convince them to break their potentially harmful tendencies
and start developing project models that run as efficiently as possible.

A quote I hear frequently from my boss, who is all about Project Management, is “If you
measure something, you can improve it.” I’m not sure where he got that but Lord Kelvin
had a similar quote “If you cannot measure it, you cannot improve it.” I think the extension
of that concept to the Health Check process would be, “Your users cannot improve what
you do not measure and report.”

Page 20