Is Your CAB Running Right?

Change control is not a new concept for Information Technology (IT) departments, but it is rarely working as smoothly as we would like nor is it meeting the intent of serving as the control point for production system changes. IT change control is the process of reviewing and staging changes or additions to live IT systems. The Change Advisory Board (CAB) is the group charged with managing an effective change control process. It differs greatly from organizational change management; a behavior-based effort for changing process or cultural norms in people or departments. The IT department’s Change Advisory Board (CAB) is more than just an approval body. In fact, for software additions or programming changes, it is not really an approval body at all; it is a triage and staging group.

The CAB should not be approving or denying the value or need for clinical, regulatory, financial or even productivity changes in healthcare software systems. These types of changes are not within the IT department’s sphere of knowledge or authority. The CAB provides the most value when it focuses on the IT role in those changes and serves as a final checkpoint ensuring the due diligence to complete plans and mitigate risks has been followed.

When CABs do not include the right people or look at the right aspects of changes, they tend to be “rubber stamp” committees or political stages for grandstanding. If your CAB rarely denies any requests or if leaders in CAB learn about changes that affects their staff for the first time in a meeting, you may want to take a critical look at your CAB’s effectiveness.

Successful CABs include leaders that can think longitudinally in areas that may be affected by a change and have a good working knowledge of their business partners’ needs. Analysts are great additions to a CAB to present individual changes and answer questions, but a CAB made exclusively of analysts will often fail to carry the authority to ask questions and push back when necessary. With the appropriate people in the meeting, the content of the meeting can be addressed.

Recommended inclusionary checks for the CAB include:

• Testing – Validation that proper testing has been completed and documented is essential. This includes testing of the new changes as well as regression testing of functionality already in the live environments. We inherently trust in computers and the information presented to us, and can fall into traps where an error in an automated workflow can be repeated many times more than a single lapse in an end user’s judgement or processes.
• Looking for Project Collisions – One large reason to deny a change is increasing risks and muddying the visibility to issue sources by changing connected or related systems at the same time. When possible, decrease risks by changing systems in series so that changes to one system may be validated and stabilized before other changes occur.
• Documentation – Not only is good documentation of the change control request and flow critical, but this point is also a good place to ensure project documentation (scope, decisions, resolved issues, risks, etc.), testing documentation, and any end user material has been completed. Make the change request documentation simple. Use checkboxes, drop down lists, or other simple tools. The goal is to ensure the project documentation is complete, not to recreate it in the change request.
• Contingency/Back-Out Planning – Unforeseen circumstances will occur. Computer systems will fail. People will make mistakes. If we blindly enter into changing production systems expecting 100 percent success all the time, we will eventually cause a crisis. Contingency planning should be a required component of any change.
• Communication and Training – Often, IT will not be the group crafting the end user documentation or communicating the details of changes made to software, but the CAB process provides a good checkpoint to ensure it has been completed, validated, and distributed.
• End User Readiness and Engagement – In our healthcare environments, change is rapid on both the clinical and technology fronts. A final check to make sure the intended persons affected by the change are ready, have been engaged along the way, and are not dealing with other organizational or critical patient issues is warranted.
• Defined Processes – Having both defined standard change processes and criteria for approval and submission of emergency changes is a must. Processes only work well when they are followed. If exceptions are the norm or leadership plays favorites, the process and the integrity of change control will break down.
• Standardization of Changes – One of the fastest ways to decrease end user confidence in a software system is for them to see it changing every time they log in. For non-emergent changes, choosing a standardized time when changes are bundled together increases the confidence in the system through predictable change windows.
• A Root Cause Analysis (RCA) Segment – Issues and mistakes will occur. It’s not about blaming and punishing staff for those mistakes; it’s about learning from them so they can be avoided in the future. A disciplined and formal RCA process used to review where errors occurred and develop processes to mitigate them in the future improves the IT department as a whole.

A well-run CAB with the right organizational leaders is a first step in creation of a proactive IT department. A proactive CAB is able to avoid issues and is ready to tackle the unforeseen problems with actionable plans. Take a critical look at your own IT department’s CAB process. Are you performing all of the checks above? Are you preventing issues or just sitting in another weekly meeting to be informed of all the changes that will occur? Revamping a change control process and those participating is not difficult, it just takes initiative and setting the right expectations for the group.