Big Ticket Transformations: Doomed to Run Late and Overbudget?

As humans, we have a natural bias for optimism that's great for many business situations, but not safe for projects.

Hi, I'm Adam Durrell. I'm the host of the Account Experience podcast. Now, last week I went to see Chris Nolan's Oppenheimer movie. Amazing. You gotta go and see that if you get a chance. And a large part of the movie is about the Manhattan Project, which is a huge wartime mega project that delivered the world's first atomic bomb in an incredibly short period of. And if I think about that, and then group it with the Apollo Program, which I'm also a huge fan of, it seems that these two mega projects delivered on time and achieve their aims. And I think that contrasts with projects that we think of that have been around recently, like the Berlin airport construction or the Elizabeth line that took way longer than planned and was significantly over budget. And again in the news recently, there's HS2, there's even the Commonwealth Games that was canceled almost at the last minute because it looked like it was going over budget. This seems to be typical of megaprojects these days. Have we lost the knack of doing them? I don't know. But if we think about projects that are familiar with most of us in our everyday lives, they're sort of big IT transformation projects that happen in the companies that we work in. And I wanted to drill into that today. Are they always doomed to fail or at least run late and over budget? Now, my special guest this week, Steve, Steve Abramson, is going to help us untangle this. We'll introduce Steve in one moment, but if you're a regular of the AX podcast, you'll know that in every episode, I like to catch up with inspiring industry leaders and thinkers to help share best practice and develop your B2B account management program. And the focal point of putting account management together with customer experience is really why we call it account experience. It's the bridge between those two things. And I'm also the father of four, a founder, and I'm fantastically interested in humans. I love anything that furthers the quantity, the quality of business relationships. And today I'm talking with Steve Abramson of Jasmar Associates. Now, Steve comes with more than 30 years of professional experience in the professional services industry across the consumer goods and retail sectors. And he's been working for large businesses like IBM. KPMG doesn't get much bigger than that, and also smaller high growth companies. And what I particularly love about Steve's background, he's worked in the crucible of big companies. Like Tesco, Unilever, Diageo, Coca Cola, Kingfisher and more. And he started his career. Maybe we can get into that later in the most British of retailers, Marks and Spencers. We all know retailers detail. And I'm pretty certain that Steve learned some of those lessons. He's now independent, working as an independent advisor and a non exec director working with a range of companies that help avoid, to help them avoid the pitfalls of these big ticket transformations. So I'm really delighted to get Steve along today to help us untangle this. Steve, hello. How you doing?

Hi. Yeah, great. Thank you, Adam. And thanks for inviting me on.

I hope, I hope I didn't overwhelm you with the introduction, but I am really interested in why projects fail. I mean, you know, why don't we just get straight into this, Just a quick thing. What happens to the big projects that cause them to fall over?

So I think it's a very big question without a very easy answer. It'll be sort of multifaceted. But if I just unpack, unpack some of that very, very briefly, hopefully. I think in part, many businesses and many leaders in businesses are brought up with this whole phrase of I have a bias for execution, I have a bias for action. And that works really well in a business environment where the pace is the thing that is really recognized and valued. When you come in to some projects that also works really well. When you move into the world of complex projects. You're in a world where actually slowing down to ultimately speed up is probably better, where taking the time to properly strategize, to properly plan is better, where actually having a mantra of think slow, act fast is going to be better. And at a headline level, I think that flies in the face of what many leaders have been brought up with today.

Yeah, I think that's really true. Okay, let's pause on that thought for a moment because why don't we look a little bit about your background because you've seen a lot of these projects come and go. So let's zoom out a little bit and talk about how your career arc worked and how you saw this along the way.

