Latest Articles

From RCA to Remediation — How Problem Tasks Structure Your Problem Management Workflow What Are Problem Tasks? Problem tasks break down problem investigation and resolution into manageable, assignable units. They enable: Clear accountability for each part of the resolution Parallel work on different aspects of the problem Tracking of progress toward resolution The Role of Problem Tasks in the Workflow Problem tasks are the building blocks of problem resolution: Problem detected: The problem record is created Problem tasks created: Work is broken down into assignable tasks Tasks assigned: Each task is assigned to the appropriate team or individual Tasks completed: Each task is worked and completed Problem closure: All tasks complete, problem resolved Types of Problem Tasks Task Type Description Example Root cause analysis Investigate the underlying cause Complete 5 Whys analysis Investigation Gather data and evidence Collect logs from affected systems Remediation/Action Plan Develop the fix Create change request Verification Confirm the fix works Test the fix in staging Implementation Deploy the fix Apply the patch Documentation Document the resolution Update knowledge base Best Practices for Problem Tasks 1. Standardized Task Types Use consistent task types across problems This enables reporting on where effort is spent Makes it easier to identify bottlenecks 2. Clear Accountability Each task should have a clear owner The owner is responsible for completing the task No task should be left unassigned 3. Cross-Functional Assignment Different tasks may require different expertise Assign tasks to the appropriate team members Ensure no single person becomes a bottleneck 4. Dashboard Tracking Track open tasks, overdue tasks, and completion rates Use dashboards for visibility  The Problem Task Lifecycle Stage Description Created Task is created and assigned In Progress Work has started on the task Blocked Task cannot progress due to dependencies Completed Task work is complete Verified Task outcome is verified Governance Models Problem Manager owns the workflow: Overall accountability for problem resolution Technical SMEs update work notes: Technical details are captured accurately Regular reviews: Task status is reviewed regularly Scaling Across Multi-Regional Teams When problem management spans multiple regions: Use consistent task types Standardize documentation Clear handoff processes Timezone-aware assignment Conclusion Problem tasks provide the structure needed for effective problem resolution. By breaking down complex problems into manageable, assignable units, organizations can ensure systematic investigation and resolution. Action Items for Your Organization Define standard problem task types Create clear accountability for each task Implement dashboard tracking Establish governance models Measure task completion time  

Headline: Stop Reviewing Technical Details Alone — Every Change Should Start with Business Impact The Context Problem One common failing in change management is that the CAB lacks the context needed to make informed, risk-based decisions. The CAB cannot determine whether a change deserves priority over competing requests or whether the maintenance window is appropriate. Business Context First COBIT 2019's BAI06 practice recommends evaluating change requests against business case alignment before technical feasibility. Every change request should open with a business impact statement before any technical details appear. Key questions: What business capability does this change affect? What happens if we do not make this change? What is the blast radius if this change fails? Creating a Business Service Catalog A business service catalog links technical components to business capabilities: Business Capability Technical Components Order Processing CRM system, payment gateway, inventory DB Employee Onboarding Active Directory, HRIS, email system Customer Support Contact center, knowledge base, ticketing Linking Change Management to the CMDB The CMDB should be the foundation of change impact analysis. When a change is proposed, the system should automatically: Identify affected CIs Show dependent services Assess business impact Identify stakeholders Automating Business Context Use automation to populate business context: Technical impact: Automatically pulled from CMDB Business impact: Derived from service relationships Stakeholders: Automatically identified from service ownership Training Change Submitters Change submitters need to understand what business context to provide: Training topics: How to write business impact statements How to identify affected business capabilities What information the CAB needs The Business Impact Statement Template text Change: [Brief description of the change]   Business Capability Affected: [What business function or service is impacted?] Impact if Not Done: [What happens if we don't make this change?] Blast Radius if Change Fails: [What is the potential business impact if the change fails?] Business Priority: [High/Medium/Low] Business Owner: [Who is accountable for the business impact?] Conclusion Prioritizing business context in change enablement ensures that changes are evaluated based on business impact, not just technical details. By linking change management to business capabilities, organizations can make better decisions about which changes to approve and prioritize. Action Items for Your Organization Create a business service catalog Link change management to the CMDB Require business impact statements for all changes Train change submitters on business context Use automation to populate business context

