Efficient Steel Design with Revit: Simplifying Stock Selection with Revit

LEAH ROYALTY: This is Efficient Steel Design with Revit, Simplifying Stock Selection Case Study. My name is Leah Royalty. I am an innovation strategist for Haskell. I have a master's of construction management from the University of Florida and a bachelor of design also from University of Florida.

My previous roles include BIM coordination at the university I was at. I helped manage some of their buildings that they owned for facilities management. I worked a little bit in virtual design construction, helping coordinate [INAUDIBLE] detections and laser scanning. And now, I currently work in the innovation department with Haskell. And I'll pass it over to you, Valentin.

VALENTIN NOVES: Thanks, Leah. I'm Valentin Noves. I'm the CEO at E-Verse. I have a master in business administration. I also have a bachelor of architecture from the University of Cordoba. And my previous roles involve being the BIM coordinator for Resorts World, which is the largest private construction in the US. And I was the CTO and founder of Architecture Gaming Assets company.

LEAH ROYALTY: So a high level overview here of what we'll cover in this case study. We'll go through the problem statement, how we determined what these problems were and what the disconnect was with our engineers in Haskell's steel shop. And then we'll talk about the proposed solution, so what we envisioned would solve the problems that we describe.

And moving to development with E-Verse, how they built us the solution with Revit and our current tools we use at Haskell. And then we'll end with our future vision, where we see this going, what our hopes are after the successful completion of the project, and then the big vision once we've met these goals.

So a little background on Haskell. We are a design-build construction company headquartered in Jacksonville, Florida. We have architecture, engineering, and construction among 20 offices in the US and also have presence in Latin America and the Asia-Pacific regions. We specialize in food and beverage manufacturing facilities but do a little bit of everything else.

And this here is the founder of Haskell, Mr. Preston Haskell. It's because of him we are such an innovative company today. He saw the importance of design-build delivery method early on as one of the fastest and highest quality delivery methods. And he had a huge role in starting the Design-Build Institute of America. Haskell is also known for being one of the first companies to implement tilt-up concrete panels for our clients, which we still do today.

And continuing on the importance of innovation at Haskell, in 2018 Haskell started a corporate venture capital arm, also known as the innovation group for the company, called Dysruptek. We invest in early stage startups in engineering and construction spaces.

And, usually, this is strategic for us. So we'll often pilot these companies on our projects, teach our teams how to use these new tools, get their feedback, and then decide if we want to roll the technology out enterprise-wide to the company, invest in the startup if they're looking to raise capital, or revisit later when they're more established.

We also do a little bit of research and development. And part of this effort includes an innovation contest that R&D projects come out of.

So this is the annual innovation contest that we call Big Pitch. It's basically like Shark Tank, if you've seen the show. We open it up to anyone in the company to submit ideas to improve their workflows at Haskell. And these ideas could be the expansion of a market or business all the way to a development of a new tool. And since starting this contest in 2020, we have developed six projects to improve current workflows at Haskell.

So we have everyone submit their idea through a platform called Bright Idea. And this lets everyone check out who submitted what and lets people like and comment on their favorite ideas. And these here are the different categories that they can submit under.

And it's important to narrow down what the idea is solving for. And this helps really narrow that down. Sometimes they'll start out when they submit their idea with a work-- it'll be a workflow enhancement. But after talking with the Dysruptek team, my team, it becomes a new business opportunity. So we'll work with them to grow their idea.

And my team meets with every single submitter to discuss their idea. And we'll determine who moves on to the review phase. And during review, we'll reach out to subject matter experts in the company and within our external network to determine if the idea is patentable, if something like this already exists, or if the idea should move on to be a finalist. And we narrow it down to about five ideas. And then, after that, we'll work with each team to create business plans and pitch decks.

And then, on Big Pitch Day, the teams will present to a panel of judges, two of them being execs that sit on the board at Haskell, and then the other two are external but still in the innovation space. And the same day of presentations, the judges will deliberate and choose a winner. The past few years, the judges have actually chosen two winners, which is how we've gotten up to six development projects so far.

