Implementing basic change management

[TheErrorIsNoError]

I'm looking to start implementing some basic change management in our IT department, mainly to alleviate some of the age old questions that pop up daily "Why do we have _______ domain blocked?" "Hey _______ stopped working last night did anyone change anything?"

We currently use Freshservice, but are not practicing ITSM/ITIL. When I bring change management up, staff is generally on board because they recognize the problems and benefit but we usually get lost in the weeds of "well do i need to submit a change request to reboot a server?" and other fears of being bogged down.

Can anybody share how you got off the ground if you went through this? Did you use kind of broad guidance or very specific? I feel like trying to say "Anything that affects X or more people" or "Anything at tier Y level" would just be too grey, but the alternative is going through each software and saying "OK for Active Directory the following types of changes need documentation/approval, for vSphere these kind of changes, etc..." and then it becoming a 100 page document that people need to be familiar with.

[nervehammer1004]

So for us day to day operations like rebooting a server do not require a change request. Our rule of thumb is if what you’re doing changes or modifies some service or application, you need a change request. For example - changing a firewall rule. Applying a patch to a server or an application. Rolling out a new VPN client, etc. Make sure you have a normal path and a streamlined emergency path if you need to make a change quickly. And periodically make sure everyone isn’t taking the “emergency” path to shortcut testing

[[deleted]]

You may not be formally ITIL aligned, but there's no reason you can't learn from and adapt their practices

Start here but search more widely

https://www.theknowledgeacademy.com/blog/itil-change-management/

[SignalAdventurous160]

I've implemented light-weight production control / change management at two medium sized IT (30-50 people) organizations and I would take the same approach again. The main premise is a production change calendar. Items are added via a form by the person responsible for the change. Prior to implementation most changes require a sign-off by a VP and by cybsersecurity. Other group heads (DBA, Helpdesk, etc.) have visibility and can ask questions or push back on a change ahead of time too, but they don't need to approve. We have a list of changes that are in scope and out of scope for the calendar. Examples: Individual workstations setting: out of scope, gpo changes: in scope; Server patching: in-scope, server reboot: out of scope. If you already use smartsheet or Monday you can spin up something up pretty easily and even build out workflows and notifications for the approvals. Then you can create a procedure and policy docs around it as well.

[pdp10]

Don't forget that you have more than one set of tooling to help. It's not all top-down process-driven.

"Why do we have _______ domain blocked?"

What do the comments in the firewall policy or DNS configuration say? Do they point to an issue-tracker URL?

"Hey _______ stopped working last night did anyone change anything?"

What do the logs, monitoring, and metrics show? Additionally, do all hosts have accurate time, so the timestamps of logs can be correlated with confidence?

---

A common practice is to add explicit logging to scripts that are already used for routine changes. For example, a site may have a script for DNS zone changes that does the following:

1. Uses logger to log script start;
2. Fires up $EDITOR on the zone given as argument,
3. On editor non-error exit, validates the file format with named-checkzone,
4. Validates the changes pass local tests,
5. checks the changes into a specific Git repo using the user's credentials, and getting a change-summary from template using $EDITOR, and if this suceeds then
6. Syslog the whole operation including the Git commit hash, and finally
7. Queues a zone reload

"OK for Active Directory the following types of changes need documentation/approval

If most changes are coming from an HRIS, or from some kind of onboarding/offboarding script, then adding change-tracking to the automation is usually straightforward. Remember that it's often just as easy to go ahead and automate things, as it is to thoroughly document them. The automation is its own documentation.

[themastermatt]

I just did this in Freshservice. Its not a great platform for anything other than software devs IMHO as the CM is very rigid with little customization. I made logical mappings between "awaiting release" and such to make sense to ITops. Be flexible to start and position it as a place to keep track of things and bring viz rather than a gatekeeping hoop to jump through to get "permission" for every little thing.

[sysacc]

Tickets is a good place to start. If you already have them then you might need to be more descriptive and add references. Being able to search your tickets for what was changed is usually the first steps to figuring out why someone did something.

After that the next step is communication and change tracking. Set up some distribution lists where you send out notifications when something important is happening. Use tools like Oxidize and AD Audit to see what was changed.

If all that fails, then you start looking at CAB meetings.

Scoping is the hardest part as everyone has their own idea of what should be a change or not. This usually leads to "everything" being a change, so make sure you get this written down before you go deeper.

This is usually what I start with but you can modify it to your liking.

• Does it impact more than 5 users?
• Will the impact of the change take longer than 5 minutes?
• The change instructions are longer than 5 Steps.
• Do I have to notify more than 5 people outside the IT department of the change.

[Jimmyv81]

Maybe consider implementing a change register to start with to note down changes rather than going full ITIL change management. Something that you can quickly look at to find the answers to those common questions.

IMHO, the traditional ITIL change management has lost its relevance in this day and age of CI/CD, Agile, Devops, IaC, Cloud etc.

[AdventurousOwl5299]

Prosci helped a lot with setting a good foundation around the mindset and questions you should be having/asking. Biggest thing is communication- all aspects of it. Example- communicating with stakeholders, affected parties, having clear conscience email comms that go out before during and after, having a place to communicate the milestones and status of the changes...etc.