Creating a Change Management Process in a few Simple Steps

Whether you employ a “best of breed” philosophy or stick to a single, integrated system, coordinating and communicating the changes that will occur in your production environment are a critical part of running a good IT department.  Manage your changes well, and you have smooth sailing.  Fail to manage them, and you can have some pretty rough seas.  Shockingly, the majority of all CIOs admit that they don’t have a change management process they feel comfortable with.

In this article, we’ll present one sample approach to Change Management.  And if your current Change Management process isn’t exactly what you would consider acceptable, perhaps our approach can be a good start for you.  You don’t have to have an overly complicated process – just a well communicated one.

Let’s begin with an explanation of Change Management.  Change Management consists of several key components: documenting and understanding all changes that need to be made in your production environments, insuring that one change doesn’t interfere with another change or create a negative impact with current setup, communicating the upcoming changes to the user community, executing the changes, and validating their success.

Failing to follow a good change management process can cause you grief in many different ways.  For example, if you fail to communicate a much needed change going into production, your user community will not be prepared, and what should have been a nice “fix” will turn into some bitter feelings from your users.  Another common side effect of poor change management occurs when changes are made to one system, such as table values changing without making the same changes in your downstream systems.  Interface rejections and delayed service can leave a nasty mark.

Here’s a step by step approach to building a workable Change Management process:

1. Assign a Change Management Coordinator (CMC).  This person will be the center point for communications and will coordinate and facilitate your Change Management meetings. 
2. For the sake of this sample approach, we’ll assume that changes are migrated to production weekly.  We’ll also assume that you have system owners (analysts) who manage or oversee your various systems – pharmacy, lab, radiology, ADT, etc.
3. Every week, each system owner must submit, on TUESDAY, the changes they intend to migrate to production the following week.  Any and all changes should be included – changes to the dietary system, changes to your ADT module, new reports, additions to your order table, etc. 
4. On WEDNESDAY, your CMC will validate and compile all changes in a log and distribute to all system owners, as well as to the Interface, Help Desk, and Operations Managers.  A sample “log file” can be found below.
5. On THURSDAY, your CMC will facilitate the weekly Change Management meeting with all system owners to discuss each change, and allow the group to validate that there will be no negative interactions or outcomes.  During this meeting, any discussions of downtime or sequencing of migrations will be determined, as well as a plan for how each system owner will validate that the changes were successfully completed.  In addition, if the team identifies a change that may cause potential negative impact, the team should reject the change, request a review/revision, and reconsider it during a later meeting, when a higher confidence level can be reached.
6. Following the meeting, communications will be prepared and sent to the hospital user community, notifying them of the upcoming changes.
7. On FRIDAY, the CMC publishes the final list to the system owners, Interface, Help Desk, and Operations.
8. On TUESDAY of the following week, the changes are migrated.  System owners will be notified so they can validate the success of the migration.  *Migrations are done on Tuesday to allow the remainder of the week to remedy unexpected problems.
9. The CMC will maintain a very careful log of all changes for easy referral of problems back to a particular migration.

SAMPLE CHANGE LOG FILE

As you can see, this process can occur weekly or bi-weekly, depending on the frequency of your changes.  We suggest you select a CMC that will adhere to times and deadlines, keeping your process on track.  With each passing week, your team will become more familiar with the process and with the changes that occur in all the systems.  And your user community will be extremely grateful to be so well informed of the upcoming changes.