IT change management part 1

Change management within IT has gained a lot of traction in the last 5-10 years, in some cases this has been accelerated by the need to comply with SOX regulations and wider acceptance of ITIL concepts and best practices.

In order to help the business meet rapid changes, IT needs to react quickly and without impacting the quality and stability of the environment and the service levels. Changes to IT systems are required due to a number of reasons, some of which are related to
1. Application
2. Hardware
3. Software
4. Network

For e.g. if you have to upgrade your business systems / business applications to the next release or upgrade / change hardware like CPU, RAM or other peripherals, or if you have to make changes to software like operating systems due to new patches or fixes or changes to your network infrastructure.

Change management as evolved from an ad-hoc basis into almost a science with specific goals, metrics, risk management and methodology.

The goal of change management from a business perspective is to ensure

• All authorized changes are based on business needs and are approved
• All changes requests are addressed and implemented in a efficient and conforming manner
• Business risk is managed and minimized
• Standardized methods and procedures are used for handling of all changes
• All changes to the IT infrastructure (software, hardware, applications and network) are recorded and documented

Now you might wonder, why I wrote from a business perspective…the changes should be based on good business reasons, it should be tied with a business approved initiative or have a valid reason such as potential adverse impact to the business. If you have to install a patch and explain the need for this change to a business person they may or may not understand the reasons. If you put it in the context or risk or benefit to their operations (possible impact of downtime to their applications / users), they will become interested very quickly.

How do you go about implementing a change management methodology within IT?

First define your process /policy clearly define
• Scope (which some or all pieces of IT infrastructure should follow this process).
• Roles, responsibilities and procedures related to change management
• Define best practices for change management and configuration of software
• Review frequency of your policies, procedures and standards
• Key performance indicators which indicate your service level and operating level performances.

All business critical applications should be under change control and best practices defined for change management should be adhered to. Without having a proper change control mechanism in place, business could be impacted by poor or no risk assessments and unauthorized changes could occur.

Roles and responsibilities related to change control are essential to ensure proper implementation. There needs to be a distinction between developer, tester or approver and implementer of changes. This can be complicated further, if you have multiple environment such as development, QA and production. Change control is not easy thing to accomplish as it involves participation and adoption of all stakeholders within IT. In some cases, smaller organizations may not be able to assign different people to different roles.

Standard operating procedures must be developed based on industry and software/vendor best practices. For example, changes to codebase of business systems must be stored within a code versioning system. Configuration management of all business systems and operating systems should be considered. There are a number of solutions which can address this. At a minimum, consider a spreadsheet based solution which highlights changes and what files/directories were impacted and tie these to change requests and package updates.

As roles and responsibilities change from a function perspective, change control processes and procedures should be updated to indicate the current state. In addition, based on lessons learned, changes to documentation might be necessary. Setup a reoccurring meeting to discuss policies and procedures on a frequent basis, maybe start out with once a quarter.

KPI’s should highlight ability of IT to react to the business and how quickly the changes were impacted and should also include adverse impact to the business through downtime, missing functionality etc in terms of dollars and hours. Review these KPI’s with the business on a frequent basis and work on areas where improvement is required.

"Disclaimer: The views and opinions expressed here are my own only and in no way represent the views, positions or opinions - expressed or implied - of my employer (present and past) "
"Please post your comments - Swati Ranganathan"