Problem Management for ITSD “Getting to the root of it” Thatcher Deane Feb 28, 2013

Overview  Where we are  Where we’re going  The Problem Process  Tool support: KBOX  FAQ  What’s next?  Questions

The Basics  Problem Management Provides a consistent methodology facilitating permanent resolution of the underlying, unknown cause of one or more Incidents. The primary Goals of Problem Management are:  Prevent Incidents from happening  Minimize the impact of Incidents which cannot be prevented from happening

Where we are  Current problem Process Is undifferentiated from individual Incidents Research buried in notes in one (or more) Incident ticket(s) Informal resource allocation to resolution No consistent or defined way to halt/suspend effort No tracked mandate to work on Problems No central place to see Problems Poor access to work around information

Where we’re going (1/2)  Problem Management Process Focused directed effort Time budget allocation and boundaries Standard Documented Process  Objectives  Roles  Metrics  Activities (down to Tasks and Prpcedures)  Tasks  Procedures

Where we’re going (2/2) Documented in the same format as other processes Statuses specific to work flow Use of separate KBOX Process Queue How Process was built:  Informed by templates  Specified by team discussion and table top testing  Tailored to our organization  Built with tools on hand

Where does Problem Management fit?  Within the other Processes: Incident, Request and Change Incidents trigger Problems Changes (attempt to) fix Problems Problems trigger Requests  With all the other stuff we have to do? By focus on only high return Problems By consolidating the current unstructured efforts By resolving Problems

Example: Incoming Delay Jan 13 th Jan 19 th Jan 25 th Resolved Jan 26 th I I I I I P 19321C 19426

What’s different (Roles)  Only three Roles: Problem Creator-Coordinator, Problem Support and Process Owner: Bill Conant  Process Owner is a Section Head not the CTO  No ‘Manager’ role, with those duties split up between Owner and Creator-Coordinator role  Minimal HelpDesk involvement at this time

What’s different (Activities)  Optimizing Workarounds Reduced impact or costs  Root Cause Analysis More troubleshooting breadth, depth and technique  Attention to budgeted resources (mostly time)

What’s different (Status)  KnownError: We have a workaround and know the root cause  Closed - Do Not Pursue When more research at this time is not cost effective To be reviewed periodically and re-opened if appropriate

What’s Different (Scope/Volume)  Expecting / designed for low volume of Problem tickets  Ticket creation and resource allocation done by Section Heads When worthy of work When effort must be tracked

What’s Different (Owner)  Ticket Ownership stays with the Problem resource  Research information requests to others can Trigger Request tickets  Time budget monitoring can use Ownership changes between Problem Support and problem Creator-Coordinator (Section Head)  Ticket Ownership stays with the Problem resource

Core Process Documentation  Process Description  Process Flow Diagram  Process Procedures Tool (KBOX) steps regarding  Ticket fields  Status transitions  Information capture  Process Resources All of the above plus resources including links to Root Cause Analysis support

Process Description (1/2)

Process Description (2/2) Goal Objectives Statuses Metrics Roles Policies Governance Activities Log, Classify, Assign Investigate and Diagnose Propose Solution Implement and/or Close  Standard Sections:

Work Flow: High Level Four Activities Role Primarily Responsible for each Activity KBOX Statuses and Owners during each Activity

Work Flow: Detail Activity Responsible Roles Tasks Other Processes

Process Procedures (KBOX Work Instructions) Process Task Procedure Name Steps in KBOX

Process Resources page  Links to all elements on the ‘Matrix page’  Problem Statement examples  Training and reference resources Skill Soft, Intermediate ITIL Training Skill Soft, Books Links and Youtube video on Root Cause Analysis

FAQ (1/4) Where are the training links for Root Cause Analysis?  Resource page What’s different about a P - vs an I – Ticket?  P is tracking focused effort on underlying cause of I Does every Incident need a Problem Ticket?  No but every Major Incident will likely trigger one. Why can’t I make Problem Tickets?  Resource and process management. You can and should recommend and prep problem tickets for your section head

FAQ (2/4) How do I prepare/propose a Problem Ticket for Section Head consideration? - Send to section head with why this specific Incident(s) deserves to have a problem ticket created to investigate its underlying cause.

FAQ (3/4)  How will we know if this Problem Management process is doing us any good?  If Root Causes are identified and Problems permanently fixed, then we’ll know that we’re getting our money’s worth from Problem Management.

FAQ (4/4)  Where do I go with my suggestions, observatories, and criticisms of this Process?  To the Problem Management process owner, Bill Conant or another ITSM Team member. Everything will go into the Problem section of the Continual Services Improvement (CSI) Register to be consulted when Bill leads the next revision of the Process

Problem Tool support in KBOX  New ‘Problem Process Queue’ Problem Specific screen fields  Subset of Incident Process fields  Single free form Configuration Item (CI) field Plus fields for  Root Cause Identified  Optimized workaround  Time Budget Linkage to triggering Incidents Linkage to Change(s) to resolve Problem

The Problem Process Queue (1/3)  Creating New Problem (Section Heads only)

Problem Ticket Layout Problem Specific Fields here Same Service Categories as usual, but not inherited from Incident

Process Specific screen fields Statuses relate only to the lifecycle of a Problem. Problem specific Statuses: KnownError Closed-DoNotPursue

Optimized Workaround To see the Optimized Workaround field in a resizable box, click here

List View for Problem Tickets  Then sort, if needed, on column, special views available on request

What’s Next  For Problem Management Try it out In 6? Months  Continual Service Improvement (CSI) or  Kill Establish Knowledge Management HelpDesk link

Reference  ITSM Program page With Docs for all ITSM Processes 37

The End Mahalo To the Problem Management Team: Sonia, Grace, Bill, Thatcher To you for your engagement, questions and suggestions. QUESTIONS? and COMMENTS!

Revisions  Between Session #1 and Session#2 Added How’s it fit (in) slide Added that Owner stays with Problem Support Fixed Typos Cosmetics  At posting Added reference page