LERNLUST #8 // User Adoption

Are IT implementation projects successful if they are implemented on time and within budget? That is certainly an important part of the success, but unfortunately they can still fail even after that – and that is because the new application is not used as it was actually intended, because the users cannot see the benefits for their own team, their own area and specifically for themselves, because the users are not really satisfied with the new application and because there is no satisfactory further learning, no exchange with other users , no further development of the solution and no really good help in the 'moment of need'.

So it is up to the users after all...

We strongly disagree with this, because it is the project's job to create an enabling framework that promotes success over the entire project and software lifecycle.

But how often did we trainers in qualification projects have the task of winning over future users for the new software, convincing them of the benefits of the solution and sometimes also defending the new solutions? All of this should actually take place much earlier as part of good change communication and good support.
And fortunately, that is often the case now, but what else can be done beforehand and how should it continue after the go-live to ensure that the software is a long-term and sustainable success and thus also supports the company's goals?

Comprehensive and good user adoption concepts start before implementation and do not stop after the software has been introduced.

Claudia Schütze discusses all this and why the user is not to blame with Johannes Starke, Product Manager for Learning at tts.

Shownotes

Host:
Claudia Schütze, Senior Learning Consultant & Trainerin // LinkedIn

Guest:
Johannes Starke, Product Manager Learning // LinkedIn

User Adoption Overview (de)
User Adoption Canvas (de)
tts - we empower people auf LinkedIn (de)

[Claudia Schütze]
Lernlust, the podcast for everything related to corporate learning.

[Susanne Dube]
We are Claudia Schütze and Susanne Dube and we are learning consultants at tts and we are the hosts of this podcast.

[Claudia Schütze]
And here we will exchange ideas about topics related to our work, in other words, everything that affects learning in organizations today and in the future.

[Susanne Dube]
And from time to time we will invite internal or external experts to join us. And we would be delighted if you were to join us.

[Claudia Schütze]
For a long time now, we have been implementing various types of software in an organizational context. In these implementation projects, it was gradually understood that software implementation also means change. And so more and more attention was paid to supporting future users and ensuring that there were really good learning opportunities.

Nevertheless, such implementation projects failed time and again, and in some cases they still do. That is why today, with concepts such as user adoption, efforts are being made to implement software in such a way that it not only sustainably increases the company's success, but also really supports users in their work, enabling them to accept the software very well. In my time as a consultant and trainer, however, I have often heard sentences that said, yes, it is only the users' fault.

If they had used the software correctly, the project would have been a success. Why we believe that this is not true and why concepts such as user adoption can contribute to the long-term and lasting success of a software implementation is the subject of my discussion with Johannes Starke, Product Manager Learning at tts and my esteemed colleague.

[Claudia Schütze]
Hello and welcome to a new episode of our LernLust podcast. I'm really happy to be sitting on our virtual coffee kitchen sofa with my esteemed colleague Johannes Starke again today.

Johannes, you're practically a regular guest on our podcast, and I'm very happy to have you here today.

[Johannes Starke]
I'm happy to be here too, of course. Thank you, dear Claudia, it's nice to be here again.

[Claudia Schütze]
I'm also glad you're here and maybe for one or the other. Johannes looks at the topic of product management from the perspective of learning and corporate learning at tts and, of course, he deals particularly intensively with all topics related to the digitality of learning. Johannes, it's great to have you here.

[Claudia Schütze]
I'm really very happy. Johannes, we have a topic today that I think is quite relevant at the moment, namely user adoption. You have brought a very bold thesis with you and I would like to ask you to briefly present it in context.

[Johannes Starke]
Actually, it's quite an old thesis and the topic is actually quite old, too. My thesis is that users are never to blame.

[Claudia Schütze]
Okay, that one is old, but maybe not in the way it is expressed. There is a need for us to look deeper into this and that's what we're going to do now.

[Claudia Schütze]
So, we said user adoption and you say that the user is never to blame. User adoption is a term that may not be so easy for German-speaking listeners to grasp.

[Claudia Schütze]
And that's why, Johannes, I'm asking: do we really want to adopt the user?

[Johannes Starke]
Yes, you've touched a sore spot with me. I've been trying to find a good German term, a more concrete term for adoption, for user adoption. I really haven't been able to do it.

