Speaker 1: 0:10

Welcome back to another episode of transformative change. So today I've been wondering what to talk about this topic and I was having another dialogue with my girlfriend, as always, and came up to the thing around execution. We've talked about execution before, but I've started thinking even more around this topic and I think I see it so clearly now that the only thing that gets executed successfully are the ones that are simple enough for us to understand. In large organizations, everybody is trying to make sense of complexity, so we take in large organizational firms, experts to try to pinpoint the complexity, but it always fails. Well, of course, many of these projects go over the finish line, but research also says that a lot of these, especially IT projects that are so complex, fast moving platform integrations, fail constantly, go over budget, goes over timeline. And why is that? We don't understand many times the things we execute on. We have project managers, product owners that don't understand the technical complexity and I'm not saying everybody needs to understand and manage complexity. But it becomes problematic when we think we can paint the picture on how it's going to look like when we're done. When project of a large size and magnitude takes years to execute on, I mean we're having a hard time sometimes just to make a plan with a friend and make that work deciding on a restaurant. I truly believe that the only things we can execute successfully on are the ones that are simple enough for us to understand. So before deep diving into this topic today, let me just give you a reminder of what this podcast is all about.

Speaker 1: 2:14

This podcast is transformative change, and transformative change is the major chip in an environment that significantly changes the characteristics or the outcome of this environment. These type of changes brings about deep and lasting transformations that fundamentally change the way things are done, the way people think or view certain situations, or the direction in which a society or organization is headed. The goal of transformative change is to improve the overall well-being of individuals and communities or, basically, to address systematic problems or inequalities. In this podcast, we will digest cross-cutting topics that are needed to drive the transformational change. No areas should be off-limit, and the purpose is to help you, as a listener to this podcast, in your journey towards creating long-lasting impact. So, if you enjoy this content, don't forget to subscribe in your app or on your web browser and share it with your friends and families and coworkers so we can make a bigger impact in this world.

Speaker 1: 3:26

But now back to today's topic. One of the things around this has really been my own frustration. I remember some time a few years back I think five or six back or something I was living in London and being a part of a large platform project. We were doing distributed computation on telco data. We were having this massive amount of nodes or computers three, four, five, hundreds of them being able to process a lot of this data. I wouldn't say instantaneously, because you can imagine how a lot of data that we have when we're working for one of the world's largest telco providers. But what got me so frustrated was that there was so many discussions trying to make sense of the complex world when basically everything we understood and I was building models at this stage, trying to model behavior over telco customers we had a hard time even understanding what the customers were doing. So we worked in iterations in these teams and we went from having an idea, a vision or a purpose to maximize profit in a certain area and then we needed to iterate and based on that iteration we could take the next step and then the next step and then the next step until we had something that could provide value. And what struck me at that point is oh, while we are working in iterations, having sort of a trial and error approach, we slowly are figuring out what works and what doesn't work. We are executing progressively Sometimes it's wrong where we can course direct.

Speaker 1: 5:17

That took me back at that point to one of the first big projects I was involved in. That was a platform project trying to implement and harmonize large Nordic banks all 24 different systems, I think of us for card issuing and acquiring into one large platform with an external party, and there was a constant discussion around how should we manage this? There are millions of transactions every day, we have different cards with different permutations and we want to maintain and keep all of those things. We don't want to really harmonize. So what we started doing was basically spend six months to a year just mapping out requirements. What is it that we want to do? So we could buy a large platform and then insert everything to it.

Speaker 1: 6:13

I came up with a suggestion at that point that why don't we do not the big banger project you want to do? We do a big goalie. Why don't we just take it card by card, all of these cards at one point they need to be migrated. Why don't we just call it end of life and then migrate the customers over to a new one? Of course, nobody liked my suggestion at that point. Who listens to a 24 year old, especially when you're 56 and you've done this a million times? The project, of course, failed after investing probably 50 millions or something into it. I don't know. I'm just making up numbers here and it became quite clear for me. And as I was reading newspaper, I could read about similar products. And now the big bank invested in a large platform, spent a billion SEA just to shut it down. You were reading about platform projects, for instance here in the Nordic in Stockholm, for schools being a big catastrophe.

Speaker 1: 7:12

