Have you ever run into a project delay that wasn't your fault?
Did you find yourself running into wall after wall when you tried to get the project team to help you out?
If so this episode is for you!
In this episode we discuss how to manage project expectations in the contracted environment.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Show notes
Phil Zito 00:00
This is the smart buildings Academy podcast with Phil Zito Episode 229. it folks, Phil Zito here and welcome to Episode 229 of the smart buildings Academy podcast. And in this episode we are going to be discussing expectation handling in the contracted environment. So I was sitting and reading through Facebook once again and came across a post in the controls and building automation Facebook group. And this guy was asking about how to better handle expectations with contractors, mechanicals, and GCS on projects. And I started reading through the responses and just kind of what was being said, and I thought this would be a really good topic for this week's podcast. So everything we're going to discuss is available at podcast dot smart buildings Academy comm forward slash two to nine. Once again, that's podcast, that smart buildings academy.com, four slash two to nine. And depending on when you're listening to this, if you're listening to it, the day it releases, there is still time to take advantage of our black friday discount that goes on until Monday night of the 30th at midnight. And that's when it ends, you can save 20% off of any of our training courses. Alright, so when I look at expectation handling in the contracted environment, what I look at is that expectation handling really starts with expectation management, and expectation management and an in and of itself begins with proper project planning. So later in the episode, we're going to cover how to handle project requests, which is ultimately what expectation management is all about, is, hey, making sure that you are managing requests, and both to you as well as from you. And that begins by laying out what the expectations are. So first thing I want to cover is this concept called the project management triangle. And it becomes really important for us to understand this in order to properly understand expectations, and ultimately to understand how our requests affect both our profitability and execution as well as the contracting team's profitability and execution. So the project management triangle basically says that, if you are to go and increase the quality of a project, you're either going to have to increase cost or decrease or increase time. If you are to decrease time, you're either going to have to decrease quality or you're going to have to increase cost. And if you're going to decrease costs, you have to increase time, or decreased quality. So there's this inner relationship. It's almost like the ohms law of project management. And it's important to understand this because when we walk into a project, and we haven't done proper expectation management, we haven't planned things properly, then what can happen is we can be expected to do scope in a highly compressed timeframe with not enough cost and that can degrade quality. And so you can see how these concepts become interrelated. So let's dive into what expectations are and why that matters to us. So expectations by my definition, are quantifiable measurements for delivery of scope items based on the current project schedule and associated dependencies. Now, there's a lot to unpack here in this simple sentence. The first thing we need to unpack is quantifiable measurements. What are quantifiable measurements for delivery of scope items. So quantifiable measurements are not we're going to finish the project this year. quantifiable measurements are not we're going to deliver a building automation system. They are much more specific than that. So it becomes critical that we have specificity when we are dealing with our projects. Specifically, we want to be clear on delivery dates, we want to be clear from the expectation of the contracting team, as well as the expectation that we have as well for any measurements that are going to be applied to things that are dependencies for us.
Phil Zito 04:44
So for example, if we are expecting to have power or mechanical systems start up on a specific date we need to go and define that and we need to be clear in that we need power to act systems we need x system started up we can't just say we need the mechanical system started. up, because quite frankly, we may need the hydronic plant started up sooner than we need the airside or we may need the airside started up sooner than we need the hydronic, we may need specific rooftop units started up so that they can cool specific areas using dx cooling. And then we can suffice to wait for the central plant later. But if we don't quantifiably measure these aspects of our project and manage these expectations, then we're off on the wrong foot from day one. So then we get into expectations or quantifiable measurements for delivery of scope items, what are scope items, so scope items are things that are unclear to many, in that we say we will install a fully functional control system, we will commission the building automation system per the specification, we will provide programming of the central chiller plant, you're getting a little closer with that last one, but those first two are extremely vague. The startup and validation of chiller one is a scope item, saying we're going to install a fully functioning control system is not a scope item. Vague terms are going to lead to vague expectations. And they are going to be hard to manage, especially when you're doing work for the government or work for you in this palette it and they will really take you to the cleaners if your scope is not very clear. And you know some private entities will as well. So the reality is that vague terminology and vague scope definition is really going to put us also on a poor foot for going and managing expectations, it's going to be much easier as we get more specific. Now we have you know the delivery of scope items based on the current project schedule. So the current project schedule all project timelines, and pm processes are based on the initiation and close dates of the project confirmed at the kickoff meeting. So if you've ever studied project management, you know that we have an initiation period and we have a closed period the initiation period is where the contract effectively begins. And the close date is where the contract effectively closes. Now that could be percentage of completion 90 100% it's all dependent on the contract. But substantial closing of the project is usually where our project management duties will start to fall off. Now, it's important to know that this is all confirmed at the kickoff meeting. However, that's not necessarily true. It also is confirmed in the release to operations meeting which all of you should be having no matter how small your project is. This serves two things. One, it serves holding the sales team accountable, and ensuring that you're helping them to develop in their ability to provide better quotes and better sales estimates, which ultimately is going to be good for them because it's going to make them more competitive. And it's also going to point out areas and where costs can be trimmed or you can make competitive strategy decisions that will make their proposals that much better. But it also is a period for you to re estimate the project, right, you can go in and perform a project re estimate. And you can ensure that your costs are all in line, you can go and clarify any expectations that were promised to the contracting team. There's a variety of things you can do. When you know the current project schedule, and you're performing a released operations. Now, you're going to have an idea of that current project schedule from the released operations meeting. However, it is up to you to go and confirm that in the kickoff meeting, you should always attend the kickoff meeting, because the meeting itself is going to confirm timelines. And it's your opportunity to communicate any associated dependencies that you need. Because associated dependencies are ultimately going to drive, the project schedule and any changes to the project schedule, power material equipment startup, those are all associated dependencies, some of what you control. And some of what you don't control. You can't control material delays. Or can you I mean, if there is the potential for material delays, you could order your material earlier, you could take that risk and saying hey, our submittals aren't approved yet. But
Phil Zito 09:40
you know, this is the exact same building that we've done 10 times on this campus so I'm pretty sure I know what we're gonna end up doing. We you cannot control power. Usually you cannot control equipment startup usually. And those are key dependencies to a lot of tasks in the building automation world and it ultimately becomes your job to attend these project meetings and keep the project management team aware of impacts to the project schedule. Oftentimes, when I run into people who are saying they are having trouble communicating to the project management team, the importance of having a proper equipment startup or having power, or having consistent, you know, 42 degree chilled water or having consistent 55 degree discharge air prior to being able to go and do startup or do test and balance, etc. What I'm running into is not always, but sometimes a person who has not effectively managed expectations from project kickoff, because if you provided a Gantt chart to the project team that showed clear dependencies and requirements, and you explain those dependencies, and you ensure that clarity was reached, and you know, a decision was reached that yes, we accept this Gantt chart, we accept these dependencies, and we're aware of the other contractors roles in achieving those dependencies. Then if those dependencies slip, like the site gets a big rainstorm for three weeks, and you know, the slab can't get laid, and power can't get run and all sorts of issues, then you can go back and effectively communicate what is going on. And you can communicate that, hey, these impacts are going to delay us by x. So an example of a good associated dependency would be we need power and equipment startup complete four weeks prior to point to point which will take two weeks, then after point, the point we will require two more weeks for functional test. A bad associated dependency would be we need power and equipment startup complete to do our part. But that's often what we say I myself have been guilty of saying that to the contracting team. And then wondering why they were getting upset with me when I didn't communicate any expectations for them on what it would take for me to deliver and how much timeframe I needed in order to deliver. So I will often go and I will communicate all of this upfront. And then I will read through it. My notes, or process my thoughts. And I will send all of this information, as follow up in a actual email to formally confirm what was said, when I am looking at this email that I'm sending. And I'm thinking through it, I'm ensuring that I'm thinking about is there any vagueness in this email? What does complete mean? What timelines Have I given people? What expectations have I gone? and laid out? And are they clear? And Does everyone agree that these expectations are clear? It's really important that you get that consensus because it's much easier to handle a conversation. When you've previously had consensus, rather than a conversation where no one really agreed to it. They just were there and present. And then they miraculously forget what they agreed to post project meeting. So whenever I look at a request, whether it's a request to me or a request to someone else, I take these four steps and the four steps are step one, identify the Ask step two, communicate the reason for the ask. Step three, tie the asked outcomes that matter to them. And then step four, explain the outcome of not approving the ask. So step one, identify the ask, we need an extension on point to point Checkout, because we have not received power yet to our units. And because of that, we have not been able to begin Point to Point checkout. We had communicated previously, that we needed four weeks
Phil Zito 14:17
of point of power in order to get everything going. And then we needed two weeks to go and do point to point I'm just making up numbers here but you get the point. So identifying the ask is we're asking for an extension, communicating the reason for the ask, we just communicated it, tie the asked outcomes that matter to them. If we don't do a proper Point to Point check out, we're not going to pass commissioning. If we don't pass commissioning, we're not going to get certificate of occupancy. And if we don't get certificate of occupancy, all of us are gonna have egg on our face. So that is both the outcome As well as what could happen if we don't approve that ask. So some common scenarios for this situation are the no power, the equipment startup not done and it you're not present, those are the most common situations you're going to run into. So no power is simply tying back to the fact that we don't have power as soon as you realize that power is slipping. And you should be talking with the electrical contractor to ensure that you're aware of this. But as soon as you realize that is slipping, ultimately, any of these scenarios as soon as you realize they're slipping from their required date, your job is to notify your contractor in writing that that is slipping, and there will be an impact to your ability to execute. And then the remedy is to execution. The remedy is to execution are one delay, right? That's one remedy, you can just simply delay it until you get power. remedy two is a additive change order. For extra labor, this is assuming you can pull labor off your projects. And usually you you can't, especially during a busy season. So being able to pull labor off the project, you don't want to burn out your project team. So that may not be an option. So you would go and identify the ass that you either need to delay or you need a additive change order. And you would explain that and scenario two is very much the same equipment startup not properly done. And this can take place in kind of two aspects one can be it can delay you. And two, it can actually cause rework. So for example, you were told the rooftop unit startup was done, you go and you wire everything up, you start to check everything out, you realize startup wasn't properly done. And you actually have to go back and redo point to point in which case, you can actually have some additive change orders for the time that you have to redo things. As long as you're going and notifying the appropriate people that this takes place. It you're not present. This is a common one nowadays, it now that we're doing more IP centric control. And this is also a delay scenario. So most of the scenarios you're going to run into are going to be delay scenarios. Now this may seem rather simplistic, but I've used this on massively large projects. And I've used this on tiny projects. This approach works really well. But the approach is really dependent on proper expectation management from day one. So I want to recap real quick, and then we'll close off the episode. So to recap, we need to understand the project management triangle and the key interdependencies between quality, time cost, right. So quality, time, cost, and scope, we have to understand those interrelationships, we have to be managing expectations. And remember, expectations are quantifiable measurements for the delivery of scope items based on the current project schedule and associated dependencies. So we really need to get tight on that. And the best way to do that is to do a proper sales, to operations handoff, and then to do a proper Gantt chart and project management plan based on basic project management disciplines, which we will then share with the project team during the project kickoff. And then as soon as we start to identify shifts in our schedule, or shifts in our scope or any changes whatsoever that could impact project delivery. It's our responsibility to present that clearly to the project team. make that clear ask and then respond using email or some other formal method of correspondence so that the project team is now legally communicated to
Phil Zito 19:13
all right if you have any questions at all, please go to podcast that smart buildings academy.com Ford slash two to nine a really believe if you apply this you will start to find your communications with the contracting tier to be much easier. It will take the vagueness out of those conversations. It will really bring them to a level of quantifiable discussions. You're making discussions bait when I say quantifiable. I mean discussions based on data. So quantifiable is measurable. qualifiable is opinion. Oftentimes we're having discussions based on opinions. It's my opinion that you didn't do this right. It's my opinion that this is delayed because of you. That is a Very different conversation, then it is delayed because of x. And I communicated X to you on such date. And I also met with you to discuss our project plan on the project kickoff, and you agreed to that plan. And I notified you at time X, Y and Z of the delays and the ramifications of the delays. That becomes a very different conversation than just saying, Oh, hey, I was at the site today. And I realized we don't have power yet. We're not gonna be able to get this done unless we get power, which let's be honest, as the conversation most of us are having, we aren't going into this level of detail. But we need to Yes, this requires more effort up front. Yes, it requires more thought up front, and it can be a difficult habit to apply. But once applied, this effort on the front end is going to substantially reduce conflict and effort on the back end. Plus, it's going to let people know that you are a serious player when it comes to project management, they're going to know that you are going to be dealing with the facts and are going to be holding them to that same level of expectation and standard as well. And people in my experience will rise to the level you hold them to. So if your level of accountability to the project team is based on quantifiable data, you will see them rise to that level. I know that seems like really new agey and kind of goofy, but I'm telling you, the sooner you start to apply this kind of thought process to your project management processes, you will see better results. Alright, like I said, everything's available at podcast, smart buildings academy.com for slash two to nine. If you found this interesting, I encourage you to check out our VA s project management bootcamp. There'll be a link to that on the post. And if you're listening to this on the day it went live, I encourage you to take advantage of our black friday discount. It will be ending Monday, November 30. At 12pm or rather at 11:59pm that night. Hey, thanks so much. I look forward to talking to you in next week's episode. Y'all take care and I hope you had a great holiday.
