SharePoint and the Importance of Taxonomy to Drive Better Search, Governance and Security for AEC Industries

Joe Giegerich: 

Hi, everybody. This is Joe Giegerich and Shaili Modi, and we’re here today on The ProjectReady Podcast.  

Today, we’re going to talk about SharePoint and the importance of taxonomy in the AEC industries.  

Basically, the long and short of this is we cut our teeth in SharePoint, it’s where our practice originally came from. Then, we came up with the integrated data environment, and managing the project ecosystem inclusive of Autodesk, Box, and Procore.  

But SharePoint is where we cut our teeth, and we know the product very well. That’s what we’re going to discuss today. We’re going to define a bit of what taxonomy is, what the advantages of it are, some of the challenges, et cetera.  

For one, and this really is, again, how we started out, everybody owns SharePoint.  

The number of firms you speak to, particularly in the AEC, who own it but really don’t know what to do with it, and that has to do with there are a lot of challenges around it.  

We see it deployed, not deployed. Frequently, we see SharePoint deployed where they have just one site, and tons of libraries and sub-folders. That is contrary to taxonomy.  

SharePoint is great for collaboration. Again, you own it. It’s cheaper storage than most of these other systems. Let’s face it, as I often say, your project isn’t a CDE. It’s your project and your CDEs of components of it, they’re just part of that project ecosystem. You’re going to have a lot of assets that really and rightfully belong in SharePoint. We’re going to discuss how to set that up, how to make best use of it and bring it together.  

Again, one of the reasons why you don’t see it readily used in the fashion that we do, or provide for our customers, where you have a SharePoint site dedicated to the project, along with ACC or Procore, et cetera. The reason why people don’t do that is there’s a lot of operational overhead.  

You have to manage security. You have to roll it out quickly for each and every individual project. You got to make sure that having more CDEs doesn’t add to more confusion and that is absolutely what we solve for. But when you get into that how do you own it in manage it, the taxonomy really does come into play.  

Let’s take a step back. Shaili, you’re the technical expert on the call. If you would define what taxonomy is? Obviously, I always weigh in. Then, talk about what SharePoint taxonomy involves.  

Shaili Modi-Oza: 

Just at a high level, basically just managing the content more effectively, in a hierarchal kind of a format, is the main definition of taxonomy. To just organize and structure the information properly.  

Specifically in terms of SharePoint, I guess what I would add is wherever people are using other systems, even file folders and Autodesk, Procore, Box, Dropbox, they all have a very different kind of a structure, where there are just folders. It’s one place where you put all the folders, and then there are sub, sub, sub folders.

Basically, that’s how I would say SharePoint is different, where if it is organized properly, it makes it much easier to manage content and take all the possible steps to make sure the project taxonomy is good.  

But I think that’s where everybody really struggles because it is different, people don’t really know how to set it up, what’s the best way to manage sites, and libraries, and all these things.  

I think that if set up properly, it is much more powerful than all these other systems where we just have files, and folders, and infinite number of sub-folders to just manage the data.  

Joe: 

Yeah, the industry is rife with that. I’ve never seen an industry that love nested folders as much as the AEC.  

Let’s face it, the way that folders are named, and files are named, they’re paragraphs, they’re not names of documents. That’s nothing fungible. You can’t scrape through and make sense of a long, concatenated sentence with underscores.  

I think one of the things you mentioned, file folders, that is part of the problem is that people are stuck in that mindset.  

“Well, I have file folders here, I’ll stick them over there.”  

But SharePoint is not a file system like a UNC path on a network. Libraries have very different rules and functions, and advantages, that are distinctly different than folders. Folders tend to be very static, you hope. Because the other thing I’ve seen is every project gets set up slightly different, that its own challenge. 

Just a little formality around it, Wikipedia, the conversation if you will. Taxonomy is the formal classification and system organizing terms in the hierarchy. Terms of names of libraries, names of folders, names of documents. One of the things about SharePoint is that you can manage that metadata in a way that you can now get a universal set of search descriptors and user experience. But again, this precludes that you have it set up in a repeatable fashion.  

Let’s take a step back and take a look at the benefits of having a solid taxonomy and bringing this in, particularly in the context of SharePoint. Which, to your point, Shaili, I absolutely agree. It is really the most robust CDE I know of, in terms of the ability to organize content.  

Shaili: 

There are a lot of great functionalities with SharePoint, definitely.  

