Mastering the Art of Adopting R and Python: Innovative Strategies for Effective Change Management

Hello, hi everybody, my name is Mark Bennens, I'm heading the Scientific Computing Operations at Johnson & Johnson, and I'm also a change leader for adopting R, our open source within our company, especially for clinical trials.

So if you're here today for a change management one-on-one, you're in the right place. If you're here today for how to win the lottery, good, it's the same thing.

First a disclaimer, these are my opinions, it's your responsibility what you do with it, and I'm not endorsing any specific products or services.

The five stages of grief applied to change

What you see on this slide are the five stages of grief, introduced by psychiatrist Elizabeth Kubler-Ross in her book on Death and Dying, and these stages represent the emotional journey that individuals experience when faced with a life-changing or tragic event.

Now at J&J, we've been using SAS, statistical analysis software, as you know, for many, many years. Not that that is a tragic event, but imagine telling a room full of seasoned statistical programmers and statisticians who always relied on SAS, that they have to basically switch from their beloved SAS to R or Python open source, what would be their response? Well, surprise, surprise, they actually go to those five stages.

First of all, denial. This cannot be true. SAS is so established and reliable. Anger, this is a waste of my time and resources. I'm so proficient in SAS and now I have to start over with all these new tools. Bargaining, can we just not keep SAS maybe for the data processing and have Python and R for visualizations? Depression, oh, I'll never be as good in R and Python as I am in SAS. And finally, there is acceptance. They see the market value because everybody is doing it at other pharma companies and there are really opportunities of going to learn open source.

And during this presentation, I will basically explain how change management can significantly help individuals as well as your organization going through emotional stages of change.

What successful change looks like

Now how does successful change look like? Well, successful change has two basically sides, a technical side and a people side. Technical side can also be in processes as well, but just delivering on the technical side, that doesn't get it. So people really need to embrace, adopt and use the future state for it to be successfully implemented.

And Nicole talked about the technical side of changes, a technical journey. Well, I'm going to talk more about the people side of change. And I'm going to use as a real life example, going from SAS to R to give you some examples on how you can adopt some of the strategies I will explain.

Now change is not necessarily hard because it's the people side of change. It is actually something that you cannot use as sometimes common sense, right? And I will be demonstrating that by debunking a myth around change as well.

Planning for change

How do we do plan, go and manage change effectively? Well, I have three phases. First of all, we plan. I'm going to spend a little bit more time on the planning part because it's sometimes that is more overlooked. It's about defining the change, understanding the potential impact of the change and creating a detailed strategy to go to that process. Then implementing the change itself, I can give some tips and tricks there, and then eventually sustaining the change. So it's not enough to just have people implement it or that we implement the change, but that we also reinforce the behaviors and the processes there as well.

So first of all, the planning phase. It's not just enough to start planning for training. So why plan for change? I don't know if you've ever tried to assemble EKF furniture without any instructions. It's like embarking on a heroic quest armed only with an Allen wrench, a screwdriver, and I think a vague sense of optimism. So you start very confident, convinced that you don't need a manual to only find yourself an hour later with a mysterious piles of extra screws, a lopsided bookcase, and I think a psychosynching feel that something is terribly wrong here.

So planning for change is just like writing those EKF instructions, but then for others and also better knowing EKF instructions to help avoid that you end up with a wonky outcome and that you do basically everything fits together from the start. There's a bonus that also most working relationships will hopefully stay intact. So yeah, before launching a new software or going with a new programming language, please prepare for that change. Just providing training is not going to cut it.

And in planning for change, I like to go over five steps. Basically explain the what, the who, the why, any concerns, and also the when. So let's start off with the what. So in defining the what of the change, you go from a current state to a future state and you have a transition. But there are four key questions that help explain to other folks what actually the future state will be and how you're going to transition.

And that is, what are the things that we are used to be able to do and still can do? Another question is, what are the things that we couldn't do before and still cannot do? These two questions are very important because it means that this is business as usual. You don't have to change anything there and that calms people down. So it's good to explain that as well. And then, of course, there are the things that we could do before and can do now. So these you have to let go. And the things that you couldn't do before and can now. So that is where you have to go. That's a change that's hopefully giving you a lot of gains. So without a clear definition, there is room for ambiguity. It can lead to resistance, also confusion, or inefficient use of resources.