And the first place winner gets $10,000 and funding for their idea, which makes submitting for the Big Pitch pretty enticing for the company. And we hold this event every fall. And then, the following year, my team will work closely with the winners to help bring their idea to life. Our winners from the last year-- they are shown on the right-- are two junior structural engineers who submitted the idea of Steel Harmony. And we worked with E-Verse to bring their idea to life. So what was their winning idea?

Haskell owns and operates a steel shop, called Haskell Steel. And we are a steel fabrication shop that's located also in Jacksonville, Florida. And there was over $1 million of unallocated steel sitting in our shop yard with no plan in place to sell this accumulation. So this might be from projects that no longer need it due to change orders or a change in design.

And our structural engineers noticed that this was a big missed opportunity. They could design using these members that were already brought in and on site at the steel shop. So if engineers had access to this information while they're designing, this could help lower project costs and then shorten overall project durations.

So the solution proposed for this problem was a Revit addin that would scan the Revit model and prepare two categorized reports of the steel sections. So the first report being possible unallocated inventory steel matches. So the criteria would be, as long as it's above the current design length, above two sizes in depth, plus or minus 30 pounds per linear foot. And then, the engineer would review any of these matches and reanalyze the number to see if the unallocated shape would work in replacement of the original piece.

And the second option for the reports would be a high-cost section with a recommendation for a replacement. So this would include any items with long lead times, uncommon shapes that are hard to reuse in the future if the project is terminated, or just if the piece is hard to fabricate. And the addin would provide the user with a recommended replacement so the engineer could analyze the piece, see if it's possible to replace the section. And this is where we began working with E-Verse to help us build this workflow.

VALENTIN NOVES: At E-Verse, we're a AC software consulting company. We're based in Miami, but we have more than 50 employees scattered all around the world. Most of our projects are in the United States, Europe, Latin America, and Australia. And our big differentiator is that we know the ins and outs of the industry, as we are just a group of architects, engineers, and nerds who code for the AC. Next one.

So when Haskell approached to us, they had a great idea. And we had to start working on how the architecture of the program would work. So we decided that we were going to split the architecture in three different parts. The first one was going to be the rapid adding, where the user was going to select all the different steel members and adjust that to match the ones that were going to be on the shop.

The second portion was going to be the web app, where the admin users from Haskell are going to be to approve all the different requests that comes from Revit, or they're going to be able to feed the web with the different uncommon elements that are out there in the market. And then, the third portion was going to be the database, which is a PowerFab.

So the Revit addin, we decided to also split it in three different parts. So the first functionality was going to be the matching functionality. The second was going to be the uncommon members. And the third one was going to be the logs of the tool.

So the first one, the matching functionality, is where the user opens the model. It gets scanned, and then it suggests either if there are elements there on the shop that can be used instead of the section selected there. So what the user does is, it selects each of the elements and then makes a request to Haskell or to the admin to get and use that specific piece of steel that it's lying on the shop.

The next one is the check for uncommon members in the model. This is where the model gets scanned, and then the user gets to know if they're using a section of a piece that it's uncommon, or it's expensive, or it's hard to get in the market. So they can be aware of, hey, this beam is going to be hard to get. Why you don't replace it for a different section that's much more easier to get, or that it's out there lying in the shop?

And the third one, the third piece, is the logs. Here, everything gets-- is the whole history that has been done in the model, if a section has been replaced because it is uncommon, or if a section has been replaced because we decided to take a piece of steel from the shop, everything is going to be able to-- you're going to be able to see it here in the history. And this is important because you're going to be able to see who did it and when did it and check if something was done wrong or right.

Then, another functionality that we introduced was that sometimes Haskell, they just do the design, but they don't do the build. So what we decided to do was that for each piece of steel that was selected from the shop, we added in parentheses an INV. So it means inventory. So anybody who gets the drawings know that that piece needs to come from the steel shop from Haskell.

And another feature that we are also adding is a note on each drawing like, hey, be aware that there are pieces on this drawing that needs to be taken from the inventory. You need to go to another supplier. Be aware that it's going to be taken from the shop of Haskell. Even if they are not in charge of the building process of these pieces, of this design, they can still-- anybody can still and use the pieces from their shop.

