Policy 6139
CHANGE MANAGEMENT

I.     PURPOSE

The purpose of this policy is to require changes to Longwood University information technology (IT) resources and systems to be planned, communicated, documented and evaluated prior to implementation.

This policy applies specifically to university IT resources and systems that are shared. However, all who manage university IT resources and systems must document and follow change control practices that are commensurate with sensitivity and risk.

1. Changes: Changes are modifications to the IT resources or systems in use by the university.
   
   
2. Emergency changes: Emergency changes are changes made in response to situations negatively impacting operation resulting from a loss of service, severe degradation of service, a system or resource failure or a substantial and imminent threat to system or data security.
   
   
3. Maintenance: Maintenance refers to routine updates to an administrative process on existing IT resources and systems that carry a minimal level of risk and do not result in disruption of operation.
   
   
4. Application: An application is a software program or suite of programs that provides an information management, retrieval or display function for more than one individual.
   
   
5. Infrastructure: Infrastructure refers to IT resources and systems including operating systems, computer hardware and networks provided and supported by Information and Instructional Technology Services (IITS) for use across the university.

1. Changes to university IT resources and systems must be formally requested, approved and tested and signed off on prior to being put into production, regardless of the level of impact of the change.
   
   
   1. Change Requests:
      
      
      1. All requests must be in writing in the format specified by the approving authority for that level of change.
         
         
      2. Requests must include:
         
         
         • (1) Change Description: The description of the proposed change must include an explanation of what change is to be made and identification of who will be implementing the change. The description must also include an assessment of the business impact of the change and a justification for the change.
           
           
         • (2) Testing Plan: The narrative description explaining how the test process will be conducted must be in a format specified by the approving authority.
           
           
         • (3) Notification Plan: Notification must be made to all impacted parties prior to the change. The notification should include when and how the change will occur and how the change will affect the users.
           
           
         • (4) Schedule: Changes must be scheduled for minimal impact. Requests should be scheduled as far prior to the date needed as possible.
           
           
         • (5) Contingency Plan: A contingency plan must be included to document plans to recover from a failed change. That plan must include a full system-level backup to return the system to its previous state.
      
      
   2. Approval:
      
      
      1. Changes will be classified into one of three levels based on the nature of the request. The approving authority for the change will depend on its level.
         
         
         • (1) Level 1: These changes to applications will be requested and implemented by a functional area (e.g, Human Resources, Registration). Approval for such changes must be given by a team consisting of representation of functional area directors from all areas using the application.
           
           
         • (2) Level 2: These changes to applications or infrastructure will be requested by functional areas and implemented by IITS. Approval for such changes must be given by a team consisting of representation of functional area directors and the IITS director responsible for information systems.
           
           
         • (3) Level 3: These changes to infrastructure will be requested and implemented by IITS staff. Approval for such changes must be given by the IITS management team.
         
         
      2. Unapproved changes must not be implemented. Change requests may be denied for reasons including inadequate planning or inadequate resources.
      
      
   3. Testing and Sign Off:
      
      
      1. When a test environment is available the proposed change must be tested before it is put into production.
         
         
      2. The change requester is responsible for signing off that the change delivers the planned results as documented in the plan
         
         
      3. When seeking approval the requester should coordinate with other functional areas and/or IITS to ensure that others who may be affected by the change are communicated with and provided the opportunity to be appropriately involved in testing.
   
   
2. Archive: A change management log of all changes requested must be maintained. For approved changes documentation must be retained of the request, approval and testing and sign off. For changes that are not approved the rationale must be documented and retained. IITS will set uniform requirements for the archiving of change management documents for all levels of changes.
   
   
3. Emergency Changes: Occasionally emergency changes may need to be made by a functional area or by IITS before a meeting of the approving authority can be held. Emergency change requests must be submitted in writing to the IITS director responsible for information systems for Level 1 and 2 changes or to any IITS director for Level 3 changes. The emergency request should include as much detail as possible from the standard change request. At the next meeting of the approving authority a written change request should be submitted for the emergency change for documentation and approval.
   
   
4. Maintenance: Maintenance is not subject to the requirements of this policy; however, documented and tested maintenance procedures should be in place and a process should exist for logging the maintenance.

V.    ENFORCEMENT

The University regards any violation of this policy as a serious offense. Violators of this policy are subject to disciplinary action, in addition to possible cancellation of information technology (IT) resources and systems access privileges. Users of IT resources and systems at Longwood are subject to all applicable local, state and federal statutes. This policy does not preclude prosecution of criminal and civil cases under relevant local, state, federal and international laws and regulations.

Approved by the Board of Visitors, September 11, 2009.

Back to the Table of Contents                                                                    Next Policy