Visualizing Building Coordination Data & Trends

Everyone produces a long data trail as part of their work. Emails, calendar appointments, building information models (BIMs), meeting minutes, and issue trackers. While we use this data in the moment, we rarely take the time to look back and learn from the data we produce. Knowing the pulse of active projects as they relate to other successfully completed projects is often only perceived and never tracked or measured.

For example, the general contractor who is tracking issues knows how long issues take to be resolved. You can correlate that with the subcontractors that were involved in those issues. This may highlight which subcontractor requires more time to coordinate than others. Using this data, you know to have the subcontractor start coordinating earlier with other subcontractors. The data could also reveal that although it took a subcontractor a considerable amount of time to be coordinated, the majority of the time may have involved another particular subcontractor. Investigating other sources of data could help diagnose this process issue as the two subcontractors do not work well together, or that one is just a sloppy modeler. Some of these things may be perceived through the weekly/monthly coordination meetings with the team, but how do you convey those trends to someone outside those meetings. How do you convey that insight to the client?

Measure Process, Not Just Outcomes

In the past three posts I’ve been focusing on why issue tracking is uncommon in the AEC industry, tools that attempt to track issues in the AEC, somemisunderstandings of what is needed for issue tracking, and how CASE deploys issue tracking on projects. When teams attempt to track issues on a project within traditional AEC applications, the time invested in tracking and understanding the coordination issues often outweighs the value obtained. Though each project is widely different, the ability to track performance and quality remain constant. It just requires a shift in thinking from focusing on outcomes to focusing on process. It is in the process where inefficiency can be found that directly affect the outcomes. It is in the process where you can inject the variables you need to measure. In Tyler Goss’s words:

But while every project may be superficially unique, they are nevertheless comprised of a series of highly-granular highly-repeatable processes – processes that can be measured, analyzed, and optimized across a wide range of projects. Processes that can be measured with very simple and generalizable rate variables – clashes resolved per man-hour, design elements created per day, and so forth – are foundational to true improvement. Ultimately, creating greater understanding of the internal nanoeconomies of design and construction has a huge value for our industry. By analyzing our processes rather than our outcomes, we can start the process of removing – empirically – the waste that is distributed and hidden within our informational systems and our projects.

Tyler Goss – Building Datum

It is no secret that we love Jira at CASE and deploy it on projects for BIM coordination. With Jira, we add any additional information we see valuable to track for each issue. For example, knowing what level, zone, and room an issue is associated with allows us to uncover what floors tend to cause the most trouble. What is it about those floors that caused a slip in the schedule? It also allows us measure the flow rate of the coordination team. If the team took 10 weeks to coordinate approx. 3,000 sqft of a particular room type, the team now has a benchmark to set for the next phase or project. When you cross reference the flow rate to the subcontractors that helped coordinate that room type, it may help you decide whether you should hire that subcontractor for the next job or not.

For best results, there needs to be an information manager that cares for the system. This is often the coordination lead, but can be someone else if necessary. That person meticulously manages the issue tracking platform in order to capture clean, accurate, and useful data. Jira by default allows you to create dashboards with charts of issue attributes across a single and multitude of projects. Examples of these charts can be seen below.


The charts are excellent for visualizing how issues are distributed across the project based on certain attributes like status, assignee, or priority. However, Jira charts do not allow you to investigate correlations between two seemingly disparate attributes. For that you can extract the data out of Jira and use Tableau! We do this with a tool, built by Matteo, that periodically extracts all the issue information via the REST API and stores the information into well structured SQL tables. These tables are then linked to Tableau. In Tableau, we are free to slice and dice the data how we want.

BIM Coordination Dashboards using Tableau

The majority of the charts below are very straight forward; however, a few are more complex. Matteo had to do insane magic to connect/sort the data correctly for the charts with complex relationships. The following are charts and assembled dashboards we use in our production at CASE.

Project-wide charts showing count of issues created, resolved, and remaining open. With this dashboard, you can see the impact of onboarding three different teams throughout the course of the project. The Open Issues chart is the best place to see this. In the beginning, it appears the first team did not aggressively resolve coordination issues, pushing the schedule. With closer investigation, it may be caused by the natural slowdown that occurs over the Christmas holidays. This slowdown is also reflected in the third team’s stats (the third hump in the Open Issues chart. The second team’s hill of open issues was a little more stable, as they were consistently resolving issues. Further investigation would be needed to determine if it is indeed the holidays, or if it is something more concerning.
These charts together help the coordination lead determine which subcontractor was the primary assignee when the project had numerous open issues. These conditions could be caused by a subcontractor not buying into the process, or that their scope of work is simply massive.
This dashboard of charts about a single subcontractor is super helpful. In one dashboard, you can see the number of issues a subcontractor was assigned to. The number of conversations they had to resolve those issues. The number of revised model uploads to resolve their issues. When time is added to the chart, you can determine when they were the most productive at resolving issues. By totaling the amount of square meters each issue encompasses, you can calculate their average flow rate each week. You can not only see a subcontractors willingness to engage, but also their participation, work effort, and scope of work.
This dashboard shows communication activity on issues that involved them. It also displays the top five subcontractors and the top 5 element types that their issues involved. With this infographic, the coordination lead can possibly determine what needs more attention next time. Should this subcontractor and the next 2-3 subcontractors that are most involved in their issues begin coordination earlier? Should certain building element types be modeled and coordinated more fully by the design team before the subcontractors take control of the model?
This project-wide chart shows running total of comments. It is meant to show overall team engagement and not a path forward. It is interesting to see that sometimes the designers’ communication dropped at points and how that may have an impact on resolution times.
This project-wide chart shows the sum of all the building element types that are involved in issues. It makes sense to see slabs, ducts, walls, and pipes in the largest circles. However, what is more interesting is the middle of the field. What was it about sanitary pipes, sprinkler pipes, lighting, ceilings, lifts, and curtain wall clips that caused so many issues. Should the Level Of Definition of those elements be reconsidered? Should the ownership and design of those elements be reconsidered?

Other Tableau Stuff

In addition to connecting to Jira, we have also used Tableau to visualize building information generated in Autodesk Revit. Check out Federico’s post on how to do that with CASE’s Exceler8 tool developed by RudderDon.

CASE has also delivered Tableau training to firms that are interested in visualizing data generated from both tables (Excel, ERP) and models (Revit, Rhino/Grasshopper).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s