A good chunk of BIM Track’s power is based on properly filling out issue attributes; most of which can be customized per project in the project settings. We’re going to take a deep dive into issue attribute best practices for optimal BIM Track project and team management.
The most important thing to keep in mind while you are setting and assigning these issue parameters is that this is how you will filter issues for coordination reports, check your project is on track and more. Think of what you will need to sort these by and you will set up the right parameters 👍.
Here are each of the issue attributes (as shown in our web platform):
We’re going to start with the issues that are our most FAQs:
Assigned to is the person that needs to resolve the issue. In BIM Track, we allow users to add one individual’s name. This generates an email that gets sent to the user, albeit within their user notification parameters (weekly, daily, monthly). Only one person can be selected to avoid lack of accountability / lack of action / confusion.
Dev team scoop #1: We will soon be allowing multiple users to be assigned to an issue due to client demand.
Confidentiality controls who can see an issue. Much like your Facebook’s post settings, you can set who’ll see your posts. Oh but we actually respect your privacy 😉. If you’re not part of a team, you won’t see any issues that have this team assigned to it.
In confidentiality, you can grant access to one or multiple teams. If project creators want to see all issues, they should add themselves to all the teams.
**Please note this issue attribute was recently changed from Team Access to Confidentiality**
Notify is the BIM Track equivalent of cc’ing someone in an email. They will be notified of all changes. Teams or individuals who have access to the issue can be selected under the notify column.
How critical is it?
Priority is set according to impact on project. This table clarifies what we consider acceptable resolution timeframe; feel free to appropriate, fill out with your own resolution deadlines and distribute it internally (or in your BEP / BxP) so all teams are on the same page.
|Priority||Severity||Timeline for resolution|
|Critical||Puts the project at risk||Ideally in 1 day
(with meeting if req’d).
|High||Major impact on the feasibility||Ideally in 1 - 3 days.|
|Medium||Moderate impact||Ideally in 3 - 7 days.|
|Low||Weak impact||Ideally in 7 - 14 days.|
Due dates are by default set 7 days after the creation of the issue. The default length may be changed in project settings or assigned manually per issue to a given date for a specific deadline.
Where is it?
Zone is usually set according to the nature of the project in the project settings. Zones (or areas) will be used for filtering issues and creating detailed reports, so this is the main driver to figuring out how you want to configure zones.
Here are a few examples of how they can be used:
- In a high-rise multi residential building, the zone would typically be set by level.
- For a large campus project with multiple buildings on the same site, the zones may be set for individual building (zone A, B, C, D etc.).
- For an airport project with connected zones, you can split by area in the building ex: terminal gate A, B, C. Or an annex of all of them.
- Another option for further precision is to create names like BuildingA-Level1.
Phase is configured differently based on the scope of work or project phase you are involved with.
For example if you’re a designer and you’re working early in the project then your phases may be schematic design, design documentation, construction documentation, construction, and project handover. If you’re a GC or sub, you may only be involved in pre-construction and construction.
So it might make sense to split the phases by construction sequence. You may also align them by work package to follow up with specific work scope with the sub trades. You can set up custom phases in the project’s settings.
More helpful details
Discipline usually represents core disciplines such as architecture, structural, MEP, or sub-disciplines like fire protection, drainage, HVAC, plumbing, steel structure, concrete structure etc. Bear in mind, there is no link to issue access with this attribute. It is used primarily for metrics aka tracking team issue resolution so bear this in mind when setting it up. It is also the only attribute that allows the user to apply multiple fields.
**Please note this issue attribute was recently changed from Label to Discipline**
Group is a bit like a tag. This field is not predefined in BIM Track’s project settings. Usually our clients are adding the clash test name from Navisworks’ clash detective, or a coordination meeting name / date to create reports for meetings or a specific groups of issues.
Type is a field to provide additional information about the nature of an issue. Issues are not just clashes. They could be RFIs, comments, requests, clashes of course, questions, data validation, replacement requests, defects, financial matters, errors, or omissions. We have default values that can be changed, or added to, in the project settings. Why is this helpful? Again you can sort your reports and metrics by type, allowing you to focus on the issues you need to.
Dev team scoop #2: We have two new issue attributes in the pipeline: grids and levels.
If you’re looking for more help in setting up your project for success, please don’t hesitate to reach out to me.