Vasudha Prabhala

Hello. Welcome. Thank you for carving out 30 minutes of your time with us on this journey, where Kari and I will talk about change management in large legacy transformation.

My name is Vasudha Prabhala, and I'm a senior vice president at Headspring, and my charter is essentially delivering large transformations for great clients.

Over to you, Kari.

Kari Brey

Hi, everyone. My name is Kari Brey, and I work at Travelers Insurance Company. I'm a second vice president with Travelers, and my main charter is transforming a large legacy application to modern technologies. So I have a lot of experience in change, and I'm very excited to talk to you all about that today.

Vasudha Prabhala

So before we talk about change management, let's talk a little bit about legacy transformations. If you look at the emerging landscape, you can see that CIOs are under significant pressure to move IT at the same pace as the business. Organizations expect that our systems and our capabilities in the IT organizations reflect the business reality, which means they're asking for flexible, scalable, and secure systems.

But most legacy applications right now, and when I say legacy applications, you can see some of the bullets. These are on outdated technologies, and you have some aging workforce, or you have outdated skill set. And a lot of them, you can't even put in more features. And also what's happening is as people retire, there's a huge change in the tribal knowledge, loss of that. And also a lot of them, we see that requires re-engineering of business processes.

And given all of these, then this requires large transformation programs. Large transformation programs have four characteristics. One is scale. And more often than not, these changes affect large parts of the organization, if not all of it. Magnitude. What I mean by that is it significantly alters the status quo. And then the duration, the third angle is the duration, which means it lasts for months, if not years. And more often than not, trust me, years is the reality than months. And these are of strategic importance. So they are, again, trying to change how the business functions, health, business capabilities, and also the IT capabilities.

So we are always working through these four aspects in long-term transformations. And what essentially that means is change management becomes the core of everything. How you manage change, how do you incorporate change? How do you become an organization that is able to deliver these programs successfully and also in turn change your organization?

Now, one of the things that happens when you are talking about change management, there are a lot of definitions out there in terms of, "Hey, what is change management?" Change management is changing processes. Change management is changing people. But if you look at it at its core, it is actually becoming a learning organization. And what I mean by that is it's a process of continually renewing an organization's direction and its overall structure, and also the capabilities to serve the ever-changing needs of your internal and external customers.

And I'm not saying this is easy. We are not saying that at all. But I have to understand that the focus is on becoming a learning organization, and you want to get it right as much as possible. And I talk about that because managing change is really hard. And the sad truth is a lot of change management initiatives fail. Gartner did a study, and it said about only 54% of these transformations actually succeed. The change management initiatives succeed. And that's because of some of the reasons that you can see on the slide, but more often than not, it is because of the top two reasons that are there.

The first one is confusing communication with engagement. And what we mean by this is, while it's absolutely necessary communicating all aspects of things, just because you are communicating doesn't mean the people in your organization are actually engaged. So you want to try to make sure that you have capabilities to manage both of those: the communication aspect of it and the engagement aspect of it.

Now, what I've seen in my experience is, and I'm sure Kari can vouch for this, is there's a lot of emphasis on formal aspects of change management. Who's the sign-off? Who should be doing this? Where should it go next? Hey, are we following agile process? Are we following XYZ? Are we capturing these metrics? What gets lost is the human element of it. How does this make people feel? How do you capture that into metrics? We'll talk a little bit about all of those, but that's essentially where we want to focus. So you want to make your culture a priority and make sure that you can learn, adapt as an organization.

If you don't do change management right, then you can have some unintended consequences. It is all the way from the job satisfaction of the individual. And in software development, if you're not really happy and you're experiencing burnout, it affects your performance. If it affects you as an individual as a performance, it affects the organization that you are in. And eventually, your delivery doesn't meet the expectations of what the business wants, and that creates a negative user experience.

So these things have ripple effects, and so you want to be extremely careful of how you implement change management and what the intended and unintended consequences are.

A lot of times people focus, or organizations' focus is on, "Hey, where are we on the maturity model of change management? Are we just becoming better? Or are we really evolved?" What you want to focus on: are we measuring the right things? Are we creating the right capabilities? And are we becoming a learning organization? And managing change means, not to forget, it's humanizing it.

So with that, I'm going to hand it over to Kari to walk us through the best practices that we should be incorporating in change management.

Kari Brey

Thank you, Vasudha. Very nice introduction. As Vasudha mentioned, I want to talk about some best practices within change management. These are the best practices that we have found to be successful through many transformation efforts. There's probably others that you could use or have used. So you will adapt and adjust as you find necessary.

So moving to the very first one. Choose your direction. As we think about legacy change, one big component is actually in the DevOps, and DevOps is a journey towards more frequent and reliable, higher quality releases via a pipeline. And with that, we're recommending you choose one direction and stay the course. Understand, though, that things may come up where you might need to alter the course, but your overall course direction and objectives don't really change.

