How To Overcome The Headache That Is Document Control

Joe Giegerich:

This is Joe Giegerich and Shaili Modi once again from ProjectReady. Thank you for listening as always. Today, we’re going to be talking about the challenges that document controllers face around managing the chaos of content that’s everywhere, including email and across other systems. We have a white paper and it’s up on Autodesk website. They were kind enough to publish it up there a couple of years back, it’s still there. Around content chaos, right? And it’s been very popular, particularly, around document control because it speaks to this content that’s in flight everywhere. And so the challenges, there are multiple systems, multiple players. How do you come about managing that? And so sort of pivots into how do you integrate it and all the other features that you’re going to need. So starting there in terms of content chaos and searching cross systems. Shaili, I mean, what do we see out there? Procore, ACC, M365. What else? 

Shaili Modi Oza: 

Yeah. Definitely all of these systems, Joe and the other systems also, we see that integration is an issue. But it’s not just that it’s Autodesk or Procore, it’s an internal Autodesk with external companies, Procore, those kind of combinations as well. But at a project level, we always see that there’s more than one system at play. So making that very hard to define, which is the system you would use for document control. All of these systems have their own workflows around document control. But what becomes difficult is when you have content across these systems. 

Joe: 

You know one of the other challenges with that too is that you’re now, it’s what I always refer to as monolithic apps and monolithic dev. All right. We’re always going to use this one system. Well, maybe not. I mean, people have different portfolios. So what am I trying to say? The place of record may always be Procore, but it might be SharePoint. Or you’re working for a customer and they’re using ACC. So not only is there these number of systems that they’ve got to deal with, right? But there’s even “What’s that final resting place?” And if you don’t have an eye to integration, it’s a modular world. I think often you find companies trying to shoehorn everything they do into the one platform, which I don’t think scales very well. 

Shaili: 

Yeah. Definitely, depending on the team and the type of work they’re doing, the type of documents that the teams work with, they have their own platform of choice and that’s how it should be. People shouldn’t be forced to use just one of the platforms, but just bringing them all together in an effective way that at a project level it can all be organized. I think that that’s the key. 

Joe: 

Yep. And I think at a minimum there is no idea that you’re just going to have one place for content that you’re going to have to maintain. I mean, I have not heard to date anybody we’ve spoken to where they’re not using Microsoft 365, right? Everybody does. This is where all your office assets are going to be, your Excel sheets, it’s where you’re going to be starting projects from when you’re in the RFP stage. And then it’s inevitably a Procore, an ACC, a box. Most people have to interact with Bluebeam at some point. Even with the best intentions of different companies, they’re never just going to have one system. They’re always going to have some level of chaos just based upon the fact that it’s Microsoft plus you name it, 1, 2, 3 other systems. 

All right. And so start right there, that’s the initial challenge. You have stuff all over the place. It’s multiplicative, right? To your point, Shaili, internally it’s going to be Microsoft and Procore or ACC or both. And then a project though generally is never just you, it’s the owner with the GC, with the design team. It’s always a multitude of different actors and systems. Let me ask you this, so you have all these multiple platforms, all these different players, what are some of the challenges and some of the opportunities around integration across these systems? 

Shaili: 

Yeah. I think just as a day-to-day usability challenge that we see all the time is if you, as you mentioned, have an external systems, your internal systems. You have all of these different systems open in different browsers with different logins, just trying to manage that on few documents. I hear a few documents are there, we’ve seen users who are always downloading and uploading from one system to another and that can cause a lot of manual errors because you’re just manually trying to get things from one system to another. There is no integration if you are working with two different Procore’s to just make sure that all of that data gets moved. And even with workflows, if you have workflows in different systems, you’re constantly going to all of these different systems to make sure that things get done. 

Joe: 

Right. I issued an RFI on Procore, has the other person in ACC who’s the owner rep, have they responded to that RFI? That sort of thing. 

Shaili: 

Mm-hmm. Yeah, definitely. And a large part of all of these systems, again, we’ve been talking about SharePoint and M365, but is email as well. You get so many emails and people are always sending around attachments, which also adds to that content chaos to just kind of now manage that separately. 

