Computational Kickoffs 101

KAYLEIGH HOUDE: Welcome to computational kickoffs 101. A little bit about myself-- my name is Kayleigh Houde. I am the global computational community leader for Buro Happold Engineering.

So we do lots of different engineering-- so MEP, structures, city planning, lighting. You name it, we do it. We are a global company, and most of my personal experience with Buro Happold has been traveling around the world pre-COVID to teach engineers around the globe how to embed computation in their workflows. So this topic of kickoffs is very close to home for me.

I am one of the co-creators of the AIA award winning BOM LCA toolkit, so studying bi-carbon, which I actually gave a presentation at AU last year on that. I'm a mechanical PE, so you will hear a lot of MEP references throughout this. Apologies if you are an architect or structural engineer, but just imagine it in your scenario. I have spoken at AU seven times, and I'm a 13 year Revit user and an eight year Dynamo user, so big fan of Autodesk products.

So a bit of the description of what we'll be covering today in computational kickoffs 101-- we are not only asked to just have a BIM kick off now. We're asked to embed all of these different computational tools, and it can be so overwhelming for maybe yourself as the BIM manager or to the design team. And how do we take advantage of all of these different tools?

In this session, what we're going to be going through is how to set those targets per design stage, engaging management in those design decisions that will be made, including the deliverables that you actually need to produce, adding in feedback loops, and taking care of those prerequisites stumbling block steps that you need to run things like Dynamo scripts and also just setting those goals at an appropriate level so that the team can feel comfortable and that they're actually able to achieve them. So the learning objectives for today is to learn how to run a kick off at every design stage, discuss those goals setting strategies, identifying skill gaps and prerequisite steps for running scripts, and creating those QA feedback processes. So some words of advice-- at Buro Happold, we have what we call the top 10 golden rules that we like to abide by in computation, but they apply equally well to just projects in general.

So be organized. That is the number one piece of advice that I would give. Entropy only increases as a project goes on.

So please be as organized as possible from the very beginning. Know where your folders are. Let the team know where everything is stored so that everything is very clear moving forward.

Also ensuring resilience, not having single points of failure-- it's really easy to point to Susie in the corner and say, she's the one who runs all the scripts. However if she's sick or on PTO, you never know. So really just having skills shared over scripts where multiple people on the team know how to run things is always key. Breaking everything into workflows-- input, process, output.

I have yet to see any problem that can't be broken into that formula. So as often as you can, try to break everything down into that and get those thoughts down. Sketch out your workflows.

Enforcing modularity-- we've all seen those monster scripts. There's a big bowl of spaghetti there. Try not to do that. Try to have little pieces so that if one little piece breaks, you can revert to manual mode if necessary rather than having one giant thing that only one person knows how to run. Try to avoid that at all costs.

And co-create. Try to work in a way that others can participate. Be organized as you're writing out your script so that we know, oh, this group is working really well.

It's colored in purple. And this one's in green. And letting people know how you're working so that it's not just a big spaghetti mess is always very useful to the team. So

Before the kick off, things that you want to do before you even sit down with the design team-- establish the project timeline. I know this seems kind of trite to point out, but to know when you actually need to deliver things by is really relevant. So let's say your schematic design phase is happening in two weeks. Probably not going to be able to accomplish much computationally.

So maybe you're looking more toward the next phase of design there. So making sure you've got all of the stages of the project lined up, or maybe we're only delivering through DD. So we don't even need to worry about CDs. Very relevant to get that on the table first and foremost.

Next thing you'll want to do is sit down with the project leaders, the discipline leaders, and in some cases even the external teams and set those high level project goals. And I said computational in brackets there because you're looking at the big picture here, not the nitty gritty things that you're going to be doing. So first of all, what are the deliverables you have to achieve by the deadline? Do you need LOD200 drawings by a particular deadline, or are you just submitting a report? Really important that you kind of outline those per design stage.

Also, what are the client's goals? Are they really tech savvy do they want to be blown away by some fancy UI you produce? Important to know that as well.

Are they expecting really quick turnarounds? Are they expecting lots of options? That will help to set the stage for your kickoff.

And then to the design team or the leaders of the design, what hasn't gone well in the past? Where are you receiving lots of RFIs? If you could fix a workflow that your team always trips over, what would that be? Ask those types of questions to figure out what would be most valuable to the team if we were to automate it.

