1. Why good enough, is NEVER good enough.
Continual Service Improvement:
Why good enough, is NEVER good enough.
17 October 2008

2. Agenda 9:30 – 9:45 – Introductions and Overview
9:45 – 10:45 – Defining Continual Service Improvement
10:45 – 11:00 Break
11:00-12:00 – CSI Exercise
12:00 – 12:30 – Review Exercise Results

3. What we will cover today
Understanding of the key elements of a Continual Service Improvement program
Simple approaches to beginning a program of your own
Common pitfalls when implementing a Service Improvement Program
Aligning with a formal “Quality” program (Six Sigma, TQM, TPS, etc..)
Gathering the Voice of your Customer
Measuring the results of your program

4. What are Services? IT Service – Business Service –
“A service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer’s Business Processes. An IT Service is made up from a combination of People, Process and Technology and should be defined in a Service Level Agreement”
Business Service –
“An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service, which is used internally by the IT Service Provider and is not usually visible to the Business”
Infrastructure Service –
“An IT Service that is not directly used by the Business, but is required by the IT Service Provider so they can provide other IT Services. For example directory services, naming services, or communication services.”
All definitions from: ITIL “Service Design” book © Crown Copyright 2007 (OCG)

5. A Service Centric Viewpoint
$ell Insurance
Market
Sell
Onboard
Support
Application1
Business Process
Application3
Application4
Application3
IT Service 1
IT Service 2
IT Service 3
Infrastructure
Service 1
Infrastructure
Service 2
Infrastructure
Service 3
C I 1
CI 2
CI 3
C I 4

6. What is Continual Service Improvement?
Aligning and realigning IT services to changing business needs
The goal of Continual Service Improvement is to align and realign IT Services to changing business needs by identifying and implementing improvements to the IT services that support the Business Processes.
The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle.
In order to manage improvement, CSI should clearly define what should be controlled and measured.

7. What is Continual Service Improvement?

9. What does ITIL say about CSI
Focused on all aspects of the ITIL Core processes
Applies to service improvement and process improvement for related processes.
Should be systematically applied throughout the entire Service Lifecycle
Identifies 3 metric types:
Technology – (How is the technology performing – Monitoring, Uptime, etc)
Service – (How is the service performing relative to the needs of the business)
Process – (How is the process performing – Cycle Times, Customer Satisfaction, etc)

10. 7 Steps Define what you should measure Define what you can measure
Gather the data
Process the data
Analyze the data
Present/assess the data
Implement corrective actions

11. Define what you should measure
What should be measured based upon:
Business Requirements
Functional Requirements
Expected outcomes of Business Processes
Existing Service Improvement Plans
Defined Service/Process KPIs and Metrics
Should provide a balanced View
Qualitative - what does your customer think of the quality of the product being delivered?
Quantitative – What do your Technology and Process metrics tell you about how your product is being delivered?

12. Define what you can measure
What data is available to you?
How are you going to collect that data?
From an existing tool?
From a new tool?
Manually tallied?
What if you can’t measure something?
Establish a Data Capture Plan
How are you going to get this data, and what gaps do you need to overcome if any?
Determine which metrics are the most important.
What is important to your customer and their business processes?
What KPIs and Metrics align to the highest priority Business and Functional Requirements?

13. Gather the data Gather all of your relevant data
Execute your data capture plan
Depending on whether your data is “Quick Turn” (lots of transactions resulting in a large amount of data in a short period of time) or “Slow Turn” (minimal transactions occurring over a long period of time), combined with availability and quality of your historical data will determine your sample data size and time period.

14. Process the data Validate the data: Is the data what you expected?
Is the quality of the data sufficient?
Do all of the data sources validate one another?
Ensure that all data is in a format that can be worked with while analyzed.

15. Analyze the data Create reports that display the relevant data points.
Be able to understand and articulate the meaning of data points, and trend information.
Understand any special cause data, which is outside the norms.

16. Present / Assess the data
Identify opportunities to improve service based upon the analyzed data
Present the data and recommendations to key stakeholders / decision makers
Determine which Corrective actions should be taken (follow standard release management planning and change management processes)

17. Implement corrective actions
Execute according to standard Release and Change Management processes.

18. Aligning your CSI Program to Other Quality Programs
Most current quality programs have some basis on the Deming Cycle (Plan – Do – Check – Act)
W. Edward Deming
Born in 1900
Focused on Statistical Quality Control
Was instrumental in the 1940 U.S. Census
Demonstrated the link between training and product quality
After WWII worked with the Japanese to improve the quality of products produced in Japan
Had two major area of Philosophy
Fourteen Points
Seven Deadly “Diseases”