If our listeners have any ideas, I would be very, very grateful. The term is actually used in a great many different contexts.

[Claudia Schütze]
Okay.

[Johannes Starke]
Well, no, but just to put your mind at rest, we don't adopt users.

[Claudia Schütze]
Okay, well, then I'll go against that and say, Johannes, I think to some extent we do adopt our users.

[Claudia Schütze]
Do you know why I think that? For me, adopting has something to do with caring, being there, providing opportunities for development, providing a framework. I actually associate all of that with the terminology of adoption, even if it's just a little bit.

And I think that if we can give that to our users in – and I think I'm unfortunately anticipating something here, but I'll say it anyway – IT implementation projects, we're already doing a lot for them, aren't we?

[Johannes Starke]
Isn't that a rather bleak picture when we have to take care of our poor users who are exposed to terrible software?

[Claudia Schütze]
Oh God, no, we don't want to paint that picture. So, Johannes, go ahead. What is user adoption really?

[Johannes Starke]
I don't think it's really about the users – I'd rather talk about users than about the use of the software itself. Well, of course it's about interaction. Users use software to do something specific.

And to release and permanently release the potential that is often still far too underutilized in this software application. That's what user adoption aims to achieve.

[Claudia Schütze]
Okay, I think that's a very, very nice point – and I think it's not only nice, but above all, it's also a very important point. And I mean, we've been implementing IT for many, many years, not just since yesterday. And now you've touched on a few things very briefly, and yet I'll just ask you again very directly.

[Claudia Schütze]
When is an IT implementation really successful?

And above all, as you just said, successful in the long term.

[Johannes Starke]
Well, first of all, it starts quite simply with the IT application supporting users in their daily work, enabling them to do something that they do for their work, in their work. Then the second step is that the users recognize, yes, that's useful for my work, that somehow has a meaning. I actually like this English term, this “What's in for me?”

[Claudia Schütze]
I think it has also become established. I mean, I think you can just leave it at that.

[Johannes Starke]
So, and that I then of course have the opportunity, when there are users who have recognized the “What's in for me” of the software for themselves, that they can then also use the software in the intended sense, in a sense that the business processes are supported.

[Susanne Dube]
Yes.

[Johannes Starke]
And only when all of this comes together, the fourth step, when the business processes run smoothly thanks to the support of the software that the users operate, only then is business value achieved.

[Claudia Schütze]
Absolutely, and I think that's the big point at the end.

[Johannes Starke]
Of course, that's what it's always about in the end.

[Claudia Schütze]
Yes, great, very nice. So, I think that sounds good the way you're presenting it. Very good, and above all, very understandable.

And now, of course, the question in the minds of our listeners is, yes, okay, what exactly can I do to make this happen as you have described it?

[Johannes Starke]
Where do I start? Well, it is very important to me that we consider the process to be a very long, holistic one that is considered until the software reaches the end of its life.

[Claudia Schütze]
Okay, a small aside, but I think it's a very important effect.

[Johannes Starke]
Absolutely, and above all, it's something that is often neglected.

[Johannes Starke]
But you asked me how we start. So maybe I won't start at the end after all, but at the beginning.

Well, it may sound banal and perhaps one or other of you is now saying, yes, of course we all already do that, that we first take a close look at the contexts in which the people who are supposed to use the software work. What are their individual views on the activity that is carried out with the software? And that's where scenarios come into play, for example, that need to be developed.

Maybe some of you are familiar with the term “user stories” from IT projects or software development. It's actually quite similar. Can we perhaps go into a bit more detail on this later?

[Claudia Schütze]
Yes, we'd be happy to, but please continue with your chain. I don't think we're at the end yet.

[Johannes Starke]
Exactly, we are looking at when my work with the software leads to success. What kind of success criteria play a role here? How do I recognize that I am successful?

How can I communicate success? That we learn on a small and large scale, of course. And very, very important, that we go beyond the step of the go-live, the roll-out, the introduction of the software.

I already mentioned it earlier, what do users need in the long run, after many, many years, until the software is eventually switched off. And perhaps I should also say, as I have already mentioned several times, that this is the point that, in my opinion, is often neglected. Software projects don't just fail at the beginning.

