- BDQ FAQ -
How to improve Change Management
with Jira Service Management.
Ever thought about how you could improve change management?
Would you like the ability to add tracking, scheduling, and approving, rather than dealing with lots of emails and enormous CC lists?
Well, take a look at our video below, have a read through the transcript and hopefully, using our expert knowledge and Atlassian's Jira Service Management, we'll answer all of your questions.
There are also some Helpful Links at the bottom of the page that you may find useful.
And if you still have questions after, feel free to get in touch →
Our Cloud Burst videos are designed to give you a lot of information in a short space of time.
To help you absorb it all, we've also provided you with a transcript below the video.
Introduction
Ever thought about about how you can improve Change Management? Could you track changes better? See them all in one place? Have approvals? See who’s done what? Rather than dealing with lots of emails and enormous CC lists? Well stay tuned, we’re going to give you a practical example of how this can be achieved with Jira Service Management.
Hi, my name’s Chris Bland. I’m an Atlassian Certified Master and I’m with BDQ, an Atlassian Solution Partner in the UK. Now, I want to talk today briefly about Change Management. Now, Change Management is essentially just a framework for managing change and the ideal way is to do this in a controlled fashion, often with approvals. It can be used with any process really, but it’s often used with IT in particular as part of ITSM. Why would you want to do that? Well, you want to make sure that changes to systems happen in a controlled way and you want to know who’s done them, and you usually want to know when/where they are going to happen.
Now let’s do a quick recap on Jira Service Management. It’s got a portal where customers can make requests, Change requests for example. you’ve got the Agent view, were the agents can actually deal with queues of requests and you’ve got Issue Types and Workflows, which represent work that’s got to be done. You’ve also got Request Types, these are basically the forms that show to customers in the portal. And in the latest Cloud version, you’ve got a Change management calendar which is really, really handy - you can see what the upcoming changes are going to be.
So you’ve got those useful concepts together - the portal, queues, request types, the specific issue types which, one of these is going to map on to Change Management requests. So the concept of changes and approvals is actually supported out of the box and it is actually just one aspect of ITSM, along with service requests, incidents and problems but it is a very key one. Some things worth bearing in mind, customers or agents can raise change requests so anyone in your organisation, that you allow, can basically do this - you can end up seeing them all in one place and on one calendar. A really nice feature is - approvals can be required from Stakeholders. So I might make a change request and then I might ask somebody else to approve it, or it might be many people need to approve it. And the best bit is, it’s all going to be audited so your going to be able to keep track of this, all in one place.
Lets step over to the PC to take a look.
Demo
Ok, let’s discuss how Jira Service Management can help us with Change Management. Now, Jira Service Management, as we have talked about elsewhere, has a “customer portal” view where anyone can access the system, if they are allowed, obviously, to make requests. And there's also an “Agent” view which is used by people servicing the requests. You can make change request through either mechanism. So one of your regular users of managers make a change request, and you would do that here in this particular case. Very straight forward - summary, description, type of change - standard, normal or emergency just like the ITSM standard, along with the reasons, risk, plans, dates and so forth.
Now, I'm not actually going to create the change from the user in this particular demo. I'm going to create the change as if I was doing it from the agent point of view, but we'll come back to this, because what I'm going to do is, I'm going to use this user, who's only got portal access, as the approver. And that just demonstrates that actually anybody can be an approver, it could be a manager, doesn't have to be somebody that's actually only got access to the actual desk itself. So let's go ahead and dive into the agent view and create that change request.
We're now looking at the agent view, these are the queues. This particular view I've got here is of all changes. So already we've got one centralized place where we can see that all the outstanding change requests, of all flavors, that've been dealt with or, rather, that have been created by users or anybody else for that matter. This can of course be customized, like most things in JIRA Service Desk [Jira Service Management], but this comes right out of the box, it's very easy to get going with.
So let's create that change request. So the project is in “Change Demo“, the particular type is “Request to change”, I'm going to say “I’d like a change”, I'm going to pop in some dates for this. So I'm going to say the “planned start” and “planned end” is today. I worry about the… yes, I’ll pop that in as well and I’ll pop all these in right now. So that's when that's going to take place. We'll see that on the calendar later on. I could actually say this is a “normal” change. And I'll remember in ITSM, “normal needs approval”, so a bit of alliteration there. So it just makes it a little bit easier to remember what's going on. Because in ITSM, for some reason, they decided to call the two change - well, there's three change types actually, they decided to call the commonly held ones, both standard and normal, which is somewhat confusing. “Standard” basically means pre-approved, “normal” means needs approval and emergencies is emergency! So right now I've created a standard change request. Let's have a look at it.
So let's just imagine some work's been done. I'm just going to assign this to myself. I could say, for example “plan something” and then I’m going to go “Do you know what? I think that is now ready for somebody to go and approve” so I'm going to hit authorize. Now I want it approved, I need to choose somebody to go and approve it. And that's because this is a “standard” workflow. We're going through a standard ITSM change.
So let's go out and choose an approver, and I'm going to choose that, I'm going to choose that user we saw a minute ago. There we go. So the act of doing that, is actually going to send an email to that person. So they're going to be alerted that there's a change request and needs their approval. And actually, if they went back to the portal, they'd actually be able to see it there, ready.
So let's go and have a look.
Okay. So, if I was actually in the portal as this user, I would see there's now an approval waiting for me. Here it is. And if I want to know a bit more about it, I can click on it and go and have a look. I might want to ask some questions about what this is connected, you know, connected with and, how people are going to do things or me just want to hit authorize.
Now if I want to go back and have a look at my email here, and as you can see, this is just regular Gmail. We'll have to wait for a second. There we go. I would have been alerted to this so I can either go in to view the request or I can just go right ahead and approve it from here. And I'll be popped straight back in. There we go.
So as the manager, now I've approved this request, so let's go back and see what the agent's got. Notice this is now actually moved along in terms of its transition. This is now awaiting implementation. And if we have a look down here in the comments, we can see that the status was moved, well the demo user, in fact approved it. And if I look at the history, I can see, basically an entire audit trail of what's gone on. Okay. So you've now got changes which are centralized in a queue. You can ask people to make approvals. Everybody can collaborate over these things, adding comments and so forth. And I can see where everything is, who's doing it, what state it's in and how it got approved.
Now we can dig a little bit deeper here, as it happens, we've got one change request that we expose in the portal. A one change request, a request type I should say. And it's called just request a change. We could have as many as we wanted, if we wanted to make it easier for users to request changes and we can see it's associated with the “change” issue type. And if I have a look at the change issue type, I can see that that is related to a change management workflow. Now, as I’m sure you’re all aware, workflows in JIRA are customizable. You can have them basically any way you want them, but very helpfully with service desks, there's a bunch of really good ones come straight out the tin and you can use straightaway.
And the “Change” one is customized really for the purposes of team change management. And it's got the ideas of planning, authorization, change approval boards, and so forth. And in fact, right in here, I can see I've got the idea of a normal change, standard change and emergency change, which basically maps on to the ITSM standards - normal needs approval, standard is preauthorized, and emergency is an emergency.
And how the planning piece works… well, the approval I should say… when things are at the “authorize” stage, we've set that up with the “approval” configuration and if have a quick look at that, I can determine exactly how we want approvals to work, where we want the approvals to come from, how many people have to approve something. So, you know, it could be a list of hard coded people, or it could be that the users select people, and it could get those people from a custom field, so on and so forth, okay, could determine we, we, we could actually only allow things to transition once all the approvals have been agreed upon, or it may just need one out of seven.
That's a little bit more detail about how approvals work. It's all basically pretty, you know, pretty straightforward, very flexible. And I remember one of our clients said actually they found, the change management and the ability to basically get on top of changes and understand everything that was going on was one of the absolute chief benefits of implementing JIRA Service Desk [Jira Service Management] and they could see everything was being asked for in one place. So, one final thing that is really quite nice with this and very new, you've now actually got a calendar. So if you set those dates, those things will actually pop onto the change calendar for you. So not only have you got list of changes in one place, and know what is going on with them, you can even see them on a calendar.
So there you go! Centralized changes, collaboration, audit trails, approvals, calendars, and that is just part of ITSM as it comes out of the box, JIRA service management.
Summary
I hope you found the demo useful. Let's just conclude. We showed you how you can raise change requests. You can see them all centrally, approvers can be required and they don't need to be licensed if they're going to be doing approvals through the portal. You get an audit trail baked in, and basically this gives you a scalable, manageable solution.
Now, I hope that short overview gives you some insight as to how you might be able to improve your change management process by using JIRA Service Management. If you want to maybe get away from lots and lots of emails and ever increasing CC lists to a centralized, scalable solution, why don't you get in touch?
