With The Right Metadata, All Things Are Possible
What is metadata and it’s role in managing project information effectively? How can metadata reduce rework and litigation on projects? Join Joe Giegerich, CEO and founder of ProjectReady, and Shaili Modi-Oza, head of product development, as they discuss the importance of using metadata on a project. Metadata helps users categorize and classify project information. It can be used to manage project-level data as well as individual documents,. Proper metadata usage is essential for the Architecture, Engineering, and Construction (AEC) industry and project owners.
This conversation highlights the challenges of working with multiple systems and data silos in the AEC industry. The duo goes on to emphasize the need for a scalable taxonomy and consistent metadata as a means to connect and manage project information.
What You’ll Learn About Metadata On This Episode:
- The benefits of metadata, such as improved searchability, consistent classification, and reporting.
- How implementing a coherent metadata structure enables better project information management, reduces risk, and increases efficiency.
- What you’ll gain with a holistic view of projects across different systems and organizations.
We hope you enjoy and come back for future podcasts!
Sign Up For Updates!
If you liked what you heard on this episode of the ProjectReady podcast, you will love these additional resources:
How To Find Your AEC Files Faster
Project Documentation Creation: Automated, Accurate, Appealing Forms In Seconds
Contact Us Today For A Free Demonstration!
Transcript
Joe Giegerich:
So hi, everybody. Thank you for joining today’s podcast. The topic today is to discuss the importance of metadata within the AEC. Why is it important? What role does it play? And what value does it bring as it relates to managing a project and the information therein? So I’m Joe Giegerich. I’m the CEO and founder of Project Ready. And with me today is Shaili Modi Oza, who is the head of development, and as I refer to it, the mother of Project Ready. Now, the reason why we’re talking about metadata today is, metadata is just central and part and parcel with the secret sauce of our product, Project Ready. The way that we bind everything to reading a key, typically a project or facility ID, and achieve a scalable taxonomy so that you can get a better handle on the management of project information, and ultimately what that means in terms of your pocket. Less rework, less litigation.
Shaili, this is the general topic today, but let’s just start with this. What is metadata and why is it important for the AEC?
Shaili Modi Oza:
Sure. With metadata, I think we can start with, what role does metadata play? And we can refer to it as metadata. They are essentially properties or categories or tags, or things with which you can categorize different things. So we can have metadata… All the different aspects that are there as a part of a project would need metadata. There would be metadata at the project level down to the individual documents that would need metadata as well to basically categorize the items that would help us define what the different properties are for the project, for the documents, any activities that go on for the project. It just makes all of that data so much better when it’s categorized using all of these metadata properties. So I think at the highest level, it just makes the categorization and classification of the data much more manageable by tagging everything with metadata.
Joe:
So metadata is throughout our product. In fact, I would argue, Shaili, that the way Project Ready works is it starts with one unique piece of metadata… In our case, typically it’s the project ID… By which all these other categorizations can then get a nice tight hierarchy and roll up to it. So I just even taking a step back from all of this, it really is about project information management at the end of the day, and the only way you can manage information in the AEC is with metadata, because of the unique challenges. And those challenges are, you’re working in your system, other people’s systems, you’re consuming data and documents and information typically across the stack, from the M365 stack, SharePoint, to Procore, to Autodesk Cloud. So if you can just take it from that context, why should the industry care about metadata in that regard?
Shaili:
Going back to where Project Ready starts everything with our project ID-
Joe:
But even agnostic of Project Ready. Just on an industry level. And I’ll even add even one more thing to it. What we find is, before we come in, generally it’s glaringly absent, right? Because what are you doing about metadata on a spreadsheet you have siloed? What are you doing about documents that are just shoved into the out of the box library and SharePoint document folder inside ACC? Do you agree with that much at least, is that very commonly, metadata… And I guess more importantly, universal metadata. A way to connect that all together is pretty wanting once you go outside 1CDE.
Shaili:
Definitely. Yeah, all the different CDEs have their own set of properties and how the metadata is defined. So there is that separation as well in terms of the multiple CDEs at the project level where each CDE would have its own set of properties and metadata, and it’s hard to manage the documents. And in some cases, as you mentioned, Joe, they don’t even have that level of classification. The documents are just dropped into folder structures, be it in a single library in SharePoint or in just files, folder structures across ACC Procore. The only classification is that it’s in this folder, doesn’t have-
Joe:
Which is a poor man’s metadata, right?
Shaili:
That’s correct.
Joe:
But it’s not fungible. The industry is deceived with silos. Naming a folder just complicates that matter because there’s no way to scrape that data. There’s no way to put that into a relational database by which you can map and make sense. Fair?
Shaili:
That’s correct. And all of these CDEs, it doesn’t really help to search for a document based on the folder it is in. So that makes that really difficult to find and classify these documents as well, in the long run.
Joe:
We handle that through what we refer to folks as master metadata. So we have metadata, as Shaili was pointing out, on the project level itself, on the tasks and the deliverables, but also this layer of, as we again refer to it as master metadata, by which you have metadata that regardless of where that content sits, you can catalog it, you can get like, a document register, if you will, with a consistent set of metadata, be it that document exists in SharePoint or ACC or Procore or Box.
Shaili:
Yeah, that’s correct. So the metadata can be tagged at… Right from the project level, the metadata can be associated with the different work flows in this system as well. So if you’re doing an RFI, there can be metadata that is specific to the RFI, and for all of the document control workflows. At the document level, the metadata can be stored and it can be basically the source of truth kind of a thing, where it doesn’t matter where the data is going, the metadata stays consistent. And that can be defined at the project level, and the consistent metadata stays with the documents irrespective of where the document ends up in any CDE.
Joe:
And consistency in this case is not the hobgoblin of little minds. It’s the absolute only way that you can really start to piece together and ultimately manage project information. You have to find some consistency and some way to connect. Two things. One is, how do you approach metadata in all these systems, both within the context of our product and generally, I guess, as a methodology? And once you got that right, how does that facilitate decision making and reducing risk and rework? If you could talk to that.
Shaili:
Yeah. Specifically, I would start with when we begin the approach, and start defining what metadata makes sense for a business or an organization. We start with the use case, and the end result for all of the metadata and the properties is that we can have robust reporting and searching of the data that has been categorized. So it would be the best place to start on, what are the different properties that make sense for your business-
Joe:
That are important?
Shaili:
That are important, and which would help with the reporting and giving all of the valuable reporting aspects from that metadata, be it document registry with, what are all the different categories or properties with the documents or drawings irrespective of what CDE they live in? As end users, what are the different properties that makes sense? And that is where we generally start, and then basically start defining what the standards should be, what the different properties should be for the document. And then once the properties are defined at the project level, they just hierarchically flow through that.
If there’s a property at the project level, it can automatically just flow through for the document because that document lives in the project. So it just kind of makes sense, as we start defining and working with companies, to just ensure that we have that initial layer or initial set of metadata properties that make the most sense.
Joe:
Well, when it comes to trying to figure out what the right set of information is, the right meta values, it’s not pretty much any one person. I would argue the point and purpose of having a scalable taxonomy around metadata is that each discipline has their different acts to grind. It’s why you have so many silos. If you’re a designer and working in BIM 360, you have an absolutely distinct set of needs around that information that you’re working with and generating, versus somebody in Procore or PlanGrid.
So the fact that it takes dozens of disciplines and trades to create a built object is really what’s creating in large measure, or exacerbating the data silos, right? Because they all have their own bespoke purposes or specialties, just like the trades have specialties, just like design teams and build teams. So if you want to establish… At the beginning you’re trying to figure out, how are you going to build this coherent taxonomy? You really have to talk to or at least have subject matter experts in a variety of these roles that they may set in. Do you agree with that, Shaili?
Shaili:
Yeah, definitely. And that’s what makes it difficult for organizations to come up with that standard, or it’s a lot of different teams and a lot of different processes across a single organization. Taking that time and defining that metadata in the longer run makes it so much better in terms of the eventual end result of the project, and just managing that project becomes that much easier. And it could be that each department could have their own set of properties and metadata, and the way they’re using the metadata values could differ widely, but at the end it just all comes together for the project.
Joe:
And exponentially on a project, there’s your systems, your internal team, and it’s just extremely compounded by the fact that you now have to accommodate data from systems in other organizations’ systems. But the one thing I will say is that at the end of the day… And again, I like your opinion on this… The industry does have, however, a reasonable set of nomenclature and terms as a starting point. Even down to the pedestrian, that request for information, that workflow itself has some generalized standards as to how it’s managed. Same thing with submittals, et cetera.
Shaili:
Yeah, that’s right. That’s correct. They all have responses and status codes that need to be categorized properly, and it definitely has that in place.
Joe:
And to make it powerful enough to really manage that information, that’s where metadata comes in. So the workflow, we know what an RFI is, ball in court, all those terms sets, but bringing it together across those teams and systems is where metadata comes in. So that’s the devil in the details, but it’s the details that really drive home that ROI. But there is, at least I think, a generalized starting point within the industry. And I would argue that, and I’ve witnessed… This is something the industry on whole, I believe, is starting to try to move toward. Some, at least more, universal standards. And for us it’s the project ID or the facility ID.
And the way I always looked at it at the beginning of this whole process was, particularly if you’re an owner, it’s the facility. If you’re a vendor, the project ID is usually the PO. And so everybody, despite skills and passion for their profession, are looking to eat, have housing and all that good stuff. So by using that project ID or that facility ID, we always thought that. That’s what me and Zach were saying.
And to pick up on something that you had said as well, you mentioned search. And again, in our own case, with everything bound to that project ID and everything cascading, and then universality of descriptors across these CDEs, search becomes super powerful, and has a unique value given that you’re able to search for content across these different repositories as long as it flowed through the transaction regardless of where they live. And so that search of a horse of a different color, there’s a search of a different color where it’s not your traditional Google search or even a SharePoint search, it’s searching within the context of a transaction, beta submittal, an RFI. And then subsequently, the way we have this very scalable taxonomy lets us find direct links to those documents. And so that becomes part of the power of metadata.
But I would argue that one of the big challenges, again, that we think we can solve for is, how do you do that on scale? So you have this great mapping, you know what you want to describe, but how do you get that to scale? That really requires a fair bit of plumbing after the fact. It’s all about scalable taxonomy, and you can’t scale if you don’t have a coherent structure to all this.
So the other question is then, now that you have this, you mentioned search and the like, what other benefits are there of having a scalable hierarchal taxonomy as it relates to metadata? So we know it makes classification of data consistent, but how do you think that helps reduce risk?
Shaili:
Yeah, the classification and searching and reporting are definitely something that would be an ongoing thing. But in terms of just a day-to-day use case kind of feature, let’s say all the documents across multiple projects, the users need to have that information of a lot of different things going on. Who the document is assigned to, what are the different statuses that the documents are? And all of the custom metadata properties that we’ve talked about, the different classifications based on what region or facilities. Just some examples of different metadata properties that this can be tagged with. But I would think that the most powerful thing would be, just at a portfolio level across all the projects, you need something that is rolling up some sort of day-to-day view of everything that’s going on across projects, across CDEs. And having the metadata properties along with it would just give that full view or the full picture of what’s going on across the projects.
Right now, what we’ve been seeing is that all of these processes are very disconnected. There is an Excel that gets maintained separately where people are manually updating different statuses, and who is working on what? The documents themselves live somewhere else, and then the project and the project information is in a third place. So it makes that very hard to manage because all of that is siloed-
Joe:
Because it’s all siloed.
Shaili:
Yeah, all of that is siloed and it’s all separate, and it’s just very difficult to bring that all together. Just by having these metadata tags for projects and documents and different features, and just putting it all in one place makes that much more manageable, and it makes the day-to-day activities, I think much more efficient.
Joe:
And so efficiency is a big part of it. I’m all about ROI. There’s no part of technology that anybody will fund unless it’s improving their bottom line. And so that single source of truth, you need a single source of truth across all these different systems so you can make informed decisions. The reason why you want to make those informed decisions is to reduce risk. And that risk comes in two or three ways. Primarily is rework and litigation. So you have to make sure that this drawing is complete out of ACC, that the owner has in their SharePoint, that the people in the field using Procore or PlanGrid are all looking at that one version of the truth, that one specific document. And if they’re not… It’s kind of funny to me and ironic that the built world is about all connecting these different systems as it relates to a building, like HVAC and your exterior and your foundation. But within the industry’s ability to manage all the information that ultimately leads to that built world object, that’s all siloed.
And subsequently, those wrong plans can make a building collapse, or a bridge collapse. A story I always tell was at a Microsoft conference, years ago in Boston, and they just opened the tunnel and that collapsed, and it turned out there was this problem, there was that problem. But it all could have been solved if there was an easy way to get a coherent view of what’s going on, what was being built, was it being built to spec? And so you see these kinds of failures routinely on the basis of that inability to bring stuff together. So the purpose of metadata ultimately is to make sense of information that’s across phases and actors and all that other stuff, and drive your bottom line, which is the reduction of rework and litigation.
Shaili:
Yep, definitely agree.
Joe:
And Shaili, we have a lot of customers using the system. One of the clients that comes to mind is Takraf, manufacturer in Germany, heavy equipment, etcetera. But they use our document control suite, DCNext, very heavily. How does metadata come into play? How does metadata help them in that process? Because that’s an onerous thing. So how many document control packages are they issuing? How many documents? How does the use of metadata in the way we’ve implemented in DCNeXT within Project Ready, how does metadata help that client?
Shaili:
So in terms of… Yeah, definitely with Takraf, they are sending this huge volume of documents out with our document control suite, and we have metadata set for them with a whole lot of different workflows starting from registering the content, which comes in externally from vendors. So what this would do is whenever vendors are submitting documents, it forces them to add all of the different metadata properties and tag all the documents correctly.
And then that metadata along with the documents would flow through as the document gets reviewed and approved, and goes through the next pages in the project. And they have at least 25 different properties that are tagged with the documents. And all of this across projects helps them to create this master document registry of all the different documents in the different stages of approvals and review. And they can have this global view at a portfolio level across projects, of the status of all of these different documents. And because there are so many thousands of documents, all of these metadata properties that consistently have been kind of flowing through right from the initial stage where the documents come in from the vendors, to then it goes through an approval process. It just helps maintain that overall list, and it gives them a clear view to just see what’s going on at the portfolio level.
Joe:
So one of our features is the registration of content. I believe they use that feature as well. So the use case, my understanding is, they have a myriad of vendors working for them that have to submit… What are they, PDF drawings, primarily?
Shaili:
Yes, correct.
Joe:
So from the get go, with our master metadata and our document control suite, the vendor themselves will be corralled into using a consistent set of descriptors. I mean, we’ve seen this in a lot of clients where every vendor sends them a spreadsheet with some register with their own language design for twins. And so by pleasantly, if you will, forcing a standard on those outside vendors who are contributing to the project, right out of the gate, they’re able to make a lot more sense of all this documentation, these millions of records that they have to manage. And without that in a spreadsheet and a file system, you’re just doomed. Fair enough. I mean, how would you really know until something went desperately wrong?
Shaili:
Yeah, definitely. It was very manual before, and like you said, people send different metadata properties maintained in Excel files all over the place. Just very difficult to keep track of all of these documents. This gives a very good standard that this is the standard we are following, these are the metadata properties that these documents need to be set with, and then across different projects, different vendors, it creates that standard set of SOP, and that just increases efficiency at a great level.
Joe:
Oh yeah, that was the other thing I forgot to pick up on as well, is efficiency, right? So yes, there is rework and the risk of litigation. How long are you taking to brute force these processes? And again, the irony is that metadata is being used, but just not in a way that traverses different systems and stages and vendors, and all that other stuff. So everybody knows they have to describe these things even in the very old school and not good way of naming folders with these long paragraph names, 256 characters. That’s all attempts at metadata, but it’s not scalable. And at scale, at that point, what would have taken you a day probably takes you half an hour.
All right, well, we’ve taken up a lot of your time today, but I hope some of this was informative. Very passionate about the product, very passionate about efficiency. And metadata, from the beginning, is really where we’ve been focusing as we continue to develop and enhance and innovate in terms of what we do for the industry. So hope to have you back on the next podcast. I want to thank everybody for their time today, and you’ll hear from us the next time. Thank you.
Shaili:
Thank you.