They often fail at the beginning, when the time or budget has not been met, functionalities are missing, the software has been poorly implemented, or the training has not been carried out properly. But often they also fail after a few months, when the hoped-for success does not materialize for various reasons, when the processes are not supported, when there are still competing systems, isolated solutions, and so on.

[Claudia Schütze]
And above all, the users have found an excellent way to somehow continue to live in the old world under the new conditions.

[Johannes Starke]
Absolutely, that's a point that often comes up.

[Claudia Schütze]
Right, Johannes, I think that's a very good description. I've been listening very carefully and I've heard that the entire lifecycle, especially after the software has been implemented, plays a role again and again. And I think we'll go into that in a little more depth in a moment, because I also think, as you do, that these are actually the crucial points for success in this user adoption.

But Johannes, so that our users might have a little idea of what we can expect. I think everyone will now have some IT implementation project that they have been affected by themselves. Maybe it was Teams, which was new, but maybe it was actually some module in SAP or SAP S4.

[Claudia Schütze]
Johannes, could you perhaps give us an easy-to-follow example that we could work on a bit?

[Johannes Starke]
Yes, exactly. Maybe a really, really simple example that many people might be familiar with. Time tracking in a time tracking system.

[Claudia Schütze]
Okay.

[Johannes Starke]
Now a service provider who provides billable hours, which he naturally wants to bill to the customer. The problem arises that employees record their hours very, very late, record them incorrectly, or perhaps not at all, so that hours are simply lost. Of course, this has a variety of negative effects on the business.

Invoices cannot be issued, money is simply lost, projects cannot be managed, and so on and so forth. So, and then you think in this service company, the old software, it's no good, we need a better time tracking system for that. Then a modern software is introduced, then there is good training and there are good performance support materials.

The software runs efficiently, maybe even on a cell phone. So everything should work now, when employees can even report their times on their cell phones on their way home.

[Claudia Schütze]
Yes, that's what you think.

[Johannes Starke]
Exactly.

[Claudia Schütze]
But what happens?

[Johannes Starke]
From experience, the times are still reported late, tend to be even later, and are still wrong. So somehow nothing has changed for the better. And the first impulse, of course, is to blame the employees.

They are too lazy, too stupid, they don't want to report the times, it's their fault. Yes, absolutely.

[Claudia Schütze]
But our thesis is that the user is never to blame. Yes. So, let's take a look, Johannes, at how we can achieve this in the long term.

[Johannes Starke]
I think you may have already gathered that two points that are very, very important to me are the consideration of the work context and what the employees really want and should do with the software, what their work context is. And for this we can formulate scenarios, scenarios, a kind of drilled-out user stories.

[Claudia Schütze]
Would you like to go into a little more detail on that, Johannes? Because I don't think everyone is familiar with it.

[Johannes Starke]
Yes, I'd be happy to. Maybe first of all the term scenarios, which I took from the Microsoft Service Adoption Framework, adoption, which was a great inspiration for this user adoption concept. So that focuses very, very much on Microsoft applications.

We then expanded and added to this significantly based on our project experience, and made it more general. But that's where the term scenario comes from. They follow a very simple grammar.

[Claudia Schütze]
Would you like to present it?

[Johannes Starke]
Four elements as a role in team XYZ. I want to do the following, so a description of the activity. I do that by performing the following steps in the IT application.

And now it gets particularly interesting, I think. I know that it was successful if the following success criteria have been met. I have achieved the following KPIs, so I can recognize my success.

[Claudia Schütze]
I find that exciting, Johannes, and I think it's new.

[Johannes Starke]
And that's the first starting point for promoting this “what's in for me” aspect. Gaining this insight really makes sense. I can really achieve something here.

Whether it's spontaneous, direct, or over a longer period of time.

[Claudia Schütze]
Absolutely, but it also offers me a starting point for both those responsible for the project and the users to reflect on themselves. What has to be in place for me to be able to say that I am using it successfully?

[Johannes Starke]
On the one hand that, exactly, and on the other hand, it really is a way to prove concretely that success is occurring. Thanks to modern technology, you can collect data and tap into data sources to see whether it really does have an effect, whether it's not just that people come, are inspired by their training sessions and think that the world is changing for the better, but that their work has a positive impact for provable reasons.

