What 22,000 Projects Reveal About Success and Failure

In order to accelerate a project. You don't skip planning in order to accelerate a project and be as fast as possible. You actually have to think for longer or think harder. Hello, welcome to the Shift Code, the podcast about innovation, transformation and leadership in the project economy. So my guest today is Alexander Boutier. You were a professor at Oxford said Business School. You also with Ben Fliberg, you have this organization called Oxford Global Projects. You've done incredible work, right, with Professor Flyberg on what we call major projects, complex projects, GIGA projects, basically projects that are unusually expensive, difficult. And that work has really helped all of us understand, through more rigor, in the way you were doing research, how leaders think about risk forecasts, complexity, project performance. But Alex, you've also contributed to our work as a volunteer at pmi when we two years ago reframed project success and came up with all this research. That happened in 2024, 2025. We have a new wave going on right now for 2026, understanding what is actually project success and what drives project success. So, Alex, welcome. Before we start, I'd like really to acknowledge again the importance of the work that you and Ben have done. It has influenced me. I think it has influenced a lot of people, shaped the way many of us think about major projects. Now, I mentioned that research that we've done, right? One of the outcome of this research was to frame project success in a way that is somewhat broader than the classic triple constraints of budget, scope and schedule. And we established that for us, project success in the end is when it's really thinking about projects as an investment and a project is successful when the value that is created or has been created exceeds the effort and the expense that had been engaged or required. So I'd love to begin with this tension and then, of course, use the rest of the conversation to learn from the deeper insights that your research has produced. So let's talk a bit about these triple constraints versus project success. Your work has done so much to expose the limits of wishful thinking around cost and schedule. And at the same time, we would argue that project success anyway cannot be reduced to the triggers, constraints, right? So how do you think about this relationship between, let's say, traditional delivery metrics and the broader question of whether a project is actually worth the investment and created value that is worth the investment. First of all, thank you, Pierre, and it's great to have this conversation. And I think you all have something that exactly that kind of question of what is success in projects? You know, that has also really sort of that's where our research here in Oxford really started with that kind of question of, you know, are we doing the right projects? And our key focuses on always been in the front end. So and very much we were particularly interested in, you know, how do you get a project to the big decision that we're going to start this now that we are providing the funding of that. And when I look at that and also the intellectual history of this, which is really, I think really fascinating, which goes back to the 1800s. You know, it goes all the back to a very angry Frenchman who in the 1840s was very angry with the French government about trying to build a lot of canals in France and digging up the countryside. And so these very now long standing ideas about, you know, what is value? Sort of back then ended up in an essay by Jules Dupuy on what is the value of public works. And it was really very important essay because it introduces things like marginal pricing and the NPV formula and all of those good things kind of key to tools that we now use. But he was just a NIMBY protester. He hated the French government and he didn't want them to dig up the countryside and build canals that nobody needed. So, you know, this is a long history that we've been asking of, you know, what's the, what's the value of projects? And so I think the kind of, you know, having been part of that insights team about sort of that guiding the research that sits behind that redefinition and also the MOA initiative has been quite informative thinking about us in unison, should we measure project success in a different way than the Iron Triangle, which as we all know also has a long history, but even when it was first suggested, immediately ask. Here's a couple of certainties of how we can evaluate project. Yes, there is cost overruns, yes, there might be delays, but you know, a what should be number three? Is it benefits, it is scope, is it quality, and what about satisfaction of others, etc. Etc. So, you know, as old as that framework is, there's always been a question of, you know, but what else? It never felt complete. And so having a broader framing obviously makes it feel much more complete. And I think that's a, that's a really important stepping stone to understand and start thinking about, you know, are we doing the right projects and you know, are we doing them in a way that, or could we do them in a better way? Would you recognize that a project can fail on cost and schedule and still be a success in the broader sense, and I would say, conversely, can a project hit or meet each of the triple constraints of the iron triangle that you were mentioning before? So budget, scheduled scope and still be a failure? How would you think about that? Yeah, so I think yes, yes. In both of these scenarios, you know, sort of we've seen projects in the past that had big cost overruns, but also lengthy delays and are seen as a massive success. So, you know, sort of, I think the poster child for that and there's a long list of those, but the poster child of that is the probably the Sydney Opera House was a massive success. This has redefined the city and really put Sydney on, on the international map, created tourism and you know, now studies show what the contribution of that project was to the local economy. So by all measures a success. But during execution it was massively delayed, massively over budget and you know, cost the architect his career and his job because of that. So it was a complete execution disaster or was seen as a massive failure back then and now we look back and say it was a great success. Yeah, it still could have been done differently and better. Right. Even though it's a success in the end. Yes. So I mean, and that's kind of one of the questions we always ask is, and you know, yes, of course, you know, very few projects ever get cancelled or very few projects get stopped halfway way through but deliver. So people must see some value in it, but it probably doesn't, you know, hence the whole idea isn't just looking narrowly at did it deliver on budget, to deliver on time is not a, a good indicator of overall project success. So what it kind of sort of the flip side of that is, you know, you might be over budget and over time and the project might be successful or seen as a success. But then that always begs the question, but what about the planning? Right? So all the often millions, sometimes hundreds of millions, very often also decades that have been spent on coming up with a number and coming up with an opening date or go live date, you know, what was that for? And did we spend that money wisely, come up with completely unrealistic numbers. Right. So, you know, you often see project, project success. But you know, some people say since a project management failure, not entirely sure about that, but you probably can often say it was definitely a planning failure if these things materialize in the end. And then to your flip side, as in, you know, projects can be very successful, but so then somehow, you know, they don't generate the value and so they can be on budget and on time, but they don't generate the value. And then you look at this and ask the question, was that worth it? One of my favorite examples of this is that in Germany, a supermarket chain called Little, they built a big IT system to digitize their accounting. They spent half a billion euros on this. And, you know, and the system went live and it won all the awards in the industry. You know, the system integrator gave them the award for being the best customer of the year kind of thing. And it took one CEO and 15 months after go live, the system was, well, the announcement was, nope, we're not going to do this anymore. The system will be retired. We're going to write the investment off. You know, it was a project management success, it was an IT development success, but it doesn't fit the business. Too many compromises were made and they just, you know, walked away from it. You know, today you see exactly the opposite of the Sydney Opera House. Yeah, absolutely. Now if we, you know, if we think about the biggest lesson of all the research you've done in the last years, and if we step back a little bit from specific frameworks or methods, what is the most important thing that your research with Bent has taught leaders about large projects that you think they still do not fully understand when you talk to them? Yeah, and I think the first one is, I think one of the big things we obviously looked at was how often we are correct with our plans. So when we look at our big database now of more than 22,000 projects across all sectors, from IT and organizational change to classic construction, transportation infrastructure, energy, defense projects, so, you know, anything you can think of or we can think of, so 22,000 projects, sort of some. What we see is, and I think one of the core elements of that is how many projects deliver the NPV or the business case they promise to deliver. So when we look at, at the data, we see that sort of 1 in 2 projects delivers on budget or better, but only 1 in 12 projects, about 8% deliver both on budget and on time or better. And once you take the benefits as least as they're measurable, that's a different question into account as well. So you ask the question, okay, how many projects deliver not only on budget or better and on time or better end on benefits or better, then that is about half a percent. So 1 in 200, 1 in 250 projects, depending on the sector, that deliver all these things together. And I think that's sort of one of the key empirical contributions from our research to actually show, you know, it's really difficult to deliver these projects. But at the same time, our own research shows that about half of projects in the end can be seen as a success. So they deliver sufficient value compared to what had been invested, regardless of the quality of the planning. Planning that could have been honest or dishonest because we all know sometimes everybody knows that the budget is underestimated because the project has to start right. So how do you, what kind of learnings do you get from that beyond the, you know, if we add everything compared to plan and we compare the triple constraints and all of them together is only half a percent, what else did you, did you learn that you think would be of incredible value to improve both the success of projects, but also the way we use our resources and help us increase the ROI we get from the resources we engage? That's true and I think there's a very important element there. One is that there is actually something about setting projects up for success. And there's not only our own research, but also other research that investment in the planning phase pays back quite significantly. And sort of for our, for my latest book, the how to Measure Anything in Project Management, we looked through our database and seen that most projects invest between sort of around 3 to 5% of the total cost go into the planning of the project. And the better projects that actually are, you know, even on our measures of delivering on time and on budget and to benefits, the ones that invest somewhere between 20 and 30%, those actually perform better. So there is some value in how does it work in a. So is this because you're working mostly on very large projects or would it also apply basically, are you against Agile, let me ask it, or do you mean by that that for instance, developing a prototype or an MVP is part of the planning phase, just a different way of planning? How do you think about that? As we all know, I think it needs to fit the project and I think that's the main lesson there. Even if we look at, we looked at everything, particularly in for instance sort of from smaller scale to larger scale projects. And I think with Agile, the one thing that is, I would completely disagree with is the massive push to immediately start doing stuff without thinking too much. You know, one of the big things that comes out of this is this mantra that think slow, act fast. And I think sort of when we did the research it goes back to actual IT projects. But building the metro in Madrid, where the team had the beautiful lesson learned that in order to excel, accelerate a project, you don't Skip planning. You don't accelerate projects by cutting the front end shot and just get shovels in the ground. Start coding, you know, those kind of things. In order to accelerate a project and be as fast as possible, you actually have to think for longer or think harder at least. And I think that's sort of what you know, if you think about agile, if you have the interpretation that only just get going, let's get going, don't do the planning kind of thing, that's when I think that's what I would disagree with. And do you think it applies the same way in all kinds of projects or do you recognize that? I don't know. If you're developing an app, for instance, things could be a little different. You start vibe coding on day one with your idea. You iterate this way, you think as you build, would it make sense? And of course I do realize that if you're building the metro of Madrid, starting to dig without even thinking about anything is probably a crazy idea that no one would actually support. We recently sort of together with my colleague Harvey Meller, we looked at a really successful nuclear project. A sector where sort of success is even less obvious and frequent. You know, it's definitely not the norm, but there you have an industry where from an idea to starting a project, it will take six years anyway because there's so many approvals and regulatory things you have to sort out. So you know, you can't go any faster than that. And so you have six years of preparation. There's the question, how do I prepare very well. And the interesting thing about sort of these ideas now, you know, we can be much, much faster. And as you said, right. We can vibe code, we can do amazing things. Here at the university, I was looking at a hackathon a while back where you, you it's amazing kind of apps and how you can create ideas and make them into software in a single weekend. Yeah, and it's really, really impressive. But then there are some elements to that, you know, when we are thinking and sort of also looking at some of these project is, you know, what's the technological debt we are creating with these projects? So a lot of the governmental projects we looked at, particularly in the public sector that had a big focus on MVPs over the last few years because, you know, you know, why should we do all of this? Just let's do the MVP and nothing more, you know, we have got something to show for. While cost pressures are on the public sector, suddenly you end up with a lot of technological debt. In the system. And probably the same thing with vibe coding about questions of, you know, now that we have a solution, how does it scale? What does it do to our security requirements and so on? So there are some kind of like, you know, making progress rapidly, but also thinking about the fundamentals that these projects are built with, you know, sustainability and operations and future safety in mind. That might fall a little bit under the bus if you go too fast. Absolutely. Okay, Alex, if we shift gear a little bit. One of the big lessons from your work is that once projects reach a certain level of scale and complexity, and we're working a lot right now at PMI on complex projects. Right. And then try to understand what is specific to complex project beyond saying they are complex. Right. So once you reach a certain level of scale and complexity, they kind of stop behaving like simply bigger version of small projects. Right. So what in your opinion fundamentally changes when you move into this category of like super complex giga projects or that territory is the main shift. Technical, organizational, political, systemic. You know, at one point you have to change the playbook and not just add more people, more money. Like it's. It's really different. Yeah, and you're absolutely right. And I think there's some really interesting inflection points, you know, So I think somebody once described it to me, sort of reflecting on this and I thought was lovely because it was a practitioner putting it into words that a lot of academics have tried to, you know, identify because they look between what's the difference between complicatedness and complexity and so on, you know, and all those kind of interesting things about, you know, sort of a new aircraft is complicated, you know, versus mayonnaise is complex. Those kind of metaphors that don't really help practically. But this person, an engineer, was putting it into the words, and this was about construction projects and basically saying there is a certain limit. And he was putting it at 25 million sort of US dollars and saying project smaller than that, a single person, the project leader, can keep in their mind, above 25 million, you need a team to be on top of the project, and above 250 million. So if you multiply that by factor 10, then not even a project team can be all over the detail all the time. So there will be stuff that is not fully controlled. And that's when you start getting into this. And I think the interesting thing about this is we like to think human elements is one thing that makes things more complex. But I think the best thinking around this is still where does the complexity hide and it's often in the interfaces. So whether you have big projects, because there's know, because of big scale means, there's lots of people working on it. Oh, different organizations, vendors, suppliers, 200 companies, different cultures. Right, exactly. All of that. Right. So a lot of the risk and the uncertainty sits then in the interfaces. And, you know, the way we organize project interfaces are not owned by a single person. You know, there's always two people or two organizations either end. And so it's not, you know, and that's sort of what makes these things difficult and difficult to manage. It's interesting you mentioned thresholds. Right. And at pmi, we've been discussing this a lot and we feel thresholds in terms of dollars are not very relevant. They don't translate very well from one sector to another. And even if you think of construction sometimes building a data center, for instance, could be quite simple, could be a lot of money because it's massive. But not necessarily extremely complex. Right. So how we get to define what is a complex project is still, I think, think an area for research. If you want to research that, Alex, you'll be very welcome. Well, the profession, yes, we're working on it. Because one of the things, and I think my colleague Harvey, we're currently doing some research on this, is he put it really well. And, you know, it doesn't really help if you say this is complex. It's just asking the question, what makes projects, planning and delivery of projects so difficult? One could be it's big or it needs to go very fast, or it will last for decades before we do something. But then there's also the other elements. One is that it might be very political or might be very human. Think about a change. Right. And resistance to change and all those things. Or it might be that it's very emergent, so very uncertain. So you were just mentioning data centers. You know, sort of when you have projects that, you know, even if they're only a year long or three years long, you're kind of almost certain that the technology that you are thinking about today is not going to be the technology you're actually going to deliver. Because in some areas of the world, things are changing so fast. Yeah. I would actually argue that the longer the project, the more complex. Right. Because the environment is going to change and it creates a lot of uncertainty and needs for reassessment that you would probably not have if you manage to deliver quickly. That is true. That is true. And then there's a kind of a question about how could you accelerate these projects. So we do know and, and we've known for some time now and there's some good statistics out there, particularly from, you know, if anybody remembers function points, you know, in the IT industry that was a big thing in the 2000s and before. But great insights from that is that if you have an IT system even back then that about a third to almost 40% of all requirements change within 12 months. So if you have a three year project, all the requirements will have are different from what they were three years ago when you started the project. Not necessarily all of them because some of them will renew several times. But yeah, we see the point. It's like a very quick decay in the specs, relevance. And then sort of you plan that forward, right? And then sort of even in other areas not in it, but if you're in construction or transportation or energy, right, where things take almost a decade to deliver, or planning and deliver and so on, then you know, a lot of things will change. And I think that's a very good thing. And you know, a lot of our research is about us and how good are people at planning things and forecasting things. Let's talk about that, Alex. Forecasting, right? Because you've done a lot of work around forecasting. So I'd like you to share with us what are the pitfalls of forecasting? The pitfalls of forecasting. Well, we just already talked about time, right. And Philip Tetlock once put it so beautifully, sort of when you ask a forecaster, you know, next year is probably going to look a bit like, like the current year, you know, and then the year after, like that. But three years out, any forecaster is just like he said, a chimpanzee throwing darts and always like that kind of analogy. I was always hoping that we're a bit better in project management and project planning than they are. But sort of the big pitfalls as we see them is kind of threefold things. And one thing is that it has to do with our tools and our methodologies. And we, I like to again borrow a term there. So Daniel Kahneman called it the what you see is all there syndrome. So in project management we have a lot of kind of like tools that require you to identify things correctly. You know, sort of if you do risk identification, for instance, or you know, you do your work, breakdown structure, if you forget things, you can't, that doesn't feature in your project plans. So that's the what you see is all there is problem or syndrome. And then second thing that we've known for a long time the Junes are optimistic. And there's the planning fallacy that we do underestimate how long it takes us to do things. You know, that happens to every one of us on a probably weekly basis that if you write your to do list on a Monday, by Friday, you know, there's still items there that you haven't gotten to. And you know, in the next Monday, you start again with a great hope that, that this week you will get through all of your to dos. And you know, that's something we struggle with sort of really understanding isn't how good we are at. Yeah, sort of we are underestimating how long it takes to complete tasks. We're too optimistic about these things. So there's a lot of psychological influences. And the third one is, of course, and you mentioned that earlier as well, you know, sort of there is, you know, the governance systems we build and also the project selection systems and portfolio management systems that we often have in place. They not some that push for realism these things. You know, sometimes it is just about getting the project to go. And so you refer to these kind of slightly political estimates early on. And that's sort of kind of the third big thing that we're not. Is that something we should fight or is it in a way a good thing? Because in the end, if the project is great. Right. Does the. The end justify the mean? Right. So in other words, what do you think about that? Well, you know, there's of course, then a kind of a question about isn't, you know, what are the opportunity costs? Right. If you do one project and not project, you know, we're making a judgment, we're making a value judgment about why is this better to do than to do the other thing. So there is, you know, that there is a moral argument there that we're trying to be fair and just in selecting which project gets done and which doesn't get done. So in a sense, you know, is that a competition between who is best at representing their project in the most advantageous light and then realism comes on through later? I think there's, there's a moral, moral argument there of why we should actually be more realistic. And there's also quite clearly a business argument there because if we're looking at some of the big downfalls, you know, sort of say, for instance, Westinghouse went bankrupt over Vogtler in the UK here, our largest domestic construction company, Carillion, went bankrupt because of delays to their project and sort of they got startup of starved of cash because they missed some payment milestones on three different things. Right. You know, this has, can, this can have real consequences. Alex, you, you speak sometimes about the early warning signs. And you know, in this industry we, we love to talk about the, the, the watermelon effect, right? So like all green outside and then when you dig into it, it's like red. So how do we, how do we avoid that? Like, what are the. And if you're not the project professional, but the sponsor, the leader, the people who fund. Right. Or even a project professional who tries to do a job with a lot of honesty and as you said, a moral compass, how do you see these warning signs? What are they? Typically, we've done research last year and continuing that research, and the interesting thing is that we found is we started looking in IT projects for that. And the single biggest red flag that our data showed was the idea that my project is unique, you know, so if people involved in the project, whether it's your vendors, your suppliers, your project team, your experts say, well, this is unique, the single biggest warning flag for having a massive cost blowout. And same thing, sort of on another dimension, if Ufiz, you have a project and there are some gaps in the project team, so some critical functions are not filled, you know, or sort of, you're not entirely clear who's going to do that, then that is the indication of a massive delay. Another factor over there is on the schedule side of things is, for instance, if you're struggling to really involve users and subject matter expert in your IT project, that's another big warning sign. And I think the interesting thing about that is sort of we can talk about that uniqueness trap or uniqueness bias as we called it, but the other interesting thing about this is these are kind of warning flags that are typically not part of your project reporting, you know, sort of they're kind of weak signals in a sense. They're not strong signals. Yeah. For instance, what you just mentioned, which is common sense, like involving stakeholders, which is one on one, one on one learning for anyone who's like studied under PMI's guidance. Still, in most reports, you don't really see that, right. How much stakeholders have been involved. If you ask the question, you'll get an answer, probably really qualitative answer, but it's not usually very well measured. No, it's not. Right. And now you think about this in sort of the latest PMI research on the Moore practices. You know, we've seen from the research that the PMI has done over the last couple of years, that these are actually linked to project success and generating value. But then the question is, you know, if you were now to sit in a steering committee or you sit on the project board, you know, is there a system in place where you actually can evaluate whether these practices are implemented and happening on the ground? Absolutely. You did mention earlier in our conversation that very few projects get stopped, which I thought was an interesting comment you made. So what, in your opinion and based on your research, what separates the situations where we feel the project can still be turned around from those where we have to, you know, basically we're in slow motion failure and we better stop. Right. How, first of all, how do you identify those cases and then how do you actually make it work? Because there's always this confirmation bias. Right. So like people hate stopping something that they've invested time on. Right. And resources in, starting with CEO. Right. It's very difficult to admit that you're going to pull the plug. Yeah. And. Exactly, exactly. And takes forever, you know, So I think the sort of great case in research has always been the Denver airport, you know, which tried to introduce this baggage handling system that didn't quite work. But it took 8, 18 months to change tech in the project. And people first needed to really realize that it's not going very well. So I think that's the kind of the first step is, you know, you create some honesty about how the project is going or not going. And that is difficult to accept because it is challenging the people in the project. And then once that realization has set in, the next step is to actually show them that there's a better way, there's an alternative to just going down the same path. Path and creating that alternative with whatever it requires, technical studies, experimentation, task forces and so on, just to show a way out of this mess. And then you can sort of shift over to a different course of action. And that's hard. And that takes a lot of time. Sort of that kind of the power of the pause of a project. It's hard to do. And I really like this idea that, you know, sort of of here in the uk, in the public sector, for the very big projects, you get appointed and you get an official appointment letter. And in that letter, which basically is congratulation, this is your project now, this is where it stands. And so on. Whenever a new leader comes on, it offers in a period in which they can say, I'm coming, I have a fresh set of eyes. I've looked at this project now and I think we need to change something, we need to reset this project. So there is kind of like, you know, you have a specific amount of time, a month or two to just say no. And before, you know, I'm, I'm now responsible for this. But I can honestly say this is not going where I think it should be going. So we need to pause and replan rethink the project. And I think that's something rare that very rarely happens in the way we've set up projects that you really test projects regularly. Are they still fulfilling the mission that they were initially set out to achieve? And do we then have sort of the governance in there where people actually call for rethink, pause or even a full stop of a project? And as we both know, true abandonment rates are relatively low, so they're probably highest in it. But you're right, I mean, you mentioned more PMI framework based on the research that we mentioned before about project success. And the R of more is relentlessly reassuring. Assess, which is exactly what you're talking about, right? Constantly making sure you have a proper reassessment of whether you are going to deliver value. You're spending the right amount of money for that and if needed, make some adjustments to the scope, maybe to the schedule, and negotiate all of that. Not always easy, of course, depending on the project. Sometimes you're very constrained by contracts, by regulations, by decision made. But it is very important that at least you know what should be done. If you have any hope to change things at least, you know, Alex, I would like to talk a little bit about leadership versus systems and structure. Right. So when you look across all the projects you mentioned 20,000 projects, I'm sure you haven't yourself personally looked into each of them, but you've seen a lot and you've seen patterns. In the end, do you think that what matters more in terms of project outcome, success is the systems, the quality of the systems around the project or is it in the end the quality of leadership and the behavior of leadership? I think a little bit of column A and a little bit of column B. I knew you would say that. Right, but how do you know? I know, but let me explain. Right, so I think very often you can see sort of here's a great leader, but they are working in an impossible system. And so sort of they can't actually do what they want to do. They're constrained, as you already said. Right. Sometimes it is we the car crash coming, but we can't do anything about it because the project is set up as a system that just plows on regardless. And, you know, you can be a great leader in that kind of situation and you still end up in a car crash and nobody's going to be happy. And so I think it is about the system, but that means that the project leaders, they are actually responsible for that system. You know, they own that system. Exactly, exactly. That's what I would say the greatest responsibility of a leader, of a great leader is to create a good system. Right. And to leave as a legacy a great system that others can benefit from and then not just count on your personal talent, charisma, ability to, you know, sell anything to anyone. Right. Or convince anyone. I know. I mean, that will always crash in the barriers at some point in time. Right. So, you know, sort of the, the pull of these systems is strong enough. So actually thinking about us and, you know, and changing, you know, the operating environment, the system, the governance structure, the architecture, the organizational structure of a project, that's kind of the core thing, but also recognizing that depending on the context in which you work. Right. So as a leader, you don't always have the full degrees of freedom. You can't change everything. You're not allowed to change everything. There's some choices you can make and a lot of choices you can't make and sort of really realizing what those are and how to work with them and how to work around them, that's kind of the art of leadership. So it's less about, you know, giving the firebrand speech, the Monday morning meeting, or the daily standup. It's often, you know, what good leaders do is the quiet work of structuring projects, structuring the system, working the interfaces, you know, sort of being the people that shape how the work gets done in the project and creating an influence and a legacy through that kind of work that often goes, goes. It's not very often recognized because everybody just looks at the progress and the output of projects rather than realizing sort of the system work that also goes on. Yeah. Are there things that you think project leaders need to unlearn based on everything you've seen? The first thing that we kind of really started off with today is about as long as you deliver on time and budget, everything will be fine. I think that's something to unlock, learn, and really asking that kind of question of, you know, what is, what is the value? What's the value I want to leave behind? What's the long term contribution I want to make, not just to the organization I work for, not just to the project, but also say for Instance to the profession of how you. You know, so what's my legacy and what's the legacy of my project because of that? I think that's the first element of this sort of. It's that wider thing. The other thing I've seen many, many times that is really difficult is that if you're a project leader, many project I meet our courses at the university but also in our research those have come through a rank of specialists. They're often engineers, they're computer scientists, they're chief medical officers, you know, they come through specific area. And the biggest kind of crunch point there is sort of the moment of unlearning is that once you're a project leader it's not your job anymore to do the work work but it's your job to get the work done. And that's a really hard thing to unlearn. Right. So it's not that you know, you need to do everything, you need to be over everything and sort of you need to make every single decision is kind of project is, you know, if you don't want to work 24 hours a day and probably you know, threaten your mental health and physical health in the process of projects because they are stressing for it's your job is to get the work done, not to do the work. So how do you work with your team? So how do you create teams and empower teams etc. That the work gets done without constantly landing on your desk or on your inbox. And that's a really difficult thing to unlearn. If you have come often through that kind of specialist, you know, sort of. I've been doing the work for many, many years now I'm in the project leadership position. I need to unlearn that. That's the hardest thing. I think that's the biggest struggle. I see a lot of project leaders to grapple with and there's a balance to find, right. Because at the same time if you lead but you're not hands on enough and you're too far away from the realities, then you're not very effective either. Right. So there's the right balance to find between being able to delegate a lot and create the system where things get done without you, but also your ability to stay really up to date with what's going on and if needed, roll up your sleeves and go help fix specific problems problems. I think it's the same problem for any leader, same for a CEO. I don't see any massive difference here. No, it's not. It's not, it's not. And I think this is in sort of where it often shows up is in the quality of conversations, right? So if you don't really know anything, then you can't ask any good questions, or at least not questions that matter. And so I'm sure that we all have been in project boards and steering committees where various people have just asked completely nonsensical questions because they don't really understand what's going on in the ground and they can't really read what's going on in a project, you know, and that infuriates everybody. But as a leader, you know, sort of when I'm saying, as you know, it's not your job anymore to do the work, but it's your job to make sure the work gets done. And also knowing that the work gets done so that, you know, doesn't mean you're hands off and, you know, sort of your work is now completely different. And that's a big challenge. You're absolutely right. It's a big challenge, you know, sort of to sort of know where to look, know what questions to ask, know what help and support to offer when it's needed, know when to change course or nudge people in the right direction without, yeah, taking over their judgment. And that requires, you know, both are kind of like higher level thinking as well as in sort of the being being actually in the details and understanding the details and what's happening in organization and the technologies and all those good kind of stuff things. Alex, I'd like to finish this conversation with AI. AI and the future of project management. So AI we're seeing this, right, is changing completely. How projects are planned, monitored, managed, what people do when they do project management. It also forces us in a way to rethink the role of our profession, what we're accountable for, what we actually do day to day, day. It's changing how information flaws operate, how decisions are made. And so from what you're observing, how is AI transforming project management? Are you already seeing it, especially on these very large projects, like what are you observing? So we see some big changes, of course, in IT projects, as you already mentioned earlier about your attempts to vibe code. And there we see a big, big explosion of productivity. And we see the same thing in engineering and design tasks and so on, where AI is completely revolutionizing what we can do and it's already there. I think there's some, you know, as we always say, you know, sort of we're sometimes overestimating the immediate impact of a new technology but completely underestimating the long term impact of a new technology. So there is something I think fundamental there in terms of how AI is going to shape the world of project management. Management and project management and projects in general, often not sort of, you know, the first people to adopt new technologies and adopt new innovations. And innovations are very hard to come by in this particular sector or way of working. And so it's a little bit hard to see, isn't that, you know, we've not seen people really jump on the bandwagon and sort of probably embracing the technology to its fullest extent like other industries have, other sectors have so far. And so, you know, and yeah, so I do think it will be quite disruptive and very. In shaping our profession in the long run. Even though we're currently just more or less in that experimentation stage of what can it do and what can't it do. But we do know it's very good at organizing information, it's very good of automating tasks, it's very good of also supporting the decision making. So thinking about as in, you know, how is it augmenting the work of a project leader and sort of as in how can AI help me of doing stuff that I is not particularly value added? I think that's an important thing I always think about. You have a master degree at Oxford, right? In project management. How have you already changed, transformed your courses, your learning, learning to embed AI in everything people do. If you have. I'm just curious. Yeah, I mean universities are obviously even slower moving than the project management profession, you know. Yes. Yeah. Because professionals, you'll be surprised. Alex, like a lot of. So we have, we had already more than 1 million people taking our courses. I see from my standpoint many product professionals using AI and actually moving from AI, AI like ChatGPT to improve your emails. Right. To actually agentic AI and getting things done through AI. And I'm seeing a lot of AI also being embedded in project management software now. So it's becoming, in two or three years the progress made has been quite significant. And of course many project managers are involved in AI transformation projects. Right. They have to lead AI transformation projects. So much money is going there. So I'm not as, maybe as cautious as you are in terms of the adoption by the profession. I can see where in very large infrastructure construction projects, maybe that's a little slower, but I feel that our profession is actually embracing AI fairly fast. I was wondering your students, they're typically maybe thinking about, usually you don't do this when you retire. Right. A master degree. You did this earlier in career. And so how do they perceive that? Are they really very motivated in learning how to apply, use, I don't know, cloud, cowork, or, you know, all the tools that are out there right now that help you actually do things beyond even learn? Yes. And sort of, you know, what you're saying is, you know, we're seeing big, great adoption in sort of particular administrative tasks, I would call them, you know, sort of even. You said there's some construction projects. Maybe not so much, but in some projects it's still the job of a project leader to sign off all the invoices every month. You know, it's bonkers. You know, why should they do that? That, you know, and sort of some really interesting tools exist and you can build agents, and these days you can build your own agents very, very quickly. Right. It takes less than help you go faster through all of that. Just like I do myself. Like read all my emails of the last 15 days, make sure I followed up on everything, if not help me do it. You know, Like, I think the, the really interesting challenge is, and there was some really interesting research by the new Bureau of Economic research in the US last year, so end of 2025, which shows that they did productivity improvement statistics on AI, and particularly you have generative AI, and they saw that on average it's 40%, 40% more productive. Yeah. I would not today write a project charter without using, for instance, PMI Infinity. Right. Which is our tool that helps you do that. We have an agent doing that just by conversing and improving. I think that should be a normal habit that we'll develop. And the same thing if you want to sort of analyze where your project is at. Right. You don't click around with Excel anymore or you just converse with the AI and then sort of it generates those insights. You inherit project size, like 1000 files, Excel spreadsheet documents. You put all of this in cloak, go get a coffee and when you come back, gives you a pretty good sense of what's going on. Right. And where to look. I know. And then you get Nano Banana to make a presentation out of it, and you're going to your steering committee. Right. You know, so I know, it's so good. But the other interesting side, right, Sort of individual productivity up by 40% on average, but at the corporate level, only 5%. Yeah. So it's a really interesting thing. So we had that. Learning how we play together. Absolutely. Yeah. Yeah. So how do we scale? How do we scale AI from individual productivity to really transformative impacts on corporations. And I think that's that's the next big stone or the next big step that we need to achieve. And that's. Yeah, I think that's going I mean, it's going to happen faster than we think, and it's probably going to happen in a couple of years time. Well, the next few years. But that's probably the most exciting development to really watch out for and to work on. You know, how do we make that how do we translate that individual improvement into really differences that makes the corporations. This is a wonderful conclusion to this podcast. Thank you so much, Alex, for your great insights, for your kindness also to come to my podcast. Thank you you very much. Thanks so much, Pierre. Thanks so much.