From the course: Putting ITIL® into Practice: Change Enablement

Why change enablement?

From the course: Putting ITIL® into Practice: Change Enablement

Start my 1-month free trial Buy for my team

Why change enablement?

“

- [Instructor] Let's define what we mean by a change. At its core, a change is anything you add, modify, or remove from one of the configuration items that make up a service that can have a material effect on that service. I will define four dimensions of items that comprise services, four categories for where to look for risks and impacts, and a whole lot more. Organizations and people, information and technology, partners and suppliers, and value streams and processes. Memorize and use these dimensions in your change enablement practice to make your approach more holistic and idle aligned. Changes can occur and services may be impacted by changes in any of the four dimensions that make them up. Adjusting one dimension often necessitates changing in another. For instance, modifying a technical architecture, information and technology, may require staff training, organizations and people. What should become clear from these definitions is that we're talking about change enablement, not just change control. This practice focuses on balancing agility and control, ensuring that changes contribute to business value while minimizing disruptions and risks to services. It applies to all types of changes, including standard, normal, and emergency changes. Having said that, apply these techniques to only major and significant changes. They're overkill for standard, minor, and emergency changes. Significant changes need CAB review, as their complexity requires expert advice for good decisions. Major changes demand business approval due to their major risks, costs, and impact. The activities of these techniques are still applicable to standard and minor changes, but in a vastly scaled down way with fewer actors involved due to the lower risk, cost, and impact levels. Standard changes are routine, they're low risk and pre-approved. Minor changes need only the change manager's approval. Emergency changes require swift action through a separate workflow. The key to good change enablement is to keep just enough eyeballs on each type of change to make good decisions. Don't over-involve people. Don't consult them when they only need to be informed. Doing so stalls change instead of enabling it and wastes people's time. Balance is key. Never rush into changes without assessing risks, costs, and impacts across all four dimensions. But don't get stuck in analysis paralysis. Waiting for perfect data can mean no action or action taken too late. Effective change enablement means balancing the considerations of risks, costs, and impacts with delivering the changes stakeholders need quickly so they can begin to realize value from them. Aim for just enough analysis to gain a sufficient insight and spark timely action rather than for perfect insight. Do this because the effectiveness of your decisions and actions in making changes and the value stakeholders can realize is time-bound, like a mariner's decision to change course. And the sooner you deliver needed changes, the sooner your stakeholders will benefit from them. Change enablement is about creating a better reality by making the changes stakeholders need so they can begin to realize value from them. But getting a better reality isn't enough. You must also seek better perceptions from stakeholders through how you enable changes, ensuring they have good experiences when they interact with you as you do. Throughout this course, you'll see the same example of a collaboration service used as the basis for exercising each technique. Using a single example should help you better know the scope and applicability of each technique, how they fit together, and how you can use them as a set in your change enablement practice.

Contents