Change management deals with how changes to the system are managed so they don't degrade system performance and availability.
Change management is especially critical in today's highly decentralised, network-based environment where users themselves may be applying many changes. A key cause of high cost of ownership is the application of changes by those who don't fully understand their implications across the operating environment.
In effective change management, all changes should be identified and planned for prior to implementation. Back-out procedures should be established in case changes create problems. Then, after changes are applied, they are thoroughly tested and evaluated. This article describes the process steps for change management and factors critical to its success.
Step 1: Define change management process and practices
As you would with other systems management disciplines, you must first craft a plan for handling changes. This plan should cover:
- Procedures for handling changes—how changes are requested, how they are processed and scheduled for implementation, how they are applied, and what the criteria are for backing out changes that cause problems
- Roles and responsibilities of the IT support staff—who receives the change request, who tracks all change requests, who schedules change implementations, and what each entity is supposed to do
- Measurements for change management—what will be tracked to monitor the efficiency of the change management discipline
- Tools to be used
- Type of changes to be handled and how to assign priorities—priority assignment methodology and escalation guidelines
- Back-out procedures—Actions to take if applied changes do not perform as expected or cause problems to other components of the system
Step 2: Receive change requests
Receive all requests for changes, ideally through a single change coordinator. Change requests can be submitted on a change request form that includes the date and time of the request.
Step 3: Plan for implementation of changes
Examine all change requests to determine:
- Change request prioritisation
- Resource requirements for implementing the change
- Impact to the system
- Back-out procedures
- Schedule of implementation
Step 4: Implement and monitor the changes; back out changes if necessary
At this stage, apply the change and monitor the results. If the desired outcome is not achieved, or if other systems or applications are negatively affected, back out the changes.
Step 5: Evaluate and report on changes implemented
Provide feedback on all changes to the change coordinator, whether they were successful or not. The change coordinator is responsible for examining trends in the application of changes, to see if:
- Change implementation planning was sufficient.
- Changes to certain resources are more prone to problems.
When a change has been successfully made, it is crucial that the corresponding system information store be updated to reflect them.
Step 6: Modify change management plan if necessary
You may need to modify the entire change management process to make it more effective. Consider reexamining your change management discipline if:
- Changes are not being applied on time.
- Not enough changes are being processed.
- Too many changes are being backed out.
- Changes are affecting the system availability.
- Not all changes are being covered.
Other process issues
Other process-related issues are also critical to the success of change management. Changes are evaluated and tested prior to implementation. It is practically impossible to predict the outcome of all changes, especially in a complex, interrelated system architecture. You must carry out a thorough evaluation of all changes, especially those dealing with critical system resources. We also highly recommend that you test all changes prior to full-scale deployment. For minimum impact on the system, test with a user not on the critical path, with test data, during off hours, and on a test system.
All changes, big and small, should be covered. Minor changes can have major effects on system performance and availability. A simple change in a shared database's file name could cause all applications that use it to fail. An additional software utility installed in the user's workstation could cause the user's system to become unstable. Or a move of a user's workstation from one department to another could prevent it from properly accessing the network. You might occasionally need to bypass certain change management processes, like emergency changes required to recover from a fault condition. But, even in these cases, document the change thoroughly, and have it approved after implementation, to ensure that system records are updated.
Document all changes. Perhaps the hardest part of change management is documenting all actions performed before, during, and after the change has been applied. Technical people often fail to document changes, and we have seen many problems caused because not everyone knew about earlier changes. Many IT organisations are familiar with the Monday Morning Crisis—that most problems occur on Monday mornings because someone implemented a change over the weekend without following correct change management procedures.
Communicate the benefit
Many people mistakenly view change management as more IT red tape. They fail to realise that good change management acts like a traffic light that regulates the smooth flow of changes and does not stop all change from happening. With a well-planned and well-deployed process, you can ensure that changes do not negatively affect system performance as a whole.
Harris Kern's Enterprise Computing Institute and Change Technology Solutions, Inc. represent the industry's leading minds behind the design and implementation of world-class IT organisations.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2003 TechRepublic, Inc.
1%
2%
It never fails to amuse me that the change management perspectives adopted and practised by IT professionals fails to address the fundamental aspect of human, organisational behaviour and culture. The measures put in place to 'scorecard' an engagement or project manifest themsleves as 70% technically oriented, rather than a targeted and well articulated approach around stakeholder management, business readiness, communications, organisational impact and training.