We're always trying to make sense and create the perfect solution on paper. I think this is true for the technology sector in particular. When you're building a bridge, of course you want to know how the bridge is going to look like before you start building it, but when you're building and managing complexly that's constantly moving as the tech field, new technologies comes in, things become obsolete. People have the knowledge in their head. One engineer is the only one that can maintain the system. You want to have more flexibility in the delivery mechanisms. You want to have an agile approach.

Speaker 1: 7:50

An agile approach isn't just an execution model, an agile approach because one of the things I think is so misconceived around agile deliveries is about the role of an architect, for instance. I see when a large organization are going to implement a platform, they use an agile methodology. They call it, but basically they know already what they're going to implement and then they shop it up into Sprint and they say they work agile. But agile is really figuring out. You know what it is that you want to achieve, but you don't know how the solution looks like. And this is the common misconception, because we need to separate it, because there are the solutions we're going to build where we know exactly how it's going to look like. I gave you example of if we're building a bridge, we're building a tower, anything physical most of this time is not something you want to do in an agile manner. You want to have sort of a waterfall approach you paint the picture and then you execute on that.

Speaker 1: 8:47

But when you know what you want but you don't know exactly how the solution is going to look like, the solution becomes secondary almost, because there's a lot of technology solutions that can deliver the same outcome, at least in the short term, in Dream State. And of course, there are other requirements like scaling up or maintainability and those kind of topics. But when you don't know how the solution is going to look like, the architect needs to be very hands-on. And iterations are much more important, where you iterate towards and you get feedback to the perfect solution. And then, of course, you have those things where you don't even know what it is that you want. That's called startup, that's called innovation, that requires another type of methodology in order to deliver. And I think people always mix these things up and they agile will solve all our problems.

Speaker 1: 9:39

No, because agile isn't the solution, because you're asking the wrong question. And then, why is this important? Because if we don't do these things, we will be really bad at executing and delivering subpar standards. And this is really true because there are so many big examples of this. When we, for instance, take Windows Vista, those of you that are Windows users I would assume many of you work in corporate, unless you're a data scientist or a programmer using Mac or Linux or Unix-based operating systems. You remember Windows Vista. I used to have Windows. Now I don't.

Speaker 1: 10:23

The Vista operating system was a disaster. I remember getting it I think I was in school already back then. It was a complete disaster. It was so full of bugs and problems and that really shows that, even though it's annoying to do updates on your phone, for instance, that shows that the vendor behind it, at least, is improving and working and shipping. So it's really about understanding and working towards a working solution.

Speaker 1: 10:54

And we have a lot of these examples in the world and most of them is around bad execution and estimation. It's done poorly and when these things go wrong, they can lead to major problems for businesses and organizations. Some specific things that really can go wrong when it comes to execution estimation is not having a clear plan, for instance and this is such an interesting project because I've worked with teams and they use agile methodologies but they have no plan. And this might be a bit counter-intuitive, because when you talk about agile, of course you shouldn't have a very detailed roadmap in front of you, but what is important is to have a direction, to have something that you can show to your stakeholders, to have it at least on an estimated level. You don't need to do all the planning and you don't need to do all the dependencies from day one, but you need to have a direction that this is our. I wouldn't call it plan. You know what I would call it. I would call it hypothesis.

Speaker 1: 12:10

This is our hypothesis, this is our focus area, and I know the majority of organizations in this world are not the cool tech startups that have no legacy to take into account when they're doing execution. The majority of organizations actually have a lot of technical legacy. Even many of the organizations we consider being cool and startup and techie I think again the Googles and the Amazon's of this world now are 20 plus years in the making and they probably somewhere have technology and infrastructure that is starting to be quite old. So it is important to have a plan on how to manage this complexity and show that you understand it. We solve the details when we get to that point, but if you have an expert with you that understands the complexity and you know how to ask the right questions, you can at least conceive a plan that's feasible. And then, of course, as we add there all the IT plans out there, add 50% to the estimate, because that's going to happen at some point. And then it's about the resources side of things.

Speaker 1: 13:20

So, if you're having a clear plan, or at least a plan that's on the level that's relevant enough, did you have the right people in the room when you made that plan? Because I'm going to let you in on a small secret Plans are useless. Plans is crucial Because that's always where you identify the right things that you need to do. Which are the people that you need to talk to, which are the hard part in these problems, where you're going to face obstacles, who is the key stakeholders, etc. It gives everybody opportunity. Planning is communication, so that's why it's important to have the right people in that room.

