Develop an IT Change Management Program

Change Management Program (CMP), more commonly known as Change Control Process or Change Control Management Process, is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner (as defined by ISO 20000). CMP should not be confused with Organizational Change Management (OCM), which manages the impacts of new business processes, including those stemming from system roll outs and IT initiatives, changes in organizational structure, or cultural changes within an enterprise. In short, OCM manages the people side of change.

The purpose of the CMP, is to ensure that the negative impact of changes to a company’s Information Technology system is minimized by using a standardized process of governance. Some changes are not optional. If, for example, the bar code standard is changing, you must adapt; if a tax withholding structure changes, you must have a change. Nevertheless, all changes of this kind are still subject to governance.

It must never be the case that ad-hoc changes are made to the system or to procedures without some oversight. This idea must originate with senior management and be passed down, with no exceptions, to everyone in the company. Without backing at the highest level, the CMP is a useless waste of time and money. With proper backing, this program will save your company from some very costly errors.

Steps

  1. Develop a Request for Change (RFC): This may originate from problem management where an issue, or a series of related issues, is identified and a mitigating change is necessary to prevent (or minimize) future effects. The RFC may also originate as a result of a business decision that will require some modification (add, delete, change) to the supporting technology. An RFC may also be necessary due to outside influences (i.e. governmental regulations or changes made by business partners).
  2. Obtain Business Change Acceptance: The decision to make a change is typically a business decision where costs vs. benefits are weighed. Even in situations where the change is strictly infrastructure oriented (component or system failure) the decision to spend money resides with the business, not with the IT department. There are occasions when procedures are developed in advance to preauthorize changes such as emergency system maintenance, but regardless of the timing of the authorization, the decision still rests with the business management.
  3. Initiate the Development Project: Development of the change (including testing) is an IT-guided function. In the event of an emergency change (server is down) those functions are typically predetermined. When a new system is to be developed, there is a collaborative effort between the business users and the IT team. The systems are designed by IT, the design is approved by the business partners (users), developed by IT, tested by a combination of IT and the users, and the final product is approved by both. Careful attention must be given to ancillary effects the new change may have on existing systems.
  4. Pass the Change Management Gate: The Change Advisory Board (CAB) reviews all changes before they can be put into production. Normally, the CAB will consist of a group of people with different perspectives, backgrounds and areas of expertise. Their function is to review the change from a process and governance standpoint to assure that all foreseeable risks have been identified and mitigated, and that compensatory techniques are in place for any elements of exposure (things that could go wrong). The development team and the change sponsor will present the change to the CAB. Evaluation of risk will be the focus. Implementation strategies, communication to affected stakeholders, backup plans and post-implementation monitoring are elements on which the CAB is required to focus. The CAB is not responsible for determining if the change is appropriate – that decision has already been made. The CAB is also not responsible for determining if the change is cost effective. Again, that is strictly a business decision.
  5. Implement the Change: If the CAB does not approve the change, the reasons are listed (this is always because certain risks have not been mitigated or communications have not been planned) and the development team will be given time to fix those issues and reschedule a meeting before the CAB. If the change is approved, the implementation is scheduled. It is not normally the case that the CAB is represented at implementation although it is possible that some members of the CAB have expertise that is necessary during the implementation, but they will not be present as official CAB representatives, but rather as subject matter experts (SME). How the change is implemented, the checklist and steps, are predefined and were presented to and approved by the CAB. The entire process must be thoroughly documented and the approved process must be precisely followed.
  6. Report the Results: Either the change was implemented successfully with no issues, the change was implemented with issues that were corrected during implementation, the change was implemented with issues that were deemed acceptable, issues arose that were unacceptable and the change was rolled back, or in the worst case the change was implemented with unacceptable issues and could not be rolled back. Whatever the result, that is documented and returned to the CAB. The CAB is then responsible for distributing that information to the stakeholders and for storing and maintaining those results in the Change Management system (that may either be an automated database or a paper filing system, but the documents must be maintained for audit purposes).
  7. Link Problem Management to Changes: Issues that arise should be compared to the CAB documentation of changes so any unanticipated adverse effects of a change can be isolated. It is often the case that undesirable effects of a change are not noticed immediately, but are identified by the emergence of problems in ancillary systems. For example, the addition of several fields to a database might not have a direct negative effect on the users but could impact network performance that would be apparent to other users who are not directly involved with the modified system.
  8. Periodically Audit the CMP: At least once each year an audit of the CMP should be conducted to assure that all change documentation is maintained and available. Every change approval document should be examined to assure that the proper signatures are in place and that the results of the implementation are properly documented.

Tips

  • Standard periodic maintenance should be preapproved. If it is a normal process to reboot a server on Sunday morning at 2:00 AM, it is not necessary to submit an RFC each time, but that process must be approved in advance.
  • Ad-hoc maintenance must adhere to the CMP. Include such things as testing the fire suppression systems, cleaning sub-flooring in the data center, HVAC inspection and testing and even pest control maintenance. Some companies go so far as to require an RFC if a light bulb is changed in the data center (the ladder fell and damaged the network).
  • Procedures should be subject to Change Management. If there is a change in system backup scheduling, that must go through Change Management. Analyze every change of any kind (system or procedure) to determine if there is any possible risk.

Warnings

  • Rotate CAB members frequently. Always having the same members can lead to favoritism, and it can lead to burnout. You want your CAB to be fresh, pay attention, and not be subject to outside political influences.
  • Politics can often get in the way of the CAB. "This change is required" may be true, but it could also be a personal agenda from one of the executives. The CAB must have ultimate authority to make decisions on implementation.

Related Articles

Sources and Citations

Retrieved from "https://kipkis.com/index.php?title=Develop_an_IT_Change_Management_Program&oldid=296086"