INFORMATION TECHNOLOGY SERVICES IT CHANGE MANAGEMENT POLICY & PROCESS Revised: 12/5/2011
Table of Contents Overview... 3 Roles and Responsibilities... 4 Management Process Definition... 6 Management Process Stages... 7 Emergency Management Process... 12 Emergency Management Process Stage... 13 Blackout Periods... 13 Appendix: Risk Assessment Tool... 14 Revised: 12/5/2011
Document Name: Management Policies Overview Policy Statement The Information Technology Services (ITS) policy is to ensure that standardized methods and procedures are used for the efficient and prompt handling of all changes, to minimize the impact of any related incidents upon ITS services. There will be one change management process to identify, assess, prioritize and schedule changes to the production environment. All changes affecting the characteristics or configuration within the production applications and infrastructure for which ITS has accountability will be subject to the change management process. A risk assessment level will be associated with every change and will be assigned using the predetermined criteria. The approving authority will be based on the risk assessment. Purpose This policy is to manage changes to the production environment in a rational and predictable manner that will help the staff of Information Technology Services and the users of their systems and services to plan accordingly. A formal Management process ensures that a common method is used to handle all changes to the production environment, including appropriate planning, communications, scheduling and evaluation. This ultimately leads to more informed decisions and better communication about changes. Scope The ITS Management process applies to all changes to the production environments for services and infrastructure components for which ITS has accountability. Management is a process, roles and tools that answers: Who does what? How do we ensure readiness? How do we communicate? How do we schedule? By example, ITS has the accountability for the infrastructure components of the college s ERP/SIS system and the Register has accountability for the functional changes to the registration service. This change process would apply to configuration changes to the applications, firewalls, servers, etc., but not to the functional changes to the service. By contrast, ITS has accountability for both the functionality and the infrastructure of Staff/Faculty email services, and so this change process would apply to any changes in either of these areas. IT Management Policy and Process Cincinnati State Page 3 of 15
Document Name: Management Policies Roles and Responsibilities The ITS Management process defines several types of user roles. The table below lists the different roles that are involved in the change management process, along with their respective responsibilities. Role Process Owner (Assigned) Manager Responsibility The Process Owner owns the Management process and supporting documentation for that process, oversees the process, and ensures that the process is followed by the organization. The Process Owner is also responsible for the approval of all proposed changes to the process and development of process improvement plans. Same as Advisory Council (CAC) Manager see below (Assigned) Requester (variable) Coordinator Sr. Coordinator (variable) A Requester is any individual who submits a Request For (RFC). This is a variety of user, likely within ITS. The Coordinator is responsible for recording, planning, and tracking the change request. Planning activities include assessing risks; identifying, creating, and sequencing the tasks that must be performed to accomplish the change; estimating the costs of the change request; creating plans; alternatives; back out plans; identifying stakeholders; classifying changes; and scheduling people and resources to implement each task. The Coordinator is also responsible for ensuring that all parties involved with the change have all the information that is needed for the change to progress through the process. The Coordinator may also serve as the Project Manager. The Senior Coordinator would be the manager from the affected area/service Sponsor (variable) Approver, including The Sponsor has the responsibility for the cost of the change, either directly through charging or indirectly in terms of demonstrated business need. The Sponsor is the individual that approves the RFC from the business perspective. The Sponsor assumes responsibility for a specific change. An Approver is an individual or group who must approve a change request before it can be scheduled. ITS promote approval at the lowest appropriate IT Management Policy and Process Cincinnati State Page 4 of 15
Document Name: Management Policies Advisory Council level in the organization, based on the assessment and classification. Three levels of approval have been identified: 1. Coordinator 2. Senior Coordinator 3. Advisory Council A Manager must review changes with high user impact and coordinates/chairs the Advisory Council (CAC). The CAC is comprised of relevant stakeholder representatives for each critical IT service. These stakeholder representatives are the people who can best make decisions about changes because of their understanding of the business goals, subject matter experts, as well as the technical and operational risks. The CAC is also responsible for scheduling changes as it is comprised of representatives who can best complete the planning and scheduling of changes with minimum risk to service availability. IT Management Policy and Process Cincinnati State Page 5 of 15
Document Name: Management Policies Management Process Definition IT Management Policy and Process Cincinnati State Page 6 of 15
Document Name: Management Policies Management Process Stages Proposal Stage The first stage is the proposal of a change. s can arise from a variety of sources: Help Desk incidents, problem management and resolution, introduction of new IT services, or simple infrastructure and application maintenance efforts. Inputs Activity Outputs Roles Related Tools and Data Request for : Who, What, Why, When Accept the change. Identify any duplication or redundancy Capture information about the change Classify the change Categorization Affected systems and services Classification of (low, medium, high, urgent) Requester Coordinator Tracking Tool: Request Database (Remedy) with Risk Assessment Tool Data elements: title, number, date, Who: requested by, sponsored by, prepared by, What: description of change, When: date of the proposed change, Risk elements matrix: number of users impacted, training required, time to perform the change, local testing, back out/recovery, impact if change not performed. Emergency Flag is this an emergency? Communication: During the proposal stage, a tentative schedule for a service change is discussed and advance notice of the change and the schedule is communicated to key players, such as the senior management team, service managers, divisional liaisons, and the ITS Help Desk. IT Management Policy and Process Cincinnati State Page 7 of 15
Document Name: Management Policies The purpose of this advance notice is to gain feedback on the proposed schedule to find out if there are any conflicts and to address customer impact. Work in Progress Stage The work in progress stage of the change management process is a potential point of integration with Project Management, which guide and inform planning. If the change is too small to be a project, the task planning happens by the change coordinator outside that process. This is the stage where the change coordinator develops the design document and obtains buy-in from all stakeholders. Inputs Activity Outputs Roles Related Tools and Data priority Classification (low, medium, high, urgent) Planning for low classification Transition of projects to project management Appropriate Artifacts for Classification Coordinator Sponsor Tracking Tool: Request Database (Remedy) with Risk Assessment Tool Artifacts list Priority Classification: The priority will determine the relative importance of the Request for (RFC) in relation to other outstanding RFCs and it will be the main item of data on the basis of which pending changes are scheduled. The category determines the difficulty and impact of the RFC and will be one of the main parameters used to determine the resources that need to be allocated, the foreseen deadlines and the level of authorization needed before the change can be implemented. The basic classification should include at least the following priority levels: Low: this change may be best made alongside others, such as when updating software packages, buying new hardware, etc. Medium: This change should be made provided it does not get in the way of another, higher priority, change. High: a change that should be made without delay, as it is associated with known errors that are significantly degrading service quality. The CAC should assess this change at its next meeting and take the relevant measures to enable a rapid solution. Urgent: this problem has to be solved as it is causing an interruption or serious degradation to service. An urgent change triggers the emergency change process. Audit Stage When a change is considered for release into production, the audit stage confirms readiness, asking questions such as: Has it been tested? IT Management Policy and Process Cincinnati State Page 8 of 15
Document Name: Management Policies If there was a need for training, did it happen? What was the communication around the change? Was support staff notified this was in the pipeline? Inputs Activity Outputs Roles Related Tools and Data Appropriate artifacts for Classification Review artifacts appropriate to scope Confirm readiness Approve change for scheduling Artifact audit Approval for scheduling Coordinator Manager Approver Tracking Tool: Request Database (Remedy) with Risk Assessment Tool CAC Agenda/Minutes Audit status Communication: If the service change and schedule is approved in the proposal stage, then the audit stage serves the purpose of writing the message, confirming the communication plan, deciding the best communication channel(s) and verifying the audience. Schedule Stage If confirmed, the change is then scheduled, taking into consideration the other changes that may be in the pipeline and potential conflicts, e.g. finals week, fiscal closing, priority one registration, critical campus events. Inputs Activity Outputs Roles Related Tools and Data Artifact audit Approval for scheduling Review proposed change date and duration. Approve or revise proposed change date. Date scheduled or proposed for change Communication Manager Approver Coordinator Tracking Tool: Request Database (Remedy) with Risk Assessment Tool Communication: Once the service change schedule gains final approval in the audit stage, advance notification to the ITS division is communicated. It s important that the Help Desk and appropriate ITS staff receive advance information to better prepare for customer impact. Before the change is announced, the Manager finalizes the message. After determining the proper channel and audience, a message is communicated to the customer with details on what is happening, when the change will take place, any action needed, impacts, change benefits, and where to go for help. IT Management Policy and Process Cincinnati State Page 9 of 15
Document Name: Management Policies The change is then implemented during the approved schedule maintenance window. Documentation: Scheduling Checklist Question Answer Information Source Is this scheduled for a regular maintenance window? Does the campus calendar indicate a possible customer/event conflict? Do any of the already planned changes indicate a possible conflict? What is the drop dead date for the change? What is the impact on customers given this date? What is the impact on support given this date? What is the impact on regularly scheduled processes given this date? Do we have the lead time to adequately communicate? Service Level Agreements (SLA) Campus Calendar Campus Calendar Coordinator CAC member representing Customers CAC member representing Help Desk CAC member representing Application Development Communication Plan Implement Stage The implementation stage is another integration point with project management, depending upon the size of the change request. Inputs Activity Outputs Roles Related Tools and Data Scheduled date for change Implement the change Status success of change and/or backout/recovery. Unexpected impacts of change(s) Coordinator Tracking Tool: Request Database (Remedy) with Risk Assessment Tool IT Management Policy and Process Cincinnati State Page 10 of 15
Document Name: Management Policies Assessment Stage The final stage is assessment of the change, where the post-implementation review and evaluation is done and the success or issues are recorded. Inputs Activity Outputs Roles Related Tools and Data Status success of change and/or back out/recovery. Unexpected impacts of change(s) Review the status and unexpected impacts. Input to change or project or other processes Manager Tracking Tool: Request Database (Remedy) with Risk Assessment Tool Data elements: Status of change, unexpected impacts, recommendations Communication: It is here that the Manager, division liaisons, and Help Desk staff, communicate and discuss feedback received from the customers and technical support staff. The feedback is recorded and forwarded to appropriate ITS staff for further evaluation. Evaluating customer feedback ensures effective communication, builds credibility and enables ITS to communicate effective messages to meet the needs. It also enables ITS to continuously improvement the Management Process. IT Management Policy and Process Cincinnati State Page 11 of 15
Document Name: Management Policies Emergency Management Process IT Management Policy and Process Cincinnati State Page 12 of 15
Document Name: Management Policies Emergency Management Process Stage An Emergency is defined as a change that without immediate action will result in the loss of critical business operations. Proposal Stage Emergency changes are flagged as such in the proposal stage and the advance notice is bypassed. Planning Stage Urgent planning is done. Audit Stage A minimum CAC is convened for approval and the artifacts are postponed until the assessment stage. Communications advances to the scheduling stage. Schedule Stage A minimum CAC is convened for scheduling, emergency changes may have a quicker timeframe for scheduling and communications. Implement Stage No difference from the standard change management process. Assessment Stage Emergency changes require a post-audit for testing artifact as well as the post-implementation evaluation. Emergency changes may require a follow-up status communication. Off-Hours Emergencies Note that off-hours emergencies will be handled by the Coordinator and Manager, who may decide to activate a minimum CAC for any approvals and may initiate required communications. Follow-up communications will happen when the regular business resumes. Blackout Periods Blackout Periods There will be periods of time at Cincinnati State where there will be no changes implemented. These periods are necessary to accommodate activities that are undertaken by the school in which the disruption of services are unacceptable. On an annual basis IT leadership will publish a schedule of the blackout periods. IT Management Policy and Process Cincinnati State Page 13 of 15
Document Name: Management Policies Appendix: Risk Assessment Tool This tool would be integrated into the Request Tracking Database. It identifies the business and technical risks that are relevant to the change being implemented. Evaluate each Risk Item by indicating the appropriate classification. Once the potential risks have been identified, add the row totals on the overall total for the Total Risk Assessment. Risk Item 1 2 3 4 Score Number of users Impaced Communication Artifact: Evidence of Communication or plan in WBS Single User Single Group or Unit Division Requires Artifact Multiple Divisions, Campus-wide, Public Requires Manager review User Training required Training Artifact: Evidence of training or plan in WBS Requires Artifact None Minimal Moderate Considerable (some customer education (internal staff, customers, end required) users, all) Requires Artifact Requires Manager review Local Testing Has been tested in production-replicated Testing Artifact: test environment Evidence of testing or plan in WBS Requirements for : Requires Artifact Has been partially tested Has been tested in an No local testing done; Vendor or in production-replicated environment that is external testing. test environment significantly different than Requires Artifact the production environment Requires Artifact Time of Outage Less than 1 hour 1 to 3 hours 4 hours to 1 full day Multiple days Backout / Recovery Backout is easy; can be Backout is complex; can Backout is difficult; can be Backout is not possible performed within 1 hour be performed within 4 performed within 1 day hours Impace if change NOT performed No impact Minimal performance degradation/loss of functionality OR exposed to low risk security vulnerability Substantial performance degradation/loss of functionality OR exposed to medium risk security vulnerability System or application becomes unusable or easily compromised/exposed to high risk security vulnerability Requires Manager review Total Risk Score: 0 Risk Category Low (6-11) Medium (12-17) High (18+) Artifacts Required -RFC w/risk Score RFC w/risk Score RFC w/risk Score -Triggered Artifact(s): Communication Training Testing -Triggered Artifact(s): Communication Training Testing -All Artifact(s): Communication Training Testing Approval Required Coordinator (unless requires Manager review) Sr. Coordinator (unless requires Manager review) CAC IT Management Policy and Process Cincinnati State Page 14 of 15
Document Name: Management Policies Minimum Lead Time Required Align w/ Service Maintenance Window 1 week 2 weeks Minimum Notifications Required - Requester - Approver - Notifications per Service - Communication Policy - Help Desk - Requester - Approver - Notifications per Service - Communication Policy - Campus Calendar - Help Desk - Requester - Approver - Notifications per Service - Communication Policy - Campus Calendar IT Management Policy and Process Cincinnati State Page 15 of 15