You also want to seek 360 stakeholder buy-in and feedback. You want to talk to your stakeholders, understand how they define success, understand how they can help you through this journey, and where you can actually leverage them in your direction.

You want to identify your enablers and derailers. Think about who and what you need to be successful. Engage those things and people as early as possible. Also, think about derailers, which are a form of disruptor that you also want to think about. Derailers can be anything. So think about things that can take you off track and set you in a tailspin. What if I fall behind? What does that really look like? How am I going to get back on track?

Anticipate what those disruptions will be and pre-think through some mitigation strategies. Have them handy, so when something comes up that you didn't think about and that's disrupting you or derailing you, you can focus on that and come to answers quickly. But having pre-thought through mitigation strategies for what you anticipated will really help you answer things very quickly. Quick decisions are key.

So next, we're talking about change leaders. Change leaders are more than your end users. I chose the word leader in change leaders very carefully and thoughtfully. Change leaders and leaders of the whole are really essential to your success. They set vision. They think broadly. They're not thinking about just the particular modernization or legacy effort that you're working on. They're thinking about the entire ecosystem and how does that fit into that. So leaders actually drive and make things happen without people really understanding how they're doing it and why they're doing it.

End users are necessary, and they help bring things in perspective. And they're looking for end results and not necessarily at the entire ecosystem.

You also want to invest in champions at every level. This is very similar to your stakeholders. When you ask them how do they define success, make sure your champions at each level understand that and can support the success and help bring that message back to your stakeholders.

You're also going to want to develop reinforcement loops. And these are places where key messages are made by stakeholders, by your change leaders, by peers. And invite them to speak at retros, at staff meetings, at team meetings, or send out emails along the way expressing their commitment and their support to this change effort. That actually helps motivate people on the team, saying, "My leaders recognize what I'm working on. They think this is important." And so you're going to want to make sure you deliver your best.

You're also going to want to inspire others to perform at higher levels, and this can be done many ways, but you want to recognize people that are willing to take risks, go on a limb, have the how-can-we attitude versus, "Oh, we ran into another hurdle. We're going to have to delay," as their first response. You want people that when they run into a hurdle say, "How high can we jump over this hurdle and keep on moving?" Push them to their potential and past their potential. Give them stretch assignments. Even have some of your change leaders meet with them and explain to them the importance of their performance and how it's really driving success.

Moving on to the next best practice is making culture a priority. This is really important. You need to understand what is the culture I want to drive to? What does that end state look like? Once you define that, you're going to want to map the gaps. And as you're thinking about that end state culture, take things like this into consideration. Am I going to do this journey for just my brownfield development? Am I going to do it just for my greenfield? Or am I going to do it for both? If I do it for both, what order am I going to do it in? And then develop the culture around that.

What's in it for those end users? If I'm a developer, I want to be able to push my code anytime with the least amount of hassle, the least amount of overhead. That should be part of your culture when you're working through a DevOps journey.

Another point is really around transparency and sharing your successes and your learnings. A lot of people do not like to use the word failure. Failure sounds bad, but failure is first attempt in learning. So remember that. Fail. Fail fast. First attempt in learning. Share those. Learn from them. Share what went well and keep on doing what's going well.

Over-communicate is another thing I can't stress enough the importance of. Have everybody be involved in the communication. The more you communicate, the more people are going to be aware of what's going on, and that's important.

Adopt a blameless postmortem attitude and culture. It's really about what and why and not the who. Focus on what went wrong, what did we learn, what was involved, what can we do differently, and when can we start? It doesn't matter who was involved because it could be you, it could be me, it could be somebody else, and that's the wrong place to focus. You will lose trust from your team if you focus on the who. They won't want to tell you what is going on. And so that's what you want in your culture, a learning, collaborative culture.

So as we move on, we want to talk about the best practice of expanding iteratively. Most people are doing agile type efforts nowadays, and everything's done in small, shareable, consumable pieces, bites, and that's the approach you want to do to your legacy modernizations. It's really important to commit, have small commitments, hit your commitments. You will then build trust with everybody, your stakeholders, your end users, your change agents and leaders. You're not distracted by putting together status reports of how you're going to catch up. You're focusing on your next commitment. Do what you can to be true on those commitments.

Make continuous delivery a mindset. When we think about mindset, that's really your attitude, and when we think about attitude, we want to make sure we're always thinking about continuous delivery and how do we bring that into everything we do. And it's not big bang, it's small bites over time.

We also want to embrace continuous improvement. We want to learn. We want that learning culture. We want to adapt and adjust. And by having a continuous improvement culture, that allows you to grow, accept change, adjust from change, and do the next thing, and not dwell on maybe what went wrong.

