3.1.3. Change Enablement

💡 First Principle: To deliver improvements and new value successfully, an organization must balance the need for speed with the need for stability by managing the risk of every change to a production service.

Scenario: A developer wants to deploy a critical patch to a production application. The Change Enablement practice ensures the change is properly documented, the risks are assessed by the right people (Change Authority), it's scheduled to avoid conflicts (Change Schedule), and there's a back-out plan, maximizing the chance of a successful deployment without causing an incident.

• Purpose: To maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing a change schedule. This balances the need for change with the need for stability.
• Definition of Change: The addition, modification, or removal of anything that could have a direct or indirect effect on services.
• Exam Details: Change Authority assigned per type/model; role is pre-deployment approval. Flow: Assess -> Authorize -> Deploy. Change Schedule used for planning/avoiding conflicts. Handles Normal (needs assessment/auth), Standard (low-risk, pre-authorized, often via SRM), Emergency (urgent, expedited auth). Requires communication for risk assessment/preparation. Authorizes updates needed for incidents. Distinct from OCM, Release Mgt, Deployment Mgt.
• Practical Implementation:
  • Challenges: Balancing speed and stability, overcoming resistance to the change process, accurately assessing risks, coordinating complex changes, communicating changes effectively.
  • CSFs: Clear change types and procedures, appropriate change authorities, effective risk assessment methods, a well-managed change schedule, strong communication and collaboration.
  • Your Role: You might submit change requests, participate in risk assessments, implement approved changes, or be involved in communicating changes to stakeholders. Understanding the change process is vital for minimizing disruptions.

⚠️ Common Pitfall: Making the change process so bureaucratic and slow that teams try to bypass it, leading to undocumented and risky changes. The process should be tailored to the risk of the change (e.g., Standard Changes should be fast and simple).

Key Trade-Offs:

• Speed vs. Risk: The core trade-off of change enablement. An Emergency Change accepts higher risk for greater speed, while a Normal Change prioritizes risk assessment over speed.

Reflection Question: Why is it important to have different types of changes (Standard, Normal, Emergency)? How does this help an organization apply the "Keep It Simple and Practical" principle to its change process?