Persistence Toward Change

Patty recently posted about handling the people side of change. For the past year, I have been driving a wHolistic Change^SM that involves the sunsetting of old applications to save a company money. The fact is that the majority of the savings in application retirement come from simplifying not only the technology landscape (number of IT systems), but also in reducing the volume of people required to support a myriad of different technologies.This has forced my change team to have to handle all aspects of driving a change. For some of them, this is the first time they have been challenged to do all of the following (and it is a stretch assignment compared to their previous projects):

1. Be able to make the business case for change
   • The change team must be able to articulate the business value why this project is so important to the company and its shareholders
2. Clearly define success metrics - how many applications must be shut down each year (and measure monthly how we are doing against that metric)
3. Avoid the pitfalls that prevented the company from methodically retiring applications in the past
   • All of these learnings were incorporated into the organizational design of the team and the templates created for the project.
4. Leverage our sponsors, when needed, to ensure all of the executives across the organization support the initiative
   • Becoming comfortable in engaging our sponsors is critical to remove obstacles and keep the change moving forward.
   • There are people who are reticent to delegate upward or to escalate issues (as appropriate); when driving a corporate change, if the sponsor doesn't know that a major roadblock has been encountered, then they cannot remove it!
5. Teach people who are assigned to the project how to be change agents
   • My counterpart and I spend the majority of our time training and mentoring the people assigned to the project (at all levels) how to maintain a corporate point of view and drive the change forward, no matter what excuse we hear.
6. Methodically plan the change, along with the roadmap for the tools needed to make this happen
   • In some cases, we have had to get people out of the academic, theoretical thinking about change and into a mode of creating clear, understandable templates that everyone can use consistently to ensure full decommission of the applications.
7. Determine the key stakeholders and regularly communicate to them through a variety of mechanisms
   • Without stakeholder buy-in and awareness of the initiative and its impact to them, the change will not succeed
8. Create a continuous improvement process with regular checkpoints to gather voice of the customer feedback on how we are doing
9. Develop training materials so people understand application retirement
   • As far as I know, computer science and engineering schools focus on how to build new systems, not on how to simplify and reduce the number of systems.
   • People who have potentially spent their entire careers to develop an application go through a grieving process when the decision is made to shut it down. This is a normal human response that requires empathy and coaching to get them through it and to the place where they can help make the change a reality (because without understanding the system, we cannot ensure business continuity once the system is shut down).
10. Celebrate successes, to encourage more people that the change is the right thing to do
11. Overcome resistance to change, which is being encountered at every level. Learning to handle the resistance has been the biggest adjustment for the people on my change team:
    • IT leaders who have been in their positions for many years may hold the belief that the number of people who report to them (and number of applications that they are responsible for) equate with their importance to their company. Application retirement is thus at odds with their sense of self worth and power as compared with their peers, and requires cultural retraining (a corporate, shareholder point of view) to get their support.
    • Application owners who have spent their careers building the systems may not want to share any knowledge of what they do or how the applications work, because they fear losing their jobs. All obstacles need to be handled with compassion but persistence - using data to articulate the business case, explain the plan for retraining (if needed), and be honest about the future.
    • Business users who are comfortable using their legacy applications may not want to learn new technology (even if it has more feature functionality and fewer clicks to get their jobs done). Again, persistence is required to share the corporate point of view explaining the reason for business process change, listen to their concerns, and continue to push forward.

I am grateful that I work with a team of professionals who are able to maintain their senses of humor while also resiliently moving the change forward. Application decommissioning is a difficult change, but definitely one that can be successfully managed if one takes a wHolistic approach.