Webinars

16 min read

How Important is Change Management in an Organization?

Apr 2, 2019 9:00:00 AM

 

 
 

Join this webinar to learn how to take change management to the next level with Jira Service Desk. Senior consultant, Lauren Schroeder, takes you through how we helped transform a Fortune 500 semiconductor company by recreating their change process in Jira, proving the importance of change management in any organization.

Full Transcript:

Joseph Lane: Welcome back everybody, let's go ahead and get started.

Mark your calendars for next webinar, Agile Project management with Atlassian and Tempo with Morgan Folsom, Senior Consultant.

Let's do some quick housekeeping: no doubt you'll have some questions, and when you do, use the control panel on the side of your screen to ask them. We’ll get to your questions as fast as we can. If we can’t get to all the questions during the webinar, we’ll follow up with answers as soon as possible.

We have hundreds of clients across the United States, ranging from small and medium businesses all the way of the top Fortune 5. Our clients include the world's largest retailer, the top media company, and the top automotive retailer. This also includes the largest Healthcare Services Company an Electronics manufacturer.

Let me first take a moment to tell you about us here at Praecipio Consulting. We’re an Atlassian platinum solutions partner and we've been doing this work since 2008. Over 99% of our projects are Atlassian related: this includes work around DevOps, IT Ops and scaled agile. we do pretty much everything there is to do in the Atlassian world; everything from implementation and training to customer development, licenses and upgrades, and managed hosting and services.

And now let’s get on with the webinar.

Thanks!

Lauren Schroeder:  Thanks! My name is Lauren Schroeder and I'm a senior consultant with Praecipio Consulting. I recently worked with it team at a Fortune 500 semiconductor manufacturing company to figure out a better way to handle Change Management.

So when I started on this project, they already had a Change Management process in place, although it was very vague. They had a change-ticket type that had very basic fields, and people would submit changes but they didn't really know if they were filling out the fields right and there was a lot of miscommunication and uncertainty around the process.

So by implementing a new change process we were really able to change this around, and I wanted to present this webinar to give you a better feel of how this happened, and maybe some tips and tricks on how you can make this happen at your own organization.

Today we're going to cover some different things we're going to start at a high level and look at Change Management concepts, so just what change management means and some different terminology that you have to understand.

After that we're going to go over the Tool set that we use, which is Jira service desk and see some different tools that they have to help implement these designs.

Then after that I'm going to talk a little bit about the client that I worked with, and some specific areas such as how we were able to get the right information, how we were able to coordinate this process across the organization, and then how we were able to use these change tickets as a history change record that people could reference for different things.

And after that we’ll follow up with some time for questions that you might have.

So first of all we're going to go over change management Concepts and just give you an overview of some different ways that people think about change management and how they approach it when they're trying to develop a process that they can use.

So ITIL is an acronym that stands for Information Technology Infrastructure Library and it's a set of practices that you can use for IT Service Management and it focuses on aligning business needs with IT services, so this is a very high-level kind of library that any organization should be able to use, and it’s not technology-specific, it’s not industry specific, but it’s really used for generally defining processes for change organization.

So the official definition is the addition, modification, removal of any authorized, planned or supported service component that could have an effect on IT services.

ITIL defines three different types of changes and the changes that we focused on with our client. So first of all we have standard changes: now this is a type of change that is really common, it's an everyday type of thing, and there's not very many problems associated with it. So an example of this could be something like updating a user account access level. Something that happens on a very regular basis and there's a really low risk of this type of change impacting anything else in the IT systems.

The second type of change is a normal change so this is something where it's less of an everyday type of thing, it could be for example something like moving Jira from a server version to a data center version, it could include downtime, there might be more risk associated with it and it could also impact other areas of the organization.

And a third category, this would be emergency or latent changes so these are actually two different types of changes with our client. We handled them in a similar way and I'll explain more about that later but an emergency change, this would be something that needs to happen immediately, there isn't time to really formally document that change before it happens, it's something where there's a problem and you have to deal with it, so an example of this would be security threats or a VM going down: it's just something where people don’t have time to create a ticket they need to deal with the problem right away.

So a latent change is kind of similar, but it's a change that already happened maybe because there was an emergency and change has to be documented after the fact.

