We are looking forward to doing this webinar and sharing some of the insights and practical advice with all of you. Before we get on with the program we'll just do a brief introduction and maybe Alex you'll put a few words to your experience and knowledge. Alex Kroker, Ph.D.: Sure. Good morning everyone. Good morning from Oxford. Since the Eurovision was this and this is Oxford calling to Copenhagen and really excited to be with you here. this very morning. My name is Alexander Bozier. I'm a fellow in management practice at the SAE Business School at the University of Oxford and I'm really excited to join Kim this morning to talk about our research that we did for the book Intelligent Change. Kim Thuesen We are looking forward to the European Union. Thank you so much Alex. I'm also quite excited and love your reference to the Eurovision. Obviously Denmark competes but we hope to do even better today. My name is Kim Thuesen. I am a partner here at Implement Consulting Group. I've worked with change management for more than 15 years in IT projects. And you can say actually my interest started more than 20 years ago as a young student assistant in a global organization here in Denmark where I shared an office with what I at the time thought was an older woman. Now I'm much wiser. She was probably only 50 but I was 23 and thought that was very old. And I very very distinctly remember Tina saying to me one day Kim I cannot comprehend all those new IT systems that I need to learn before I can retire. And as a young 23 year old tech geek that was very very strange to me. But it sort of sparked an interest and then some years later I was lucky enough to be a tech geek. And I was lucky enough to be able to be able to be able to get to actually work with the Tinas of the world. And later on together with Alex and other good people do this research and nerd even more into that. So that's what we're going to dive into. We will start out with a quick introduction to the research, the background and how we did it and the high level results. And mind you this is four years of research put into very few slides. But we'll do that. And then we'll deep dive into some more practical advice. And some of the key findings that also surprised us a bit. So Alex do you want to say a few words about the research? Sure. So same kind of journey as Kim went on sitting in that office but not so much about all the new programming languages to learn and all the new systems to explore. One of the things years and years of research including my own have shown is that when we're thinking about IT-led projects, transformation, digitization initiatives, one of the key factors to determine the success and failure of these projects is how well they manage the organizational change that comes with these projects. So that's why we started off to really understand what do we know and what don't we know about the organizational change and how these kind of projects manage the organizational change. And when you think about digital transformation two things are kind of the real challenge because you have to manage the organizational change at the same time as you change the technology. And both of these things require a very different skill set and both of these things also move in different ways and at different paces. So when we started out we obviously wanted to understand what has already been what is already known in the world out there. So I think we were a team of five and Kim and I and the rest of the team were reading through everything that was published on this particular issue of technology and organizational change at the same time. And there was nearly 2000 different articles and then we interacted and talked and workshopped with a lot of leaders and we then went into a deep dive of studying what information. information. So deep dive case studies which took us more than 200 hours of interviewing each of those. And the questions we asked them were all about what we call the seven levers of success. Once we read the literature we kind of distilled it into what are the common assumptions, the things that need to be true for change to be successful. We didn't say we wanted to end up with seven we ended up with seven in a big series of workshops with lots of practitioners and also other academics. And here are those seven. So the first one, the first thing that needs to be true for change to be successful is that there needs to be a structured approach to the change. So we need to have a plan or framework. Second thing is that we have to have a clear reason, a rationale, a purpose for the change. We need to we need management to take the ownership of the transformation can't be driven by the project account, be driven by consultants, it needs to be the management of the organization that needs to own the change. The fourth one, very, very important, particularly inspired by all the pushes and sort of the methodologies and agile and design thinking is that users need to be involved early. And then we need to build trust in the organization or with the organization with senior stakeholders, stakeholders, stakeholders, stakeholders, stakeholders, as well as with the end users and the future users of a new process, a new system, a new piece of software. We need to train effectively. And we also need to be our communication. So these are the seven things that looking through all what's known came out as okay, these are the fundamental things that drive the outcome of digital transformation. And what you see here is the data is the data that we are called we collected. So all the dots in these charts are the 155 different digital transformations that we studied. And on the horizontal axis, you see how well they performed in each of these layers. And our interviews, we asked people to rate themselves, we also asked questions why they rated themselves and record that kind of evidence. And the variable that's the outcome here is the success of the digital transformation. And that entails things like how satisfied were the stakeholders, the user, the project team, the project management, was the impact achieved? What was the adoption rate? Where the benefits realized that the project set out to do? So all of those factors or all of those characteristics combined into a measure of success. As you can see here, the great thing is that there is some truth to these fundamental beliefs because all of these blue curves point upwards, meaning that if you are doing better, the digital transformation, any of these things, any of these things, say, tick the one on the left, if you have a little bit of a clearer reason and purpose for the project, for the transformation, then that increases the success. But you also see that some of these curves are steeper than others, meaning that some of these factors are actually more important to make your digital transformation successful. And if you go to the next slide. What that tells us is that we can prioritize things. And we also found that once we start prioritizing things, other good things will naturally happen. So in that case, actually, not all the things we expected would have a direct impact on the success of the digital transformation had an effort. And that led us to thinking. And that led us to thinking. And that's what we want to talk about today. Actually, about the logic of, you know, it's a little bit of waste in our activities. And we want to sort of show you, based on the data that we collected of the things where we typically, in many, many transformation, way to overinvest, and we should stop doing that. And instead, slightly refocus our efforts on doing other things. And here's our first example of what that looks like. What we found in the data is that kind of the belief that we have to have a structured approach to change. And what we found in the data that actually having a structured approach or less structured approach, it doesn't matter during the execution of the project, we found one element where it actually is important. And that is when you have to go in front of the investment board and ask for more money for more money. No, for more money, no, for money, not for more money, hopefully that's not going to happen, but for money to get your project started. Interesting enough, in our data, once you got that money, that plan, that structured approach uses all its usefulness to drive the actual success of the transformation. So that got us thinking. And well, Kim, what was our conclusion of, you know, what should we do instead? Yes, thank you, Alex. That was obviously a surprising finding for us that the structured methodology and approach doesn't matter that much as we thought. And I can say as a consultant coming out with these kind of frameworks, it's a little bit devastating. But it does make sense, actually, when we dive deeper into the data and thought deeper around it. I think in the research, we found around more than 250 different methodologies and frameworks. So if one of them was the framework that could encompass all kinds of change, then they would need the 249 others. So maybe there's something that it's not the methodology or the structured approach that does it as such. Secondly, secondly, is also something around. I, early on in my career, spent a lot of time writing 25 plus pages, Word documents about our change approach for this project coming up. I'm not sure anyone actually read those, not even the steering committee who were giving us money. So maybe there's, I at least spend a lot less time on that and see if we can get by with agreeing on what are sort of the core principles of how we drive change in this particular project. So what we want to advise you on doing is spend a little bit less time on crafting that methodology or following that exact long-term plan, but actually try to also help your key stakeholders, your sponsors, understand that change is not a linear process, understand that change is not a linear process. We can try to make it and that will help us some way, but we also need to understand that we need to be able to react. So we try to avoid those really, really detailed, I've done a four-year change plan for a global project. Didn't make much sense. We ended up doing a lot of other stuff. But try to do that. And then try to understand sort of the signals from the organization. So spend more time out there being with the organization who is to receive this, understanding their actual sentiments, their actual attitudes towards this change, and then try to maneuver those into the plan for the coming three to six months maybe. Another very, which is also part of the book and which inspired us quite a bit is the capability-based planning approach, which is a lot about we know what kind of capabilities we need. We need someone who is good at stakeholder management and change. We need someone who is good at communicating and setting a communicative direction. So we also need those kind of capabilities. We will most likely need someone who is good at training. We will need someone who is good out there in the organization to understand and be in dialogue. So if we can have those capabilities in place, we can actually move ahead. So those are sort of our advice to you in a more practical level when it comes to instead of crafting a big plan. So that's the first one of the things you should stop doing is spending hours and hours and hours on that big change framework. But also other interesting things, Alex. Indeed. The other thing that really, really surprised us because this is the core mantra of the agile movement, early end-user involvement. So there is, when we're looking at digital, that big, big push to involve your users early. And then at the same time, like Steve Jobs' very famous quote of saying is, well, you know, it's not the user's job to know what they want. And actually, that's what we found in the data. So we measured when in the project was the start, when the transformation starts, the user involvement. And we actually found that the earlier it happened, the less successful the project was. So it was not only just completely flat, the curve, it was even slightly negative. And that really surprised us. And then when we started digging and asking these people, okay, you know, it sounds like it sounds it must be true. Why is that not bearing out in the data? People were telling us a lot of things about us. And, you know, you have to realize the realities of the organization. We work in the organizations that we work in. And those mean that the users are very, very busy. So actually getting the true experts in an organization, those busy, the very busy people to be involved in the project to really get into the project is super, super hard. So you might ask for a subject matter expert from accounting. Typically, you get the person who has a bit of slack. And, you know, they can just hand over for a while to your project, and they wouldn't miss much. Right? It's not the true person who carries the knowledge of the organization. And secondly, what we also heard over and over again, because change takes time. On average, the transformations that we looked at were about three to four years. So there's a lot of churn and turnover with a lot of knowledge loss in the user base. So what we've heard in our interviews was that it sounds like the right thing to do, a good idea and practice, but it is, it's such a hard thing to do in practice. So with putting our thinking caps on, we thought about, okay, what does that mean? How can we crack this and see whether we can change this and actually create meaningful end user involvement? Yeah, and it was, as Alex mentioned, a very, very big surprise to us all that in and of itself, early user involvement doesn't help. But it also did make sense that we have a lot of experience. sense once we thought more about it due to the reasons Alex mentioned. And I've also been in many projects where coming from a finance background or coming from, you know, shop floor background, being thrown into a big IT project in the early phase with a huge uncertainty and what do I, what am I supposed to do? It created more uncertainty and mistrust, actually. So those were some of the things. So I think when we are to involve users, what we really want to do is to think about who and how and what do we involve them in. So there's something about identifying and getting access to the right people who are always busy in any organization I've ever been in, but getting them in and then being very clear also on what is their tasks. And we could see in the data that especially if we can put users in front of something tangible, like testing, even mock-ups of a new system or a new process, then that's going to be a little bit more. So that's much better than putting them in front of a blank drawing board and saying, hey, what would the perfect accounting process look like? So try to do that. And then as we state, raise our level of ambition and involvement. So really carefully craft how we involve, how we ensure the right energy in that room, how we ensure to get the knowledge out of them, the experts in a way where we also create a level of trust towards the project. That's where we really want to spend our time. So Stine is asking, just to be clear, involving the wrong users is bad. Is that what you said, right? Well, yes, you can say there's something about who to involve and what to involve people in or how to involve them. So just putting the best procurement expert in an early stage IT project and asking him or her, what would the perfect procurement process look like for you? Please draw it. That's super difficult for a person who is used to be very operational or can be at least. I've seen that can be very difficult. So how do we involve that expert? How do we get their feedback in the best possible way? That's what I think we need to spend more time thinking about rather than just getting, you know, flat 50% allocations of experts and then put them in the project room and hope magic happens. That's our advice. Yeah, this one was also fun, especially our communication colleagues. Alex? That is very, very true. We actually, and this was another one very, very much surprising thing. It was, so we asked that kind of question to all of these transformation interviewers and sort of said, how clear was the vision, the rationale, the purpose of, for the change and for the change project? And what we found is that the clearer and redefined that vision was before it went, was communicated into the organization, the greater was the resistance to the change. So the more chiseled this all was, the less people had a positive, helpful attitude towards the change and the project. So that was really, really interesting because of all the things that we know, right? Build a vision and then people will fall in line behind it. Sort of the idea that a vision is the key thing to get people to have a commitment to the change was totally unsupported in our data. And actually the opposite happened. And so again, we had to think hard about it. So what could be the reason for that? And what does it mean, you know, in practice, because obviously we all, you know, really know and sort of drill down into us for the last years and years and years, that's everything is about the big why, get the big why, clarity around that. That's the job of the leader of a transformation. But no, it's not. Yeah. And obviously there's new answers to everything we're saying, but we are trying to provoke and start a conversation in the change community as a whole, also based on our data. And the data is quite clear and quite strong. So there are, of course, good reasons to spend some time on crafting that clear and strong vision. But what this has done for me, at least in my work is that I spend less time on it than I used to. And I spend more time on crafting those little whys, you can say, out in the organization. What does this mean for the shop floor workers? What does this mean for our warehouse people? Trying to break down that strong vision and make it meaningful to the different user groups instead. And Claudia, I see your comment about I've never heard a user or an employee saying I've heard enough about this transformation or about this project. You are absolutely right. We often get the I didn't hear about it. I didn't get enough information. On the other hand, I don't think I've been in many organizations where they say there's a lack of communication. So when it comes to effective communication, it's getting help to sort of stay clear. of all the clutter and all the clutter and all the other communication and be effective in reaching the right stakeholders with the right message, being in dialogue with them at the right time, rather than just blasting out more information or more communication. So I think it's that, you can say, intelligent way of communicating that we're trying to advocate for, rather than more and stronger, and then making it really meaningful on a more lower level, rather than crafting those big, big vision. So I hope that's a more and more. And then I think I think I think that we're trying to do a more and more. And then I think I'll just say a few words on the dialogue part because we can see that really makes a difference in the data we have if you engage in dialogue. And dialogue is not sending out a survey. Sorry, it's not. That also shows quite clearly. But we try to spend more time on that, being out there, understanding what's going on, and being in dialogue to really get feedback. I see too many projects. I see too many projects blasting out communication. We are now 63% done with the UAT. And the users are going, what does that mean to me? Why is that important? And obviously, it might be a huge milestone for the project, but no one in the world around them cares. So yeah, these are our practical advice. And we are there's nuances to everything, of course, but we still strongly believe that we have very, very clear data that shows these things. And then there's organizational peculiarities around and culture in every organization that you need to get into. So I think those are our key things for now. But these are our key advice that what we think actually works. Do you want to say a few words on that, Alex? Sure. So the one thing we found that the structured approach to change doesn't help in the execution of the project. So we need to create something that builds in flexibility and, but also satisfy the needs of the logic of the organization, how they govern investment, that there needs to be some structure and accountability process to, of course, a transformation. Second thing is we found, as we just said, that we need to co-create the reason for the change. So rather than crafting the change, invest the time in engagement and co-creation processes. We found that frontline management, generally all management needs to take ownership of the organization. As we just expanded, we need to use involvement is good if it's done right. If it's done badly, it doesn't add any value and might cost you a lot of benefits that you never, ever thought about. So there is a very, you know, thinking that through and how to best approach this is really important. We didn't touch upon this today, but we might in the future, maybe now we've got a poll coming up. What do you want to hear about next? But we found that trust is a very, very important component of, or building trust-based relationships around the project. We also found that sort of these days we need to co-design, training should be on the job, et cetera, et cetera. And when it comes to communication, and as Kim just said, there's one big element that we found is that, so it needs to be dialogue-based. And that actually means the most important skill in communicating is listening, not talking. And that very frequently we have to help and empower others in the organization to do the listening and the talking on behalf of the transformation project. So it shouldn't be us who are the key communicators, but it should be line management. And they certainly might benefit from a little bit of coaching, support, et cetera. So those are kind of the seven big things we found. And so, well, I think we've got a few moments to pick up some of the questions, don't we, Kim? Yeah, maybe you can, we'll bring up the poll for you so you can let us know what you would like to hear more about. And this will be around building and leveraging managing ownership or how to create trust. As Alex alluded to, it's a very, very important topic that we can see in our data. It's actually probably the most important level that we can do, and it's not easily done. Then there's something around communicating effectively. What does that mean in practice? How to involve, as we've also touched a little bit upon. Then something around designing and delivering training with impact. And also how to structure a change approach, as we have talked very little about it. And Jonas, I did see your comment. There can still be very good ways and reasons for having a common approach and a common language to change, as ProSci offers. Or it could be something around how to utilize your reason for change in an optimum way. And those are sort of the things that we wanted to throw out there. And if you have any questions in the chat, I think we can take one or two. We'll see if the poll. I can see you are already voting and it's a fairly even game on my screen. Well, we're looking for that. Maybe expand a little bit on this process thing. So, you know, there's nothing wrong with the process models. But what's wrong with the process model is that they indicate a certain logic of the steps. You should do awareness first and then desire, etc., etc. So what we see is that you need to do all these things all at once. And when I talk to digital transformations, somebody gave me this beautiful metaphor of thinking about the military, where this whole idea of capability-placed planning comes from. The military has two modes of operations. The one is the creative, high-impact, getting-stuff-done mode. So it's kind of the order of take the hill. And you've got all the different capabilities that you need in the place and they will just find out how to take that hill. That's one mode of operation. And then there's the other mode of operation, which is logistics. Moving material and personnel all around the globe. So one, the logistics, that takes tearful planning, big risk management, meticulous management of interfaces, gunshots and milestones and all those kind of things. But that's fundamentally a very different mode of operating compared to the very creative, you know, achieve this objective. You're all capable people. Go and do it. And I think that's one of the fundamental things we're thinking about is why the structured approach to change doesn't work is because we're often in that kind of take the hill situation and try to put a milestone, a gunshot, some ordered process of do this first, then that onto that. And that is not the most effective way of doing it. Or not the most successful. We are running out of time because it's so interesting. But we really hope to see you. Thank you for joining. We will take the poll and what was in the chat. Thank you so much for joining today. And we hope you have a wonderful day out there and that you got a little smarter today. Wonderful. And look forward to seeing you in August for the next one. Thank you.