Change control

From Wikipedia, the free encyclopedia

 This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (September 2007)

Change control is a general term describing the procedures used to ensure that changes (normally, but not necessarily, to IT systems) are introduced in a controlled and coordinated manner. Change control is a major aspect of the broader discipline of change management

A change is “an event that results in a new status of one or more configuration items (CI's)”.

Change control aims to ensure that all changes are assessed and approved by management before their implementation. Its goals are:

  • Minimal disruption to services
  • Reduction in back-out activities
  • Economic utilization of resources involved in implementing change

Change control is a formal process used to ensure that a product, service or process is only modified in line with the identified necessary change. It is part of ITIL. It is particularly related to software development because of the danger of unnecessary changes being introduced without forethought, introducing faults (bugs) into the system or undoing changes made by other users of the software. Later it became a fundamental process in quality control. A change "freeze point" was introduced to suspend any further changes until after the completion of the initial project. Change Control is also formally used where the impact of a change could have severe risk and/or financial consequence. Typical examples from the computer and network environments are the upgrade of operating systems, network routing tables or the electrical power systems supporting such infrastructure, not forgetting changes to the contract itself. George Brilis et al. have published a paper which provides a guidance of development and implementing the policy on the integrity of recordkeeping systems [1]

Contents

[edit] The process

There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others.

Change Control today is seen to be a set of six steps. Each step may have another process associated with it. These start with the receipt of the Request for Change or RFC, or a Request for Service (RFS):

  1. Record / Classify
  2. Assess
  3. Plan
  4. Build / Test
  5. Implement
  6. Close / Gain Acceptance.

A formal request is received for something (usually in the Client's [contract]) to be changed, known as the "Change Initiation". Someone then records and classifies or categorizes that request. Part of the classification would be to assign a Category to the change, i.e. is the change a "major business change", "normal business change" or "minor business change". The first category would be immediately liable to a CAB (see below for references to CAB's). Then it would be necessary to assign a priority to the change, i.e. "emergency change", "expedited change" or "normal change". The first would be already completed in reality with the change being done retrospectively (An Emergency CAB may have been involved too).

The second implies that it needs doing within the SLA (Service Level Agreement) times. The last is business as usual. Finally either here or at consolidation, the Impact Level needs to be decided, i.e. is this change going to have a "major", "normal" or "minor" impact on the business. The first should go to a CAB.

The classifier then decides upon who or whom should be invited to make an impact assessment. The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the IT estate, and follow this by making a judgment on who or whom should carry out the Change, typically known as an SDU team (Service Delivery Unit).

If more than one Assessment has been carried out, it should be the job of the Change Manager or Change Administrator to consolidate or summarize these, as at this point they may decide or have it decided by policy to have the first CAB, or Change Advisory Board meeting to ascertain that there is a business justification for the change. Afterwards the decision on the technical justification can be carried out. The change is then sent to the new Change Owner or CO.

This will be an SDU team who have been identified or pre/identified as having a major role in carrying out this particular type of change. The SDU's first job is to plan their change in detail, and also construct a regression plan, if it all goes wrong. The Plans and the Build should be according to ITIL standards checked out by an independent reviewer, of course this is optional and would depend on the nature and scope of the change. If their plan is agreed (this could be another CAB), then they will build their solution, which will then be tested. They will then seek approval (and as stated maybe a review) and request a time and date to carry out the implementation phase.

They may do this by raising a flag called a Request to Implement flag (RTI). This is then answered by the Change Manager when this is approved (by another CAB) with an Authority to Implement flag (ATI), the Change can then be implemented but only at the time and date agreed. Following Implementation, it is usual to carry out a Post Implementation Review (PIR) which would take place at another CAB meeting.

When the client agrees all is OK, the change can be closed. The various CAB meetings would of course be one meeting charged with looking at all changes in their various phases and agreeing that they may proceed or not, as the case may be. The information for the CAB's would be obtained by interrogating the Forward Schedule of Change (a database of the changes).

[edit] Roles of involved people

The following roles have been identified in the Change Control process:

  • Change Initiator (CI) - The Person who initiates the request and who ultimately will confirm its completion.
  • Change Sponsor (CS) - The Person who gives business approval for a change.
  • Change Administrator (CA) - One or more Change Administrators carry out initial categorization and assessment, monitor progress of the change requests through the change Owners and ensure acceptance.
  • Impact Assessors (IA) - Relevant people who assess the impact of the change
  • Change Owner (CO) - Typically the person who is allocated to a change and who manages it through to acceptance and closure
  • Change Manager (CM) - The Change Manager manages the overall change process, acts as a point of escalation for COs, exercises judgment in assessing requests and escalates to a Change Board. The CM also acts with authority delegated by the Change Board to drive emergency changes or expedited changes through the system
  • Task Owners (TO) - Task Owners are assigned specific tasks by the Change Owner and own them through to completion. The system supports supervision of assigned tasks
  • Change Advisory Board (CAB) - An appropriate management Board used to review the change process and specific changes where required. Typically comprising Service Delivery Manager, Customer representative & Change Manager

[edit] Notes

  1. ^ George, Brilis et al. (2005). "Implementing and Auditing Electronic Recordkeeping Systems Used in Scientific Research and Development". Quality Assurance: Good Practice, Regulation, and Law 11 (1): 5 - 24. Taylor and Francis Ltd. 

[edit] See also

[edit] External links