Joe: 

So, to address the chaos, first and foremost, you need a unique ID. Fair? You’re going to bind this stuff together. What’s the rule, right? Who is the master of the whole hierarchy? 

Shaili: 

Yeah. I think so. Definitely. At the project level, we always think that the project ID is the one key ID that brings everything together. And then based off of that project ID, all of the different connected systems can basically look up to that one ID. So it doesn’t matter if the systems are in different places, but they all have that consistent project ID. And then with that we can roll basically all of that information up together that it’s all related to the one project irrespective of where the content lives. 

Joe: 

That the hierarchy is built underneath, it’s taxonomy. Right? So now you have a project ID. Oh, but the other people, they have a different project ID. But at least now you’re mapping your project ID to theirs. I mean, talking to folks, it’s a lot of the challenge I see institutionally is the determination of who the traffic cop is, right? To even start. But if you pick one, you pick the project ID. The reason why I always thought the project ID was sacrosanct, that’s where you bill from, right? And accounting will always get that correct. So why would you want to use different platforms? It’s a loaded question, but I’ll ask it. 

Shaili: 

I mean, again, as we mentioned before as well, it depends on what the team is working on. If it’s a design team working on Revit files, they need to be in Autodesk. If it’s PDFs, construction related documents, the users and the teams they work in Procore. Office assets, they use M365 and SharePoint and Teams. So again, depending on what stage the project is at, what the different teams are working on and what types of documents. All of these different platforms have expertise in different areas. So I feel that it’s at a project level, it’s always going to be a combination of one or more of these systems. 

Joe: 

And it’s best to breed, right? It’s the load of question, it’s best to breed. If it’s an office asset, no one will do better than Microsoft and these cloud repositories. Now, I think about it. I mean, why does ACC exist is because Autodesk makes it money from people using Revit and the rest of the suite pools they have. If they don’t have a way where they can collaborate on the information on those models, collectively they lose market share. So they need to supply a cloud-based collaborative platform that is targeted toward that user type, what they need best of breed for the specific collaborative parameters around those assets. And Microsoft does the same, and Procore does the same. This was a big part of the acts I was grinding on, it’s a modular world. 

Don’t force people to use systems that aren’t bespoke to their specialization. All right, so going back to the chaos. So we accept the fact that best of breed, or at least we do, is the rule. There’s no getting around it, you will never have less than two systems in flight. You’ll probably on a large project to the seventh degree, right? Seven platforms, seven major projects. There you go, there’s your exponential factor. And so we talk about solving it. So we start with the project ID, what from there? What do you think the next requisite thing is for the resolution of that chaos? I 

Shaili: 

I think, definitely, once they’re all connected with a project ID… Now, that they’re all connected as we talked about, that teams may even just who are using Autodesk, would stay there, people in Procore would stay there. But still at a project level, bringing it all together, even just recording all of this information at a project level, it makes that audit trail necessary. Because now, at a project level talking about program managers, project owners, if they’re trying to get that high level view of everything going on in these systems that… 

Joe: 

With the ability to get in depth views as well to drill in. 

Shaili: 

Mm-hmm. Yeah, of course. That project ID and then all of the data culminating from these systems in one location is really important and I think that enables that. 

Joe: 

Yeah. So the taxonomy, that ID and a really scalable taxonomy represents on the backend. And the other thing is to get to all that middleware data, you need a user experience, right? ‘Cause that’s the other thing that we’ve noticed that even if you have this information connected, what’s your next challenge is the coordination of it’s movement either through synchronization or distribution, right? And so this is a huge time burn we see out there and resonates really great every time we talk to our customers. Everything from connect to attach, to the way we handle registration of content, and stuff like RFIs and submittals. Submittals, we do a great and unique job of as well is that it’s really about a simple way to quickly work with that information. There’s this constant time burn. It’s these little things that add up across a day, it is a future podcast. But it’s those little things that occur every day. You go, “Oh, that was five minutes.” Every hour times 100 employees, that is a lot of time that has burned on these things. 