Then, on the web app, we also decided to divide it in three different sections. The first one was going to be the request section. The second was going to be the uncommon member section. And the third one was going to be the unallocated inventory section.

So in the request section, what an admin user can go and see is are all the requests that come from Revit. It doesn't matter the project. It doesn't matter the user. An admin could go there and see all the different requests and all the different properties of the requests, like when it was done, the user that did it, the section, and the piece of steel that they want to use from the shop. So an admin can either approve or reject the request from a Revit user.

The second section, the uncommon member section, these are all the type of sections there are, either expensive or hard to get. And this can be updated over time. From Haskell, they can even adjust it and remove a section, because now it's not uncommon anymore, or now it's not as expensive as it was 10 years ago, or they can add new sections that nowadays are hard to get on the market.

And then, the third section is just the view of the database that reflects all the different items that are there lying on the shop and that nobody is using. So just in case even when everything is automated, any Revit user can come in into the website and can check what's already there lying on the shop.

So now, we're going to give a video and a presentation of how the whole workflow works. So what first is happening here is, in Revit, this is the margin section. The model gets scanned, and then the user, it's highlighting all the different pieces that can be replaced for a piece on the shop. And, here, the user is selecting the one they like the most. And they're making a request to the admin that should be reflected on the web app.

So now, an admin user refreshes the request section on the web app, and it checks this new request from the Revit user and approves it. So now coming back to Revit, the Revit user updates the request section, and now you can see the request was approved.

So now, the same user checks the model. The section of the actual Revit piece was updated. And if he goes to the logs section, he can see that now it's part of the history that requests he did for a piece that was replaced from the shop.

And then, on the uncommon section, what the user is doing right now it's also scanning all the different pieces that are harder to get out there. So that's a suggestion from the tool that it's saying, hey, change this section of the steel piece. So the user now already changed that section. That gets automatically modified from the dimensions on the Revit family.

And then, the user can go into the logs and can also check that's part of the history of what was made on that specific model. And that's it. That's the brief presentation of how the flow works.

LEAH ROYALTY: So the next piece to this is where the inventory information is coming from. So our steel shop uses Tekla's PowerFab to manage all inventory-- that includes quantities and costs that's associated with each piece of steel. PowerFab also has a reservation functionality that lets users mark pieces as reserved for particular projects. And that's how we're using it at Haskell.

So we connected the inventory system with the web app as a gateway for the steel shop to approve these changes that were requested by the engineers. And with the current UI of PowerFab, as you just saw, we only have one person at Haskell that knows how to navigate and access it. It's not super intuitive to use. So how are our engineers supposed to know the most up-to-date steel pieces in inventory?

Our steel shop would export Excel spreadsheets monthly with the most up-to-date steel pieces and unallocated inventory and put that on the company's SharePoint. But the engineers rarely checked up on this spreadsheet, let alone tried to compare these pieces manually to what they already have in the Revit model.

So we decided a web application would solve that issue. And now, everyone can see the most up-to-date inventory coming from PowerFab, as well as the uncommon and costly members with their recommended replacements. And they can also check on the status of these pieces once the steel shop has accepted or denied their request to reserve a piece of steel for the project.

VALENTIN NOVES: So, typically, when a company explains about the process of developing a software, we always hear amazing stories on the results and how the process was marvelous, but that's far from the truth. Even if you have the best teams working on it, the best consulting firm, you're always going to encounter problems. So we wanted to highlight a couple of problems that we encountered on this specific project so, if you want to create your own tool, these kind of things doesn't happen to you as well.

LEAH ROYALTY: So we needed Haskell's IT department's help for two big items. We needed access to Tekla's PowerFab server to actually be able to read that inventory information. And we also needed to migrate Haskell's Azure Active Directory for single sign-on to the web app.

So our IT department has their own internal projects going on. And these integrations were put on pause during the original allocated time. So we instead used this time to test the addin in the web app and provided E-Verse with feedback to make the addin meet our needs.

