Change management
On this page
Introduction
Change Management is a collective term for all approaches taken to prepare, support, and help individuals, teams, and organizations when making organizational change. Implementation of changes across your organization can be a complex and cumbersome task, especially when your business and employees are directly affected.
In SolarWinds Service Desk (SWSD), the Change Management module helps you plan, execute, and communicate change plans seamlessly while following ITIL® best practices. It also provides you with visibility to past changes, their root causes, information about which plans worked, and which plans didn’t (and why)—so that you and your team continuously improve performance.
Here the Change Lifecycle is described in detail. Continue to read as outlined or click on the links below to go directly to the topic of interest.
- Common motivators for change
- Define change plans
- Persona
- Change management lifecycle
- Permissions
- Change catalog
Common motivators for change
Some of the most common motivators for change are:
- Security
- Maintenance
- Performance
- Software upgrades
- Hardware upgrades
Prior to making any changes, consider the following factors:
- Company resources
- Budget
- The effect on the organization during the change process (for example, the possibility of a simultaneous change collision).
- How you can ensure you deliver organizational success and outcomes.
After an organization determines it is time to make a change, many more factors come into play. SolarWinds has identified four main personas, each playing a vital role in successful completion of the organizational change management process.
Define change plans
Prior to any change, it is best practice to define your change, rollback, and test plans.
Examples
The definitions below refer to an example for upgrading router firmware.
Change plan example
A change plan describes how to respond in the event of a problem. For example, when you need to upgrade the router firmware to the latest version. In an ever-changing environment, you face many unexpected interruptions, but at times, the solution can be straightforward. If a solution has worked in the past, there's no need to re-invent the wheel. Instead, document the solution in detail to let others repeat the process in the future. See the example change plan below:
Change plan: Upgrade router firmware to version (XX.XX.XX)
- Copy firmware image to deployment server.
- Validate the MD5 hash of the image.
- Confirm communication between deployment server and router (HTTP, SCP, etc.).
- Back up existing image from router to deployment server as legacy image.
- Capture running configuration on router.
- Copy new image from deployment server to router.
- Update configuration to include the new firmware image.
- Save configuration.
- Reload router.
Rollback plan example
Always have a plan B. For example, after performing an upgrade to router firmware, if the new image is active on the router but previously existing issues persist, you would need a rollback plan.
Rollback plan: Roll back upgrade of router firmware to version (XX.XX.XX)
- Copy legacy image from deployment server to router.
- Restore configuration from backup.
- Reload router.
Test plan example
It is important to test for success.
Test plan instructions
Test plan: Validate firmware is deployed to router.
Persona
As organizations vary in size and maturity, so will the breakdown of responsibilities when change is necessary. In more mature organizations the tasks and responsibilities of each persona are often filled by a different individual. In smaller organizations those tasks required by multiple personas are often carried out by the same person.
The classification of roles and responsibilities is important to:
- Ensure clear expectations of each persona and its responsibility in the Change Lifecycle.
- Provide each role the appropriate permissions in the system to carry out all approvals and additional tasks required to achieve successful change.
Change owner
There can be multiple change owners in an organization, each acting as a subject matter expert of their own domain. The change owner has four main responsibilities:
- Defining the specific change and the workflow needed to best carry out successful outcomes.
- Approving all steps and processes along the entire lifecycle of the change process.
- Constantly overseeing all changes to ensure they are being processed correctly. This can include bringing in analysts and specialists, if needed.
- Working in conjunction with CABs (Change Advisory Boards).
CAB manager
The responsibilities of this role can be performed by the Change Owner. The main responsibilities include:
- Overseeing the CAB (Change Advisory Board).
- Taking a holistic view of all the changes within the organization to minimize any inherent risks.
- Staying up-to-date on all progress and milestones of the change processes the CAB Manager is involved in.
- Approving change templates throughout the Change Management process lifecycle.
Change initiator
The Change Initiator is responsible for standard changes. This role can be performed by the same person as the Change implementer, depending on the criteria of the change and the size of the company. The main responsibilities include:
- Submitting the Change Request.
- Reviewing and tracking the progress of the Change Request.
Change implementer
The Change Implementer is responsible for implementing approved changes and, at times, for closing the Change Request. The main responsibilities include:
- Completing all assigned tasks related to the specific change.
- Staying up-to-date on all the progress and milestones of the change process.
- If needed, determining that an update in the Change Request or its fields is required. If that is the case, the Change Implementer puts in the request for the change within the process to ensure that the Change Management lifecycle is achieved smoothly and successfully.
Change is a process that at times impacts many people throughout the organization. Therefore, it is crucial to define the change and take all the necessary precautions to ensure positive business continuity while minimizing any disruption of workflow.
Change management lifecycle
The Change Management Lifecycle consists of three main phases. Within each phase there are key roles responsible for ensuring tasks are carried out in the most efficient manner. As stated above, depending on the size and maturity of an organization, different roles may be carried out by the same individual.
Phase 1 - Change catalog creation
In Phase 1, the Change Owner and/or CAB Manager creates and maintains templates, referred to as Change Catalog Items (CCIs). Changes are often unique; however, changes from the same family and type may have a great deal in common, therefore, a CCI that includes all the common processes will expedite the change creation and allow for better planned change processes.
Why do we depend on CCIs?
The CCI provides a predefined template for implementing Change. The use of a template enforces the adherence to ITIL® best practices, drives consistency, and streamlines Approvals and Execution workflows. For additional information regarding CCIs, see Change Catalog.
During Phase 1, the CCI undergoes its own process including three states:
- Draft
- Internal
- Approved
After the CCI is approved, it is published and ready to be used for future requests.
Phase 2 - Change request
The Implementer and/or Requester is responsible for requesting a change and tracking the status of that specific Change Request. It is best practice to use an existing CCI, however when there isn't a relevant CCI in place, or you are looking to make a one-time change, an Ad-Hoc change can be requested.
The Change Request initial and default State is Open.
Phase 3 - Change implementation
The change assignee, owner, CAB Manager, and/or implementer, reviews to ensure all fields and processes are accurate. After confirmation, the person presses the Start Process button to trigger the process and the approvals.
Permissions
The first step in the Change Management process in SWSD is for the administrator to assign relevant users with the proper permissions.
Navigate to Setup > Users & Groups > Roles. All roles that can part take in the Change Management process need Create and/or Manage permissions.
The following sections explain the Change Management process and lifecycle in detail. This information is helpful when determining which permissions are relevant to each user.
Click Add Permission. From the Action dropdown menu select an action, and from the Subject dropdown menu select Change Catalog. Click Create Permission to save changes made.
The tables below identify the action enabled by each permission and best practices for which permission is required by each persona. Make sure only relevant users can make changes in the Change Management Lifecycle.
Table 1 - Defining the permission
Scope: Site - Department - State (Draft/Internal/Approved)
| Action | Definition |
|---|---|
| Manage | Lets users create, delete, or update CCIs |
| Read | Lets users view approved CCIs |
| Create | Lets users create new CCIs |
| Update | Lets users update existing CCIs |
| Delete | Lets users delete CCIs |
Table 2 - Best practice to manage the permissions
| Role | Permission |
|---|---|
| Owner | Manage |
| CAB Manager | Update |
| Requester | Read |
| Implementer | Update |
Changes
Table 1 - Defining the permission
Scope: Site - Department - Requester - Assignee - Copied
| Action | Definition |
|---|---|
| Manage | Lets users create, delete, or edit a Change Request |
| Read | Lets users view (only) |
| Create |
Lets users:
|
| Update |
Lets users update an existing Change Request. This includes:
|
| Delete | Lets users delete a Change Request |
Table 2 - Best practice to manage the permissions
| Role | Permission |
|---|---|
| Owner | Manage |
| CAB Manager | Update |
| Requester | Create |
| Implementer | Update |
Change catalog
SolarWinds recommends you familiarize yourself with the Change catalog to better understand its features and how to use it.
Changes index page
For information on the Changes index page, see Changes.
Ad Hoc changes
Whenever a single-use change is necessary, an ad hoc change is the best way to proceed. It neither requires nor creates a CCI.
For example, across your organization you are replacing the phone system with VoIP (Voice over IP) technology. When the change process is complete, it will not need to be repeated. You can request an ad hoc change that will not be saved as a CCI for future use. Instead, it will display as a change created without a template.
-
From the Changes index page, click Add
. -
Scroll to the bottom of the dropdown menu and click Create New Ad Hoc Change.
In the New Ad Hoc dialog, notice the information requested is similar to that of a CCI with the execution of the Custom Fields that are included in this form.
Restrict ad hoc changes
You can restrict roles from creating ad hoc changes. See Roles and Permissions for more information.
