LMS Change Management

• Definitions
• Advisory Groups
• Process Goals
• Maintenance Schedule
• Maintenance Logs
• Normal Processes
• Exceptions to Normal Processes

Definitions

Change Management

A process for limiting the impact of system changes.

Learning Management System (LMS)

Blackboard Learn and its associated services.

Instance Management

DLT currently manages three LMS instances: one is the production system, while the other two are used for system testing, functional testing, and development.

Requests for Change (RFC)

Before changes are made to production LMS components, DLT will create an RFC at least one week in advance, to allow for testing and discussion. Changes to non-production systems do not normally require an RFC, except for systems which are also hosting production standby systems.

Change Advisory Board (CAB)

CAB meets weekly to review RFCs and discuss their potential impact on campus operations. Each proposed change is discussed for approval. Issues and changes to the process are discussed by CAB.

Major Releases and Updates

Major releases or updates to any LMS component, such as service packs or similar upgrades, may require a substantial effort. Therefore, a project plan should be completed before non-production implementation and testing.

Advisory Groups

Depending on which learning technologies are impacted by change, DLT consults with several advisory groups:

• The LMS Advisory Group oversees academic learning management systems, such as Blackboard Learn.
• The Enterprise Training Collab oversees compliance training systems, such as DTS or SkillPort.

Process Goals

With a goal of increasing campus adoption of our LMS, we all must be committed to:

• Keeping our systems stable and online.
• Ensuring system software is current
• Testing all changes before going into production.
• Properly communicating with campus by filling all RFC’s at least one week ahead of time.

DLT will strive to adhere to this process when any changes are needed for CSU Chico's learning technologies, including all environments and services related to Blackboard Learn, SumTotal, Kaltura, Zoom, and LinkedIn Learning, along with other integrated LMS applications and systems.

Maintenance Schedule

Third-party vendors sometimes schedule maintenance windows outside of this process; when that happens, we will do our best to communicate with impacted users before the maintenance occurs.

When DLT is able to control maintenance scheduling, we will strive to ensure maximum stability and availability for all students, faculty, and staff.

The following maintenance windows are typically used for the LMS, and may be leveraged for other systems as well:

• Overnight maintenance window (no downtime)
  Thursdays, 12AM to 2AM PST
  Weekly/Monthly
  
  
• Morning maintenance window (no downtime)
  Thursdays, 8AM to 10AM PST
  Weekly/Monthly
  
  
• Extended maintenance window (extended downtime)
  Thursdays, 12AM to 8AM PST
  Quarterly/Between Terms

From time to time, DLT will need to schedule maintenance outside of this standard schedule; when that happens, we will be sure to communicate with users.

In addition to the above, our schedule also considers several "blackout windows", where DLT will avoid making system changes in order to maximize stability during critical usage periods:

• Two-week window at start of Spring/Fall term, starting one week before first day of classes
• Two-week window at end of Spring/Fall term, starting one week before final exams

Maintenance Logs

All service interruptions, including planned or unplanned downtime or other incidents, are logged on DLT's website in order to foster transparency and accountability:

• Blackboard Ally service interruptions log
• Blackboard Learn service interruptions log
• Blackboard Predict service interruptions log
• DTS service interruptions log
• Google Classroom service interruptions log
• iClicker service interruptions log
• Kaltura service interruptions log
• LinkedIn Learning service interruptions log
• Proctorio service interruptions log
• SumTotal service interruptions log (TBA)
• Turnitin service interruptions log
• Zoom service interruptions log

Normal Processes

Non-production install

DLT will take non-production systems offline to install changes, including patches or other updates.

System testing

DLT will be primarily responsible for system testing. The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.

Functional testing

TLP will be primarily responsible for functional testing. The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.

Final GO/NO GO decision

DLT and TLP will report on test completion and make a final decision regarding a move to production.

RFC created

If a go-ahead decision is reached, DLT will create an RFC. 

RFC approved

If CAB approves the RFC, DLT will schedule any necessary downtime for production maintenance. 

Changes installed

DLT will install the change, including application shutdown as needed. Refer to the managed hosting maintenance schedule for scheduling information.

Exceptions to normal processes

Emergencies

Emergency patches to resolve security issues, system instability, and similar issues may bypass some or all of this process.

Zero-Day vulnerabilities

Patches to fix zero-day security vulnerabilities will be evaluated on a case-by-case basis.