Managing changes with your IT service desk

Still need help?

The Atlassian Community is here for you.

Ask the community

Effective service desks plan and control changes, and they understand their impact to their business. An Information Technology Infrastructure Library (ITIL) change management workflows aims to make your change efforts successful.

The IT Service Desk template comes with a change management workflow. This workflow ensures you record, assess, approve, and implement change requests. We recommend you start with our default workflow and adapt it to your business needs.

If done well, a change management process: 

  • stabilizes your IT services
  • makes IT services reliable and predictable
  • adapts IT services to evolving business needs

You can lessen risk, outages, and defects. And, you can prevent duplicating efforts from failed changes.

This page describes some best practices for managing changes using Jira Service Desk. You may seek formal training in how to make ITIL recommendation work best for your business.

On this page

Change management process

The IT Service Desk template connects certain requests to a change workflow. We set up the workflow to complement the following change management process. Use the workflow to transition change request records alongside these ITIL recommended activities:

  • reviews
  • planning
  • approvals
  • implementations

We recommend you start with this workflow and adapt it to your needs over time.

The ITIL change management process, in brief:

  1. An internal IT member requests a change. They note details like the affected systems, possible risks, and expected implementation.
  2. The change manager or peers determine if the change will be successful. They may ask for more information in this step.
  3. After review, the team plans how to put the change in place. They record details about:
    • the expected outcomes 
    • resources
    • timeline
    • testing 
    • ways to roll back the change
  4. Depending on the type of change and risk, a change approval board (CAB) may need to review the plan.
  5. The team works to implement the change, documenting their procedures and results.
  6. The change manager reviews and closes the implemented change. They note whether it was successful, timely, accurately estimated, within budget, and other details.


Setup for change management in Jira Service Desk

Configure the workflow and fields with the Change Management workflow add-on

We used the ITIL framework for change management to build a workflow for Jira Service Desk: https://marketplace.atlassian.com/plugins/com.atlassian.servicedesk.change/server/overview.

You can use this add-on as a template to help you build your own change management process.

To use the workflow from the Marketplace:

  1. Log in as a user that has the Jira administrator global permission, and follow the instructions listed here to import a workflow.
  2. To add the workflow fields to your change issues, activate the screen by following the instructions here: Defining a screen.  

Change management workflow




Coordinate changes with a calendar 

With Confluence, you can schedule changes. Use Team Calendars to track changes, and schedule change to coincide with business events.  Try Team Calendars for Confluence for free.

To set up a change calendar with Team Calendars for Confluence:

  1. In Confluence, go to your team's space.
  2. From the sidebar, select Calendars.
  3. Select Add calendar.
  4. Viewing the calendar, select Add event.
  5. Select the Event Type drop down and choose Jira Issue Dates.
  6. Under Display, select the JQL (advanced) and enter the following: 
    project = "Your IT service desk project name" AND issuetype= Change
  7. Under Date range, select Add start and end date… Select Change start date as the start date. Select Change completion date as the end date.
  8. Select OK .

The calendar automatically picks up the start and end dates of change requests from    your service desk .   Then, it   plots them on the calendar.  


Default form fields for change requests 

Jira Service Desk allows you to customize the fields of information collected from customers. Additionally, you can customize the fields of information used by your agents. Jira Service Desk does this through issue type fields and screens. Fields help agents assess, approve, and categorize the request for reporting or querying.

By default, we include the following fields in your agent's view of a change request. If needed, you can  add  custom fields. Find out more about fields in Jira.

Field name

Description

Summary A short description of the request.
Reporter The person who submitted the request.
Component/s Segments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labeling, categorization, and reporting.
Attachment Files or images added to the request.
Description A long, detailed description of the request.
Linked Issues A list of other requests that affect or are effected by the request. If your business uses other Atlassian products, this list may include linked development issues.
Assignee The team member assigned to work on the request.
Priority The importance of the request's resolution, usually in regards to your business needs and goals. Sometimes, priority is calculated by impact and urgency.
Labels A list of extra custom labels used for categorizing or querying records.
Request participants A list of extra customers who take part in the request, for example, people from other teams, or vendors. Read more about participants.
Approvers A list of people responsible for approving the request, usually business, financial or technical contacts .
Organizations A list of customer groups interested in the request's resolution.
Impact The effect of the change, usually in regards to service level agreements.
Urgency The time available before the business feels the request's impact.
Change type The category of the change (usually standard, normal, or emergency). For example, a standard change does not require action from change managers. A normal change does.
Change reason A short description or code that indicates why the reporter needs  the change.
Change risk The risk of implementing the change determined by the change advisory board . Usually based on complexity, scope, testing, recovery, timing, etc.
Change start date The scheduled  date the change's implementation .
Change completion date The date the change's  implementation is complete.
Change advisory board (CAB) A list of individuals responsible for assessing, approving and scheduling the change.
Pending reason A short description or code that indicates why the change is not progressing.

Learn more about IT service management (ITSM)

Get more tips and tricks for successful ITSM, view case studies, and learn how to take your service desk to the next level. 

Check out the ITSM resources on IT Unplugged.

Last modified on Apr 30, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.