(Transcribed by TurboScribe.ai. Go Unlimited to remove this message.)

Welcome everybody out to podcast number 1115. In this podcast, I'm going to talk about reference classes. Stay with us.

Welcome everyone. I hope you're doing well. I'm down here in Mexico.

Like I said, in Guadalajara with our team, we've got 35 of our people going through a planning bootcamp and it's fantastic. I'm in paradise. I'm out here in the open.

I hear birds chirping. There are people around. You know, it's funny.

It's really hard to do a podcast every day and to have quiet spaces. So I hope that the background noise isn't disturbing to you. If it is, please just skip to the next one because I definitely don't want to lose you.

I want to respect your time and the quality of these podcasts, but I want to talk today about reference classes. Let me tell you kind of a funny little intro to why I'm talking about this. We all read the book, how big things get done as a, as a pre-work or prerequisite work for a, uh, the bootcamp that we're doing and we're all doing it together.

And Kate was reading it and she started to dig into me, which is a good thing. I'm saying that from a positive standpoint. She started to really dig in and be like, Hey, have we done enough research for the reference class for our, um, the, the $58 million project that we're about to build with lean build our first project.

And I was like, well, we, we do have reference class data. We have previous projects. We have previous projects with relevant experience and we have identified the macro, the norm and the backup plan.

And, uh, but she kept pushing as Katie does as Kate does, which is really, really quite good. Actually. It's a, it's a fantastic way to approach things.

And so she was like, yeah, but how many projects do you have? How recent are they? Were they before elevate was involved with the projects or after are we taking them into consideration that the trade partners working with us in Phoenix being new to working with us, right? Are we doing that? And I was like, Oh my gosh, I am definitely not digging deeply enough into this. And I need to dig. I need to do better.

I need to do more anyway. Um, so, uh, we, we dug into admitted a big part of the bootcamp and one of our teammates made a little graphic and I was like, Oh dude, I've got to do a little podcast on this because I'm sure that we're not doing enough when it comes to identifying our reference classes. I call this anchoring, but the den or sorry, bent flyberg and Dan Gardner call it, uh, the, a reference class.

So a reference class is basically identifying, uh, similar projects, a reference class and, and knowing what their schedule and budget was or specifically how much they overran their budget or their schedule and using that as a dataset to understand what your project will do. And it's really important because we can't, oh boy, there's a lot of noise in the background, I'm sorry, but we cannot think that our project is different. We cannot think that we're special.

We cannot think that our project is unique. Our project is not unique. We are not special.

Um, most of these projects, I don't know of anything in construction that hasn't been done before and we have data on this and the chances of us like magically hitting it out of the park are just not very good. So when we look at our reference class, we want to look at past similar projects and as many as you can in your reference class, like it would be ideal to have like, um, 50 projects in our reference class forecasting and at least 25 in our local area, meaning the state or region. Now I know that's a lot.

So really this podcast is like an ask for help. We need to get to a point where we're tracking this information more. In fact, I told or I asked respectfully our director of innovation.

I said, will you please, once we're closing out projects, uh, put on the plan or the process that we need to check in and do a reflection on the, how well the project did from a overall duration standpoint and a budget standpoint so that we can start to keep track of this and possibly even build a database. We all need to do that because if you build a hospital or a laboratory or a multifamily project or a nuclear power plant or whatever it is, then you know that data. Then you can know with pretty good certainty in the future, what future projects will take and not get yourself into trouble.

So a reference class, they're past similar projects that will give you an aggregate, an average of how far over you are in budget and schedule so that you can properly forecast your current project and not get into trouble. This is done for a schedule and budget. And what you want to do is look at the overall variance in each of the above so you can get you from your reference class.

You can either say, hey, what was the overall duration or the total budget? Or you can simply use the data from the overages, how far past schedule or over schedule, how far over budget were you and use that in your data, either one. But the point is to understand what happened to the reference class from a schedule standpoint, budget standpoint. And if you can, what were some of the largest constraints or roadblocks or problems that they dealt with? Then you'll want to do a deep dive into as many of the projects as you can and make sure that you understand some of the things that are going on.

Now, this is a touchy subject here because, and I want you to know that our tech production system is perfectly designed to accommodate this. We have macro level tech plans. That's your promise.

Those need to be fairly conservative. It represents our slowest speed. It should represent a reference class.

It's the promise to the owner, the contractual milestone, the contractual end date. Then we have a target. That is our norm level production plan.

And that represents faster speeds, but the same plan. So it's not two schedules. It's not two plans.

Same plan, different speeds. And so the macro is the promise. The norm is our target.

