Service Design & Problem Management:

(1)

Service Design & Problem Management:

The Bookends of Proactive ITSM

Business-Driven IT^®

Delivered to the Greater Cleveland itSMF LIG by Third Sky, Inc.

Introduction

Lou Hunnebeck

• Certified ITIL Expert

• VP of IT Service Management Vision

& Strategy for Third Sky, Inc.

• Author of the ITIL Service Design publication, 2011 Edition

Third Sky, Inc.

• ITSM Education

• ITSM Consulting, including Assessments &

Roadmaps, Workshops and Process Consulting

Lou Hunnebeck ♦ VP, ITSM Vision & Strategy [email protected] ♦ 1-917-544-6099

(2)

Agenda

• The Challenge

• Becoming Proactive

• Role of Service Design

• Role of Problem Management

• Conclusion

Slide #3

The Challenge

Slide #4

(3)

What We Have to Manage

• Business needs for new & changed services

• Legislation and regulatory compliance

• Constant changes to direction and priorities

• Varying skills, resources, funding and time As IT service providers, we have to juggle a lot:

Slide #5

• Relationships at operational, tactical and strategic levels

• Incidents, service requests, questions & comments

Service Management Perspectives

Process

Data

We have to assemble the pieces in a way that makes sense, trying to produce the right results for the business.

(4)

7

Driving Business Success

Business outcomes are enabled by IT services

Reused by permission from:

Where is the Pain?

Slide #8

(5)

9

Customers and Users Want…

Results!

and

Consistency

Reliability

Becoming Proactive

(6)

Slide #11

Business-Driven IT is way of organizing and managing an IT service provider that is primarily focused on visible business results.

• IT innovation in service of the business

• Excellence in service provision

• Full IT-Business integration Business-Driven IT supports:

Business-Driven IT is Proactive

12

What does “Proactive” Mean to You?

Put yourself in the business’ shoes.

What would it mean to you if your IT Service

Provider was

proactive?

(7)

Where is the Pain – Service Design?

Slide #13

Where is the Pain – Problem Management?

(8)

The Role of Service Design

Slide #15

The Role of Service Design

After the strategic decision to proceed, the Service Design stage puts detail, shape and clarity around:

Slide #16

• Detailed requirements, including both the technical and non-technical aspects of the services

Exactly what will be delivered

• Detailed design of how the requirements will be fulfilled

• Technical and non-technical aspects of the design

• Addresses all five aspects of service design and the entire service lifecycle

Exactly how it will be delivered

(9)

What Would Success Look Like?

If Service Design were done well, we would:

Slide #17

• Have services that have more than functionality – they would be stable, cost-effective and strong

• Maximize business value of our services through optimizing service usage

• Be able to manage and support our services effectively & efficiently

• Deliver more beneficial change more rapidly

• Be able to continually improve our services more easily.

What We’re Doing Wrong

• Leaving the project in the control of Application Development

• Focusing on functionality (utility) to the near exclusion of everything else

• Leaving too much to the Service Transition stage

• Working without proper customer and user involvement

Typical Service Design mistakes include:

(10)

Components of Comprehensive Design

When approaching the design of a service we need to address:

Slide #19

• Service utility and warranty

• Manageability and maintainability

• All five aspects of service design

• How the service will be “established in effective use”

• How the service will be operated and improved

Addressing Utility

• Requirements should focus around solving business problems and achieving business outcomes – don’t just be order-takers

• Be careful of the “oh, and” part of design

• Don’t involve only customers – users are needed to be truly comprehensive

• Don’t assume how the solution will be delivered. Shop at home first.

Developing functional (utility) requirements is probably the most natural part of service design, however:

Slide #20

(11)

Slide #21

Addressing Warranty

How the service needs to be delivered (warranty) must also be carefully defined and delivered in the design.

• Define service warranty requirements in Service Level Requirements (SLRs)

• Determine if the customer’s SLRs can be delivered and at what cost

• Gradually work through the service design and service transition stages to negotiate, agree and validate specific, achievable and measurable service level targets

The Service Level Management (SLM) process, together with other processes, will be used to:

Non-Technical Aspects of Design

• Training Plan for Users &

Support Teams

• Documentation Plan

• Communication and Marketing Plan

• Early Life Support (ELS) Plan Many times it is the non-technical aspects of the

service change that cause the customer to be unhappy or make the service unsuccessful.

(12)

Integration with Project Management

The work of Service Design (and Service Transition) is frequently managed as a project

Slide #23

• Carefully consider where projects and changes frequently go wrong

• Consider the impact of leaving too much of the project to the service transition stage

