University of Bedfordshire ISD Change Management Policy

Transcription

1 1 Introduction 1.1 This paper documents the Change Management Policy that is used within the Information Services Directorate (ISD) in the University of Bedfordshire, as part of the Service Support process within Service Management. The policy is applied to all Requests For Change (RFC) that have been raised, which will result in changes to the configuration of one or more systems or services. 1.2 A Change is defined as the process of moving from one defined state to another. Change Management is responsible for managing the Change process involving: Hardware System software Live application software Communications equipment and software Documentation and procedures associated with the running, support and maintenance of live systems. 1.3 The Change Management process does not extend to development environments, for which the respective development team assumes responsibility for the changes to these environments or systems. The Change process will however cover Test environments, when these are available to users to test out their own local business processes. 1.4 The process consists of a number of defined steps, which are described in this policy document: i) Request for Change ii) Impact Assessment iii) Approval iv) Implementation v) Post Implementation Review Request for Change Initial Assessment Change model scope Major Change Log Seek Approve Seek CAB Build Estimate Approval etc Scope of Change? Apply appropriate Change model Implement as defined in model Moderate Change Minor Change Standard Change Log Approve All actions Update CMDB Build Test Implement etc. Figure 1. Change process model UoB_Change_Management_policy.doc Page 1 of 8 31 Jan 2007

2 1.5 Figure 1 outlines the Change process model to be adopted. An initial assessment will be carried out to identify the scope of the Change, and therefore the appropriate detailed model to be applied. Separate models will be developed for the various services and systems supported by ISD, as the details will vary considerably according to the requirements of the users and owners of each system. 2 Request For Change (RFC) 2.1 As soon as a requirement for Change is identified, usually as a result of a Problem investigation, but may be due to an external driver (e.g. supplier advice), then a Request For Change (RFC) is raised. An example of the information required in the RFC is provided in Appendix The RFC will undergo an initial assessment by the Change Manager, working with the originator, to determine the scope of the Change. The appropriate Change model will then be identified and applied. 2.3 Three categories of Change models are defined Major, Moderate and Minor. The application of the particular model to a RFC will depend on the system or service being changed, as the potential impact of the Change will vary across the services. 2.4 Major Change A Major Change will potentially have an impact on the whole university and is therefore subject to the most detailed analysis and planning. Authorisation for the Change will be provided by the appropriate senior management, in consultation with members of the Change Advisory Board (CAB). Examples of a Major Change may include: Key system upgrade (e.g. Student Record System, Finance System), server reconfiguration, Student Record System data structure reconfiguration. 2.5 Moderate Change A Moderate Change will have a more limited impact, but may cause a service impact or procedural change to a number of users across the university. The RFC will be referred to the Change Advisory Board, whose members will be representative of the key users of that service. The CAB will advise the Change Manager, who will ultimately authorise the Change and co ordinate the implementation. Examples of a Moderate Change may include: a Hotfix installation, SRS data changes affecting reporting, minor desktop reconfiguration, telephone voic enhancements. 2.6 Minor Change A Minor Change can follow a standard change process which follows an established path, is relatively common and is the accepted solution to a specific requirement. Key elements of a standard change are: Tasks are well known and proven, Authority is effectively given in advance, Train of events can usually be initiated by the Service Desk. Examples of a Minor Change may include: setting up a new user on the SRS, replacement of a user PC, changes to Auto Attendant telephone messages to meet end user requirements. UoB_Change_Management_policy.doc Page 2 of 8 1 July 2008

3 2.7 Change Advisory Board (CAB) The CAB will be chaired by the Change Manager and consist of representatives of the business and user community. The precise constitution of the Board will vary according to the system or service to undergo the Change, and therefore the user community impacted. The members will be able to assess the Change from both a user and technical viewpoint, and therefore recommend to the Change Manager the appropriate prioritisation and Release timetable. The CAB will be responsible for approving all Moderate and Major Changes. It will not be required to consider Minor Changes. It may not always be necessary for formal meetings to take place to approve every Change. This is particularly true for Emergency Changes, which may be needed urgently to address an immediate problem. In this case, approval may be given by e mail from the appropriate parties. 2.8 Emergency Changes Where an Emergency Change is required, the Change Manager may consult with nominated select members of the normal CAB for that service. The service owners will determine who the appropriate members will be to authorise such changes. An Emergency Change may be approved by these members. 3 Impact Assessment 3.1 An assessment of the impact of the change will be undertaken by the appropriate members of the CAB. The impact analysis will include the resources required to implement the change, financial implications, the communication that will be required to users, the timescale for implementation and any other factors that may apply to that system or service (e.g. capacity availability, provision of service continuity). 3.2 A Risk Assessment will also be carried out to identify the potential risks that may arise through the implementation of this change. 3.3 Reference will be made to the Forward Schedule of Changes to ensure that the impact of the change does not affect or is compromised by any changes to other systems or services. 3.4 The Impact Assessment will be reviewed by the CAB and approval advised to the Change Manager. 4 Approval 4.1 The Change Manager will approve the Change, under advice where necessary from the CAB, schedule the implementation date and update the Forward Schedule of Changes (FSC). 5 Implementation 5.1 The Change Builder will design and build the Change in accordance with the timetable agreed with the Change Manager. The steps involved in this process will be in accordance with the model used for this service, and will typically include the necessary test plans and back out procedures. 5.2 Testing will be carried out by the nominated independent tester for the service. In certain circumstances, for Emergency Changes, testing may be curtailed as agreed with the appropriate members of the CAB. UoB_Change_Management_policy.doc Page 3 of 8 1 July 2008

