Take A Tactical Pause (feat. Kelly Doyle)

Take a tactical pause featuring Kelly Doyle construction brothers

Listen now or check us out on one of these platforms!

Apple Podcasts


Google Podcasts



Is your information available to all of the people in your organization? How does your team manage their data?

This week, we take a Tactical Pause and evaluate some of these questions. One of the biggest things that grinds our gears around the office is the assortment of applications we have to deal with working with different contractors.

Kelly Doyle is the C.O.O. of ProjectReady, a platform that connects various project management tools together and allows teams to see all of their information in an easily accessible way. We dive into how information silos are formed by our companies unknowingly, choosing your apps wisely and how to get started selecting what tools your team will use.

If you have anything we missed, feel free to text us! - 478-221-7009


Kelly's LinkedIn

Project Ready Website

Please consider subscribing to our podcast!


Like us on LinkedIn!      

Like us on Facebook!    

Follow us on Instagram!

Eddie's LinkedIn      

Tyler's LinkedIn      

(Our day job)   


Tyler: Welcome to the Construction Brothers Podcast. I'm your host, Tyler Campbell, and with me like he is every week: My brother, Eddie Campbell. 

Eddie: What's up, Tyler? 

Tyler: Not much, Eddie. Well, this week, we take a tactical pause.


Interview: (12:04)

Tyler: Well, Kelly, thanks for joining us today, man. Can you tell us who you are and what you do?

Kelly Doyle: Well, my pleasure. My name is Kelly Doyle. I'm the Chief Operating Officer for ProjectReady. We're a SAS Base Application trying to bring together owners and design teams to help them manage their projects more easily, connect their multiple systems that they're working with together into an integrated data environment, and just helping to break down some of these data silos we have in this industry. 

Eddie: Well, I want to go ahead and get into what you've kind of made yourself an expert in, and that's integrating all of these different softwares that we've got to deal with. I mean, there are a lot of them out there right now in the construction world. What are your thoughts on just handling the amalgamation of softwares that get thrown at us right now? 

Kelly Doyle: That's a great question. You know, in a previous life I ran the construction technology consulting practice for JBKnowledge. And in that role, we were trying to keep track of upwards of 2,500 software applications at any given time and then be able to advise folks, hey, what's the best tool? And really what I found most important, and I'm going to frame all of this in that reference, is figuring out what you need before you go out and look at all the different options on the table, right? What are you really trying to accomplish? And that really served as the foundation of how we help folks. So to answer your question, “How do you deal with all these different systems?” Why don't you take stock first on what you do have, and what are you actually using, and what are you using them for? What's your end goal? What's your desired end state? Are those tools really helping you? Once you pull that inventory together, is there an opportunity to consolidate in some way between, I've got overlapping applications that if I bring two different efforts into one, either one that you already own or another one that you can purchase in lieu of two, that helps. But at the end of the day, what you don't want to do is create a bunch of data silos. And unfortunately with the confluence of options out there, all these 2,500 different options, that's what we've created a lot of these days, is data silos and systems that don't work together, which just creates more inefficiency and waste on the part of duplicate effort putting things into place. Not to mention the rework that happens when folks didn't update one system or another. Does that make sense? 

Eddie: Oh yeah. And I mean, I feel this. This pain is real. Because trying to navigate between the different pieces of software we have, making sure that everything's up to date, so if I say, “Hey, team, we need to make sure that RFI are logged here,” but RFI also have to be emailed, they have to be logged somewhere else. It just, you're trying to make sure that you're not putting an oppressive burden on your team in keeping up with all of this stuff.

Kelly Doyle: Well, a hundred percent. You hear the word “common data environment” thrown around a lot. And there's multiple systems out there that are considered common data environments. What I think has also happened is, some of those common data environments are really focused on different phases of the projects, right? BIM 360 as a tool is probably more geared towards the design phase of a project. Procore is probably more geared towards the build phase. And then you have some firms that do both—design and build, right? Design-build firm. What tools are they using internally to manage the design process and manage the construction process and internally have their own interoperability? How do you get information from one to the other? I've heard of some very large firms out there, design-build type firms, that are literally using email and spreadsheets to manage the design process, and using a powerful CDE for the build process. Well, why not work together? And some of that is because how do you connect a design platform to build platform—or, you know, the other thing that you just described within RFI. There’s folks on multiple ends of that one transaction, that one workflow, if you will. It's your perspective on how much pain you feel there, how much effort you need to put into it. Not that you're going to not give it the appropriate effort, but by nature of those multiple systems, how much effort do you need to put into maintaining them to play CYA, make sure you've logged it and things of that nature. So surfacing that information workflows that bridge multiple platforms, it's the Holy Grail, right? How do you make that happen? And that's what that's what we need to see in the systems today.