And so what contributes to the chaos is the overhead. Thoughts? Sorry. But it just really struck me like a thunderbolt right now. That particular relationship, right? It’s the overhead from all those little things that eats the clocks, so you can’t do it as accurately as you should. You can’t audit it post. 

Shaili: 

Yeah, definitely. And we’ve seen that just a lack of having that process. Almost everybody that we’ve talked to, it’s just, “Okay, we’ve just ended up creating a huge Excel file where we are now just managing all of this, which makes it even more chaotic.” So definitely a lot of time burn and everything that you’ve mentioned that you downloaded a file and then it changed by the time you were able to send it. Having that easy-to-use user interface where at the moment you’re sending the documents, it gets the latest version. It makes sure that it’s all security and properly… Just having that is a great benefit to just reduce all of that overhead of manually looking for the correct documents, making sure it’s the latest version, making sure all of the metadata is tagged properly across so many different systems. It’s a lot of… 

Joe: 

Or mapped accurately. 

Shaili: 

Yep, yep. Mm-hmm. 

Joe: 

Right? I would throw that into the mix too because look, the specific underlying terms in a database of Autodesk or in Procore, they’ll be different but the same, right? It’s the same idea, just somewhat different. 

Shaili: 

Yep, yep. And at a document level you need these 15 properties. It doesn’t matter where the document lives. So definitely it needs to be mapped properly. 

Joe: 

Right. ‘Cause further on that, the whole user experience, right? If you’re going to manage project information, for it to be effectively managed, you have to easily collaborate on it. And for collaboration to really work in a way that people will use it as a tool is it’s got to be quick, and it’s got to be accurate and take all that overhead out. And so speaking of overhead, this would be my segue, is email. There’s another thing that I’ve talked to people, “Oh, we only want to live an email.” You shouldn’t do that. Then we have people going, “I’ll never use email.” Yes you will. So there’s an inevitability to email, and email is a document any other that needs to be controlled. So what are some of the specific challenges around emails that relates to document control? Ways to address it, that bring it back to a scalable taxonomy. Taking advantage of doing it right. 

Shaili: 

Yeah, yeah, definitely. As you mentioned, almost every time in the workflow there are users who are outside of the system, users who refuse to come to your system to have that process in place. Inevitably, there are times where people are dealing with emails and email attachments, which causes a lot of manual effort to download those. Make sure they get to the right place, they’re tagged properly, they’re in the correct folder or the library with the metadata. Even just bringing them in is a lot of work. But in addition to that, if they’re a part of a workflow, I’m just taking an example of our submittal workflow where you’re working with an external vendor who is a part of a submittal workflow, but they’re just emailing your attachments. So every time there’s a new version, it needs to be cleanly integrated to the workflow just to keep a proper track of it. Who’s approving it, when it’s going out? But it… 

Joe: 

Right. ‘Cause you’re going to be managing that submittal on behalf of the person who insists on emailing you anyway. You shouldn’t have to be brought completely outside of everything to manage it, right? ‘Cause otherwise, you go to the email, download the attachments, grab the EML, bring it someplace else. 

Shaili: 

Yep, yep. 

Joe: 

Sorry, I didn’t mean to cut you off, but keep going. 

Shaili: 

Yeah. No, definitely. So that whole flow where let’s say as a part of the workflow, you’re sending documents out as attachments, you’re receiving newer versions back in an email, people are resubmitting documents. There are all of these different user flows that happen through emails all the time. And by bringing a process on top of that to still continue using email but integrate that seamlessly as a part of your workflow, I think that just makes it so much easier to manage. 

Joe: 

Yeah, it’s essential. 

Shaili: 

Yep. 

Joe: 

