Change Management

The purpose of Change Management is to ensure that all Changes are made in such a way as to minimize their effect and the effect of any related Incidents on the business.

Emergency, Normal and Standard Changes

ITIL guidelines describe three different Change processes that you could use. With Ivanti Service Desk, you can create as many different types and variants of Change processes as you require – there is no limit to the number of Change processes that you can design using the design tools. The default Change process is comprehensive as a full Normal change process.

Emergency Change – You can modify a Change process to bypass most of the standard actions in the case of an Emergency Change being logged. You could do this by adding a new boolean Emergency Change attribute to the Change object, and then adding a process decision to route to the Change process past as much of the process as required.

Standard Change – The same approach applies to the simpler 'no authorization required' Standard Change activity. Adding a boolean and process decision again for Standard Change enables a third branch.

However, you could choose to use three separate processes – one for each type of change. The advantages of this are that you can maintain and develop the separate processes independently.

During implementation, your Service Desk consultant can provide guidelines based around these approaches.

In typical, mature Service Desk implementations, Change processes grow and evolve way beyond the simple ITIL definitions. It is common to have a large number of variants of change processes.

In considering your different change processes, note that the Change Type categorization list is predefined for you with Major, Minor and Significant types.

Change Schedule, Forward Schedule of Change, and Projected Service Outages (PSOs)

Communication is a strength of Ivanti Service Desk. Many organizations communicate future and planned activities in different ways, but whether referring to them by the ITIL terminology or other terminology, the same end result is easily achieved.

Viewing a Change Schedule – At the simplest level, the correct use of Queries can provide everyone with the correct views of scheduled work. You can create a Change Schedule query based on the Change Schedule object. We recommend that you use two versions of this query – one that can Launch to allow Change Managers and other authorized roles to access the full RFC/Change, and the other to provide other departments such as Incident Management / firstline staff and end users with a read only view of any planned Changes.

Remember that you can schedule these Future Change queries, e-mail their results, and also provide them using RSS feeds. For more information about using RSS feeds with Service Desk, see RSS Generator.

Remember that you can add the queries described above to Self Service for your customers or end-users to see, and can be made rich in appearance and content using Report Templates in Object Designer.

Projected Service Outage (PSO) – If you need a PSO view presented within IT or to the business as a whole, then only one small modification is required to the standard system design. Include the Title of the impacted Service on the Change record. Depending on your initial design, this may need only a dropdown list of CIs filtered to show just those where the CI Type is Service.

You can use a new Object inside the Change process to record multiple Affected Services on a Change, however an easier approach may be just to use a text field on the Change window itself. Different Service Desk implementations tend to approach this in different ways based on their own Service-lifecycle maturity.

Once added to the Change, a new variant of the Change Schedule query can be presented through all platforms to list future scheduled Changes that will impact the availability of Services.

We recommend adding Projected Service Outage queries to Self Service, using HTML Report Templates in Object Designer to add visual impact. See the Ivanti User Community ( for examples of Self Service design.

Software Development and Enhancement

Ivanti Service Desk is well suited to designing processes beyond generic IT changes. Many organizations use Change processes across a range of product and service lifecycle activities, including Software or Application development and maintenance. A good starting point for this is the Release Management process provided in the standard Service Desk database.

Change Type and Categorization

If you have one Change process with branches for different types of Change, you add a dropdown list to the Change window from which you can select the Type of Change: Emergency, Normal, or Standard. Selecting Emergency routes the process through Emergency CAB approval; selecting Normal follows the full Change process; selecting Standard follows a flow that requires no authorization or pre-approval activities. These options are either on the Change window itself or provided as three separate shortcuts in the shortcut bar.

To help you to identify your changes, you may have a dropdown list of the types of Change Categorization that are available. These are Minor, Major, or Significant. Select these from the dropdown list on the Change Window to further identify your changes.

Approval and CAB

The Approval stage on Change processes varies both by the type of Change being followed, and your own organization. Make sure you publish the appropriate shortcuts to the each of the roles and groups in your Service Desk. With Service Desk, a default role of Approver is provided, and you can create a Support Group called CAB. You can add your own individual roles within the CAB and your own alternative CAB groups through the User Management tree in the Administration component.

When a Change reaches an approval stage, add a notification or dashboard to update the members of the CAB group. Using the Process Approver functionality, they can be sent an e-mail containing links to the Change details, from where they can click Accept or Reject in the Actions list.

Alternatively, you can design a dashboard or query for the CAB group that shows the Changes they need to progress.

If you want, you can add individual weighting calculations into the process.

Design idea: If you are holding a face-to-face CAB meeting, run Service Desk in the meeting (with large screen/projector) and accept/reject approvals during the meeting.

Backout plan

There are many documents associated with good Change Management, and Service Desk's strength lies in its ability to guide people to produce and attach those documents to the Change process. To add an attachment to a Change, click Add Attachment in the Actions list.

You can add Add Attachment as an optional action to any status using Process Designer.

However, in the case of specific structured activities such as Backout plans, you may want to use Service Desk to ensure that the documents are also correctly progressed and acceptable.

For example, you could add an Add Backout Plan action to the Change. The Add Backout Plan window would contain the Attachment option for the document, but also fields to validate the content. You could also add a dropdown list of Backout Plan Statuses, using a reference list. For example, you could add values of Submitted, Approved, and Rejected.

Design idea: The process-driven nature of Service Desk means that you can extend this further. You can create complete assign, create, review, approve, reject process sequences either as branches on your Change process, or as Change Task processes.

Change Review

The default Change process contains a Change Review stage and status. Once the Change is Implemented, a Change Review takes place – the process is assigned to the appropriate role with a notification that a review is required. Although comments and notes can be added at this status, you could expand this into greater review activity.

Design idea: Add further process activities and actions (assigning to more users, roles and groups, or adding extra review/reject steps). Or use an automatic action to add a customized Change Task process at this stage, and add a Precondition to the Change that prevents it from being closed until the Task is Completed.