So with PowerFab, that lived on a local server at Haskell, ant it was production only. So our IT department was able to create a backup server as a sandbox for E-Verse before getting the integration directly into the production server. And, in the meantime, we uploaded the latest Excel spreadsheet of the inventory from PowerFab for Revit to read to complete the matches. So although it wasn't live, it served as a good option that we could use even in the future if there's ever a connection down with PowerFab.

And then, the second portion for IT access was the Azure Active Directory migration. And that was important to us because it would give everyone at Haskell automatic access to the web app. And while we waited for IT to help us with this, we just used a password to access it, which worked well, but did keep everyone at one-layer access.

And, ideally, we'd want to give edit rights to the steel shops. They can go in and mark items as approved or denied. And then, we'd also-- we'd want the structural engineers to get in there just to be able to view the inventory.

And a few more items that we didn't think of at the beginning of the project. As we got further and further along with testing, where items came up that we needed to consider that we didn't originally. On the Revit side, one workflow issue was brought up regarding a change during design.

So the design is constantly changing. And if there's change due to design need, and there was a piece of steel from unallocated inventory already reserved for that original design, but it's no longer needed once those changes happen, how does the steel shop get notified of this? That steel piece no longer needs to be reserved for the project.

So one solution to minimize this was to only run the addin closer to 60% or even 90%. And there would need to be a way to have the addin recognize that the piece is no longer in the model so the steel shop knows they can release that piece of steel from reserved.

And this is something we're looking to completely solve for. We haven't had this issue come up yet. It's more of a what-if scenario, but we'll need to think it through moving forward.

And then, looking at the PowerFab integration, we did not automate the reservation process for the steel shop. So once the request is approved in the web app, the steel shop still has to go into PowerFab manually and put that piece on hold for the particular project. And as Steel Harmony, the addin, gets used more and more, this could be something we look to implement in the future to have this automation to reserve these pieces of steel.

But, ultimately, we wanted to leave it up to the steel shop if they wanted to prioritize that piece for another project. Maybe they have a bid that's not a Haskell project, or maybe they have a project that's already in construction and that would take priority. And that was another reason we didn't want to read and write into the PowerFab to begin with.

And another important mention is we also use PowerFab to track all of the costs on steel. So we wanted to be careful with automating something that could result in missing assets if we're automatically marking pieces as reserved.

VALENTIN NOVES: Now, all the problems Leah just mentioned were general problems we encountered. But we wanted to give our specific point of view from the E-Verse point of view. When companies work together, culture and ways of working and are different. So we wanted to give our unique comments or suggestions for future projects.

So from our point of view, what did work really well was defining a UX, UI, even before starting with the first line of code. This helped us all to be on the same page in terms of, hey, how is it going to look, and how it's going to behave? When I click on this button, what is going to happen? And the cost is so low to do that at the beginning but saves so much time on the rest of the project that it's really worth it.

Another recommendation is to involve all the stakeholders from the beginning, even when the table was really large and there was a lot of people on it. And when we started working on it, then we realized that, for example, we had to ask IT for credentials. And they were not at the table at the beginning.

So we had a really small delay of a couple of days waiting for them to give us access. But we could have just add them to the table from the beginning and avoid that. So just a suggestion, make sure you have all the stakeholders at the beginning.

Another important suggestion is to have a global plan for the project. This means being as detailed as possible. We all know that you have to be flexible and things might change. And this works exactly like a construction project. Nobody will finish on time, things will change, even if nobody likes to hear this.

But this is how things work because life is unpredictable and projects are unpredictable. So make sure you have a global plan and add as much detail as possible, but also be flexible to and expect changes.

And the last one is that implementation is always going to be more important than the development phase. Development phase is cool, it's fun, and it can sound complicated and fancy at the same time.

But the most important thing comes when you finish the development phase. How you're going to implement this? How you're going to train your final users? How you're going to develop a process to get feedback from those users to make sure they don't get frustrated with the tool? So that's the most important thing. And make sure you have a plan for that as well.

LEAH ROYALTY: And this is a couple more dilemmas that we-- or more like recommendations from Haskell's point of view. This is the engineer struggling. [LAUGHS]

