Change Management
Technology services must change.
Systems are patched, upgraded, replaced, configured, integrated, secured, expanded, and improved throughout their lifecycle.
Change Management provides a disciplined way to make those changes while balancing the need to improve technology with the need to protect College operations.
A change is an addition, modification, or removal that could affect an information technology service.
Change Management is not intended to prevent change. Its purpose is to help ISS make changes deliberately, safely, visibly, and with an appropriate understanding of risk.
Where Changes Come From
Changes may result from many types of work, including:
- Projects
- Maintenance
- Sustainment and stewardship
- Security remediation
- Incident resolution
- Problem resolution
- Vendor requirements
- Service improvement
- Lifecycle replacement
- Customer or College needs
A project may contain many changes.
A ticket may result in a change.
Maintenance frequently requires changes.
Change Management provides a common discipline regardless of where the change originated.
Change Management and Plan, Build, Operate
Changes often move across the ISS operating model.
A need may be identified in Operate.
The appropriate response may be evaluated in Plan.
The change itself may then be implemented in Build before the service returns to normal Operate activities.
Not every change is a project, but significant project work usually results in changes to one or more services.
The Goal Is Managed Risk
Every technology change carries some degree of risk.
ISS evaluates that risk using two important concepts:
- The criticality of the service being changed
- The risk presented by the individual change
These concepts are related, but they are not the same.
A relatively simple change to a service that is essential to College operations may require greater institutional review than a more complex change to a service with limited operational impact.
For this reason, service criticality is considered first.
Service Criticality
ISS services are ranked according to their importance to College operations.
Service criticality ranges from:
- Critical
- Major
- Medium
- Low
- Very-Low
The service ranking describes how significantly the College would be affected if that service were unavailable or substantially impaired.
Changes affecting Critical or Major services receive the highest level of institutional review because failure of those services could have a significant effect on College operations.
Maintenance or changes affecting a Critical or Major service require approval from:
- CITO
- Appropriate Vice President
- MCC Leadership Team
This approval is required regardless of the individual change's calculated risk.
Change Risk
For services ranked below Major, ISS determines the risk of the individual change using an established risk matrix.
The risk assessment considers:
Impact and Probability
Together, they produce an overall change-risk rating from 1 through 5, with 5 representing the highest risk.
Impact
Impact considers what could happen if the change fails.
Questions may include:
- How many people could be affected?
- How severely could College operations be affected?
- Could teaching and learning be interrupted?
- Could a significant business function stop?
- Could security, data, or integrations be affected?
- How difficult would recovery be?
Probability
Probability considers how likely it is that something unintended will occur.
Factors may include:
- Whether the change has been performed before
- Staff experience with the activity
- Complexity
- Quality of vendor documentation
- Availability of testing
- Number of dependencies
- Availability of a rollback method
- Vendor involvement
- Whether several systems must change together
A familiar, repeatable change generally has a different probability than a complex change the team has never performed before.
Risk-Based Approval
For services ranked below Major, the resulting risk rating determines the required approval.
Risk 5
Requires approval from:
- CITO
- MCC Leadership Team
Risk 4
Requires approval from:
- CITO
- Appropriate Vice President
Risk 1–3
Requires approval from:
- CITO
Employees should not proceed with a change until the required approval has been obtained.
Disruptive and Non-Disruptive Changes
Changes are also classified according to whether they are disruptive or non-disruptive.
Disruptive
A change is disruptive when a service or system is expected to be:
Customers are likely to experience something different during the maintenance.
Non-Disruptive
A change is non-disruptive when no outage or degradation is expected and customers are not expected to experience a meaningful interruption.
A change being classified as non-disruptive does not mean that it has no risk.
Unexpected outcomes can still occur.
Plan the Change
The person or team performing a significant change should understand:
- What is changing
- Why the change is needed
- Which service or service offering is affected
- The criticality of the service
- Who is responsible for the work
- When the change will occur
- Who may be affected
- Whether the change is disruptive or non-disruptive
- What dependencies exist
- What could go wrong
- How the change will be tested
- How success will be verified
- How the service will be restored or the change reversed if necessary
- What communication is required
- What approval is required
The amount of planning and documentation should be proportionate to the complexity, impact, and risk of the change.
Test When Practical
Changes should be tested before production implementation when an appropriate testing method is available.
Testing may occur through:
- A test environment
- A development environment
- A lab
- A pilot group
- A limited deployment
- Another controlled method appropriate to the technology
When meaningful testing cannot be performed before production, that limitation should be considered when assessing probability and overall change risk.
Plan for Failure
A change plan should consider what happens if the change does not work as expected.
Depending on the technology, this may involve:
- A rollback plan
- Restoring configuration
- Restoring from backup
- Returning to a previous software version
- Failing over to another system
- Vendor assistance
- Another recovery process
Planning for failure does not mean we expect failure.
It means we intend to respond deliberately if something unexpected happens.
Communicate the Change
Communication is part of Change Management.
Stakeholders and customers should not be unnecessarily surprised by changes to services they depend upon.
The required communication depends on:
- Change risk
- Whether the change is disruptive or non-disruptive
- Expected service impact
- The people affected
All planned changes must be placed on the appropriate ISS maintenance calendar. Additional email and website communication is required according to the communication requirements defined in Technology Maintenance and Change Approval. The existing change framework establishes both maintenance-calendar visibility and additional communication based on risk and service impact.
Validate the Result
After a change, the responsible team should verify that:
- The intended result occurred.
- The service is functioning normally.
- Important dependencies remain functional.
- Unexpected problems have not been introduced.
- Required communication has been completed.
- Documentation has been updated when necessary.
If a change creates an outage or significant degradation, the team should transition immediately into the appropriate Incident Management process.
Document What Happened
The record of the change should reflect what actually occurred, not simply what was planned.
If implementation differed meaningfully from the plan, the difference should be documented.
Significant lessons may result in:
- Updated procedures
- New IT Hub knowledge
- Changed maintenance instructions
- Future project requirements
- Problem-management activity
- A retrospective
Service-Specific Change Process
Some services may have additional governance requirements. Colleague already has an established CAB process. Reach out to the service owner for more details.
Connection to Our Values
People Matter because technology changes can affect people's ability to learn, teach, and work.
Communication Matters because people should not be unnecessarily surprised by changes to services they depend upon.
Integrity Matters because we tell people what we intend to do, perform the work responsibly, and document what actually occurred.
Excellence Matters because disciplined change allows ISS to improve technology while reducing avoidable risk.