We touched on libraries, so in terms of setting up different libraries is also something that a lot of our clients are not familiar with. SharePoint just comes with one default library, but then you have the ability to add more libraries and organize content in a way that makes sense. End users would basically get access to certain libraries, where they can easily work with the content that they only need access to.  

Just at the highest level, that makes a very good separation of content, where we can place content in different libraries. Then, there are a lot of great features in SharePoint around it. We would add content types to libraries. This way, the content is automatically tagged with the appropriate content type.  

Also, you touched on metadata, Joe.  

A lot of different libraries, we can set up metadata properties, which is equally important to then search data, or just organize data properly. We can have default metadata types by libraries, so if somebody just drops something in a legal folder, in our library in SharePoint, it automatically has all the properties that we want to set up along with it, as well as the content type.  

All these great functionalities help organize the documents really well.  

Joe: 

It goes further. This is the other thing that I’ve seen out there is not only do clients struggle with getting even the taxonomy correct, let alone the permissions. This is all stuff that we automate. But I’ll get comments back from our clients or their IT group, and they’re going, “Ah, but that’s a lot of documents we’re keeping up there now. I don’t want to pay for it.” Okay.  

SharePoint is part of your M365 stack, which includes things like records retention.  

If you have your taxonomy correct, meta descriptors correct, you can absolutely automate the long-term storage, obsolescence of. Not doing records retention, I’ve always scratched my head on because going, “We have everything …” I’ve heard this from clients, too. “We have everything from the last 30 years, ha ha.”  

So if you get sued and you now have material outside the statute of limitation, you have set yourself up to be hurt if, God forbid, any litigation occurs. It’s not exactly uncommon in the industry. Keeping everything because you lack the facility and the organization to programmatically obsolesce isn’t a point of pride, in my mind. It’s something that you really need to address and they’re not taking advantage of the rest of the stack. 

Get SharePoint right, get the taxonomy right. Now, we can obsolesce the data, we can put it into long-term storage.  

It certainly facilitates search.  

Then, you have things like e-Discovery, and all this other great tooling from Microsoft that has a dependency on some sort of consistent taxonomy and such.  

Although, I do want to add one last thing is that there are a number of features that Microsoft is releasing, slowly but surely, about the ability to auto-classify documents based upon pattern matches and the like. But even then, natural language translation isn’t going to just do it willy-nilly and perfectly. 

Shaili: 

Yeah. There’s that AI element to it, but again, it depends on the types of documents and what users are adding. So a combination of that with the metadata tagging we’ve been talking about is definitely, I think the best, best case scenario for sure.  

Joe: 

AI is fantastic, all that stuff. It’s not as new as people claim it is. It’s been around since the ’80s, machine learning, all that nine. But I just really will argue I don’t want to completely trust AI to make these decisions for me. The other thing that AI is not going to really do a very good job for you is fetching different sites and different group mailboxes, and the like, just based upon some sort of AI component. You really need some sort of real structure there.  

Another thing I would throw out there, as it relates to as your getting your taxonomy game in shape, just to throw it in there, is that it’s also an opportunity to start to take a look at what you’re doing in ACC and Procore.  

ACC and Procore have templates, and those templates will have file folder structures. Again, folders, it’s the Wild West. You set up the folder, everybody’s got rights underneath. But when you’re looking at your taxonomy for SharePoint, look at ACC, look at Procore. It’s not utterly necessary, but I think it’s an absolutely smart best practice, to try to get as much alignment there as well.  

Anything you would add to that, Shaili?  

Shaili: 

It takes some time at the beginning, as we’re setting up projects and ProjectReady with clients, to get that initial schema in place, but that consistency is definitely helpful long-term. We have a way we can sync documents.  

Just having that organized taxonomy even across systems because everything should be in context of the project. If things are organized differently in Procore, ACC, and SharePoint, it’s just all over the place.  

Having a consistency definitely is important there as well. 

Joe: 

Yeah. Why would you do that to your end user community?  

“Oh, in this system we call an apple an orange.”  

It really doesn’t help the day, it doesn’t your employees to work efficiently, that doesn’t help your bottom line.  

You mentioned sync, which is another one of the things that we do.  

We sync content between any of these systems, including Procore to Procore, to Autodesk to Autodesk, et cetera. If the names of the libraries and the folders align, you are making life easier, ultimately for your end users.  

Then there’s our own search, which is transactional. Do you see benefit in that across the board consistency, as it relates to our search?  