Here's some other ITIL definitions that are also really common, and will come up a lot so I just wanted to go over these: one is an RFC, this is an acronym that refers to a Request for Change, This for example would be a ticket or a request from someone that wants to change something in his system and it's a formal proposal to change the service and it would usually be submitted by someone who's using a service or a stakeholder in the organization.

The Change Advisory Board and this is an acronym CAB, or the CAB board, and this is a group of people or organization that are in charge of approving or rejecting different changes that need to happen, they’re usually experienced in the area of change management And they're the ones who might come back with more questions and make sure that the change seems like it will go through without any problems.

The change risk, so this is the probability that implementation won't go as planned, so a lot of times information around this is collected on a scale, for example maybe on a high-medium-low scale, and each organization this high medium low can mean different things, but there's generally agreed-upon definitions of what change risk can be categorized as.

And lastly business impact, so this is how the change will affect the environment and customers. It's really: will this affect other areas of the organization? If things don't go as planned who might be affected by the change? So again this is something that the specific definition will depend more on the organization, but it might be categorized as high, medium and low.

Next we're going to talk about the tool set that we use. So we use Jira Service Desk and this has a little bit more functionality than a normal Jira license, it allows you to do a few more things which are really useful when you're trying to implement a change management process.

One of the things that you can do is customize the workflows that you're using to be able to handle these unique change situations. So for example we talked about different types of changes so with our client they, had three different types of changes that they wanted to handle differently so in a Jira workflow what you can do is you can have different paths for different types of change tickets.

So what we did is we added conditions into our Jira workflows which basically triaged tickets based on their change type. So when a user is creating a change ticket what they'll do is there's a field that allows them to choose whether it's a standard, normal or emergency change; and based on what they select when they're creating the ticket, the ticket is handled it different ways and can go through different workflows with different type of approvals.

And we used a lot of different add-ons to configure this type of logic, one example would be Turbo Kit, but there's plenty that will be able to handle this type of thing. If you're in Jira Cloud you can do this natively and this will really allow you to change the way that different types of changes are handled in the process.

Approvals are another tool that are great to use for change management. So a lot of times when a change has been created a lot of people need to know about this change, and approvals are an added feature in Jira Service Desk. When you check a box at an approval what you'll need to do is configure it so that, for example, say people need 3 approvals: you can have it so that the ticket will pass through the workflow once one of the approvers has approved the ticket, or you could change your configuration so all three people have to approve the ticket for it to pass through to the next step.

So this helps you to have accountability and traceability of your tickets based on whether or not they've been approved. This is a lot more streamlined, for example, than tagging someone in a comment in Jira and hoping that they'll find the ticket and comment back whether or not they approved the change.

Another feature that Jira Service Desk ads is SLAs and notifications around these SLAs. So SLA stands for a service-level agreement and it's basically a way to track how much time the ticket is in different states of your workflow in your approval process.

So for example you could set an SLA that says that whenever a changed ticket is created it needs to be approved by the approver within 48 hours. This is all very customizable, you can also add an SLA so that the ticket, for example, once it's resolved it needs to be closed with the resolution and approved within 24 hours after that.

It's generally a way to make sure that people are aware of how long these tickets are open and basically making sure that tickets aren't getting stuck along the workflow.

You can also add notifications along with these SLAs so that for example If one of the SLAs used is about to breach, if you're about to hit your allotted time for an approval, it could send an email to the approvers and make sure that they're aware that the ticket needs to be approved.

The next topic that we're going to discuss is getting the right information. So we going over some of the ITIL concepts and the tool set, so now we're going to talk about qualitatively, what we want to focus on when we're developing our change process.

So one of the most important things to help a ticket move through the workflow is make sure that all the needed information is there. And if you can collect this right information when the ticket’s being created, it's going to save so much time later.

So you don't have people trying to get ahold of the requester and get more information, you don't have as many rejected approvals because the approvers all have all the information they need to be able to understand whether the change will make it through the process or not.
There's a few things that I would recommend to focus on when you're trying to get the right information from your ticket: the first one this is field descriptions. So ITIL language can be kind of confusing and a lot of people aren't familiar with it. Especially the difference between a standard change and a normal change! So what we did with our client is, we basically added definitions on to the main issue create screen that really spelled this out.