So my career started in operational retailing with Marks and Spencer were largely, you weren't necessarily paid to think very much you were paid to do. It was about taking the standards that were dictated to by the center and applying them consistently across the retail estate. I then moved into IBM where I started to engage with some of the larger clients you talked about earlier and started to see them successfully or perhaps More relevant unsuccessfully tackling some large systems projects. I then spent about 15 years with smaller firms, but tackling some large projects. And again you see the challenges that these large organizations face into. And then the last 10 years of my corporate career was with KPMG where we were doing projects that would often go into client spend of well in excess of £100 million. And you see some of the same challenges occurring time and time again. And then having left the corporate life and like you been fascinated around this whole area of why it is that large projects fail, you start to see some astonishing statistics. So one of which which I find fascinating, only 0.5% of projects deliver on time to budget and required benefits. 0.5. So 99.5% of projects do not deliver on one or more of those criteria.

Hold on, is that mega projects or even just big ticket transformations projects?

That's projects. That's not mega projects. That's projects. The data will get even more sort of shocking if you move into mega projects.

I think I've dimly remembered that often the cause of this is something to do with. They call it seeding failure. I believe it is. That's where you basically screw up at the beginning. You don't do all your cost benefit analysis. So are all the issues at the beginning of the project.

There's a really interesting phrase, projects don't go wrong, they start wrong. And there's an oft quoted example of, and I'll quote Amazon because I think they are a great example as a business that is really seen as having a strong bias for action, a strong bias for execution. Again, when you unpack that the strong bias for execution is for decisions which are reversible, where a decision is reversible without a huge amount of cost or challenge. I think there is nothing wrong with this bias for action. When you look at large IT projects, the decisions are not easily reversible. They are very, very costly. You are embarking on a journey which once you're underway is very difficult to reverse. The style and way of working that businesses need for decisions which aren't reversible is very different. And that's where I think this upfront piece around projects don't go wrong, they start wrong. They are not sufficiently well planned out at the start to actually set them off on the journey. But this mindset around bias for action has you moving out the gates way too quickly.

Okay, so let me see if I can unpack that a little bit or at least play it back. So if you. Most projects start wrongly and it's also a little bit about. And there seems to be the fixed mindset. So if you're prepared to go along and make decisions along the way and get there, then you're going to be more successful. But if you are just you plan at the beginning and you have a very fixed mindset, it's more likely to go wrong. If I'm just getting this right, it's a little bit. The difference between agile programming and a waterfall style of delivery is that. Am I off the target here?

I think there's a strong correlation. The reality, I think with some businesses is agile can be used as a reason why you don't plan. And I think what I'm referring to here is at the level of complexity for decisions that may be difficult to reverse, one of the key factors that will determine success is more relevant and appropriate planning. There's an interesting phrase which people with Agile will know called minimum viable product.

Yeah.

When one looks at some of the larger projects, some of the big difficult to reverse investments, I would encourage businesses to think about another phrase which is maximum virtual product, which is how much can we actually simulate before we commit?

That's a good idea.

Again, if you'll bear with me, I read an interesting example of Frank Gehry who built the Guggenheim in Bilbao. And before any foundations were built, there were iteration upon iteration upon iteration of models simulated on computers and paper based models. That might take time, but it's way cheaper than it is to actually then be sinking foundations and trying to change the course of the build when it's underway. So how much can be simulated can be tested, can be tested, can be checked before a business starts sinking significant sums of money.

That's a really good example about the Guggenheim Museum. But again, when it comes to like a big ticket transformation in business or an IT project. I know, let's come up with a good example. You need to install a new CRM system. That's for my world, you know, so when people start out with the best one in the world, they go, oh, we'll buy Salesforce or Microsoft Dynamics. But that's not the whole picture because of course they need to put all the business processes in, you know, that. And then often the, maybe the CEO who initiated that project is long gone by the time, I mean, it's finished. Talk us through some of the steps that the businesses go through and about how they can, you know, avoid some of the pitfalls in that.