So this is perfectly designed. So when you're planning a project, you will want to plan your macro level attack plan with your reference class and not think your project is special. But that doesn't mean that you're not going to attempt as best as you possibly can to get rid of the risks, to get rid of the roadblocks and constraints, and to increase your chances of being able to finish it better, faster, and easier.

And so what you'll want to do is once you have your reference class and you know what the overall duration and budget should be, you make sure that that's looped into your macro level attack plan and that that becomes your contractual promise to the owner. And don't shortcut yourself. Don't ignore it.

And don't think your project is special. And don't assume things will be better, right? Now you have a contract. Now you have a promise.

Now you'll want to take, from looking at those projects, their overages, the roadblocks that they face, the constraints they had, the black swans, the problems, the circumstances. And you will want to find out if you can mitigate those on your, or prevent those on your project, right? If you're, you know, the multifamily project dealt with late switch gear procurement, you're not just going to accept that and eat that whole duration. You're going to identify that and attempt to prevent it in the future.

So when you're looking at your reference classes, you are going to, through proper planning, attempt to not experience those delays and to not have problems in that direction and to do a better job. But that is on your target, not your promise. Okay.

I hope that makes sense. So when you do your reference class in the macro, you will establish a probability, a probability distribution throughout that reference class and make sure that it's a normal distribution, that it's the normal likelihood of how long that project will take or how much it will cost. You're not looking for the fat tail distributions or the worst case scenarios.

Okay. And that's important because you really want the average, right? And so you'll compare your project to the reference class and see if there are any adjustments, not adjustments for wishful thinking. Like, I don't think this will happen to me, but adjustments in overall duration, adjustments in complexity, things like that.

And you'll want to make sure that your promise is on target, meaning your contractual promise is on target with the normal distribution probability within that reference class. Okay. And that's really important.

That will tell you what your promise is going to be. And again, you are going to understand in your project specifically, if there are specific ways that your project can do better and then make that as a part of your plan. So your target, i.e. the normal level attack plan can do better.

Okay. So that's really important. So you will compare the specific project with the reference class distribution to establish the most likely outcome and make the promise and also make some planning so that your target can do better.

Then modify as needed and iterate in your pre-construction efforts and during your fresh eyes and your risk review to make sure that's correct. The biggest things that you have to do is don't ignore this. Don't wishfully think.

I think different people in the industry call it wish thinking. Don't think it won't happen to you. Don't think you're unique.

Make the promise accordingly and then target something better based on data. The more information we can get with this, the better. I would highly recommend that we tabulate this by program types.

And understand the overages and compare it, meaning level it like you would do with bid leveling, to make sure that you understand what your budget and your overall project duration should be. And you know from anchoring what risks you should be looking out for and what kind of different planning you should take to make sure that you're heading in a better direction. Now, if you're implementing attack planning and lean construction, you're going to start doing better and better and better on your projects.

But don't anticipate that until you've done it once or twice. So if you're implementing attack planning and last planner, you're definitely going to do better on your next project. But don't promise that yet.

Get through one or two or three or four or whatever projects of doing this. Add that to the reference class data and then start to project it and promise it, right? So that's really, really key. One of the things that I don't know that was accounted for in how big things get done is the concept of lean construction, attack planning, turning your project into a production system, last planner.

These really key techniques because they definitely will massively increase your success on your projects. But I also think in one sense the book does because it's saying, hey, stay safe. Keep your promises based on traditional construction.

And then when you have better data based on proven implementation and proven results, then you can start to adjust the reference class. So if you have any questions on this, please reach out to me. But the book, How Big Things Get Done, is amazing.

We need to be doing more of this. So the ask is, let's start keeping better data for past projects. In fact, one quick thing I want to say is that I've seen people throughout my career say, I want to track production rates.

I want to track historicals. I want to track it by activity. I want to track this.

And it never, never, never, never, never, never, ever worked. But if a company started to say, how much over on budget and schedule did we go for these different program types and quantify it either by square foot or whatever it is, level of complexity, whatever it is, so that you can compare it to new projects and had a database of this information, that would be the best way to track production of all time. And I highly recommend it.

So the ask is, let's start tracking this information. Let's start doing the best we can to get reference class data when we're planning projects. And the third one is, let's not ignore it.

And let's make sure that we have a difference between our promise and our target. I hope you've enjoyed this podcast. On we go.

Please join us next time in elevating the entire construction experience for workers, leaders, and companies coast to coast. If you're enjoying the show, please feel free to share with your construction colleagues and help us spread the word by rating, subscribing, and leaving a review on your preferred podcast listening platform. We really appreciate it.

We'll catch you next time on the Elevate Construction Podcast.

(Transcribed by TurboScribe.ai. Go Unlimited to remove this message.)