Workflow Diagrams Can Improve Your Building Analysis

Who this is for: Architects or engineers who are trying to integrate building performance analysis into their firm’s processes, are getting started with BPA themselves, or are trying to improve project collaboration.

Takeaway: Using workflow diagrams to map-out thought processes and information exchange can save headaches and hang-ups, while improving the quality and rigor of your analysis.

By: Adam Menter

--------------

I work with students and educators to help them integrate sustainable design into their projects and teaching (see Autodesk Sustainability Workshop). When working with architecture students on building performance analysis, I became concerned that many students were not using the power of analysis to improve and optimize their designs.

As I’ve spoken with more professionals about it, they’ve echoed very similar concerns about their firm’s processes.

Rather than using analysis as an integrated and iterative part of their process, too many are simply using analysis tools to fulfill some project requirement. With today’s tools it’s easy to present impressive-looking analysis results and graphs without knowing if the results are valid, and what to do with them.

 

Simply knowing your goals and metrics goes a long way

The first step is going into the analysis process with a clear picture of what you’re trying to learn and what aspects of the design you’re trying optimize. That can help you understand what tools to use and what to look for in the analysis results. Just this can save a lot of time.

We began developing a series of workflow maps to help students structure how they approach analysis. If we could help make the process for using these tools well more explicit, maybe analysis results would improve – and maybe it’d be easier for people to take the plunge and adopt new tools and methods of working.

We began by creating workflow maps that follow this format to help people understand what tools to use, how to use those tools effectively, and what to look for in their analysis.

An example of a high-level map on Sun and Shadow Studies.

For a more in-depth explanation of this approach, see this article.  Some examples of these basic maps are here:

• Sun and Shadow Studies: Vasari/Revit, Ecotect
• Solar Radiation Analysis: Vasari, Ecotect
• Climate analysis
• Daylighting
• Wind Analysis in Vasari

The original inspiration from this work came from an Autodesk University Presentation by Asbjorn Levring and Daniel Nielsen in 2011. Their presentation can be seen here.

 

Mapping Design Process and Information Exchange

Along the way we began working with a research team at Stantec, Adam Rendek and Matt Grinberg, who were working to map-out and improve their own energy modeling workflows. Their goal is to improve collaboration and the effectiveness of their analysis, both within their firm and within the industry at large.

As Stantec built-out their map, they found that the thing that bogged them down the most is not the inadequacy of the tools or a convoluted process, but clarity on the basic information exchange that should happen. So they made the iconography of their workflow map richer to show the level of confidence of the information exchange – and what level of specificity/detail should be known.

 

Workflow icons show level of confidence and level of detail.

 

The resulting map tracks information flow and energy modeling throughout all phases of the design process. It is idealized and more involved than they’re able to do on most projects. But it is effective at establishing a common vocabulary that they hope will serve as a basis for many different types of projects.

Stantec’s Energy Modeling Workflow map tracks information flow and serves as a touchstone for teams to stay on the same page. This example is for just the pre-schematic phase.

Although Stantec is still in the initial phases of deploying this work internally, response seems to be strongly positive so far. It has been helpful in improving collaboration by creating a common vocabulary, and Adam & Matt hope to work closely with several project teams over the next year to put it into practice. They will also be speaking at several conferences, including the ASHRAE conference in Denver.

For more information on Stantec’s map, and to start using it on your own projects, see this blog post.

 

We hope to continue to develop this work to help architects and engineers approach analysis strategically and get the most out of their results.

Tell us what you think:

Have you tried similar processes in your workflow and how has it worked out for you? Are these approaches valid and valuable to your firm?

Would you like to see more of this kind of thinking baked into Autodesk products and documentation?

Comments

[Tomislav Zigo]

Workflow mapping, including value stream mapping is an exercise that requires significant investment in time and resources, especially for those organizations that are hesitant when it comes to committing to R&D. Providing a set of guidelines that can define a potential framework for a novice or even somewhat experienced user would have an enormous benefit from the adoption perspective as well as from the perspective of obtaining consistent simulation results. This is a really great way to start and the only word of caution is to be more process and less application biased.

Respectfully,

TZ

[Adam Menter]

Thanks for the feedback TZ! I agree with you - it has required a significant investment in time on Stantec's part for them to get as far as they have... and it will take more time to truly integrate it into their practice. I think we're all hoping that sharing this work will provide enough initial legwork for others to undertake similar processes with more confidence (and not have to "re-invent the wheel").

Regarding application vs. process based... I think, for Autodesk, it's a balance. The basic workflow maps described in the beginning of this post are application based, because they're focused on getting students to use our software more strategically. Stantec's map is very process based (doesn't mention applications/tools at all). Because we're a software company that makes the tools/applications, I think we're trying to be firmly grounded in both. We can't be so software-focused that we lose the bigger picture of customer needs/processes. But we have to pay attention to how the tools fit-in so we can: 1) help people use the tools better; 2) work to make the tools better.