social media, communication in the global computer networks. silhouette of a human head with an interface icons.
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
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.ent 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.
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.
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.