All right, so we talked about the benefits of SharePoint itself en masse, taxonomy, metadata.  

What are the challenges? Why are people not using SharePoint as much, if at all, on their projects in an effective fashion? That’s a question for you.  

Shaili: 

I think the main difference that we’ve been talking about is again, just getting SharePoint set up correctly.  

It looks and feels very different than other document management systems, where it’s just a single location where you keep files and folders. We’ve seen so many clients who are just new to SharePoint and not having the proper knowledge to set it up properly, I think that is the biggest barrier to get started with SharePoint. It does feel a bit overwhelming.  

There are so many things going on with a SharePoint site, if you look at documents, libraries, and metadata content types, and then think about permissions. For organizations that don’t have that kind of knowledge, I think it’s just a bit overwhelming to get started with it.  

Joe: 

Yeah. The great thing about SharePoint is my God, can it do a lot. Bad thing about SharePoint is my God, it can do a lot. And really, knowing where to start.  

Just working with customers, one of the things that you’ve put out there that’s been very successful is looking … For instance, one of the things you can do is group libraries.  

Grouping a library very nicely mimics folders and sub-folders. But to your point, if you don’t have a lot of experience with it, the learning curve can be pretty steep.  

Then, the other challenge around that is its consistency.  

Again, consistency is not a hobgoblin. It’s what you want.  

Then, the security therein. You can get very granular permissions within SharePoint. But if you have 100 projects and 100 sites, 1000 projects and 1000 sites, that is more than problematic.  

Now in our case, we automate all that. Based upon the role, we have these rights, users come and go. We make that very simple. The automated provisioning of SharePoint sites, with that consistent taxonomy, is also I think key to long-term success using the platform in the context of a project in conjunction with the other system. 

Shaili: 

Yeah, definitely. In the context of permissions, similar to what you added previously, that there are so many complicated and granular ways we can set permissions with SharePoint, which is both good and bad, because if you don’t do that programmatically, we’ve seen end users just start sharing files and folders, and that breaks the SharePoint permissioning.

That just makes it very difficult long-term to maintain, in terms of who has access to what, if it is not automated or done in a programmatic fashion, and users are just sharing documents and folders right from SharePoint, that that makes it very chaotic to manage those permissions long-term. 

Joe: 

Oh yeah, that is pretty much a governance nightmare.  

To further complicate things, within SharePoint, the share with function. Everybody’s very fond of it, unless you’re in infosec, and in IT, and in governance.  

You can shut it off for people outside your organization, makes share with not all that useful. If you allow people to share with outside your organization, you have the risk of the Wild West. 

There are three levels. Am I correct, Shaili? Have I got that one right? 

Shaili: 

Yeah, yeah. Based on permissions, yes. 

Joe: 

Yeah, that you set up in your tenant and the like. Again, if you can orchestrate the proper taxonomy on the libraries, the grouped libraries, and just have those permissions … If you don’t have rights to a library, you can’t do share with, correct?  

Shaili: 

Correct. Then, there are ways at the tenant level, that we can just set it that, even if users try to share a document, it will basically share a link, but it doesn’t mess with the permissions, only people who have access.  

It would still have the share with functionality where you can share out links with users, but the permissions are programmatically taken care of automatically, and only users who have access can click on the link and access it.  

Basically, instead of breaking permissions and giving end users that ability to manage all of that, that there’s a way at a tenant level to set that up, which most of our customers, we have it set up that way.  

Joe: 

Yeah. Taxonomy is central to governance. It’s really hard to have one without the other. How do you govern access to a taxonomy that varies, that is unregulated, and is different from project to project? Or again, reliant on folders, and sub-folders, and God help you. Yet another thing about taxonomy and its utter necessity. 

I’ll throw some statistics at you.  

80% of constructions businesses are classified as beginner or emerging levels of data capabilities. In the blog post that goes with this, we’ll have the links to this. The preponderance of data that is captured in construction and engineering goes unused.  

I’m going to put a hard 100 buck bet on this, that that is because they don’t know what it is. This goes into have a scalable data warehouse and data relationships, all of which keep circling back to taxonomy. Even if you are collecting all this information, if you don’t know what it is, you’re just going to be wasting it. 

I’m obsessed on organization, it’s just part of my personality. What really set me off in the last few years, I also own a music studio and the like, and I would find myself buying the same thing three times because I couldn’t find the one I already owned.  