19. Aligning your CSI Program to Other Quality Programs
The Fourteen Points:
Create constancy of purpose for improvement of product and service.
Adopt the new philosophy.
Cease dependence on mass inspection.
End the practice of awarding business on price tag alone.
Improve constantly and forever the system of production and service.
Institute training.
Institute leadership.
Drive out fear.
Break down barriers between staff areas.
Eliminate slogans, exhortations, and targets for the workforce.
Eliminate numerical quotas.
Remove barriers to pride of workmanship.
Institute a vigorous program of education and retraining.
Take action to accomplish the transformation.

20. Aligning your CSI Program to Other Quality Programs
The Seven Deadly Diseases
Lack of constancy of purpose.
Emphasis on short-term profits.
Evaluation by performance, merit rating, or annual review of performance.
Mobility of management.
Running a company on visible figures alone.
Excessive medical costs.
Excessive costs of warranty, fueled by lawyers that work on contingency fee.

21. Aligning your CSI Program to Other Quality Programs
Aligning CSI to a Six Sigma program:
Goal of Six Sigma
Systematically improve processes to increase efficiency and reduce process defects
Typically does well in a data rich environment
Helps to objectively focus on the highest impact areas.
DMAIC – (Define – Measure – Analyze – Improve – Control) is a method employed by six sigma that aligns very well with the 7 Steps recommended by CSI.

22. Aligning to CSI to Six Sigma (DMAIC)
Define
1 - Define what you should measure
2 - Define what you can measure
Measure
3 - Gather the Data
Analyze
4 - Process the data
5 - Analyze the data
Improve
6 – Present /Assess the data
7 - Implement Corrective Actions
Control

23. Key Process Elements
Process Diagram Defines the inputs, outputs, providers, receivers, activities and critical success factors of the process
Benefits Explanation of the benefits you will receive from implementing this process.
Controls By knowing the control objectives and being able to monitor and measure performance of achieving those objectives, IT will be able to better manage and improve operations, security and their audit processes. A control objective will define the enforcement of a process and will avert high-risk activities. 
Goal Document the goal of the process.  Make it SMART:
Specific – your goal should have its expected outcome stated as simply, concisely and explicitly as possible. This answers questions such as; how much, for whom, for what?
Measurable – a measurable goal has an outcome that can be assessed either on a sliding scale (1-10), or as a hit or miss, success or failure.
Achievable – an achievable goal has an outcome that is realistic given your current situation, resources and time available. Goal achievement may be more of a “stretch” if the outcome is tough or you have a weak starting position.
Relevant – a relevant goal should help you on your mission.
Time-bound – a time-bound goal includes realistic timeframes.

24. Key Process Elements (Cont.)
Metrics The metrics by which you will measure the success of your process implementation. This page defines your Key Performance Indicators and your Critical Success Factors.
Policies The management polices that will govern the use of this process and all of its procedures.
Process Team The members of the process team and their contact information.
Roles The process’ roles that will be involved with the process activities. HR should be involved in the development, approval and assignment of all process roles.
Scope Defines what the process covers (the extent and/or scale), the inputs, the basic activities and the output, including the scope of responsibility of the process owner.
Specification Summarization of the customizable process options and lists. (ex. severity codes, closure codes, status codes, etc).

25. Process Diagram (Example: Incident)

26. Process Benefits (Example: Incident)
Details
Quick restoration of service following an incident
Users’ service or business operation will be restored faster
Incidents are not lost or forgotten
All incidents are recorded and tracked
Current status of incidents is available
Status is available on for current open and recently closed incidents
Reduces duplication of effort
It will be easily determined if an incident is currently being worked and who is designated as the resource focal point
Clear view of status and priority of incidents
More effective management decisions can be made for assignments and escalation when status of incidents and committed available resources is known
Possible to measure performance and trends
Statistical analysis will be made possible by using common records and formats and thereby providing the opportunity for problem prevention
Increased end user satisfaction
Users will recover faster and their reported incidents will be handled in accordance with applicable SLAs resulting in high satisfaction with IT services
High impact, critical, or urgent incidents are prioritized according to the Service Level Agreements for that service or business operation
Impact, criticality, and urgency will be determined prior to incident triage for assignment and escalation
Productivity gain through high system availability
Business users will gain productivity from reduced down time
Management information related to Incidents is readily available
Accurate MTTR and cost of outage or degradation incidents and their recovery will be available for management decision processes

