Risk/Impact Scorecard:

The Risk Scorecard is used to calculate the minimum lead time needed for the proposed implementation date and risk to the customer’s system. This score informs the Change Submitter and Change Submitter’s Technical Manager and determines what documentation must be communicated to the Change Manager and Change Advisory Board (CAB).  A risk scorecard must be completed for each type of proposed production change, along with a Request for Change (RFC) ticket.

The higher the risk level, the more lead time is required to ensure that both the Technical Implementation Team(s) and Customer Team(s) have enough time to prepare and test an RFC implementation, back-out plan, and validation plan.  When possible, look for an implementation proposed date that far exceeds the Risk Score recommendations.

The levels of risk to the customer are:

• Low Risk – a frequently-made change that has a track record of rarely causing negative impact to customers, and has a tested back out plan.
• Medium Risk – a change that may be more complicated to execute, rarely causes any negative impact to customers, and has a back out plan that may have failed in the past or has never been executed in production.
• High Risk – a complex change that may have failed in the past and has a back out plan that has failed or has never been executed in production.  There are likely multiple teams involved in this change.
• Critical Risk – a complex change that may involve multiple teams and/or external partner(s), requires a lot of time to execute, has a history of failure or has never been attempted before.

Risk Scorecard Templates & Instructions

You access the risk scorecard via an automated form. Complete the scorecard and either copy and paste the information into the RFC description field, or if this information is to be kept in a knowledge base, provide a direct link, accessible to both the CAB and Change Manager, in the RFC description field.

If your score is high or critical, copy and paste the content of the scorecard into the RFC.

If your score is low or medium, proceed as you normally do with a low or medium change.  You must do this only once for each change, and you don’t have to keep doing it for the same change.

Risk Scorecard Automated Form URL:

https://www.cognitoforms.com/ClemsonUniversity7/RiskScoreCard

Implementation Plans

If your risk score is high or critical, create an implementation plan.

You can document your implementation plan however you wish.  You can copy and paste it into the RFC or you can attach a link to your knowledge base via link accessible to the CAB and Change Manager.   

An Implementation plan must consist of the following items:

• System(s) impacted
• Testing Results
• Manager Approvals (if applicable)
• Customer Approvals (if applicable)
• Implementation steps: Tasks, personnel, and times of each step
• Back out plan steps: Tasks, personnel, and times of each step
• Validation plan steps: Tasks, personnel, and times of each step

Lead Times

We must give all our customers as much lead time as possible when proposing changes to the computing production environment.  At least two weeks’ lead time (from CAB approval to the actual approved implementation change time) is required for high- and critical-risk changes.  Exceptions for this lead time follows the ‘Expedited Change’ policy below. Low- and medium-risk requests have no lead time requirement, but please provide as much lead time as possible.

Notification of Starting and Completing a Change

Notification to the NOC of starting and completing a critical or high change is required. Call the NOC at 864-656-3723.  This allows the NOC to resume monitoring the affected system when changes are complete.  The NOC will post start and end times in the #change-management Slack channel.

All changes regardless of criticality, production, or non-production must be recorded in the systems change log by emailing SYSTEMSCHANGELOG@LISTS.CLEMSON.EDU.  No automated emails should be sent to this address.

Security Change Management

The Security Team and a subset of personnel working on security-related matters will advise the Change Manager as soon as possible for mission critical system fixes with a potential for outages to the system.  The Change Manager will advise CAB and post communications that there will be maintenance on the system but will not divulge any security-related details. The Change Manager will advise Executive Staff with details.  

Change Types

Normal Change

A normal change is a change with a critical or high risk score and an RFC that conforms to the lead times.

Emergency Change

If there is a break/fix or security issue that must be addressed immediately, resolve the incident by following the established Incident Management and Major Incident Management procedures.  Enter an RFC afterwards.

Expedited Change

A change with a high or critical risk score and less than two week lead time is an expedited change.  Submit the RFC, risk scorecard, and implementation plans to the Change Manager. Contact the Change Manager, who will escalate to Executive Staff for approval. For low or medium risk changes, inform the Change Manager, who will schedule on the CAB agenda or obtain approvals as needed.  

Unauthorized Change

Any change made to the production environment that bypasses this process is an unauthorized change.

Informational Change

An informational change is a change to our production environment or a dependency from a vendor over which which we have no control.  Examples are Telco changes, Microsoft upgrades, Canvas changes.

Maintenance Windows

Follow approved maintenance windows described this link.  If a change is requested outside of the maintenance window, the Change Manager will escalate to Executive Staff.  

https://ccit.clemson.edu/about/policy/ccit-policies-procedures/ccit-maintenance-windows/

Post-Implementation Reviews (PIR)

The Change Manager will conduct PIRs for changes as required to identify possible process improvement actions for implementation plans, back out plans, validation plans or other procedures.