Speaker 1: 14:07

Communication how good are you at communication? It's important to communicate extremely effectively with all your stakeholders throughout the project, including keeping them informed on the product's progress, risk and challenges. What I also like to say is win people's heart, sell it to them. People think communication is only about information. That's actually not accurate. I think communication is much more about feeling. People are more inclined to invest and support projects that give them positive feelings. Think about it yourself. Your company says and informs you that this is an important project. It's a boring project. You don't like it, it doesn't give you any good feelings and you feel like you have to do it. But if somebody comes and inspires you, make that project aligned with your values and your purpose and your goals because that's possible with proper communication you are going to be more inclined to actually contribute actively to that project.

Speaker 1: 15:20

Then we have the topic around flexibility. The world is constantly changing and projects need to be able to adapt to these changes. So then back, we have a clear plan, but things happen. How do we manage it? We need to be willing to change the plans. Being an executioner of a project and go up and say, hey, the world's changed, or we figured this out in our iterations, or the architect now finally has nailed a solution that needs us to stop for two months, but then we can go with 5x speed. We need to be flexible, and that doesn't just mean from an execution point of view. That means you, when you are a stakeholder, need to have a flexible mindset as well, because things are changing constantly and that also affects the budgeting side of things. If you have a fixed three-year plan most companies have a one-year plan and a minimum on how to allocate things what if things change? You need to do X, y and Z instead of this. What if you discover an opportunity that will make or break your organization or platform project or whatever it is, fix it. That's all I got to say.

Speaker 1: 16:33

Don't be rigid and having accountability. It's important to be countable for the project's execution and estimation. Dare to take accountability and, when things fail, dare to say it was your fault, because people will respect you more. We won't be successful 100% of the time, but we can be accountable for our own mistakes or shortcomings 100% of the time and learn from them and be better, taking responsibility for any problem that occurs during your watch and take the steps to correct them. Most projects go over budget and over time. It's known as the iron law of projects or mega projects. Did you know that only 8.5% of projects meet their budget and schedule targets and only 0.5% of large projects meet all the three targets budget, schedule and benefits? So don't be worried. If you're a product managing or being a part of a product's SLA, I would say you would accept them.

Speaker 1: 17:39

I think that what research has shown is that optimism bias is the major cause of project failures. Project managers are often overly optimistic about the time, cost and benefits of their project. It leads to unrealistic estimates and plans, which are very difficult to achieve. The planning phase is often rushed and superficial. Project managers often feel pressure to move quickly into the delivery phase and they may not take the time to understand the risks and challenges of the projects. It can lead to a lot of problems down the road not involving the right people.

Speaker 1: 18:19

Initially, as we already talked about, the project needs to be flexible and adaptable. The world is changing, you're changing, I'm changing, everything is changing. Project needs to have more flexibility built into the plan. That means being willing to change budgets and schedules and the overall planning. It needs to be clearly transparent and accountable. There needs to be clear communication about the progress, risk and challenges.

Speaker 1: 18:54

Some final tips, then, on this around how you can actually do this. Some good things is around getting the buy-in from your stakeholders early on, making sure they are on board with what it is that you want to do. Conduct a thorough feasibility study if this project actually can happen. Build a strong team with the right skills and experience. Manage risks effectively. Have a proper walkthrough of what the risks are and how they will affect you. Be prepared to make changes as you go along. Have this agile mindset constantly. Communicate, communicate, communicate. The more you communicate and update, the better. Don't forget, the project still has wins. Just because you finish and go with a finish line three, four, five years down the line, that's not when you have the parting. You celebrate the small successes along the way and, following these tips and insights, you can increase the chances of your project being a real success.

Speaker 1: 20:15

And if you want to deep dive into this topic, I really recommend the book how Big Things Get Done. It will provide tremendous insight. It is written by a Danish professor and this is where they have outlined a lot of the successes in large projects and how the successful ones really are delivered. So I hope you enjoyed today's episode. As always, it's been a pure pleasure of sharing my insights and experiences. If you have any questions or want to continue the dialogue, feel free to email me at infoarallse. If you have any suggestions for topic, please bring them up and I'm more than happy to consider them. And until next time, I hope you have a great rest of the week. Take care bye.