Dundalk Institute of Technology Change Control Procedure

Transcription

1 Dundalk Institute of Technology Change Control Procedure 1

2 Revision History Date of this revision: 07 Dec 2015 Date of next revision: 07 Dec-2016 Revision Number v1.0.1 Revision Summary of Changes Date 07/12/2015 Formalising release version of document Changes marked Approval This document requires the following approvals: Name Title Date James McCahill IT Strategy Manager 07/12/2015 Michael Denihan Computer Services Manager 07/12/2015 This Change Control Procedure will be reviewed on a periodic basis. 2

3 Table of Contents 1. PURPOSE ROLES AND RESPONSIBILIES DEFINITIONS SCOPE CHANGE CONTROL PROCESS APPENDICES... 8 Appendix I - Change Control Form

4 1. PURPOSE The purpose of this Change Control Procedure is to outline how changes to software & hardware infrastructure and critical configurations at Dundalk Institute of Technology are to be managed. 2. ROLES AND RESPONSIBILIES IT Manager To monitor compliance with the Change Control Procedure in conjunction with the business process owner, and technicians responsible for designing and implementing the change. To inform the Vice President for Financial and Corporate Affairs of suspected non-compliance and/or suspected breaches of the Change Control Procedure. 3. DEFINITIONS Change A change is any technical or functional amendment, which has the ability to impact positively or negatively on Dundalk Institute of Technology system performance, operations and functionality. Change Control Change control in the context of Information Technology (IT) is a formal process used to ensure that changes to hardware, software and facilities are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced and/or authorised changes will be introduced in an uncontrolled manner introducing unnecessary system issues. In summary, change control is the process by which the application of changes is managed in order to identify and eliminate any potential adverse impacts. 4. SCOPE This document outlines the procedure to be applied for the following types of change: Installing new hardware or software; Upgrading hardware or software; Reconfiguring, changing or upgrading facilities e.g. power, network Standard periodic maintenance Configuration changes which have the potential to significantly affect service e.g. firewall, router etc. 4

5 5. CHANGE CONTROL PROCESS While specific procedures will vary depending on the nature of the change, for example procedures for installing new hardware will vary from procedures for installing new software, the following change control process need to be applied to a greater or lesser extent to all change types: Change Request: ID, Initiator s name, Date, Description of change, Reason for change. Requirements Definition & Planning (RPD) Technician Change Request Reject Review impact on, business areas, IT Services, IT Infrastructure, technology. Assess risks, fall back plans, urgency Impact Analysis (IA) STO Accept Reject Consider timeline, resource requirements, impacts, costs, communication requirements, contingency Change Planning Meeting (CPM) IT Manager STOs Fallback Accept Reject STO and/or Technician to negotiate approval with business unit Change Sign Off (CSO) Business Owner Detail & resolve constraints and conflicts. Ensure resource availability. Identify costs. Detail test plan, communication plan, risk mitigation plan, fall back plan. Produce & walk thru detailed time schedule for the implementation. Accept Detailed Change Implementation Plan (CIP) STO &Technicians No Consider detailed implementation plans Go/Nogo IT Manager Heads of Schools, Functions & Departments Yes Update Documentation STO & Technicians Implement Change STO & Technicians Review actual timeline. Produce root cause analysis for problems. Publish change report with findings & recommendations. Post Implementation Review (PIR) STO Post Implementation Report STO 5

6 Step Description Comment 1. Requirements Definition and Planning (RDP) 2.Impact Analysis (IA) 3. Change Planning Meeting (CPM) Change Sign Off (CSO) The requirement to install or upgrade hardware, software or facilities is identified. This includes the notification and or identification of system software patches which could be applied. In relation to the latter the Computer Services Department (IT Department) need to determine if and when such patches would be applied and need to plan accordingly. In relation to hardware, software or facilities installation/upgrade the relevant business owners need to be made aware of the reason for the installation and/or upgrade, need to agree to the change, to the timing of the change and finally need to be clear on the requirement for their involvement in terms of verifying change. Planning should also include development of relevant rollback procedures. Following on from the initial identification of the need to install/upgrade/patch IT department need to perform an IA to a sufficient degree of precision to allow them to determine the level of testing which needs to be performed. The CPM is designed to bring together IT Management to consider the implications of the change proposed across the entire IT and Institute spectrum Technicians proposing the change will present the proposed change to the business process owner to ensure the business owner agrees to proceed with planned change. Depending on the complexity of the installation or upgrade, requirements definition and planning should be formalised to a greater or lesser degree. The more complex the change the more clarity which needs to be brought to the change control process through documentation. Appendix I provides a templates for changes which should be completed for all changes and which should be supported by appropriate levels of documentation depending on the complexity of the change. The template for change (Appendix 1) includes an IA section to allow details of the IA and outcome of same to be documented. Again the level of detail is dependent on the complexity of the relevant change. The CPM should consider the proposed timeline and any other constraints which might arise such as resource conflicts, cost, impacted systems, the communication needs and required contingencies. Having considered the proposed change and had the opportunity to hear and question the technical rationale, risks and plan, the business owner will formally 6

7 3.Change Implementation Plan (CIP) It is the responsibility of the IT department and/or relevant business users to ensure that there is a detailed CIP produced and communicated to convince the Institute Management that the appropriate level of testing, planning & communication has been undertaken before approval is given for the change to be applied. sign off that the business is agreeable to needs the change. Constraints & conflicts must be resolved and a deliverable plan & timeline must be identified which minimises the impact and risk to the business. All timings should allow for the activation and implementation of a fall back plan should it prove necessary. 4.Go/Nogo 6. Update Documentation Post Implementation Review (PIR) The relevant business heads and process owner(s) in consultation with the IT Manager needs to approve implementation of the change Following successful upgrade the relevant specification listing held at Dundalk Institute of Technology should be immediately updated. The final step should be to communicate the successful completion of the installation/upgrade to all those affected. For significant installations or upgrades the technician/sto should convene a PIR within a week of the implementation to consider the learning from the change. High level presentation slides should be produced to support the request for sign off. Refer to Appendix I for change templates where this approval can be formally indicated. Where the change (for example software upgrade) was applied on a test server as well as a production server the specification listing should be updated in a timely manner. PIR should review timelines, positives, negatives, resource issues, communication issues. Root cause analysis should be carried out where problems were encountered. Change owner (STO or Technician) should document and circulate the PIR to technician & management involved with or impacted by the change. 7

8 6. APPENDICES Appendix I - Change Control Form Change Control Form (v2) Change Request Number (Helpdesk Ticket Number) Name of Requestor Is this a new installation, upgrade, configuration or removal? If upgrade, replacement or removal provide name and location of existing. Detailed reason for installation or upgrade Summary outline of work to be carried out. (Attach relevant documents if required) Name of business owner Impact Assessment (What systems or services impacted?) Testing performed and outcome of testing (attach relevant documents) Proposed timing Communications Schedule 8

9 Implementation plan & procedure (attach relevant documents) Rollback plan & procedure in the event of problems (attach relevant documents) Business owner approval for change to production environment Signature: Date: IT Manager Approval for change to progress Signature: Date: Detail of Post Implementation Verification Testing performed and relevant outcome IT sign-off on completion of change (IT Technical Staff) Signature: Date: Documentation updated & filed (list documents updated) Signature: Date: 9