What are the common change management mistakes that IT executives make?

Top Answer : 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.

Pink USB Stick
Software
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.
0 upvotes
Green Hard Drive
Software
Not... 1)Setting the proper expectations upfront with the teams involved.  2)Defining a clear process flow from the start.  3)Having the proper executive support 4)Soliciting feedback from other cross-functional teams.  5)Introducing the new process at a pace that the organization can digest properly, too much or too quickly can result in a lot of resistance.
1 upvotes