The Three Types of Change — Standard, Normal, and Emergency Headline: Not All Changes Are Created Equal — Why Categorization Is the Foundation of Change Enablement The Three Types of ITIL Changes To increase efficiency, ITIL defines three types of changes with different approval authorities and processes . 1. Standard Changes Definition: Low risk, pre-authorized, well-understood changes that never cause an incident . Characteristics: Pre-authorized: Once certified, no further manual approvals needed Well understood: Detailed work instructions, trained and certified personnel Repeatable: Follow the same process each time Low risk: Never cause an incident Change Authority: Change Manager defines Standard change requirements. Once requirements are met, RFCs receive automatic change approval in the future . Examples: Regular software patches Security updates Password resets Standard user access provisioning Change Schedule: No  2. Normal Changes Definition: Changes that require thorough planning and execution and carry higher risk . Characteristics: Require risk assessment Need approval before implementation May require thorough planning Should be scheduled Change Authority: Change Advisory Board (CAB) with input from other practices  Examples: Major software upgrades Infrastructure changes New system implementations Configuration changes with potential impact Change Schedule: Yes  3. Emergency Changes Definition: Changes that must be implemented as soon as possible to resolve an incident . Characteristics: Urgent: Must be implemented immediately Incident-driven: Necessitated by an incident Expedited approval: Follow an expedited approval process Change Authority: Emergency Change Advisory Board (ECAB)  Examples: Critical security patches Immediate fixes for service outages Emergency workarounds Change Schedule: No  Moving from Normal to Standard As change success patterns emerge, organizations should move Normal changes to Standard status. This reduces approval overhead and accelerates delivery. Criteria for standardizing: Proven success (no incidents from implementation) Repeatable process Well-documented work instructions Trained and certified personnel Conclusion Categorizing changes appropriately is the foundation of effective change enablement. By matching change types to the right approval process, organizations balance speed and risk—enabling faster, safer changes. Action Items for Your Organization Review your change classification criteria Identify Normal changes that could become Standard Document Standard change procedures Establish Emergency change procedures Train your team on change types

The 80/20 Rule of Problem Management — Fixing Root Causes Eliminates 80% of Recurring Incidents The Two Faces of Problem Management Problem Management has two distinct sub-processes: Reactive Problem Management: The goal is to identify the root cause, or provide suitable workarounds, of known incidents  Proactive Problem Management: The goal is to identify and eliminate the root cause of incidents, or provide suitable workarounds, in order to prevent their recurrence  Reactive Problem Management Reactive Problem Management is triggered by incidents and aims to: Identify the root cause of incidents that have already occurred Provide suitable workarounds to reduce service interruptions Document known errors for future reference When to use reactive problem management: When a major incident has occurred  When a pattern of recurring incidents emerges  When monitoring events indicate an underlying issue that should be addressed  Proactive Problem Management Proactive Problem Management aims to: Identify and eliminate root causes before incidents occur Use trend analysis to detect emerging issues Continuously improve service stability When to use proactive problem management: During routine monitoring and trend analysis When reviewing incident patterns As part of continuous improvement initiatives The Business Case for Proactive Problem Management The economic case for proactive problem management is compelling. Research shows that problem management delivers measurable ROI: Benefit Area Impact Incident volume reduction 4-6% decrease in total incidents  Time for incident solution 95% reduction in incidents exceeding 5 days  Solver team capacity savings 5% increase in available capacity  Reduced severity of incident impact 3% reduction in impact severity  Increase in end-user satisfaction 2-3% improvement  The ROI of Problem Management A documented business case demonstrates the financial value: Direct savings include: Reduced incident solving costs Savings on SLA breach penalties First-line support efficiency gains Higher-level professional capacity savings  Indirect savings include: Improved service quality leading to higher employee satisfaction Reduced risk of incidents impacting the business  Quick Wins for Problem Management Organizations can achieve quick wins by: Internal education: Making common terminological language unified Separating Incident and Problem management: Clear distinction between the two Defining activities in each process: Clear, documented procedures Defining and measuring metrics: For both Incident and Problem management processes Automating the process: Leveraging software tools Quick start: Logging the first problem Regular reporting: Tracking progress Proactive Problem Management start: Moving beyond reactive  Conclusion The shift from reactive to proactive problem management is not just a best practice—it's a financial imperative. Organizations that invest in proactive problem management will see fewer incidents, lower costs, and higher satisfaction. Action Items for Your Organization Assess your current problem management approach—is it reactive or proactive? Separate Incident and Problem management processes Start logging problem records for recurring issues Begin trend analysis on incident patterns Measure the ROI of proactive problem management in your organization  

