Sudhir Reddy, the CIO of IT solutions company MindTree, recently pulled off a CRM 7.0 implementation without any major issues. Reddy and his team were able to migrate 180 users with little resistance, largely due to their efficient change management process. Users were given access to the prototype in QA, and were allowed to play around with, and get accustomed to the system. As a result, when the application was finally deployed, users had very few questions and were comfortable using the system — a good example of how to execute the change management process associated with an IT project.
In a mature organization driven majorly by IT, it's not uncommon for the CIO to be involved in the management of changes to business processes. The needs of a business constantly change, and technology has to keep up. But an improper change management process can end up being a waste of time and money. "The change management process ensures that standardized procedures are used for efficient handling of all issues," explains T G Dhandapani, the group CIO of TVS Motor and Sundaram Clayton Group.
The change management process may be sparked by the CIO's effort to improve the business, or it may be a reaction to external factors such as version support being withdrawn by a vendor. A case in point is Bobby Varghese, the VP of IT for CSS Corp, and his team, who plan to change (or upgrade) their automatic call distribution system in 2010 since their vendor Avaya plans to withdraw support for the current version in use at CSS.
Varghese classifies change into three categories: business critical, business-as-usual, or immediate change. The first category is when a company introduces radical changes like the introduction of an ERP system. Business-as-usual change is when business continuity is not affected by such a change; an example would be a network team replacing a switch with the same product from a different vendor. The third category consists of situations like when the security team detects vulnerability in an application and releases a patch to counter it.
These three changes can be further classified into planned or unplanned changes. Planned changes are easier to implement, especially if they are initiated by the CIO. If introduced by other departments, the CIO is consulted to understand the impact on IT and the change management process (if required).
Unplanned changes are more challenging. Organizations where the IT function has not matured enough, isolate the CIO from any board-level decisions, thus leaving him unaware about the imminent change. "The acquisition of a company and its repercussions on IT is a classic example of unplanned change," comments Reddy. In such cases, as soon as the move is announced, the CIO and his team are expected to pick up their tools, draft a change management process, and get the disparate systems to talk to each other in a matter of days. "Deadlines and scenarios will be given; you have to work backward, master the change management process, and deliver the expected result."
Getting the team together
Change implementation teams typically consist of the CIO's deputies, who are assisted by external consultants and functional experts. In some cases, vendors are also involved in the change management process. For example, at CSS, most enterprise applications are deployed by vendors, while changes to desktop applications are carried out by internal teams.
Varghese says his team consists of subject matter experts who may or may not be employees of CSS. "For commonly-used applications such as Windows servers, I have people within my team who can help with the change management process. But if I need to evaluate specific technologies like IBM mainframes, I would need to include an external consultant in my team." His team also consists of IT end users who can judge for themselves about how the change will affect them.
After the transition
Testing is a major part of any change management process, and thorough testing of the deployed change is recommended. Once the transition is completed, it is necessary to help users adapt to the change.
Not everyone adapts to the change management process easily. Hence it is recommended that the CIO communicate openly with his team, and explain why the change was initiated.
It is also necessary to engage with all the users of the system so that they are clear about why the change was initiated, and how it has affected them. This is because a change will not always reduce the effort to be put in by users. An example is the introduction of an ERP system; this would streamline many processes in the company, but the approval process to get certain tasks done would be tougher. However, although the complexity may increase, employees must be made aware of how the changes are advantageous to the organization, and hence to them.
"If you push the change management process [without proper communication], users will not adopt it wholeheartedly," explains Reddy. No change management process will be flawless, and every change will have its glitches. How the user reacts to a glitch depends on how well he has been eased into the change management process. "If you haven't enrolled him well, he may be waiting to take shots at you," warns Reddy.
Reddy recounts a change management process at MindTree, where the COO's office and the CFO's office were unhappy with the regular network printers because there was excessive paper wastage. Information security risks were also present because employees often left unattended print copies. Reddy was called in to help the company change this. Reddy and his team installed multifunctional printer-copiers with enhanced security features, and thus changed the printing process at MindTree.
A good change management process helps IT teams to control the occurrence of any untoward incidents during implementation. Testing and communication after implementation help to ensure the success of the project. Finally, understanding the need, scope and deliverables can help to make the change management process—and the change—a little easier to accept.