Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
E20: Is integrated planning possible in construction?
65 Plays2 years ago
In this episode, Jason & Carlos discuss why projects lean towards either top-down or bottom-up planning - and which is better.
They cover how lookahead plans fit into the weekly planning process and how this governs what actually happens on the project - as well as diving into the granular, daily planning underneath.
Is fully integrated planning a pipe dream, or can it really be achieved? Listen to find out!
Recommended
Transcript
Introduction to Episode 20
00:00:00
Speaker
Hello and welcome to episode 20 of the Offsite Podcast where we chat all things construction and technology. My name's Carlos Caballo. And I am Jason Lanzini. Good day, Carlos. How are you going? Pretty good. Thanks. How are you? How was Sydney? Sydney was good.
Carlos' Construction Site Visits in Sydney
00:00:15
Speaker
Sydney was wonderful. We got to visit, I guess, the context. Me and a couple of the team here, we went and visited a bunch of projects across Sydney across last week.
00:00:24
Speaker
It was really good, got to go out on site, got to feel like we were involved in construction again instead of just staring at a computer screen in my pajamas all day.
Workation Plans in Queenstown
00:00:35
Speaker
And then the best bit is next week on Monday I'm flying to New Zealand doing a workation for the rest of the week from New Zealand in Queenstown for five days. So that's about as good as it gets.
00:00:48
Speaker
Yeah, I could think of much worse places to be in the New Zealand. So yeah, pretty jealous. But a fun fact is, uh, there is a really cool, uh, like co-working space where you can like book out little booths and desks and rooms, like without being a member as a guest, uh, in Queenstown. It's really cool. If I knew the name, I'd say one of those. So next week's podcast, you will be live from New Zealand.
00:01:14
Speaker
Well, there was a time difference. So I don't know how, uh, how energetic I will be recording it. Like, yeah, but, uh, I'm not sure how fun I'll be. Yeah. We'll work it out.
Top-Down vs Bottom-Up Planning
00:01:28
Speaker
So today we're going to be chatting about something that's fairly sort of close to our hearts. It's also a topic that can fairly rapidly split a room when we're in terms of construction teams.
00:01:39
Speaker
So a little bit of context. Typically projects adopt one of two sort of core approaches to look ahead planning or short-term planning for the Aussies. And on one side we have what we call top-down planning and this is the theory of taking data from
00:01:57
Speaker
the schedule that planners own, the master schedule, and effectively distributing that to your sort of package leads, typically engineers, site managers, that sort of role. And then they own those tasks and sort of add detail. So they take that base structure from the planner and they break it down and add some more information. We then have bottom-up planning.
00:02:18
Speaker
And ultimately we're letting engineers, package managers, build their plans from scratch. We're not giving them this base level of information to work from. We're just letting them plan the package of works that they're responsible for and their closest to the detail.
Understanding the Planning Stack
00:02:32
Speaker
Jason, what's your experience with Australia? Uh, if you think about this at a higher level before a bit of detail.
00:02:38
Speaker
Yeah, so I guess if you step back and think about the theory of it or the reality of it as well, which is that I like to think of it as on most construction projects, it's almost like this planning stack. So these levels of planning. So I might start at the top where there's this master schedule.
00:02:56
Speaker
that like you said the planner's own maybe it gets updated once a month maybe once a fortnight once a week with maybe some contractual requirements that dictate how frequently that gets updated and they get updated from engineers providing input as to what the actual dates were and stuff like that.
00:03:13
Speaker
And then beneath that, that level of the planning, there is something that might be called like a look ahead plan.
Importance of Look-Ahead Planning
00:03:19
Speaker
Typically it's owned by an engineer and the plan will be weeks or months into the future. So it could be like some people might call it four week look ahead, but other people plan further into the future.
00:03:30
Speaker
Uh, there's usually sort of this weekly routine we updated every week. We have some sort of meeting about that. We coordinate across multiple, there'll be multiple ones of these look ahead. So each of the engineers will have a separate one. And then we'll coordinate that in a meeting. We might send it out to the project. So here's the updated shorts. And that level is really important because I think it's the one that governs most strongly what happens on a project day to day, week to week and what, what progress is actually made. But then there's another level beneath that, which is like.
00:03:58
Speaker
Okay, how did today go? What are we doing tomorrow? Haven't got the permit sorted for three days time. And that's sort of another level of this planning stack. And maybe it's a, maybe it's scribbled on a whiteboard, you know, like that big grid of things that go on a whiteboard. And so you've got this like stack of
Vision for an Integrated Scheduling Stack
00:04:15
Speaker
planning. There's this dream out there, like a lot of people of
00:04:19
Speaker
an integrated scheduling stack of like there's this one schedule and you can cut you know you can break it into little pieces and then people can add bits here and then that all rolls up perfectly back up to the top and um like it's much like the theory's uh nice there's benefits of you know people aren't reinventing the wheel
00:04:42
Speaker
at each level as it goes down and any information that's collected in that sort of as it steps down those levels can be rolled back up to the upper levels. But I guess to your question of you know what's my experience in reality it's like much easier in theories than in reality. I think there are lots of reasons why not only is it like hard to do in reality but maybe you wouldn't want to and not if you agree with that.
Complexity in Top-Down Planning
00:05:11
Speaker
If you just think of it from a completely logical point of view, taking away the dynamic of actual teams having to sort of manage this, it makes sense because you've got this sort of structure and coding and everything that comes with this information from the top down point of view that you're pulling in. Everything ties together nicely. It's like the dream world for reporting because you really do have like steps down information that's all tied together.
00:05:39
Speaker
We can't forget that lots of thought has gone into these schedules. So what you don't want to do is just scrap it immediately and then someone else replans it and the two are completely different. So I kind of get that side of it. I think if we think about top down first, it is complicated. When you see these schedules and you see
00:05:58
Speaker
a thousand WBS codes and like logic everywhere. I'd always say it's confusing like any engineer can think through it and understand what it's saying. It's a layer of complexity that is just going to slow down the understanding and your ability to sort of really grab it and roll with it because there's a lot going on, there's a lot of information, there's a lot of constraints and drivers and it's just naturally complicated.
00:06:22
Speaker
So I think it's really hard to really not just understand but really know your program if you're giving it from someone else because there's so much sort of going on but I can empathize with particularly planners and project controllers who really want to keep this set of data in line so you can actually do more meaningful stuff outside of the delivery
Who Handles Planning Complexity?
00:06:45
Speaker
team.
00:06:45
Speaker
And it's almost the inverse problem. So you get this problem around complexity, like you said, which is if the master schedule gets passed to the sort of look ahead plan level, then the person that picks it up to look ahead plan level has to understand all of the thought and stuff that's gone into that in building it up. But you slip it the other way around and you say, okay, if we don't have this sort of integrated approach, then
00:07:11
Speaker
you've got a collection of people building from first principles their plan for their part of the project without maybe a full understanding of other parts of the project and how they all sort of fit together and some person has to try and sort of work out stitch them all together.
00:07:27
Speaker
and fit them into that bigger picture. It's almost like it's a reverse. The complexity is just, it's like, who does the complexity live with? You know, you almost get in this like spot of, you know, who has to deal with the complexity. And it's really hard to argue against the planner owning the complexity because they are very experienced working within complex schedules and have the time to sort of really get stuck into that. It would be a very difficult argument to win saying that complexity should lie with the delivery team.
00:07:55
Speaker
trying to actually deliver the works. Yeah and the other way to maybe look at it is which of the sources of information is more useful to the other side in order to deal with the complexity and what I mean by that is okay if the complexity is dealt with by the planner at the master schedule
Challenges in Bottom-Up Planning
00:08:15
Speaker
They're having to deal with that complexity because their job or their goal is to understand, okay, what other construction team actually planning to build so that I can provide status updates and have the master schedule reflect that. So there's a need for that to happen regardless. And if you flip it the other way and say, okay, the engineer should deal with the complexity, they're being given a schedule from, maybe they're being passed the master schedule in this top downflow.
00:08:41
Speaker
which is something that was built by one or a handful of people at the tender of a project without the full depth and understanding of what actually was being built at the sort of granular detail level. And even the best person or team of people building that schedule is not going to get it right in many, many, many ways.
00:09:06
Speaker
And so you're saying, here's the schedule, which has got tens of thousands of lines in it and maybe a thousand WPS codes. And in order for us to sort of avoid dealing with finding where your work slots in on the other side, can you pass your way through tens of thousands of tasks and work out which ones
00:09:29
Speaker
are the right ones that you should break into more detail, which are the ones that are like totally wrong, which should be totally reorganized. There's like one, one is really important has to happen. And the other one is like, it's questionable about how much value it really adds, in my opinion.
00:09:45
Speaker
And so, yeah, there's like, I spend a lot of time thinking and I don't know whether you have a view is like, is the limitation of that top down thing where you pass it to the engineer, a limitation of like technology or technique, or is it more fundamental? It's a combination of things, but one of the big factors for me is the type of project.
Influence of Project Type on Planning Approach
00:10:09
Speaker
So civil engineers are used to planning.
00:10:12
Speaker
pretty well-equipped to build a plan and off they run, it's something they've always done as far as my career has gone anyway. If you look at building projects, they're not used to building plans. The planner builds a plan and most projects I speak to, they'll print the plan, distribute it, people mark it up with notes, give it back to the planner and they do their update. So transitioning building projects to individuals owning plans, they really do need the top-down approach because
00:10:39
Speaker
If you're looking at, let's just take services installed into an office.
00:10:44
Speaker
There's trades on top of trades. There's a very stripped flow and sequence or order of sort of things being installed. Trying to recreate that logic in independent bottom up sort of build plans is really difficult. So there's an argument to say it's a type of project. Technology could make it simpler. Like we could make it easier to pull and digest top down information to then build your plans without
00:11:14
Speaker
seeing the full whack of logic and codes and craziness on the screen, whether you're using Excel or any tool. Yeah, it's hard to really tackle that and make it as simple as the bottom-up approach. Yeah, what you said regarding the type of project is super interesting because I think my initial instinct was that it wasn't a limitation of technology and that fundamentally
00:11:43
Speaker
You more often than not probably want the engineers thinking through their plan from first principle so that they have ownership and accountability and understanding of the detail of the plan.
00:11:55
Speaker
I've had direct feedback that they really feel like they understand and are accountable for their plan and they can really get behind it because they built it from scratch. It's not something you're trying to sort of model together from a plan that someone else built. But what you also said about the type of project is true and probably you could extend that idea to the delivery model a little bit.
Subcontractor Schedule Alignment Issues
00:12:19
Speaker
And so if you're self-delivering versus subcontracting,
00:12:22
Speaker
There's an element of that in building versus infrastructure as well. Like a lot of building jobs are probably a little bit more subcontractor or a lot more subcontractor than infrastructure. And if I'm self-delivering a scope, I need to intimately know details, nuts and bolts, sequences. Okay, where's this coming from? Where's that coming from?
00:12:44
Speaker
Um, and you probably lean more towards a character plan for first principles, but if we're subcontracting, you know, maybe our master schedule is built up of subcontractors plans. And maybe I want to be more about tracking how they're going against that, that sort of thing and understanding what they're saying. They need cleared out of their way. So, so maybe it wasn't, you know, your point probably makes it not as clear cut as my initial thought. And there was probably some nuance based on the type of project and the delivery model for the project.
00:13:13
Speaker
Yeah, sub-contractors adds another level of complexity because
00:13:18
Speaker
your contract schedule isn't necessarily aligned to the subcontractor's schedule. So do you have this subcontractor writing the short-term plan? For them to take the top-down approach, they could just say, that's not my program. Or they could get stuck here and work in the collaborative nature that they usually do. So we'll leave that part of it for now because subcontractors, yeah, that makes it a bit more complicated. But to slightly flip it on its head, we've alluded to some of the benefits of bottom-up.
00:13:46
Speaker
through indirectly through the negatives of top down. So we're keeping it simple. Engineers really understand the detail because they built the first principles. If I was to ask you a question, if you bottom up plan, how do you know if activities are missing from single activities to sections of work?
Risks in Planning Approaches
00:14:04
Speaker
I think that's uh yeah this because I could ask the same question in the top down because you don't know I had this conversation internally recently because the same question was literally asked like a handful of days ago uh if I put my engineer hat on I would consider it probably infinitely more likely that the climate that was tendering the job four years ago sat in an office who didn't know the drawings in detail maybe the design wasn't complete
00:14:31
Speaker
know there's it's a much harder job for that person or team of people to not miss something than it is for the engineer planning from bottom up you know 12 weeks before they're going to deliver the work to not miss something and so then it's just a question of like do you have an organizational hierarchy that covers the scope of the job because planning is one thing but like
00:14:56
Speaker
Who's managing the design of that? If you're missing something in a bottom-up plan, you're missing it in not just your short-term plan, but you're missing it in all of your design. You're missing it in a lot of spots. So as long as you have coverage and clear delineation of what do I own, and one of the things I used to do when I'd start on a new project, and maybe I'm the engineer in charge of jobs, and let's pick a thing like superstructure.
00:15:19
Speaker
Well, first thing you do is you get out the drawings and go where does superstructure end and start and okay, everything then this, you know, balance is everything I need to organize. I don't think the risk of missing something from a bottom up approach is a good argument to push the top down. I guess I think it's more likely you're going to have more stuff missing from your plan from the tender than you are from
00:15:48
Speaker
You're short term by five that, you know, if you put your QS hat on, you've got the flip side, which is, okay, maybe it was missing from the tender, but who's whose fault is up that it's missing from the tender? Because if the engineer builds from first principles, they capture it, but maybe you just had stope creep.
00:16:06
Speaker
And you're now building something that you hadn't allowed for in your tender because the engineer's plan for like, Oh, this is on a drawing. I'm going to build this. I think you'd really stick around with the statement that there's more chance activities are missing from the master schedule than a short term plan.
00:16:22
Speaker
When you say split a room, when you say split a room, what you mean is you'll have like a hundred people on one side of one person on the other. Is that what you mean by split a room? That's just because that's the distribution of engineers versus planners. Okay. I guess the other, the other aspects that came to mind is how does the planner update P6?
Updating Master Schedules with Bottom-Up Plans
00:16:43
Speaker
I shouldn't say P6, I should say master schedule. P6 Asteroid MSP off the back of
00:16:48
Speaker
bottom-up plans. Okay so first they open up their computer and they you know they have to do that thing where they like wind their feet to start their computer and then they open they open Citrix or whatever to go get a coffee while that starts up. But yeah so once they finally make it in there I think the way that I would do it
00:17:09
Speaker
And the way that I see a lot of projects do it is rather than strive for one-to-one relationships between every activity in the engineer's short-term plan has to relate to something that's in the master schedule.
00:17:25
Speaker
um that there is clear grouping of those things either ending or you know grouping in the way that maybe that relates to some sort of structure in the master schedule whether it be like the WBS or that those things end in a certain set of milestones that are clearly trackable back to the master schedule. I would probably
00:17:45
Speaker
lean on the milestone approach because it's very clear cut for everyone. So set out a bunch of 20, 30, whatever it is, key dates or milestones that you want to plan to have engineers build their plans up and link those things to those milestones and then track those milestones week on week or week a week and use them to relate back to what, um, what we're going to show in the master schedule.
00:18:10
Speaker
I had the same note, which is, yeah, pulling in milestones, really simple and effective way to keep on top of these things. But is that a hybrid? Is that neither top down or bottom up, or is it a sensible bottom up approach? Yeah, I think bottom up with some control because bottom up with no control is, is like overwhelmingly complicated to keep track of. You know, if you have 20 spreadsheets, each spreadsheet's in a different format.
00:18:35
Speaker
Each one uses some sort of arbitrary grouping. The milestone that you think you're updating lives on three of the spreadsheets, you know, that sort of thing where three people think that each got that milestone in their spreadsheet. Which of the three spreadsheets of the milestone are you updating?
00:18:51
Speaker
So, um, simplifying down to one version of that short term, final one space where that all leaves for sure helps that problem. And I would also be pretty strict in the structure of those plans. So just avoiding the messiness of, okay, as a planner, I get six spreadsheets. Three of them are in one format tour in another and ones like a different format each week.
00:19:20
Speaker
or something like that. So I'd be pretty strict on, okay, here's like a hierarchy of groupings. Um, you're going to put your work in that sort of hierarchy of groupings. You're going to link these things up to these milestones and then what, you know, everything else is up to you. Yeah. Um, that's what
Conclusion on Planning Approaches
00:19:38
Speaker
I would do. Okay. So
00:19:40
Speaker
I'd only said gun to your head. It'd be the weirdest gun to your head moment ever. Gun to your head. Is that one person in the room again? Top down or bottom up, you're a project manager on a project. What are you going for? Wait, I'm going back to your point before. What type of project? One symbols, one building, sorry. Bottom up, both. Really? Cool. Have you ever managed a building project before? No.
00:20:12
Speaker
Nice. A dog with a limited set of tricks. I just like a hammer looking for nails, you know? I agree with you on the civils. I gave bottom-up all day. They are already people that can clan, so it doesn't make sense to just switch that out. I don't see enough benefit to change that to top-down.
00:20:37
Speaker
Building, I think you have to go top down. I just don't see how you can deal with the logic with bottom-up planning because in most cases that I've seen, there's literally like some of these projects is like so many supply chain members on site at the same time. I just don't know how you could actually do that from a bottom-up approach and get to some outcome that isn't 5X in your end date.
00:21:00
Speaker
So I think you need the real sort of efficiency of LogicLik program from the master schedule to be the basis there and they're just simply adding detail and following the plan.
00:21:09
Speaker
The other thing that's really interesting that I would be doing if I was running one of those projects is, so putting aside, like, obviously using our product, you can automate a lot of this recording and you can, you know, let's not, let's not do that. But like, I guess what I've seen on, on previous projects going back to my idea.
00:21:32
Speaker
uh, standardizing those, whether let's just assume it's a spreadsheet right for the look at. So we've got, you know, X number of teams, five or 10 teams. What I've seen work really well. It is a standardized spreadsheet that each team uses to update. There's some sort of restrictions on the sheet to avoid all sorts of chaos getting in there. Uh, I know those sheets get saved to a SharePoint file. Uh,
00:21:57
Speaker
and then someone much cleverer than me does the old macros thing where there's a sort of report sheet which will pull those things together and then tracks the variants of like the milestones each week so the climbers have got this sort of one spot that they can look and the engineers have their places that they can update which again obviously is what exactly what AFX will do but we're not doing the pitch though.
00:22:22
Speaker
Do a pitch and I'm doing a pitch. That's the title of the episode. Yeah, that was indirect pitch. Good chat. Pretty sure that's all we've got on today. We've burnt through that pretty quickly. So thank you very much everyone for listening. Thank you.