I'm trying to kick off some basic change management practices in our IT department to tackle the frequent questions we face, like "Why is the _____ domain blocked?" and "Why did _____ stop working overnight?" We're currently using Freshservice but aren't formally adhering to ITSM or ITIL methodologies. While my team generally supports the idea of change management, we often get stuck debating whether routine actions, like rebooting a server, require a formal change request. I'm looking for advice on how to implement this effectively without making the process overly complicated or cumbersome. Should I go with general guidelines for what needs approval, or get into specifics for each system? Any insight on what works would be greatly appreciated!
5 Answers
Remember, tools aren’t just about processes. When users ask why something is blocked or isn't working, check your firewall policy comments or DNS configurations for hints. Logs and metrics can also be your best friends in tracking changes. Automate where you can - adding logging to existing scripts can serve as documentation, and it can often be just as easy to automate a change as it is to keep track of it manually.
For us, routine tasks like rebooting a server don't require a change request. We stick to a rule that says if you're making a change to a service or application, like modifying firewall rules or applying patches, that's when you need a request. It's also good to set up both a normal process and a quick emergency path for urgent changes. Just make sure that your team isn't abusing the emergency route to avoid proper testing.
Even though you're not formally aligned with ITIL, you can still adopt some of their practices. A great starting point is to create a change management calendar. Changes should be logged via a form, and important modifications require sign-offs from higher-ups and cybersecurity. Visibility for other team leaders helps too, as they can raise concerns without needing to approve every change. Having a clear list of what's in and out of scope for changes is essential - for instance, workstation settings might be out of scope, while server patching would be in scope. Tools like Smartsheet can help organize this easily.
I've recently implemented change management in Freshservice, but it's quite rigid and not super customizable for general IT operations. I found making logical connections in the system, like between statuses such as "awaiting release," helps a lot. It's better to approach it flexibly and frame it as a tool to track changes and provide visibility rather than a bunch of red tape around permissions.
You might want to consider starting with a change register to document changes instead of diving straight into a comprehensive ITIL approach. This could help answer frequent queries without the complexity and ensure you stay organized. From my perspective, traditional ITIL change management can feel outdated, especially in the era of CI/CD and DevOps, so keep it light to suit your team's needs.
Totally agree! Automation really streamlines the process. It can also help avoid the headaches of excessive documentation.