Tyler: Curious, what does CDE stand for?

Kelly Doyle: Sure. CDE is a common data environment. So the notion is there is a single place for all project information to flow through, be stored, logged in a single database, so that you can reduce or eliminate that double entry of information ‘cause folks are working in the system. Connecting point solutions to that common data is the common practice. So having your estimating solution integrate directly to your common data environment makes that estimating information available to folks to view, to see, to report on, and things of that nature. Now, one of the things that we've been looking at here at ProjectReady is something called an integrated data environment. We've had some of our customers refer to what we do in that way. And it's really a concept I want to focus in on though, which is the integrated data environment, because you get these phased common data environments that now have to work together within the context of the larger project. When the owner commissions the project and literally is looking across the street at a piece of dirt and says, “I want to put something on that piece of dirt,” there's no system in place for them to start that exercise, right? It's now going to start with chaos from day one. You’re going to start throwing things around in emails and spreadsheets, which everybody knows while it works at scale, not so much, right? That owner needs something that bridges that entire span of the project. They are going to be there from beginning to end. Now you get into some design efforts. Okay, we're bringing enough formality to this. Let's spin up a design environment. Okay, well we need to connect that to all the effort that you've put in before you brought in that more robust design team. Okay, well now we're at the point where we need to transition to build. We're going to bring in a build tool to do all those things, right? And then as you continue to move along through the different phases of the project, until you get to turn over, where is all that going? How are you tying that together? Is there a common communication and collaboration platform that allows all the people in the project—doesn't matter who pays your paycheck, everybody has to talk, and everybody has to communicate, everybody has to collaborate—how do you do that when you have multiple systems in place? I'm telling you right now, people use email, which is why you guys get four or five hundred emails a day, right? And then you get to the noise. What's noise? You stop paying attention to your email because of all these hundreds of emails, which is your primary means of communication, communication breaks down, stuff doesn't get done on time. There's risk, there's legal implications, there's safety implications. All of that is a byproduct. So being able to tie all that stuff together in an integrated data environment, which allows you to communicate, collaborate, audit everything that's flowing back and forth between these systems, and then also do your reporting across systems. You know, we moved a piece of content from here to there, where is it? Well, we can track where it started and where it came from, how it moved through this system. And it just got dropped off in the other system. It may not be able to know what happened after that, but at least you can get it to the other system and then go searching there versus what we do now, which is maybe dig through 400 emails and hopefully find where something went, where somebody told you, yes, you have permission to do this. Does that make sense, what I'm trying to describe here? 

Tyler: I'm kind of curious, too, ‘cause I mean, we talked about silos a little bit. We kind of touched on that. And from your experience, what is the recipe for creating a silo in your organization? 

Kelly Doyle: The recipe for creating a silo is looking to solve a single problem without considering what's going on in the rest of the organization. So I'll turn the brim of my hat around for a second, go back to wearing my consulting hat. When I would talk to consulting clients, we looked at their technology deployment holistically. Let's look at the entire process that you go through and look at the goals that you're trying to accomplish. Because there are some systems that can do two, three, four, five different things. And if they're integrated together, guess what? You don't have a data silo. But if you get an estimating tool, and you get a safety tool—I can keep stacking tools on top of each other, right? But when I look at those needs in a vacuum, I end up with silos. So that's at a company level. Well, the projects that we all work on are companies working with other companies for another company. So you end up with either a batch of individual tools that may or may not work together, or a set of tools that does. Something I like to call a system of systems. I have to give credit where credit is due, an old boss that used to work for Boeing described it to me that way. And those folks have been building airplanes for how long, and there is literally zero tolerance for mistakes. That airplane falls out of the sky because of a problem, right? So you have to have a system of systems. You can't necessarily have a giant system that does everything. There's lots of folks who are trying to do that, but there is still some time before we're ever going to get there, if we ever get there. So in the interim, how do we create this system of systems? 

Eddie: There's kind of a presupposition that if I'm going through my email, that I'm going to be still in that chair later. And that's not always the case. So organizationally, and especially as an owner, I don't want to lose information because I've lost a specific person in that chain. And this is a safeguard against that sort of thing, because it puts it on that common data environment where it's exposed and it’s gettable. 