Here you can see what this would look like on your issue creation screen: so right here we have a field for change type and underneath that we have some formatted text that just reminds people what these different change definitions mean and this is something that we actually left off of the initial prototype of this process and even though the different agents who are using this work will went through a training session no one could remember which change was what and it led to a lot of confusion along the process and ever since we added this helper text in it really reduce the confusion and it hasn't come up since.

The next thing we're going to look at is high-quality data. So this is really just thinking about what you need to know when a change ticket is being created and all of this will depend on the nature of the changes that your organization but there certain types of things that are really useful to know.

So for example, a roll back plan: basically a field where someone can write “if this change doesn't go through if something goes wrong during the change process what's the plan do we roll back to how we were working before?” Is that doable? And it really just make sure that people are thinking about these types of things and they have some idea of what they're going to do in that type of situation.

Screens and fields are another thing to focus on so, Again we want to make sure that we're getting the right balance of information from the users so for example if you start flooding your screens with too many fields it's going to become overwhelming and people are going to put less effort into what they're writing so by making sure that you have enough information being collected but not fields that you're not really going to be safe this is going to make sure that people are spending more time to give detailed answers to the questions that are important.

So with our client this is something that we had some discussion around, and really these types of fields like rollback plan, change risk, a lot of this wasn't being collected as explicitly in the old change management process.

And some of the feedback that I got from the team was that a lot of these implementations happened with much higher quality so having this information really did make sure that the change was going to happen with as much success as possible.

The next topic that we're going to talk about is coordinating across the organization so there's a lot of people that need to understand what changes are happening and might need to be a part of that change and there's some different things that Jira can help you do to make sure that the right people are aware of what's happening.

Approvals coming to a play a lot when you're trying to coordinate, so there's three different types of approvals that can be really useful. one is the pair approval, and this is an approval that really is just someone else from your team is looking over your shoulder, a colleague is just looking over the change ticket to make sure that everything seems okay.

Some of the initial feedback we got in this pair approval process was that someone just going to point over to their neighbor who sits next to him and say hey can you approve my ticket real fast and maybe this approval won't be won't happen with as much scrutiny as it should. And while this might be true in some cases overall what we found with our client was that this pair approval process increased the quality of the data, and the understanding of change.

So just knowing that someone else is going to be looking this over actually helped people to think about what they're writing and put a little bit more thought into how they were filling out the different fields.

Another approval group is the Change Advisory Board. On the other end of the spectrum the CAB will look at a high-quality request later in the approval workflow. So after the change has been approved by a peer, the CAB will look at it and basically just put more of their energy into focusing on the decision that has been made and the scheduling around the change.

Also having a defined process can help reduce confusion on how these changes are happening. When you have a process that is very general and doesn’t really have a lot of different options for different types of changes, which might work at some organizations, if your organization has a lot of types of changes that really do need to be handled in different ways having a defined process, while it might seem like there's more overhead around that, it actually reduces confusion because people know exactly what they need to do for what they're trying to get changed.

this is a diagram of what might be happening during an approval process: you start with the person who requested the change and maybe you first have it approved with a peer. and this is really just to make sure that the ticket looks good and then maybe after that you move on to an approval from another group maybe your CAB or maybe more of an unofficial group of approvers, or managers who have some experience with these types of changes and we'll be able to give feedback on whether there might be any serious problems with the implementation and after that you would move forward with the change.

This is a diagram of the process that we implemented with our client. I'm not going to get into too much detail on how this logic is configured but you can tell that there's three different paths that a ticket travels along. So these three different paths stemming from the open status match up with standard, normal and latent changes.

So you can see on the left is a transition call to validate emergency change: this would be for changes that have already happened but people will create a ticket afterwards and move it through this process just so that the change has been documented and tracked.

Then we also have standard changes so this would be in this middle path we're really there's just an internal review process and after that the change immediately move to in progress where it can be worked on.

On the right we have the process for normal changes so this is something where we would have multiple approvals to really make sure that the right data has been collected before the teams to get moved all the way to the Advisory Board.

By having approval steps before this really just helps to validate that the change ticket is ready for the change Advisory Board to evaluate, since they don't meet as often as other teams and you really want to make sure that the approvals can happen as quickly as possible.

So by have a few quick checks beforehand helps the ticket move through the workflow so it can move to in progress as quickly as possible.

