1. Purpose of Change Management for Network Resources
   The purpose of change management for network resources is to ensure that all changes (decommissioning, implementations, modifications, upgrades, etc.) to Ferris State University's network resources are completed successfully and with as little negative impact on productivity as possible.

   The two main components of Change Management are planning and communication.

   • Planning includes development of a comprehensive checklist of all steps required to effect the change. Critical components of planning are scheduling and coordinating with all parties affected by the change. The change request is reviewed and approved by the change implementer's immediate supervisor.
   • Communication involves prior notification of the change to all parties impacted by the change as well as notification to all parties when the change has been successfully completed.
2. Scope of Change Management for Network Resources
   This process applies to all changes to Ferris State University's production network hardware and software resources with the exception of FRS, HRS, and SIS application changes. FSU has developed specific change management processes for these administrative applications. The scope for change management refers to the addition, change, or decommissions of any shared networking production services. Please refer to Appendix A for specific criteria that trigger Change Management.
3. Overview of Change Management Process for Network Resources
   The following steps are to be followed for all changes that could potentially impact production systems at Ferris State University (with the exception of FRS, HRS, and SIS as noted in section II).

   1. Identify and Define Scope of Change
      Once the need for a change is identified, the change implementer must fully define the scope of the change. Any change in the defined scope will require the change implementer to restart the change management process from the beginning. Larger projects should be broken down into smaller components with separate change management steps identified for each piece of the project.
   2. Develop Plan
      The change implementer will create a detailed step-by-step implementation plan, ideally in checklist format. The plan should also include the fallback point. If the process does not go as planned, the fallback point specifies at what time the fallback plan must be implemented in order to restore services by the end of the scheduled outage time.
   3. Receive Approval to Implement
      The change implementer must have the documented plan reviewed and approved by the implementer's immediate supervisor. An electronic form will be used to authorize most changes. Any change-request approving manager can ask the change implementer to attend the next IS&T Staff meeting to answer questions regarding the proposed change. If necessary, the change implementer's plan must be revised based on suggestions of the committee.
   4. Develop Schedule and Gain Support of those Impacted
      The change implementer must schedule the change. Scheduling should be made during a time period that will have the least impact on services to customers. The time period starting the Monday of the week prior to the beginning of the semester through the Thursday of the first week of the semester (at 10:00pm ), only emergency change managements are allowed. In additional, the time period starting Monday of finals week, through the following Monday (in support of grade entry by faculty) are also off limits for non-emergency change management. The change implementer is required to coordinate with all those impacted by the change, and must schedule and gain commitment of all parties involved in the change implementation.

   5. Communicate and Document the Plan
      Information contained on the change request form is used to publicize downtime notification messages. As appropriate, the change implementer should ensure that future communications take place as needed. The plan should include:

      • the name of the person who is responsible for coordinating the communications
      • drafts of the actual communication(s)
      • a schedule for disseminating the communications
      • a listing of those who are to receive the communications, including the Network Operations Center (NOC) supervisor
      • notification to the dynamic list to include the positions listed in Appendix B and may be supplemented by other people on a case-by-case basis
      
      
      The following key information must be included in the communications:
      
      • the change implementation date
      • the impact of the change
      • what the customer will experience
      • what services will not be available
      • duration of outage of services (this is the maximum time as well as the maximum time to implement fallback plan)
      • instructions for any steps the customer needs to complete prior to the implementation date
      • detailed instructions for any changes the customer must execute after the change implementation
      • a name and number of the support are to call if problems are experienced
   6. Submit Change Request
      The change implementer must submit the change request form 48 hours in advance of the change date to insure adequate peer review, manager approval, and customer notification.
   7. Change Request Approval
      Most changes will be approved electronically. However, the change implementer may be requested to present an overview of the change for a committee of group of IT staff.
   8. Implement Plan
      The change implementer will ensure that communication has taken place with the appropriate customers prior to proceeding with the changes approved. At the fallback time, the change implementer must review the status of the change. If the change cannot be successfully completed by the end of the scheduled implementation time, then the change implementer must begin the fallback plan.
   9. Provide Project Feedback
      Following completion of the change or fallback plan, the change implementer should complete and submit the post-implementation form in Lotus Notes.

4. Emergency Changes
   The CTO is responsible for scheduling emergency change review meetings. Emergency meetings can be requested by via email or by phoning the CTO. Emergency changes that occur without prior approval due to hardware or software failures must be followed up with a change request within 24 hours of emergency.

Appendix A: Change Management Criteria

Things that should trigger a CM (pre or post)
Network Equipment and Servers

• Resetting, adding, reconfiguring or removing any physical server equipment for production use on the production network.
• Adding any physical server equipment to the production network for testing.
• Adding or removing any programmed network device.
• Adding or reconfiguring an NDPS printer.
• Cable plant management changes

Network Operating Systems and Applications

• Upgrade or service patch install to production equipment that will affect more than one person.
• Modification to an existing application/database that changes structure, appearance, or interacts campus wide.

Things that should not trigger CM
Network Equipment and Servers

• Simple reconfigurations of existing switch equipment that will only affect one user.
• Adding or removing hubs.

Network Operating Systems and Applications

• Adding user, group objects within an existing NOS.
• Adding a new workstation to the production network.
• Upgrade or service patch install on workstation equipment in the production network.

Appendix B: Change Management Notification List

All IT Managers
Chief Technology Officer
Computer Operations Supervisor
Computer Technicians
Coordinator of Customer Support (SATS)
FCFTL Instructional Technologist
Director of Enrollment Technology Services
Director of Telecommunications
Help Desks & Call Centers
HRIS Coordinator
IS&T Project Leader
Lotus Notes Administrator
Network Technicians
Senior Systems Programmers

Others Upon Request