Kelly Doyle: Correct. We need to be able to track tasks. Who did them, what did they accomplish? Is it done yet? Right? You bring it back to the RFI. Somebody asked the question, was it answered? Is that light fixture that's sitting over our head an RFI that was not answered, and that chandelier is going to fall down on somebody‘s head? I use that example because I've heard it at conferences before, when folks talk about, well, did they answer the RFI about the light fixture above your head? And everybody looks up, right? I keep coming back to communication and collaboration, because I really feel this, it's a personal passion of mine, that's where things break down. You know, my background way back in the day, I was a military officer. And that is the key to mission success, and it's the key to keeping people alive, is that there is a clear way for folks to communicate what they need to do and do it together. Because if you're doing things together but not together, and you're pointing guns down range at the enemy, you don't know if you've just pointed it in the wrong direction. I know it has nothing to do with construction, but that's why communication and collaboration, you know, it's firmly rooted in my psyche at this point. So to your point, what if you have communications on the project and you're not capturing that anywhere, and either we send you home or you pack up your toys and you go home and all of that is on your phone ‘cause you've been text messaging? Because folks will find the easy button. If you don't give them the easy button, they are going to find it. So people are going to send text messages to each other, ‘cause it's just easy. They don't want to sit down and monitor emails, because they're getting so many emails they can't see through the noise. So what's the next best thing? Text is the new thing. Well now you're getting how many texts, right? Okay, great. So texting is easier, but it is not part of the project record. So look at a tool like Microsoft Teams. With teams, you can have Chat just like instant messaging, but that's part of the project record. If the way you have your Microsoft Teams set up as part of the project record if it's just a loan thing, good luck finding it, right? We like to put all the information within the context of the project—where are you going to store your content? How are you going to have your communication and collaborations? All should be in the wrapper, that one project idea, it doesn't matter who pays your paycheck, everybody's on the same project. Everybody communicates in this space. Can we make it easy to share files? Can we make it easy to conduct video meetings and record those video meetings so that way you have a record of what folks discussed in that design review or in that whatever session, right? You're building trust and transparency through the fact that you can catalog that stuff and easily without having to take that extra step of recording it in another platform and hopefully you remember to save it to the right place. Because everybody puts content in the right folder, in the right project, and that happens on every project. 

Eddie: Every time, every time. (laughs) 

Kelly Doyle: So having a tool in place like Microsoft Teams allows you to do that. It gives them the easy button, but keeps everything in context of the project. And then it's auditable, it's trackable, it's searchable. 

Tyler: So, on the texting front, it's funny that you mentioned that, ‘cause we were talking about that a couple months ago. You know, why don't we start texting some of our project managers in the field and maybe we can find a platform to handle that? And I'm experiencing a lot of that fatigue building up, too, is like, I've got this app that does this one thing. I've got this other app that does this other thing. And even internally, we were using Trello, right, to keep track of where our team is at. And you know, we'll have an individual card with an individual task that one of our team members will do. But you know, these people will keep paper checklists, or they'll use Todoist or Google Tasks or just a note on their phone. Like they have different forms of keeping track of their tasks. We have to ask them to go back and fill out the Trello board each week and say, alright, go here, tell us what you did, archive the things that you've done, so we can talk about it on Monday. But getting people to go that extra step, it always broke down there. And it's not because the people that we have are irresponsible or anything, it's that they're busy. They've got a lot going on and it's like that one added layer, they can't handle the fatigue that comes with that.

Eddie: It's an unnecessary layer of administration that gets ripped off. And so I hear being able to unsilo and get information easily, and that's an advantage, but there's the other side of this that just kind of keeps tipping and tripping over in my mind, is the overlap of systems. Because I mean, we feel that in a very real way, where a system will get all the way up and to a certain point—it's designed for this thing, it does this thing well. Bluebeam sticks out in my mind. Bluebeam does a lot of things well, and then it has some things on the periphery that it does pretty well. So there are good estimating tools in Bluebeam that you could utilize, but is it like a, “get your number” estimating software? Maybe not, maybe it's not the one you want to use. But there is this area of overlap between that and another estimating software—I was talking to a guy, Jordan, that we work with all the time, this week about that. And he's just trying to figure out that estimating software and get that solution. It's like, yeah, Bluebeam is going to get you some of the way. It's got some cool tools for it, but I don't know that that's necessarily the thing you want to use. But there's overlap. And you might want that overlap to come into one spot, because you may want to do up and to this point on this platform, and then continue that process on another one. The common data environment allows you to do that. Am I correct in that?