So now moving on to during the actual kick off meeting that you would be holding, so the first thing you want to do is kind of recap all of that information that you covered with the either external team or the project leadership, discipline leadership, to review the timeline, the high level goals from the client and from the design team, and the deliverables due at each stage. So what that might look like is setting out a timeline, letting people know high level, the basis of design report is what we're achieving at schematic design phase.

However, we might also be producing some color scheme plans in Revit, so some space data that you'd have to deal with. So your wheels are turning a little bit thinking about what you might do with that computationally. Maybe at DD, you're producing LOD 200 drawings.

So you're going to have a big package of drawings most likely, have the little LOD table. Always important to remember what that means in terms of LOD 200 specifically per system type. Maybe you want to have your energy loads completed-- again, I'm MEP, so I'm speaking from that point of view-- your plumbing pipes drawn and sized, electrical disconnects placed in mechanical equipment that's electrified, schedules, details, risers, all of those things.

And then maybe if this is for a CD phase, you're looking at refining all of those numbers or updating them. So again, you don't have to plan this out for the whole project, but try to think in terms of your current design stage or maybe one ahead even so that you know where you're looking. Usually, this LOD table's laid out well in advance with the external design team. So it really shouldn't be a big ask to get this out of the project management's hands.

The next thing you'll want to do, and this is with all of the discipline team members. If you can get them all in the same room, please extend the Teams or Skype invite to everyone to participate just because it's important that everyone be involved in the kick offs and know the context of the project before they're asked to execute things outside of that context. So understanding the team's competencies is so key.

So if you have a bunch of graduates working on your team who have never touched Revit, never touched Dynamo, it's going to be really hard to ask them to run this very complicated script over here or create your own. Probably not going to happen. So understanding who has which skills, how far you can push the team, understanding if they need some prerequisite training-- very, very important.

You want to make sure that everybody's on the same page in terms of who needs what. Sometimes people are a little shy about raising their hands. So I usually try to keep my finger on the pulse of where people are in general and just sit the team down to go through things, again, just as a refresher, make sure everybody's on the same page, and again just being realistic about what can be accomplished.

Identifying software that people are going to use on the project and where information is going to be exchanged-- so let's say for a particular project, we were planning to use Revit for documentation. We were planning to use IES for energy modeling and design master for electrical calculation. It's good to just get that on the table in terms of knowing where we have interoperability with different platforms or if someone says, oh no, I want to use a different-- I want to use task for the energy model. Good to know. Maybe that will change the strategy.

The preferred visual programming medium-- some people might be better in Dynamo or grasshopper. You never know. So good to ask where people are comfortable and what scripts they plan to use.

The frequency of model exchange and where you're going to do that-- good to know that things will be uploaded, downloaded, consumed through something like BIM 360. Also, again, which level of LOD are you planning to achieve at this particular juncture? Good to get that on the table.

Remind everyone what LOD 100, 200, 300, 350 look like. Sometimes you're contractually obligated to deliver 350, and the team's not mentally prepared for that. So always good to refresh.

Also, having a rough coordination strategy-- so again, MMAP, I'm always thinking about that ceiling sandwich. I like to get everyone around the table and just say, hey, don't run your pipes on the floor. Don't, you know, run your sloped gravity pipes at the very bottom so that they hit below the ceiling.

Just make sure everybody's thinking about that early on. Maybe draw some quick sections through the model and just say, here your zones, everyone. Please try to stick to them. Just get it out there as early as you can so that people are thinking in that regard as they're starting to model.

Also, really key to have follow up meetings and understanding that this is not just a one time thing. This is not just you sit down everybody talks about, oh, wouldn't it be cool if we automated these things? Then you walk away.

Everybody reverts to manual mode. See you again in three months. Let's hope that that's not the case.

So what we really want to do is have this kickoff meeting and then meet with the team-- I usually do every other week-- just to catch up, to go through coordination strategies, weird things I'm seeing in models, to go through where people are currently applying scripts, if they're struggling with anything, what's going really well. Good to get the whole design team on the same page about those things. So again, try to have those every other week and then also to have a lessons learned meeting after each design stage.

Maybe certain things went really well, other things went disastrously, but good to get everyone around the table just to say, hey, this was amazing. We should use this on every project. Even bring in outside teams to those lessons learned meetings. Share those skills. So again, those are the three types of meetings we should be having throughout the project.