27. Process Controls (Example: Incident)
How control will be measured
Service Desk function will be established as the user interface with IT to initiate service requests and information needs
Distribution of call types to service desk: information, request, incident, etc.
Incidents will be classified according to committed Service Level Agreements / Objectives and the Service Desk will monitor all incidents through to their closure
% of incidents closed within SLA criteria
Service Desk procedures will include escalation criteria and communication procedures for incidents that cannot be resolved according to limits set in their respective OLAs/SLAs, and/or if appropriate workarounds are not available
% of incidents requiring escalation  % of incidents without suitable workarounds  Distribution of incidents by severity
Service Desk procedures for the timely monitoring and clearance of customer queries will include resolution / closure and confirmation steps to ensure that the action taken has been agreed to by the customer
% of unresolved incidents required to be forwarded to Problem Management.  % of calls abandoned  Distribution of call answer times  % of calls cleared/closed during initial contact
Produce reports for the measurement of service performance including response times and trends, to enable management to make more informed tactical and strategic decisions governing service support
% of customers satisfied that incident management activities met or exceeded commitments made as part of the Service Level Agreement

28. Process Goal (Example: Incident)
To restore normal service operation as quickly as possible as guided by the Service Level Objectives and to minimize the adverse impact on business operations, thereby ensuring the best possible level of service quality is achieved.

29. Process Metrics (Example: Incident)
CSF: Quickly resolve Incidents
KPI
Metric
Reduced response time
Percentage reduction in average time to respond to calls for assistance by Service Desk Agents
Increased resolution by level 1 support
Percentage increase in number of Incidents resolved by Service Desk Agents
Increased first call resolution
Percentage increase in number of Incidents resolved by Service Desk Agents on first response
Decreased inaccurate assignments
Percentage reduction of Incidents incorrectly assigned
Accurate categorization
Percentage reduction of Incidents incorrectly categorized
Meeting service level objectives
Increased percentage of Incidents resolved within SLA parameters
Decreasing MTTR
Reduced mean time to resolution of Incidents
CSF: Improve Business and IT Productivity
KPI
Metric
Reduced cost of incident response
Percentage reduction in average cost of handling Incidents
Increased first call resolution
Improve percentage of Incidents resolved by Service Desk Agents
Reporting on time
Elimination of delays in producing management reports
CSF: User Satisfaction
KPI
Metric
Increase in customer satisfaction
Improved scores on Customer Satisfaction Surveys

30. Process Policies (Example: Incident)
Policy
Detail
Purpose
Incident Ownership
The service desk will maintain ownership of all reported Incidents and Service Requests throughout their lifecycle, which includes monitoring, tracking and invoking escalation procedures as necessary.
To ensure incidents are responded to in a timely fashion and the appropriate escalation procedures are triggered per SLA commitments.
Incident Management Process
There will be one Incident Management Process defined to provide IT related technical support and Service Request handling for all internal customers.
To provide definitive management of all IT related events that disrupt normal operations.
Incident Supported Products
The Incident Management process will only be responsible to support standard hardware, software, and applications that have been approved for use within the IT infrastructure.
To ensure resources are managed to meet agreed to business commitments and service level objectives.
Incident Communication
The Incident Management Process will promptly communicate any known or expected degradation of service(s), as well as potential impact, to the affected Customer community and IT support family
To ensure minimal disruption to business operations and the assignment of resources that is commensurate with commitments and expectations.
Incident Escalation
There are defined assignment and escalation models in place within the Incident Management process to ensure timely resolution of incidents and fulfillment of Service Requests. Assignment and escalation occurs as defined in Service Level Agreements or documented procedures.
The Service Level Agreements and the process procedures will dictate escalation and notification requirements so that management is well informed as to the progress and status on priority incidents.