One of the really interesting considerations in embarking on a project of that type, I start from a Premise that Salesforce works, it's in enough clients to know that it works, as does SAP, as does Oracle, as does Workday, as do all the other systems. So why is it that they don't work in the client's environment? And there are a range of reasons for that. But if a client were to at the start recognize that these projects or programs really are all about managing trade offs and that there will inevitably be tension between a number of criteria just to list those criteria. There will be a focus on delivering the business outcome to a defined timeline. There will be a focus or desire to constrain resources or to constrain cost. There will be a desire to implement a minimum level of functionality, let's call it solution integrity. And there will be a desire to keep everyone happy and the stakeholders aligned. So if you imagine those four as criteria that you might want to set and then recognize that each of those is in conflict with the other, and when you ask many executives which of these are the most important, the answer typically is all of them. And that cannot be true or it never is true. In a large project, if you want to actually deliver the business outcome, you need to compromise on budget or resources. If you want to actually deliver the business outcome, you may need to compromise on the functionality of the solution. To hit a defined deadline, you are dead set on delivering this functionality. You might need to compromise on deadline or you might need to actually recognize you can't take all the stakeholders with you. If one got the stakeholders in a room at the start of the project and said, you're not leaving until we are aligned on what this picture of success looks like at the starting position, typically you will have massive divergence between those views on what good looks like. And if you imagine those views will simmer and will start to come out in the course of the project. And here you've got the poor project team trying to deliver against everything, but simply unable to, it's no great surprise that these things then start to get challenged through the project. When an early discussion around trade offs would give a much better direction around when push comes to shove, which is more important.

It's really interesting if I think about, I mean, I think humans are not by nature great planners. I think we're great improvisers. And so often it's better to have a simple goal. An atomic bomb, for example, is a good example, or put a man on the moon. But business goals are often more complex and more opaque, or there's three objectives. So that's number one. I think and then the other thing is that what I've seen in business projects, as they get going and then the needs change or the realization about what the project can do, people go, oh, wow, that's such a great idea. Let's fold that into it. So is that typical of a project and how do you guard against it?

Well, I think it is, and I think it's also worth unpacking. And for those of us who are interested in both Apollo and then looking at what Elon Musk does.

Good example.

What you see with Elon Musk is a range of trial launches, which one could say ends up in failure in as much as the rocket doesn't ignite, or it does ignite, but it ends up igniting the whole thing and blowing up.

Yeah.

If you look at Apollo, and I don't know about Manhattan, but I would imagine it would be very similar. Everything in Apollo that could be tested as a component part before you put the men in the rocket and sent it up to space, what was tested, we tend not to do that in projects. We tend to have go lives which are big go lives. We tend not to test every element in advance. The other thing that adds a complexity or complexity is that one of the defining characteristics of something like Apollo or something like Manhattan was that it was managed along military lines. It was a command and control culture. The complexity was there, but it was huge technical complexity. The management of it was, I would argue, slightly simpler along a military command and control. If we then translate that into a large corporate. My contention will be that the technical complexity isn't the same as my pattern. But the differing stakeholder needs and requirements and expectations adds more management complexity, which in and of itself is a reason why many of these projects do get challenged as they go.

That's a really interesting point, Steve. So what you're saying is that if you're running along military lines where some person says jump and everyone else goes how high? That's one way of delivering on time. It's not going to make everybody happy on that project, is it? So, and the modern way of doing it, where you're trying to, you're trying to get everything from all the stakeholders in like, I don't know, HS2, making sure that the cricket pitch is fine, or we, we save the blue bell or whatever, you know, it's like everybody has a voice. We're not pissing anybody off. So you're saying, you know, in doing that, it's inevitably going to add to an overrun or maybe even a budget increase, right?

It is, it is depending on whether it is indeed an overrun or whether the forecast was just one at the start. Because the recognition of the need to align stakeholders ought to mean that the budget or the forecast is more appropriately set at the start. Recognizing that the consequence of keeping stakeholders aligned is going to be a delayed outcome. A higher and maybe a question on some of the solution itself that's delivered.

Yeah, that's a really interesting point. So what you're saying is that overruns on budget and time are probably inevitable in the modern project, but it's just often not. Maybe it's not even communicated very well. Or we just. It's always a surprise to us when it happens, when we should just be saying this is what happens with a project. It just goes, it's going to be late and it's going to be over budget. Live with it.

And in which case is it an overrun?

