The importance of Change Management within an IT Service Provider is generally well understood. The need to document, evaluate, approve, schedule, and ultimately govern changes to services or IT Infrastructure is well documented. Generic process flow templates are widely available, a wide variety of suitable tools exist to support the process. So, why do so many organizations still struggle with this?
Organizational culture is also frequently cited as a culprit. Lack of management commitment is another one (and, in fairness, will sink a Change Management initiative every time). It’s easy to paint the causes of failure with a wider brush and say “People” issues are the root cause. While all of these areas are important to consider, I’d like to suggest that the leading cause of ineffective change management is, ultimately, ineffective process design.
When we think about change management, what kind of changes come to mind? Changes to hardware? Upgrading a piece of software to a new version? Releasing a new service into the live environment, or deploying equipment to a new user? All of these things fall squarely in the middle of the Change Management process, at least in terms of process scope. Once the process is in place, the tools have been deployed, and management commitment has been communicated, these types of changes rarely present significant issues.
However, the key to a successful and effective Change Management program lies in the ability of the process to handle the changes which occur around the “edges” of the process scope – not just the middle. A few examples:
- What happens when a System Administrator needs to make a change to a setting on a server? Does that fall within the scope of the Change Management process, or do we view this as routine operational “tuning”?
- What about desktop moves (i.e. moving an employee to a new office or cube)?
- What if I need to increase the allocated space on a shared drive (i.e. enterprise storage)?
In order for Change Management to be effective, ALL of these changes are likely to be included in the scope of the process!
The problem with such a zero tolerance approach to unauthorized/uncontrolled change is that it has the potential to be unwieldy and bureaucratic. After all, changes like the ones listed above occur on a (more or less) constant basis in most organizations, and the suggestion that each instance would require a formal approval process is likely to bring the IT staff out of their cubes with torches and pitchforks.
This is precisely why the ITIL Change Management process describes three types of change: “Normal”, “Standard”, and “Emergency”. We’ll save the discussion of Normal and Emergency changes for another article. Properly implemented, Standard Changes can be the most powerful tool you have to reduce bureaucracy and streamline your Change Management process.
ITIL defines a Standard Change as one for which the approach is preauthorized by change management. In addition, all Standard Changes have the following characteristics:
- Standard Changes are low cost and low risk.
- The little risk that does exist is always well understood.
- Standard Changes are frequently occurring.
It is worth emphasizing that “preauthorized” is not the same as “unauthorized”. In other words, this isn’t just a license for ad hoc change. Let’s look at a practical example – an office move.
Joe Employee in the Marketing Department needs to move to a new office. So, he calls IT (hopefully the Service Desk) and puts in a Service Request to have his equipment moved to the new location. The Service Desk logs the request, and assigns it to the Desktop Support team for completion.
Upon receiving the request, the Desktop Support agent recognizes that this is a change to IT Infrastructure and opens a Request for Change (RFC) in the organization’s ITSM platform. Since this change meets the requirements listed above (low risk, frequently occurring, well understood), the agent feels that this should be a Standard Change.
If a Standard Change does not already exist for this activity (a desktop move), the Desktop Support Agent will log the change as a Normal Change. This means the change will require approval from a Change Authority before it can be executed. However, since the Desktop Support Agent is thinking ahead, she will also submit a request to have this change included in the list of Standard Changes for the future.
This request to “canonize” the change in the list of Standard Changes will include an explanation of why the change meets the aforementioned requirements (low & well understood risk, frequently occurring, low cost), in addition to very detailed work instructions as to EXACTLY how the change is performed. If the Change Advisory Board (CAB) agrees with the Agent’s assessment of the change, they will approve the request and add it to the list of Standard Changes.
This, of course, makes no difference to Joe Employee – his change had to be processed as a Normal Change, as no Standard Change existed at the time of the request. However, the next time someone requests a desktop move, the Standard Change will be an available option.
Let’s assume a Standard Change did exist when Joe Employee made the original request. In that scenario, the Desktop Support Agent still opens an RFC. However, she is then able to classify the change as a Standard Change, allowing her to select the appropriate preauthorized change from the dropdown menu in her ITSM tool. She assigns the RFC to herself, performs the work, and closes the change.
What we have accomplished here is to make the Change Management process substantially more robust. The change is controlled, documented, and auditable. The integrity of the CMDB is preserved, as the RFC resulted in a record update indicating that Joe Employee is now in a new location, on a new VLAN, connected to a different switch. We have accomplished all of this without impeding the ability of the IT staff to actually get work done, and the Change Management process is stronger because people are not forced to go around it in order to perform routine tasks. Over time, the list of existing Standard Changes will expand as the Change Management process matures and the organization gets a better handle on which activities are good candidates for the list.
Regardless of anything else we do, most organizations are just one unauthorized change from a disaster scenario. With the increasing size, complexity, and criticality of modern IT environments, high performing organizations must embrace a zero tolerance approach to unauthorized change. Standard Changes enable this to happen in a way that is practical and scalable.