zyka,善, hen, Dr. Schn City Good morning everyone and welcome to this webinar this morning. Learn from HalfDouble in real life, top-series experience in complex R&D projects. So today we're going to talk about HalfDouble. HalfDouble is a project methodology that first began to take its form back in 2014 when a group of visionary people got together and tried to solve the much discussed project problem that only 30% of projects are characterized as successful and create the intended impact. So they wanted to create a new project methodology that could solve this issue and they wanted it to be based on real human behavior and take into account unpredictability and complexity that are present in all projects. So that is where HalfDouble started. And today more than 1,200 people have been certified in HalfDouble and more than 250 companies use HalfDouble in their projects. Today we're zooming in on one of these companies, namely TopSø. And my name is Rosa Evers. I'm a consultant here in Implement Consulting Group. I work with HalfDouble in my projects, in my everyday work here in Implement. And I will be your host this morning and guide you through the next 55 minutes. So I hope you are excited about that as much as excited as I am. So I hope you are excited about that in the next 5 minutes. So I hope you will be your host, in my life, and in my life. So please write your questions in the chat during the webinar. And then we'll have a Q&A by the end. I would also like to mention that when you signed up for this webinar, you actually attended a little competition, a competition about winning this half-double book. And in the end of this webinar, we will draw the winner. So stay tuned until the end to see who is the lucky winner of this half-double book. Great. So let's see who we're going to meet today in our studio. So today with me here, I'm going to have two great people who will attend this interview that we're going to do today. We're going to meet Henrik Guldberg-Petersen, who is the vice president in Topsoy Research and Development. Henrik has been driving Topsoy's journey with half-double since they started and is here to tell us much more about both Topsoy and also, of course, their journey with the half-double project methodology. We're also going to meet my good colleague, Michael Ehlers, who is one of the founding fathers of half-double and has a lot of experience with applying half-double in projects and in various companies and also training both project managers and executives in the half-double project methodology. So I think it's safe to say that he is an expert in half-double. So before we get started, I would like to get to know you at home just a little better as well. So please get to the chat and write in the chat, where are you joining us from this morning? So while you are writing in the chat, I can let you know that I am here in Hallow, in our implement offices in Copenhagen. It's a... Oh, we are getting to some answers in. It's a little far away. I think it would be super fun to see if we have someone joining us from outside of the borders of Denmark. I see Copenhagen. Belgium, Norway, Stockholm. I see Belgium, Norway, Stockholm. There's... Okay, we have a great distribution of participants here with us. Thank you so much for sharing that with us. That's really nice to see that we have so many great people here. Okay. And... And... I would also like to just get a feeling of how familiar you are with half-double project methodology. So please answer the poll from a scale from 1 to 5. How familiar are you with project methodology half-double? And you could say that 1 equals that you have never heard about it before, but are super excited to learn more. And... And... And 5 means that you are... Maybe you even have a certification in half-double and you know about it. Maybe you even use it in your own projects. And... I think it's important to say that to join this webinar and to follow along, you don't have to be an expert in half-double. But it would be really nice to see how familiar you are with the project methodology yourself. Go to the poll. Go to the poll. Answer the question. Thank you so much. Oh, I can see it now. Thank you so much. Let's see. So we have... A lot of people who are answering 1 and 2. We also have... About 70%. About 17% answering 3. So I think we have a great distribution of knowledge. Some people who are super excited to learn more about half-double and who haven't heard so much about it before. And also... A few that have scored themselves 5 and 4. That's really great to see as well. I hope you are excited to get some new perspectives and insights to the project methodology. And... On that note... I think we should just... I would like to show you a quick video... Which will get us all on the same page and kind of set the scene for our dialogue with Michael and Henrik in a minute. The video will show you... Why we use half-double in our projects and just a recap what half-double is all about. So enjoy the video. Lean back. Thank you. Thank you. Thank you. So welcome back from the video and welcome to you, Henrik and Michael in the studio. Thank you. So I just briefly introduced both of you. But I think you should get the chance to introduce yourself as well and what your role has been in this Top Series half-double journey. So I think we should start with you, Henrik. Thank you. I appreciate that. So my name is Henrik Guldberg-Petersen. I've been working with Top Series for many years. 25 years now. In the different roles. And my current role has been for some years. And also all the way through this journey is heading our main part of our product development in Top Series R&D. And my role in that has been, I would say, as you mentioned, Michael is one of the founding fathers of half-double as such. I think I think I was one of the founding fathers of our initiative in Top Series. And I've been, I see my role as being a chief whip in R&D management, keeping a little pace, insisting not driving so much because we have other people doing that, but more supporting and creating engagement around it. And then I would say, there are two pictures there in the slide that you'll hopefully see. I like mountain biking. I like mountain biking. And I like football. And in particular one team, in Liverpool, you never walk alone or work alone is also something we normally say. And I think both of these sports interests are also related to flow, leadership and impact, definitely. And you see, when you ride a mountain bike, if you try that, you'll see immediate impact. If you don't know your role on that, for example. So there are a lot of things that you can also take these principles into your daily life. Thank you so much. What about you, Michael? Yeah, so I've been with half-double since 2014. In 2014, we started some of the first initial ideas as you introduced briefly here. And back in 2020, that was actually when I met Henrik the first time. I joined Henrik and his leadership team on a R&D leadership seminar, and I introduced the half-double methodology. And then, you know, the process started, and you just had to kind of think a bit about it. And then we started for real in January 2021. And we're still collaborating quite a bit on this. Nice. Thank you so much. And also, before we get into talking about half-double, I think we should hear a little bit about, so what was the initial situation Top Series R&D department was in before you started working with half-double? What was it that made you look for a new project methodology? It's a very, looking back, and because it's some years ago still, I would say, first of all, all our work in R&D is essentialist, is around our projects. And each of these projects is millions of Danish kroner a year. So it's a lot of money we put into the projects. So that is one thing. We had had some project managers that had some formal training in kind of waterfall methods. A lot of autonomy in how you want to run the projects. Actually, so much autonomy that we didn't really have many requirements to project managers. We had a structure around estate scale model you can see here on the slide. So I would say our focus was, and we're still working on that, but our focus was definitely on deliverables and product specifications and meeting those, and not so much on creating the business. Then we also saw in several cases, actually, that we actually spent many years on developing stuff, and they were just sitting there on a shelf, not being sold to anybody, not creating any value at all. Sometimes we saw that projects took a long time to realize for many reasons, probably we didn't really know. And then also, as part of a review process, we had BCG looking at how we were doing in R&D. And it wasn't really a red light, but they said there's room for improvement here. So I would say that we had interest, we had a wish to do something, but no real burning platform. We're doing okay. Not fantastic, but okay. That was our situation, I think. So what do you think? You saw us there three, four years ago? Yeah, yeah. And the first thing I noticed when I met you, Henrik, was first of all, a very strong expertise culture. I mean, most of your employees are PhD graduates. So you will not find brighter people working within your area anywhere else. So expertise really seems also to conquer over leadership somehow and seems to be kind of the exclusive factor that just kind of radiates everywhere. And it's super cool. However, it also kind of overshines the leadership part of it. That was one thing that I saw. And then the second thing that I also noticed was, as you said, the autonomy. You could just choose however you would like to do your projects, which is really great somehow, because it's up to the individual and you can really kind of flourish in that. On the other side, it also created quite some less nice projects. I think we could call it that. Let's call it even once in a while, it didn't go exactly as planned. And trying to avoid that kind of wriggly course in terms of quality, I think, was one thing that you really wanted to put on the agenda. Thank you so much. And would you also like to talk a little bit more into what actually characterized the projects that you do in Topsy research and development? Yeah, to do that, maybe we want to see how our main business operating model in Topsy is. We are a technology company working on creating CO2, reducing technologies for our customers through the world. And we have, you see, we supply different things in our current model. We supply process licensing, so we develop processes and sell the license to use that process. We sell catalysts, we sell catalysts, we sell catalysts for that. We have some proprietary special hardware. And then we also have some services around support, support on the digital tools, you know, different service models on that. And it's kind of, this is within the chemical technology space, but I think most people are familiar with Nespresso. So if you can look at Nespresso, so if you can look at Nespresso, then the, so we make blueprints for the coffee machines. We don't build coffee machines, but we see this is how you can make a coffee machine. Then we sell tickets to use that, those drawings. And then we sell the capsules, high quality capsules, I should say. And then there's some, maybe there's a core technology hardware to make a coffee machine. And that could be this brew thing to make, otherwise you'll not be able to make coffee. You can make everything else. But this particular piece is our proprietary knowledge, maybe have the patents for it. And then we also provide different services around, around those things. You maybe have supply agreements. So we will be able to supply fast services or different matters related to that. So I would say that our development projects are within the three first parts, within the hardware, within the catalyst and within the, you can say the process design. Not so much on the business model, you know, the business support, supporting tools. So, and I would say we use a half double for all types of those projects. And I would say also, if we look into the future, we, we, that is something that we are talking about because that's also an innovation, business creation for the companies. There will be future business models. There will not be, this is kind of a paper coffee instead of paying for the machine and the capsules. That's another business model. So we would also need to put in some innovation into that. And we're still, you know, how can we use, you know, innovation project management within that? That type of innovation. We've not gotten there yet. So Michael, I would also just like to ask you, we know that half double can be used for a variety of projects, but these projects, types of projects that Henrik is talking about, are those good for half double? They certainly are. And I think that's, that's why we're collaborating on this because you would characterize half double as a hybrid methodology, meaning that it takes kind of the best things from the traditional project management and the waterfall approach where we try to foresee things happening. And it also takes some of the great things from agile with lots of iterations where we, every time we gain new knowledge, we kind of iterate using that. So we have a quite steep learning curve when, when we work like that. So taking those two things together into a hybrid method is really what we figured out would, would suit a top three R&D projects pretty well because they are challenged by a lot of uncertainty and need for innovation, but also a need for speed sometimes. And that's, so figuring out how you would actually kind of, you know, if this was a slider and you could go towards more, do we want to prove the business model or another slider going towards, do we want to increase speed and accelerate the project? Then you can kind of do one of those things or you can try to do both at the same time. However, we figured out that in these kinds of projects and for these type of uncertainty projects, the half double methodology with all its adaptability turns out to be really great. Perfect. Thank you so much. Perfect. Thank you so much. And so now we know just a little bit more about Topso as a company and what the initial situation was before you started working with, with the half double project methodology. And so let's move into when you first started actually working with this new project methodology. What was it that first convinced you that that was the right way to go? I'm not quite sure. I'm not quite sure, but I know that we were, sometimes it's, it's, there's some coincidence related to, to, to decisions, but I would say that we've been looking at agile, considering scrum. We had talked to some, some that might be able to help us on that because we could see that this very traditional linear approach we had would not work because in some case we need to speed up. Then I heard about the half double Institute from one of my colleagues. Uh, uh, and, and also participated in one. It was, uh, I don't know, I forgot the title, but I was at a kind of a pop-up workshop here at implement, uh, developing business, not products. I said, Hmm, that is what we need to do. So I think we reached out to you and, and got in touch. And then I think what we liked about it, uh, and still I appreciate about it is, is that methodology. It's flexible. You can adapt it to the needs, uh, which I think is suited us, our culture, uh, well, uh, combining with the expert culture, but also on the business creation, I think is what we talked a lot about at that time. And also the speed. Uh, and then I think, uh, uh, uh, uh, Michael suggested the pilot approach. And I, we like that. We like to experiment, which is what you do when you have a pilot, but it's also something about, uh, clicking with people. And I think we have a good relationship. We, we understand and know each other. And I think we work well together. So I, that, uh, that had an impact as well. Hmm. So you, you just mentioned pilots, but, um, could you describe a little more about what is your, your journey then been with have double since you started back in a 2020, 2021? Yes. As, as Michael said, uh, maybe I'll say we, we, uh, actually started, uh, had a tough start, I would say, because it was COVID. Everybody remembers that. I maybe we forgot about it, but when talking about it, so we had this presentation for a lot of managers. Then we had COVID and a new CEO at the same time, a new strategy in the company. So it kind of, whoa. And then something else happened, but we took it up again. Uh, and, and then in, uh, in 21, we really, uh, took off with, with selecting projects that was, uh, we have to win these projects. Uh, it's, uh, the most important projects we had at that time, at least, uh, uh, maybe not all of the most important, but some of them at least, uh, so we selected those, uh, there is, uh, particular one, uh, area, the power to X area, huge investment, uh, a lot of, uh, unknowns and then we didn't have the time to, to work in, in, in, in, in a linear approach, uh, simply. So there's kind of a, a burning platform there, uh, I would say. So what has then been, um, if you look back on all, uh, the journey you've had with half, double and topsy, what has been the biggest impact that you have gained in, uh, in topsy by changing to this project methodology? Hmm. You could say that it's, uh, it's been, uh, hard for us because we had that talk as well. So have you seen the projects go faster? I think so, but it's, uh, all projects are different. So, and so, and we've never done them before. That's what research is about. So it's difficult to say how much faster does it go? Some of them take more years than, than we have had. Uh, but what I see is definitely the changed, uh, behavior, which is what I wanted most. As you said, project managers, specialists taking responsibility for engaging with people, uh, leading them actually, not just giving them, you know, instructions, for example. That's one thing on, on the people side. I see that, uh, colleagues talk about impact, uh, instead of, uh, product specs and that do it, uh, across the, the board, both from our business side and, uh, and also in, uh, from the technical side. Uh, and then I've seen, um, actually one of the pilot projects we had, I said, half double, double impact, half the time to get going. And they were the first, after, after one month, they were delayed. I said, what's going on here? But actually they kept working on the impact. We want to know what impact we do before we start working. And our, our traditional approach would have been, let's go ahead, do experiments, whatever we do. Then we figure out where that leads. Now to understand first, what is it we want to accomplish? I think that's a, I said, yes, we got it. I was, I had, you know, you, you, you know, I was expecting, uh, you know, pace and, and, and, and that was, uh, so, so that's, uh, that's at least one, one particular example. And I think we, we could add to that, that, that it also created quite some frustration, right? So, so for the project leader and, and for the team as well, they were also, you know, thinking, well, what is going on here? I mean, we, we, we, usually we are so, you know, when it's only the specs it's all about, then we just, start executing, but we started having discussions with the business side about, you know, where do we want to end up? And it turned out that the obvious solution wasn't the obvious one. Yeah. And so we kind of changed direction from that. And, and that discussion, figuring out where to land it differently, that just took a bit more time than, than expected. Kind of. I've seen that we have these sprint periods, uh, I'll call them learning loops that the, we saw people stop in the middle of a learning loop. We've never done that before. Uh, so they'll stop. Well, it doesn't help us now. We'll, we'll, we know, we know something else now. We just stop saying, Rosa, we don't need you for the next two weeks, uh, because we need to figure out what the next step is. We normally would just keep going and then, yeah, we'd have some more data, but didn't really use it for that. So I think that behavior change definitely, uh, definitely is, is, is visible. Also with, with a technically strong people that step up and show that they are actually good, the project leaders. Mm-hmm. And that leads me to my next question, actually, because, uh, that have double is much about, uh, so going from project managing to project leading, like you're saying, and having this, uh, this leadership focus and people focus in your projects. But how did you manage to, uh, to, to build these capabilities amongst your project managers to become this project leader, to empower project leadership? I think, uh, I think, uh, probably the, uh, probably the most important thing is that to express that this is what we expect from you, uh, clearly that it's, uh, uh, it's about, uh, leadership, but also make sure that people are trained in, in, in, uh, given them a fair chance of succeeding. Then you need to express your expectations and then also, uh, also give, uh, give that, uh, training to them. And then we found this project management forum or leadership community in other terms, which also see it as a profession or a skill to be a project leader. Yeah, I think that those were probably the most important things to sort of establish that baseline. Yeah, I was just thinking of a thing that happened in that leadership dialogue, because one thing that came out very specifically in the leadership dialogues was the dialogue that we need to have with the business side. And we kind of came from a place where, you know, business stated their kind of specs, and then you didn't talk to them for maybe a year or sometimes, or at least half a year. Yeah, we had an interesting example. We had one particular development project some years ago that we used as kind of, this is what we don't want. There was a target set of a 15% improvement. And the team has been working for maybe after one year, something like that. They had a 12% improvement. We said, now the target is 15%. So we need to get going. So they worked three more years. And eventually they had a talk with our business. We said, we said, we don't know how to get to 15% improvement. We have 12%. 12%. That's great. Okay. To spend several people's time in three years of instead of just going out and getting that stuff. So now we thought these guys, we have a role called project line directors. They are extremely busy people. They're kind of the spider in the spider web connecting all pieces or functions on their part of the business. And we thought they would not, they wouldn't have time for that. But they show up to these meetings because they get direct impact and they feel that they can impact what we do. Now we're kind of down to every second week. Yes. I mean, we're having dialogue with the business side, which is, which turns out to be actually valuable because things change all the time. And you have this saying, Henrik, which I like a lot, saying, we're working on a project. And within a month, if we do not gain new insight into a project and there's nothing new to talk about, then that would be equivalent to having no progression. And is that the case? Which it rarely is. I've never heard anybody say that. No, exactly. So bringing that forward, having that dialogue at least once a month is kind of what we've tried to introduce. Yes. Yes. So now you mentioned one thing you've introduced in all of your projects kind of across. But I think we also have the six principles or the non-negotiables in your projects. Yes. These are minimum requirements. I think the methodology has a number of tools, nine tools. And we selected those to six. And they may change over time, but those are those we selected. And they were actually suggested initially from the project leadership community. And then it was debated also amongst the leaders in R&D and saying, yes, we agree. These are the minimum requirements we want to have in all our projects. And I think the balance that we wanted to strike with this was to create somehow a standard, but not making it into a, what you would call kind of a huge quality regime. So striking that balance between making it a bit intuitive, because the things that we are claiming should be kind of the best practices are not that tough. But at least that's the six things that we would like to enforce in all of our projects. Just one thing being, just one thing being, we would like to have a meeting with the business side every second week or at least every month. So it's not kind of a big thing, but it's really creating a behavioral change. One of the tools is to have a project organization. And you say, well, that's obvious. But I would say the way to projects and successful project managers who are not exactly sure who can make a decision around the projects to make them progress. They'll figure it out somehow, but not in a very efficient manner, I would say, traditionally. But at least we try to make that clearer now. Who makes the decisions. Who makes the decisions, who are stakeholders, who is the steering group, who is the sponsor eventually, you know, in the end, who can close the project, open the project. And I think that made it clear, okay, this is the frame I need to work within together with my team. It's a simple thing. It sounds simple. It sounds so obvious. But it's a foundation for making the collaboration work as great as possible. And make it clear who has which role. And how has that changed, that change then worked out? Does all the projects now use these six tools? Yeah, yeah. Say yes, Henry. Yes, yes. No, I think we need to be honest there with ourselves. It is a journey. And we are not at the end of the journey. I don't think we ever will be. I think we'll still find ways to improve. I hope we will not be complacent there. But we did a survey this summer on our projects. And these are the six best practices. And red is, well, we are thinking, we don't really know. Yellow is, yeah, it's okay. And green is, yes, this is working well. And it's the self-assessments from the project managers. So I think they're quite honest here. And we discussed, are there certain tools that we need to change somehow to make it easier or simpler? Can we help something? Because maybe we have, to some extent, at least left the project managers figuring out themselves how to actually implement those tools. So I think we have a follow-up to do. That's one thing. And also, we realized it was at a manager meeting we had. We talked about this. So also, it's about us as leaders insisting that, because we need to change the behavior. It's a cultural change in our company. And if I would continue asking only for technical updates or, you know, what is the, when will reach this milestone, that is what people would do. So I need to also insist, so how does your impact case look? What is your sprint plan? We also need to insist a little bit on the tools, because I'm convinced that the tools eventually will create the culture we want. And we're not there yet. I think they're honest about it. So, yeah, so HalfDouble has these tools, and you've chosen six that are working for you in all projects. But I'm wondering, have you seen that different types of projects require different tools? Are there any differences there? I would more say that some of the projects are small, some are big. I would say that some tools are probably more important in the early stages where things are, you know, we know, work on things we don't even know if it's possible. So that, that, that, that, then it's a huge uncertainty. You need to learn fast and close the project if, if that is needed. So that's one focus. Whereas in other parts, it's more execution. You know the way you've done it several times before. So it's more like tuning the details. That's another way of leading the project. So I think the tools, and I think the methodology actually supports both ranges of, you know, uncertainty or clarity or certainty, you can say. So it's more, you know, trimming the knobs depending on where you are in the project. Makes sense. And to add to that, I would say that we've tried to install an awareness with the project leader about, you know, which methods to enhance more and which to do less of, depending on the phase that the project is in. So, so we're really not kind of saying that, that the tools are, how can you say, inefficient or you shouldn't use them. We're just saying, you know, put, put more effort into, for instance, the impact case in the start, which is totally obvious where most projects will struggle. With, you know, why are we doing this? What's the business impact that we're trying to create here? So, and then later on, you would have more focus, for instance, on the sprint plan. So we're not saying that it's inefficient to do that to start with. However, it's not evident that you do that. You start with the impact case, right? So installing that awareness about what your project needs. And I think that people actually, because we're in an expertise culture, really good at, at, at, at the, you know, pointing out to which, which way should we actually go to start with. So, so one question I was also wondering is that, so you had this stage gate model to begin with before you started working with half double. And a lot of companies have that. So how did you manage to, to merge the two to either adapt half double or to, to use it to in unity, you could say? I'd say it's, for us, it's still a work in progress. We need to, to, you know, make that merger of the two. It's, they're not contradicting, I would say, but, but the way our forms are now, we have some templates we need to fill out. It's kind of leading us towards the old, you know, specifications just last week. Or maybe, yeah, the week before we had a meeting on a project we need, we want to initiate and want to use the methodology. And we, we initially, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, has been, has been, has been, how do we deal with projects that are running? Projects with 15, 20 people working and so why? It's going okay. So how, why do we need to change so much? Because we're almost there, so to speak. So how, how to do that? I don't know if we figure that out exactly yet, but at least all the, probably has been, been trained and, And some of the tools are implemented, as you could also see in this overview. So that's one thing. The other thing is that for small projects, most of our projects start small, and then we work on it and see, and then we'll grow with more people, more complexity. So do we want to use the whole tool, the full Monty, for a project with two people? So we have not really found exactly, we will. We insisted that we do that. We talked about it, we know we make a light version to start up, which would be the three most important tools for starters. Those things, I think, is the two ends of projects. For a large project that start now, I wouldn't say there's any problems. It's not difficult. It's obvious, I would say, for us, at least. Great to hear that. So you might have just answered it right now, but you've come a great way with HaveDouble so far. But what are the next steps for you in terms of working with HaveDouble? One thing is, as I mentioned, the merger or alignment with our other procedures, processes we have in the company. And then I also think we need to institutionalize it even more than we have. You can see the survey said that we need some more follow-up and insisting on the tools. And I think there could be probably some, maybe later on, some adjustments to it. I think one thing, some part of the organization talked about, they needed a risk tool to be part of it. And the great thing about, I think, HaveDouble is it's not exclusive. It's not a religious approach. It's a principle-based approach, as I see it. And it's flexible. You can adapt locally. You can look in different ways. This is how you can look. So you can add that easily. But I think it makes sense for us, at least, to add it into our, you know, the principles that we insist in. It's part of the minimum requirements, as you also actually evaluate technical risk or commercial risk you have in the project. So that would be some of the things, at least. Sounds like a good way ahead you have. Thank you. And I think it's time to get our audience involved as well, because now we will have time for our Q&A. So please, please get to the chat and write your questions for Henrik. And then we'll have a little time for a few questions. So before we wait for a few questions to get in, I would like to just ask you, Michael. So now we've talked about Topsy and their situation and working with HaveDouble. But when you've worked with other R&D companies and specifically applying HaveDouble, what has been the hot topics? What are the themes that are important for research? development companies? I think that that's a brilliant question in terms of the fact that I do see some similarities between R&D organizations that are not that evident with other types of organizations. But with R&D organizations, the primary discussion we're having to start with is how can our project model or this way of working, how can that include all of the expertise that is so important for us? And usually that expertise would be articulated into specific ways of working, specific tools, specific measurements and kind of more technical details. So how do we then adapt those technical details into a leadership approach that is also people driven, right? So kind of taking that twist from having the answer in the technical details to a people driven approach where you would have multiple perspectives on the same thing is really usually the issue that we debate. because the tendency in R&D organizations would be, of course, we have specialized within this area for years and now you're coming and telling us that we should talk with other people to get more challenged. That's really not the issue. We have the answer ourselves. So I think it's striking that balance because there is a truth to that. They do have a lot of the answers. However, not all the answers for how that would be business efficient, which is really the link that we're trying to create because sometimes it can kind of, you know, spiral down to a deep expertise, you know, journey, which is also cool, but not always that business efficient. So have striking that balance. I think that that is one of the main dialogues and one of the main themes that we always kind of start out with and that we also have constantly along the way. It kind of never leaves us to some extent. Having said that, though, the great thing about R&D organizations is that you would have some of the most bright people to work with. So I think that's really important. So they would, of course, sooner or later also, you know, get to the point where it actually works. I like this. And they're pretty adaptable, actually. So working with, you know, high quality people is just a pleasure. Thank you. And it sounds like you're nodding. Yeah, yeah. I would say that if you know athletics, you know the relay race and the person, the following person is already running when you get to them. And when you are successful, at least. And then you hand over a successful. So I think that running together is important. The business is already running. So these guys are coming with the stuff and we can always start selling and, you know, making instead of waiting as we would have normally done. So I think that is where it actually fits well into a development innovation framework. So we actually got some questions from our audience. Let's see here. So we have a question here, which is, how did the employees react to the change? And how did you approach that challenge? Maybe specifically the project managers? Yeah, but I also comment that we had some, in our projects, we work a lot in labs and we have some lab technicians. And it used to be very different, very different from project leader to project leader, how they would engage with those. Some of them actually never met somebody from our business. They never saw anybody. So just working in the lab, making stuff. And now they see, we heard a lot of people saying, now we actually understand why my work is important. It actually, somebody is interested in that outside our normal, you know, working sphere. So that, those project demos or whatever the term is, is hugely important. Yeah, so I think that people engagement has increased the engagement. People engagement is across, I would say. And one thing I could add to that is, is one thing would, of course, be employees being involved in projects and project teams. However, from the leadership side, meaning the whole R&D leadership team, that also took quite some change efforts to kind of get everyone on board. And the reason for that is, is that, first of all, you're 50 people in something like 50 people in the extended kind of team. So it's a lot of people to get on board on the same way of working. So we had to use a bit of dialogue to get to a point where everyone actually figured that that was a good idea, which is totally normal. Yeah, yeah. So it's a combination of insisting and also helping, I would say. Yeah. Thank you so much. Insisting and helping, yeah. And that was actually all the questions we had time for, because I have one last question for you, Henrik, which is, so if you were to take away two key learnings from your journey with Have Double, in TopSoup Research and Development, what would that be? I would say definitely go with pilots and then find those that are most engaged in learning. I mean, the first adapters or whatever the term is, somebody who can be front runners, have them go with a pilot, see how it works, and eventually the rest of the organization say, I want to have that too. So I think that is a way to make that change. Just a short side note. Those early adopters are champions today and helping their colleagues to inspire them on how to do it on their own projects. So it can really turn into a thing on its own for those early pioneers. Thank you so much. And thank you all for writing your questions in the chat. And thank you for engaging and being here today. Thank you, Michael and Henrik for joining us this morning. It has been really insightful and learning for a little session we had, I think, at least. So now up for the thing we've all been waiting for, our little competition with this Have Double book. So we have drawn a winner from the sign-up list from today's webinar. And I have the winner right here. So let's see who is the winner. The winner is Kristina Jakobsen. So congratulations on winning this Have Double book. And we will reach out to you shortly. And then we'll make sure that it will get shipped your way. Congratulations on that. And for the very last thing I have here today. My slide won't change. It's here. So I hope this talk inspired you all to reflect on how Have Double project methodology might fit into your organization. And if you would like to discuss how Have Double might benefit your company, your projects, your organizations, then please do not hesitate to reach out. We are always ready for and willing to have a complimentary conversation with you about that. And you can see our contact information here on the screen. And you'll also get our contact information sent to you in the follow-up email, which you'll get in a short while, which will also include the video from today's webinar. So thank you so much for joining here today. And I hope you all have a great Tuesday. Bye.