Riccardo Cosentino welcomes Ali Mafi, an industry veteran whose career spans construction, automotive, and consultancy. Ali shares his journey from site engineer at Heathrow Airport’s Terminal 4 to leading transformative project management practices at Balfour Beatty, where he introduced innovative methodologies like critical chain management and lean principles. Drawing comparisons with the automotive sector, Ali emphasizes how better project monitoring, bottleneck identification, and accountability can improve outcomes in construction. "My definition of project management is knowing the impact of every task on the end date, every day. If you don’t know that, you cannot manage the project. You’re managing tasks, or you’re managing resources, but you’re not managing the project." – Ali Mafi
Riccardo Cosentino welcomes Ali Mafi, an industry veteran whose career spans construction, automotive, and consultancy. Ali shares his journey from site engineer at Heathrow Airport’s Terminal 4 to leading transformative project management practices at Balfour Beatty, where he introduced innovative methodologies like critical chain management and lean principles. Drawing comparisons with the automotive sector, Ali emphasizes how better project monitoring, bottleneck identification, and accountability can improve outcomes in construction.
"My definition of project management is knowing the impact of every task on the end date, every day. If you don’t know that, you cannot manage the project. You’re managing tasks, or you’re managing resources, but you’re not managing the project." – Ali Mafi
Key Takeaways
Links Mentioned
The conversation doesn’t stop here—connect and converse with our LinkedIn community:
[00:00:00] Ali Mafi: My definition of project management is knowing the impact of every task on the end date every day. If you don't know that, you can't manage what you can't measure. So I have never come across what I would define as a project manager. People are not managing projects, they're managing tasks, they're actually managing resources.
[00:00:23] Riccardo Cosentino: You're listening to Navigating Major Programmes, the podcast that aims to elevate the conversations happening in the infrastructure industry, and inspire you to have a more efficient approach within it. I'm your host, Riccardo Cosentino. I bring over 20 years of major programme management experience. Most recently, I graduated from Oxford University's Saïd Business School, which shook my belief when it comes to navigating major programmes. Now it's time to shake yours. Join me in each episode as I press the industry experts about the complexity of major programme management, emerging digital trends, and the critical leadership required to approach these multibillion dollar projects. Let's see what the conversation takes us. Hello everyone and welcome to a new episode of Navigating Major Programmes. I'm here today with my esteemed colleague, Ali Mafi. How are you doing, Ali?
[00:01:21] Ali Mafi: Thanks, Riccardo. Thank you for inviting me to this podcast.
[00:01:24] Riccardo Cosentino: Good to have you on. I think we met online, if I'm not mistaken. I think we've engaged in a few exchanges on LinkedIn about some of my postings, some of my podcasts. And so I think in the end, we decided well, if we're going to have a exchange of conversation and ideas, let's do it on the podcast so that everybody can benefit from that fruitful exchange. But maybe before we get into the podcast, can you tell us a little bit about yourself, about your background and what you do today and what you did in the past?
[00:01:52] Ali Mafi: I started in construction in 1980 on Terminal 4 Heathrow as a site engineer. We were doing all the civil's work and I'm sort of moved between a couple of companies and eventually reached a dizzy height of becoming a project manager. And within 9 months, you know, I love being an engineer. I loved, you know, I was working 6 days a week, 12 hours a day. It was brilliant. And then when I became a project manager, I was very disillusioned. I thought the experience was dreadful. This coming to work every day and chasing people and all the sort of the blaming and the defensive reasoning and just endless and the other one that the other thing was constantly answering the same question different people coming saying, have you thought this? Yes, the architect would come, the engineer would come, the client representative would come and your boss will come. I thought this is not for me. Because I remember it well, it's not intellectually engaging, unlike when you're a site engineer. So I left it, I signed up for an MBA, then got involved with the automotive industry, which involved quite a lot of research and data analysis. And then I got involved with a couple of other things, and then I ended up back in construction. I got, somebody said, Balfour Beatty were looking for people, so I came to join Balfour Beatty. I joined Balfour Beatty Civils and sort of major projects. I started off on a utilities project and I was involved with the underground nuclear bunker in Whitehall. It was brilliant. And after a couple of years, there was this thing that the chief executive wanted to set up a transformation type team, you know, a business improvement team, because it was fed up with the way projects were run, especially the fact that QSs were left on site for months afterwards, agreeing final accounts. So, he then brought somebody from the automotive industry with PQM experience and a lot of knowledge about dimming and system syncing. So, they asked me if I wanted to join that team. I said, absolutely. So, then I joined, we became a five person team and part of that for about four or five years, we experimented with everything you can think of. Then we got involved with sort of the last planner with the (inaudible) and all and we tried that and we met Eli Goldratt and he trialed his first project on our, then we started to find out about the Lean book came out, the Lean Thinking book, which was really back to what a lot of stuff we were doing with TQM and statistical process control and all that stuff. And then I was with him doing Balfour Beatty Rail a couple of years. I'll come back to this later because there was some data collection there, which was brilliant. And then I got seconded to (inaudible) where my role was help promote offsite, lean and basic collaboration. So that was about three, four years of doing that. And then I got involved with the MOJ. Everybody's talking about MOJ, you know, where did it all start? I think I had part play in that. And then we trialed BIM and then, you know, I'd set up the company with a few others and we've been providing consultancy predominantly around critical chain. And it's been experimenting with all sorts of different things, different types of leadership, different types of data collection. So, yeah, self managing teams, for example. So, done a lot, been involved with close to about 200 odd projects in all the sectors. So, and got lots of. 5,000 probably project big on the back of critical chain program, project updated programs on my computer. So I have a good understanding of what goes on. And then I've had some throughout this journey. I've never felt that I had the complete picture. I always thought something was missing. It was only the last sort of couple of years that I've sort of started to all the light bulb moments that two new things have come to mind. And I think that I'll have a much better picture now what we need to do. And one of my singular views is globally, I'm on my own, I think trying to push something that nobody wants to hear, which we'll come back to.
[00:06:06] Riccardo Cosentino: Wow. What a resume. First of all, when you describe the way you felt as a young project manager, I think I totally relate. I felt exactly the same way. I mean, I remember working on a very large railway construction project, for Balfour B. Funnily enough, I'm thinking, I'm thinking there must be a better way to make a living. And that's where it pushed me to do an MBA. That's what brought me to Canada. It was that thinking, feeling is like, this can't be it. I mean, if this is the life of a project manager, I don't think it's for me. And then you mentioned Deming, you mentioned Goldratt. I mean, those are two books that I really enjoyed. I read The Gold three times now. I read the book from Deming and his trip to Japan and how he brought back that culture to North America. Very interesting. And then the Movement for Innovation. I remember being a young graduate. I think it was a workshop organized by the Institution of Civil Engineers and they were training young graduates about all the great things for Movement for Innovation and what they were doing. You know, I mean, we go back a few years that, that was, I think it must have been early 2000, right? Yes, it was early 2000. It was early in my career. So, yeah, very curious to explore with you. You know, we in the industry, we always draw parallels. We always compare the construction industry to the automotive industry. And we're obviously trying to learn from their practices. I mean, it is slightly different. Different industry, different challenges, but certainly there are things that we, by now, should be able to incorporate in our processes. We can touch, I don't know where you want to take this, but my curiosity is how do we do that? Why have we failed as an industry to fully embrace? I know there are pockets of the industry that have embraced the TQM and all of the concepts that you mentioned in your intro. But how come that we have not been able to fully implement it to the extent the automotive industry has done it?
[00:08:02] Ali Mafi: Very good question. Let's go back to the role of the project manager, because when I went to tell my head office I was resigning, they're saying why? And I said, well, this is not for me. This is just nothing seems to work. And I couldn't explain really why I was leaving. I just thought this is just not for me. Then when I worked in the automotive industry, realizing the right color door comes to the right color car every time without fail, you think, and then I realized that two things that were missing was, you know, not enough science on a daily basis or any data. I had no idea at the end of every day, what just happened to the project ended. For example, you know, when you work in the automotive industry, you have the countdown, you have the undone system that tells you how many left to complete that day. And my view in terms of the automotive industry is that all the underlying principles apply without fail to the project environment, you know, the principles and they're all very similar, like playing sports is what I always use as analogy. If you play something that involves striking something like I play lots of tennis. If you're playing cricket or even football, there are a number of things that really help. One is bending your knees, keeping your head still, focusing on what you're striking, and following through. So those are principles that apply and give you the maximum sort of range and benefit and control and the same with the automotive industry. But what's happens with construction is we don't work backwards. We don't follow COVID, you know, begin with the end in mind. We keep pushing initiatives. You know, Goldratt used to say, I remember in one of his talks, the world of management, it's obsessed with ill-conceived solution to ill-defined problems. We don't actually know what the problems are, we just make up stories. I'm just reading a very good book called Nexus. I don't know if you've read that, by Harari. And he's talking about we're all connected together by stories. And the stories don't have to be true. You know, somebody says, ah, projects are running late because it's their complexity. And then everyone goes, oh yeah, it's all complexity. And then a whole lot of people are sort of on that bandwagon or, you know, we need to do offsite. Oh no, no. We need to do digital twin. Oh no, no. We need lean and we need this and that. And we keep pushing things into the system. We don't actually. Have a way of monitoring how that works effectively, and we have too high expectation because we think, okay, we tried that the project didn't finish on time.
So it doesn't work. And the reason, you know, one of my light bulb moments has been that actually we don't value the project time. We don't account for it the same way as we do with safety with quality with costs. Do you remember QA?
[00:10:51] Riccardo Cosentino: Yes.
[00:10:51] Ali Mafi: Quality assurance. So, I mean, I think Balfour Beatty was one of the first to sort of be QA-registered. And it didn't take long before everyone realized, actually, QA did not improve anything. All you had to do was say how bad you were, and as long as when they audited, you showed that you weren't as bad as your procedure, then it was all fine. And I think that's the way we program, plan. We produce this plan, which is as bad as it can be. And then, you know, as long as we sort of match it, we're saying, okay. But that's your own plan. Well, again, it's a bit like with costs, you know, we account for every penny, and then we do a comparison with a budget that we may have. Well, when it comes to project time, we don't actually account for every hour, every minute, but we keep comparing with a program. It's just like comparing with a budget. It's not reality as such. And then I realized, actually, because I'm doing some work with (inaudible) here, and realized that this problem that we have is not a construction problem. It's a project problem. And having worked with Siemens and a few other organizations outside the IT project, they all suffer from the same issues and problems. And part of it is the lack of science and lack of proper accounting for the time.
[00:12:09] Riccardo Cosentino: Can you elaborate a bit more? What do you mean by not accounting for time. How does that manifest day to day?
[00:12:17] Ali Mafi: In the same way, for example, as I would sort of say, as a (inaudible) calculates your time to completion every few seconds, because if you're just comparing with some estimates, say you plan something to take 10 days and it takes 10 days, if you haven't actually monitored what happens every hour or every day, you know, you may realize actually that the guys actually worked on that task for five days. But because of what's called Parkinson's Law, you know, the guy only turned up four days and finished it. But we think, ah, that was 10 days of work, but it wasn't. That task actually took four days and we wasted six days. We need to monitor exactly, you know, every project day in the UK cost 70 million pounds, every project hour globally for 70 million pounds every hour and who's keeping track of that, you know, that's fine is the biggest cost on the project. We are obsessed with the value engineering. 70 to 80% of the project cost is time-related and 20% is the actual product, what we built, and we are obsessed with value engineering the 20%. And at best, if you improve that by 2%, you're not actually making much of a gain, but we are not dealing with what causes us delays like complexity and uncertainty and risk. We're also squandering a lot of time unknowingly, and we're squandering time all the time, every day, every hour, on every project. Let's go back to the uncertainty and risk. Yeah. Those things, not the same things happen on every project. Not every project has the same level of complexity. Or the level of risk and uncertainty and risk and uncertainty, they're not prevalent constantly, they come and go and when they happen, they may not actually impact on your end dates. You know, you've got a major project, you've got a thousand files of activities and somebody doesn't turn up does not mean your end date moves out or even the 10 people don't turn up. And we're spending an inordinate amount of time talking about why the projects run late due to complexities. So these are the things that could happen. And if they do happen, they may not actually have an impact as such. But there are things that are happening, which actually we're not aware of. You know, there's seven different ways we're actually squandering time every day on projects. Some of it is not every day, but some of it is every week, but some of it is every minute of every hour. Let me give you one of them. That's prioritizing work. Again, this is a lightbulb moment. After all these years, only a couple of years ago, I think, oh my God, you know, we don't actually prioritize work because every project, the respect of complexity and size, has one bottleneck. Yeah, I will show in the idea of the bottleneck with Eli Goldratt in, was it 1995 or something, and it's actually a very good starting point for everybody to start every time you think I've got to do this. I've got to do that thing. No, actually, unless I know where the bottleneck is, I am going to gain nothing. So every system has one bottleneck. But if you work on that bottleneck, then the bottleneck moves very quickly. And if your system doesn't pick that up instantly, then you are pushing the end date out without knowing. So, therefore, you need to not only know what the bottleneck is, you need to know the impact of virtually every task on the end date, in my view. So, my definition of project management is knowing the impact of every task on the end date, every day. If you don't know that, so under Drucker's, was it Peter Drucker's term, you can't manage what you can't measure. So, I have never come across what I would define as a project manager. People are not managing projects, they're managing tasks, they're actually managing resources. They're just balancing stuff out and this idea of coordination. Which actually has a negative impact on the end date more often than not, especially if you've got package managers.
[00:16:18] Riccardo Cosentino: I don't disagree with you, but let me be a devil's advocate. I mean, you're referring to the goal, right? The bottlenecks, fixing one, moving to another one. But they, obviously, I mean, when you read The Goal and hope every listener is going to read The Goal, because it's a great book, that's a manufacturing environment. That's a controlled manufacturing environment with less variable than a construction site, where it doesn't play a role in a manufacturing facility. Weather does play a role in the construction site. So it's not a one-for-one comparison. There are slightly different challenges when we deal with construction that makes the management or your supply chain, the management of your production line, which is a construction site, can be viewed as a production line. A bit more unpredictable than what you have on a manufacturing facility. What's your view on that point?
[00:17:12] Ali Mafi: I'm not trying to compare when it comes to the bottleneck with the manufacturing. I'm trying to say that every system has a bottleneck. The rate of output of every system is determined by its bottleneck, and every project delivery system has a bottleneck. So the more complex the project, the more uncertainty. This is the difference with manufacturing, then the faster the bottleneck shifts, and if you don't have a system that actually monitors that, you're in trouble, you're losing time without knowing it, you know, when we update programs weekly or sometimes monthly. We have no idea. Project managers have no idea. You know, they tell you, oh yeah, everything's driving the end date, but it's not, you know, when I go to project because I've got 200 people, I say, which one's driving the end date? They look at me like, what are you talking about? They're all driving the end date, but they are, but they're not. One other thing that's another sort of light bulb moment that now AI has actually come forward. And that's basically backed up. What I've learned over all these projects is that on average, we only work on 30 percent of the available activities, 30 percent of the work phases. 30 percent is a lot more than what we need to work on. People go, oh, only 30%. I've heard so many people say, only 30%. Yes, because most of this work does not need to be done now. If you were to do just in time, you will only work on one task a day. If you push everything to the latest possible start, you will only be left with one task showing on your list. So you only need to work on the 20%, but you need to work on the top 20 percent in terms of impact on the end date. And you need to update that at least once a day, if not more. It's like, you know, I was, somebody else said to me, and when I was doing that conversation, you say, it's like trains, isn't it? I say, yes. You know, all those parts of activities are all moving like trains. If you're not knocking off the ones that are closing to the end or working on those, then you're going to end up pushing the end data. You know, the bottleneck, the constraint activity is so tight behind. If you work on one, then the one behind. So you have to work at least on the top 10 or 20 if on a daily basis, not to push your end date out. Again, we have this sort of mindset. People say, oh, don't worry, we'll catch up. I have heard that statement so many times. Don't worry. No, you're not catching up time. Time is you cannot, if you're going to do something that will shorten the project later, you could have done that without losing the time you're losing now. So we need to be aware. And this is where it comes to complexity. You know, to know where you're at, you need to use elapsed time as a way of monitoring your position, exactly the same way as a satnav does. Yeah, a satnav does not say, the original satnav, apparently, worked out, you've got 60 miles to go, you're doing 60, you'll be there in an hour. But now the satnav says you're doing 60, you've got 60 miles to go, I can tell somebody has already reported an accident ahead and the cars ahead using the same satnav are not going at that speed and the sensors are also saying you're not going, so you're going to be there an hour and a half.
[00:20:28] Riccardo Cosentino: Let me play devil's advocate. I don't disagree in principle with anything you're saying. I totally understand. But the harsh reality though, is that the world of construction, the world of major project is not that perfect. And there are many situations where leadership doesn't actually want to know the bad news. So.
[00:20:47] Ali Mafi: This is one of the problems. Because the news is not good.
[00:20:52] Riccardo Cosentino: Yeah.
[00:20:52] Ali Mafi: It's not. I mean, I've got to talk about a daily measure and it does not look good unless everybody collectively takes responsibility for it. It does not reflect well.
[00:21:01] Riccardo Cosentino: And I believe that there are many very capable individuals and companies working on this project, but the human factor at a certain point, everybody knows what needs to be done. Everybody knows what's going on. And at times I've experienced that myself. There is a tendency of saying, well, that can be right. And so until you come up with the right answer for people online, I'm making air quotes, the right answer, you always ask to reassess your schedule till you get the right answer. I don't think there's anything that Deming or Goldreich can do to help us fix bottlenecks until we actually fix that problem. How do we get better leadership that is not looking for the right answer, but is looking for the answer?
[00:21:48] Ali Mafi: I like that, the right answer. I know this is probably not going to go down well with some of your listeners.
[00:21:54] Riccardo Cosentino: Good.
[00:21:56] Ali Mafi: As I said, I've got probably 5, 000, probably more updated programs from 100 odd projects. And something I've learned is that 80% of that in program probably higher than that, it's actually a repeat of the same sequence. You know, if it's a railway, 200 mile railway, every kilometer's sequence is the same. Every half a kilometer is the same. If it's a block of flats, every flat is near enough the same. Every floor is near enough the same. There's nothing complicated about the program. If you know what you look for, you know, I can instantly look at the program and not when I'm sending a PDF, I can't believe people sit around and review a PDF. It's like everyone's sitting around looking at a map. And saying, actually, where are we? You know, we've got a hundred cars and a hundred roads. Who is where and what's happened? So this idea of a deep dive makes no sense to me. If you set up buffered programs, which requires a quite a lot of upfront effort in terms of validation by the input subcontractors, most of these programs I have, they've not been re baselined yet. They've all been updated, rescheduled. I mean, so many people. If you're not going to reschedule, a lot of people don't, then you shouldn't waste money on a programming update. You might as well just use Excel. It's madness. And you know, you don't need to use P6 to just reschedule. The only benefit a project program provides, the only benefit, is that allows you to prioritize every task in terms of impact on the end date. No other benefits. And you don't need a fancy software for that. Yeah, and nobody uses that facility. Nobody gives out a list to everybody every morning. You know, people talk about, oh, so and so does morning briefing. Yeah, but the morning briefings are you stand there and you say, okay, Riccardo, what are you doing today? And you go, I'm going to work here and there. But I'm saying, no, you don't. You say, Riccardo, your highest priority task is in that space, in that corner. You go there first. And if you're not going to go there, tell us now, why not? And the other thing is if a program is rebaseline and it shows a different outcome, I would personally sack that person who was actually working on it. It's like driving along, you're running late, you're sacked and says you're going to a meeting, you're sacked and says you're going to be half an hour late, and you press reset. What do you get? You get the same answer. You do not get somebody cooks up a different answer, you think, how is that? You know, what is it you've done now, and why didn't you do that at the outset? Because I've been involved, okay, I have so many projects and quite a lot of them not at the outset. Yeah, so I get asked to go and help, and then I say, can you send me a copy of the program? Okay, and I say, can you, unless it's in this format, send it to me in XML so I can look at it, because then I can move things around, have a look. Not once in 20 years has anybody done anything but send me a PDF with a, what's the word, disclaimer that this, or whatever, I can't think of the term, that this program is not complete. Like, hold on, you've invited me to join your project halfway through and you're sending me something at what point it's like you're satnav saying here, Riccardo, you'll be there in an hour and a half. But this is not, we're not sure yet, but we'll tell you late.
[00:25:14] Riccardo Cosentino: But again, isn't that and look, I've had the same experience, I've had some stories that I can't repeat on the podcast, but yeah, the PDF. I mean, in fact, there are certain clients now in Canada that actually specified that the format of the schedule has to be XML because they were getting PDF from if it wasn't specified. So now the contract clearly says what it was the form of the schedule. But again, you identify a lot of issues, which I will, I think anybody that's been in construction is familiar with. But to me, the root cause of that problem is the contract. This trust is the contractual provisions. Is the fact that people don't want to send you the XML because is that going to share information that my then will be used against me? You know, so there's a problem with the lack of trust. The problem is that if you show the full schedule in XML, somebody can see that maybe you haven't been completely transparent about your schedule. So, yeah, those are very common issues, but the root cause is different, right? The root cause is deeper and more difficult to solve because it goes back to the contracts. It goes back to the relations that are established in large construction project and even not so large.
[00:26:29] Ali Mafi: Absolutely. I mean, the whole contract setup means that on major project, you probably have 60 or 70 programs and then people create their own daily schedule of their own bats have nothing to do with what the priorities are. The guy says, oh, yeah, I'm going to make sure that gets done, that gets done. And people sit around, do this weekly thing, weekly scheduling on an Excel spreadsheet, asking people, you know, you've got all these different systems, basically. And you can't be monitoring what is going on. So what my view is, and I think the only person saying this, and maybe, you know, every morning I think, am I mad that we need to monitor every day how much of a project day, how much of this 70 million we spend daily or being paid for, how much of that project day do we complete? Does that make sense? So you've got a 100 day project, at the end of day one, you should only have 99 days remaining. Is that the case? Because it's not the case on any project, and I believe unless we get that up and running, we're going to be just chasing initiatives and pushing them into the system, thinking they're going to give us the right answer. Because once you realize, actually, no project finishes on average a day per day. And you then also will realize, you know, for years, obviously, because everyone's talking about, oh, is this the right way? Should we have this? Should we have this form of contract? Should we have these layers of delivery? Should we not employ people direct? What's the answer? I think once you start measuring how much of a project a day you complete and trying to work out why you're not achieving, you will really then realize, actually, you will never be able to cut anywhere near one day per day, on average, unless you completely rethink the way everything is done.
[00:28:19] Riccardo Cosentino: Okay, in the spirit of being devil's advocate again, the underlying assumptions that you bring is that it's actually something that I realized only a couple of years ago. I mean, some of these schedules or programmes as you call them in the UK, we call them schedules in North America, have a high level models of how we envision the project being developed, but they're highly reductionist. And I would argue probably wrong because I can't remember who said it, but like all models are wrong. Some are useful. Right, so every construction program is probably wrong to begin with, but it's useful. And so there's also that element, right? We can't really, so you say measure every day, but what if you're measuring something wrong every day?
[00:29:04] Ali Mafi: Very good point. You can't measure it 100 percent accuracy, but you can measure it. If you set up like you would set up a sort of a buffer program and have elective validation, you get to pretty much 80% accuracy. And you're only then moving between certain parts of activities weekly, and you're not really that far off where you should be. So, there's that side of it. Yeah, and the other thing is, to do what I'm saying, I talked about squandering time. The most amount of time we squander is by using estimates to create schedules. We have to move away. I mean, you know, the automotive industry do not use estimates to organize how the cars assemble, their focus one car at the time. So that's what we got to do. Everything has to be based on units of work. How many meters before the next activity, not 10 days of this, 10 days of that. And it doesn't matter if you don't meet it. You should always organize work to fail because it's always, this is experience, it's always easier to push people back than bring people forward. Always.
[00:30:12] Riccardo Cosentino: Yes.
[00:30:13] Ali Mafi: And people say, oh, no, no, no, you know, what is this? You can always tell them to wait another few days, but if you finish early and it's costing you whatever, a hundred grand a day, prelims, you can't ring up and say, oh, go, you know, we finished early, come in early.
[00:30:27] Riccardo Cosentino: Right.
[00:30:27] Ali Mafi: Again, it goes back to, you know, adaptability, flexibility. This is not a solution. That means nothing will go wrong because the measure I'm telling you shows that everything does go wrong. And if you want to put all that right, you have to start going back to sort of employing some people direct and changing some of that and not having so many layers of subcontractors because otherwise you will not change, but you just have to be able to respond collectively. And this is where I've now sort of came up again, this is only another light bulb moment listening to my wife and my son. My wife is a hospital doctor, senior consultant, my son qualified as a doctor. We would talk for actually about three, four years ago. And a few years ago, they kept talking shop and then whatnot. Then they started talking about ward rounds. And I'm sitting there going, oh my God, that's one of the missing pieces of jigsaw. We need to do collective board run because that's the only way we can work out, you know. A) solve problems, B) know where the project is at, C) get proper feedback in terms of elapsed time. D) know if we're batching up work or not. F) if we can see the guy is driving the end date, is actually being effective or efficient or is he getting the right stuff to him at the right time, all those things. Purpose of the ward rounds basically is obviously to improve people's health and get them off their bed ASAP. And we need to do the same to the collective ward with a priorities list. And when you do that, you need to follow the five steps. I would, my thought on it, the TOC. Five steps when you're doing those walks, it is an amazing thing.
[00:32:13] Riccardo Cosentino: Who should be doing. I mean, I'm assuming you're talking about a conceptual word round on a large project. So how would that materialize in our context?
[00:32:25] Ali Mafi: I facilitate the weekly thing. It's the older black hats and if the client representative comes and the architect, the designers come, even better because everything gets resolved there and that is amazing. You know, the difference he makes sitting in this room, people going, oh, there's a problem. What problem? Oh, on the third floor, we're on the third floor in that corner. How big is the problem? Oh, it's big, but when we do the ward rounds, people go, let's go up to the third floor, I want to show you all something. And then somebody says, and it's amazing how the conversation goes around. You know, I guess sometimes somebody who's not a plumber, for example, says, oh yeah, you know, I've sold something like that on a few other projects. This is what they did. You'd be surprised when I do this, start doing these ward rounds. These black hats do not know each other. They don't even know each other's names. And after a few weeks, there is so much banter. And they love it. They always turn up. They're always there. When I get there, whatever, and with the board round starts at 10, virtually all the subcontractors are there. Because they feel a sense of belonging, because their voice is being heard. It is the most amazing sort of experience on a, you know, project. It really does work. Does that make sense? But you have to be, you have to follow a pretty, you can't, when you're world round, you're not going to every task. You're only going to the maximum. Top 10, if not the top five, you need to prioritize every day, though, you know, make sure.
[00:33:53] Riccardo Cosentino: I guess that's your point about the end date. Well, you're going to focus on the tasks that are driving the end date. I'm going to try and solve those like in the bottlenecks in the goal, right? You focus on those.
[00:34:03] Ali Mafi: If you, if you walk the top 10, you know, if your thing is not 100% accurate, you're very close in every other day that you will be touching on really stuff that is impacting.
[00:34:14] Riccardo Cosentino: Fascinating conversation, ali. I'm conscious of time. Is there any other point, concept that you want to leave with the listeners and with myself? I mean, you have some really great concepts on how we improve, and I really liked the conversation because it's very specific is not abstract. I mean, you're bringing concepts that are very well established, proven in other industry, and you're trying to apply them to our industry. And as I said, these are not theories, these are well-established practices. And that's why I like this conversation, because it's not abstract, it's very concrete. But on that, is there anything else that you would like to quickly chat about or leave with the audience?
[00:34:56] Ali Mafi: Yeah, just two things. One is obviously what I'm trying to say is to deal with complexity and certainty, you need the shortest possible feedback loop. You need to know instantly if it's having an impact, what impact, and deal with it. And secondly, I mentioned about pushing stuff into the system. You know, I keep going to events and everyone's talking generalities. Off site. I mean, somebody said that the tip event last Monday, off site is not the solution to everything. And some people are saying this focus on these initiatives actually creating further complexity. We need to talk in numbers. You know, if you're using Project 13 or FAC 1, whatever, show me, show me how that actually is improving your project delivery. Don't just say we're doing this and that. It's like when people used to say to me, when I went for ideas, everyone, we do got a collaborative project and I go, okay, I'm going to come and have a look. I said, what will I see that will be different when I get to your project? And you know what the answer is. Whenever I got there, you couldn't tell any difference.
[00:35:59] Riccardo Cosentino: Yeah. My fear is that those are all solutions looking for problems. And so I think we're very good at coming up with solution and then finding, you know, if you're a hammer, everything is a nail. Right? So if you're Project 13 and you developed a collaborative model, a collaborative framework, then every solution has to have collaboration, but ultimately certain problems don't require that solution. So you really have to start with a problem, not with a solution, which I think.
[00:36:26] Ali Mafi: You need to quantify it.
[00:36:27] Riccardo Cosentino: Yeah.
[00:36:28] Ali Mafi: The Toyota principle is you're not allowed to express opinions. If you say something is a problem, how big is it and how big is it relative to the others? I mean, if you hear somebody who is pushing a certain initiative, yeah, you hear them now, for example, they talk about data analytics. Next minute they're talking about robotics. Hold on, robotics is a different thing to data analytics. The next thing they talk about lean, because I think, you know, they realize actually all these pieces is not just one piece. So I think this is actually quite important. I mentioned this. You've got to do what the automotive industry do, that you only talk about the five, six things that are performance of your organization. So whatever you talk about is either going to be about time, about cost, about safety. About quality, about the environment, so you don't come and say, oh, we must do 80% offsite or three levels of BIM, you'll get thrown out. And, you know, one other thing about AI and this predicting the future nonsense, I don't know why people think, you know, if your satnav could predict exactly when you're going to be there, you know, you're talking one part of activity, the journey, not thousands.
Yeah. So then you wouldn't need to leave it on, would you? You'd look it up and he says, you'll be there at 4:30 and you can switch it off because that's predicted it. You just ring up the other end and say, I'll be there at 4:30, but that's not how life works. Somebody was telling me, oh, but satnav tells you, you know, at what time, it tells you different times. I said, well, that's not very clever, is it? Because if you look at what this shows you, it tells you what you already know that if you go during the rush hour in the morning, school run in the afternoon or whatever, it's going to take you longer. I said to the guy, I tell you what, you're big into this data analytics, once you gather all this project data that you claim and then put it into AI and then say, I'm going to concrete in next winter, AI will tell you it'll take twice as long to come through in the winter than he does in the summer. So I'm sorry, I'm not into all this sort of prediction and AI. And one last thing, if you want to, you've talked about a number of books to read, you must read Maverick by Ricardo Semler.
[00:38:41] Riccardo Cosentino: Will do. It's on my list now. Well, Ali, thank you very much for a tremendous stimulated conversation. I want to thank you for joining me today and I look forward to continue our exchanges on LinkedIn and possibly meet you in person at some point.
[00:38:56] Ali Mafi: That'd be nice. Yeah. Look forward to that. Thank you very much. Thanks, Riccardo.
[00:38:59] Riccardo Cosentino: That's it for this episode of Navigating Major Programmes. I hope you found today's conversation as informative and thought-provoking as I did. If you enjoyed this conversation, please consider subscribing and leaving a review. I would also like to personally invite you to continue the conversation by joining me on my personal LinkedIn @RiccardoCosentino. Listen in to the next episode, where we will continue to explore the latest trends and challenges in major programme management. Our next in depth conversation promises to continue to dive into topics such as leadership, risk management, and the impact of emerging technology in infrastructure. It's a conversation you're not going to want to miss. Thanks for listening to Navigating Major Programmes and I look forward to keeping the conversation going.