NETWORK CHANGE MANAGEMENT POLICY

NETWORK CHANGE MANAGEMENT POLICY

po7540.07Adopted December 1, 2005

7540.07 - NETWORK CHANGE MANAGEMENT POLICY

Introduction

Information technology infrastructure is critical to the effective operation of the District. The educational technology department strives to continually maintain and improve this vital resource. However, as the infrastructure (and the organization) has grown, it has become more complex. As the interdependencies - between systems, between people, and between people and systems - continues to grow, it is essential that the District carefully manage changes to the infrastructure. Even the most well-intentioned change can cause unexpected hardship to technology users if the implications of the change are not mapped out in advance. By implementing a controlled change management, hardships should be minimized and diagnostics and troubleshooting of problems, if it occurs can be dealt with in a systemic manner.

Purpose

The purpose of the change management policy is to manage changes in a rational and predictable manner so that staff can plan accordingly. Changes require serious forethought, careful monitoring, and follow-up evaluation to reduce negative impact to the user community and to increase the value of our vital information technology infrastructure. The purpose of this policy is not to frustrate change or to question the rationale of changes. Rather, it is to make sure that changes have their intended impact while avoiding unintended consequences.

Scope

This policy covers all changes to hardware, software, or applications in the shared IT infrastructure of the District. This includes modification, changes, or additions to the network services (LAN/WAN), server hardware and software, and support facilities (such as electricity) for the IT infrastructure. Any change that might affect the IT infrastructure upon which District personnel rely to conduct normal business operations are within the scope of this policy.

Changes to the IT infrastructure can be necessary for many reasons, ranging from the need to fix a hardware problem to the need to update software. Here is a non-exhaustive list of change sources:

  1. periodic maintenance

  2. user requests

  3. hardware and/or software upgrades

  4. acquisition of new hardware and/or software

  5. other changes or modifications to the infrastructure

  6. environmental changes (such as changes to the electrical system)

  7. operations schedule changes

Change Management Group

The technology network support - coordinators or designee shall comprise the Change Management Group (CMG) will receive all requests for change. Requests for changes must be made through the change request form. The CMG will have the following terms of reference:

  1. They will meet once a week to review all requests for change with the requestors.

  2. They will determine if the change can be tested on a "test environment". The CMG will have to note what devices are not available on a test environment and this information is to be provided to the management team with explanations as necessary.

  3. They will be responsible for mapping out the potential impact of the change of various stakeholders.

  4. They will be responsible for communicating with all stakeholders' critical information about how a given change will impact their work.

  5. They will establish the urgency and potential impact of a proposed change. High impact changes, for example, might require downtime outside of regular maintenance cycles.

  6. For changes to critical hardware and software systems, the group will establish testing and approval criteria in advance of making the change to the IT infrastructure.

  7. The group will be responsible for properly documenting all changes and will be accountable for all changes. The group will maintain a change log that documents all requests for change, plans and scheduling for the change, and outcomes.

  8. The group will maintain regular contact with stakeholders through the District's information technology management team, as well as directly with heads and/or user committees of business units impacted by technology changes.

Change Management Process

The change management process will include the following steps. Each of these steps must be completed for every change. If a deviation from this policy is required (e.g., virus attacks, immediate repair required due to a malfunctioned system), authorization must be provided from a member of the management team.

  1. Requestor fills out change management form. The form includes space for a detailed description of the proposed change, the systems involved, the business units impacted, and the location impacted. The requestor also makes an initial estimation of the urgency and potential risk of the change, how much implementing the change will cost, and how much downtime the change may require.

  2. The change management group reviews and approves/rejects the change. At its regular meeting the CMG will review the request for change. The group will evaluate the requestor's proposal in light of their knowledge of the District's technologies, business processes, and interdependencies. They may adjust some of the estimates.

  3. The change management committee can send the request back to the requestor for further detail and study, if needed. Reasons for sending a request back can include the following:

    1. inadequate planning

    2. inadequate fall back plans (in case change fails)

    3. the timing of the change will negatively impact a key business process, such as year-end accounting

    4. adequate resources are not readily available for the project

    5. staff is not available to make the change in the time specified

  4. The CMG assigns responsibility for making the change. If the request is approved, the CMG will assign responsibility for making the change to qualified personnel thru the use of the HEAT system. Identified within the HEAT system is the device or system requiring change, description of expected changes, and eventually, the outcome of the change. They will establish specifications and testing requirements depending on the nature of the change.

  5. The CMG will communicate with stakeholders. The CMG will make sure that all stakeholders are aware of the nature and potential impact of the proposed change. For changes requiring downtime outside of regular maintenance cycles the group will also get feedback from stakeholders on appropriate scheduling of downtime.

  6. The CMG will track progress on the proposed changes and have final approval. Personnel tasked with working on the change will report back to the group regarding progress on planning and testing. When the proposed change has been tested, and appropriate fallback has been planned in case of a problem, the group will approve the change. They will schedule the change - if it requires time outside of regular maintenance cycles - and will communicate with stakeholders.

  7. The CMG will perform a follow-up on all changes. At their regular change management meetings, the CMG will perform post-mortems on all changes. Successful changes, as well as reasons why a change did not go through as planned, as lessons learned from the experience will be included in the change log.

Reviewed 3/12/24

© Brevard County Public Schools 2024