Kelly Doyle: Yes and no. So you bring up a good point, right? The common data environment is essentially the plumbing and the database behind things, right? The plumbing is the integration between tools that allows you to do something in one system and have that data flow through to another and be stored somewhere. The overlap between tools is sometimes a good thing and sometimes a bad thing. I don't think it's a problem having the overlap, even using different tools to do the same thing. One of the ways I described ProjectReady as is connective tissue. We're bringing systems together. And folks ask us all the time about, well, you can distribute content between using BIM 360, or you can distribute content using Procore. You can, and there's any number of other systems that do, why do you need another tool like ProjectReady to be able to distribute that? And my answer is that, just transferring data back and forth between systems is great, you have ones and zeros—what are you going to do with it? It's workflows that bridge different systems. You have content in multiple systems, how do you grab that content out of both systems to send to a third party? You know, you do your design, review, your design iteration to get a CD set to a particular point that you're willing to distribute it or need to distribute it, but you also have content sitting in SharePoint that you want to pick up to send out in that same package. There is some stuff that's sitting in Procore because that's where they've captured and stored the information. Well, as connective tissue, we're able to grab that content from multiple systems, package it up into a single package and then send that out. So now you have a workflow that bridges multiple systems. It's a user experience that empowers the user. So if you bring it back to an estimating scheme, like you were just talking about, yes, you may be able to do some of this stuff in Bluebeam. You may be able to do some of this stuff in a dedicated estimating platform. That doesn't mean you need to be one or the other. And it also doesn't mean that you're necessarily creating a data silo. You may want to focus your Bluebeam on the markup kind of tasks, or utilizing studio sessions to do a design review. And you still keep a Bluebeam as a tool that you use all the time, but your desired end state from an estimating standpoint is more mature, more robust. Well then use your estimating tool for that. But when you're looking at it holistically, don't make that decision in a vacuum. Look at the other systems that you have, and is there a way for you to get that information from your one tool to the other? And oftentimes there's multiple avenues of approach, right? And in an integrated data environment. I could have an estimating solution that types into a construction management platform. Okay, great. There's a way for the data to flow that I can still access in my integrated data environment because I have connections between all these different systems. And then there's other things, like the communication collaboration that I just described, that's spanning the tools and has nothing to do with either of the core systems or any of the core systems that you have in play. But again, there's a way to still connect it together. Our business, our industry, is highly interdependent, right? You can't draw straight lines to anything in our industry and the way we do things. And the more we want to become a productized supply chain, use more industrialized construction, and have multiple organizations that may— A fab shop for a subcontractor is still within the current envelope, if you will. But if now you're having parts manufactured by some production facility because it's custom, you still need to have that be part of the supply chain. The communication needs to be there, the collaboration needs to be there, some way to have that data flow from here to there between two systems that will otherwise never have a direct integration. How do you pull all that stuff together? That's this whole concept of an integrated data environment. Which layer of the fabric is your data flowing, and do you have this building cladding, if you will, wrapped around the whole thing that allows you to communicate, collaborate, search, audit, all that kind of stuff, ‘cause you have all these systems and folks in play.

Tyler: I would imagine filter, too, a lot of the data as well. And that’s, you know, we'll be creating a lot of data as we're going through these processes. Like you said, you know, we'll have 400 emails or 500 emails, or even a thousand emails on a project. Being able to filter all stuff out in one environment, I could see how that would be very, very desirable. And often I'm like, “Oh my Lord, I need something like that,” because you tend to create so much data around what you're doing.

Kelly Doyle: Yeah. I mean, a manifestation of that is we have an ability to search project emails. By the way that we provision our projects and bring these systems together and unify them around a single project ID, Microsoft Teams is part of that provision. So that communication layer that I keep talking about is part of that initial build. When we do that, Microsoft actually creates a group around that particular project. So when an email comes in and it hits your inbox, or some group of emails that hit your inbox, and you're like, “I don't need to answer every one of them, but I need to keep them within the context of the project,” you can grab a batch of them, drag it down, and then drop it into the group. It's now contextualized within the project itself. And then using our search, and we leverage the Microsoft search tools, we are able to search by key terms and use some of the same filtering that you see when you go to your search bar in Outlook or Microsoft Search or Bing or something like that to to filter down to, does it have attachments or not, it's from this person that went to that person, date ranges. So the tools are out there, but if you don't bring things into the context of the project in some way, then you're looking for the needle in the haystack, right? So that's our end goal. And hopefully that gets you to your desired end state that you just described.

