The term “change management” can refer to several disciplines. Just within IT, “change management” can make people think of
- organizational change management (e.g. how to handle two departments merging),
- IT service change management, most commonly thought of as ITIL’s Service Transition change management process (e.g. I am changing this production server), or
- project scope change management (e.g. this project should now implement version 3.0, rather than version 2.0).
IT people commonly use “change management” to refer to IT service change management. IT service change management developed from the realization that IT systems are very complicated, and a change to one component can dramatically affect other components.
IT systems require many different roles working together to set up the system and maintain it: a data center manager for the physical location, a systems administrator for the operating system, an application administrator for the application, a database administrator for the database, a storage administrator for the storage area network (SAN) storage, a network administrator for the network. Many other roles are involved too–perhaps a service level manager to negotiate the service level and the Service Desk to provide helpful customer support when things break or new service is ordered.
What’s more, all these complex technical components can dramatically affect one another. A server’s TCP keepalive setting may need to change based on the network firewall’s timeout setting. A database’s configuration can affect how backups need to be conducted. Or as a basic example, a systems administrator cannot do a network-dependent server upgrade if the network team is upgrading the network.
IT service change management is intended to help people think about how their change might affect others. The change management process is intended to evaluate the risk of a change and to get other people’s eyes on the change to make sure it doesn’t have any unintended consequences. The IT security manager can review whether a network change might introduce a new vulnerability, for example. The storage administrator can review whether the disks will fill up.
According to the Visible Ops handbook, almost 80% of outages are due to change. The better changes are understood before they are implemented, the less likely changes will introduce outages or other unplanned events.
Documented changes also let you see how a system has changed over time, review the changes that happened at a particular time, learn from past changes to inform future changes, and otherwise better understand and learn from the IT environment.