Yeah.

Or is it the case the forecast wasn't right at the start? And we tend to run projects by comparing against budget. We're over budget. Where if we go back to the start, if 99.5% typically are over budget, that to me would say that typically the forecast isn't right to start with that we're not factoring in complexity to get the right budget to sort of framework at the start.

Yeah, it's a really interesting thought actually because I think as projects go along and as we. We see things added to it, we call it scope creep.

We do.

So we just think about it as being on the negative side of the balance sheet. But it's hard to then look at the increased value of a project that suddenly gets departments working together more efficiently. And of course we take for granted things like just in time delivery these days or what is the thing that Amazon gives you, you know, predicted delivery time. And that's, I mean it's incredible really. We just thought. But those things were difficult IT projects that got us there.

Right.

So they are. But I also think that the way we plan probably doesn't help that we are surrounded now by planning tools that enable an aggregation of all the different tasks. And a thousand one day task, it's called a thousand day program.

Yeah.

And arguably what we don't do enough of is if I take five or ten other organizations implementing a complex salesforce based initiative, what does that actual delivery and budget wrapper be? And then maybe that starts as my reference point and then why do I believe I should be above or below that? But I think we are lulled into false sense of security by some of the detailed bottom up planning when the reality is by definition given how many go over budget, they're simply wrong.

So what are some of the solutions to this? Do we need to train our leaders in a different way to manage projects?

It's a really, really good question and certainly what I have seen and I'd love people to share thoughts as to whether they agree or not. I think there is a wealth of support out there for leaders to lead better. I don't see as much support for leaders to lead change better and I think it does require different muscles. I think it requires focus in areas that could feel uncomfortable, such as much more focus on planning for decisions that are difficult to reverse. So I'm not suggesting for a moment that a project which might be more operational but could be reversible should fundamentally be treated differently. Because I think many people listening to this podcast will have experience of landing there successfully. But when you move into complex, maybe cross functional, maybe systems related, they do require different skills. So I think that's one which is sponsors appropriately trained to lead complex projects better. I think another really helpful piece would be recognizing that some of these complex projects will require trade offs and having that conversation of which factors will I trade on when push comes to shove and am I aligned with my other stakeholders around that view? I think that'd be immensely helpful. I think the third probably comes down to this false certainty, which is we have a habit of saying this project is going to be delivered for X amount of money, when actually in reality, most of us have no idea whether that's true or not. So if we were to move to a ranging conversation rather than an absolute conversation, it could be here, it could be here, it could be here. The worst case might be here. Here's how I manage away from worst case. These things can really set the teams up better than having them potentially reporting things as green, green, green, green, green until the day goes red.

This PODC is sponsored by CustomerGage and they're the experience leader in the CPG market. Let me tell you why they're contacting more people in the independent trade and modern trade than any other customer experience company out there. And you'll know the brands that they work with. We're talking Coca Cola, AB, InBev, Heineken. Just E takeaway, they're literally pulsing millions of contacts around the world and in more than 60 countries multiple times a year, delivering those insights to thousands and thousands of frontline employees in those companies. But you know, it's not just the CPG business customer gauge is famous for. They're ranked number one for B2B customer experience by Gartner. However, if you're in the CPG business and you have not contacted Customer Gauge to understand what is going on in your business, you're seriously missing out because we know there are other people out there just doing it once a year. Well, Customer Gauge gives you customer insights 52 weeks a year right to the front line in real time. It's going to absolutely transform your business like nothing else. But don't take our word for it. Listen to the podcast and they'll tell you exactly why.

Let's pull the plaster off a little bit on this and go. Because you've mostly been involved in your career on delivering services to big clients and they you must have had some tough conversations, probably be on the receiving end of them as well. So can you give us an example, perhaps without not mentioning any details of of where you've had to compromise between time, budget and scope and how did you look at that tensions and then talk the client through how you'd manage it?

Again, I would say in a complex system related scenario, if I look back on my corporate career.

Yeah, can you give us a good example? You can change all the names to protect.