You also want to experiment in small slices. You could take something that you do today. For example, you deploy quarterly. Instead of going to deploy daily, you might say, "What if I were to deploy monthly? What's standing in my way of doing that?" Take that slice, break it down, figure out how to deploy monthly, do that, do it well, and then move on to the next thin slice. Okay, now I've got monthly down. Let's deploy weekly. Some people are going to start quarterly, some people are already doing weekly, some people are already doing daily. It depends on where you are. But the point here is do small bites, and do them well, and then get better.

Okay. The next best practice is focus on capabilities. And this, in a way, goes back to the direction you're heading. So all these best practices, in one way or another, tie to each other. Identify and agree upon the capabilities necessary for a successful transformation. And think about things if you're doing the DevOps journey. What are the capabilities I should focus on? Depending on your level of maturity, you might start with: do I have working software? All the way to: do I have the appropriate governance or automation built in? And your capabilities can span anywhere between those types of things. Identify the ones that you will build your success for and on.

Also then, assess the skills of the team you're going to be working with. Recognize that not everybody is going to have the skills that you need. There might be new processes. I should say there will be new processes. That's probably a better way to state it. There's probably going to be new tools, techniques, different people to work with, things that you haven't expected. Make sure you plan time for people to be upskilled, learn new things, unlearn things at the same time.

Adopt a willing, able, and ready strategy. Don't think you have to start from square one. Other people have done this. Learn from them. Surf the net, find out what has worked and what hasn't worked. Engage with experts. Find out a vendor that can come and help you. And they will also help upskill, they will coach and mentor your folks, maybe even hire some new people that have the skills already. Surround the people that need to learn and grow with expertise.

Lastly, learn from other mistakes. You don't want to repeat a mistake that somebody else has already encountered. Learn from it. Ask them, "What would you do differently? What would you do the same? Why is that? How long did it take you to learn that?" And embrace that this is a change. Change is hard, but it's very doable.

So with that, I touched five of the best practices that we have in our topics today. I'm going to turn it back to Vasudha, and Vasudha is going to talk about measuring change and the best practice and importance around that. Vasudha, back to you.

Vasudha Prabhala

Thank you, Kari. That was wonderful. Thank you for walking through those best practices.

The last one, equally important one, is ability to measure. And you have heard the famous saying, if it doesn't get measured, it doesn't get done. But you also have heard, if everything is important, then nothing is important. So the key takeaway is you want to focus on measuring the right things at the right time.

And the other aspect that I want to highlight here is you want to focus on the directionality than the absolutes. The reason we say that is when you're starting out the program, you don't have any absolutes to compare it with. And especially which is true when you are having end-user engagement or you're measuring the culture and the direction. How effectively are you able to communicate, and how effectively are you evolving your culture? That needs to be a directional aspect of it.

And one of the metrics that is highly popular and is leveraged across organizations is eNPS. So eNPS at 20 is no-- it doesn't make any sense unless you are measuring this quarter over quarter and it is moving on the positive scale. So tomorrow it is at 75. In six months it's at 74. Now, that's positive and that's what you want to see. Yes. And so let's say if it comes down to 15 one of the quarters, you want to understand what have you incorporated that has brought it down? And you want to gauge it. So again, directionality is more important.

You also want to measure things that will have impact. Let's say you are building a product and you are letting your business stakeholders know that this particular piece is going to be available to you 99.99% of the time or one of those metrics that get thrown out these days constantly. The focus there is, then you want to measure the meantime to restore a service because that directly impacts what you're promising your business stakeholders.

And we measure a lot of software development metrics: velocity, throughput, the variance of estimation from the beginning and end. But you want to also make sure that all these correlate to the business outcomes. Business outcomes is you want to know the estimation duration, the variation, because you want to make sure the budgets that have been allocated have been leveraged correctly and how we are tracking. The other aspect when it talks about business outcome is, are we able to deliver? How long does it take for a feature set to get delivered? That's an important metric. And are we able to repeat this on an ongoing basis? And what can we do to improve these?

So these are just some of the examples, but you want to focus on the right measurement at the right time for your organization, and which is a 360-degree view, and not just end users, not just the business stakeholders, but also the people that are part of this entire journey, which is the people who are part of the legacy application, the people that are currently developing, the management, every aspect of it. So please make sure that you have a cohesive, comprehensive framework to measure some of these.

With that, I want to just reiterate all the five practices about making the right direction and also developing these change leaders. And overall, instead of me going through all the rest of them, what we want you to take away is, are you able to build a learning organization? And are you able to evolve the culture and make sure and thrive in this culture as you move forward and deliver?

Thank you so much for spending these 30 minutes with Kari and myself, and we hope we get another chance to talk to you through these presentations or cross paths in some other way. Thank you.

Kari Brey

Thank you. Happy change.