Change Management Process Suggestions
By Rich Mach

How comfortable are you that what is enabled in the Test system at your site behaves exactly as it does in the Production system? Is your site "the Wild West" where rogue analysts are making changes on the fly in (gasp) Production? Do you still have VSAM items in test status from the guy who left five years ago? Have you reached the point where you are only comfortable performing VSAM transfers on Tuesday to give yourself enough time to clean up the ensuing fallout before the weekend begins? If the above remotely describes the current situation at your site, it is time to implement a change management process or revisit the process your facility already has in place.

Following is a three-level Change Management Approval process. Perhaps this framework can be the basis or starting point for a new or revamped process at your facility.
NOTE: These processes do not necessarily impact emergency changes. They should follow a separate approval process based on the severity and impact of the issue.

Self Approval

This would consist of the analyst following a set process to move simple changes into production. An example of the types of changes that fall under the self approval heading would be: minor changes to profiles, minor look and feel changes to a single screen, changes and additions to ad hoc reports, regular maintenance of the service master etc…, and minor document routing changes. These approvals can be done at any time other than Friday Afternoon.

Manager Approval

This process involves a manager review of the build and its potential impacts to the customers and systems. An example of these types of changes includes, but is not limited to, more advanced logic changes to screens, TCLS and other types of modules, changes brought on by SUP applies or minor interface changes.

CAG (Change Approval Group)

This group should consist of the MIS Manager and any other MIS management appropriate, at least one representative of the user community, and a representative of the "hospital management group". This group meets weekly - I would suggest on Tuesday or Wednesday morning - to discuss and approve larger changes and review upcoming downtimes. A list of changes and downtimes to review should be in hand by noon Monday. This allows for plenty of time for the items to be moved to production and the ability to deal with ramifications prior to the weekend. The types of changes included for review could include, but are not limited to, the following: major pathway changes, multiple module changes, major changes / additions to interfaces, and new application installs. In my experience, these meetings usually only need to last half an hour or so.

Process Design:

At the conclusion of build testing, the approval process starts.

For Self Approval the process is as follows:
The impacted customer group is notified of the impending change. This should not be the first time the customer has heard of the modifications.
After the customer group has indicated approval, the change is made in production.
The change date and time is documented in the build documentation.
The MIS group is notified of the change date and time. This may help in issue trouble shooting. This should not be the first time the MIS group has heard of the change.

If the Manager Approval process is used, the process is as follows:
The analyst discusses the change with the MIS Manager.
The Manager approves the change and documents the change approval date and time in an e-mail to the analyst.
The impacted customer group is notified of the impending change.
After the customer group has indicated its approval, the change is made in production.
The change date and time is documented in the build documentation. The Manager Approval e-mail should be placed in the documentation as well.
The MIS group is notified of the change date and time.

If it is necessary to get CAG approval, the process is as follows:
The change request is submitted to the CAG via e-mail 24 hours prior to the group meeting. This request should include the name of the analyst doing the move, the impacted customer group, the how and whys of the change (with minimum detail), move date and time, risk assessment, back out plan, and communication plan.
The CAG will then discuss the change at their weekly meeting. The analysts with items to review should be present to answer any questions that may arise.
If the group approves the change, an e-mail is sent with the approval date and time to the analyst for documentation.
d)The impacted customer group is notified of the impending change.
e)After customer group has indicated approval, the change is made in production.
f)The change date and time is documented in the build documentation. The CAG Approval e-mail should be placed in the documentation as well.
g)The MIS group is notified of the change date and time.

If your facility has no, or a very loose, Change Management Approval process, the above may seem like cumbersome and needless overhead. However, the biggest hurdle is the upfront work of establishing your process and putting your process in place. Consider how much extra work is truly represented by backing out changes, re-analyzing pathways and (again) presenting yourself and your changes to the effected department. Now consider the credibility you and your team stands to gain by implementing hospital-wide changes in a consistent way with little or no impact as opposed to implementing changes by "flying by the seat of your pants".