Change management is arguably one of the most important processes in ITSM. One mistake in the process can cost a company millions of dollars. It’s straightforward in theory, but can have major organizational consequences if it’s not done correctly. Over the years, I’ve seen a variety of companies who have made vital mistakes in their process. As organizations look to implement and sustain their change process, I wanted to share some of my observations to ensure success.
1. Configure vs. Customize
It’s important to define what I mean by configure vs. customize. For example, in your change management process, configuring would be setting system properties for the change_request table to true/false. Customizing would be scripting a business rule that references a 1,000-line script include. For the most part, avoid customizing at all costs. Once you start adding dozens of scripted business rules, parts of your process start to contradict itself. This can break existing processes, make it difficult for your developers to figure out what is causing defects, and is the gateway to a disastrous change process. To say the least, things get out of control quickly with customization.
2. Business Rules and Conflicting Workflows
This one is a recipe for disaster and goes against best practices on the platform in multiple aspects. For example, let’s say you have a workflow that is setting the state on a change request, but a business rule that is preventing a state change from happening and aborting the database action.
I can’t tell you the number of times I’ve seen these lines cause issues between workflows and business rules:
3. Required Fields Developers and engineers don’t like documenting changes, especially when they have to fill out thirty required fields on the form. Before you go making every field on the change form required, ask yourself:
A feature which I like to add to all change processes is a “Save as Draft” UI action on the change request form. The use case for this being, when requestors start documenting the change, they often don’t always have the initial data required, but still, want to save their change for later editing.
4. Over Complication
If your change process spans multiple pages with dozens of workflow activities and paths, your change process is likely overcomplicated. Over the course of time, it’s easy to let this process grow exponentially. Don’t let this happen. It’s important to scrutinize every single enhancement request to modify this workflow. In fact, I would only recommend modifying change workflows very rarely once you have it in a steady place.
The purpose of the “show workflow” UI action is to allow your end users to have a visual and comprehensible view of where their change is in the process. When this starts to look like an intricate engineering diagram, people immediately get frustrated with ServiceNow.
5. Data Policies
Data policies are excellent for maintaining data integrity. Unlike client-side UI policies which can be bypassed with certain user action, data policies run server side. Data policies enforce required fields even on list views, which will ensure you have quality data for reporting and compliance purposes. Always use data policies for change management instead of UI policies.
When it comes to change management notifications, less is more. I personally think the OOB notifications provide more than enough detail to end users. Each additional notification you add on increases the likelihood that change requestors will set up an email filter for these notifications.
A nice feature I like to add when implementing change management is having these emails send from a unique email address and not using the default system mailbox. Setting the “From” address to your organizational change process email address ensures that previously created end-user filters are not honored.
Quality data in your CMDB is important for all aspects of ITSM. However, it is an absolutely vital piece of ensuring your organization is practicing effective change management. Although there is an extensive list of best practices for maintaining quality data in your CMDB, some things to look out for as it relates to change management are:
8. UI Actions
The default UI in ServiceNow can be a lot to look at. A clunky form view in combination with the application navigator is a lot for an end user to visually consume. When possible, always try and add net new UI actions as related links. And if you have to add new form buttons, always try and avoid showing more than three at a time on the header and keep the verbiage on the button at a maximum of one to two words.
9. Stuck Workflows
Every developer or change process owner has probably heard “my change request is stuck” at one point or another. Often times, the change may not actually be stuck, but rather, a confusing process has been put in place. To avoid this situation, always follow the rules below:
This post was originally published on Josh Brostoff’s blog post here.