Hello and welcome to our little videotaped event about benefits realization and change. And change especially this time because you have already heard one event about benefits realization. But before we get started we just want to give you a short introduction to who we are so you know who's on this side of the screen. So Rasmus can I ask you first? Yes of course. My name is Rasmus Rydder. I'm with Implement Consulting Group and I've been working there for the last 10 years or so. But the 10 years before that I actually worked as a project and program manager in the private and public sector. And in that period of time I managed to make just about all possible mistakes that you can make in terms of benefits realization and that that motivated me a lot. And so for my last 10 years here within implement I've been working to figure out how to make benefit realization happen. And I've had that as my day job and then in weekends and evenings and holidays. I've also written a couple of books and the latest one was published in English this May. Yes. My name is Helena. I also work at Implement Consulting Group. I've been working here for five years and Rasmus and I were actually just talking about that. That means I will soon have a master's degree in benefit realization. At least that also takes five years here in Denmark. And that is what I do. I work a lot with Rasmus also with other of our colleagues on projects with benefit realization and I'm especially focused on the change part. So how is it that we actually help people make the change so we can get these benefits. Yes. And now we both mentioned Implement Consulting Group, which is a Danish consultancy that we work for. It was founded in 1996 here in Copenhagen. And it has just grown since that approximately 20% every year. And that means that we are today approximately 1,200 people more coming every day. And we are now in the same time. And we are now in the same way. And we are owned by ourselves. That means that we have almost 300 owners which all work for us. So it's quite a special place to be in. And that also gives us this freedom to do what we love and dive right into our passions, which is, of course, benefits realization. And I think if I should just add to that, then, you know, we also have offices in Norway and Sweden and Switzerland and Germany and one in the United States. So we're huge in Scandinavia, but globally, we are still a startup. Exactly. And what we will talk about today is right now we're giving an introduction. Then after these first five minutes, Rasmus will recap on the video that some of you at least have already seen about benefit realization. And then we'll spend the majority of time on change management. So how is it that we work with it? And we'll give you some really cool tools and examples of how we have done it previously. Then we'll try to wrap up after 40 minutes and say thank you. So we hope you will be inspired by this. Rasmus, first recap. Yes, thank you. And as you know, being a good consultant, we obviously would like to start out by showing you some numbers. And it has actually been very, very difficult to find good numbers about benefits realization. So it was not until recently that we found something that was not only based on surveys, but actually a study on 44 large IT projects within the Danish government. And what they found was that when they asked the owners of these projects, you know, how many benefits or how large part of the benefits did you realize, they answered less than 50%, even though that they could change their estimates right up to the point in time where they actually launched the IT system. And then when we looked at it and tried to figure out how many of the benefits could they actually document, it was only a measly 18%. And obviously, you know, as taxpayers, we obviously hope that the truth is somewhere in between the 18 and 50%. But nevertheless, it's a very, very low number. And of course, what we want to dive into is, you know, why are we in this situation? And one of the main reasons is that we are just, we are looking at these as IT projects, instead of what they really are. Because if we take a step back, then none of these organizations will actually realize any value if there aren't people in those organizations to actually use the IT that they're building. So taking a step back, we can see that we're not actually dealing with IT. So we're dealing with IT projects, we're dealing with change projects, which is of course, also the main topic of the day. And what we can also see is that even though every time we ask, maybe if you ask you or anyone in your organization who is doing project management, then if we ask them, do you think benefits realization is important, then they will say yes. If we ask them, do you think it's important to help your colleagues change the way they work? Then you will probably also say yes. But when we look at, you know, where we actually spend our time and money and efforts, it's not on the change part, it's not on the benefit realization part, it's on the technical deliverables. And so what we want to do today is to just briefly touch upon a new way of looking at change and transformation projects, have a small recap about, you know, how do we decide? design projects to create value and then deep dive into the change part. Okay, so what you see here is our view of change and transformation projects. And what we want you to notice is that down here in the bottom, there are a very, very basic project model with an analysis, execution and realization phase. And what we want you to notice is that, you know, all these projects, all these different tracks, all these different tracks, all these different tracks, all these different tracks that are in the projects, the technical track, the change track, and the benefit track, they all start in the beginning of the project and finish at the end. Of course, except from the benefit track, where we also want to track whether we actually realizing benefits after the project is done. And so we start out by designing the project in a benefit workshop or benefit realization workshop that we discuss extensively in the first video. And so what we want to do. And so what we want to spend the majority of time on is, okay, how do we actually do a good change analysis? And what elements do we need to bring into the change arena in order to make sure that the transformation part and the behavioral change part of the project is successful? All right. All right. So what we did was, you know, roughly speaking was to cross our fingers and hope that those, that IT system or the new product, the processes, they would actually fulfill our purpose. But what we want to do instead is to unveil the complete benefits realization process. So instead of just defining a purpose and then start to work on the deliverables, we want to clarify the purpose and figure out what, what does this really mean? What benefits do we want to measure in the end? What new behavior is required for those employee groups that are affected by the change? What new competences do they need? And what new IT tools, processes and so on, classical project deliverables do they also need as enablers to, or for this change. And so, normally, we also stress that this benefits realization process is built sort of on a cause and effect relationship. So if you are able to sort of take off the project deliverables, you manage to provide the employees with new competencies, and you help them change behavior, then you will also get the benefits. And of course, it also works the other way around. So if you don't manage to do that, then you won't get the benefits. And even though we portray both competencies, behavior and benefits as a black hole on the previous slide, the darkest part of that black hole is the new behavior part. And so when we look at where do things go wrong, this is usually where it happens. So what Helena is now going to elaborate a bit about is, you know, how do we actually look at that change part? So welcome back, Helena. Thank you, Rasmus. Yes. So just as Rasmus said, we will now do our deep dive into the change part. So diving into the change track, I'll actually start off with this story because it illustrates really well what normally happens when we work with change. So when we have a project, we usually design it in a certain way. We, for instance, in this case, design our project with signposts so we know where to go, when to stop. We also try to educate people how to ride a bike, how to ride a car. And we do all sorts of efforts to mark the way we have a path here, we have some lines so that people can follow them. Yet what often happens is that we have people like this guy, we call him the mammal, the middle aged man in Lycra. This mammal appears to be going to a guitar lesson or maybe he has to play with his band. But whatever he's doing, he's not following the path. So as a project manager or a change manager, these type of people can be very frustrating because we have spent a lot of effort designing our projects or our systems or our projects. So it's clear so it's clear so that people can follow. And yet we have these people like our mammal who are not following the rules. However, when we step out of the project room or the ivory tower or whichever we call it, we sometimes see that the world that these people are navigating in is not similar or at least it's not the same as the one that we have imagined when we designed the project. Because in the real world, there's traffic, there is a lot of traffic. barriers, there's a lot of things that the people, employees, colleagues meet that might make it very difficult for them to change. So that's our main goal when we work with change. We want to understand which world the people are living in, how they're actually navigating in the real world, and we want to make it easy for them to follow the path in the project, and we want to make it hard for them to do it the wrong way. And in doing that, we're basing our way of working on a lot of knowledge from thinkers that are much smarter than us, which is really lucky that they are there. And these are just some of the people that we use a lot. So the first one here is behavioral design from Kahneman. Some of you might know him. He's a Nobel Prize winner and has done a lot of research on what is it actually that makes people do what they do and which biases is it that we work with. Then we also work a lot with Mauer and his ideas about how is it that people are reacting to change, how is it that we see resistance, and especially how is it that we work to overcome this resistance. We also work with change via network. So how is it that you can say that the change spread in the organization, and we also use a lot of knowledge about how first line managers can be really important change agents to make this spread in the organization. So these are just some of the thinkers that we base our way of working on. And I'll just dive a little bit into the behavioral design part for beginning. So on this slide, we have displayed System 1 as the elephant and System 2 as the rider. And some of you, again, might be familiar with this concept if you have read Thinking Fast and Slow, which is quite a classic in this area. So our system 1, here illustrated as the elephant, is our intuition, our habits, everything that happens naturally. And that also means that this is a system or a way of working or behavior that is quick to respond. It's something we do without thinking about it. It also means that it doesn't require a lot of energy from us. We don't have to spend a lot of thought process or energy. It's just something that we do. Like if I ask you what's 2 plus 2, you already know the answer. You don't have to think about it. Our system 2, on the other hand, it's our analytical mindset. That's the hard thinking when we have a problem that we need to solve. And it takes a while for us to come up with the answer. For instance, if I ask you what's 16 divided by 328, you'll probably have to think about it for a little while before you know the answer. And maybe you will even have to use a calculator. It also means that it's hard for us. It takes a lot of time. It takes a lot of energy for us to use this system. And what we often see when we design change or when organizations design change is that we spend a lot of time convincing the writer, the rational part of our brain, the rational part of our behavior, what to do by explaining. You need to do it because of this greater purpose and we provide training so you have the ability to actually do this complicated math. And then we think. Then the writer will actually do it. But if you imagine that the writer is actually trying to write this elephant, it will be very, very difficult for the writer to control it. Even though the writer know where we're going, if the elephant is not happy or if the elephant sees an easier way, it's simply the way it will go. And very often the elephant will just go the way that it has always done. It's our habits, right? So we just fall back on that all the time. And it's the same when we see the mammal in the picture a few slides back. If there are barriers in our path, the elephant will simply just go another way. Because for the elephant, it needs to be easy. And that is basically our principles when we work with change. First of all, we do need to have this link between the behavior and the benefits. We do need to have the rationale in place. We do need to be able to explain why is it that we're doing it. What are the benefits you get out of it? Because both we need to cater for the writer, our system too, but also because change is hard. So we don't want to ask people to change their behavior if we don't get any benefit out of it. The second principle is that we have to make it easy. And I'll just double click on this picture because it just underlines the point that I've already made. That even though we have this project where we have designed this beautiful path, we have even put tiles on it and we have made a little walkway to make it clear that this is here that the people are supposed to walk. If our system one, our elephants, our mammals see an easier way, we'll simply just cut across. So when we work with change, we want to try to spot these, you can say shortcuts and understand is this a path that we can use in our project? Or do we maybe need to put up a fence so we can make it hard to do it in the wrong way? And one of the ways we have made it easy to work with change is that we have a pretty clear, concrete process that we follow. So in the analysis phase, we have a step by step process where we have a workshop. We work with the input we get from the workshop to get concrete input to our business case. And then in our execution phase, we are basing the design of the execution phase on the input we get in the analysis phase. phase, but that also has change activities throughout. But we'll start with the beginning. So Rasmus, will you just elaborate a bit on what it is we do in the workshop? Yes, I would love to do that. And I think the great thing about the analysis part here about the in the change track is that basically, we always ask the same questions. We always ask the same questions. And so it's possible to make it possible to make it quite easy to do the analysis part because it's always the same set of questions we need to answer in order to figure out what is actually needed in the execution phase in order to be successful with the changing behavior. But first of all, let's try and deep dive into the change analysis and what we want to get out of it. Because actually, we want to the change to have sort of the same output from the change analysis that we have when we analyze the technical deliverables. So we want a list of activities, we want the new behavior described, we want estimates for each of these activities, and then we want a plan. So basically, what we want to get out of the analysis sort of from a deliverable perspective is exactly what we normally get out of the analysis of analyzing what would it what would it take to do an IT system. But what we also want to get out of it is to make sure that the people we involve in this analysis phase actually is is will become owners of the change that we will get both both groups that we normally invite and that is line managers, and a couple of employees that we hope to transfer into ambassadors that we make sure that we make sure that we're going to be able to get out of the change. So that they both understand and own the change because we are going to need their help to make the change happen later. And what we want to do in the second half of this presentation is to really deep dive into the change workshop that is sort of the first element in the change track. So that we want to do a change workshop and we can do a change workshop as soon as we got an overall benefit map that we discussed extensively in the last session and which we will also sort of briefly touch upon in a minute. So when we have the benefit map and we have sort of a very handheld demo of what a possible future could look like for a particular employee group, then we can do the change workshop. And again, for the change workshop, we invite the first line manager and a couple of potential ambassadors for the employee groups that has to go through a substantial change. All right. So the first part of the workshop over here, setting the destination, here we discuss the first version of the benefit map and we show a very handheld demo and then we ask the first line manager and the two ambassadors from the two ambassadors from each employee group and then we ask them, okay, which benefits do you see for your team and for the business case in general? And the most important part of that question is, of course, what's in it for the team? Because that will sort of unfold their motivation, what's in it for them in the transformation? And so that's very important because we can use that through throughout the change. Of course, sometimes we also get an additional input for the business case, but it doesn't happen very often, but it's not really the purpose. The purpose is to make sure that we understand what's in it for them and get a good start on the workshop. And what I also want to stress is that as I said before, it's always the same questions that we ask and that is why we can actually print the facilitation question on posters to make it easier for you to actually do the change work. So keep an eye on sort of the B, C and D posters because you will see them later. But before we get started, we need to get the benefit map in place and the example for this benefit map and also for the rest of this example, is a project from Copenhagen University. It's actually from the Faculty of Health and Medical Sciences. And the overall objective here was to be more efficient when they handled test tubes and other types of glassware. And so if the purpose was efficiency, then that materialized into some energy savings, reduced maintenance, and reduced wages. And the trigger for all of these things was that it was possible for them to do or clean all the test tubes and other types of glassware in one place instead of six. So that was sort of the main trigger behind those benefits. And of course, in order to make this work, there was some employee group at the faculty that needed to change their ways of working. And one of those group was the lab managers. And that is sort of the focus. And that is sort of the focal point for our example. And of course, in order to make the change happen, we of course also needed to work on there or provide them with some new competencies and some new tools and new places to wash their test tubes and some stuff for the logistics part. But what we're going to zoom in on is the change part. And so this is the first poster. And what you can see is sort of the first step here is to figure out, okay, the lab managers at this faculty, sort of in respect, of course, to the task related to this project, what is their current behavior? And after that, what will their new behavior be after this transformation? And so we start out by just listing current behavior. And then we separate current behavior in what do they need to continue doing and what do they need to stop doing. And it's very important to do this because the stop doing part is important because that leaves some space for new behavior or it makes optimization or efficiency possible if sort of the overall ambition with the project is the way that they need to actually save time. But in this case, it is to make room for new behavior. And so once we've done this, we have a better idea of what do we believe is going to be new behavior? Because this is very early in the process and many people will probably have different perspectives on that. But when we have a basic understanding of what could the future look like, then we go back to the future. And the next step is to brainstorm on reactions to this change. And so we ask both the first line manager and the future ambassadors, okay, what reactions could this entail? I mean, how would your colleagues respond to this? And then we brainstorm and put it over there. And that's good to know what's coming. But in order to make it a bit more clear about what level of resistance can we look into, we use Mauer that Helena mentioned earlier. And he has sort of a four-step approach to viewing reactions to change. So the first reaction or the number zero is I like it. So that's probably not the type of reactions that we are going to worry most about. Then the second type is number one is a reaction called I don't like it. And so I don't get it. And that is usually a logical response probably based on that maybe they didn't receive sufficient information to actually understand what has to happen. And so in that sense, it's easy to handle. And so in that sense, it's easy to handle because it's probably just because they haven't gotten the right information. Then the next one, number two, is I don't like it. And that is an emotional response. Perhaps because I'm either losing status or maybe I'm concerned that I won't be able to do my job in the future. Many things here can be at stake. But it's an emotional response. And thirdly, I don't like it. And thirdly, I don't like you. This is a reaction to lack of trust. So either I don't like you as the project manager or either I don't like the people that you represent. And so what we try to do is sort of the next step is to sort of categorize these reactions to figure out, okay, what are we actually looking at in terms of reactions to the change? And of course, we do this because it helps us to understand, you know, what kind of activities do we then need to put into our change plan to get this group of employees, the lab managers, well through the change. But what we need to also remember is that before we ask the first line managers and the ambassadors to actually come up with activities, then we need to remember that, you know, they're probably not experts within change management. So often we inspire them a little bit about typical change activities. And this is what it often looks like in a workshop and Helena will deep dive into that a little later. But obviously, then we try to inspire the people at the workshop a little bit and you can do that too. And then get their initial response. And obviously, because they're not change experts, even though we provide them with a little inspiration, it's probably necessary after the words to add some change management knowledge to actually get sort of the best possible change plan, adding to what we got from output from the workshop. And when we have looked at what we call individual barriers, we need to also look at what barriers do we see in the surroundings of these employees, in this case, the lab managers. And there are two overall types of barriers. There are the technical barriers. And that is the stuff that they're usually building in the technical track of the projects. And those barriers are typically either IT systems, technology, digitalized tools, but it could also be sort of physical settings. It can be projects and it can be products and services. On the softer side, we have the organizational barriers. And that can be differences within the group. In this case, the group of lab managers, organizational structures, incentive systems, and so on that are not helping us in creating behavioral change and cultural norms. And I think it's important to stress here that not all projects have all types of barriers. So it's more of a checklist. What's interesting about the project that we're using here as an example from Copenhagen University is that they actually sort of had all the barriers. And so that makes it a good example. On products and services, they needed a new services so they could actually call somebody to pick up their test tubes and glassware to get it cleaned. And if you look at sort of the softer side, then it turned out that lab managers was not actually only one group. They were working in a very, very large building. So depending on which floor we were looking at, people were working in different ways. So for some of the lab managers on some floors in that particular building, the change was not very big because it looks pretty similar to what we were changing into. But for others, the change was substantially larger. So that can be an example of subgroups within a group. And of course, it's Copenhagen University. So obviously, every time you look into sort of the educational sector and where you do research, the word standardization is always a bit difficult. So there was something about adhering to the culture and norms at the university. And finding other ways to describe this, not to make sure to step on any toes that we didn't need to. But that was sort of the deep dive into the workshop. And maybe Helena, you can elaborate a little bit more about the execution part of the change. I sure can. Thank you, Rasmus. So yes, now we are at a point in the project where we have done the workshop, as Rasmus just said. And then based on that workshop, there will be some analysis. We need to understand what is it that it means, all the observations and information we made in the workshop. And all of that will give input to a business case that hopefully will result in the project actually starting up for real. And then in our execution phase, we base our change activities on our initial understandings from the analysis. But we also need to get a little bit wiser before we start it up. So when we work in, you can say, projects that are in execution mode, we have the these phases that we look into from a change perspective. And in the beginning, we of course need to look into the results from the change workshop. We need to maybe go out and do additional observations. Maybe we need to understand exactly how is it that these lab managers work today. We need to maybe get some people who understand people to go out and actually have a look at them and see how they work. And based on that, we can create some quite detailed plans on when is it that we need to do what and what kind of change effort is it that we need to ensure that we have in place. And then here in the very beginning, we also onboard ambassadors and first line managers because as we have mentioned before, these are going to be key people to help us succeed in the change. Then as the project moves along, we ensure to design and develop the new new behavior or the new way of working. And we do that together with the people who are changing. So we try to involve them a lot throughout the project to ensure both that we get input from the people who actually know what it looks like in the real world, but also to make sure that they feel heard and seen in the process towards the go live date. Then pretty close close to the actual launch or the release of the project, we do the training. Before that, of course, we have prepared all the material. We have decided how we want to train. Maybe there are different ways of training depending on how many different user groups or target groups that we have. But the training is pretty close to go live. And maybe it's also actually a little bit after go live so they can use the live system. And of course, we need to follow up on training and provide additional training if more training is possible. So we need to fully succeed in changing their behavior, getting the competencies and starting using the system. Then after go live, we do have, you can say this is where the entire organization is actually able to use whatever the project has produced. So we do have a big change effort here as well. So it's it's key to remember to have these good people, the ambassadors and the managers that we are on boarded. early to have them available as well because they will be the change experts, you can say, or at least the agents that the people will go to for help. So they need to be there as well. And one of the reasons why these people are so important is you can say as the role as network notes basically. So we use this method or it's a this theory of backstage leadership where we equip the ambassadors and the first line managers to actually have these conversations with the people that they're close to, to and to help them both with technical questions, but also with how to manage resistance, how to manage actions to change and to help them get into to the new world of change. And the reason we do this is that these people have the close relation to the people who are changing the way of working and they also have their trust. So when we say backstage leadership, it's not a form of manipulation. It's basically just to make the change easy for the people who are going to change by allowing the people that they know and they trust to communicate with them and to maybe also you can say interpret the technical words of the project manager in a way so they understand it. And it's also a really good way to the project manager to extend, you can say her reach in the organization to make sure that you actually get to all the people that you need to, to, to get to in order to succeed with changing behavior so we get the benefits. So this is a key tool to or a key way of working if you want to make sure that the change is actually spreading in the organization. So that was the the, some words on change. We could say a lot more, but for now we are slowly running out of time. So we will try to limit ourselves and just say a huge thank you for, for listening. And hopefully you got inspired in different ways of, of designing projects and working with change. We at least think this is a really cool way of, of doing it. Yes. And, and, and, and so if, if, if you have any questions or you, you want to just reach out to, to ask us a question or maybe get us, get a piece of advice, then please don't hesitate to reach out to us. And, and we are, we are also trying to, to help make the use of benefits, realization and change easier by providing a lot of resources at our website. So, that's on implement.dk. So here you can find both other videos, but you can also find, cases, templates, and other kinds of inspirations. So please feel free and download whatever you need. We hope that will help you on your benefits realization journey. And of course you can also buy the book. It's available all across the world in all major online books. stores. Yes. Yeah. And we do hope, of course, that you are a little bit curious and maybe you have some questions or some comments, then we would really appreciate to hear from you. So our email addresses are here. You can also call us all the way from Australia. Just make sure the time zones are worked out if you want us to pick up. But we would love to hear from you and continue this conversation with you also live. So thank you. Thanks for that. Yes. Hopefully talk to you later.