Who is involved in the change? So how do we define that? These are entities, groups, individuals who are affected by the change. Also there, I would divide them into four different groups. The ones that are above the change, these can be your sponsors, can be influencers, change partners on the change. These are mostly the people in your project starting to work out the change. The change recipients, those ones will be in the change or going through that journey. And then also interesting onlookers around the change. Sometimes other departments who are also looking at something you like to implement.

And identifying these key stakeholders is also an ongoing process. For instance, you can have groups who are onlookers and get interested. Okay, they're adopting R, they want to use R. They might also be, hey, can we not be involved in that journey maybe as well? So they change from onlookers to be recipients. And also a good thing to look out is for if you have recipients, to maybe divide them into subgroups. Going from softs to R, you have maybe a subgroup recipients is statisticians. You might make a subgroup there of, okay, these are statisticians who already know R or these are statisticians who don't know R yet. So that helps in defining, okay, you might have to tackle those groups a little bit differently.

Step three is assessing the impact of change. It's not about producing widgets or features. So it's not about, it's about changing behavior. I give an example, if you put in a sign to say people to turn right, that doesn't mean that people are going to turn right. So the widget is there, but it doesn't mean that the behavior is changing and that people are turning right. So it's all about the outcomes itself. And you can explain it very well, the impact for people with pains to gain. So what is for them to gain?

And that explains it a little bit more from the emotional side than from the technical side. At heart is, yeah, the question that we need to answer is for what's in it for me. And you need to do that uniquely for each stakeholder. So for instance, from going from SAS to R, you can explain to statisticians that they have a wider range of advanced statistical packages and libraries to their availability. And that gives them cutting edge, gives them access to cutting edge methods. And that from a statistician's perspective can really help.

The fourth step is developing strategies for managing resistance. Well, people might say we've always done it in this way and it works fine with SAS. Well, they're often expressing a variety of underlying sentiments and perceptions. They have a sense of loss of control, they're uncertain, it's something new. They might fear of failure, doubts that it might work because they have already gone through past failures. They don't see the problem with the current process. So people resist for many, many different reasons and can also be very personal as well.

So some examples, if you move from SAS to R, what you can put in place for the resistance is a support team, SMEs that you can put in place to really help guide and hold the hands of people in that process. Pilot projects to gain, people need to gain some experience in it and maybe do also gradual transition. So not putting in a hard deadline for people. But also an escalation process may be in place because some of the concerns that people have, you need to listen to them. They might be actually valid reasons why they are a little bit hold back to do that change. Give an example, there might be clinical trials which are so, and need to be done so fast that it might be better to do an exception and opt out and say, okay, just do that study still in SAS.

Debunking the myth: education will change behavior

Let's debunk a myth. Education will change behavior. So we're always thinking about training. Let's give the right information. Let's tell people, okay, this is a great idea and it's all the best you can do. Well, it's actually not the education and information that will lead to changing behavior. It's actually the actions and opinions of others called social norms that influence the behavior of people to the greatest extent.

It's actually the actions and opinions of others called social norms that influence the behavior of people to the greatest extent.

And street musicians, they know that. So they, when they play, they already have their case with money in there. Just to give you an example, while other people have donated, maybe you should donate as well. What street musicians a little bit forget is if you would have a friend passing by every five minutes and dropping some money in it, that would even more convince other people to dropping money in it. So it's the same way going from SAS to R. If you have experienced peoples in your team, start doing it and explaining to other how great and how good it is. And that might help actually to convince other people to start doing it as well. So actions and opinions of other called social norms, that's what influences our behavior to the greatest extent.

And the last step is the one. So that's basically making a roadmap that provides a clear structure, ensures that all the stakeholders understand their roles and responsibilities, and that the behavioral expectations placed upon them at various stages of the transformation. So including key milestones, tasks, is essential for successful realization of change. So it gives a good view of it and definitely a clear structure.

Implementing and sustaining the change