4 6 Post Implementation Review 6.1 Following completion of the implementation, the Change Manager will undertake a PIR of the release. The scope of this PIR will depend on the nature of the Change. For Moderate or Major Changes, the PIR will as a minimum consist of the standard ISD PIR report see Appendix 3. For Minor changes, a formal PIR is not required, but the Change Manager will record that the change has been implemented satisfactorily. 7 Relationship between Change, Release and Configuration Management 7.1 Figure 2 illustrates the relationship between Change, Release and Configuration Management, and the responsibilities of each process. Within the ISD, reflecting the close links between the two, the Change and Release Management processes will be combined into one. Change Management Release Management Configuration Management Request for Change Register and allocate RFC number Reports and Configuration audit to check environment Assess Analyse impact Reports on CIs, areas and parties impacted Approved Change Update CM records Implement Change This will involve prerelease testing where software changes are required Post Implementation Review Has change met expectations? Release and distribute new versions of software and hardware with documentation Baseline, release software from DSL and update DSL and CM records CMDB Definitive Software Library Close Change Analyse impact Check all CM records were updated End Figure 2. Change, Release and Configuration Management UoB_Change_Management_policy.doc Page 4 of 8 1 July 2008

5 8 Release Management 8.1 A Release is defined as a collection of authorised changes to an IT service. The size of the Release can vary, according to the service involved, and the number and complexities of the changes included with the Release. Likewise, the frequency of Releases across different services will vary. It is not possible, therefore, to define a detailed global Release policy that can be applied to every system or service. This policy outlines the key tasks within the overall Release policy. 8.2 The Release Manager will oversee the Release to ensure that only correct, authorised and tested versions of software are installed. The aim is to protect the Live environment and the integrity of the software. As with the Change Management process, the Release Management process will only cover Live and Test environments, where users may use the service to test operational processes. Development environments are not included in this policy. 8.3 A Release Unit is defined as a portion of the IT infrastructure that is normally released together. The size of the Release Unit will depend on the service affected. 8.4 Types of Release i) Delta Release This is a partial release which contains only those configuration items that have actually changed. This is the fastest and least costly release, but carries an increased risk due to the reduced opportunity for full integration testing. ii) iii) Full Release This contains all the components of the single Release Unit, whether they have changed or not. All components of the Release Unit will be tested to ensure that the changed items have no unexpected impact. Package Release A number of different Release Units are brought together to form a package. Each individual package may contain either Delta or Full releases, but full integration testing will be performed on all Units. The Release record will define which type of release is being made and will list the configuration items and release units that are being released. 8.5 The Release Manager will act as the librarian for the Definitive Software Library (DSL). This library contains the master copies of all software released on the University systems, together with the licence documentation (where applicable). The DSL may be a physical store, or a logical file directory, depending on the software required to deliver the service. The Release Manager is responsible for ensuring the integrity of the software contained in the DSL, and that only the latest, tested and authorised copies are released to the Live environment. 8.6 If changes to hardware are included in the Release, the Release Manager will co ordinate the movement of equipment from the Definitive Hardware Store (DHS). (The DHS is the location of the store of Hardware components which are the same as those used in the Live environment). UoB_Change_Management_policy.doc Page 5 of 8 1 July 2008

6 Appendix 1 Request for Change RFC Number Item(s) to be changed (include version number) Reason for Change Effect of not implementing change Person requesting the Change Date of Request for Change Priority Scope of Change Major / Moderate / Minor Impact and Resource assessment Authorised by Authorised date Implementation Plan Proposed Date of Release Release Plan prepared by Change Builder Back out Plan Actual date of change Review Date Review Results Impact on Business Continuity / contingency plan UoB_Change_Management_policy.doc Page 6 of 8 1 July 2008

7 Appendix 2 Examples of Changes Student Record System Major Change SITS Release upgrade Server reconfiguration URL address change Data structure re configuration (instigated by Planning) e.g. new Faculty Moderate Change Hotfix installation Changes to data which may affect reporting (Planning) Minor Change (standard change procedure applies) Request for new user set up User Password reset UoB_Change_Management_policy.doc Page 7 of 8 1 July 2008

8 INFORMATION SERVICES DEPARTMENT Appendix 3 Project Post Implementation Review Project Title: Project Manager: Objectives: (brief description of core objectives) Weights for all key objectives must total 100%. Key Objectives i) ii) Weight ( ) Score (for each key objective) 1 Not delivered 5 Fully delivered iii) iv) Average Score 0% Comments on Objectives Costs Budget Actual Variance Score ( percentage > budget) 5 < 10 % 2 40% 50% 4 10% 20% 1 >50% 3 20% 40% Capital: k k Comment on Costs Delivery Date Planned Actual Delay (Months) Score (months late) 5 On time m 4 0 3m 1 >12m 3 3 6m m Comment on Delivery Date Total Project Score 0.0 Completed by Date: PIR result Positive PIR >= 12 Negative PIR < 12 Lessons learned (for ISD circulation) UoB_Change_Management_policy.doc Page 8 of 8 1 July 2008