I would say not well is probably the short answer. One of the largest systems implementations that I was involved with was very large retailer and actually those compromises weren't really called out. And what happened almost a little bit by osmosis is all the focus of the program ends up being shifted towards getting the system in. And when the system is in and the bugs are resolved, one sort of declares success and then you have a stakeholder who says business stakeholder. What value did we actually get apart from transitioning to a new system? What business value did we actually derive? And the answer tends to be not a great deal because we focused so much on getting the system in. And with hindsight having that trade off conversation early would have actually enabled a very different conversation. It might have been a compromise on the full functionality of some of the solution, but with an upweighting of some of the the benefits were delivered as a consequence. If I look again another example which was delivered actually very successfully but it was more of a top down and it was a restructure of a global consumer goods business away from a product orientation, a divisional product orientation towards a country and regional P L. The CEO in that situation was very much in the zone of you're either on the bus or you're not. But this is the way we are moving. This is the future. We are moving to a single regional P and L. There were quite substantial fallouts from that in terms of heads and any of the country general managers who weren't on the bus were very quickly moved on and it was successful, it achieved what it needed to do, but it was not an exercise in keeping all the stakeholders aligned and happy.

And I've also seen some of those, especially like a head cautious relocation or something which I think are often ways to get rid of a pension legacy, but not really designed to make the business more efficient. But it might be wrapped up in a kind of like a corporate message that we need to do these more efficiencies.

There are situations where the delayering has seen very successful situations where delayering and head office moves have worked very well simply by having less senior leaders in the decision making process.

You thin out people. That's maybe a topic for another, for another podcast, but I think the what I'm picking up from what you're saying is that the what you said is in a very good example you'd focused on getting the. Or they had focused on getting the IT system put in place, which is often the way that these things come. They've seen, they're saying we are, this is the IT solution and it's named a salesforce thing or you know, and if you forget the cultural aspects of this, how is it going to land? And often it's a surprise. You know, it's like, oh, we do this now and people are always hesitant to change and it's hard. So I think the cultural change aspect is often not costed into a project like this. And I'm just going to bring this up because I see this all the time in CX programs as people do a customer experience things. They buy the software, they do the actions and it lands on stony ground. And so let's drill into that a little bit, Steve, and talk about what you know, the good, the bad and the ugly of where you've seen that.

Well, if we start with the good, I think the recognition that I'm going to throw it out there. There is no such thing as an IT project or let me be more specific, there will be IT projects, but they might be around the IT infrastructure and the networking. When one comes to a CX project, I would love more companies to start the language of there is a business project supported and enabled by it. And so whenever I talk to a client and I say who's leading this project? And you're appointed towards an IT project or IT program lead. That's a real red flag. Nothing in any way critical of the individual leading it. But it does point to a lack of appropriate buy in and ownership from the business. So where do these things tend to land better when they are business projects, business programs run by a business owner enabled and supported by it. That will be first and foremost where the investment in culture around the system. It may be significant, it may not be, but it's the ownership I think that one needs to get right right at the start. If one is sitting in it, running a project of this kind, it's really hard to land it successfully because you don't have control over the levers necessary other than implementing the tech, which as we know is not the determinant of success. So that will be the overarching which recognize that when you come to business systems, maybe the adage of there is no such thing as an IT project, there is only a business project enabled by it.

Yes. Okay. And you've seen this from being working as a third party for the companies that you've been in, also working closely with internal teams. So where's the line of success? Well, things are best left to the third party services team to manage. What are they really good at in bringing a big project in and what are the things that can better left.