Now into the meat here, establishing those workflows-- so understanding the opportunities for computation is where we really start to get to the computational part of this kick off. So for schematic design, let's say the goal was just to produce a BOD report and have some Revit color scheme plans in there. Easy enough. There's only one task under there.

So the traditional workflow-- and again, you can have people sketch these out. What would you do if you didn't have any special tools? Well, if you were looking for Revit-specific color scheme plans, you may be manually entering space type data into spaces to say this space is this many watts per square foot for lighting, and this office over here is this, and the cafeteria is this, and the bathrooms are this. And you would be manually entering those.

Well, I can think of a few ways that could be more efficient. So using any Excel add, and you can use Dynamo. You can use something like Rushworth tools, anything that would make it easier to translate large chunks of data because really, once you set up the space type, everything else should follow because things tend to follow that schema of a space type sets the rest of the lightning loads and the equipment loads and the regular small power. All of those things kind of fall in after that occupancy. So that's a great opportunity that you could seek out at schematic design.

In terms of identifying opportunities during design development, so we're looking for drawings at LOD 200 at this stage. This would probably include your energy loads being completed, your plumbing pipes drawn and sized, your electrical disconnects placed next to mechanical equipment, and then those schedules, details, and risers. What is the traditional version of that? Manually building those IES models. And it's time consuming and boring.

So we can see that there would be an opportunity there. The process that we have at is called model laundry. It's a process of taking the Revit model that was already built and just snip, snip, snapping it together so that it can be processed into IES very easily.

IES does not deal with non-orthogonal geometry very nicely. So that's a place where we've really honed in on that workflow. A good one for the energy team to take on because it's a lot of manual work normally.

Drawing those plumbing pipes-- if you draw them regularly and then just size them in a spreadsheet, don't put any connectors on them, they're dumb systems. What you can do is add little connectors at the ends of the systems and put the number of fixture units in them. Maybe count up the number of toilets in a room. Those are all labeled very nicely.

And then use something like Revit's pipe sizing tool, which is awesome. It's per international plumbing code, allows you to do velocity-based sizing. It's amazing.

A lot of people don't know about it. But something like that is a great opportunity. Placing disconnects where mechanical equipment appears-- sometimes people, I've seen them flipping through not even PDFs, real pages of paper saying, oh, there's a piece of mechanical equipment in this bathroom.

Oh, over here on my drawing, I'm going to draw a little disconnect switch. You need to go take that markup. I mean, that was a long time ago.

However, that's not the most efficient way of doing that. So I would say to take that up a notch, at least use a filter for viewing that electrified mechanical equipment. Maybe there's a special parameter to tick on and off from mechanical side. Use a script to place those disconnects next to it. Maybe you size it thereafter manually.

But I think that's definitely one of those areas where we tend to misplacing disconnects in certain spots. This would help that not to happen. At least you would see it in the background through the filter.

And then manually placing details, there are really quick ways to do that in Dynamo in terms of detail placement. It's just squares on a sheet. So very simple-- you just select the ones you want.

And then if we're looking at CDs, it's basically the effort of taking all those things you did at DD and doing a day two version of it. And that's where you want to harness those opportunities for computation because if I know I'm going to do this once, twice, several times, I want to make sure that I'm not redoing it manually every single one of those times. So if you know you're going to be doing something at DD and then at CD, definitely go through the process of thinking out that workflow, automating it as much as you can, and making sure the team takes those little improvements they make to the scripts and applies them later on.

So again, just tweaking that IES snapping script, tweaking that script to place the plumbing fixture unit connectors, and maybe just identifying those differences in the architectural model so you know where to look-- again, identifying the differences in the mechanical model-- where did they add, delete, modify equipment-- so that you know how to update it. So those ingredients that you're going to want to go through in each one of those workflows if you don't have a script created is what are the inputs. What information, documents, models-- where does that information sit?

Does it sit with the architect? Does it sit with the lighting consultant? Does it sit in a Revit model sitting somewhere?

You just need to know what those pieces are. That's manual or not, but always good to point those out. The process-- that's usually where you have that little scripted component set there.

But how are you going to get from the input to the output? Even if it was manual, write it down. Not everyone's heads are in the same spot. Outputs-- definitely for the deliverables, but what are you actually doing?

Are you placing something? Are you tagging something? What is the output?

And then always have an evaluation piece. What are you checking? Like, you have to have QA there even if it's a manual process where I just have a 3D view set up so that I can look at that. Make sure that that's in place in the model well ahead of time.

