Change Advisory Board (CAB)



Contents TOC \o "1-3" \h \z \u Introduction PAGEREF _Toc386440062 \h 2Change Advisory Board (CAB) PAGEREF _Toc386440063 \h 2About PAGEREF _Toc386440064 \h 2Purpose PAGEREF _Toc386440065 \h 2CAB meetings PAGEREF _Toc386440066 \h 3CAB authorization/approval PAGEREF _Toc386440067 \h 4Rejection of a change by the Change Advisory Board PAGEREF _Toc386440068 \h 4Planning PAGEREF _Toc386440069 \h 5Approval PAGEREF _Toc386440070 \h 6Explanation of Change Types PAGEREF _Toc386440071 \h 6Retrospective PAGEREF _Toc386440072 \h 7Explanation of Change Priority PAGEREF _Toc386440073 \h 7Completing the Documentation PAGEREF _Toc386440074 \h 8Completion of the Request for Change Document (RFC) PAGEREF _Toc386440075 \h 8Definitions, Acronyms, and Abbreviations PAGEREF _Toc386440076 \h 12IntroductionNorthern Savings Credit Union is proposing the adoption of a Change Advisory Board to improve communication regarding, and implementation of, IT-related changes.Change Advisory Board (CAB)AboutThe Change Advisory Board (CAB) delivers support to the change management team by approving requested changes and assisting in the assessment and prioritization of changes.? The CAB helps ensure that changes are managed in a rational and predictable manner by enforcing standard change management policies and procedures.PurposeThis document provides guidelines on the operations of a Change Advisory Board (CAB).In addition, it describes what is expected of change owners presenting change requests to the CAB. All requests for change are presented to the CAB for approval prior to implementation.The IT Change Manager is responsible to ensure rigorous IT Change Management policies and processes are complied with across the organization in order minimize the risk that an IT Change negatively impacts the performance, operations or functions of the Northern Savings organization.CAB meetings are nominally open meetings that support remote attendance. In particular, CAB members and the Change Manager may invite attendees to all or part of any meeting.?? Also, each change will have an expert representative present at the CAB. Any present person can advise the Change Manager. The CAB meeting must, of necessity, be quick and professional.Northern Savings has identified that changes affecting any of the following areas must be presented via a Request for Change (RFC). Data CenterBranch / LocationDepartmentSoftwareHardwareNetworkTelecommunication In the event of a Request for Change that is in direct relation to a specific project the RFC process shall remain and reside within the agreed upon project charterCAB meetings CAB meetings either virtual or face to face should be called by the Change Manager at appropriate times to ensure the prompt and efficient handling of all changes. For complex, high risk or high impact changes, or when major projects are due to deliver products a formal CAB meeting be would be necessary. The meetings can then be used to provide a formal review and authorization of changes, a review of outstanding changes, and, to discuss any impending major changes. Where face to face meetings are appropriate, they should have a standard agenda. Relevant change information should be circulated in advance to allow CAB members to conduct impact and resource assessments prior to the CAB meeting. The CAB called by the Change Manager should consist of attendees who are relevant to RFCs being considered. This also includes attendees representing other groups or business units outside IT. Authorization at the CAB for each change must be given by appropriate representatives from all areas the change will affect. The CAB for a significant or major change will require representatives from the organization at a different level. It is the role of the Change Manager to ensure that those who are invited to participate in the CAB meeting are at the appropriate level in the organization as key decision makers. A standard CAB agenda should include:A review of all failed changes A review of all backed out changes A list of RFCs to be assessed by CAB members A review of all implemented changes The change management process – including any amendments made to the process, as well as proposed changes to the process (as appropriate) Change management successes for the period under discussion, i.e. a review of the business benefits seen as a result of the change management process (as appropriate)CAB considerations for each change (prior to authorization) Risk/impact assessment (on the business) Effect upon the infrastructure, performance, reliability and resilience, contingency plans, and security Impact on other services that run on the same infrastructure (or on software development projects) Resource assessment – the IT, business and other resources required to implement the change, covering the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required The impact on non-IT infrastructures within the organization Effect/risk/impact of not implementing the change Other changes being implemented on the schedule of change Technical capability and technical approval Financial approval (if required) Third party/supplier involvement in the implementation of the change Business approval (if required) Review/assessment of the change priorityCAB authorization/approval Once all aspects of the change have been considered (as per the CAB considerations for each change information above) the CAB will then give authorization for the change to progress for scheduling and into the change build stage of the process. The CAB is an advisory body only. If the CAB cannot make a final decision on the authorization of a change then the change escalation needs to be initiated by the Change Manager to ensure that authorization is given (via escalation) at a higher level. The escalation of change authorization is documented in the request for change – the Change Manager will detail to whom the change was escalated and the final decision that was made either authorized or rejected. Once a change has been authorized, the status of the change at this stage of the change process will be: AUTHORIZED. Rejection of a change by the Change Advisory Board If the CAB rejects the change, the Change Manager must document, in full, the reasons for the rejection and ensure that the decision is communicated to the Change Initiator. The Status of the change at this stage of the change process will be: REJECTED BY THE CAB.For the CAB to properly review change requests, the change requests should contain the following information:? Manager approval? Change Planning information. Completing the Change Implementation Plan template captures all the information requested below. (See Change Implementation Plan Template)Implementation – verification - and back-out plan details with hand offs.Listing of those parties involved in the execution of the change eventListing of those parties known to be impacted by the change eventSome change requests may require additional information, such as:? Updates to associated operational procedures, if any are affected? Impact to member or member experience, if anyIt is expected that those change requests reviewed by a Local CAB will have met the above criteria, in addition to completing the information listed below. This information will allow for quicker decision of change requests at the Intermediate CAB level.? The risk rating on the change has been reviewed by the Local CAB and adjusted if necessary? Significant changes, those with high potential for impact, are noted as such on the change request? Change requests have all required approvals up to, but not including Northern Savings approval.Note: When determining the impact and risk of a change event, it must be considered that the change may fail and cause the object of change to malfunction. Therefore, the “worst case scenario” and its impacts must be considered.Planning RFCs are to be submitted at least 5 working days before the change is required. If the date of receipt by the Change Management Team of an RFC is less than 48 working hours (2 days) before the Release date/time, due to exceptional circumstances, then the RFC must be re-classified to ‘Emergency’. This does include receipt by E-Mail. Renegotiation of the implementation date/time of the change is to be commended, not resisted, as this prevents the system from becoming stressed, especially if this takes the change outside the 48 hour period.The Change Management function classifies the change according to Northern Savings’ criteria not those of CUTASC. Remember that an Emergency Change is not a get out of jail card for a poorly organized implementer/Project Manager.If this scenario is suspected, then the change will be refused and a re-schedule insisted upon. The Change Management team will ALWAYS resist Emergency Changes that are NOT due to a broken piece of hardware/software.ApprovalAll RFCs and Releases must be approved by the Change Advisory Board (CAB). The CAB is a body that exists to approve changes and to assist Change Management in the assessment and prioritization of changes. The members of the CAB will be capable of ensuring that all changes are adequately assessed from both a business and a technical viewpoint. To achieve this, the CAB will include people with a clear understanding of the Credit Unions business needs as well as the technical development and support functions. The composition of the CAB will vary according to the change.Explanation of Change Types ‘Requests For Change’ fall into three categories: BasicEmergency StandardThe type of change you need to action, will result in a slight difference in how you complete the RFC and Release documents. For this reason users must familiarize themselves with the following explanations of the change types to enable the process to run smoothly.Basic ChangeA Basic change is a ‘one off ’ change. It is planned in advance and is to be submitted at least 5 days before the change is required.Emergency and Retrospective ChangesEmergencyAn Emergency change is also a ‘one off’ change. It is still a ‘basic’ change, but is usually a ‘fix’, hence the term ‘Emergency’, and therefore hasn’t been planned in advance. A change will be classed as an ‘Emergency’ if it is submitted to the Change Team less than 48 working week hours (2 days) before the Release date/time.RetrospectiveIn the event that an Emergency change has to be carried out prior to any documentation being raised, then the user/implementer must advise the Change team to get verbal authorization to allow the change to go ahead.The change will be classified as ‘Retrospective’. Failure to inform the change team (of any changes) may result in disciplinary action.The RFC and Release documents will still need to be raised and authorized after the event.Standard ChangeA Standard change is ‘Repeatable’. It follows a common set of procedures and is pre-authorized. The ‘user’ can action the Pre-authorized Standard change at any time by simply filling out a ‘Standard Release Notice’ Examples of Standard Changes are:Adding users to a systemAdding/Removing hardware from a rackPatching Network Cables Explanation of Change Priority Every RFC is allocated a priority that is based on the impact of the problem and the urgency for the remedy. Change Management are responsible for assigning this priority. The priority of RFCs ideally should be decided in collaboration with the initiator and, if necessary, with the CAB; but it should not be left to the initiator alone, as a higher priority than is really justified may result. The following priority ratings are used: Urgent. Causing loss of service or severe usability problems to a larger number of Users, a mission-critical system, or some equally serious problem. Immediate action required. Urgent CAB meetings may need to be convened. Resources may need to be allocated immediately to build such authorized Changes. High. Severely affecting some Users, or impacting upon a large number of Users. To be given highest priority for change building, testing and implementation resources. Medium. No severe impact, but rectification cannot be deferred until the next scheduled Release or upgrade. To be allocated medium priority for resources. Low. A Change is justified and necessary, but can wait until the next scheduled Release or upgrade. To be allocated resources accordingly. Completing the DocumentationWhatever type of change you are raising (Basic, Standard, Emergency), an RFC and a Release document are ALWAYS required. Completion of the Request for Change Document (RFC)Open the Request for Change (RFC) template. Fill out the form ensuring all relevant fields are completed following the guidelines further on in this document. All sections of the RFC must be written in plain terms, to be clearly understood by a person without technical or specialist knowledge, as this document is purely to state the Business requirement of the change.REQUEST FOR CHANGE (RFC) – Details Required (all sections to be completed unless otherwise stated)Change prepared by – person writing the Change request.Date:- Date document raised.Change Type:- Basic, Standard or Emergency Client:- name of client – could be one client, a list of clients, or “all”. Planned Date & Time(What are the requirements for the end user i.e. desired implementation date/time of the release?)Planned Implementer(s)(The Resource carrying out the change)Reserve Implementer(s)(Alternative Resource in the event the above are not available to perform the change. If no reserve is possible state ‘why’. We are trying to avoid single points of failure)Summary of Change (In a non technical way give an overview of change taking place and why?)Impact of change (In a non technical way give the impact/effect of the Change on the following)Business of the Client(Give the impact of the Change on the business of the Client)Confidentiality of the Data/System(s)(Assess the risk of whether confidential information relating to the change will be compromised)Identified Risks of ChangeRisk(s) associated with the change. What could go wrong by carrying out the change?Mitigation of RisksSteps taken to reduce the risk(s) as previously stated. Testing MethodologyA description of the planned processes to test the Change Regression MethodologyIs it possible to regress the Change? A list of vital Considerations to be completed if so. If not, why not? Sign-off Implementer(s) – Resource doing the change Reserve Implementer(s) – Resource doing the change in case the above are unavailableCUTASC - Manager Technical Services / Designate Northern Savings IT Senior Manager / DesignateNORTHERN SAVINGS CREDIT UNIONCHANGE ADVISORY BOARD (CAB) Change Request ID____________RFC Prepared ByDatePhone #Email AddressChange Type – Basic, Standard or EmergencyClient – Could be one, list or allLocation(s)Department(s)Planned / Proposed Date and TimePlanned Implementer / Resource Reserve Implementer / ResourceChange Request Definition – Briefly describe the proposed change by explaining the business problem and desired outcome. Attach any relevant documentation. 3619511176000Mark if attachment is includedJustification – Justify why the proposed change should be implementedImpact of Change – In a non technical way give the impact/effect of the changeImpact of Not Implementing – Explain the impact if the change is not implementedConfidentiality of Data – Will confidential information be compromisedIdentified Risks – Risk(s) associated with the change – What could go wrong be carrying out the change?Mitigation of Risks – Steps taken to reduce the risk(s) as stated aboveTesting Methodology – A description of the planned processes to test the changeRegression Methodology – Back Out plan – A list of considerations Change Request Analysis Impact Items – Check each item that may be impacted by the proposed change476259715500Procedure Manual 647709715500Software476258509000Training Manual6477031978600064770285623000647702521585006477021590000064770179641500647701454785006477010928350064770768985006477043561000647708509000Hardware476258826500Workflow ProcessLicensing 476257429500NS IntranetContract Amendment476255080000North Save Web SiteUser guide476256540500InfrastructureIP Addressing476255969000CommunicationsRemote Worker476257429500WB Banking Telecommunication476258953500NetworkCabling476257683500PrintingBusiness Processes and Procedures476257112000Departmental Procedures3rd Party Applications / Vendor Support476255905500Location647705905500OTHER (attach details)Impact – Identify the impact of the proposed change with consideration for each item checked47625654050015792456540500MAJOR10287006286500MODERATEMINORSign OffPrint NameSignatureDateImplementer / ResourceCUTASCNorthern SavingsComments:Definitions, Acronyms, and AbbreviationsTermDefinitionChangeThe addition, modification or removal of anything that could have an effect on IT services.Change Advisory Board (CAB)A group of people that support the assessment, prioritization, authorization and scheduling of changes.Change EvaluationThe process responsible for formal assessment of a new or changed IT service to ensure that risks have been managed and to help determine whether to authorize the change.Change ManagementThe process responsible for controlling the lifecycle of all changes.Change ModelA repeatable way of dealing with a particular category of change.Change RecordA record containing the details of a change.Change ScheduleA repeatable way of dealing with a particular category of change.CharterA document that contains details of a new service, a significant change or other significant project.Configuration Item (CI)Any component or other service asset that needs to be managed in order to deliver an IT service.Critical Success Factor (CSF)Something that must happen if an IT service, process, plan, project or other activity is to succeed.Emergency ChangeA change that must be introduced as soon as possibleEmergency Change Advisory Board (ECAB)A subgroup of the change advisory board that makes decisions about emergency changes.ImpactA measure of the effect of an incident, problem or change on business processes.Normal ChangeA change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process.PriorityA category used to identify the relative importance of an incident, problem or change.ProcessA structured set of activities designed to accomplish a specific objective.Release and Deployment ManagementThe process responsible for planning, scheduling and controlling the build, test and deployment of releases, and for delivering new functionality required by the business while protecting the integrity of existing services.Request for Change (RFC)A formal proposal for a change to be made.RiskA possible event that could cause harm or loss, or affect the ability to achieve objectives.RoleA set of responsibilities, activities and authorities assigned to a person or team.Standard ChangeA pre-authorized change that is low risk, relatively common and follows a procedure or work instruction.Work OrderA formal request to carry out a defined activity. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download