Home    ITIL  Index

Change Control vs. Change Management: Moving Beyond IT


Mar 14, 2005
By

ITSM Watch Staff





By Edward Stickel

Towards a Solution
With the renewed attention on "best practices" and Service Management, many IT organizations are recognizing that the complex impact of infrastructure changes extend across many enterprise groups. With this recognition comes the realization that infrastructure changes need be managed not simply controlled.

In fact, change control is an important but subordinate procedural component of a robust change management process. The additional significant components, the "secret sauce" of change management that makes it effective are procedures that emphasize assessing the business impact and ramifications of a change and the communication and coordination activities involved in evaluating, approving and implementing a change.

The broader goal of change management is to ensure that the service risk and business impact of each change is communicated to all impacted and implicated parties, and to coordinate the implementation of approved changes in accordance with current organizational best practices. The result of effective change management is that changes are handled quickly in a uniform way and have the lowest possible impact on service quality.

The British Standards Institute in its Code of Practice for IT Service Management defines the scope of change management to include the following process steps:

  1. Recording Changes
    In practice, the basic details of a change request from the business are recorded to initiate the change process, including references to documents that describe and authorize the change. Well-run change management programs use a uniform means to communicate the request for change, and work to ensure that all constituencies are trained and empowered to request changes to the infrastructure.
  2. Assessing the Impact, Cost, Benefits, and Risks of Changes
    The business owner of a configuration item (i.e., a CI in the Configuration Management Database which records the exact state of the IT infrastructure) to be changed (e.g., IT for infrastructure, Finance for a Billing application, etc.) and all affected groups (e.g., users, management, IT, etc.) are identified and asked to contribute to an assessment of the risk and impact of a requested change. Through this means, the process is extended well beyond the IT department and draws on input from throughout the organization.
  3. Developing the Business Justification and Obtaining Approval
    Formal approval should be obtained for each change from the "change authority." The change authority may be a person or a group. The levels of approval for each change should be judged by the size and risk of the change. For example, changes in a large enterprise that affect several distributed groups may need to be approved by a higher-level change authority than a low risk routine change event. In this way, the process is speeded for the routine kinds of changes IT departments deal with every day.
  4. Implementing the Changes
    A change should normally be made by a change owner within the group responsible for the components being changed. A release or implementation plan should be provided for all but the simplest of changes and it should document how to back-out or reverse the change should it fail. On completion of the change the results should be reported back for assessment to those responsible for managing changes, and then presented as a completed change for customer agreement.
  5. Monitoring and Reporting on the Implementation
    The change owner monitors the progress of the change and actual implementation. The people implementing the change update the configuration management database proactively and record or report each milestone of change. Key elements of IT management information can be produced as a result of change management, such as regular reports on the status of changes. Reports should be communicated to all relevant parties.
  6. Closing and Reviewing the Change Requests
    The change request and configuration management database should be updated, so that the person who initiated the change is aware of its status. Actual resources used and the costs incurred are recorded as part of the record. A post-implementation review should be done to check that the completed change has met its objectives, that customers are happy with the results; and that there have been no unexpected side-effects. Lessons learned are fed back into future changes as an element of continuous process improvement.
As the above process makes clear, true change management differs from change control in the depth of its overall process scope and in the range of inputs it uses. Where change control ensures that changes are recorded and approved, change management considers overall business impact and justification, and focuses not only on the decision to make or not make a given change, but on the implementation of the change and the impact of that implementation as well.

Where change control chiefly takes into account the IT perspective on changes, change management draws information from and relays information to constituencies throughout the organization at every step of the change process.




Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Most Popular