Every business is different, but generally, there are two IT service management (ITSM) areas that organizations...
turn to: change and release management.
- Change management is how IT makes changes to existing things.
- Release management is how IT introduces something new, such as a project, into the IT environment. Releases by nature include a significant number of changes.
To move from a purely reactive IT organization to one with some ITSM processes in place, look at the small changes first, build up to a change management process that is resilient in complex scenarios and then rely on that process for new things in release management. It's easiest to understand what's changing -- for example, to roll out a Windows update to all desktops -- in smaller projects.
Change management means the IT staff must understand who is affected and the business risks of a change, and they should have an approval process in place, as well as a plan for how to undo it if need be.
Getting your head around these basic change management steps for a task you already understand will help create habits that apply when dealing with more complex changes and lead into release management. If you can't do small changes right, don't attempt them at a bigger scale. Change and release management are anchored in good practices, regardless of scale.
When rolling out a change, get buy-in from your immediate team, whether that's IT operations, IT engineering, developers or another small group, as well as from other teams, on what everyone thinks is acceptable. You'll set everyone's expectations, which is a pattern that will flow from changes into release management.
Embrace change on the right terms
There's nothing wrong with deciding, as a group, that certain changes to the IT deployment are low-risk and need little or no oversight. If the business can keep running even in a worst-case scenario after these changes and the effects won't damage the business in the long term, then those certain changes can be carried out with the least amount of red tape possible.
Even the smallest of changes should be documented and communicated to affected users in a change management process, however. A change's effects and dependencies sometimes aren't known until long after it occurs. A change and release record enables anyone to assist in diagnosing when a problem started or the root cause of an incident.
Once you have a general change management methodology laid out, consider how the communication will actually happen. Will you need approvals, workflows, forms? What happens when someone's on leave? You might be fine using pure email communications or discover that a more complex and robust solution that controls the experience is better for all involved.
Change and release management is the main focus of this foray into ITSM, but it is likely you're getting pressure from the rest of the business on incident management. IT organizations in reactive mode are often seen as too slow to respond to and resolve incidents. If incident management is your ITSM sore spot, then it should be your focus to improve first, before change management and release management.
Pushing for more procedures is going to be met with resistance around resourcing and time, and you'll most likely be left with processes that aren't followed, along with unhappy employees. Focus on improving incident management as well.
Does change, release and incident management process flow work need to happen before you invest in a configuration management database (CMDB)? They're projects that can be done separately. An organization can implement change and release management without a CMDB, but it's more risky. The fact that rebooting Server A will create outages for Services X, Y and Z, for example, might be something that's picked up in a change request, or it might not. A CMDB enables anyone to check what the relationship is between any pieces of the puzzle that make up the IT environment. On the flip side, CMDB selection, setup and maintenance are big tasks, and it can be hard to justify ample resources for them. This is a risk analysis and management decision.
There are many change and release management options out there, as well as more in-depth ITSM platforms, but until you know what you're looking for in processes, you'll be taking shots in the dark at choosing the right one. Once you make an informed decision, keep working at ITSM maturity. An off-the-shelf product doesn't provide an instant framework to follow, because every business is different.
Dig Deeper on Application Rollout Planning and Problems
Related Q&A from Adam Fowler
While basic monitoring services and feedback loops provide critical insight for DevOps teams, an end-to-end monitoring tool gives them a more ... Continue Reading
Outlook crashes and rendering issues might require an upgrade -- or a downgrade -- for administrators who want to avoid a Band-Aid approach and want ... Continue Reading
What are some ways to level up from an IT operations or administration role into an IT engineering one? Will my experience in IT operations ... Continue Reading