31. Process Policies (Example: Incident)
Policy
Detail
Purpose
Incident Reporting, Recording, and Resolution
The Incident Management Process acts as the initial point-of-contact for reporting, recording, and resolving all IT related Incidents and Service Requests.
To ensure all reported Incidents and Service Requests are recorded and tracked through to an appropriate closure.
Incident Metric Reporting
Metrics will be collected to measure the effectiveness and efficiency of the Incident Management process and report to customers, management and specialty support groups, as defined.
To meet management requirements of process and procedures for the handling of Incident and Service Requests, defined metrics, targets, and the associated attainment will be reported.
Incident Status Update
Status information on incidents will be made available to customers throughout the Incident Management Process lifecycle.
To let the customer and management know the status of an Incident at any point during its active state
Incident Closure
Closure of an Incident or Service Request is dependent on customer validation that service has been restored or their request has been completed, or the Incident Manager deems the incident/request to be closed. Incident and Service Request records will be closed in the IT Service Management tool when restoration of service and customer validation has occurred.
To ensure incidents are closed in accordance with agreed to process and procedures as negotiated in the Service Level Agreements.
Incident Management Priority
Support personnel must assess all Incidents and Service Requests for impact to the business and urgency to restore or provide a service. Assessing impact and urgency thereby defines Priority.
Customers and users provide input into Priority determination, which is defined by IT support staff using the criteria within this Policy.
To follow pre-defined matrices and guidelines for incident priority due to potential or actual service or business impact.

32. Process Team Role Name Area/Division Phone E-mail Process Owner
Process Manager

33. Process Roles (Example: Incident)
Role: Incident Process Owner
Attribute
Details
Role
Own and maintain the Incident Management process
Responsibilities
Document the process  Ensure proper staffing levels for execution  Ensure proper training for execution  Maintain the process  Manage the incident staff
Organizational Position
Manager
Skills
Manages people  Understands all ITSM processes  Verbal and written communication
Experience
Management  Process Design and architecture  Operations support

34. Process Scope (Example: Incident)
Incident Management is responsible for any reported event, by tool or user, which is not part of normal operations that causes or may cause a disruption to or decrease in the quality of a service.
The inputs to Incident Management are:
Events
Customer Contacts
The outputs are:
Restored service
Requests for change
Problem records
Service Impact Measurements
The major activities are:
Detection and recording
Classification and initial support
Investigation and diagnosis
Resolution and recovery
Incident record administration and control
Scope of activities for the Process Owner is to have the overall responsibility to ensure the process is both suitable and relevant for the organization, for the continuous improvement of the process, and for keeping this process guide current.

35. Where to start?
Start small and gradually add complexity to your program:
Focus on a handful of Highly Visible Services and Processes
Don’t strive for perfection out of the gate
Plan for a series of iterative improvements that keep the level of change manageable for all stakeholders.
Be sure that your release planning accounts for other initiative so as not to stack too much change into a given period of time.

36. Measuring the Voice of your Customer
There is only one person capable of the determining the quality and value of your product:
Your Customer
Qualitative measure are typically gathered by surveying your customers.
A well developed survey can provide a tremendous amount of good data for your Continual Service Improvement program.

37. Common Pitfalls Too much scope
Don’t try to do everything in the book at once
Balance strategic vision with tactical execution
Be realistic about what can be achieved given the time and resources you have available
Striving for perfection on the initial release:
Engineering in unnecessary complexity
Introducing too much change at one time
Plan for a series of iterative improvement releases that incrementally move you to your ideal state.
“Analysis Paralysis”
It is very easy to get caught up in what the metrics say
Don’t’ be afraid to make the best decision you can make even in light of less than perfect data.

38. CSI Exercise
Based on the following scenario, come up with a Service Improvement Plan for the following service to include any recommendations for process improvements for related processes.

39. CSI Exercise (Scenario)
Employees of ACME products were having difficulty getting support for Incidents related to their Widget Scheduling Service. Any time an Incident was reported, it typically took weeks to resolve regardless of the priority. During that time, there was very little communication from IT regarding the status of the requests, and typically when the issue was resolved they were only aware of it because they got a ticket closed notification.
In talking with the ACME IT Desktop support team, they claim that the reason why they take so long to resolve the incidents is due to the fact that they have to work directly with the Widget Scheduling Service team to resolve all but the most simple tasks, and that in many cases a temporary work around is put in place to get the customer working, only to have the same problem repeat itself every few weeks.
A problem management ticket was opened and the findings indicated that the root cause was due to a Database locking issue that the team has been aware since a previous release went in over 6 months ago. The Estimate from development is that it would take Approx 80 hours of development time to develop, test and implement the fix. The reason why the issue is more critical now, is that an additional 300 users were added to the system 90 days ago when they were migrated from their old and beloved Access based scheduling system.
The next release is not scheduled until the end of the quarter which is still 6 weeks away. All of the development resources who are capable of fixing this issue are currently 100% allocated to developing critical new functionality for the next release of functions needed by the Marketing Team and claim that due to the needs of the business, they are unable to dedicate any resources to fixing this issue until the new release is launched and stable.
Information from the Customer Satisfaction Surveys indicate that a growing number of users are increasingly dissatisfied with not only the Service, but the IT team as a whole.
Business Management for the 300 users has expressed frustration with the IT Team, and also that he feels that because his team is focused on Inventory Management and is not directly a revenue generating division, that his needs are largely ignored. He has shared that for every hour of downtime that his users experience, he estimates that the company loses $10, 000 in potential revenue due to unfilled orders at the regional distribution centers. (This information is based upon a Six Sigma project from the prior fiscal year that was focused on improving Supply Chain Management).