[Claudia Schütze]
Exactly, and that's exactly why we're doing all this. It's not an end in itself. Okay, we're doing it for another reason, Johannes, and I think that needs a second perspective for you now in the presentation.
You had already briefly touched on something like success criteria earlier.

[Johannes Starke]
Exactly, thanks for the reminder. Right, that's, yes, what's so important to me, I'd like to go into it in a bit more detail.

[Claudia Schütze]
I'd be happy to.

[Johannes Starke]
No, I'd like to push something up front because I'd like to note that I and I think you too, of course, to some extent, we're wearing our learning glasses, our qualification glasses. Of course, I only have a limited insight into what is going on in the IT project, what the techies are doing when they implement the software. That's why my glasses are of course relatively learning-oriented.

Nevertheless, I feel a great desire and need to take a broader view. This will perhaps become clear when I discuss the success criteria.

[Claudia Schütze]
Exactly, and I think that's what you actually want to pass on to the IT projects, is that right?

[Johannes Starke]
Absolutely, exactly.

[Claudia Schütze]
Okay, then let's share these success criteria, please.

[Johannes Starke]
Well, the basis for the software to be used at all is, in addition to technical availability, of course, that the qualification activities, change support and so on are working and that the employees are able and motivated to use this new software. That is the basis, of course. And unfortunately, I know that in many qualification projects, at least that's where they stop.

So if the training seems to have been successful in some way, then a check mark is put next to it and then it hardly goes any further. But now it's actually just getting really exciting. Now we're going one step further and looking at whether the employees who have now been empowered actually use the software afterwards.

[Claudia Schütze]
Okay, yes, exciting.

[Johannes Starke]
Because it's one thing to want to and theoretically be able to, but then perhaps being prevented by all kinds of different factors, whatever they may be, from actually using the software is the next step. And here, too, you can of course check whether the software is being used at all through usage logs and so on. Okay.

Also emphasized in the long term, because on the one hand it's great to see in training, but then really feeling the success in your day-to-day work is another thing altogether.

[Claudia Schütze]
Johannes, may I interject very briefly? I think that's a really essential point, because not every new software will immediately create a cry of joy for the end user. Maybe things are new, maybe they are different, but in any case, it also requires rethinking, adapting, learning, dealing with and perhaps also working together with other colleagues because the processes now look different.

So a lot is happening there. And I also recognize from my own experience in projects that you simply assume that this will somehow make the users happy. But I think that's often just not the reality, because it requires a change in the users.

And in this respect, asking how satisfied you are with what you have is, to be honest, a totally essential question, where I am a little surprised why this may not have been done so often in the past. And maybe I'll take this as a good impetus to make a good suggestion, which I think can be implemented and used relatively easily, and above all, the fruits of knowledge, so to speak, can be used later on.

[Johannes Starke]
And you just said that we are so willing to accept that it will somehow fall into place, that they will be satisfied. That's one extreme. The other extreme, which unfortunately I also hear very often, people don't like change per se and initially build up resistance.

I am convinced that this is not true. But people like meaningful changes. So this word symphony.
If I have recognized that a change is good for me and is intelligent in the system in which I operate, then I am convinced that users will go along with it. But success.

[Claudia Schütze]
And possibly also for my colleagues. That may also need to be added, because when we are talking about something like an IP system, it is often the case that the benefit of using this integrated software arises. And maybe that's not for me, but for the colleagues in the neighboring department.

And I think that's also a very important point.

[Johannes Starke]
Exactly, because you've already touched on the idea of teamwork and collaboration. That's when things really start to get exciting: if all users are now using this software to a high degree of satisfaction and with expertise, will it really support the business processes? And will it also support them in the way we had in mind?

[Claudia Schütze]
Absolutely. And that is the goal and purpose of the exercise. That's why we're doing all this.

We don't implement IT because it's so exciting to implement IT, but because, of course, we expect very specific benefits for the business.

[Johannes Starke]
Right, exactly. I mean, we think we know all the software that is used regularly, but for completely different purposes than originally intended. That's nice too, but it just makes strategic alignment difficult.

And in the end, the business value just has to be generalized through the use of the IT application. And that's the highest success criterion, where it actually comes down.

[Claudia Schütze]
Okay. Janis, let me just put this in context very briefly. We have been talking about the necessity of defining scenarios at the very beginning of this IT implementation project and formulating these success criteria.