When in doubt, sketch it out. So we may assume that what's in my head is what's in your head when we think of a particular workflow. However it's usually not true.

So in the case of the plumbing fixtures, which is the second from the bottom in the yellow squares there, the architect owns those. And you should probably have a conversation with them about where those things are going to live in their model. Please don't put them under generic models. Put them under plumbing fixtures.

That's a conversation you need to have. So that's an input, making sure that you've got the right family in place to place that little connector there. That is an input as well.

And then the process that you would go through is the script to maybe place them. And then you would go through and actually use the connect into tool to connect them to the pipe and then use the pipe sizing tool. So sketching something like that out-- very, very useful.

You can do that in the form of [INAUDIBLE], sketches, a napkin. It does not matter. Just get everything out on the table.

Removing those stumbling blocks. So a lot of times, what will happen when something fails is I'll look back at it and say, what happened here? Why didn't we seize the opportunity to make things more efficient using computation?

A lot of times, it's, oh, the family wasn't working. So I gave up and reverted to manual mode because I was doing it three days before the deadline. I'm sure we've all heard that story before. So test those families. Make sure that they're are all working even if you just use it on the last project.

Every project is different. Clearly identify the inputs in your scripts. That is always key.

Make sure that people know what they need to tweak. Have a clear plan for your model splits, where stuff lives. That sounds ridiculous to say, but if people don't understand, we're splitting out all the different disciplines. So you need to have a different strategy for view templates-- something like that. Very key.

Also communicating with your collaborators-- we cannot forget to pick up the phone or call on teams or whatever, messaging people, emailing them, communicating about the inputs that you need. Really, really key.

The process portion-- make sure you test it. Make sure that it fits the project's requirements. Usually, it'll get you 80% of the way there and you need to tweak a little bit. But make sure your team has the skills to actually be able to make those updates.

Also making sure that your script reflects the manual process-- make sure it's not something completely foreign. I have some scripts that say, like, geometry magic on them. Probably just let the team know what it's doing is very useful for transparency's sake.

Outputs-- check those outputs have a view that reflects what the outputs are so that it can be checked. Don't eat an elephant. Maybe do it floor by floor or have a very clear 3D color-coded view so that you can check the outputs. But make sure that there's an evaluation procedure there as well.

And then I would say the most key thing is to assign people and deadlines to make it real. So if we just say, oh, I'm going to automate the whole process of placing electrical disconnects, it's not going to happen like that. You need to break it down into the chunks of what's required there.

Leave some extra time in case people do decide to revert to manual mode. So I've gone through the plumbing example ad nauseum here. So for the electrical one, talk to the mechanical engineers about the parameters they're using, the types of equipment they're using, their specs that you might need to look at to actually make sure that they copy down the right information into the parameters. Have a conversation. That is a very real part of a computational workflow is communicating with other humans.

Setting up the electrical template views-- that's something you need to do ahead of time. Testing your disconnect placement script, creating it in the first place, running that script, and then QAing the locations, with senior staff on the project. So that's one of those processes where you want to make sure that all of that happens. You leave a lot of time for QA at the end before your deadline.

And then post-kick off, be sure to have those regular catch up meetings. People fall off the wagon. It happens.

It's OK. But make sure you're identifying why that was happening. Maybe you need someone with a little more skill to come in on the project for a few hours to train everyone.

That's OK too. But just know why things aren't happening if they are or are not. Identifying and eliminating potential stumbling blocks, especially those training requirements, like I said before-- using lessons learned meetings to share with everyone on the project team and to share with outside team members because the next project, this will hopefully get easier and easier as those teams grow. And then cataloging all of your new workflows, all those scripts that you created-- I don't know if you have libraries at your company, but maybe create a script library where everything is nice in there.

You can update between versions. This works for Dynamo 2.0. This works for Dynamo 2.3.

Just being very clear about having those things available for re-use-- not like, oh, that SharePoint location doesn't work anymore because you move the folder around. No, keep it in a library. Keep it somewhere that other people can access it.

Again, just to recap what we went through-- establishing that timeline, setting the goals of the project team, identifying the skill gaps and software that you'll be using on the project, identifying those opportunities for efficiency, laying out those workflows, identifying the stumbling blocks, making it real with the deadlines, and those follow up meetings. So this is the kind of overall picture of a successful computational kick off meeting. Hopefully, all of you found this very useful. And thank you for joining. I'm looking forward to the QA with all of you.