ICT CHANGE MANAGEMENT POLICY - Mulungushi University
INFORMATION COMMUNICATION TECHNOLOGY (ICT) ICT CHANGE MANAGEMENT POLICY 2021-2023
Table of Contents 1 Introduction . 3 2 Key Definitions . 3 3 Roles and Responsibilities . 4 4 Metrics and Reporting . 4 5 Communications . 4 6 Classification and Categorization of Changes . 5 6.1 Normal Changes . 5 6.1.1 6.2 Emergency Changes (approved after the fact) . 5 6.3 Standard Changes . 6 6.3.1 6.4 7 Normal Changes Categories: Expedited Changes . 5 Standard Change Categories: . 6 Unauthorized Changes . 6 Document Approval . 7 Appendix A – Scope . 8 Appendix B – Change Management Processes . 10 Process Workflow . 10 Detailed Change Procedures. 10 Normal Changes . 10 Emergency Changes . 11 Appendix C – Impact and Analysis Template . 12 Appendix D – Change Communication Guidelines . 14 Change Notification Matrix . 14 All Rights Reserved, 2021, Mulungushi University Page 2 of 14
1 Introduction This document will serve as the official process of ICT Change Management for Mulungushi University. It will introduce a process framework and will document the workflow, roles, procedures, and policies needed to implement a high-quality process and ensure that the processes are effective in supporting the business. The scope of this document is to define the Change Management Process, and process inputs from, and outputs to, other process areas. This document includes the necessary components of the Process that have been confirmed for the organization. 2 Key Definitions Change – The addition, modification or removal of an IT service or service component and its associated documentation. Change Model – The step-by-step process to be followed to record, review and implement a change. A Change Model can be used for any type of change. Change Record – The record within Mulungushi University that contains all of the information relative to a change. This information includes justification, risk and impact analysis, communication, approvals, phases, and tasks associated with accomplishing the change. Change Schedule (CS) - The CS shows when all changes are to take place within the entire IT infrastructure. This at-a-glance change schedule makes it possible to see available change windows and possible conflicts. Configuration Item (CI) - An IT component that is significant enough to be under Configuration Management control. Each CI can be composed of other CIs. CIs may vary widely in complexity, size and type from an entire system (including all hardware and documentation) to a single software module or a minor hardware component. Request for Change (RFC) - This is the formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements, and approval status. All Rights Reserved, 2021, Mulungushi University Page 3 of 14
3 Roles and Responsibilities Roles and Responsibilities Roles associated with the Change Management process are defined in the context of the management function and are not intended to correspond with organizational job titles. ROLE RESPONSIBILITIES Change Initiator System owner who initiates a request for change. This person is responsible for filling out the Request for Change (RFC) form ensuring that all required information is included, submitting it according to this procedure, and notifying ICT Manager. ICT Manager This person has overall operational responsibility for the change management process in the IT. Accountable for ensuring that the change request is accurate and complete and includes enough information to approve the RFC. May make the determination regarding categorization and classification of the request. Stakeholder Any individual with an interest in types of changes or in a particular change 4 Metrics and Reporting The ICT Manager will work with the Change Initiator to establish appropriate metrics to monitor the success and continual improvement of the change request. Reports containing the above metrics will be generated by the ICT officer responsible. 5 Communications The change initiator is responsible for communicating the change to the proper audiences as may be required through the approved channels. Once the initiator is notified of the change approval, they should initiate necessary communications about the change prior to the change being made. Appendix D contains guidelines for when change notifications should be sent. All Rights Reserved, 2021, Mulungushi University Page 4 of 14
6 Classification and categorization of changes Following ITIL guidelines, there are three different types of service change: i. Normal Change – Any service change that is not a standard change or an emergency change. ii. Emergency Change – A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. iii. Standard Change – A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. In addition to the change types, changes can be categorized as major, significant or minor, depending on the level of cost and risk involved, and on the scope and relationship to other changes. The detail procedures for each group should address this categorization. 6.1 Normal Changes A Normal Change is one which will affect services in the production environment, by: i. Causing a service outage; or ii. Running a significant risk of causing an outage; iii. Creating a significant change in the end user experience, Regardless of whether the change is made during a normal maintenance window or not, all Normal Changes must be approved by the ICT Manager, and communicated to the appropriate stakeholders prior to implementation. 6.1.1 Normal change categories: Expedited changes An Expedited Change is a Normal Change that must be expedited for approval more quickly than the normal change management process allows, due to critical business requirements or risk. Expedited Changes must be approved by the ICT Manager who will then review and approve the Expedited Change via email or other collaborative tools. The ICT Manager will ensure that all RFCs processed by the Software developer are properly documented as soon as possible. 6.2 Emergency changes (approved after the fact) A change that must be made before the ICT Manager can be consulted to review and approve the request may be directly be approved by the Software developer or corresponding ICT Staff if it is due to a repair or error in an IT service that is causing a negative impact. Incident resolution may sometimes require Emergency Changes. Examples include a critical service-down that requires a quick hardware swap-out, or a latenight system emergency when the ICT Manager or others may not be available. An Emergency Change must follow these steps: All Rights Reserved, 2021, Mulungushi University Page 5 of 14
i. If time allows, the Software developer/ICT Staff must make a good-faith effort to contact the ICT Manager to give Him/her the opportunity to approve the change prior to making it. ii. Once the change is deployed and the incident is resolved, the Software developer/ICT Staff must document the change as an Emergency Change. iii. The ICT Manager will then review all Emergency Changes as soon as he is available in office. 6.3 Standard Changes A type of change that follows an established procedure or work instruction and is relatively common. Their risk profile is the inverse of the Normal Change, meaning they do not: i. Cause a service outage, ii. Run a significant risk of causing an outage, or iii. Create a significant change in the end user experience. Change Models for Standard Changes will be defined by each IT group making production changes. IT personnel may submit a Change Model for each proposed Standard Change for review by the ICT Manager using a Normal RFC. Service Requests which trigger changes to configuration items in the production environment will also be authorized via Change Management. Normally these are Standard Changes using a Change Model, and only the Change Model requires approval, not each individual change. 6.3.1 Standard Change Categories: Local review change A Local Review change is a Standard Change which requires some form of approval. The team manager will determine whether a team member or the manager must review the Standard Change prior to implementation. Log-only changes A Standard Change Model which has been reviewed and approved by the ICT Manager, and which the team manager agrees can be made without further review 6.4 Unauthorized changes Any change in the scope of this policy which does not follow an approved process is an Unauthorized Change. Relevant ICT officers managing the software and hardware sections are accountable for any unauthorized changes implemented by their own and by staff in their sections. All Rights Reserved, 2021, Mulungushi University Page 6 of 14
7 Document Approval The document was reviewed by University Management and approved by the Executive and Finance Committee of Council at its meeting of 25th of February 2021. On behalf of Council: NAME POSITION SIGNATURE DATE All Rights Reserved, 2021, Mulungushi University Page 7 of 14
Appendix A – Scope Defines the types of changes to be handled per this Policy Item In/out Description in Installation, patching, upgrade or removal of software products including operating systems, commercial off-the-shelf packages, internally developed packages, utilities, and desktop base images Hardware in Installation, modification, removal or relocation of computing equipment such as servers, storage, network printers, and network equipment. Rebooting of production servers. System configuration in Moves, adds, changes and deletes such as firewall changes, access methods, shared system file permission changes, secure FTP keys, etc. Databases in Changes to databases or files such as additions, reorganizations, and major maintenance Facilities in Installation, modification, removal or relocation of equipment in wiring closets, telecommunications rooms, data centers including power conditioning, cooling, fire suppression, and environmental monitoring/alarming systems Applications in Application changes being promoted to production, new application systems being introduced, and obsolete application systems being removed Applications under construction out Applications that are in the process of being implemented are controlled by the change control process established for the particular project that is underway. (If out of scope, application teams have the responsibility to communicate changes to any affected customers.) Production Schedules in Requests for creation, deletion, or revision to batch job schedules, back-up schedules, maintenance windows or other production schedules managed by IT Services in Services being moved into production, service changes with significant user impact, and services being retired Services under construction out Decision to commit resources and provide a new service to customers, up to the time a service goes into production. Software All Rights Reserved, 2021, Mulungushi University Page 8 of 14
Telephony System in Installation, modification, de-installation, or relocation of PBX equipment and services Telephony Units out Any modification or relocation of individual phone lines and desk phones (maintained in Pinnacle) Business Continuity / Disaster Recovery Plans in Desktop out Any modification or relocation of individual desktop equipment Desktop Owner out Assigning desktop equipment to a new individual or system Production Documentation in Non-production out Changes to non-production configuration items (CIs) or resources out Examples include: End User password resets User adds/deletes/modifications Adding, deleting or revising end-user security groups and roles Daily administrative tasks Planning and architecture documents Any changes to standards, procedures, and guidelines All Rights Reserved, 2021, Mulungushi University Page 9 of 14
Appendix B – Change Management Processes The change management process involves: Logging change requests. Assessing the impact, cost, benefits, and risk of requested Changes. Providing approval or rejection. Overseeing the Change implementation. Monitoring and reporting the status of Changes. Closing Change Requests and conducting post-implementation reviews. Process workflow Below is a diagrammatic representation of the workflow of the change management process Detailed Change Procedures Normal Changes a) Change initiator initiating request for change (RFC) will create an RFC. Change type is Major. Changes should be entered into the system at least two weeks in advance of the actual change date. If change date is sooner than this, an explanation must be entered. The status of the initial RFC is recorded. b) ICT Manager will review all changes entered for completeness (all necessary sections have been filled out and are clear). ICT Manager may request change initiator to clarify or add information if needed. If the RFC is complete the ICT Manager will change the status to Proposed. The ICT manager will fill in a proposed completion date. c) The ICT officer will review the following items: Affected systems- Analyze effect on the system changed and other systems affected by the change. Proposed changes – make recommendation to ICT Manager on approval or rejection based on possibility of change request. All Rights Reserved, 2021, Mulungushi University Page 10 of 14
Timeline – any slippage of dates will require that the proposed completion date is updated. Any issues (changes made with no RFC, or any RFC’s that caused incidents) d) ICT Manager approves the RFC - this will then change status to Approved automatically. The initiator will be notified via e-mail of the approval (from the ICT department). e) ICT Manager closes all completed RFC’s (change status to Closed). f) Change initiator executes the change. g) Change initiator completes the RFC by marking the RFC to as completed and selecting the successful or not successful field. Emergency Changes 1. Change initiator initiating request for change (RFC) will enter RFC. The change type is Emergency and the status of the initial RFC is recorded. 2. Change initiator will attempt to contact management and get verbal approval if at all possible. Note the attempt and response in the RFC. 3. ICT officer responsible will attend to the change as quickly as possible. 4. The change initiator will change the status to complete and indicate if it was successful. 5. ICT Manager will then change status to Closed. All Rights Reserved, 2021, Mulungushi University Page 11 of 14
Appendix C – Impact and Analysis Template RISK ASSESSMENT Risk Score: Low/Medium/High 1. How often has this change been successfully made? 1 Routinely 2 Occasionally 3 Never 2. What is the degree of difficulty to implement this change? (Consider the complexity of the change, number of devices involved, number of steps in the process, time pressure and number of people involved to accomplish it.) 1 Low 2 Medium 3 High 3. Has this change been successfully tested, or will it be, prior to implementation? 1 Yes 2 No 4. Which test environment have you, or will you, use for this change? 1 Separate/duplicate 2 Shared 3 Partial 4 Production/none 5. Have the recovery procedures ever been successfully tested? 1 Yes/NA 2 No 6. What type of support is available if external technical assistance is needed? 1 On site 2 Remote 3 On call 4 Not available 7. What is the degree of difficulty and effort for the Vendor/Partner, if needed, to return the system/component to an operational state? 1 NA 2 Low 3 Medium 4 High 8. What is the probability of this system/component failing? 1 Never/low 2 Medium 3 High 9. What is the probability of this change negatively affecting any of the applications, databases, servers or infrastructure components supporting a tier 1 application? 1 Low/NA 2 Medium 3 High All Rights Reserved, 2021, Mulungushi University Page 12 of 14
IMPACT ASSESSMENT Impact Score: Low/Medium/High 1. What amount of downtime will the user experience, outside of the regularly scheduled maintenance window? 1 None 2 Less than an hour 3 Greater than 1 hour 4 Greater than 4 hours 2. What is your recovery capability if this change fails? 1. Easy backout or alternate/fail-over is available and will provide almost immediate service. 2. An alternate is available, but needs to be brought online. 3. No alternate system/component or spare is available 3. Mission-critical programs (e.g., SIS, Exam system, SAGE, eLearning Portal) potentially experience a negative impact due to this change? 1 Yes 2 No 4. Is end user training required, prior to implementation? 1 Yes 2 No 5. If the change were to fail, what is the worst-case scenario? (In or outside of the regularly scheduled maintenance window) 1 None 2 Slowdown 3 Partial of full outage 6. If a partial or full outage is possible, has the business successfully tested their manual/contingency procedures, should the change fail? 1 NA/Yes 2 I don’t know 3 No 7. How many IT services/business applications are impacted by this change? 1 None 2 One or two 3 Three or more 4 All 8. Approximately how many users/workstations will be negatively impacted during the change implementation? Number of users/workstations All Rights Reserved, 2021, Mulungushi University Page 13 of 14
Appendix D – Change communication guidelines Change Notification Matrix Change Type Risk Internal Notification Normal Standard Emergency High Medium Low High Medium Low All All Rights Reserved, 2021, Mulungushi University Required Required Suggested Suggested As needed As needed If Possible External Notification Required Suggested As needed As needed As needed As needed As needed Page 14 of 14
Below is a diagrammatic representation of the workflow of the change management process Detailed Change Procedures Normal Changes a) Change initiator initiating request for change (RFC) will create an RFC. Change type is Major. Changes should be entered into the system at least two weeks in advance of the actual change date. If change date is .
MULUNGUSHI UNIVERSITY CENTRE FOR ICT Student User MANUAL VERSION 07-2018 Student Course Registration The purpose of this document is to describe how to perform tasks using our student information system, please be sure to read through it thoroughly, this is to ensure the smooth running and securing of the course registration process. Contents
Afhankelijk van de onderwijsambities en de ICT inzet van de school kan dit zijn; een ICT kartrekker (Professional) een ICT-coördinator (Pionier) een ICT coach (Specialist) De rol van de ICT'er op school is vooral inspireren en adviseren bij een goede inzet van ICT en krijgt hierbij ondersteuning van de Adviseur ICT Onderwijs en .
The above candidate is applying to Mulungushi University for admission to postgraduate study. It would be of significant assistance to the University in considering his or her application if you would kindly complete this form or attach a reference addressing the questions below.
Het aandeel van de ICT-sector is dus gegroeid. — In 2013 realiseerden Nederlandse ICT-bedrijven een lagere omzet dan in 2012. De krimp bedroeg 1,4 procent. Zowel de ICT-industrie, de ICT-groothandel als de ICT-dienstverlening zagen hun omzet dalen in 2013. — In 2012 zorgden ICT-bedrijven voor 5 procent van de toegevoegde waarde
List of Actions to be Taken Importance, Priority and Relevance of Each Action Actions to be Taken A-1 Sub-decree issuance on National ICT Policy A-2 Preparation of Internal ICT Policy of NiDA consisting of ICT Policy for e-Administration and ICT Policy for Information Security B-1 Preparation of Portal Enhancement Plan B-2
7.3 Children’s use of ICT 64 7.4 Use of ICT to support children’s learning 65 Supporting children’s learning 65 Documenting children’s learning 65 7.5 Use of ICT to communicate with parents, caregivers, and whānau 66 7.6 Staff use of ICT for their own learning 66 7.7 Staff readiness and confidence to use ICT 67
berdasarkan peringkat kesediaan, penggunaan, penerapan dan transformasi. d. Mengenal pasti fokus latihan ICT untuk meningkatkan kompetensi ICT pemimpin sekolah. 1.4 Soalan Kajian 1. Apakah tahap kompetensi ICT dalam kalangan pemimpin sekolah berdasarkan domain Dasar dan Kepimpinan ICT, Pembudayaan ICT organisasi, Pengetahuan dan Kemahiran
11 Annual Book of ASTM Standards, Vol 15.03. 12 Annual Book of ASTM Standards, Vol 03.02. 13 Available from Standardization Documents Order Desk, Bldg. 4 Section D, 700 Robbins Ave., Philadelphia, PA 19111-5094, Attn: NPODS. 14 Available from American National Standards Institute, 11 W. 42nd St., 13th Floor, New York, NY 10036. TABLE 1 Deposit Alloy Types Type Phosphorus % wt I No Requirement .