So the idea was established, but we-- so we came with all the information that we had available up front. And we knew what we wanted it to do. But we had no idea what we wanted it to look like or how to build the backend of the solution.

So as we worked on the idea together with E-Verse, they proposed options for, first, the user interface of both the addin and the web app. And all we knew is it looked great, and it was functional, and it was better than what we had in mind. But once we started testing the solution, we learned how it worked with the end user. We quickly realized it wasn't the best way.

And as you probably saw in the previous video, we had originally window popups in Revit for the user interface. So these windows covered the 2D and 3D views of the steel members. And being able to actually see these pieces and investigate the current member before making that change using the plugin, that was important to us.

So we needed to be able to actually dock these windows to the side, something like the parameters window in Revit. And knowing that we needed this initially would have saved us a lot of time. But this wasn't something that we had even thought about when imagining what the addin would look like.

And then, also, this goes hand-in-hand with the last one, but just, communication is key. So when we were looking for a development company to help us build Steel Harmony, we created our request for proposal with guidelines very generic for what we wanted-- again, what we wanted the end result to be.

And, of course, because we wrote it, it was very clear in our mind that we were conveying what we were looking to get back from the project. And even getting the scope back from E-Verse initially, it had matched with everything that we wanted. But, again, once we actually started testing and realized that we needed something else, things changed, which is OK. But asking some of these questions up front would have eliminated this communication for sure.

So to recap, some of our problems that we had before implementing Steel Harmony, we had steel that's already been bought with no home. It's taking up prime real estate at the steel shop with no plan in place for these pieces. The engineers were disconnected with steel and inventory and unaware of expensive members. Haskell steel wasn't selected for all Haskell projects due to pricing during bidding.

And Haskell is a design-build construction company. If we're getting the design and construction for one project, which we do prefer, why wouldn't we also use our own steel shop? Being from the same entity, we should have open communication between our engineers and steel fabrication shops so we can get steel on our projects cheaper with less complications and higher accuracy versus going through a non-affiliate steel shop.

And then, our results after implementing and working with E-Verse. So we're slowly starting to deplete our unallocated inventory. And we now have a plan in place to start using these pieces in our projects instead of buying more steel. We're prioritizing the pieces we already have and ordering anything that we don't. And the stock will start to get smaller, making room for a real inventory system, which we'll discuss in the next couple of slides.

And then, the second one, engineers now have an idea of what pieces are expensive and what pieces are more common. So using the addin, the structural engineers will actually submit a less expensive design to be ordered and fabricated.

And then, because of this, there's-- we'll have no reason not to use Haskell Steel as our steel fabricator. We're making the most of having a local shop that's aiming toward the same goal. We want to build the best product for our clients, which includes remaining on schedule and having competitive pricing.

So next steps, where we see this going. So once our unallocated steel inventory has been depleted enough to create more room in our shop, we'd like to move to a general inventory approach. So we'll work on collecting data regarding what types of steel members we use over and over. This will come from Revit that we're using on our projects.

And we'll keep a constant supply of these members in the shop. And engineers will be able to actually request these pieces to use. And that will reserve them for a specific project. And as we design the projects in Revit, we'll use the addin to scan the model, collect the data regarding specific types of steel, and then we'll organize this based on project type. So once Haskell Steel can have a constant supply of these members, they're already bought and ready to be shipped to the job.

And looking into the future of this system, we see the idea bringing us one step closer to automating steel fabrication and distribution. So we envision a warehouse with each steel member pre-ordered and fabricated and placed in its correct location within the warehouse. So backing up a little to talk about this process, during design, engineers would select their pieces using Steel Harmony, the Revit addin, that are in stock for their design.

And once the design is completed, the drawings would get sent to estimating at the steel shop-- or this could also be pulled from Revit-- to determine what pieces are needed for the project. And then, these prefab pieces would get pulled from the specific area in the warehouse that are not yet assigned to a project and put in the correct location ready to get loaded onto a truck and shipped to the job.

And that is Steel Harmony. Thank you.