The art of making sure everything doesn't happen all at once. Most often, change management addresses code and/or systems changes - upgrades to operating systems, moving networking cables from one device to another, pushing a change from testing to production, and other similar things can all be found in the bailiwick of change management.

On the back end, this process means written plans of all events happening. Frequently, change management will limit these events, or certain types of these events, to a single time period which is communication to external customers (any clients your company may have) and internal customers (anyone inside of your company impacted by these changes). In order to qualify for this type of procedures, most events must meet certain criteria.

These include:

  • They must run the risk of negatively impacting production (where the work gets done) systems.
  • They must be more than unusually dangerous than your average small changes. Setting up a new server, unless this server is going to manage how the network works, or how other servers do their jobs, usually doesn't qualify.
  • They must be reviewed and approved by a qualified team of peers, managers, and coordinators

Frequently, custom interfaces or types of trouble ticketing (such as Jira, Remedy, or other systems) are used to keep change control items from mixing with the ordinary workday system. These items are then gathered and discussed, frequently in meetings, by all stakeholders. This may include groups as small as the engineer performing the action and a customer liaison, and as large as every technical manager and member of the engineer's team.

Change management may also involve custom calendars displaying all events for a particular length of time, engagement to a NOC in order to delegate monitoring and response staff, and use of other engineers whose role involves making sure the event goes smoothly and that any unexpected impact can be resolved as soon as possible. These are frequently considered shit jobs for those working the events.

Due to the fact that most people work from the hours of 9am-5pm, most change management happens after hours. This means whoever is upgrading Windows on your file server, or the configuration on your firewall is going to be at work until probably late in the evening, if not until 5am in the morning. Typically, the worse the impact, the later the changes will be made, meaning that some work gets done as the sun is coming up. Often this is delegated to a night shift.

Log in or register to write something here or to contact authors.