This is a screenshot of what does approval looks like when someone receives it in Jira. When you select someone as an approver they can get a notification which will bring them to this screen and it will basically give them all of the information that was added to the ticket and then give them the option to approve or decline the request.

Now once the approvals have all done through, and the change has been implemented, at that point you're going to want to make sure that you're maintaining a change record.

There is a few reasons that you want to have a change record available: so what are these things is reporting and dashboards this can help you understand what's coming up in your schedule what changes are about to happen and basically keep track of what's going on in your change management processes.

Here is an example of a gadget or a conference macro you could add: It's a change calendar, and this particular one is called team calendars for confluence. This is a type of reporting will basically be pulling all of your Jira issues that are change tickets and display them on a calendar so you can have an idea of what's been done and what's coming up in the future.

Change records can also be used to diagnose things that might have happened. One example that came up with our client was they knew that something big happened around the holidays. There was something strange and they couldn't figure out what might have changed to cause this new behavior in their systems.

So what they were able to do was these reports in these calendars and basically filter through and understand what changes happened during the time frame that they start to see this behavior, and this really helped them to troubleshoot their problem.

Another thing that you might want to do is use these dashboards to find bottlenecks in your process. When changes are moving through these workflows and coming through different approval steps, it’s important that this happens as efficiently as possible.

Different reporting tools can be used to understand where tickets might be getting held up.

Here's an example of what these dashboards look like in Jira: So right here we have some gadgets that show you different tickets that are in QA review. By using these types of gadgets that break tickets down by status, you can see also there's a pie chart that shows different types of tickets, you can create these based on change type for example.

This type of reporting gives you a really good idea of how things are working in your change management process and whether or not there's tickets that are getting held up in different statuses.

Overall, using these types of techniques with our client really helped them to make their changes with higher quality, as well as record more data. Overall the project was a huge success and was picked up really well by everyone who is implementing these types of changes.

With that, I would love to hear any questions that you might have.

Alright our first question:
How do you deal with tickets there forever waiting on an approver?
All right so good question! This is actually something that came up with the team when they were rolling out this process, and it kind of depends on what step of the workflow you're looking at. For example with the Change Advisory Board that something that people should hopefully be able to plan for for those big changes and wait for that CAD meeting if possible, but for other changes, or for other steps of the workflow like peer review, You can always change the approver. For example if you find out that the person that you picked is on vacation or isn't the right person to be looking at the ticket, you can always go into the Jira ticket and edit it and edit the approvers field and then it'll actually resend the approval to someone new.

Next question: Some of our IT staff aren’t familiar with ITIL definitions like change type: how can they understand what to select as their change type when creating a ticket?
This depends a little bit on the background of your team. One thing that you could do is put up an article on Confluence that explains this. You could have training for your team to walk through these different definitions. But I understand that a lot of people will forget about it and by the time that they have to create a ticket they're going to want to have that reference information available so besides adding more definition text to your fields in Jira. you can also do things like the dashboard, you could use the text blurb gadget in Jira and write out that information there, but physically having it somewhere that people will quickly think to reference it is probably the best bet.

How do you ensure the onboarding process for this new platform would go smoothly?
What our client did was, well there's two main things: one was they had an internal advertisement so basically just communicating this to the team in a way that made sense for them. And then also really important was the management and stakeholder buy-in, so making sure that everyone understood the new process and was on board with it and had approved it, that was important for the success of the new platform.

The last question will be able to answer today: Did you find adding more approval to your workflow slows down the change process?
Our client found that actually wasn't really the case. A lot of that he attributed to the fact that there was less confusion around the process. People were less likely to procrastinate and have to ask around and understand where to go to get the right approvals and what not. Having all of that more explicitly out there helped people to get the change started; not only that but they also found that with this new process, the changes were also implemented with a higher quality. There were less mistakes, less having to go back and go over things again. Overall they found it wasn't really a problem in terms of having to wait on those approvers.

Joseph Lane: Don't forget: Mark your calendars for next webinar: Project management with Atlassian and Tempo with Morgan Folsom, senior consultant.

That’s a wrap folks, thanks for joining us today, we’ll be sure to send a recording of this webinar soon so be on the lookout for that.

Webinars

Past Webinars

Case Studies

Blog