"What does change management have to do with ITSM?" Find out in this episode of Appfire Presents: The Best IT Service Management Show by Appfire.
Jira rockstar Rachel Wright joins Appfire's Kerry O'Shea Gorgone to talk about change management and ITSM. What if a customer request requires a change to a system or application? How you can create a path in the tools to link those things together? And how do you close the feedback loop and let the customer know you did the thing? Rachel shares valuable advice in this 10-minute episode.
About the guest
Rachel Wright is an entrepreneur, process engineer, and Atlassian Certified Jira Administrator. She wrote "The Jira Strategy Admin Workbook," and "The Ultimate Guide to Jira Migrations: How to Migrate from Jira Server to Data Center or Cloud". She's also a speaker, an Atlassian Community Leader and author of courses for new and advanced Jira admins and users.
She started using Jira and Confluence in 2011, became an administrator in 2013, and was certified in 2016 (the first year you could actually get certified). She's the owner and founder of Industry Templates, LLC, which helps companies grow, get organized, and develop their processes. Rachel also uses Atlassian tools in her personal life for accomplishing goals and tracking tasks. She wrote her first book, the “Jira Strategy Admin Workbook“, in Confluence and tracked her progress in Jira!
About the show
The BEST ITSM Show by Appfire brings you expert insights for IT service delivery, so your employees and customers have what they need to succeed. Get the right tech and tips for the right job at hand. Look like you’ve come from the future with all your new ITSM smarts. Every episode is a brisk 10 minutes—less time than it takes to provision a laptop or troubleshoot a tech support issue.
For your convenience, here is the transcript of this episode:
What does change management have to do with ITSM?
Kerry: We’re joined today by Rachel Wright, entrepreneur, process engineer, Atlassian certified Jira administrator, author. She’s going to talk with us about what change management has to do with ITSM. Stick around for the next 10 minutes and you’ll get a whole lot of insight.
Rachel, change management, what does it have to do with ITSM? In fact, what even is it before we get that far?
Rachel: I’m excited to talk about it. I feel like of all the things that ITSM brings an organization, change management gets the least amount of love. That might just be because it’s hard to implement a good policy sometimes.
Also, there’s reactive planning and there’s proactive planning. At first, we’re all working on the reactive side, and it takes a little while in an organization to be able to sit down and actually create something that we’re going to actually be proactive about this, we’re going to try to prevent issues instead of just responding to issues.
Does that answer your question?
Kerry: I was thinking change management at some organizations is like here’s a memo about something you need to stop doing, so let’s implement this change.
Rachel: Right. Traditionally, it’s set up for IT infostructure, but really any organization can benefit from some of the same standards, procedures, and methodology that IT would use.
That memo is the very lowest way you could potentially manage change. The problem with the memo is it gets recycled in the recycle bin or it gets filed away in an email and who knows if anyone is actually adhering to that new request.
We could use tools like Jira, Jira Service Management, to document what we changed, how we changed it, were there any problems or incidents that occurred because of the change. Or maybe the change is because there was a problem or an incident and we need to change something about the way our systems work or something that is considered risky, and we want to really understand the change and know that there is oversight and people making sure that the change didn’t cause downtime or other problems.
Kerry: So, change management then is when you have something sort of significant that you’d like to do that affects and involves a lot of people, and then you decide proactively how you’re going to do it instead of just firing off a memo.
Rachel: Right. It’s managing the risk. Every time you change anything, no matter what you’re changing, there is a risk. It’s tracking that, tracking the progress of that, and also just being able to communicate between teams.
For example, if the development team is going to fix something really quickly without a whole lot of time or oversight, the operations team needs to know about that, and the customer service team should probably know about that, too, in case customers start calling in and asking why did this change or reporting that the change has negative adverse events for them.
Kerry: It sounds like maybe you need a process for this.
Rachel: Absolutely. When you’re crafting your process, be careful about creating too many bottlenecks. If you’re in an industry that’s highly regulated and you have a lot of compliance guidelines, your process might be a little bit dictated for you already. If you’re not and you have some freedom, concentrate on what the most important thing is for your organization. Is it ensuring communication? Is it creating a legal and authoritative historical record of what you changed? Really tailor your process to whatever those goals are.
Kerry: I’m thinking about where you would actually store these things for people to find them, because it’s very easy to forget that you had a half-started thing or a thing that you’re supposed to adhere to and you vaguely recollect it. Where do you put these things so people will find them?
Rachel: First of all, you have to set the expectation. You have to change the culture, that we don’t just go right into production and change something. That’s first. It doesn’t matter what your policy is if people just think that’s an okay idea.
I know when I started out and I was small, that’s what I did, too. There’s a typo on the website? Go into production and change it. But as you grow and as you have more people working in the same environment, that doesn’t work very well.
For me, I like to document it in our central repository. We use Confluence, but whatever system you use. Then there is a request process, so you actually file an issue in Jira or Jira Service Management explaining the change. Then someone is tasked with understanding it, reviewing it, helping to determine when this change should be done.
It’s a team effort, people are involved and informed. There’s none of these, “I changed something in the middle of the night and nobody knew about it,” kind of problems.
Kerry: Not to be devil’s advocate or whatever, but I know there are small things, like typos on the website, that you could spend all day fixing those and never actually do anything much for the company goals. How do you triage, which things need a whole process and which things do you give people agency to just do on their own?
Rachel: That’s a really good question.
Kerry: Maybe a typo is different than a software feature. Right?
Rachel: Absolutely. Or restarting a server. The impact is much larger, so that’s going to impact your customers immediately. That’s a very good point.
I generally collect some sort of risk assessment, and based on the scoring, or based on the potential cost, or based on the potential impact, you decide. You can use automation to do this. If the score is low, you can let the change request go through without as much oversight, or maybe without approval. If it’s higher, then you involve more people. That’s a great way to handle that situation.
Kerry: What tips can you offer for creating the right process for change management, since clearly there should be a process of some kind?
Rachel: Right. First of all, don’t let any tool dictate your process. Think about what your process is in real life and try to mirror that in your tool, whatever your tool happens to be where you’re tracking this. Tracking it at all is better than tracking it perfectly.
Keep in mind that you might need to have this information in the future, or you might need to use it to train a new systems admin. This becomes a historical record of what you did, how you supported people, and how your systems have evolved and changed over time. It’s definitely worth it to have this information not just to prevent future problems, but also to understand what you did.
Kerry: What does it look like when it goes horribly wrong versus when you get it right? Do you have any examples?
Rachel: I’ve never made a mistake in production. Never ever.
Kerry: Me neither.
Rachel: I’ll give you a couple of examples. I’ve only brought down Jira a few times.
Once, I was making a change in Jira Server to the announcement banner. If you’ve ever used that feature, you know that if you don’t close your tags, you probably prevent Jira from displaying information. It’s very hard. You have to go into the database and remove it in two places. Here I am writing my code in production and, of course, I miss a closing tag. That’s all it takes, really.
Another day, my cat jumped up on my keyboard while I was in there, and submitted the half-written code. Same thing, Jira doesn’t load, you have to go into the database.
How can you mitigate that? For me, write the code outside of Jira and then paste it into Jira when you’re ready.
Kerry: And put the cat outside.
Rachel: Have a talk with the cat and describe why his work performance is not okay. Little tiny things like that can just reduce some risk. Of course, not making changes in production first. Always have a hierarchy, make it somewhere else.
Then, like I said in the beginning, when you’re small and just starting out, there is a temptation to just make a change real quick and not log it. I’ve hurt myself in that. I’ve tried to see what did I change last year and why in the world is that setting the way it is, and I didn’t document it myself so now I can’t remember.
For me, it’s just vital to have that even for the changes that I make myself that aren’t impacting anybody else. I can’t remember what I did last year, so that helps me a lot to understand how far I’ve come, understand the problems that we used to have that we’re not having anymore because they were addressed, all sorts of good learning over the years.
Kerry: Be proactive, have a process, and don’t let the cat in the office when you’re coding in production. Is that about it?
Rachel: Generally, yes.
Kerry: Thanks, Rachel. This is The Best ITSM Show by Appfire. You can find more episodes at Hub.Appfire.com or anywhere you listen to podcasts. We’ll see you next time.