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.
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.
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).
Collective BIM 