Podcast: Play in new window | Download
Dr. Alexander Budzier is a Fellow in Management Practice in the Field of Information Systems at University of Oxford’s Saïd Business School. Dr. Budzier’s research focuses on the challenges of managing projects, not just in the field of IT but also in energy, mega events, hard and soft infrastructure, and organisational change. He also teaches and develops courses on project and program management, systems thinking, and risk management.
At Oxford, he directs the Australian Major Projects Leadership Academy and the Hong Kong Major Projects Leadership Program. He also regularly teaches on the MSC for Major Program Management, the MBA programs, the UK’s Major Projects Leadership Academy, as well as other programs for private sector organisations.
Dr. Budzier also works with private as well as public sector organisations to build their organisational and individual capabilities so they can master the challenges of working in and around programs and projects. He completed his doctoral studies at Saïd Business School in 2014. Prior to joining Oxford, he worked at T-Mobile International and was a consultant at McKinsey’s Business Technology Office in Düsseldorf and Chicago.
If you’re interested to know Dr. Budzier’s thoughts on strategic planning and goal setting, don’t miss today’s episode. In addition, he also shared the pain points of managing and communicating goals and gave valuable advice to leaders and project managers in the industry. So many gold nuggets in today’s episode, so don’t miss it.
Read the Transcript Here:
Welcome to the Construction Goals Podcast, where industry experts and leaders reveal the good, bad, and ugly about strategic planning. I’m your host, Santosh. We will dive into the who, what, when, and how of goal setting in construction projects. Most importantly, why you should care. Whether you’re a seasoned leader or a budding entrepreneur, you’ll discover something new in each episode about how to manage goals better in the challenging world of architecture, engineering, and construction. Let’s get started.
Santosh: I’m delighted to be joined by Dr. Alexander Budzier, who is a fellow in management practice in the field of Information Systems at Oxford University’s Saïd Business School. Dr. Budzier’s research focuses on the challenges of managing projects, not only in the field of IT but also in hard and soft infrastructure, energy, mega events, and organizational change. Alexander teaches and develops courses on project and program management, risk management, and systems thinking. At Oxford, he directs the Australian Major Projects Leadership Academy and the Hong Kong Major Projects Leadership Program. Alexander works with private and public sector organizations to build their individual and organizational capabilities to master the challenges of working with, in, and around projects and programs. He completed his doctoral studies at Saïd Business School in 2014. Prior to joining Oxford, he worked at T-Mobile International and was a consultation with McKinsey’s Business Technology Office in Dusseldorf and Chicago, where he advised clients on IT and operations issues. Alex, welcome and thank you for your time today.
Alex: Well thanks for having me.
Santosh: So, I saw the term “mega projects” pop up several times in your articles and I’m curious, how do you define a mega project or a mega event?
Alex: That’s a good question. A lot of stuff that we research is practically interested in the things that are difficult, it’s strategic and transformative and so on, because we think that real added level of complexity once you get to this kind of scale in projects and I know all sorts of different definitions that are out there and some people have suggested, for instance, that everything that’s more than a billion dollars but, quite frankly, we’ve studied projects of all size and also duration and we kind of find that there’s a lot of difficulty attached once politics and transformations come into play. So, in the normal space of construction and large transport infrastructure, for instance, you often have to spend billions to have so much impact on the community or a country or an economy and in some other projects, say for instance, in IT or in constitutional projects then you can have similarly transformative impact for a few million spent, it’s kind of – I mean, mega project sort of seems to suggest size but when I look at it, why we gave it that name was really to highlight a little bit those additional challenges that come with big scale.
Santosh: So the complexity is really the defining factor?
Alex: Yeah, the complexity is really the defining factor and I don’t really like the word “complexity” either because, as we always say it’s complex and I think there was a lot of space and conferences wasted in the 1990s just sort of teasing out what’s complicated and what’s complex and all of that and I think generally in projects, so the term comes with a lot of baggage, right? I think “difficult” is probably the better word, right? Stuff that’s just difficult, right? But you can think of, okay with all the great management in every project organization that I worked with or that we study they have project manuals and handbooks coming out of their ears, right? Not all projects are successful so at that juncture when you ask yourself the question, so why not? Why is there all these great handbooks and all these cool tools and it’s not fully getting us where we want to be and then sort of the question is why is that? What makes it then so difficult that we can’t manage it like a team or like a scientific problem so it becomes this kind of sociopolitical animal that we have to deal with?
Santosh: Right. So, how long have you been in the construction industry and how did you come to the construction industry?
Alex: Well, that’s very funny. So my background is in the IT industry and I was working for many, many years mostly on turning around failing IT projects and one of the things that always bugged me in big IT projects was that they never do any frontend planning, right? They sign off on like massive, company-tied projects and maybe, if they’re really diligent, sit down for six months and plan, right? And I always thought this is just insane, so, together with a couple of colleagues, we then started looking into other industries where there’s a little bit more discipline, a little bit more rigor around the planning stages and so you get to oil and gas and manufacturing projects where frontend loading is a big thing and in this space we also stumbled across some work on transport infrastructure projects in a book called Megaprojects and Risks and I then decided to work with the author of that book, Bent Flyvbjerg, who was then a professor in Aalborg University to sort of learn more about what’s going on in transport infrastructure and that industry to see whether we can learn any lessons for the IT industry and so that was my first touch point and that was twelve years ago and out of that then really given interesting opportunity to join Bent and his research team here in Oxford and really set up an interdisciplinary center to work across all industries and as you said earlier in my little intro, we’re now looking at things like big games, mega events. We’re looking at things like energy projects which of course they have a lot of construction in them but also things like military and defense acquisition projects, projects in outer space and so on, in IT as well, and normal civil engineering and normal construction projects too, so that was the first research idea on really trying to understand how do they do planning in the construction industry. That was twelve years ago. And then I had a great joy with that research team actually going out and seeing my first mega project and I think that was 2013 so nearly six, seven years ago when we ran around Europe’s largest dam in Iceland, massive dam project, massive hydroelectric project, and that’s when the bug really got me, right? And ever since, I’ve been working with lots of organizations and operators in the space of construction but also individual projects and I find it absolutely fascinating.
Santosh: That is fascinating that you came to construction to sort of learn how construction, oil and gas does planning and to translate that into some of the IT world that you’re in and I’ve seen now almost the reverse, where in the AC industry they have the tremendous appetite to learn from not only technology but other industries out there. So do you actually feel that the planning process in construction is more mature than what you have seen with other industries?
Alex: I think it’s more mature in a way that is a bit more structured and people actually know what they have done in that planning, although I doubt that very many projects ever get to that point. In theory, they would know when they have done enough detail design to actually go, but most projects start earlier than that which is part of the problem, so, yes, I thought that was kind of interesting, and then you also think about the execution phase of things, so a lot of that is also interested in some what happens after the planning and how you execute this and what I found quite interesting now is that these two fields rapidly merging and with all the digitization of construction and BIM and robotics and MI and all those emerging trends and we’ve talked a lot more about IT in construction than we’ve ever done before that is a very big field. I’m really glad that my two big interests really start to fuse together and I find that actually fascinating so I do think, yes, absolutely IT projects can learn a thing or two about the diligence and the insistence on doing from planning and good quality designs that come from oil and gas and construction. At the same time, I find it absolutely fascinating to also look at what happens after you start a project and the scary thing that I see is that even the flipside when civil engineers get up to manage the software implementation project when a bunch of railway engineers get together and try to write software for train automation or signaling and stuff like that it always seems to go horribly wrong. So there seems to be also sort of the second thing around, that once you start – I would not trust a developer or an IT person to really deliver the construction project, at the same time. I don’t wanna trust an engineer to deliver a software project, right? It’s kind of a funny world where suddenly these two industries that have always sort of worked side by side have to intersect and work together and so it’s exciting times because it’s also not going very well.
Santosh: So our focus in this series is a subset of planning which we’ll use strategic planning and strategic goals. I’d love to hear, in your experience, how have you seen leaders of construction projects approach strategic planning and goal setting with their teams?
Alex: A lot of our research and the end goal of the perspective where we are coming from is a little bit around – originally we’re particularly interested in how do people make the decision to select the specific project and start with it and what are the promises that senior leaders make about the project. So we’re particularly interested at the very highest level of what are the costs and what’s the schedule and what is the benefit that come out of large projects, and how does this decision stack up to reality when you look at the end of the project. So, that was sort of our big interest in the first instance, so looking at sort of this very, very high, topline level of project goals and then thinking around and that’s our perspective and a lot of our research comes from then looking at the risk and the uncertainty behind these goals, so what’s the uncertainty that matters and that might stand in the way of our strategic objectives. What I find quite interesting to see is what I see at the moment is really when you, particularly in the frontend, when you sit down and we get some sort of more or less well-articulated benefits that somebody has an idea for a project, right? You got some sort of nebulous statements of why do we wanna do this? Well, here’s the purpose of the project. And then I often see this process where, okay, someone needs to go in and break those benefits down and make them a bit more specific so define some user requirements off of this and then somebody else comes in and translates those into physical and intangible deliverables so the project’s scope and then you go in and sit down and think through how that’s going to be delivered so what should be the project methodology, what is sequencing, what are the activities, what are the other factors, the bills of materials and all of that, and then people sit down and do cost and time estimate and so I see that kind of classic cost engineering type of world, instead of setting basically aspirations, ambitions, goals for the project and basically coming up with an integrated view of taking what seems to be a good idea or, “Yeah, that makes sense, let’s do this, so here are some benefits that we want to achieve,” and then getting all the way down through design, through programming, down to the level of, “Okay, here’s the cost frame and here’s the time frame for this project.”
Santosh: Right, right. And, so, from a perspective of defining and communicating and managing these goals what are some pain points that you’ve noticed? Where is the pain in this process?
Alex: I think the pain in the process is that, A, this process is very, very slow, right? So, this process takes a long time to do and with that come obviously a lot of different changes over time, so I think the two pain points is that this whole system that we have built up on how to get from an idea to a good project plan and a good project budget and all of those good things and then starting the project to execute against this. This whole process is pretty inflexible so I think that’s the first thing, right? That things change and quite dramatically so along the way. The second thing I see is we have to deal with, as always, we deal with people and in any project of a critical size, you get politics and negotiations in this so one assumes you sit down and think through, so what’s my project methodology, this waterfall kind of approach, what’s my project methodology, somebody will start and picking and change the rules of requirements, right, and then you have to start again. So that’s kind of the second big problem that since there’s all these loops in there that make project, even if it wasn’t often rushed and there were sort of external changes, there’s also a lot of changes that generate for this.The third problem is that we often have to skip a lot of these steps so we have to fill in some of these gaps with a lot of assumptions and so this is our goal, say for instance a simple goal like the project budget, right? If you don’t have a detailed design, how can you really give a budget with a certain level of confidence, and so, typically, because people ask for these very bottom line outcomes of cost and schedule estimates a lot earlier than sort of our typical methodologies allow us to give them a good answer we have to backfill our answers with a lot of assumptions and a lot of these assumptions never come true so, that is another massive pain point. And the outcome of all of this, of the uncertainty, the changes, the emergence, and all the politics around these things is that it’s really hard on a project to keep them all integrated and aligned, so the benefits somehow correspond to our cost estimate and to our schedule estimate and if things like scope or requirements or the delivery methodology of the project change that can quite often really trace them back how do our goals change or how should they change, right? Are they still realistic? Can they even be achieved in this new world? And that is really the fiddly-ness of all of these systems to really trace all those dependencies through. I think that’s what a lot of projects struggle with and therefore they don’t really have a clarity of goals so when you then get into execution and you then have a very large project organization, not everybody knows exactly why they are doing what they are doing at this point in time and how that feeds and helps the overall project to achieve their goals so it’s the integration amongst all the different goals and all the different dimensions by which you can measure goals and then you have all the admirable ones on top as well, but also, when you break it down into overall of what you have at the program level and then you get to a large construction project with maybe 4,000 people and 30 or 40 contracts running or something like that, then suddenly you find it’s really hard to make this whole pyramid align and that is really challenging.
Santosh: So, I wonder if you’ve seen the approach where perhaps a project manager says that “I have a detailed schedule, I have my budget, I have my team structure,” so what’s the real value in articulating the strategic goals and benefits that you’re mentioning? If you have all these artifacts, isn’t it enough to use those and execute?
Alex: Well, to one extent I think there’s a great fallacy in assuming that every single goal will go according to plan because nothing ever does. You know? Planning is important but not the plan, or something like that, right? So, I think there’s great value in articulating all these things but then it needs to be a living and breathing system and that’s where a lot of the difficulty comes into steering this, more fundamentally what I think is really important and why this goal kind of idea is so important is that if you think about it, you need to build projects that can deal with a lot of stuff that might be emerging, a lot of risks that come into play or a lot of uncertainty and change, sometimes one of those fallacies that we often fall into is that somebody at the top might find all the solution just defines exactly how everybody should respond to this and gives all the tasks that they need to do and then once they do them correctly and quality and deliver them on time we all would be fine, right? Whereas I think some other organizations, they have better ways of planning, right? Instead of just defining milestones and all the tasks that go into those milestones and ticking them off whether you’ve done that, so basically some sort of like a to-do list planning like we do in most of our projects. Other approaches of planning are more capabilities or even more like the goal-oriented planning kind of approach and those types of organizations are actually a bit more resilient. I mean, bear with me with this example, but one of the organizational forms that’s extremely resilient and very agile and good at solving problems are probably terrorist networks. That kind of idea of you modularize a whole program of work by basically creating these cells of teams, only we don’t want to call them terrorist cells in normal projects, we typically tend to call them task forces or something like that, but when we organize things in task force mode, we tell people, “Look, here’s the problem solved, so this is your objective, there might be some secondary objectives as well like this is the time you have, these are the resources you have, there’s a specific element about what’s the quality and what’s the performance of the thing that you need to deliver at the end, but other than that, we’ll just leave you alone,” right? So we’re not going to go in and organize this for you and we expect you to simply come up with a solution that works. We talk about these things when we talk about performance with contracting or outcome-based contracting, and generally people are more excited about this than the typical project management planning out all the tasks and activities in a massive Gantt chart, which kind of always feels like micromanaging, instead of actually giving experts the feel and the way of working and to break it down and be independent. So, terrorist networks are one extreme way of thinking about this where that’s exactly defined in that way. A different way of thinking about it is, for instance, the organization into labs. How scientists tend to work, ideas picked up by the Google and the 3Ms of this world of organizing their innovation have physically given people the freedom and instead of managing by milestone, you manage by achieving goals and that is a different form of approaching projects and when I look around, particularly when it comes to innovation, driving change, doing things differently, solving very complex problems, or operating in a world where things are very uncertain or things constantly emerge and change so there’s a lot of ambiguity in things, that kind of management or that kind of leadership by objectives is much more effective than our default position where we go in and define 30,000 tasks and track task completion and roll them up to milestones and all of that good stuff.
Santosh: Interesting. And so you mentioned the word “resilience” and it goes into everything you’re saying, so it’s almost like your typical work breakdown structure and defining of tasks may create the illusion of having things under control but it actually creates a more brittle and fragile state but you’re suggesting that there is a way where you can align through goals and have a more organic, flexible, resilient kind of environment. Is that right?
Alex: Yeah, exactly, and with that comes basically that you empower a lot of decision making to the bottom and actually where the project work gets done and that makes projects go much, much faster so you have better time to market and all of that. For that to work well, you need to be very clear about what are the boundaries of each of these teams or these sub-teams and work streams or whatever they are, however we wanna call them, and so you have to define very well the boundaries and the interfaces they have with other teams and what they need to deliver, but not the how and that’s kind of the important thing in this way, right? One of the worst things or one of the things that always happened with work breakdown structures is that we take all the work and try to break it down and forget some stuff and the other thing that is really, really difficult is obviously the integration across all the pyramid structure in the work breakdown structure, because often we forget about the integration function and that creates a lot of problems, right? So, rather than sitting on the top and actually having this organic approach to this is mapping things out and breaking them into different units, whatever you wanna call them, cells maybe, and then seeing whether they make up all project so that should be the leadership work at the very highest level and create more simply I always hated this term. Whenever you do a project management course and I’ve done way too many on these, not toward them but through them, there’s usually sort of the joke when it comes to work breakdown structures and planning where people say, “How do you eat an elephant?” You eat it bite by bite or slice by slice. But I think that’s exactly not the problem because the problem in project management is always that we get presented with lots of different slices of the elephant and our job really is to take all these slices and put them together so that suddenly what looks a bit like an elephant comes out of it and that things are able to move afterwards. That is really the hard bit. The slicing is not the hard bit. The hard bit is putting it all together.
Santosh: Interesting. So, specifically in construction, Alex, do you think construction projects and large construction companies, are they doing this right now? Are they figuring out this resilient, adaptable way of planning or are they more stuck in the traditional work breakdown structure mode?
Alex: I think they’re more stuck in the traditional work breakdown structure mode. I haven’t really seen any projects that have done that very well, but then I’m also pretty obsessed with project failures and my projects have cost overruns and so on and there we often see sort of very traditional approaches to project management and, so that’s a really big challenge so I’m actually not aware of any projects that I’m aware of some projects that do this really, really well and you get a very oiled machine that really can execute a great work breakdown structure and some really good milestone charts and Gantt charts and all of that and they’re actually really successful with it, but I also see a lot of projects that really benefit from a different approach because as soon as it’s not quite clear how we’re going to deliver that, as soon as it’s not quite clear how we have to sequence the activities or if it’s not really clear what the deliverables are of a project, then sort of all these traditional system engineering construction management type of problem solving approaches and management approaches, they kind of really fail and that’s where I see a lot of projects failed, but in the world of construction, I haven’t really seen some of the other bits. So, I mean, there might be pockets in there, particularly if you think about where some people are using this is when you get to some architectural firms and they do some creative design thinking around some of those things, you see it in those phases but it tends to be very, very localized and so you find it there but you don’t really see it across the whole project from cradle to grave.
Santosh: So before we talk about kind of why that’s the case, let’s actually look at some of these examples of failures. I mean, what’s an example of a specific project where you saw a cost overrun and maybe that’s because of a gap of alignment and because they were going too far down this obsessive work breakdown structure milestone kind of thinking. Can you give us some actual flavor of what it looked like and what was their life like? Where is the pain in that environment?
Alex: Yeah. So, I think a good example because I spent a lot of time on that project was the Express Rail Link in Hong Kong. It’s a high speed train that links Hong Kong, specifically West Kowloon which is opposite of Hong Kong Island, the peninsula there, to the China mainland and it’s a small stretch of high-speed rail to connect into the whole Chinese high-speed rail network and it’s fully underground, it’s fully tunneled, which make it a bit more difficult or risky to do. In that project it was managed in a very conventional way when we looked at it and, when I first started working with the project, it had a very small cost overrun so they just announced a baseline shift of 10 percent and it was quite embarrassing to the XRL, to the MTR Corporation was the builder of the project on behalf of the government of Hong Kong because it was the first time that happened to one of their capital investment projects, so before that, they always very proudly delivered better than due time and this time, they had to announce a small cost overrun that later would grow actually a little bit larger and they also had to announce a delay of two to three years for the project. One of the things there that struck me was it’s a very complex project, a very difficult project, a lot of different contracts in the project with lots of interface issues and so on and one of the things there in the way the organization worked was very typical for a lot of construction projects is that they actually managed everything by the schedule, right? So, claims, unless they really need additional scope, would be handled through extensions of time. Project construction site managers or contract managers on these contracts, they would have their milestones and would have to hit these and only about four or five levels above them, somebody would actually put that together with the cost and then directly reporting to the head of projects at the MTR Corporation, and what that didn’t give anybody really is a full overview, full programmatic overview of the project. Everybody could see that in their little local bit, milestones were slipping and everybody tried really, really hard to achieve their milestones, but that just created even more interface problems, right? So, people were falling over each other to get access to work forms and sites and lots of energy and frustration was spent working with that because people saw that was in their way. At the same time, people tried to have a schedule and it didn’t go very well but it wasn’t also clear how much you could invest in this. Not in this project because it was financed differently, but in similar projects of similar size, remember we’re talking about a couple billion US dollars, if that’s privately financed, you easily have just interest costs for the delay in the hundreds of thousands of dollars every week, but if you don’t have that kind of transparency of how everything, the costs, the benefits, the schedule, and all of that hangs together and have that programmatic overview, then you’re probably not always taking a very courageous route, right? So what the construction site managers in that project tried to do is they basically tried to come up and recover the delays and they had probably about 200 different initiatives they tried to do. A lot of them were at no cost to the project, so they were good ideas, they just needed to be signed off, yet, if you actually had that an idea as construction site manager that every week of delay is worth $200,000, I know, in the worst-case example, that can put you in a lot of pressure, but also, if you take a more positive spin to it, it actually shows you how much you could maybe ask for to invest to hit your milestones and deliver on time, and I think only having a partial view and only having your little very overly simplistic goals, delivering specific items of scope to this date without really understanding how that all hangs together in a programmatic sense and how this hangs together with costs and with the benefits and all of that, that really ties people’s hands and they can’t get into the space of thinking more creatively about getting out of some of these things. So, a lot of projects, they simply then fall into the trap of just trying to work harder, which is a very uncomfortable space and comes at massive personal cost and stress and so on, and when that is not really turning the project around, then that’s doubly frustrating and it’s a very horrible space to be in.
Santosh: So, I’m really curious to understand how in that example you had a breakdown between different functions and possibly a lack of alignment and despite having a very rigorous task level definition, what was causing this lack of alignment? What was causing different functions to be out of sync?
Alex: Well, I think it had a lot to do with the way all these different elements of the project were actually integrated. In this case, it was distributed all the way too many functions in the organization at a lot of different levels of hierarchy and so that’s what we see in a lot of projects, right? Often, the full view of the project you only find that at the very top management so what you don’t really see is actually it flows up and down very, very nicely and therefore, when things change, that takes a lot of time to flow down and that people understand the implication of certain decisions and so on so it makes the organization very, very slow. At the same time, the other way around, instead of actually seeing it from a team level upward, if issues arise and delaying events or other events occur, then that doesn’t get surfaced quickly enough and, therefore, other teams are still working on the assumptions that everything is fine until you escalate it first up that some of the goals or objectives can’t be met and then it flows down and three, four weeks later, so after the team basically sitting in the container next door, you finally realize what the impact on their work is and then they escalate that up as issues and so on, so it’s kind of a way where what happens next or what happens if kind of things takes a long time to discover, it’s really hard to get transparency and get clarity around these things and, that’s not a good thing.
Santosh: No, absolutely, and the interesting thing is that in hindsight, I’m sure those groups of people, very capable, intelligent people, would have possibly come up with a different approach so that they have that integration and context to avoid such issues, but now if you were to hypothesize or say the same organization is embarking on its next project and, again, with similar high stakes, tremendous capital outlays, a lot of public attention on what they’re doing, do you feel that they would approach it differently? Would they fall back to the same top-down command and control structure because that’s easy? What would it take to get a group of planners to adopt this more agile, more organic goal-based planning?
Alex: Aa always in construction, inertia is quite high, so I fear that they might fall back on some of these behaviors and I think to some extent they have with projects that have happened subsequently, but what I think is that is important and when I look at this on what planners should do differently is thinking since thinking a bit more creatively about some of these objectives and some of the goals of their project, right? We know that schedule is very important but it shouldn’t be the sole dominant factor that people are working through. In particular, when we’re going into sort of more innovative forms of project delivery, say for instance, when stuff is designed off site or off-site manufactured, we can’t control the project necessary through lens-off tracking activities, so what we really need to do there is tracking things through deliverables of prototypes of things and that’s a very different way of controlling project progress than, say through controlling progress through milestones, and that is a big shift and that’s a big shift in the approach of things that needs to happen on that front. I think to some extent of course all these systems need to run side by side depending on really what the task is so what I wish and what I really hope and what I like to see this is all going to in the near future, because of all these different things, because we have more IT which is very different and you manage that very differently with more IT in lots of projects, with lots more digital engineering and all of that kind of stuff, we’re trying a lot more manufacturing-type approaches which, again, are managed and controlled very, very differently, so what I see in the future is that planners and people who have to stay on top and project leaders who have to stay on top of their project progress that you really need to write a toolkit of how they’re dealing with those things, right? So the good old stuff like value management and milestone tracking and all of that is still relevant, but, even in the here and now, it should only be one of the tools that you use to keep on top of your project.
Santosh: Absolutely. So, Alex, I’d love to get your perspective on sort of four different dimensions of strategic planning, and we’ll just do a quick rating on a scale of 1 to 10, 10 being extremely capable and efficient, 1 being nonexistent, how well do construction projects specifically, but maybe if you look across all the projects and I think you’ve formally studied a large number of projects, it must have been in the thousands. How many projects overall?
Alex: I think in total we’ve looked at 12,000 projects now.
Santosh: Wow.
Alex: Yes.
Santosh: So, if at all possible, let’s try to get a macro sense of this large number, but let’s start with the way goals are defined and if you were to look at construction projects, on a scale of 1 to 10, where would you rate the capability of organizations in defining goals?
Alex: Probably 2 or 3.
Santosh: Wow, okay.
Alex: Yeah.
Santosh: Then, the next step being communicating them, and if you feel you wanna go back and change any of these numbers, that’s fine.
Alex: I do feel on the daily level, on the task level, at the workbench meeting, target setting for, “Okay, guys, or girls, we need to achieve this today,” that works quite well, and so both the staff, so say for instance, goals around health and safety and those kind of things, I think that also works really well on the daily thing, where it always becomes a bit more interesting and really more difficult than a lot of those good things. I mean, now we often say, right, you have a team leader at the very lowest level, so they’re often quite good at defining what do we need to do this week, what do we need to do today, okay, good, but then anything more forward looking of, okay, what do we have to do next week, what do I have to do this week to be ready for next week and stuff, then it starts falling down, so when you say it’s strategic, that’s how I think about it, strategic goals or strategic planning is a little bit about foresight, near-term future, and the further you go, from this is what we’re going to do today or this is what we’re going to do this week or this is what we’re going to do next week, once you get to week 3 in this little system, then you see a massive erosion of the ability of the construction to actually do that.
Santosh: Fair enough.
Alex: That’s my observation.
Santosh: So there’s a bit of myopia in this system?
Alex: Yeah, there’s definitely a lot of myopia in this system. So, when it comes to oriented goals to just sort out stuff that needs done, needs doing in the here and now, it tends to work quite well, but a little bit of foresight above six months is really hard, really, really difficult.
Santosh: Right.
Alex: Not very well done.
Santosh: So you gave the construction projects a pretty low score in defining goals. How about communicating them out across the organization?
Alex: Yeah, I think that’s sort of similar, right? So I do think the way the whole trickling down, that doesn’t work very well. It’s a bit too slow, too many errors in translation can happen, so when it comes to tell people what they need to do today or what they need to do tomorrow, their communication is fine, but then sort of lifting it up and so when we know communicating goals and aligning goals between different teams or even different contractors and subcontractors, then it all becomes very, very difficult and if you then even want to as a good client, good infrastructure kind of construction client, explaining to the people who are building your project your benefits case is really important and what’s driving value, what should be the priorities so that they can suggest better and creative ways of dealing with it to even just empowering people to make these decisions, actually we’re not very good at it. I wanted to say crap.
Santosh: So it sounds like we maybe utilizing the negative range of the scale too.
Alex: I know. I should have started with the first question was a 10.
Santosh: No, no. There’s no preemptive bias here, I think it’s great. The third dimension is tracking goals to closure. How well do organizations, and I assume if they haven’t defined them well, it’s difficult to track it to closure, but what’s your feeling on that?
Alex: Yeah, I think that’s actually true, and in terms of closure, I think what we often see in construction projects is that really obsessed with the physical asset and, hence, once the last bit of concrete set in, building is kitted out and all of that stuff or the tunnel opening is done and we’ve really focused on the physical side of the asset and that often stands in the way of the benefits when we actually think more about future operations of things and how those things are really generating value and benefits, so that’s where I wouldn’t even define closure is when these projects are used and have delivered the benefits they’re supposed to deliver and we’re really bad at doing that. We’re probably better at actually finding out what is the scope and what is the tangible physical deliverables that need to be delivered and tracking those and there’s lots of systems in place, quantity surveying and all of that kind of good stuff to make sure that the scope has been delivered to quality, but how does that all hang together in terms of the wider strategic ideas, in terms of time, cost, and benefits? That’s sort of where I think we’re not particularly good at tracking that through.
Santosh: And then what about the last dimension of assimilating learnings or learning from the strategic planning process so that you can do a better job in the next cycle?
Alex: Well, that’s interesting. We see some people doing alright. A lot of people are trying more and more about this so rather than thinking and say, “Oh, no, next time, it will all go according to plan, let’s just try again and work a little harder at it,” I very encouragingly see less and less of that mindset and more and more people really engaging with what has happened at other projects and how can we learn from these things, those kind of things that people actually go back and check and look at planning assumptions and simple goals like productivity and unit cost and other things that might be a goal in the project and they’re looking at these things to inform their future plans. Some of the organizations I work with, they’re actually getting to that level of maturity where these questions are asked and learning actually takes place which I find really, really encouraging.
Santosh: That’s very good to hear. And in each of these areas let’s say that there was an ability to move the needle a couple of notches in the way that goals are defined and communicated, tracking to closure, having a team really assimilate learnings, how would you quantify the benefits of doing so for an organization? Where does the rubber really meet the road in terms of having the real tangible benefit in investing time and energy in doing these things for an organization?
Alex: I think the benefits are huge and so every planner would dream of those kinds of things, right? If you just knew, for instance, when we sit down and plan stuff, we often look into what was planned last time and for a lot of organizations it’s really, really hard to actually then find out and have a structured way of, okay, what did really happen? So what was really the schedule as billed? What was really the productivity we had on this particular piece of work? How much did we really plan for this? And just closing those feedback loops would be tremendously helpful, and I like to think about these things as feedback loops where what actually happened to things is really informing then how we’re going to build the next thing, and I think that just happens too rarely, not often enough, and would be really, really good. One of those things this is not really related to goals, per se, but what I’ve been actually fascinated recently was that a transport for London, they changed slightly the process on how they draw down on contingency and when you now draw down on contingencies you simply have to put together your normal forms to apply for more money or an extension of time and that goes through the normal decision making processes, but on those forms you actually have to write down which risk has materialized that means that you need to draw down that money and after 12 months that gives them a very rich data set that they could actually now go back and for the next projects that they go in, they actually have much, much better data, much better starting point of looking into what are the risks that we’re supposed to be expecting, how much is it going to cost, how frequent are they, and so on. And before that there’s basically a gut feel and gut intuition and all of the risk registers, basically 90 percent of the value of the risk was always around site access because it’s a metro system, it’s all underground, it’s light railway, it’s difficult, but when they actually had the data, they found out that that’s not the case, it’s not 90 percent. It’s still high, I think it’s about 50 or 60 percent or something like that but it’s not 90. A lot of other risks are also important and site access is not as traumatic and problematic, at least in terms of cost impact of things. And I thought that was really fascinating. So, after 12 months of collecting that data of closing this little feedback loop, they have much, much better idea, much, much better data. And same thing goes for, so if I look at big projects and often when the frontend, when they try to put together their plans, they’re thinking, “Okay, this is normally how we would plan this out,” but then even having that ability of going back and asking, “Yeah, so, the last projects where we did this, how good were we actually at hitting these goals,” right? And what is really a realistic level of ambition we should have and what should we plan for and, therefore, buffers and all these good things to then risk things and which goals and what level should we set them to drive ambition and innovation but in a way that’s realistic and I think it’s just about closing these feedback loops. And as long as you manage most of your projects in Excel spreadsheets and as soon as the project closes and all the project teams disperse and all your contractors go home and you know the access to that data, it’s really hard to do that, right? Even simple things like knowing if we have this goal difference with productivity, how much can we reasonably achieve? What is the best case? What’s the worse-case scenario? If we wanted to pitch in innovation, what is really the baseline? What does this innovation need to do? What’s the level of ambition we need to put in to then actually have a really good case to make a change? So I think those are all important questions that without any good data, we can’t really answer and in many, many projects, we just don’t have good enough data of what has happened in the past.
Santosh: That’s fascinating. So, you’re suggesting that the process of thinking forward about some of these strategic areas is perhaps too heavily loaded with intuitive bias, whereas if we had a system of really defining and communicating and tracking and learning from this then looking at the data, then we would be able to inform that bias through actually how we’ve managed these goals in the past.
Alex: Yeah, absolutely, and, at the same time, everybody at the moment knows that construction productivity is pretty low, the rate of innovation is also too low and we need to see more of it, but, at the same time, because there is a lot of competitive bidding out there we always bid basically based on roughly the size and shape and cost of the last job and so as a thought experiment, I always like to ask people and contractors, if you knew that you close down your projects and immediately everything you did, all the rates, all the productivity figures, everything of that project would be released to the world, right, so that if you found a little bit of change or doing something slightly better that all of your competitors can immediately copy this and therefore bid for this, right, so what would that take to really get this kind of, okay, the next job, we’re really going to win the next job but bidding on new innovation on something, doing things differently than we did from the last job rather than just replicating what we’ve just finished and I think that is not the mindset that I see in most companies in the construction sector but if we had that, then I think we could really get around some of those vexing issues where everybody is always saying, “Yes, we have very little productivity improvements, we have very little innovation, we have very low margins,” and all of that and changing a little bit the way why we do work.
Santosh: Yeah, absolutely. And there are so many goal setting, strategic planning frameworks out there, tons of wisdom over decades, where is it falling short? Isn’t there enough adoption or awareness in the field and what do infrastructure leaders and project managers really need to actively implement a mature goal-setting framework in their teams?
Alex: Yes, there’s a lot of goal setting out there. One of the things is that I know there’s a lot of strategic advice around there and so on and so forth and I think we need to really take a hard look at the system and one of the things is that what I think what we’re always slightly bad at is thinking around where do we get our early warning signs and how can something like a goal setting system really give us insights into how well it’s going. Ideally, a little bit ahead of time, and the way we do it at the moment, which is kind of really 1960s thinking about goal attainment where that is going to get us is very reactive and very slow, so we tend to not focus enough on very short cycle indicators that basically at the end of the day tell us whether we’ve hit our targets or we’ve gained or lost schedule today, that extreme real time feedback. We’re not very good at this, so the short cycle indicators of our goals and we’re also not very good at just some of the weak signals and the leading indicators that would tell us a lot more in advance whether we’re going to hit our goals or not. So I think it’s a little bit about that and, in many ways, the way we use data, the way we use foresight tools and some other strategic planning tools that our maturity is quite low in that regard so what I see in terms of construction management and the management leadership of it, a lot feels very much like it’s the 1960s and the world has changed dramatically in other organizations and other industries and thinking around ideas that world of manufacturing has completely changed because they switched from product-based thinking to service-based thinking and service quality models which bring with it a whole different graph of goals that have nothing to do with the product. At the same time, we now have an abundance of data and we’ve got the ability to actually enable computing anywhere on a construction site because everybody runs around with a mobile phone and stuff like that so we can have much better ways of collecting, integrating, disseminating data and analyzing data much faster than before and the other things that we see is actually the world of work evolves into more of a world that’s more personal and more trusting so less transactional, more relational, and all of these changes also have changed how we should manage and think about goal setting and strategic management of projects because it’s not simply this kind of 1960s model of let’s define an object and let’s make it smart so when you hit your objectives, you get a gold star and the project will be fine so the world has moved on a little bit.
Santosh: Absolutely. So, lastly, what advice would you have for leaders and project managers in this industry?
Alex: What advice? We talked about so much stuff today. When I think about it, there’s three big pitfalls that we see in mega projects in the construction industry and elsewhere happening and where a lot of projects always struggle with and those particular three areas, the first one is getting realism into your targets, into your objectives, so that you have realistic starting positions because one surefire way to fail is to not give yourself enough time or not plan enough money and, lo and behold, you will end up over budget and over time and delayed and so on if you don’t get that right so there’s a little bit about that frontend loading, that realism into the frontend. Secondly, it is about having good governance and governance is always about the people who are part of your governance structure, so getting cross-team alignment and integration with the client and all of those good things together so who’s sitting in your governance structure, but then also how are you enabling good decision making off that governance through the good use of data, fast, reliable, truthful, and at the same time lots of data points, they all need to add up to the whole of the project so that’s a big challenge. And the third challenge is around having good and capable teams. So thinking about the HR implications, the capabilities of the team and also thinking about those in the same way that we think about other things like health and safety and budgets and schedules and sort of the green impact or sustainability impact of our projects, also not ignoring the people side of things. I think those would be the three things. So really make sure you got a realistic starting position. Secondly, have good, efficient, effective governance, that is really making good, high quality decisions and data safe and fast information. And, thirdly, making sure that you have a cracking team to develop or deliver and think around these three things of, as project leader, how do you know that you have a realistic planning frame, cost frame, and so on, whether you have good governance structure, and how do you know that you have a good team, right? How do you know? That’s kind of the key question you should ask yourself.
Santosh: All great points of advice, and I really love the perspective of thinking of goals not, as you put it, in a 1960s archaic kind of way but really as an integration fabric to bring together all the different parts of your initiative, which is difficult and complicated. And then also using goals to guard against that intuitive bias that sets in in leaders’ mindsets of, yes, I know what we want but perhaps by looking at our previous system of goals, if you have access to that data, it would alter and inform this planning process as well.
Alex: Exactly. The more you write down and the more you have it readily accessible, the better your future becomes and that is absolutely important and the way we muck around with spreadsheets and stuff like that, it’s just so – why? Why are we doing that?
Santosh: Well, this has been fantastic, Alex. Thank you so much for sharing from your deep well of experience and wisdom.
Alex: It’s also my pleasure. Thanks so much, Santosh.
Santosh: Thank you.
Thank you for listening to this episode of the Construction Goals Podcast. I’d love to hear about your experience with goals and strategic planning, or answering questions you may have after listening to the show. You can e-mail me at santosh@goalcheck.in, or visit www.GoalCheck.in to submit any feedback or questions. I look forward to hearing from you.
Thanks for listening!
Thank you for listening to this episode of the Construction Goals Podcast. I’d love to hear about your experience with goals and strategic planning, or answering questions you may have after listening to the show. You can e-mail me at santosh@goalcheck.in, or visit www.GoalCheck.in to submit any feedback or questions. I look forward to hearing from you.
- Subscribe on the platform you listen to most: Apple Podcasts, Google Play, Spotify, or Stitcher
- Leave an honest review and rating on iTunes. Your ratings help people find this podcast, and I read each and every review!
- Leave a note in the comment section below.
- Share this podcast on Instagram, Facebook, or Twitter.