Headline: One-Size-Fits-All Change Is Dead — AI Personalizes the Journey for Every Employee The Personalization Imperative Change isn't just organizational—it's personal. Just as airline passengers may land at the same destination but recall the journey differently, employees experience change in ways shaped by their roles, contexts, and engagement . Employees want change that feels as intuitive and relevant as the technologies and services they use every day. Yet most change approaches still rely on one-size-fits-all tactics that overlook differing motivations, mindsets, and needs . The Data Gap More than two-thirds (67%) of leaders believe it is important to customize the design and experience of work based on worker skills, behavioral patterns, motivations, passions, and work styles. Today, workers are expecting that level of customer-grade personalization. But only 7% of leaders are taking action . AI is the key to closing this gap. How AI Enables Personalization AI-driven learning platforms deliver targeted content based on : Role: What does this employee need to know? Skill level: Where are they in the learning journey? Progress: What have they already completed? Learning style: What format works best for them? The result: Employees receive relevant guidance instead of generic training, accelerating adoption and building confidence . Personalization in Practice Example: Field Representative Training A field representative preparing for an upcoming customer conversation might turn to a coaching chatbot—not for scripted answers, but for a space to experiment. The representative could roleplay different scenarios with varied audiences, refine their message, and receive personalized feedback based on their tone, approach, and confidence level . Instead of static learning, the experience becomes dynamic—a personalized dialogue that builds skill, confidence, and ownership . Example: Personalized Learning Paths AI-driven learning platforms adapt content based on role, skill level, and progress. Employees receive targeted learning and support instead of generic training, similar to how platforms like LinkedIn personalize learning recommendations at scale . The Business Impact Organizations using AI for personalized learning and development report 73% more employee engagement . Personalization: Speeds up adoption Builds confidence Reduces frustration Demonstrates that the organization values employees as individuals Conclusion The next evolution of change is hyper-personalization: change journeys that adapt dynamically to each person's role, readiness, and response . By using AI to offer hyper-personalized change journeys, organizations can ensure people tune in instead of tuning out. Action Items for Your Organization Map employee personas for change audiences Implement AI-driven learning and communication platforms Develop personalized change journeys for different roles Use AI to recommend content based on role and progress Measure engagement and adoption by persona

Headline: The CAB Is Dead — Long Live the CAB: How Change Authorities Are Decentralizing Decision-Making The Traditional CAB In ITIL v3, the Change Advisory Board (CAB) was the main approval body for changes. It was typically a group of stakeholders who met regularly to review and approve changes. While this model ensured thorough review, it could also create bottlenecks and delays. The ITIL 4 Approach ITIL 4 introduces a more flexible Change Authority model with distributed decision-making . This doesn't mean the CAB is gone—but its role has evolved. The modern Change Authority model: Decentralized approvals based on change type and risk Delegated authority to teams for low-risk changes Automated approvals using AI-powered risk assessment CAB focuses on high-impact, business-critical changes only When to Use a CAB The CAB should be reserved for changes with: High business impact Significant risk Complex implementation Need for cross-functional coordination Modernizing the CAB 1. Expand Participation Instead of the same people meeting every time, use a "subject matter expert CAB" approach where participants are selected based on the change being reviewed. 2. Use Technology The modern change authority model uses tools to track workflows, backlogs, implementation, deployments, feedback loops, and collaborative processes . 3. Focus on Business Context The CAB cannot determine whether a change deserves priority over competing requests or whether the maintenance window is appropriate. Change requests should open with a business impact statement before technical details appear. 4. Automate Low-Risk Approvals Use AI-powered risk assessment to automate approvals for low-risk changes. The Evolving Role of the CAB Traditional Role Modern Role Approve all changes Approve only high-risk changes Meet weekly Meet as needed Static membership Flexible membership Focus on technical details Focus on business impact Conclusion The CAB is not dead—it's evolving. The modern CAB focuses on what matters most (high-impact, high-risk changes) and uses technology to speed approvals for everything else. Action Items for Your Organization Define which changes require CAB approval Establish automated approvals for low-risk changes Create a flexible CAB membership model Implement technology for change management Focus CAB on business impact, not just technical details