Eddie: So what platforms, or what softwares is ProjectReady bringing together? 

Kelly Doyle: Sure. Great question. What we are able to do is bring together SharePoint, Microsoft Teams, BIM 360, Box—and everything I just mentioned there, we can actually provision. So from scratch, using a concept I call “going slow to go fast,” you set up your security matrix, your role matrix, who's on the project and what roles they're able to do, and then the security that goes along with it, in under five minutes. Just by selecting the folks on the team and the template for the project itself, I can provision those four together in under five minutes without IT’s help. Okay. So that brings everything together around the project ID. I can also integrate a byway of just having a project ID from an existing project in both Procore and PlanGrid. So those are a good number of the major platforms that are out there in the space right now. And that gives us the ability to have the connected workflows that I described earlier, where you may have an RFI generated in PlanGrid that, once it hits the boundary of PlanGrid, and it needs to go to the owner for a response or the architect for a response, they're waiting for that email to let them know they have something to do. Well, we can surface that on the dashboard in ProjectReady. And when you click on it saying that there's something for you to do, it takes you into PlanGrid to action. We have the same thing for BIM 360 issues, same thing for Procore submittals and RFIs. It's extending those workflows between those different platforms. And then obviously Microsoft Outlook is in there as well. The reason we leverage Microsoft 365 so much is because over 90% of the organizations in the world. So that's how we're able to bring these systems together and tie them together in a stack so efficiently.

Tyler: All right. Well, I think we have come to our megaphone question, our favorite question. So if we gave you a megaphone that the whole industry could hear for only 60 seconds, what would you say?

Kelly Doyle: The thing I would say to the industry is, we need to take a deep breath for a second, take something from my military days called the tactical pause, and take a look at the industry and where are things breaking down? How can we look for our commonality and our common goals that we can get these things accomplished? And I'm really looking at this through a technology lens at the moment. Look at things holistically, instead of looking at where does it break down, let's look at how we start putting things together. How can we make incremental progress and not be looking to solve the entire problem right now? That's something I saw all the time in consulting. Those organizations that are taking the efforts to make incremental progress are going to rise to the top. The folks who are not doing that are going to fall by the wayside. There are some folks in the industry, big alliance projects, that are actually now starting to set aside budget to innovate in-flight online projects, because their mega projects are so big they can test things end to end. So the industry is moving in that direction. It will happen. The big boys have way too much at stake not to figure it out, right? So if you are not doing that, when they get a piece of it figured out, or they start putting multiple pieces together, or when it all comes together, if you've not taken any progress or any steps to make that progress, it's too late. And I think BIM is a perfect example of that, right? I can recall, from the technology survey, about 40% of the industry is doing nothing in BIM. And when I talked to folks in consulting environments, I'm like, why aren't you doing anything in BIM? Well, there's no real call for it in our region. Okay. Well, what are you going to do when the owners really get the grasp on how much benefit there is for them and they dictate you have to have this? You don't flip a switch. It takes investment in people and equipment and software and training and effectiveness. It takes time as teams in the design process put all this stuff together, to get good at it. You don't flip the switch. So the megaphone is, start doing something. Even one step at a time as forward progress. If you do not, you are actually going backwards. 

Tyler: Heck yeah, man. Love it. Love it. Well, Kelly, thank you so much for joining us today, man. We really appreciate it. 

Kelly Doyle: Oh, it was my pleasure, loved it. Great conversation, looking forward to future opportunities to chat. 

Tyler: Heck yeah.


Tyler: Hey guys. Thanks for joining us today. I wanted to take a second and point you at a couple of things before you go. Number one, make sure that you go check out our website, it is www.brospodcast.com. We're constantly posting new blog updates on there and thoughts of things that we're seeing in the industry. And then also, make sure while you're there, go check us out on social media. We are on Facebook, LinkedIn, Twitter, and Instagram. We're constantly asking questions there, trying to get people involved and engaged and learn more about what's happening in the industry so we can keep bringing stuff to you that's relevant. And also, share it with somebody. If there's something in here that you thought was valuable, forward it over to your friend, let them know about the show. Again, that's going to help us out a lot. And finally, please leave a review. If you found this interesting or helpful at all, you could help us out in a big way by just hitting a review on Apple Podcasts or Stitcher. So thank you so much for joining us this week. Have a good one.