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

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

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

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

Continual Service Improvement:

Why good enough, is NEVER good enough.

17 October 2008

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

Agenda9:30 – 9:45 – Introductions and Overview9:45 – 10:45 – Defining Continual Service

Improvement10:45 – 11:00 Break11:00-12:00 – CSI Exercise 12:00 – 12:30 – Review Exercise Results

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

What we will cover todayUnderstanding of the key elements of a Continual

Service Improvement programSimple approaches to beginning a program of

your ownCommon pitfalls when implementing a Service

Improvement ProgramAligning with a formal “Quality” program (Six

Sigma, TQM, TPS, etc..)Gathering the Voice of your CustomerMeasuring the results of your program

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

What are Services?IT 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)

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

A Service Centric Viewpoint

Market Sell Onboard Support

$ell Insurance$ell Insurance

Application1

Application3

Business Process

Application4 Application3

Infrastructure Service 1

Infrastructure Service 2

Infrastructure Service 3

C I 1 CI 2

CI 3 C I 4

IT Service 1 IT Service 2 IT Service 3

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

What is Continual Service Improvement?Aligning and realigning IT services to changing

business needsThe 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.

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

What is Continual Service Improvement?

Page 8: Continual Service Improvement: Why good enough, is NEVER good enough. 17 October 2008.
Page 9: Continual Service Improvement: Why good enough, is NEVER good enough. 17 October 2008.

What does ITIL say about CSIFocused on all aspects of the ITIL Core processesApplies to service improvement and process

improvement for related processes.Should be systematically applied throughout the

entire Service LifecycleIdentifies 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)

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

7 Steps

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

Define what you should measureWhat should be measured based upon:

Business RequirementsFunctional RequirementsExpected outcomes of Business ProcessesExisting Service Improvement PlansDefined Service/Process KPIs and Metrics

Should provide a balanced ViewQualitative - 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?

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

Define what you can measureWhat 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?

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

Gather the dataGather all of your relevant dataExecute your data capture planDepending 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.

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

Process the dataValidate 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.

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

Analyze the dataCreate 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.

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

Present / Assess the dataIdentify opportunities to improve service

based upon the analyzed dataPresent the data and recommendations to key

stakeholders / decision makersDetermine which Corrective actions should be

taken (follow standard release management planning and change management processes)

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

Implement corrective actionsImplement Corrective actionsExecute according to standard Release and

Change Management processes.

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

Aligning your CSI Program to Other Quality ProgramsMost current quality programs have some basis

on the Deming Cycle (Plan – Do – Check – Act)W. Edward Deming

Born in 1900Focused on Statistical Quality ControlWas instrumental in the 1940 U.S. Census Demonstrated the link between training and product

qualityAfter WWII worked with the Japanese to improve the

quality of products produced in JapanHad two major area of Philosophy

o Fourteen Pointso Seven Deadly “Diseases”

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

Aligning your CSI Program to Other Quality ProgramsThe 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.

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

Aligning your CSI Program to Other Quality ProgramsThe 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.

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

Aligning your CSI Program to Other Quality ProgramsAligning CSI to a Six Sigma program:

Goal of Six SigmaSystematically improve processes to increase efficiency

and reduce process defectsTypically does well in a data rich environmentHelps 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.

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

Aligning to CSI to Six Sigma (DMAIC)

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

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.

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

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).

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

Process Diagram (Example: Incident)

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

Process Benefits (Example: Incident)Benefit 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

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

Process Controls (Example: Incident)Control 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

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

Process Goal (Example: Incident)

GoalTo 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.

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

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

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

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.

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

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.

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

Process Team

Role Name Area/Division Phone E-mail

Process Owner        

Process Manager        

         

         

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

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

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

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.

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

Where to start?Start small and gradually add complexity to

your program:Focus on a handful of Highly Visible Services

and ProcessesDon’t strive for perfection out of the gatePlan 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.

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

Measuring the Voice of your CustomerThere 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.

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

Common PitfallsToo much scope

Don’t try to do everything in the book at onceBalance strategic vision with tactical executionBe realistic about what can be achieved given the

time and resources you have availableStriving for perfection on the initial release:

Engineering in unnecessary complexityIntroducing too much change at one timePlan 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.

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

CSI ExerciseBased 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.

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

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).

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

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.

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

AssumptionsService 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 HoursPriority 2 – 8 HoursPriority 3 – 3 Business DaysPriority 4 – 5 Business Days

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

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

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

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

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

CSI Exercise (Supporting Data – Cust Sat)

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

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!!!

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

CSI Exercise (Open Incidents by Service)

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

CSI Exercise (Service Levels Met By Service )

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

CSI Exercise (Downtime for WS Service by dept )

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

Review Exercise ResultsPick a representative of the GroupDescribe how you approached the exerciseTalk about your recommendations.

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

RecapStart simple and add complexity as you goBalance your strategic vision with your tactical

outcomesMost quality programs come from the same

foundational rootsContinuous 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.

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

Q&AAny questions?Comments?Areas of additional discussion?

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

Resources:Process Improvement

http://www.gantthead.com/ http://www.isixsigma.com/sixsigma/six_sigma.asp http://www.isixsigma.com/me/tqm/ http://www.work911.com/tqmarticles.htm http://www.khosla.com/softwaremgmt/deming.htm

ITIL and Six Sigmahttp://software.isixsigma.com/library/content/

c080116a.asp http://www.eweek.com/c/a/IT-Management/How-

to-Use-Six-Sigma-to-Complement-ITIL-v3/ Process

http://www.pepperweedprocessmodel.com