Welcome everybody to today's event that's called Beyond Benefits Management, the next steps in value creation. And we have been looking very much forward to this. And by me, I of course mean you, Peer, from Aarhus University, our special guest star today. Peer is a very significant voice within benefits realization in academia and known for his ability to bridge academia and the real world. So there's much to look forward to. You'll get a chance to say a few words about yourself in a second, Peer. Before you, I hand the word over to you. My name is Rasmus Rydda. I'm with Implement for almost 14 years. I'm a partner in Implement, but the real reason I'm here is because benefits realization is really my big professional passion, to the extent that I have been spending evenings and weekends and holidays writing books about it. And the first one with you, Peer. And that is actually what sparked an idea for this event. But maybe you could share a few words about yourself, Peer. Yes, absolutely. I have a little bit of a special academia background because I've been working 25 years in industry before joining academia. And then I've been in academia since 2007 at Aarhus University. And I've been researching a lot of our projects, value creation, benefits management. And I always strive to bridge between practice and research. So I think that's also the reason why we wrote this book. Absolutely. Because we want to bridge the things. So that's probably an introduction to me. Yeah. Thanks a lot, Peer. You know, you'll get back in just a second. But I'll just introduce us to today's agenda. We are in the midst of the welcome introduction part. And in a little while, we'll start off by looking at the sometimes painful realities of benefits realization. Then Peer will get back on stage and talk about insights from research. And then I will be back to talk about best practices, lessons learned from a decade of projects. Then we will take a small peek into the future. And then we will wrap up and ask questions. And we will probably take most of the questions in the end. But feel free to just write along in the chat. Then we will ask or answer as many as we can in the end. And then we finish at 9.30. All right. But just to give you an introduction to me and Peer's work with benefit management. For me, it started more than 10 years ago when I, together with a good colleague, Jesper Linn, and others, wrote a white paper on program management that included benefits realization. And we thought that was so intriguing and so an underdeveloped topic that we decided to write a book about it. But we also knew that it would be good to have a friend from academia. And that was where Peer came into the picture. So the three of us together wrote a book in 2015 called Benefits Realization. And then much has happened up until today. Peer published his book, Project Management and Implementation of Complex Changes. And Peer also did a lot of research, among other things, in the half double methodology. I know Peer will be tapping into that later. And frankly, there was no room for all the cool stuff that Peer has made. So you need to forgive us for that. But then a couple of years later, then we were looking at our experiences with benefit management and benefit realization project for the couple of years that has been passed since 2015. And we found out that the benefit part from that book was actually quite good. But what we needed was a stronger and combined approach of benefits management on the one hand and change management on the other. And so again, I spent some evenings and weekends and holidays writing two books about that. And it's actually only one book, but in two different languages. So that was the focus. And now more years have passed. And today it's 10 years ago that we published that first book in the autumn of 2015. And that sparked our interest in looking at what has actually happened since then. What's still true? What best practice has emerged from practice and research and taking a look into the future. So I hope you're up for that. We will start by looking at some data on benefits realization. And since I've been working so much with benefits realization for many years, I had an idea that, you know, I pretty much knew where we were in terms of how good organizations were at actually realizing their benefits potential. But last year we decided to go from thinking that we kind of know to actually knowing. So we made a big survey and the report from that survey was called predicting transformation success and failure. And the key question in that survey was, and it's the same that's on the screen now, it was overall, what percentage of the benefits potential do you think your organization is realizing in your change projects? And these are the answers. And every time I look at these data, I don't know what's worse. If it's the fact that only 18% of the 145 respondents said that in their organization they were actually realizing less than 20% of the benefits potential. Frankly, I think that's a bit wild. But it's also a bit wild that only 3% of those 145 respondents said that they were actually realizing more than 80% of the benefits potential. I think that leaves a lot of food for thought and a substantial improvement potential. So what I would actually like is for you to give us a little input on this as well. So what we have done is that we have prepared a small poll for you and we would actually like you to answer the exact same question. So on average, what proportion of the benefits potential from change projects and change transformation projects is realized in your organization? And it's fair enough. If you just take a stab at it, that's quite all right. And the categories you can choose from is, is it above 80%? Is it around 50 to 80% of the benefits potential? Is it 20 to 50% of the benefits potential? Or are we in the less than 20% of the benefits potential range? So please spend a second answering this poll. And while you're answering, I'd like to invite you back here, Pierre, because I would actually like for you to also have a look at the results. But I think that normally there's a small lag, so we'll just give you a little bit of time to answer. And if you're in the car, please don't answer the poll. Then focus on getting safely to work. All right. I can see there's a lot of responses coming in. And I think it's fair to conclude that the majority is in the 20 to 50% range. And we have nobody in the 80 and above. And then there's also substantial part in the 50 to 80%. And also some in the below 20%. And, you know, Pierre, an initial reflection from you when you see these numbers. Yes. First of all, I think we need to understand that this is perception. That's the way people feel about it. Because when we sometimes investigate it more objective, we see a different pattern. So so. But but it's true to say that there is problems getting the benefits. That's that's true. It's not easy to get. And that's something we'll dig further into our presentation today. Yeah. And actually, it's a bit funny because we have answered. We have asked the same questions for events like this and physical events and companies. And we almost always get exactly the same results as we are getting today. And I think that's good and bad because I was, of course, hoping that we would have seen a stronger transition. But I guess it just leaves us for a bit of room for improvement. Yeah, for sure. For sure. And that's what we'll be talking about today. That is what we'll be talking about today. Yeah. All right. I'll leave this over to you, Pierre. Thank you very much, Rasmus. And I will continue digging a little bit further into the research part of of this webinar today. And I've called it the benefit beyond benefits management insights from research. And the topics that I will cover is I'll try to look back to look forward. Looking back at our book 10 years ago, I'll try to give you some theoretical perspectives, which hopefully could advance our understanding. I'll talk a bit about the half double methodology, which you already introduced. Rasmus, which is a proven methodology for focusing on benefits, realization, impact creation, etc. And then I have three key takeaways for my presentation. First of all, looking back to look forward on looking back means looking back 10 years ago. And the book we wrote at that point of time. I think one of our understandings at that point of time was that we had what could be called classic benefit realization. And with classic benefit realization, we mean that we focus on traditional cost benefit analysis, very quantitative oriented and very focused way of doing cost benefit analysis. But we thought this is not enough. We need to think broader about benefit realization. And that's what we did in our book at that point of time. And that's the reason why we call it benefits realization 2.0 at that point of time. And I'll now dig into some key points from this sinking 10 years ago. Realized or mentioned in five points here. The first point is that the projects and benefits are not fixed in time. We think that we can set up benefit and goals at the very beginning of a project. But real life tells us this is not the way we can do it. Because we also have to understand that things develop over time. So very often we think of some initial benefits, but we see that other benefits realize or emerge during time. So we have to be open about this dynamics we see in benefit realization. That was one thing. And that leads to the next point, which is that many benefits are emergent and they are context dependent. What do I mean by that? I mean that they emerge during the period as I told in the first point. And the second thing is that it's context dependent. Because you can for instance implement the same IT system in two organizations and it will develop very different. So you can't just say we have some standardized benefit in one organization and then copy it to the other organization. It is context dependent. That does not mean that you can't learn from one organization to another. You can learn a lot of things, but you have to be open to that things are context dependent and you need to understand what is the specific context I'm working in. Then very important is that value is more than monetary. It's not enough to think in only quantitative terms when we are working with benefits management and benefits realization. When we are working with cost benefit analysis, we have to be open to that there's a lot of other things which happens in a project. For instance, learning and innovation. And very often that materialize a long time after you have launched a product or service. So you have to be open to the other parts of the project which create something which is not where you're not able to quantify directly. Then a thing which is still very important. That is the project must engage in benefits harvesting. What do we mean about that? We mean that it's not enough to focus on the technical task of launching product and services. We need to do something to harvest the benefit to make sure that the organization gets adapted to what we have been working with and realize the benefits in real life and not just start up using something new or merging with another organization without taking the benefit. That means active benefit harvesting, which is important. And then finally, we have a more theoretical perspective called a resource based view. And a resource based view say that when we do something in projects, we want to create capabilities. Capabilities are something that an organization can have. It's something that people can have. It's something that people can have. For instance, you can build an IT infrastructure which is very, what should I say, open to digital transformation. It's open to digital disruption. So you can prepare the organization. When you prepare for this, you don't get the benefits immediately, but you build up capabilities which later on could be enacted. So these were main arguments 10 years ago. And the good news is all these arguments still hold. It's not that we have to skip these arguments. They are still valid. They are still something you should focus on if you are working with benefits management. Then I'll move on to the next topic for my presentation. That's theoretical perspectives to advance our understanding. I've been digging into the research literature and I have a few slides about that. And I think the key word here is stakeholders. That's a key word because I think that benefits management and stakeholders are so highly related, which I think you will see when you see my slides about that. First of all, what do I mean when I say beyond benefits realization? Here you have a figure where you see different parts of a project or a life cycle of something where we start with project conceptualization. That's where you build or design the way you do the project. Very often you prepare a business case here. Of course, you can have a very good business case or a modest business case or not so good business case. Then you start on doing project delivery. And in the project delivery phase, you have to be keen on how do we achieve the benefits we have stipulated, but also open to that something could happen in the project which we need to adapt to. That was the emergent part of benefits, which I told on early on. And when you launch the product or service after doing the project, you run into this harvesting benefit phase. It's called a benefits realization phase because it's not enough that you launch a product or services. Very often you have to do something active in order to really gain the value and the benefits out of this. And of course, you can get more or less as it's shown on the figure. And then looking back 10 years ago, that was where our book stopped 10 years ago. But now I would introduce you to that. We even need to think beyond that point where we have been harvesting the benefits. We also have to think of that there's something called benefits sustained, which means that to keep the benefits after we have been harvesting them, we need to make sure that we still have the benefits. And it could be if you don't do anything that you have what is called benefits atrophy, which means that it degrades over time. You might even think of how can we enhance benefit. So when I say beyond benefits realization, I really means benefits sustainment and benefits enhancement. And this is an extended view to what we said 10 years ago. I told you early on that stakeholder is a key word. So what can the stakeholder theory tell us about benefits management and project management? First of all, context matters. We need to identify the stakeholders from the very beginning, which could be context driven, as I told about earlier. But it's also important that new stakeholders may arrive. We might have overlooked stakeholders. So it's dynamic. And we need to make sure that we have continuous engagement with all stakeholders in order to get the benefits out of the project. Then we also have to focus on multi-win and interdependencies. Multi-win is that when we have so many stakeholders, it's difficult to satisfy all these stakeholders. But we need to work on how we can align the stakeholders and get something for all the different parts of the stakeholders. That's the reason why I say multi-win, because we have to satisfy many stakeholders very often. And sometimes these stakeholders are depending on each other. For instance, if you want to work with solar energy, a community might not like the plants that you are building, but the organizations which are delivering it like it because they get profit out of it. So you have a conflict. But you need to find a way where you can combine these things, maybe by giving incentives to the community for having the solar plants. That's just an example where you need to align stakeholders and where you have to focus on benefits and value to a broader stakeholder area. Last but not least, you have to be innovative and you have to have an ethical approach. Innovative thinking means that you should focus on how could we build this project in a nice way so we can get value to all the different stakeholders, which is a difficult task and it even becomes more difficult over the years. And then the ethical part of it is that we, of course, have to take ethical consideration into account. We have to focus on sustainability issues and we have to understand that we should also focus on long term success and legitimacy for all the stakeholders. This leads to the last slide from this theoretical perspective I'm having today, which is called inclusive strategies, which means that we need to create win-win-win, win-win-win for all stakeholders. And that's difficult, but we need to understand what it is. We need to understand who are the stakeholders. And here we traditionally have focused on what is called market stakeholders, which are customers, suppliers, investors, project sponsors, consultants, etc. But we also need to focus on the non-sparket stakeholders. That's local authorities, local communities, as I talked about early on with solar energy, unions, labor groups, social movements, NGOs, media. Not forget media. They are very important and they are also something you need to take into account. And they can impact value creation very much and the understanding and the discourse about projects. And last but not least, we have to have this sustainability focus. It's not enough to focus on profit. It's not enough to focus on people. We also need to focus on planet and nature. And this makes our work with benefits management much broader and much more complicated because we have to take all this into account. And this is not an easy task. And that's one of the reasons why it is challenging to work with benefits management. Now I'll move on from what we said 10 years ago and some theoretical perspectives to the half-double methodology. The half-double methodology was built to focus on value creation and benefits management. So I can say also from my own research that it is a proven methodology for impact creation. Half-double methodology is built around three principles. I'll only mention one principle here and that's the one which focuses on value creation and benefits management. It says stakeholder satisfaction is the ultimate success criterion. If you think about this statement and connect it to what I said earlier on about the broad stakeholder group, then it becomes difficult to satisfy all the stakeholders. But if you don't focus on satisfying all the stakeholders, you really might run into trouble. And that's what it says here. One of the reasons why you could use and should use half-double for value creation and benefits management is that it focuses on impact over output. What do we mean by that? Very often projects has been focusing on delivering products and services. That's not enough. It's much more important that we focus on delivering value creation. And sometimes that could be that you should focus different on products and services in order to focus on value creation and impact. Then you also have to focus on accelerated value delivery by emphasizing flow and speed. The quicker you can get value out of a given project, often the better. Then also be adaptive and context driven. It's a half-double methodology that is built to be very adaptive and to work with what we call local translation. And the good news here is that we have proven results from using half-double. We have a quite high success rate of 74% and there's a strong relation with the project outcomes creating measurable value. And we have been doing over the last 10 years, we've been doing a lot of research into this. This is also reflected in the next slide here, that there is a high correlation between the more you use the practices in the half-double methodology, the higher you can impact project success. There is a clear relationship. All these dots here are different projects which are measured. And then we have drawn a correlation line or regression line, which shows the relation. And I think that more or less proves that working with this, you could be able to focus more on getting success and working more with benefit realization. This leads to the last slide for my part of this webinar, where I have three key takeaways for you. First of all, benefits management must evolve beyond static models. Things are dynamic, emerging things happen, be able to adapt to all this, accept that you can't fix everything at the very beginning. Many things happen over a project course. Then stakeholder-centric approaches are essential. I think one key word from my research part of this presentation is stakeholders. And I have shown the diversity, the broadness of stakeholders. And you need to take all these stakeholders into account if you want to work with benefits management today. Finally, I have shown a bit about that the half-double methodology are able to drive measurable impact. And then you can, that you have a more practical way of doing it. I haven't had time to go into any details about that. That's another story. But at least I can show you some of the good research results. And here you have a specific way of doing it. That was my part of the presentation. Thank you very much, Pierre. And I think that there are some super interesting points, both in terms of the longer outlook that, from my perspective, makes both tracking and the portfolio perspective more important. Yeah. And of course the stakeholder part, where it also sort of points to us that benefits realization should, in essence, also point a finger at us to take a larger responsibility, also more than just the cost and benefit part. Exactly. Exactly. Thank you. Thank you for now, Pierre. Yeah. Then I will take over. I think, actually there's one question. Please keep them coming because we will have some time later on in the presentation to do the questions. Okay. But what we're going to focus on now is that we're going to take a deep dive in the lessons from the last decade of projects and highlights of the key elements of the things that have really proven themselves through the last decade. And I would like to start by showing you this slide and I apologize in advance. It's a little bit busy, but what I would just like to share here is the model of how we see change and transformation projects. And if you start by noticing here in the bottom, then we have a very, very basic project model. And above that, we have three tracks that sort of contain the content of the change and transformation project. And down here, we have the technical track. That's probably the one that most of you are most familiar with. That's where we sort of make the product or the service or whatever it is that we're doing. But then there's also a benefit track and a change track. And the key message here is that from the very beginning of the project to the very end of the project, there's a job to be done, not only in the technical track, but in all three tracks all the way through. And that's a key point. And exactly the only exception here is the benefit tracks that actually extends after the project is done. So make sure that we keep tracking benefits as Peir just said before, that we are able to do the sustainment and enrichment activities that we need to do. My final point in this slide is that what we recommend is that we kick off these change and transformation projects with a benefit realization project workshop where we design the project in the very beginning. And that has been one of the things that has really turned out to be super, super valuable. So we will touch upon that in a little while as well. Okay. Okay. So what we do or what we see or what we saw 10 years ago and what we unfortunately still see is that many of the change and transformation projects are designed where we start out by looking at a purpose and agreeing on that. And then we jump straight to the project deliverables and then, and forgive me for being a bit rude or blunt, but then we just cross our fingers and hope that something great will happen. And that will make the project deliverables help us fulfill the purpose. And then, and I think that if you want to be part of that terrible statistic that I showed you a couple of minutes ago, this is the right way to design your projects. And actually this was a key element 10 years ago and it still is because that is unfortunately still roughly the way many change and transformation projects are designed. So what we suggest instead is that we keep starting out by looking at the purpose and the purpose is important because it says the overall direction for the project. But, and then instead of jumping straight into deliverables, then we need to have a look at what benefits do we need to realize in order for us to fulfill our purpose. And the interesting thing about benefits is that it's usually a multi-step thing. So you might have a big sum of money in the big, in the end as an end benefit, maybe want to save some money or save some time for other interesting things. But then we also need to consider, okay, what improvements in performance is it that will free up this time for us. And once we have defined that, it also, it will also appear what parts of the organization that actually needs to change in order to make this change happen. And I think this is actually the key question in change in transformation projects. How does the organization need to change in order to realize the benefits? So that has become the key question, not so much what deliverables do we need? Because if we ask the question, what needs to happen in order for the organization to change its way of working in order to realize benefits? Then we will have a conversation about, okay, how big a change is this for the organization? What new competencies do we need to put in place in order for us to make this happen? And then last but not least, we have the deliverables, the IT systems, the tools, the new reports, the whatever that you, that the organization need in order to change their way of working in order to realize the benefits. So in essence, this changes the focus from what is it that we need to do to what benefits do we want to realize and what does that require from the organization? And now we will show you an example of how could this process design look like and what would the outcome be from a benefit realization workshop? And forgive me because I know this looks a little messy, but this is actually how it often looks. And this is a process optimization and digitalization project in a job center. And what you will see here up in top is that we have the purpose, the benefits, the changes in behavior, the competencies and deliverables, and then everything on index cards. And what we have done here is that we have gathered senior representatives from that municipality and discussed, OK, what could the purpose be? What benefits do we need to realize in order to fulfill the purpose? We have, as you can see here, detailed, you know, what performance improvements will drive these benefits. And then we have listed the number of people and roles that would be needed for us to succeed with this change, the competencies that they would need to have, and then the deliverables that we need to work on. And of course, if you spend three hours doing this workshop, then you will know exactly what this means. But obviously, there's work to be done after this, obviously, mostly very, very interesting workshop where we get aligned on purpose, benefits and so on. But then after this workshop, there's a job to be done. On the benefit part, we need to do some analysis to really understand what's the potential. On the change part, we also need to do some analysis to understand how large is the change and what do we need to do in order to help our organization through it. And of course, we also need to be firm on, you know, what deliverables and tools do we actually need to provide the organization to actually realize the benefits. So after this super important workshop where we get senior management aligned, there's a job to be done. And then usually, sometimes, sometimes after, still in the analysis phase, you will often come up with something like this. And again, there's a lot of details here. And so I'll spare you sort of a quick walkthrough. But what I will share with you is the purposes that the organization identified. And there was one purpose about being more effective. And then there was one purpose about providing better service to employees, that is companies. And then there was one purpose that focused on making it easier for a regular person to apply for a job through the job center. So, again, both efficiency purpose and stakeholder purpose. And every time we end up in this situation, we always need to ask, OK, there's usually a lot of benefits that we can chase. So what is most important in this project? And in this particular case, it was the effectiveness part. So what was most important for the management team here was that we optimized our ways of working and save some time. And that time would come from a reduced case handling time. It would be the job center employees that would change their ways of working. And they will also be the ones that were most important to provide with new competencies and new tools. And that doesn't mean that the other benefits are not important. But a key learning from a decade of doing these types of projects is that if we also need to look at the cost side and the scope side, then it's very important to be focused on what's really most important. So we don't chase all potential benefits because that will also most often make the project very expensive. And so what I would like to notice you here as the last element of this slide is that we have these numbers here. And these numbers are indicating that that is what we will be tracking going forward. And again, another key learning from a decade of projects is that we want to make the reporting part as simple as possible. And so this is an example of benefits realization plan overview. It's as simple as we can make it. It has a number here where you can see the end-bit benefits that we are measuring, the performance, the behavior that we are measuring, and the competencies. Then there's a short description. Then there is, of course, our short description of how do we measure it, who owns it in the organization, who is it usually a person in mid or senior management that will own the benefits, who is it in this particular case, what is the baseline, and what is the end target. And normally, especially in larger projects and programs, there will be an expansion of this part of the overview where you will monitor the benefits probably once a quarter. But this serves as a good example of what it is that you need to track and nothing more. So again, a key message here, the good learning says that we want to keep reporting as simple as possible. So this could be a good example of that. All right. That was our most important lessons from a decade of projects. And I can see that there is a few questions. And then there's a Stine who asks, how good are we to define quantifiable benefits? And I think that's a very good question. And I think in general, we're not very good at it. And if we are just going to stay a little bit back then, then if you saw the BESI workshop slide here, then that is a good example of a workshop output. And it's also a good example of where many organizations start, but also stop in their work with benefits realizations. So what we need to do is we need to remember that this is not enough. We need to do a firm analysis on the benefits. Most of it is actually possible to quantify. And so we should do it to the extent possible and to come up with a firm benefit map like this and things that we can actually measure as in this image and the next one. So I think it's probably one of the key things that we are not very good at and we need to improve to get out of those statistics that I started out with. Yes, and I'll just take one other question before we move along. Anita asks, is the balance scorecard and OKRs part of your framework? And the things can melt together because I think this is a framework that fits very easily into all the KPI and management frameworks. For example, both the balance scorecard and the OKRs. In terms of the OKRs, well, the essence of OKR and the benefit map is essentially the same. OKRs are also sort of a way to break down goals, but it's just much more generic. So what we do if you're using OKRs in the organization, we will do a translation. So we will map purpose and benefits and behaviors to objectives and key results. And so we can use this more elaborate way of breaking down and designing a project that is very suitable for projects. And we can map that up into OKRs that you will not only use for projects, but probably also as for the operational parts of the organization and so on. Thank you for the questions. I'll move on to the next part and then in the end we will take up some more questions. All right. And now we will take a sneak peek into the future. And what I would like to say is that there's one question that I have spent a lot of time wondering about. And that is, why is it that we are not actually putting more efforts into benefits realization to do something about those numbers? And I think had I had my good friend and former colleague, who is an expert in behavioral design, then Mase would probably have said something like, well, Rasmus, if you want more of certain behavior, it's a good idea to make it easier. And I think maybe that's a good angle to understand what the future could hold for benefits realization. Because I think if it's possible to make benefits realization easier, we might be able to push more of it out there in your organizations and create more value as a society. So how can we make benefits realization easier? And I think there's several things that can help us here. And I think another one of the learnings from doing really a lot of benefit realization projects is that they are much alike. They are pretty much the same. And what we have identified is that there are four benefit types that stand out. So either you want more revenue or at least avoid losing some or you want to reduce costs or improve effectiveness. That is actually sort of the most popular or most used benefit type that we see out there. It could also be that your company need to be compliant or buy to the law or as peer dive into. There's a multitude of stakeholder perspectives. So stakeholder satisfaction is almost always also a part of our projects. But basically, these are the four benefit types that all projects tap into. And they are also often very much the same. So you can find digitalization and process optimization projects, much like the example that I showed you before, that will tap into cost and effectiveness. And yes, the systems might be a little different, but in essence, they are much the same. People also often ask me, how did you get good at benefits realization? And I think sort of the very simple answer to that question is that I did a lot of projects. So I've seen a lot and much of them are actually much alike. So this holds a large opportunity for us to learn from previous projects. And actually, most of the advice that we give our organizations when we have a discussion about benefits realization is that, you know, the best way to get started is to get the best practice that I briefly went on before. And then once you sort of apply these new ways of working, then immediately after, start assembling all the benefit maps, the benefit realization plans. And if you're really good, note down how many benefits you actually realized, because that will help you a lot in future projects. So with that in mind, me and a group of colleagues decided to do a development project. And some of these colleagues are very skilled within benefits realization, and others are very skilled in AI. And now you need to brace yourself again, because what I will show you now is a very, very simple use case for our project. And what you see here to the left is a project manager or perhaps a product owner, if you are working in an agile framework or a benefit owner, higher up in the organization. And the idea here is that that person can type in his or hers high level ideas about what benefit types do I hope to achieve? What kind of project is it? Is it process optimization? Is it a SAP for HANA project? What is it? What technical deliverables do I think I have? Is it a SAP? Is it another system or a new module that I would like to use? What do I think the organizational impact could be? And if that person types that in, then there would be a response like, Hmm, okay, well, then, you know, elements of your benefit map could look like this. Benefits could, you know, you should have a closer look at these types of benefits, could that could be relevant. Maybe they're broken down like this. Maybe these groups in your organization will be impacted. Maybe ways to measure the benefits are those and those. And these are suggestions for how to track it. If you're really good and you don't have that much data on that yet. But if we actually have or get more data on actually realized benefits, then we will also be able to look at potential benefit realization benchmarks. We're able to do that for some types of projects, but not all. And actually also, very importantly, it sets out a clear image of what goods actually looks like. And we think that's super interesting. And it's, it's, it's kind of sort of the benefit catalog that we have perhaps recommended to some of you who are listening in today, where we just say, okay, please keep hold on to your benefit maps, benefit realization plans, and how you're measuring it. And maybe also the benefit you realize because that will help you in future projects. I think that the, the, the key use cases here for, for implement are twofold. We have one and that is our internal use. Well, we will help our own consultants get a better input from when they're doing projects with, for example, you. And then there's another perspective and that is sharing our knowledge base with you. And so what we're actually looking for is some organizations who would find this interesting, not only to tap into your own experience, but also the big pile of data that we are sitting on and implement to improve benefit management in your projects, make it easier and maybe also make it a little bit better. This could be a way to improve our ways of working with, with benefit management. So if you think that's a super interesting, then leave a message in the chat or write me an email and then we'll get back to you. We are hoping and implement not to fall in the startup trap and do something that nobody's really interested in. So interest from you would be super interesting. All right. This is at least what our image of the future looks like in implement. And I've been really looking forward to share that with you, I must admit. So I'm also looking forward to some responses on that. But like Peer, I would also like to finish my presentation of key takeaways. And it's actually a recap of what I just said. But one, if you haven't started using best practice benefits realization on your change and transformation, then the first good advice is to get started with that. And I know it wasn't a very long presentation that we did for you today. But there's a lot of videos and materials on our websites where you can get inspiration. And of course, you're also welcome to reach out. But that is really, you know, if you haven't started, then get started. And then the second advice is consider as soon as you start to gather the data that you have benefit maps, plans, all of that, because it is really a big help when designing future projects. And then finally, if you're already at number two, then you can consider going into the future. And actually, we think this would be both a help to make things easier, but also to sustain the efforts that you have already done in realizing benefits in your organization. Those were the three takeaways. And now I would like to invite you back on stage, Peer. Thank you. Because now we have time for questions. And I'll just pull the questions a bit closer so we can actually read it. And I'm going to cheat, Peer, because I actually have a question that I would like to ask you. So I'm going to bypass the list. Okay. Because I just talked a lot about, you know, that benefit management has not been sort of fully embraced by our organization. So what barriers do you see? And do you have any good advice to sort of get started? First of all, as you said, apply these best management or best practices, because you need to do something to emphasize the capability of doing benefits management in organizations. Then you also have to understand that this benefit management is something you should put much effort into. It's not just something you do as you do a technical project. Very often we are focused on doing the technical project, as you also showed in one of your slides about the technical tracks. And we forget all the time and effort. But you can say it could merely or it could nearly be wasted having the technical track if you don't put effort into the benefits track. And then you need to understand that benefits emerge over long time. It's long term success. It's not just something which happens suddenly. No. So if you want to focus on benefits, it's something you should do over the years. Yes. So you need to make sure in your operational part of your organization, there are a capability to harvest the benefit and to sustain the benefit to get even more benefits. So it's kind of thinking in an organization you have to work with. It's not enough to think of it in a single project. It's at a much higher level if you want to get this. Yeah. I think it's a key message that this is, you know, it actually requires some work if you want to realize the benefits. Yeah, it doesn't come by itself. It doesn't come by itself. No. And then, you know, my final question before we sort of open up for all the questions from the audience is that, you know, I also ended my presentation saying that we could probably benefit from the audience. We could probably benefit from looking at the past projects. And I was sort of curious, you know, is there any research on that? And what's your perspective on it? Yeah. First of all, there are research on that. And I think we talk a lot about uniqueness bias. By uniqueness bias, we say that people think that projects are unique. Yes. And I think it comes back to the old definition of project where you say that a project should create a unique product or services. But that's not true. Most of the projects we do are similar to other projects, which means that we can learn from one project to the other. So I think we need to abandon this uniqueness bias and understand that we can learn from projects. And there's a lot of research about that. And I also think that organizations become more and more aware of because we can see organizations which has a high project maturity. They learn from one project to the other. They learn from other organizations. So this learning process and learning capability is in itself important. And to skip this thinking about uniqueness bias. I think that's what research also tells us. Yeah. Very good. Catherine has a question. She says, my experience is that you need to involve hand on subject matter experts and not just senior leaders in this type of workshop. I think it's the benefit realization workshop she's referring to. Otherwise, you'll end up only mapping senior leader biases and miss out on real bottlenecks. What is your take on this? And if I should start then, then I think that it's the one group of people that we can't do without in that kind of workshop is the people who needs to own the benefits. And that is usually either middle or senior management. And we need them because our experience say that if we don't include them, that we might not be aligned on the purpose or the benefits. We might not have a common perspective of what is it that we need to do to help the organization change. And then there's a good chance that the project will fail. That doesn't mean that we shouldn't add, you know, more hands on competence in the room. That can very often be a good idea to sort of bring some knowledge on what is not actually working at the moment. I totally agree on that. But we need to find a combination and we can't do without the benefit owners, the senior managers. We tried it and it's really not a good idea. Yeah, my take is that you have to consider the stakeholders. And because users and people in an organization is also stakeholders. And if you don't involve them and understand what is key for them, what is value for them, then you miss something. I talk about win, win, win, win, win, win. And if we need to achieve that, we need to involve the right and all the stakeholders. That's the key message I think I have about this. Yeah, cool. And then Nikolaj has a question for you, Pierre. Yeah. And he says, I often experience that the broader change context, stakeholder views and the organizational environment are very entangled and non-linear. And the different elements that affect each other are very dynamic in short time spans. How do you recommend the lining, strategic direction and project execution in dynamic environments? That's a good question. That's what I would say. I think that's the reason why I say it's complex to satisfy all these stakeholders, this diverse stakeholder group. And there's no specific formulae you can just follow. But at least you can try to make sure that you do this strategic alignment, not just at the beginning, that that's something you do along the way. I think you need to understand the dynamic perspective of this. And then you need to make sure that the strategic alignment from the very beginning has involved sufficient stakeholder group. If you miss too many stakeholder group, then you run into trouble. But I won't say this is not an easy task. That's the reason why benefits management and benefits realization is so difficult, because very often you have conflicting goals here. You might have a strategic direction which does not align with what different stakeholder groups want. So it's not an easy task, but you need to communicate, you need to involve, you need to engage. That's at least words which are important. And that takes time and effort. Yes. And then we are back to that it's not enough to focus on the technical part of the project. No. But it is complex and I won't say there are any easy fix here. That's hard work. I think that should be the last comment to that question. Yeah. Good. I think we still have time for maybe one question. And that is Jonas, who should ideally own the value realization after the project is officially closed to ensure sustainability? Maybe that should also, do you have a perspective? No, I don't have a specific person. But I think two things. First of all, it should be people who are mostly affected by all this. Absolutely. So typically it is a business line, operational lines. It's organizations which have to operate all this that we have been implemented. But that's not enough. It's not enough to give them the responsibility. They need also to have the thinking that they should work with benefits sustainment as I talked about. And benefits sustainment means that they should work on how can we continuously ensure that we have the benefit out of what we have been doing. So there is a need for separate focus. And it might even mean that they have a project or projects running which only focus is to make sure you get benefits out of this. And as you have more projects coming with changes to that particular organization, catch it up, cluster it together in kind of benefit projects, in organizational benefit projects, in operational lines or business lines. And I'm afraid that was all that we had time for today. If you want to look at more material, then there's good stuff to be found on Piers website and ours. And I just want to say thank you so much for coming. And hopefully we'll see you again and you again some other time. Thank you very much, Piers. Yeah, thank you for inviting me and thank you for having a very nice discussion. And it's good, always good to discuss this topic. So thank you very much from my side as well. Thank you. Thank you.