In case you haven't started reading it, Phil Read formerly of Autodesk Consulting has joined HNTB Architecture and started started a Arch | Tech blog. His latest post is on the weakness of the current Revit Warnings system.

In case you haven't started reading it, Phil Read formerly of Autodesk Consulting has joined HNTB Architecture and started started a Arch | Tech blog. His latest post is on the weakness of the current Revit Warnings system.

I used to be one of those users that didn't concentrate too much on warnings, until I started working with Daniel Hurtubise. It took Daniel all of a half hour to show me the importance of addressing warnings immediately. Yes, I know that is not always possible, but it is a good practice. (If you are a non-believer, send Daniel an email and I am sure he will provide you with a demo).

Since then I have been working with Phil and Autodesk Consulting (and yes they still have some assume talent there) on addressing warnings. While we have been documenting many warnings to provide the user with greater insight on how to correct them, the ability to access and track warnings has been lacking.

When Phil joined HNTB, one of the topics I was hoping would be addressed is the issue of accessing and tracking warnings and during the recent AIA Large Firm Roundtable BIM Implementors meeting, Phil let one of the Revit Architecture product managers aware of his thoughts about how the warning system could be improved ad what would happen if this didn't get done. So, I thought I would include the text from his blog.

One final note, Autodesk is monitoring his blog, so if you have a comment to make about the warning system, by all means comment.

Dear Anthony,

The cultural challenge with Warnings in Revit is the present lack of accountability. Users are smart enough to know there's something amiss in the file. But they have no idea where to point (or give) the finger. Or fingers.

Warnings also provide some indication as to the learning and experience level of members on a team. Warnings indicate when users have decided to work in a way that is expedient rather than deliberate. Reviewing Warnings allow people to learn from their own mistakes. Or better yet - they allow people to learn from another team member's mistake. ;)

Unfortunately, many users and teams tend to put off reviewing / resolving Warnings as there's no sense of ownership. This makes project management really difficult. By the time you need to review warnings - it's often too late. And who should fix what?

So I'd propose the following stuff with regard to Warnings:

1. Warnings should be maintained in a regular Revit Schedule. Stop hiding them in a dialog at the bottom of a Tools Menu.

2. Project Managers would like to know the Workset Username responsible for generating the Warning. This would allow Warnings to be scheduled per user name - which would impose a sense of accountability in the Revit database.

3. Original date / time stamp helps the team track the frequency of Warnings against project development.

4. Like any other Schedule in Revit , the ability to jump from line item / to context of project location.

5. Some indication of severity (for ranking purposes). All warnings are not created equal.

6. Counts / Totals / Types of Warnings. Now the project manager knows who (typically) on a team is responsible for the bulk of Warnings so they can remedy the situation, and prevent its recurrence.

Overall, this added functionality compels team members to preemptively fix what they have broken. Project Managers can quickly get a sense project dynamics. And the rest of the team isn't penalized with one or two team member's lack of discipline.