And here I come back to your wording. There will be no standard recipe for how this can work, but there will always be individual characteristics and you just have to make the effort. And that is, and this is the framework I would like to provide, in the so-called before, before we implement.

Well, not so much now, just the two of us. We are more likely to be wearing these learning and change management glasses, but we are thinking about the people in the implementation projects. This is the topic that is best addressed there in order to make this user adoption a beloved practice.

So, and now I have put it so nicely in inverted commas. That is, of course, the phase that is perhaps the first thing that is actually at stake.

[Claudia Schütze]
And that is the phase of implementing a pilot, perhaps, but maybe already a rollout.

And Janis, this is not new. Software implementation projects have been around for an extremely long time in every conceivable form of software. And typical things that have always taken place in such projects were, of course, considering whether a pilot project could be used, whether multipliers could be won over, and if so, who the really valuable multipliers were that were really needed for the projects.

We have always talked about change communication as a support measure, and that is precisely what we need to design, create meaning for, offer and, of course, provide learning opportunities of all kinds in the context of this change support. None of this is really new, Johannes, but what does it mean now in this implementation phase?

[Johannes Starke]
Right, the nice thing is what you described in such detail before, that's the basic foundation we're building. So we can continue to use these scenarios and the success criteria in quotation marks in the overall context. So everything that comes now is used by the IT project, the training experts and corporate communications.

Everything is based on that. And what is really essential now, as I have already mentioned, is the idea that everything we are already building in the context of piloting, before, during and after the go-live, is intended for the entire software lifecycle, and that we, and I think I would like to go into a bit more technical detail now, that we are introducing not only the training courses but also a so-called Digital Adoption Platform.

[Claudia Schütze]
Johannes, stop. What is a digital adoption platform? I don't think that my listeners are already familiar with all this.

[Johannes Starke]
I also mentioned a term earlier that perhaps not everyone is familiar with: performance support.

[Claudia Schütze]
That's right. Would you like to explain both very quickly?

[Johannes Starke]
Very, very quickly, because I don't want to go into the technical specifics now. My colleagues from the software department can certainly talk about that much better than I could. A software platform that offers context-based support to users whenever they need it, for example when they have a problem, when something is new in the software and they don't know how to proceed.

And that could be, for example, short digital materials that show click paths, that show certain additional information that is needed at that moment, that show SAP transaction numbers, whatever. The main thing is that it is quickly available, it is context-based and always up to date. And that is, for example, one of many building blocks, of course, that can be used to ensure that all the help you need is available in your daily use of the software.

[Claudia Schütze]
And that means that this support, which you have just described very nicely, ends up in this so-called User Adoption Platform. Have I understood that correctly?

[Johannes Starke]
I think Gartner calls it a Digital Adoption Platform. I don't want to get hung up on terminology here. For example, we also have a solution for this, the tts Performance Suite.

That would be one example.

[Susanne Dube]
Okay, very nice.

[Johannes Starke]
Exactly. And the nice thing is, and we are now already moving directly into the daily use of this software, that in the past it was, or probably still often is, the case that when any problems arise in daily use, in daily application, then colleagues may turn to the key users. The key users help.

They then have to take the blame for whatever goes wrong. And I have often seen that the step back to the IT project, which may have already been dissolved, or of course to the product owner, does not work as smoothly as it could. I think we are now getting to the point where, because we have built up such structures and also because we have built up project structures, this interaction between the various parties involved works well, we are entering a phase where we can learn permanently from the use of the software.

[Johannes Starke]
Learning from the achievement of the success criteria and making the application of the software better and better and more and more valuable for the users. In other words, actually achieving a cycle of continuous improvement.

[Claudia Schütze]
That means, Johannes, now again, I'll try again to give this structure, a discussed visualization, because of course our listeners don't see this graphic, which we both know and probably have in front of our eyes when we talk about it. But it's a good time to point out that we will of course extend it in the show loads. And that means that now we are talking about the phase of productive use, so the one in quotation marks afterwards, the value-adding phase.

And we are of the opinion that what is really new now is that we are now looking at what the software delivers and how it can be further supported.