Basically. Again, going back to that scalable taxonomy, the only way you’re going to properly tag an email to make it work through a workflow is again, if there’s that real hierarchal view toward taxonomy at the very beginning of a project. It’s a slight digression, but it’s related. The other thing I notice a lot of times when we speak to people, they’re like, “Okay. Now, that we’ve been doing this project for two years…” Not that you can’t help them or improve it or any of the rest of it, but it’s kind of after the fact to go, “Okay. Now, I need to integrate.” It goes back to my earliest deposition, you always be integrating whether you admit it or not. So dealing with it upfront in a way that manages it on scale, well that’s really what this is all about and just compounds that content chaos if that doesn’t exist. 

This is the other thing too. So not only do you have the overhead of all that interaction, but then large sets of documents. So one of our customers overseas and… I forget how many documents they move, but they move a lot. It’s a constant struggle for them because it’s coming from different vendors and the like. So one of the advantages that I think the cloud offers is dealing with large volumes of documents. Do you want to pick up on that? 

Shaili: 

Yeah, definitely. And even a simple workflow, if you think of a transmittal, the client that you mentioned, Joe, they have at least 200 to 300 documents in a single transmittal. So just automating that whole process. When we create content approval workflow from ProjectReady, we automatically create a cover sheet, which is templatized. So creating that cover sheet automatically with 300 documents, each with even if they have five to six metadata properties, we automatically populate that entire table with the correct values. That reduces the time effort exponentially, bringing it together, making sure all of those documents are security trimmed. Creating the cover sheet and then notifying the correct users. That whole workflow, which goes with… It’s one of the simplest workflows, but it happens all the time. And with the volume of documents doing that repeatedly for multiple projects, it just needs to have this kind of a process in place. 

Joe: 

Yeah. Otherwise, you have several full-time resources trying to manage that, right? And that reminds me of someone that we’re speaking to now, and hopefully we’ll be working with in the near future. Document control is more than RFIs and submittals. This is something I’m always on about. One of the challenges they’re having is the control distribution of content that originates in their Procore that they have to get to their client. I think that’s something I’d like to pick up on is even what is document control? Right? So it’s obviously the control distribution of document. I think it’s generally defined more as RFIs submittals, transmittals. But then there’s all these, it’s the edge cases, right? There are elements of document control, control distribution of document that extend past additional workflows that even a resident in major platforms like Procore and ACC. So anything come to mind specifically? 

Shaili: 

No. I think, yeah, just to add to that. That even as you mentioned, a simple synchronization would be considered document control. You are moving around documents, making sure they’re lying- 

Joe: 

Right. 

Shaili: 

… in the correct folder, security trimmed, correct version, all of that. Inclusive of that makes document control. 

Joe: 

Right, right, right. Yeah, exactly. So it’s the synchronization, which again, you need matching IDs and all that other stuff to really orchestrate. It’s kind of like document control light. If you know you’re at least always getting in receipt of all the information. And there is no formal workflow for, “Did I get this stuff I bought?” Let’s take it from an owner rep perspective. There’s also the workflow that we have that I haven’t seen out there otherwise, which is the registration of content. This again, it’s one of these edge cases. So you need to sync it, it’s document control light, right? You have an audit trail, you always know what’s in flight, you always know what you have. But then, like one of our earliest customers, what do they do? They have to ingest large sets of data. Well this is the same thing with our friends to craft, right? Where they’re working with outside vendors that have to upload large sets of data to the project. 

But just giving somebody the keys to a library outside of the governance of that, I don’t even want to think about it is, how do you even know it’s there, how do you keep track of that? And is that not also document control? 

Shaili: 

Yeah, it definitely is because it has so many aspects to making sure that the users have correct access. Once they uploaded all of those documents with the metadata, they should be tagged properly. And once they’re uploaded, we need the correct users who are in receipt of those documents to be notified. And down to then having a way to report against all of this that these users were supposed to submit these documents in this timeframe, having that report in place across systems. All of that processes is required for that. 

Joe: 

So, what are some of the challenges around data security? 

Shaili: 