All right, let's go with the next phase, that's implementing the change. Some of the key things I would like to highlight there is that communication is key in that perspective, but also be honest and transparent when you communicate. So sometimes you need to give the bad news as well. So don't sugarcoat it, just mention it like it is. Use also multiple channels of communication, like not only email, but also maybe Yammer, maybe a SharePoint as well. And there's also something, don't give the message once. People might not read the email, people might not read the Yammer page. So we know for a fact that you have to repeat the messages seven to nine times for it to really start sticking, and that's a lot.

Also monitor your change because you really want to know how basically you're progressing. So from going from soft to R, you have a statistical computing environment, you can crank the numbers out and how many people are actually using R already. Because there might be people that are not doing it yet, and you might have to talk with them, listen to them, or see how you can best support them in their change. This besides communication and monitoring, give plenty of support. It's really important to have resources available for holding the hands of people going through that process, that they really feel they're not alone in that whole process.

And then lastly, sustaining the change. It's not a one-time event. It's an ongoing process. So you'll possibly have to do some additional trainings again, reinforcing the behavior, support the people along the way. Maybe also be flexible and willing to do some adjustments to your plan as well. Tell success stories and reward people for it. Also very important to sustain the change.

Branding and making change fun

And then last but not least, I would like to talk about branding and infusing some fun into it. So creating the right buzz about the change is something that people get engaged and want to get involved in. Personally, I really like the theme, my change and what we've done here going from soft to R. We rebranded our change initiative to SAIL to R or SAIL.R. We call our meeting Sailor Trips, where we sail the seas of open source together. So maybe you recognize some familiar faces. We really took in person a photo from everybody with a sailor cap on. And then we had AI put in all the different suits.

So yeah, you might have recognized maybe JJ Hadley, Dhariv, Jason and Phil. So yeah, this is our last slide about change management. So I would like you to remember that know your stakeholders and what's in it for them. People are not wired for change, so resistance is to be expected. Education will not change behavior. Communication is a tourist street. And brand and infuse some fun. So thank you all for your time and attention today. And please don't hesitate to reach out if you have any questions. So thank you.

Q&A

Great, we do have some questions from the virtual audience. So how did you handle the people very hesitant or even against change? We have to, yeah, what we did is talking a lot with those people and seeing what actually why they are hesitant and maybe we can support them, maybe we can help them. And like I said before, we also have that escalation process. So there are people who may be resistant for a right reason, then we also need to, okay, this is what you need to, we need to adopt a little bit for them. On the other hand, we do require people also to move as well. So it is a strategy. So some people do need a gentle nudge in that case.

So another question, how do you generally determine resourcing for a change management effort? For example, is it a team of one or is there a general structure to follow? We do have a change management team. And then depending on, because in our case, we moved trial by trial. That means that we have a support group depending on when those trials are moving. We do have additional resources in place and also SMEs. So a support network of subject matter experts in place as well.

Have you used any specific resources for SAS programmers transitioning into Arc? Yes. So what we do is we have a team of change agents as well. We do have SharePoint websites where we put a lot of information on. Also, I think there is a Canvas project where we have the differences between SAS and Arc. So we really explain everything to the people and we have additional support people available that can help out. So teams can jump in if they really have any questions.

So two large pharma companies made public top-down announcements about their goals replacing SAS with R and filings. Was that captured in your roadmap internally or considered as a public statement? We do look into, yeah, what those companies have done. And we also try to connect to those companies as well and learn from them also. Yes. So it's not, we're not alone in that, in that situation. Correct.

A question about deadlines. So you mentioned that there are sometimes no hard deadlines. They tend to be useful though. So how do you ensure completion without a hard deadline? We give people the time to transition, but that doesn't mean there is no timeline. There's no clear deadline. There's no flick of a switch, I would say, from going to SAS to R, but we are moving people in a certain direction. I give an example. There are some studies that we say first patient in from that day, those people will have to move to R. So there is a gentle requirement to moving to R, but that doesn't mean that you need everybody or there's one fixed deadline. You can have multiple deadlines for different stakeholders involved.

We have one more question here we can end it off with. One of the benefits of using R and open source software is quick change implementation. Did you try to wrap a general quote unquote flexibility to handle change into your trainings? Well, we have a clear process in our statistical computing environment. And yes, there are also some updates containers from technical perspective. Yes, there are some flexibility in there and we also have a development environment so that new code that you really want to use, you can install it and you can start using with it. So yes, there is some flexibility. Thank you. Thank you.