Internally when you look at the landscape, if you like. And having worked with large corporates and having worked with smaller firms, I don't think I could honestly say though is, you know, one is better, one is worse. I think that there is a fit and appropriateness assessment for the organization. There is a place for turnkey for having a turnkey solution from a larger services provider. The danger is if the client isn't an informed buyer that they end up potentially getting what the larger firm wants them to have, not what they actually need. So that turnkey does require an intelligent buyer. Now the client can secure intelligent buyers. If they don't have them, they can bring in client side advisors. So I think there's number one, which is if one is going to go for a larger firm, then recognize that you do need the skills to manage that larger firm and understand the drivers and motivators that the larger firms have around what matters to them. If one's going to go for the smaller firms, there can often be real value in that. And those smaller firms can be more agile. They often just don't have the volumes of people to put on the ground. So they might be more naturally disposed to making the best Use of the people that they do have. And there can be a real value in filling some of those client side gaps. And of course you then move into the interim and the consulting market. But I think this is one where being a more informed buyer, bringing more right to left thinking, what is the outcome I'm seeking to achieve and how do I then drive towards that outcome? And then as I come closer to where I am today, what does that mean in terms of gaps? There can, I think be too much of a tendency to abdicate some of the activities that should rightly sit with management into the hands of third party. And I think that's where it can start to go wrong.

And finger pointing as well. I'm pretty certain that can happen. Yeah. So as we start to give people some resources to help navigate this, Steve, as we bring this fascinating conversation to a close, what resources have you relied on in the past? I mean, you said there was a book that you thought was a really good textbook on this.

Yes, it's a really good question. There clearly are niche providers we can talk around that and happily link into to any that I've seen who are very good. There's a really interesting book by Professor Ben Fleiberg called How Big Projects Get Done. And Ben Flyberg has leveraged knowledge from his time at Oxford University and capturing a lot of data around successes and failures and synthesize that into actually what is a very, very easy read. Now this book focuses on megaprojects. So typically projects above a billion pounds, which for most of us moves us into the world of construction rather than business change. But many of the learnings are equally applicable to the typical type of business change projects that we will be doing.

Yeah, we're not building a bridge. And you have to. Once you start a bridge, you can't stop building a bridge really, can you? But I guess that you can use some of the elements of those mindsets to.

Well, you can. And there's a really, really interesting example given of the Empire State Building which we would naturally think of as. Once you started, maybe you can't stop the Empire State Building long time ago, but built under budget and under time. And the way that was tackled was intentionally, not using new techniques, only using proven techniques, and again intentionally set up as a project that was going to build 101. I think it was one story buildings, not one 101 story building. And so the repeatability was built in from the start. It was designed as a modular program so that once we built one floor we just do another hundred of the same. And there were learnings out for us in how can we make our projects modular? Because modular is much, much easier to implement.

I'm actually, I'm really glad you mentioned I'm a huge fan of the Empire State Building. They built one floor a day, which is incredible and in a really amazing production rate with phenomenal speed, all the modern stuff and that without the computers to do it. So, Steve, this is a brilliant tour through big projects. It's really hard to boil your credible experience down to a few bullet points, but I'm going to try and ask you to do that. If you had three bullet points for tips to help us avoid the failure of a big project, what would they be?

So I think the first, and I touched on this before, is try and get views on what an appropriate forecast should be. You'll have your own teams, but try and get views from what has the reality been for other organizations? And then why do we think that we are different? That would be the first, I think the second we touched on again, which is recognize that by nature we do have a bias for action and a bias against planning. And if it is a big investment that is going to be difficult to reverse, put ample time into planning. And I don't know who it was, but it was Abraham Lincoln who said if I had five minutes to chop down a tree, I'd spend the three minutes first three minutes sharpening my axe. But there's something about that element of planning would never be wasted for very large basic projects. The third then probably does touch on setting your teams up for success. So recognize that these are complex, they are ugly. There will be trade offs and the more one can actually face into that early, the better you'll set your teams up for success.

Fantastic, Steve. I really like those and they're really good, good rules for life. I think I might print them up and give them to my services. Now if people want to follow you or get in contact with you, how do they do that?

Yeah. Thank you, Adam. So please feel free to drop me an email. Steveasmoreassociates.com have a little look at what I'm doing on LinkedIn. I'm always fascinated to talk to Insync folks about Insync related projects. And having spent 30 years in and around consulting, always happy to leverage my network where it can add value to people's efforts.

Super, Steve, thank you so much for joining us today.