Jill Carniglia, Senior Director of Business Applications at Automation Anywhere, shares best practices when it comes to successful change management, implementing major transformations with small teams, and the value of communication.
One top challenge is that people are very tied to their tools. Their tools are their babies. It's what helps them be successful. So when you come to them and say, "These 10 tools that you're using, they're all going to go away and you're going to do that same thing inside of a different tool." There's a lot of doubt and fear that's attached to that. And so that leads into the change management aspect of how you help those folks through managing the fear of change and the resistance of change, which is the immediate reaction that you get when you say, "You know your day to day, but now we're going to change that up. And I don't do your job but I'm telling you that you're going to have to do your job with a different tool." Bridging that gap and developing that trust is a large hurdle we had to overcome. You need to come from it with a people first approach. That's about demonstrating to your stakeholders that you understand their point of view. Another challenge is speed. A lot of the efficiencies also are associated with cost savings, and that becomes more top of mind with COVID. So when you are retiring applications for a new application, sometimes you're predicated by those different timelines. So the speed at which we had to execute in order to be successful was not ideal, so to speak.
I tell them, "I get it, we're in this together. I know this is hard. I'm not discounting that. We're going to figure this out. Tell me the things that are most important to you about this." That helps to change the conversation from a reactive, defensive, resistant behavior to..."Okay. All right. If I'm going to have to do this, let me think through with this partner what is really important to me and what do I need to be able to achieve. She seems like she wants to partner with me to get this done. Let's try and figure this out." Changing the tone of the conversation upfront is really important. And then demonstrating that you're not here to try to make this a negative experience for everyone, but that you're here to really try and figure out how to pave the path for them and work together. Then, you need to consistently demonstrate that by checking in, even if it's picking up the phone and saying, "Hey, I know there's a lot of change coming. Tell me about the sentiment in your organization right now. Is there something that we need to pivot to do differently? Different communication style? Do we need to do a conference call with everyone? Do we need to have a virtual training session? What is it that we need to pivot on based on the pulse that you're taking from folks today.” This is critical because as you go along, you need to be agile with what you planned three weeks ago, and shift in order to make sure that you’re maintaining that sense of trust and confidence from your stakeholders that what you’re executing is going to be something that they're going to be successful with.
Some companies have actual teams that are focused on change management with an established methodology, so everybody knows what to expect at every stage of change. Many companies, including Automation Anywhere, don't have that. It’s almost a luxury these days to have a change organization. And so in the absence of this people think about, "Okay, what are the most important things? I need to have stakeholder involvement, executive sign-off and oversight and support, and a communications plan (including training and enablement).” Those are the three basics. But what happens is, a lot of folks assume that they need to heavily invest in ensuring the C-suite is aware of what's going on. And as decision makers that's extremely important. But really where you need to be spending a lot of your time is with the people who are impacted by the change. I see that being a core fundamental misstep in a lot of these large transformational projects. They spend a lot of time managing up, communicating up, making sure everybody's aware of the projects, red/yellow/green, what the core issues are, etc. Often, a project manager's time is spent mainly doing these updates slides on a day-to-day basis. Really, where you can get the most value for your time, and actually make sure your project is progressing, is spending time with the people who are impacted. They're the ones on the ground.
Another common mistake is not getting constant participation upfront, at the beginning of a project, to really make sure you’re defining what your requirements are and attaching what the expected outcomes are. It's very easy when you're inside of an IT organization to understand the importance of requirements, and the way that requirements drive outcomes and solutions. But someone sitting in a finance or sales organization does not have a technical role. Their role is not about delivering software projects. Their role is, “I need to do XYZ. I’'m responsible for revenue, or I'm responsible for selling.” And as it pertains to CRM solutions, those roles all have a part to play in defining how we build out Salesforce for instance. So when you're bringing them into these types of projects, you need to talk about requirements that you need from them, which can be a very tedious exercise.
Lastly, it is so important to NOT allow your stakeholders to give you solutions. Ask them what their problems are, have them tell you what they're not able to do today, and then you provide them with the recommendation from a tool perspective. Because, otherwise, they get so caught up with..."Well, this is how I know the tool works now. The tool just needs to change this way." And I'm constantly saying, "Okay, let's not talk about the tool. Tell me from a business process perspective, what do you need to do to be successful? What are the outcomes that you need to be able to achieve?" And then we'll talk about the tool and it changes the conversation significantly.
The C-suite are the decision makers, the ones who are funding the project, so they're critical for the success of the project. But the execution layer and the way that you build out the team that is going to be responsible for the success of the project is super critical. Most of my projects have about 70 stakeholders, so I typically create a pyramid where there is somebody who is ultimately responsible for attending every single one of these meetings. Depending on who's impacted, if it’s finance I've got somebody from finance, if HR is involved I’ve got somebody from HR present, etc. They have to know everything that there is to know about this project on behalf of their department. They're my change agents and for the lack of having a change function at the company. They know who to pull in from their teams to be involved. So when I kick off a project with these team leads, I talk about the importance of communicating constantly. You never know who might be interested. If it's a weekly email, if you have a spot on the agenda in your team meeting, whatever it is, make sure that you're communicating and over communicating the status of things. And if you need me to attend those meetings, I'm happy to do that as well. That’s how you manage and proliferate change and change agents.
That's very top of mind for me right now. We've got a very small team, and now we've taken on this investment to do a significant amount of transformation and really make Salesforce one of our mission critical systems. With that have come some challenges in terms of making sure we've got the right skillset to be able to support these new technologies and feature functionality that we're investing in. Salesforce is a very prolific tool. You can do a lot of things there. Doing this successfully requires that you really understand your roadmap 12 to 18 months ahead of time, not just from a technology standpoint but from an enablement standpoint. At the beginning of the year, we started talking about the need to bring in CPQ for new business. I didn't just look at that in terms of, "Okay, let's do some rationalization around the timeline of when we would be able to execute this project taking into account our year end and other projects that were already lined up.” But rather, “Let me think about the team that we have today. It's not about whether they can actually deliver the project, but once we've delivered it, can we support it? Can we ensure that we're delivering best in class support to our internal users so that they in turn are optimizing and adopting the tool itself?" Looking at the number of support tickets that we received during, what I call, hypercare, the first two weeks post deployment, about 50% of them that came into the team were “how to” questions. “How do I do this now? I used to be able to do it this way and that field's no longer there. So now how do I do this?” Despite delivering a fairly comprehensive sales enablement and training program ahead of deployment, you're always going to have a number of folks who either were not participating or there could have been a myth in that material. So you really need to think about the full enablement, and whether you are making sure the team can be able to talk our users through how to do this from a business perspective as well. That planning piece is critical.
The measure of a successful project is how satisfied the end-users are with the result. There's going to be bumps in any technology project. Things aren't always going to go perfect. Software is imperfect by nature. You can plan as much as you can but you're always going to hit some snags during deployment week. But ultimately the end-users are either satisfied or they're not satisfied, regardless of those blips. So the way that I measure my personal effectiveness is related to that. "Has this made your day-to-day lives easier?" That's super important, because technology is an enabler; it is not the one doing the job for you. The people are doing the job; the tools are what are enabling them to do that. So if they're not doing that and they're actually doing the opposite, then that's not success for me. Number two is, the folks who worked on the project, what was their experience like? Did they feel successful? Does the team feel like they delivered a good product or service? And if not, why? That's also a critical area that I measure myself on. So those are the two core things I look at in a project post-mortem perspective.
I think IT organizations are increasingly moving and reporting to the CFO. We're a cost center and I think people are recognizing that through enabling technology there's opportunities for efficiency and cost savings. That's the same conversation that goes along with helping to develop a relationship with your CFO. When talking about technology, my expectation isn't that the CFO is going to understand the odds and ends of what the software deployment looks like. What he is going to understand is why it's important that we make investments in different tools. We look at our entire technology portfolio to help him gain insights into what we see as our core objectives for the company. But most importantly - and I say this to him often - is help me understand what the core company objectives are. If I don't understand what those are, I can't be effective or successful in my job because I'm going to be enabling the wrong people. If an objective is centered around growing revenue X percent, but I'm spending most of my time trying to understand what HR needs out of Salesforce, then those are misaligned objectives. We're never going to have success there. So I think that there's a huge benefit for IT to be under a CFO in that they really have a bird's eye view as most C-level executives do. But the CFO in particular has an important perspective on the roadmap, and where the company objectives fit in, and how to underlie that with the tools and technology to get us there.