I would think that having that level of security, it again, depends on different workflows. When external people are involved or different team members are involved, it is very important that they would only have access to the documents that they’re supposed to be seeing. So with our workflows that we have in ProjectReady, we make sure that at a folder level that security is maintained. Only the team members who are assigned those documents are supposed to see those documents or the users who are supposed to be submitting the documents have that secure location where they’re able to make the submissions, basically. In different varieties, I think there is no one drop off location that everybody has access to everything in that spot. It needs to be security trimmed and governed very effectively. 

Joe: 

So maybe like an outside critic on this though going. Yeah. Okay, you have security in location, who doesn’t? So I think that the real challenge with the data security is, okay, is the dynamic nature of team members who are internal and external. And I think that’s what really compounds it again, is yes, you need access to those things. We do an amazing job, and the amazing job that we do is around roles to permissions in these assets that you just swap people in and out, right? So that’s the biggest challenge with data security. I think is just how much of it you have to administer and how for the most part, most systems, it’s a bit onerous. Certainly, on the M365 side. 

Shaili: 

Yes, definitely. Down to the folder level permissioning, there’s no easy way in SharePoint to do that at scale. But with our roles and users, as you mentioned Joe, even when a workflow is in progress. Let’s say, if you reassign something from one architect to another, we automatically update that security in the backend as well. So the end user doesn’t have to worry about making sure the correct user has correct access to the documents. If you remove someone, their access is removed. All of that is very tedious to do manually in SharePoint for sure. 

Joe: 

Yeah. Removing the noise, lets everybody hear the tune properly. Right? Stay focused on the key elements of what their skillsets are about not going, “Oh, damn. That guy got in.” “Oh, I didn’t mean…” I mean, that is all noise in a project. That kind of noise, I think also negatively impacts the adoption of solutions. Right? If you’re giving somebody going, “It’s really auditable and it’s very governed and it takes forever and a day and it’s not intuitive.” It’s the old thing, build it and they won’t come. All right. Getting toward the end of I think, relevant things for us to talk about. Let’s talk about one last thing. So matching ID, get everything to communicate, best of breed at all. At the end of the day, having a way to control documents consistently and a highly scalable taxonomy lets you get to auditing and reporting. So do you have any comments or observations on that? 

Shaili: 

Yeah. I think as we mentioned before, a lot of the times we’ve seen users resort to just Excel files to keep track of this because there’s so much involved with document control. It’s not just the documents, but a lot of metadata around the documents, the assignees. What are the different statuses, what’s going on with each document, is it approved, is it not approved, is it waiting for someone? There’s a lot going on with each document and- 

Joe: 

Which hits milestones in getting paid too. 

Shaili: 

Yes. Definitely. So having a way to easily report against that is, I think it’s a necessity to be able to report and audit all of this information in a way where again, we can still export all of that to Excel, have a Power BI report if we need to. But still just by using all of these workflows automatically, creating that document level report. It’s, yep, yep. 

Joe: 

Yeah, those relationships. 

Shaili: 

Bringing it together. 

Joe: 

Right. Again, part of the chaos is data and other people’s systems. So even down to, “Well, I have all my stuff, it’s auditable. But now, that I’m closed out of the project, I’m no longer working with the design team that was using ACC. Whoops. I got no audit trail.” By having hooks into all these systems, relating it back to the project, even when you get to project closeout. Those other systems that you or other team members or other partners are using, that can still all be recorded in the context of that project. And that’s really key because at the end of the day, I really think more than anything, document control is about milestones, getting paid and not getting sued or if you get sued, winning. Right? Where if you solve the chaos, you’ll also solve what is at the end of the day, regrettably, a big part of what you need document control for is the audit trail. 

Anything else you want to add, Shaili or- 

Shaili: 

I think I’m good. 

Joe: 

Good for now? All right. I hope this is somewhat informative. Document control is where we started early. It was one of the first things we solved for before there was a ProjectReady, was trying to extend SharePoint into document control. And then we hit walls and then we realized, “Well, that’s why you build what we have today, ProjectReady.” Anyway, thank you for coming in today. And again, coming up is going to be the challenge of project owners in the AEC. So we’re really looking forward to sharing with you and there’ll be more to come after that. So thank you as always and talk to you next time.