40. CSI Exercise (Scenario Cont.)
You are the Service Improvement Manager and a new Improvement Opportunity has been brought to you as a result of the previously mentioned Problem ticket.
The Problem Manager has focused solely on the DB issues, but knows that there is impact to the business because he carpools with the Director of Inventory Management
Your boss has cautioned you that this Marketing Release is a huge priority for ACME and that for every day it is late, it will cost the company $25,000 in lost revenue.

41. Assumptions
Service Owner for Widget Scheduling is Wyle E. Carote a Senior Manager in Application Development.
The Initiative Owner is always the Service Improvement Manager (Pick a representative from the group)
Average fully burdened cost of an Hourly employee is $60 per hour.
Service Level objectives for Incidents related to the WS Service are as follows:
Priority 1 – 4 Hours
Priority 2 – 8 Hours
Priority 3 – 3 Business Days
Priority 4 – 5 Business Days

42. Service Evaluation
The following information is typically recorded within the Service Evaluation Report:
Name of the IT service under review
Date and time of the review
Person in charge of the review
Participants of the Service Review Meeting
Business and user representatives
Service provider representatives
Summary presentation of agreed vs. achieved service levels
Report on exceptional situations
Satisfaction regarding service quality on the client-side
Compliments
Complaints
Areas which must be addressed by improvement initiatives (resulting in changes to the service and/ or to its underlying processes, or to customer agreements)
From the customer viewpoint: New or changed requirements for the service
Changes in business processes or strategy which lead to new functional requirements
Changes in risk perceptions, priorities and criticalities which lead to changed Service Level Targets
Anticipated changes in service consumption, short term as well as medium and long-term
Required short-term modifications (e.g. due to current/ recent problems)
Changed requirements with respect to service level reporting
From the IT viewpoint
Areas where service quality is to be improved
Conceivable cost-optimizations, e.g. by using new technologies or optimizing processes, or by influencing service demand

43. Service Improvement Plans
The following information is typically contained within the Service Improvement Plan:
For each defined initiative for process or service improvement:
Process or service concerned
Person in charge of the process (Process Owner) or service (Service Owner)
Initiative owner (person in charge of the initiative, often Service Management roles like e.g. Service Level Manager, Capacity Manager, Availability Manager, Process Owner, Service Owner)
Approval from senior management (initiative approved by …)
Description of the initiative
Source of the measure (e.g. Service Review, Process Audit)
Business case
Expected outcome of the initiative
Cost estimate
Specific desired result of the initiative, e.g. a specific decrease in cost for providing a service
Implementation schedule and status
Target date
Current status

44. CSI Exercise (Supporting Data – Cust Sat)

45. CSI Exercise (Cust Sat Comments)
Joe in Desktop is Great!!
I opened this ticket 3 weeks ago for a problem I had editing inventory delivery schedules and was never called back. Today the ticket is closed, and I can work again, but it would have been nice to have been told something.
It seems like every time I try to work in Widget Scheduling, I am fine for a few days, then I am down again for a week or more. When is someone going to fix this problem?
We have the worst IT Department in the world.
Joe in Desktop is Great!!!

46. CSI Exercise (Open Incidents by Service)

47. CSI Exercise (Service Levels Met By Service )

48. CSI Exercise (Downtime for WS Service by dept )

49. Review Exercise Results
Pick a representative of the Group
Describe how you approached the exercise
Talk about your recommendations.

50. Recap Start simple and add complexity as you go
Balance your strategic vision with your tactical outcomes
Most quality programs come from the same foundational roots
Continuous Service Improvement is a lifestyle not a journey.
Be sure you are committed for the long haul.
Be sure management is committed
If you stand still, you will be left behind.
In the long run, Good Enough is NEVER good enough.

51. Q&A
Any questions?
Comments?
Areas of additional discussion?

52. Resources: Process Improvement ITIL and Six Sigma Process
ITIL and Six Sigma
Sigma-to-Complement-ITIL-v3/
Process