[Johannes Starke]
Absolutely, yes. And there are two points that I believe to be absolutely essential to achieving this permanent improvement. On the one hand, we have to develop certain rituals in which the various participants come together. I believe that in the Microsoft Service Adoption Framework, this is called the Service Health Review, where we simply look at whether the success criteria are being met, what our data sources say.

And perhaps this is also the point, because it is often the case that when I am involved in a qualification project, for example, I do not have access to the data that tells me whether the system is really running as intended. That's where different areas have to come together. It's one thing to introduce regular service health reviews, but to get the data, you have to tap into the sources.

And then, for example, this Digital Adoption Platform is a source of data that, if you have built analytics functions into it, can tell me, for example, which help materials, which performance support materials are accessed particularly often or which search terms are typed particularly often, where there is no help available. Exciting.

[Claudia Schütze]
You can actually analyze that?

[Johannes Starke]
Exactly.

[Claudia Schütze]
Cool, okay.

[Johannes Starke]
At least in the tts Performance Suite.

[Claudia Schütze]
Yes, great.

[Johannes Starke]
And that of course points out very specific problems to me. For example, the example I briefly mentioned earlier with the time reporting system. On the one hand, we have the option of looking directly into the system and seeing when times are reported back.

This shows me that the new input mask is obviously not adapted to the daily working conditions in such a way that the colleagues would simply be able to report their times directly. There must be some other reasons. Then, of course, we can also see which materials are accessed on the Digital Adoption Platform for this purpose.
And to report times, in the example given, you need so-called PSP numbers. And often, colleagues can't find these. And then they permanently access this list of the numbers they need on this digital adoption platform.
So, of course, you could consider the short-term solution of fixing this problem by providing the appropriate materials on the digital adoption platform to make it easier for me to find the numbers. In the medium term, we should perhaps adjust the software itself.

[Claudia Schütze]
That would have been my immediate thought, Johannes, because perhaps certain intelligent value helpers could simply be added to the system or programmed into it. I don't know how you would actually do it now to shift this exact search to the system. Yes, very nice.

Exciting. Very exciting. So, and of course there is also the point that we briefly touched on earlier, Johannes.
Now user satisfaction also comes into play again, by also investigating it at this point, in order to really get feedback.

[Johannes Starke]
Of course, this is a permanent point, of course.

[Claudia Schütze]
Okay. And now, as I listen to you, Johannes, I'll just think out loud what's going through my mind right now. You know, I come more from the SAP world.

Change requests after the go-live of a software or now specifically in SAP are not uncommon. This means that you collect error messages, you collect user requirements, of course, from feedback, and try to evaluate them according to necessity, sense, and budget, available budget, and then perhaps implement them with a business release or whatever. This already exists, but there is no longer an established organization for it, and perhaps there is no longer a standardized established budget either.

And if I establish that from the outset in my – it's no longer a project organization, but in the accompanying organizational structure, it should actually have a great deal of leverage as a standardized, whatever, a standardized process committee, whatever, to actually be able to live this role.

[Johannes Starke]
Yes, it's interesting that you bring that up. I think it is really an important change for many organizations to think more collectively. I can think of a project right now, a small consulting project that we currently have.

The customer is not planning to implement any specific software at the moment, but has recognized the underlying problem that we have had so far, that the individual responsibilities have always worked in parallel with each other, that an incredible amount of potential has simply been wasted. And that, the first step now is to consider that the areas of change support and learning, which have actually been working in parallel up to now, come together through this approach, but then, in perspective, of course, in future software projects, the IT project is added and communication is added. That it all grows together, which should have been together all along.

[Claudia Schütze]
I think it's a really nice approach and it shows that user adoption can actually look at things like that. And that maybe it's not about the big picture at all, but also about small, selective support. Thanks for mentioning the example, Johannes.

So, but that brings me to the thought that I just briefly touched on. Again, that I say, yes, that sounds very good, that sounds very valuable and it also sounds very value-creating, but it does indeed sound, Johannes, quite big.

[Claudia Schütze]
And now, of course, the thought is in my head: are all our customers doing this?

[Johannes Starke]
Yes, exactly, important point. Actually, you mentioned this process plan, which we also link to in the show notes. It seems overwhelming when we show it to customers, I have to take all that into account, I can't do it at all.