• Involve all relevant stakeholders

• Agreed improvements need to be embedded into the project management methodology

The Service Owner Perspective

Slide #24

The Service Owner serves as the Voice of the Customer (VOC) inside IT throughout the service

lifecycle, in relation to their particular service.

Service Owner is accountable for:

• Delivery of the service

• Quality of the service

… all within set budget

(13)

Service Owner in Service Design

Slide #25

• Develop and refine business requirements

• Participate in SLA negotiations with Customers

• Participate in OLA development

• Understand UCs as needed

• Identify service requirements in other lifecycle stages

• Coordinate Service Design Package development

Some of the activities that a Service Owner does during service design are:

Doing It Right Every Time

It is not enough to do an individual service design well.

We have to develop a common framework of repeatable, reusable and reliable practices and

embed them in all service designs.

The scope of the design doesn’t matter.

It doesn’t matter if design is done through a project or through a change alone.

The Design Coordination process leads.

(14)

Role of Problem Management

Slide #27

28

Problem Management

• Prevent problems and resulting incidents from happening

• Eliminate recurring incidents

• Minimize the impact of incidents that cannot be prevented

The primary objectives of Problem Management:

The purpose of problem management is to manage the lifecycle of all problems from first identification through further investigation, documentation and eventual removal.

(15)

Sound Problem Management could:

What Would Success Look Like?

• Address systemic issues in an orderly manner, reducing reactive behaviors that introduce cost and risk.

• Make many small improvements that cumulatively create significant improvement.

• Harvest and share organizational knowledge reducing undesirable variation in how repeat incidents are resolved.

• Apply business-driven prioritization to problem resolution, putting our time and money where it will best serve the business.

• Develop and mature organizational competency in root cause analysis techniques to speed diagnosis

Slide #29

What We’re Doing Wrong

• Treating the process like Incident Management on steroids

• Failing to utilize formal Root Cause Analysis techniques

• Failing to allow staff dedicated time to contribute

• Failing to actively develop broad staff competencies

Typical Problem Management mistakes include:

(16)

Problem Management doesn’t exist in

isolation

Problem Management & CSI

Continual Service Improvement is the broader improvement umbrella under which Problem Management

is one competency.

Slide #31

32

Proactive Problem Management

What does this mean to you?

Describe what proactive problem management would look like and who

would do it.

(17)

Analysis Techniques

There is a broad spectrum of measurement and analysis techniques that can be leveraged in CSI in general, as well as in Problem Management specifically, such as:

– Benchmarking

– Maturity Assessment – Balanced Scorecard – SWOT Analysis

– Kepner Tregoe Analysis – Ishikawa Analysis

Slide #33

Proactivity in Reactive Problem Mgmt.

Let’s take a few minutes to look through

the reactive problem management process.

See if you can find ways that we can be more proactive in how we perform

this reactive work.

(18)

35

Sample Problem Workflow – First Steps

Problem Detection Problem Logging

Problem Categorization

Cabinet Office

36

Sample Problem Workflow - Continued

Problem Investigation and Diagnosis Workarounds Raising a Known Error Record

(19)

37

Sample Problem Workflow - Conclusion

Problem Resolution Problem Closure Major Problem Review

The Key is to Look and Not Wait

We can’t wait for the

issues to present themselves.

We have to actively go out and look

for them.

If people are given the skills, tools, time and recognition they need, we can get

(20)

Conclusion

Slide #39

Comprehensive Service Design

• The success of the rest of the lifecycle of the service is dependent on good design

• Focusing on functionality is not enough

• Don’t leave things to Service Transition that can be designed/planned in Service Design

• Integrate good practices into your project management methodology

• Leverage the Service Owner to maximize results For Service Design, the message is clear:

Slide #40

(21)

Comprehensive Problem Management

• Problem Management can make our services more robust, stable and reliable

• Focusing on reacting to incidents is not enough

• Everyone in IT should be able to open problems and contribute to investigation, diagnosis and resolution

• Develop root cause analysis competencies in the organization

• Don’t wait – go look!

If the issues aren’t prevented in design…:

Slide #41

Supporting ITSM Success

The same can be said of each component of ITSM.

For ITSM Success, programs need:

•Strong & Committed Leadership

•Clear & Relevant Objectives

•Willing & Prepared Participants

•Demonstrated Value

•Sustained Momentum

(22)

Lou Hunnebeck ♦ VP, ITSM Vision & Strategy

Q & A

Thank you for Joining Us!

www.thirdsky.com

Slide #43

[email protected] ♦ 1-917-544-6099