The term “change management “ has been interpreted in different ways by different people depending on the context in which the change is being introduced, the reason for the change or the execution of the change. While conventional wisdom suggests that this phrase encapsulates any shift or transition from a current state to a pre-defined, different and desired future state, various experts have broken down this term in a number of ways and coined their own definitions. Some prefer to list the phases or stages involved such as 1. Adapting to change, 2. Managing change and 3. Effecting change. Other organizations such as Prosci Inc. talk about the three elements of change management being 1. The process, tools and skills to achieve change, 2. Managing the people part of the change and 3. Achieving the objectives related to the change. (Prosci Inc., 1996-2011)
In this article, we aim to examine change management with a strong focus on the people management side of change, using one of Prosci’s models to illustrate the challenges faced during change management while analyzing a real life example from relevant past industry experience.
A close-up view of ‘what can go wrong’ in change management was experienced during a large AMS (Application Management Services) project for a truck and bus manufacturer in Japan. Being part of the IT vendor onsite team which was to build and implement a new incident management system for this client, we were able to experience first-hand, how people try to avoid change at all cost. The structure of the Business IT department which handled the companies’ application portfolio did not make it any simpler. Applications, depending on their functionality, were divided among IT managers who were responsible for daily operational execution.
Prosci’s ADKAR model has five elements which we will review utilizing the aforementioned example:
Awareness of the need for change
Up to the point where the idea of a new incident management system was conceived, the users of the applications would send their requests, incidents and tickets to the responsible IT manager, and he in turn would forward it to our onsite team. Since we followed a Global Delivery Model and had a large portion of our work being done offshore, effort tracking was never a simple task. Prioritizing different tasks from different client IT managers was also a problem. The new incident management system was supposed to fix both problems – 1. Allow us to track efforts spent in each incident. 2. Enable prioritization of tasks with all stakeholders having their input or being informed. Hence the need for change seemed to be clear, justified and well communicated.
Desire to participate and support the change
The biggest challenges faced were in this element. Users had different ways of reporting incidents or suggesting enhancements to systems. Some sent emails to the IT managers, while others communicated directly with the onsite vendor SME. This change would force them to follow a workflow of approvals along with initial overhead which they were more than happy to avoid. The interest to accept the change in the process was not present. Users who had good relationships with SMEs were still sending emails to communicate their requests in the hope that they could bypass the IT managers and hence avoid using the new tool. Some of the SMEs faced a tough situation where they had to refuse requests that were sent to them outside of the new system.
Knowledge on how to change
This area of the change was handled well. Regular training sessions and workshops were held, educating the users, managers and the offshore SMEs who were not aware of the tool, on how to use it. A manual was created in which the workflow was explained and initially, onsite SMEs helped users and the IT managers in creating incidents using the tool, monitoring it through closure.
Ability to implement required skills & behavior
As mentioned before, the skills to use the tool were not difficult to teach. The problem was the complicated and fragmented nature of the reporting structure within the department. Hence, implementing the behavioral aspect was the real challenge. Some applications had no IT manager assigned to them. In some cases, a small group of users also acted as responsible managers for the application. For those users, it took longer to warm up to the idea of entering all incident related information in a tool. Another problem was that prioritization issues crept up as everyone thought their request was the highest priority. In many cases, the vendor SMEs were asked to prioritize, which led to more issues such as strained relationships between users, managers and onsite SMEs.
Reinforcement to sustain the change
It took a lot of effort from everyone involved, including the senior managers, and eventually the head of the Business IT department, to turn the corner and eradicate the usage of emails for making requests. By the time all incidents (previously open as well as new) were tracked in the system, almost 13 months had passed. This timeline was not foreseen in the project plan as this change was estimated for a 4 month transition period. However, even after this stage, it took disciplined follow up procedures and constant reminders on behalf of all parties to make sure the tool was effective and the quality of the data entered was high.
The above example illustrates how difficult the people management part of a change process can be to implement and sustain. It usually is never as simple as theory suggests, but most cases can be managed if a well structured plan or model is put in place to initiate and control the change. In addition to the processes put in to place to manage change, T-Systems also has teams consisting of experts with vast experience in this area. These experts ensure that the processes are followed to the finest detail, while implementing all the best practices in this area and hence nullify the main challenges associated with this highly sensitive and volatile area of change management.