We also got feedback that the IT project goes to the barricades when they have to go through this long process. That's why we have a second document, a user adoption canvas. Maybe we can put that in the show notes again, which can simply initiate a conversation on a very small level within an hour, for example, about what would be possible if we take this user adoption process into account or often just think about it in our daily work.

Of course, not all IT projects are so large, so complicated, that we have to consciously take into account everything we have touched on today. Often, it just runs implicitly alongside, if we get used to working together, as banal as it sounds. We have developed a questionnaire that we can use together with our customers to check whether this software project could be particularly susceptible to a lack of user adoption, i.e. where it is particularly necessary to actively promote user adoption.

And in the questionnaire, we then ask questions such as, is it of particularly high strategic relevance, can resistance be expected, is a popular system being replaced, and so on and so forth. And then we can determine whether the approach would be particularly worthwhile.

[Claudia Schütze]
Okay, so that means that we also have the phase of assessment before that, and we can still provide help there with some supporting materials or events.

[Johannes Starke]
Exactly.

[Claudia Schütze]
Okay, now I understand that every project needs it, because it is neither so big nor so complex nor so complicated. But where we should never avoid it, Johannes, that would be my bottom line from what we have discussed.

We should always involve the user.

[Johannes Starke]
Absolutely, because the user is, of course, the basis.

[Claudia Schütze]
Johannes, it was a lot of fun. It gave me a lot of details on the topic of user adoption. And since I understand that you have already gained a lot of experience in projects on this topic, perhaps my final question would be for you.

[Claudia Schütze]
From your perspective, can you tell our listeners the three greatest achievements and successes that you have experienced in these user adoption projects so far or that you simply see in general?

[Johannes Starke]
Yes, I'll take the question as a kind of summary, because of course I've already mentioned it at one point or another. The central factor is joint responsibility for the success of a software, the close cooperation of all departments involved. That's the basis.

And also the use of synergies. I mentioned it with the shared scenarios. When the departments work together, user adoption increases.

Specifically, change and learning, which were previously separate, now belong together. That is my second learning at the moment. And the third is that IT applications create value over a very long period of time.
That they live through their users and that this life then also takes place in the middle of life and at the heart of life.

[Claudia Schütze]
Very nice. Such a beautiful prose presentation. I don't think anyone in our audience will forget that.

[Johannes Starke]
Great.

[Claudia Schütze]
Very nice. You should always work with linguistic images. I think that we have now definitely succeeded in doing so, at least with this third point of the summary.

[Claudia Schütze]
Johannes, I think we have presented a lot of details and we have shown a bit what is important, what is ideally included in such user adoption projects. What is perhaps actually new about this approach is that it requires a bit of a path, a bit of a path, how should I put it, a bit of a path to independence in setting up such projects and measures. But I think what we have succeeded in showing, or at least I hope that our listeners will be very happy to give us feedback on it.

[Claudia Schütze]
We were able to show that the user is never to blame and why they are never to blame.

[Johannes Starke]
Oh yes. Thank you very much for having me.

[Claudia Schütze]
Then I would say that it was very exciting for me. Thank you very much for being here and for sharing your thoughts on this topic, which is very close to your heart and, I think, very topical.

[Claudia Schütze]
And as always, we are of course very much looking forward to feedback and discussion and, as has been mentioned several times now, I think we also link to a lot of material in the show notes.

And if we could get one or two of them to think a little more deeply or perhaps even at all about these phases and value-generating actions in a user adoption approach. I think we would have achieved a great deal with this podcast. Johannes, thank you very much.

I enjoyed it very much.

[Johannes Starke]
Thank you very much, dear Claudia. I'd love to come back.

[Claudia Schütze]
Yes, you may.

[Claudia Schütze]
My regular guest in our Lernlust podcast. Johannes, all the best, see you next time. Ciao.

[Claudia Schütze]
And thank you to our listeners. Thanks for joining us. See you next time.
Oh yes, have you already subscribed to us? You can do that wherever you prefer to listen to your podcasts. Lernlust is released every three weeks and we really look forward to your feedback and, above all, to interacting with you.

You can write to us on Podigy or on Twitter or LinkedIn and please feel free to tell us what you particularly like about our podcast and where we could perhaps improve. And please feel free to give us a rating on Google Podcasts or any other portal of your choice. So, we'll see you at the next Lernlust.