In this episode of the Project Chatter Podcast, Dale & Val talk to ALICE Technologies VP of Product Dimi Farmakis about "Why CPM fails and what comes next". What is the Critical Path Method? Why does it fail? What alternatives are there to CPM? Find this out and more as we explore what is possible in this episode...
Watch the video
And if you'd rather read, here's an auto-generated transcript (accuracy not very high):
"Welcome to project chatter, the podcast where PPM experts from various sectors talk about the latest trends. Listen to Val and Dale as they talk about tried and tested best practices and share their unfiltered thoughts about the industry. Whether you're here to learn how to progress your career, improve your project control skills, or just want to hear an Ozzie and south African branded out projects.
Then you've come to the right place. Welcome to the project chatter podcast with your hosts, Dale Foong and Val Matthews.
This podcast is brought to you by inEight we hear it from our podcast guests frequently. Today's capital projects require the highest degree of visibility. That's why we had the project. Had a podcast. Want to tell you about construction project management, software from inEight software that integrates every aspect of your project and puts you in control know it's cloud based solutions provide a connected data flow that improves efficiency and guides, better outcomes across the entire project lifecycle
see what inEight software can do for your next construction project. Learn more at ineghtdot com. That's I N E I G H t.com. This podcast is brought to you by plant academy. Plan academy is the world's leading learning site for anyone working in construction, project management or project controls. I plan academy, you learn construction planning and chiseling theory.
How to master scheduling software like Primavera P6 and even advanced construction scheduling techniques, then academies courses are a hundred percent online and at your own pace, you can learn at the office at site from home. Anyway, get $75 off any plan academy course by visiting plan academy.com forward slash chatter that's plan academy.com forward slash C H a T T E R.
Hey, everyone. This episode is brought to you by just two.com. Just do as a great business and project management tool we've been using here at project chatter. I agree. Well, I like to keep things simple and just do is perfect for that, but I do know it's got a lot of powerful functionality as well, and one of my favorites is the task specific chat.
Absolutely. And for all you, slack is don't wait for Monday. Check out, just do.com now on with the pod. Hello, project people. You're listening to the soothing sounds of the project chatter podcast. I'm your host, Mr. Val Matthews. And as always, I'm joined by my cohost. Hey fel. Hello everyone. I hope all your listeners are doing well.
I think today's pod is going to be particularly spicy and thought provoking. So let's well spicy. I'm looking forward to it. It didn't I'm going to Del and just to listeners to hit that subscribe button on whichever platform you listen to your good podcasts on. And I forget our YouTube channel for the full podcast and our guests bonus bits and Q and a.
And if you'd like to sponsor the project podcast, you can, you can get in touch with us to fire our website, project chatter, podcast.com, but let's get on with it. So in this pod, we are joined by Dimitrios or Dimmi for Marcus from ALICE technologies. And he's going to be talking about why the critical path method or CPM fails and what comes next.
Hey Demi, thanks for joining. Hello everyone. Thanks for having me. I appreciate the chat. Before we get stuck into the content and the context of what CPM and what's next here is Dale with Demi's bio as well. So Demi is the VP of product at Ellis, where he works on revolutionizing the construction industry with integrated processes and artificial intelligence.
So exciting already. That's just the first sentence. Jimmy has been heavily involved with Ellis from the early days of R and D working on product prototyping and beta testing, as well as leading customer success for two years, as a lecturer at Stanford university and TEDx speaker also lends his expertise on the benefits of sustainable building design and boom DME holds a master's in civil and environmental engineering from Stanford university prior to LSE founded Solvia studio.
I pronounce that correctly and boom consulting services in. Greece. So welcome. Dimmi as well said, it is a great pleasure to have you on this pod. I guess first off Greece, w you know, you've traveled the world a bit from Greece. Where did you go? So from Greece, I, I went to UK for a year for my previous master's in operations research.
And this is what UK does to you. You can hear it, my obnoxious accent. Then I, I worked in the Netherlands for a little bit doing some operations management, and then I was like, what the hell? You know, just, you know, switch domains and go to Stanford and do some civil engineering. Before that, I was more on the business operations, operations research, and optimization side of things.
So a lot of quantitative stuff still, but not civil engineering a. I traveled quite a bit with SALICE because before doing that, I, I was doing everything like in every other stop though. And at some point I was heading our customer success department, which required quite a lot of traveling because I was implementing our tool around the planet, various types of customers, very various types of projects.
And fortunately enough at various locations in the world right now, especially due to COVID, I don't travel as much, unfortunately like everyone else, but, you know, thankfully through technology we've carried asleep, travel, you know, various areas, you know, chatting to two chaps like yourselves all around the world.
So trying to get by with a substitute here, No, you're right. It's it is a strange world we're living in and hopefully there's some light at the end of the tunnel with the, you know, the vaccines and things that are happening today, but it would be remiss of us not to mention the 40 construction group guys and you know, special, thanks to James DJ and Chris you know, for putting us in touch because you know, they sing your praises and you've got some fascinating and amazing technology at ALICE, but and we'll touch on that, but we're more but remote after understanding why the critical path method fails, because everyone's probably thinking, what the hell, what, what else do I do?
I mean, surely it's the critical method. There is no other way. It is exactly it's the backbone. How can you challenge that? So I think it's going to be a really, really exciting one just before we get into why it fails. Can we set a baseline, you know, we love baselines in the product world. In your words, to me, what is the definition of a critical path method?
So a tough question. The, the main ingredients the loss of a better word are the following. Part of it is the theory or the science behind it. Like everyone knows, you know, forward, backward, pass the network diagram of free flowed, earliest star earliest finished, latest star, latest finish, you know, all the John fondel related theory.
But for me I'm, I'm, I'm being a bit obnoxious by being, by having the tendency to be a systemic systems thinker. So for me, it's not just the theory behind it or. The tools whether you call it PCX or Ms. Project or spreadsheets, or what was the other thing that's smart, smart sheets is one of the latest trends.
But it's also the system around it. You know, how the data communicates between the different disciplines, how these different disciplines collaborate you know, communicate and so on and so forth. And to my limited knowledge so far, the critical path has been, I guess, the cornerstone of all that system.
Like especially when you're talking about, you know, project planning, durations and risk management. So I guess this is a baseline for me. This is, this is how I would package what you call like the CPM, like world.
No, no, I, I think that's a, that's a great definition. You know, it's, it's in simple terms for those that don't understand project management or schedules at all, for me, it's just you know, what is the quickest path through your project schedule, right? Yep. But that is conventional planning, right?
That is conventional planning. And I guess we could go into that as well. What is conventional planning? And I don't know if there's actually a definition for conventional planning and may and maybe. Yeah. And maybe this is why it fails, but anyway we'll leave the debate out there because I have heard, and I think we mentioned before that, you know, us controls people and include planning in there and risk.
You know, we've been compared to plumbers or electricians. And so you'll go in and you'll look at someone else else's schedule and you'll go, well, why did they do it like that? Why did they plan it like that? There's a logic, the million dollar question. Exactly. So perhaps there isn't a standard way of of planning because it depends who you are and what your experiences are.
And so this is probably where technology comes in, but I, I don't want to speculate. I want to hear, so why does the critical path method fail? You know, if, if I can schedule out my project plan in the traditional ways and let's say their waterfall ways and I can get my fastest path through that. Why does it fail?
Before we dive into the details and we started fighting and, you know, going back and forth let me try and let me try and I guess make a poor man's effort off, you know Shedding some light on defining the conventional planning. Let me mention first off, I think it's extremely interesting that you chose the word planning and not scheduling.
And I think this is where this is where the essence of conventional planning or scheduling make your, make your pick, like realize. And I think this is where, or one of the cornerstone aspects, why CPM fails because in today's world, a lot of professionals and companies, they don't distinguish between the two.
Like there's a, what is the difference between a plan and a schedule? Right. And as you know, probably much better than me from your experience, everyone's says dives into the schedule, everyone in like let's create a schedule, let's open up our tool and start drawing precedence relationships. However, there is a distinct difference.
The plan is essentially, you know, a list of activities, basically what you need to do in order to build this project you know, with our relationships you know, production rates, you know, all the data that goes with them schedule is essentially assigning start and end dates to those activities such that no constraints are violated.
There is, there's a difference between the two, because, and this is, I guess I can, I will use this as a segue to start, you know, the debate about CPM. Yeah, this is, I guess, one of the cornerstone aspects white fails because the plan essentially encompasses all the rules, all the assumptions all the thoughts process that goes into like Manny making a project into a reality.
But when you are like throwing it out of the window and you're like focusing solely on the schedule, things start becoming unclear and fuzzy. You can inform what if analysis, because you don't really know what your assumptions were. And secondly, the rules are unclear. Actually, you already mentioned that, right?
You looking at someone else's schedule and you're like, scratching your head. You're like, okay, why did you do it this way? Or, you know, and subsequently it's difficult to assess the impact on metrics because it's very difficult to like change things, right. You're presented with a rigid snapshot of. Of reality, you know, which might be great.
I'm sure there are like many, many competent and you know schedulers and planners out there. But what about all the other stuff that can happen? Right. So I guess the first reason for these debates about CPM is that there's no transparency. Everything is modeled through precedents and the scheduler or planner is tasked with something that I think is a bit inhumane.
They're trying to model all types of constraints, whether it's, you know, the resource limitations, physics, space, calendars, whatever it may be, material deliveries, they, there are tasks that like model all those different complex stuff, all be through precedents. So when someone actually, once I'm on outside the SAS side, the scheduler.
Tries to ask questions, or even, even a lot of times when the scheduler needs to communicate their schedule, you know, it's very difficult to have a, let's say, meaningful discussion or call discussion, not being feisty about it, like about yeah. What does, what does that arrow represent? Like why did you draw that relationship from eight to B?
Is it because you were thinking about the crane availability? Was it because, you know, there was a physical sort of thing. And as a result, as you may already understand that makes it extremely difficult to identify and align on what the real bottleneck for the task is. You know, whether it's a delay or not please feel free to chime in by the way either was flattering.
Another reason is CPM the, the way of the approach there. The approach itself, like presents you with only one option, right? There is a competent professional who is trying to wrap their heads around these. Like, as I say, inhumane complexity, that construction projects present, and, you know, the times we'll come up with a way to like, make this happen.
What about all the other ways? You know, what about all the other sequences I'm as I'm sure everyone knows, you know, there are like thousands of ways to build something. In one of our, like in one of our like heaps, the Atlas presentation slides, we basically present that there are like 35 pounds to build a box with some very, very like simple assumptions.
So you can imagine how much that number, you know, like skyrockets when you're talking about like complex projects. So we talked about transparency. We talked about sequence. What else is there? Yes. So for me, as I said, the, this, this kind of delves into the system of the whole thing there's no there's no integration.
So as everyone knows, in order to make sound and informed project management decisions, you need to think about three things, right? You need to think about the work or the schedule, the work packages, the WBS, call it, however you want. You need to think about the scope. In other words, the design, basically, what do you need to build, but also the cost.
So in the, I don't want to call it the CPM world. So I'm going to call it the conventional world. As you know, these three aspects are siloed, you know, they're, they're not like connected to each other as a result, you know? And I'm sure you guys probably experienced it. It's very difficult to Have a clear vision, visual, sorry, clear visibility into how these different interrelationships work and what is the impact and how does the impact cascades to the other system.
In other words, it's very difficult for your project control systems to accurately represent what is really going on in your project, both during planning, but more importantly, during execution, right? Yeah, if we just jump in there I just find it fascinating when you, when you mentioned planning versus scheduling and we've had this sort of discussion before about the differences and what it means, and we've been provocative about, you know, how the schedule is just a piece of jockey, really for the most part.
And you know, we, we just discuss how we've always, we always somehow seem to upset someone on every pod that probably listens to us, but that's okay too. We're here to disrupt a little bit. But I think the things that pop up, if we just pause and just think about what you've just said there, one thing is I I've experienced this and I'm sure you all have on the call as well.
I've got, I've often gone in to a new project set up and I've seen the schedule and I've said, well, okay, so you've got an integrated schedule. Where's your integrated plan? Where's your imp. And they're like, what do you mean. Exactly. And, and I think that's, that's what you're referring to. It's how have you brought everything together before you've just jumped into a Primavera or a Microsoft project, you know, any other tools, script, scheduling tool that you're talking about.
And so I think that's fascinating because if we just pause and think about that, a lot of people don't appreciate that. There's a key difference there. And the fact that you highlighting it's still today is, is, is quite a standing. If you think about it, because scheduling and planning have been well, they symbiotic, but they're also separate at the same time.
Right. And it's been around for such a long time. Yet you go in and you go, oh, there's my planner. And you know, what did, what does he do? We put stuff into . Yeah. Okay. So. And, and part of the problem we spoke about this is one education, and this is why we do things like this, the podcast to share that, that insight, but to.
I just think that the, the, the, the desire and the pipeline isn't there. So, so people inherently in the organizations that exist, they're not trained in the correct ways. And so they only know what they know. So you can't really blame people as such it's, it's our system that we work in our industry that we haven't done enough.
So I just wanted to pause and comment on that, but also just to bring velvet in there, Val, I know you've got quite a lot of thoughts on this. We had a debate in episode 30 in season two around you know, Is there anything better than the critical path method? And we had a whole bunch of painless experts and we struggled a little bit, but fell.
Yeah, jump in. We did, we did. And that there is, there is, I mean, there's elements where it does work. I mean, I know defense, you say integrated master plan, they do have integrated plans. But we're always saying, we are saying this, I think we're inferring at least that critical path method. Isn't going to get you accuracy.
Because it is a model, it's a representation of everything that's put into it. And we've, we've challenged this before where it's, it's actually about the quality of the inputs. So even if you decompose your, your scope, if you resource it, if you labor it up, if you thought down all your assumptions, if you limit all your constraints, if you calculate all the risks you, you get a representation and you write it.
There's not one. Scenario a there's multiple scenarios. It's kind of like a multi-verse, but we don't think in terms of dimensions, when we talk about planning, we tend to think about this in this two dimensional space where you have this flat Gantt chart and that somehow afforded in a backward pass is going to give you your early and late start dates.
So finish dates, which in fact, it's probably the most primitive way to report on a project because projects are getting bigger and more complex and more complicated. And so how do you do it? And I think this is where we start talking about technology. It's like, there's a point in time in which. No humans are at their limit in terms of capacity, right.
To understand, to comprehend, to calculate. And we have to bring in machines to help us. Like we can only run so fast. So we created it, but now we've got a car and a, if we want to compute, you know, we needed a computer. So now we're getting to that point where if we want to plan, we need a planning machine to, to provide that.
So I'm not convinced that a critical path method is the best way at all. I think a lot of people are holding onto it because it's the only way they know. And in the absence of a red line, in their schedule of what do they do, where do they go? It would, it's a very disruptive nature to think that if you removed the CPM.
You really have no benchmark at all. So you leave all these industries open, and this is the hard part about changing people's minds. Hearts and minds is all our projects are about is how do you then get them to the next solution? And we haven't gone into the next solution yet, but how do you wean them off critical path method and bring them into the future?
And I'd love to talk about that for a minute. Oh, absolutely. So I really I'm really fascinated by, by your perspective, both of you because truth be told we are encountered with those friction points, like in every customer engagement with Atlas. So to kind of like take a step back and build up on your, on your points I, I wouldn't, I even my, I wouldn't put the blame on the professionals either.
I think he'd say systemic fallacy, that governance construction with, which has to do with the fact that if you think about the construction process model is, is rigid and siloed. You have a design, then someone takes that design estimates, the cost, and then someone takes these costs and resource information and tries to build a schedule around it.
Right. This is very rigid and like, it doesn't allow for exploration or, or anything to that end like technology and, and methods and systems definitely help. And this is this is actually something that, you know Alison angles, right? With I'm, I'm not gonna to talk about tablets. So let me generalize or abstract a little bit.
So model based systems. I'll allow by modal. I'm not referring to the casual, architectural, 3d model. I'm talking about, you know, simulation models here, you know, models that allow you to build, you know, every presentation of reality, mess around with it and gauge reactions from it and learn from it. Which is a similar system, like like how this technologies is using So that's models trans immediately with the approaching itself, transform the construction process model into something dynamic where everything is in one place.
And you have a clear mapping between the three cornerstone aspects, right. Design costs and schedule. So that is the systemic aspect of things about the organization, the organizational aspect you mentioned. Oh Jesus. So yeah, I mean, in all honesty I think organizations organically have reached similar conclusions that look, we need to change the way we do things.
But what is the first step towards that? I call it next generation builder. Right? How can I make my company the next generation? You know, GC or the next generation developer, whatever, whatever you want to do to that end there are some very specific adoption barriers that need to be overcome.
I'm, I'm going to try and be very, very succinct or more simplistic here. One is the operational model of the organization itself. Like the processes need to change the data transfer and communication and dissemination needs to change the communication channels need to change. So I'm, I'm honestly, I'm talking about organizational restructure here.
And the second thing is, or let me not number because, you know, I might, I might go a long way, but another aspect is the culture, which I think both Dale and Val, like both of you guys, like sort of like hinted towards As everyone knows. It's scientifically proven construction is a very risk averse industry.
There are multiple reasons for that, but to try and stick more to the human aspect I agree with you partially. It's the only thing that people know, so it it's naturally difficult for them to deviate from that. But I'm going to, I'm going to be a bit provocative here. Like perhaps reluctantly it's the politics, right?
Like we've been, we've been encountering that thing with ALICE, like many, many years now. Right? Yeah. This is a bet to schedule. I'm not going to do it like, Y like initially, like in the first year we're like flabbergasted, like, what are you talking about? Like, and th the reason was like a, Cato's like a lead brick, like, because.
Because if I show my boss, my PM, my owner, a better schedule, I might get fired because they might tell me why didn't you come up with it? Oh, is that the consensus? Is that the feeling that there is it? I would think so in the sense that, you know that professionals feel that, you know, and I, I totally understand them to some degree, to be honest with you because it characteristic of a model based parametric system, like, like we have is transparency.
So there's full visibility and transparency in the assumptions, in the data, the quality of data you're putting in. What, what are you assuming? So I guess the consensus is to, to place it, to position it more accurately that. That transparency is stressing people out with. And also it needs a big shift and I'm not going to like deviate any further, but sticking to the organizational like spectrum.
It's a, a big, big difference. A big, big difference is made through the company vision. Like one of our earliest customers with ALICE, obviously I cannot say names, but one of the earliest customers in Alice who like onboarded with us like three years ago, you know, and I can tell you the product had a huge, huge difference.
So technology wasn't a decisive factor. The reason they did it was very simple. They wanted to become the, the most advanced developer in their geographic region. That was their vision like, and he came top down, like from the CEO. Like it's disseminated throughout the rest of the company. I can, I can keep on going.
No, no, I was just on that point, which is why you get into the next point. I think you're right on the, we've had this conversation, Dale haven't we, when we talk about the organizational breakdown structure, not aligned to the workflow. And so you have these super structure, organizations, silo doing their own thing and getting away with it.
And what it does is it actually infects the rest of the business from having any kind of planning, integrity. And you try and stem it as a project controls team or PMO team, you try and get in there and standardize the works. But from that point on in particular mega projects, you can see, it gets very complicated because now you've got disconnections between what was real and what was inferred and what was guessed.
And there's no real basis of where this information is coming from. But I really like the two points you mentioned before as well, around transparent integration. You touched on culture, which dialogue again, we super agree. And I'm going to go out on a little bit of a limb myself and just go direct to plan is any plan is the schedule is listening.
Hear me well, evolve or die. You'll roll. Is it as good as you'll value? So you need to be watching the trends in this area and companies like yourselves Alice at DB there's end plan as a few other companies out there in a, we know these companies are. One of leading pioneering in the construction space, pioneering in this machine, learning space and new ways of thinking about planning.
I can't, I can't fathom for the life of Mandale and I have this frustration sometimes with resources, both in Australia and the UK. It's like, you know, your job is not at risk. But the way you do your job is. And that's the same for everybody. Software is going to be disrupted. Technology is going to disrupt every single industry sector you can think of.
And it will happen at different times. As we know it will be staggered. And politics is slowing that down. So we there's a thing called the digital adoption index. So I don't know if you've heard this and Australia is in the stall out quadrant, despite having all the beautiful luxuries of a developed nation and all the fancy tools you can think of.
We're stalling out. We're not, we're not adapting to change at a rate would be acceptable or going to compare to other developed nations. And the reason I think is larger. And what you referenced is about resistance and politics and company culture is not being driven from the top down. I think it has a huge part to play in how you, you get on board with advancing digital urgency.
We have to be adaptive and it's, it's kind of counter to human nature to do that. Isn't it absolutely like. Professionals need to know why the leadership both in the organization, in the particular organization, but also in the industry needs to explain why. And you did a very nice, I guess, segue to that, like explain why their roles need to change because they there's a, there's a whole redefinition like endeavor here.
I it's redefining new roles sort of redefining existing roles, but also defining new ones so that these new integrative processes can be supported. So that's sort of like, at least in my in my simpleton head follows like the three ingredients, like people process and technology, that order, if people do not understand why, and they will not follow the process.
And if the process isn't there supported by the people, no technology can enable it. And. I guess the tail-end of what I had in mind is under this whole, like the restructuring thing is it's. If I was asked to like pinpointed, you know, a bit more specifically it's about the decision-making process and model these organization views right now, it's, it's very, as as we sort of like mentioned rigid and very centralized, like the PM needs to approve a lot of stuff and everything which creates decision latency.
But so unless that decision-making model is not, does not become decentralized, I reckon my humble opinion is it's going to be very difficult to ingest, to inject value engineering into, into the whole scheme arrive. Yeah. So yeah, this is my point. On that point to me, I think, I mean, we've, we've, we've kind of gone into the, I guess the, the structures of, of, of modern day projects and their challenges.
And maybe we could talk about the comparative now. So you said critical path method. We said what's what's next. So if it's not critical path method, what's next, can you explain maybe some of what the comparative is to the new solution and, and why that would be a better option for those on projects, if that's absolutely.
Yeah, yeah, yeah. My humble opinion. Model based approaches model based decision-making because at the end of the day in construction, everything is about decisions like probably more so than any other industry. And to your words, it's about how you make those decisions. It's, it's not really about the decision itself because simply enough things change.
So whatever decision you make now it's bound to change. So it's, it's about like the approach to making that decision. AI definitely supports, you know that, that new system or AI, AI powered technologies and ultimately all these, like in my mind, sort of like have the S the, the same cause, which is control, controlling the risk, controlling the variability and being able to.
Like I, I use a, a simplistic analogy here, peel the onion, like okay. Everyone sees there's a non-owner here and you know, it smells, but you need to peel it to see, you know, layer by layer to see where this is coming from. Why was it done this way and so on and so forth? This is I guess, a a short version of my answer.
Yep. So, so the, the idea then is, is to provide cause it's about making informed decisions, right? It's about bringing in as many scenarios as possible through. Scenario models is that you're saying and other factors, and then I wouldn't call them going. Right. And then allowing them to make informed decisions with more information effectively.
That's that's the end goal. Exactly, exactly. Precisely. It's about making that shift from experienced based decision-making through data-driven decision-making because today this is that juxtaposition, right? That today the decision the decisions are made based on who slams their fist, how they're on the table, who looks the scariest, or who has the loudest voice weights by the way, let me try something here.
Experience makes a ton of difference and experience the aspect of experience into this whole universe where like discussing will never go away. And let me tell you why, because. All the output of all those AI engines model based systems, so on and so forth needs to be reviewed. And the main filter for that review is the experience like only an experienced superintendent planner project manager can look at a, you know, a computer generated output and be, I dunno excuse my friends.
This is bollocks. This works, that, that part, you know, we can keep and so on and so forth. So it's as a result it, it becomes an iterative process of learning. This is, to me, this is actually a huge problem in construction that the new technologies like AI engines and model based systems can, can literally solve it's about the reuse of knowledge.
First off allowing you to capture it in modeling the constraints capturing the rules in your simulation and so on and so forth, but then, and perhaps more importantly reusing it because as you're going through these exploration, you're learning your your intuitive understanding of what really matters for your project, where the real risks rely, it increases.
Hmm. That's fascinating. I want to go down a bit of a rabbit hole cause we love rabbit holes on this podcast. So we chatted a little bit about how roles will change. And so I was thinking, okay, if I'm a planner or engineer, project manager or controls person, what will it look like? Are those roles going to be molding into one.
In your opinion Dimmi would it be a case of I'm not going to sit with, or maybe it's all three of those people, but in very much more similar roles. And we, we spoken to Steve wake about fusion skills rather than having these sort of, you know, specialist roles. And isn't a host of it's a panel perhaps sitting around the same software model as you calling it with their different inputs and experiences, also drawing on what AI and machine learning is giving them to make these informed decisions.
Is that what it looks like? I definitely agree with the panel aspect because there needs to be collaboration and many so that multiple voices from many angles and disciplines are heard and molded into a, an aligned decision. Which as you, again, guys, you already know this. Paramount factor.
Why a lot of schedules are not being followed in the field because the superintendent goes, it looks at the schedule and they're like, what is this? Like, I feel this way. And the scheduler, like, again, as you guys accurately brought up earlier, get so offended because like, no, no, no. I make the schedule.
I used all these man hours to do it, like going through it this way. And the guy is like, no, mate, you cannot build like that. Like why, why didn't you bring me in earlier? This, this is I guess one of the million dollar questions. Like, why didn't you bring me earlier? So I definitely agree with the panel aspect about roles.
I, I think it's going to be an amalgamation of two aspects. One is some existing roles we need to evolve. For example, the, I see personally the planner and scheduler transforming more into a. And model analyst, if you wish, basically the person who is going to look at the model, assumptions, validate their soundness and also reviewing the results, you know, like the output of the model.
I see on the, on the same, same note, I see also at the patients and changes through some other existing roles. Like for example, you know, the project manager might become something like a model coordinator, essentially, you know, specifying what these bloody thing is intended to do. Like, because like a lot of this I'm gonna make, I'm gonna open a bracket here.
A lot of I think a useful analogy that, you know, might help people. It helped me, but hopefully it's gonna help others is look what happened with BIM, like as an adoption, right? At corner, a cornerstone principle have been, has been. Purpose based modeling your bill, been based on what you want to get out of it.
You want to do energy analysis, you will need to structure your model differently. Do you want to do it for structural analysis, need different type of model. And everyone, like I think is experiencing these like limbo in a GAAP over the correct adoption in BIM because they're using the architect's model, basically for everything, same notion in my humble opinion, applies to the construction models or the scheduling models as we call them at Stanford.
You know, you need to specify, you know, questions and objectives. What the, what do I want to get out of these of these parametric model of the schedule model? So I see, you know, these manager management type positions, like evolving to these types of roles, like model coordinator and everything.
I see also noodles coming up, so model development. So these technology, you know, needs meet someone to sit down and like build all those constraints, input the data to the system, you know, like make it all happen, like build the model. I am given, you know, the polls and, you know, some reactions we've seen, you know, with trying to get companies to adopt our solution is.
That role can be very easily taken on by new professionals. So Dale, you're a very experienced scheduler and planner. You've been building, you've been doing a lot of stuff for like decades. Why spend your time building constraints? Why spend your time, you know, setting up simulation models, spend your time to think strategically and critically about, you know, those models and their output.
So it, it was, it was really fascinating to, to see the difference in the reaction and acceptance between experienced professionals and literally students like with experienced professionals to your period, your earlier. Arguments. Like, why are you doing it this way? Does it CPM or PCX or Ms.
Project does it that way? How can I do that thing? And you're like, mate, it's different. It's like apples and oranges. They're both fruit, but they're different for it, but they're so that the reaction vastly different as compared to students who don't do not have these mental model biases, if you will, and you show them something like, like Alice, like a parametric model system.
And they're like, ah, it makes sense. And then we're like, okay, lads, this is how things are. If you go out to work today, this is how things are done. And they look at us and they're like, why you're asking too much, let's move on. But Yeah. This is my, my primary thoughts from the, on the map. No, that's great.
That's great. And I wanted to also bring in another aspect as well. So a lot of commercial aspects contracts are set up based on you know, critic path float, you know, who gets compensated for one, when things shift, does it change the nature of our contractual setup now going into the future? It might be in the sense that I, I see moving a lot more towards alternative delivery methods because of the, because of that exact reason, right.
It allows for a lot more flexibility and risk control earlier on. So everyone's happy. The GC, you know, has more room to protect and hopefully increase their profit margins. And the owner is going to be happier because they're going to get a higher quality product at the end of it. So this is an, and I think that will be greatly enabled by the transparency of these model based systems.
Because again, I was a good guy, you know today the owner has to like pull together, you know, like committees and construction team, like reviewers and all this kind of stuff, because they, they don't trust like whatever the GCs like giving them. Right. They, they scrutinize it. And why is this? And why is that?
And what about this? What if this happens? You know, throwing all those curve balls. So in the future, I think the Project delivery methods are going to become a lot more fluid closer to what we currently experience as, you know, alternative delivery methods. I I'm hopeful that, you know, IPDs will become more of a norm.
But that also, you know, depends on the design activate, right? Like the correct adoption of BIM so that you can integrate everything like on no, that's fascinating. And if I just may carry on peeling this idea a little bit more layer by layer. Are we then saying that we might get to a stage where we can 3d print buildings or are we going to get to that stage where we don't need construction workers?
Because it's all been worked out by computers and you know, it informs the machines and that they, they build the buildings on our behalf. I'm sure there are many advocates out there you know, in favor of that. I'm not one of them. I think as I, as I mentioned the experience and the human aspect, I, I think it will be a big loss if it's taken out of the equation for construction.
And I'm going to make like a powder realism here with artificial intelligence. And hopefully I'm not being too provocative, but I don't think artificial intelligence is the key. I think augmenting current intelligence is the key. Because as, as we said or as I said to be more accurate, I think we need that filter of experience.
So I definitely believe we're moving to more towards a more industrialized version of construction with the involvement of, you know, a lot of automation, a lot of model based systems and stuff like that. And robots that, you know, that everyone has started seeing already, you know, insight mapping applications, sensors in the field safety applications and so on and so forth.
So I, I see the robots and all these like machinery coming into like as, as an aim to reduce risk and improve safety in construction. But I see 3d printing, you know, certain hazardous aspects of a building, not necessarily the whole building But this is, this is my position. I would, I would hate, I would hate to see a fully robotic like structuring side.
Yeah. Yeah. It's when machines take over the world. And I'm going to hand to Val in a second. But I, I just wanted to kind of cover it and go well. Okay. So what we're actually saying is that using technology and with the change of roles, you'll still get a critical path or multiple, depending on how you want to look at it.
You know, you're just challenging the current critical path methodology that we're using today. To get to that critical path. Is that what we're saying? Because a lot of people will hear this and go, oh, so we're we rubbishing the critical path. We don't know, actually there is still a critical path because you can't get rid of it.
There is still the shortest path through your prone. Exactly, exactly the way in which we get there. That is, yeah. It's, it's not if I, if I can, if I can piggyback on that a little bit and try and close the loop, it's not just the way you get to it. It's also, how do you use it? And let me tell you why, because the critical path changes.
Very the sequence of your workflow and also very impair the instantiation of resources. Like it's about the path your crews are following when these two things change, the critical path changes. So depending on how you do stuff and how you treat the critical path and how do you react to those changes?
Because at the end of the day, it's about reacting to what's changing. So when something is changing, you need to see how so you can leverage the critical path knowledge, right? You have, along with my humble opinion, all the other potential critical paths to see, to properly gauge what is really critical for your project.
Right? Because I I've heard like many, many discussions, right? Like, no, no, no, no, no, no, no. We can not do this because that activity is okay. Critical path. So what if you do it differently? Yeah. And they're like, yeah, yeah, it's going to be, no, it's not going to be on the critical path or you don't know. So you need, you need to, for these, for proper risk and variability control, you need to get a bird's eye view on all the other options that can be explored in order to make a proper decision.
I feel no, that's, that's great to know. And just recalling from the debate we had. I think one of the debates was, well, you know, because we play such prominence on the critical path in the current day. Everyone's so focused on that single critical path, but as you're alluding to there's multiple calls, that could be critical if events change.
And so what about the others? You know? And so we think we do it by using things like floaty, erosion, et cetera, but all we really. Replicating reality. But it's so, so fascinating, but I'm gonna hand over to developers. I know he's probably got burning questions there. No, no, no. It is. It is. It's good listening to you guys and just having my own thoughts, kind of crystallize.
And I agree that there's going to be some challenges if we played this out and you're, you're effectively giving them an nth degree plan where the variations are unlimited, the opportunities are unlimited and the critical path could be multiple, multiple dimensions. It could go down this route, this route, this route, depending on a number of factors, that's going to be difficult in a contract model.
And imagine as, as Darrell pointed out, I think. How do you quantify the end date and get that in the contract and look to incentivize contractors to finish before that date, if the variables are always changing it'll be very difficult for them to have something in place. Something that, you know, traditional or conventional planners love is certainty.
And they try to communicate this back up the stream to the directors and the directors are very nervous forecast change, and every month you'll have PMO and controls come in and they'll want explanations into why, why numbers have changed? Why a times have changed? Why dates have moved? Yep. And it's like, yep.
Because this is a project. That's what happens on a project. The goal has always been, I think, is to try and take a snapshot at a point in time where you think you have the most information possible, the most plausible, realistic constructable project. You say, let's take a snapshot. We've got something that becomes the baseline.
Then, then your goal is to maintain that your goal is to remain as close as you can to achieving what you set out in the baseline. Now I dunno for the people listening and I don't know if dial, but all the projects I've been on the baseline is, is almost irrelevant. After the fact generally, because of the way we do baselines we, we refer people.
There's a lot of politics. As you mentioned estimations aren't really done properly. People have lack of training. It's not facilitated properly by professionals who have done it before. And then we take a snapshot to appease the client. I'm getting to a point. Don't worry. And, and I think one of the concerns is that if we, if we produce and like you said to me, you mentioned before, if you, if you told I can train a data scientist, a PMO faster than I can train a PMO guy, a PMO guy, data science, and as he's exactly around your point is they have no biases, no limiting factors in their brains or belief systems that make them do certain things.
And there is a danger. This is why I'm kind of, we're trying to unbreak the mold or break the mold a bit is, is to say to planners, actually, you're going to have to break the conventional ways of which you deliver projects. If you're going to provide multiple simulations of what could happen. Now, the problem I think, and maybe you can comment on this is we present a director of a project with a multifaceted, multidimensional variability model.
And it says it could hit, he, he, he, he, he here now. What's the difference between that. And let's say a a Monte Carlo simulation. And how do we stop decision fatigue at that level, from your perspective? I did it bitter was the best way to answer that question. For me okay. Let me take my form of poor man's attempt.
I think there are many levels of certainty depending on, you know, what level you're talking about at the snapshot level that, you know you guys brought up, you know, it's, it's a snapshot, it's, it's one of the many, many other like, you know, alternative. So if that snapshot, but there's a, there's a layer above it, which allows you to see a higher level of which allows you to assume a higher level of certainty or a more bird's eye view.
Basically, I guess the structure that I have in mind is, you know, a plan can generate many schedules. Those schedules can be the resource loaded, but each resource loaded schedule can have many CPM schedules for simplicity, right? Because. Again, the, the workflow and, you know, the, the, the path for the crews, you know, can, can have many, many different ways.
The certainty between these different light layers is, is different, right? So a director should be looking more at the higher level to see what is the overall certainty for my project. Like, for example your still crew can be critical for this like scenario or that particular like X option. But it might not be critical in 85% of all other options.
If I try to make me to make some sense here. So that's, that's how I would, I would go about it whether, whether you're using like Monte-Carlo or, you know, like search algorithms or anything else, like assess, you know, You know, this, that certainty to me, it ultimately, and perhaps qualitatively, it comes down to that.
Like what level of certainty are you? Are you gauging, gauging out? So you're thinking it's more and I know I'm putting it on the spot. I mean, this is something that, you know, every, every project struggles with, it's not something that's simple and it's different for each project, but you're saying something like that, your basically giving it a confidence score.
And maybe if you had multi varied scenarios, the machine or the system could calculate, which ones are more viable and then roll that up. Kind of, so you've got this, so it's not everything it's not, everything's fall at all. And everything's kind of spewing out different numbers. It's actually saying there's some areas here which may change.
It's giving you some variability counters, but overall it will give you a certainty score. Is that something correct? Absolutely. And this is, I guess, what is. I didn't want to sound biased, but this is, I guess, a leniency towards like the Monte-Carlo approaching in terms of sampling. Right. Because you're essentially what you're doing.
You're like sampling from a pool of thousands of potential, like CPM schedules, you know that from that sampling, you're getting a higher level confidence level or criticality score or criticality metric call it or baptize it however you want. But yes. Okay. Okay. That's great. And my, my last question from, from, from my perspective on this, before I pass over to Dale is around you mentioned uncertainty before.
And so, you know, one way to avoid uncertainty is, is, is. So it's, you know, to retrieve and recall knowledge from previous projects, we used to call them lessons learned, but we've, we've talked to people like Dr. Dan Patterson about how you get benchmarking from, you know, similar projects or similar categories of projects or classifications of projects back into the system to prescribe not predict, but prescribe what a good schedule would look like.
Is that also, is that something that we're also looking I see to be fairly honest, no, may because eats of those, that, because first off, you know, it's all that is based on historical averages and, you know it's, it's the basically proven there's a, there's a huge flow in taking averages, you know, into all the averages into consideration.
It's that doesn't mean it's that doesn't render it useless. Right. But the, the other thing the other reason behind me saying no. Is all those predictions based on old schedules and all these other than that, that approach their predictions based on a particular's sequence or approach. But again, we're back in the same question.
Like it's a vicious cycle. What about all the other stuff that could have happened? And I mean, to me, it's a bit like contradictory. Like every construction project is unique. It's, it's different. I know there can be some patterns, but yeah. Can there in, in, in the, in the sense that, because now we're going to gore going down into the rabbit hole, right.
How accurately have you, have you been tracking your schedule? Like how accurate is your ass billed and accurate to what level? Because for example, there's a delay you're fixing, you know, the actual start and end time, but did you fix the relationships for example? Back into that peeling, the onion aspect, right.
Of transparency. Like I am being able to answer why something happened either in planning or during execution. What else can I say? And I guess I'm going to wrap up my my succinct answer. Hopefully succinct is it's difficult for me to, to get like good quality of data with a proper structure, with a proper level of detail and all this kind of stuff without standardized modular processes.
And without. In, in order to your words to efficiently capture the knowledge so that you're able to reuse it. And also without formalized QC steps in the whole process, right. In order to verify validity and suitability of the data for those purposes. Yeah. Yeah, no, that's such a good point. So I mean, I, you know, I kind of put that up under me to set you up.
It's a, it's a difficult thing to answer because it's different on each project. And one of the things you come back to is the fact that data quality isn't always there. And so, and, and when you do collect data, There's always a level of bias that comes with it. It's the opposite of saying, having a lessons learned versus a black box on an airplane that records, everything records, all the instruments, records, all the communications records, everything.
That for me would be, you know, the kind of the, the Elysium of, of machine learning is if it was a black box recording of a project and had everything in it from culture to organizational structures, to all the data, to every decision ever made that to me would be, then you could build off that anything you want.
But we are far far from that. I would not far far, but, but far because it, it it delves back into that systemic restructuring that, that needs to happen. Right. To that end, I think emerging technologies, especially for the field, like real life, real life, data feedback censoring and all those like amazing tools that, you know, a lot of companies and solutions are enabling professionals to more accurately and holistically from the ad track, the progress of production.
I think that's a huge step towards, let's say shedding, some light on that black box. Nonetheless for me humbly, the essence lies in the integration that we, we mentioned in the beginning. How do you map all those things together so that your project control system can accurately reflect the reality?
Yeah. Thanks to me. I mean, I could keep going on and I think we're going to have to have another podcast session or even maybe just a few days, but it's, it's so fascinating. I'm going to pass up the dial now for some questions, things. So as well. Yeah, so actually this brings us to one of our favorite parts of the pod, the whole pods of favorite part.
But one of our favorite parts, maybe the cherry on the top, or, you know, sprinkles but a fun Dimmi this part of the pod is called defend the indefensible. So how this works is we, we put our guests through to to defend a ridiculous statement for 30 seconds. It's a bit of fun. So if you're up for that, I'm happy to put you in the hot seat.
Sure. There's enough hot here in California, but yeah. Okay. Are you ready? Sure. Okay. So the statement I'll read out the statement and then you have 30 seconds to defend it. The CPM is tried and tested all this other tech is nonsense. Defend that 30 seconds starts now. It is okay. Oh my God, this is so difficult.
It is definitely tested. There are decades and myriads of projects that have been delivered with CPM. I actually, although this is supposed to set me up, but I actually agree with, to some degree with, with a statement because for every new technology, every new method, any new theoretical frontier, you need to cross test it.
And you know, that, that's why we at Alice, we spent like three years doing R and D because we were like translating all those construction constraints into paramedical equations where like, can it happen? We didn't know. Hopefully we were able to do it, but I I actually agree with it, like. And you know, the other aspect of it is the following.
It's impossible to simulate, to accurately simulate a hundred percent of reality. So you need some relative confidence level in, into the accuracy of your model. And that's why I believe there's going to, it's going to take a lot of testing and trials and iterations for us to be able to formulate assumptions and objectives properly in order to properly use and extract the value from these new technologies and methods.
Brilliant. Brilliant. Yeah. Thanks for being such a great sport. It's, it's great fun because, you know technologies like what you're doing is disrupting the industry and you will have, and, and as you've alluded to a lot of sort of people just go, no, Nope, it's not gonna work. It's not gonna happen.
But we, we, we, we thought we'd bring this in for season three where we, you know, put one of these ridiculous statements to our guests and, and have a bit of fun with it. So thank you for being such a nice with that. Oh, thank you. It's been fun, indeed. It has been great funding as Val says, you know, we'd love to have your back, you know, for a part two there's so much we can go With with that.
And there's, there's so many more sub topics that we haven't discussed, I guess. I guess we can, we can talk about why CPM fails, right? We delved into the new stuff, which is great. I enjoyed it very much has effort to become funny. No, no, I, I, I appreciate your candor and your openness to everything. It's been brilliant, but was the, before we sign off, is there any final thoughts you want to leave our listeners with?
If you don't all right. I'm going to be a bit rude again. If you don't bend over a little bit, like it's going to be difficult to move forward. So to kind of tie it back to the hot seat gain. Yes. There are many friction adoption, friction and barriers. Yes. If we don't like try and overcome them, like, no matter how painful it is, like you will never, ever change.
So I don't know. I, it might sound a bit cynical, but if you don't want to change to me, it sounds like you're okay with projects being over budget and over time, at least to some degree, like you you're comfortable with it. Yeah. So it's about, you know, being up first and then reaping the gains. So every, all of us need to pay up, like with sweat work hours and fruitful, informative discussions, like you guys are hosting.
Thanks, Jimmy. Appreciate it. And very wise words to finish off with Phil. Any final thoughts? No, it's great. Having you on DME. As Al said, we look forward to another podcast. You know, I'll leave you with a quote that one of my favorite quotes of all time is by a guy called Alfred closed. Debuskey ski.
I always get names wrong. And he says, the map is not the territory. He talks about semantics, but it's exactly how model-based planning works. Right? You will never get reality. Maybe you can only get as close as possible. And I think that's a really great way to picture it in people's minds if they're listening.
But yeah, thanks for your time and your insight. It's been really great and honest and upfront and authentic, and hopefully people get on board with the future. Thank you. And if I can piggyback a bit on, on your last point a quote from a famous statistician, you know, statistics was of me, of the, you know pioneering, you know, fields using models to make decisions and engage insights from them.
All models are wrong, essentially, but some are useful. So that, that what I would like to do close it up really appreciate it. Really enjoyed it. Looking forward to continuing the discussion. You guys are great. I really enjoyed it. The discussion, the questions, the back-and-forth. Thanks, Jimmy. Appreciate it.
But folks that is all we have time for on this episode, but it doesn't have to stop there. You can support our charities and Xs blogs at project chatter, podcast.com. Remember, don't forget to hit subscribe on our YouTube channel and your favorite podcast player. So you don't miss the next one. A massive thank you to our guest, Mr.
Dimi for meccas that I pronounced it correctly. I hope I did. And thank you all for listening until next time we say, stay safe, be disruptive and have fun doing it from me and bell it's bye for now.
Thoughts and opinions expressed in this podcast belongs solely to the participating individuals and not necessarily to the individual's employer, organization, committee, or other group or individual. Additionally, any views or opinions are not intended to malign any religion, ethnic group. Club organization, company or individual.