I became very big on labeling everything, everything in boxes, my own taxonomy in my studio life. That applies here because you’re going to keep going and fetching more data, and then you’re going to look at the data and going, “Hm, which version was … We have it from three places now.”  

So that there’s also a risk of getting the information incorrect.  

Further, if you’re going to have all this information, that the value of that information and its analysis is also pinned to the ability for people to collaborate on it, to give more insight, more input as to the meaning of the information that you have. 

Finally, one of the things that really brought me to this point when we were doing our SharePoint services practice over the last couple decades, and people would set up FTP sites 20 years ago. Then whoopsie, this layer underneath has now exposed data from another client.  

There’s a lot of very necessary data security concerns around this information. And again, there’s no way to govern it if the taxonomy is all over the map.  

I’m going to turn to you, Shaili. Outside of procuring a project, which we heartily recommend, clearly, which really does solve for all of this. Agnostic of what we do, what’s some best practices and strategy you would offer to our listeners out there?  

Shaili: 

Not relying on the out-of-the-box documents library that comes with SharePoint.  

Basically, when we set up M365 with the group and a Teams team, it comes with a SharePoint site in the back end.  

The files area that is there in Microsoft Teams, in the back end that’s basically a SharePoint library, which is a documents library. We’ve seen so many clients who just end up using that. They start using the documents library, create all of their folders in the one location, and they don’t know that, in the back end, it’s a whole SharePoint site that they can use. Which is a full site, where you can add libraries and set it up.  

I think that is the number one recommendation.  

From Teams, we can go to SharePoint and it’s just that back end SharePoint, which is much more powerful than just using the one documents location to drop everything in. 

Then as we are setting up the project the first time and figure out what are the different libraries, the general recommendation is to see what’s the best way that the project documents need to be categorized, keeping in mind security as well. If there is finances related section, a legal section that needs to be separated, that we don’t want all the users to have access to, we recommend creating that as a separate library.

Just working through it, creating what are the different areas that we want security from it. We also touched on it before, that we can group the navigation in SharePoint as well, which is a great functionality to give that hierarchal structure as well. 

Joe: 

Yeah, it mimics folders.  

Shaili: 

That users are generally used to that. Okay, in this section we have three different libraries, which are grouped under the main library, so we can set it up that way as well.  

Joe: 

Yeah. The thing I would throw in there as well is sourcing metadata from line of business systems. When we automate the rollout of projects, typically most of our clients will pull that information from an ERP or a CRM.  

We learned that trick because when we were doing just basic SharePoint services in 2005, ’06, ’07, ’08, ’09, ’10, we had worked for some very large engineering departments. To make hay of things, it was not the biggest deal to pull in that information from a line of business system. That’s one that I would really throw out there, is authoritative metadata. Metadata that is sourced from the only system that counts, the one by which you invoice.  

I’m very big on the project ID and the ERP system, which at the end of the day, is where projects begin and end. You got to set it up, you got to bill against it, you got to get paid.  

But again, the sourcing externally of metadata, my God, the number of things you can do with it post, including then greater work around the Power Platform, and other areas of the M365 stack.  

Shaili: 

You brought up Power Platform, so that is something that that’s a great feature within SharePoint and M365 as well. There can be a number of customizations that we can do with forms around the documents, any custom workflows.  

All of that is also I think a great functionality, if the SharePoint taxonomy’s consistent across projects, we can make use of these other powerful tools as well. 

Joe: 

Right. You can centralize workflows, you can run fewer workflows. But it does need something consistent to chew on. It needs some form of trigger, some sort of value by which it can run its business logic. 

Then, I guess we’re pretty much at the end of this. The other thing to point out though, is we mentioned Power Platform, we mentioned Teams. Other thing about Teams, desperately overused. You have 100 Teams teams with 30 channels each, I just think you’re adding to chaos personally.  

Really, what this comes down to is it’s very difficult to separate SharePoint from M365. It really is one integrated platform. Microsoft has done a remarkable job in that regard. That’s part of the overarching thing we recommend to everybody, agnostic, outside of ProjectReady, is to really have an eye to how you develop business solutions and improve productivity, with a comprehensive look at how all this stuff intertwines. Then from there, how M365 can and should interact with and have relationships to ACC, Procore, Box, et cetera.  

That’s my last two cents on this. Anything you would add, Shaili?  

Shaili: 

No, I think we pretty much covered everything.  

Joe: 

All right. Until next time, folks. I do appreciate you coming out today. See you next time.  

Shaili: 

Thank you.