ITIL Continual Service Improvement Design Guidelines For Version 3

ITIL Design Guidelines Part 5 – ITIL Continual Service Improvement Paper Overview Purpose This paper briefly describes the concept of using guidelines when designing ITIL services. It then presents a starter set of design guidelines that can be used by IT Service Management Implementation teams. Contents This publication contains the following topics: Topic See Page Paper Overview 2 Understanding Design Guidelines 3 Design Guideline Examples for ITIL Continual Service 10 Improvement © 2007 Randy A. Steinberg & Robin Yearsley Page 2

Understanding Design Guidelines Overview Introduction The following section provides some basic background on what Design Guidelines are and how to use them. Contents This part contains the following topics: Topic See Page Design Guidelines Defined 4 Components of a Design Guideline 5 Examples of Design Guidelines 7 Examples of Poorly Constructed Design Guidelines 8 Examples of Design Guideline Categories 9 © 2007 Randy A. Steinberg & Robin Yearsley Page 3

Design Guidelines Defined Introduction The following section defines Design Guidelines within an ITIL context and lists their key attributes. Definition Design Guidelines: • Are statements about how IT Services should operate. • Support the IT Service Management Vision. • Are critical statements of direction that will have major impact on how IT services should be designed and operated. • Should be clearly understood and communicated both internally and externally to IT Services. Derivation These Guidelines are derived from: • Basic beliefs • Experience • Priorities • Underlying culture within a business organization • People involved with the delivery of IT Services. © 2007 Randy A. Steinberg & Robin Yearsley Page 4

Components of a Design Guideline Introduction As an early activity in IT Service Management implementation, consider each guideline in isolation. The underlying rationale for advancing each guideline with its resulting implications and impacts should be agreed to and documented. Describing Each guideline has three parts, which are described below: Guidelines • Statement • Rationale • Implications Statement This consists of a single sentence that states the guideline. Example: We will let our customers know the key services we offer them and who is accountable. Rationale This lists reasons why the guideline should be accepted by the business. Considerations include: • Why should the organization do this? • What business benefits does this guideline advance? • What characteristics can be used to defend the guideline? Examples: • Will provide clear accountability for the service. • Will provide service clarity for the customer. Continued on next page © 2007 Randy A. Steinberg & Robin Yearsley Page 5

Components of a Design Guideline, Continued Implications This lists areas of impact to business and IT units as a result of operating with the guideline. Considerations include: • What needs to be done if the guideline is implemented? • What impact will it have on business and IT units? • What kind of behaviours, tools, data or processes need to be in place to support it? Example: • We will need to define each service that we offer in a Service Catalogue. • We will need to develop cross-organizational capabilities. • We will have to establish a formal communications program. • We will have to establish a single owner for each service. © 2007 Randy A. Steinberg & Robin Yearsley Page 6

Examples of Design Guidelines Characteristics Well designed guidelines have the following characteristics: • States a fundamental belief of the enterprise in one or two clearly written sentences. • Relevant to the IT Service Management solutions. • Worded directly and simply in terms understandable by both business and IT managers. • Widely applicable. • Will not be outdated quickly by advancing technology. • Have objective reasons for advancing it over the considered alternatives. • Have impacts which need to be documented. Examples The following are examples of some well constructed design guidelines: • External customer information will be kept strictly confidential within policies set by the organization and regulatory agencies. • Service Management solutions, whether purchased or developed internally, will be highly structured and modular. © 2007 Randy A. Steinberg & Robin Yearsley Page 7

Examples of Poorly Constructed Design Guidelines Characteristics The characteristics of a poorly designed guideline are: • The statement is difficult to dispute. • Is a general business or financial statement. • Does not support business goals. • Is stated at too low a level or names a product/technology. • May be included with \"because I say so\". Examples Examples of some poorly designed guidelines are: • The overall cost of computing must be reduced. (A business objective but not a guideline) • All servers will use the EISA Bus to achieve high performance. (Specifies an exact standard at a very low technical level) • Only Ethernet LANs will be implemented in our corporation. (Specifies a standard with a specific technology already selected) © 2007 Randy A. Steinberg & Robin Yearsley Page 8

Design Guideline Examples for ITIL Continual Service Improvement Overview Introduction The purpose of these examples to give the reader a starting point for defining their own unique design guidelines, not to dictate or recommend them. For purposes of clarity, the examples are grouped by key topics within the ITIL Version 3 Continual Service Improvement book. Contents This section contains the following topics: Topic See Page Improvement Process Examples 10 Service Reporting Examples 18 Service Measurement Examples 20 Return On Investment Examples 21 Business Questions Examples 25 Service Level Management Examples 27 © 2007 Randy A. Steinberg & Robin Yearsley Page 9

Guideline Example #1 – Improvement Process Guideline We will take action to continuously improve service quality. Example Our management processes encourage personnel to perform root cause analysis when statistics show an increasing trend in any particular problem category. • Continuous improvement is an added value. Rationale • Simply measuring and reporting does not ensure continuous improvement in our services. • Objective measurement facilitates cost-benefit analysis of changes. • We have objective measurements. Implication • We educate everyone involved in the improvement cycle. • Our management processes are focused on change. • We understand that improvement activities must be seen as an investment, they in cost time and resources, which are recovered later in terms of quality of service delivery. • We communicate to all the benefits of continuous improvement. • Our culture recognizes that continuous improvement of service quality is a key part of management’s role. © 2007 Randy A. Steinberg & Robin Yearsley Page 10

Guideline Example #2 – Improvement Process Guideline Business units will provide consolidated feedback on service quality levels and key service issues. Sample The Order Entry Business Unit will provide the following service Application quality feedback information to the IT Service Manager on a monthly basis: • Summary of key service issues and concerns • Level of business unit satisfaction with IT services • Changes to service functions, features and delivery targets • IT cannot tell the business what it needs – this has to come from the Rationale business directly. • Promotes business unit buy-in and responsibility for influencing IT service plans and strategies. • Promotes a business-oriented approach to delivering services. • Business units have committed to the process. Implication • We have a method of translating service quality feedback into IT terms. • IT needs to demonstrate positive results with the process or else the business will abandon it. © 2007 Randy A. Steinberg & Robin Yearsley Page 11

Guideline Example #3 – Improvement Process Guideline All service offerings will be reviewed at regular intervals to determine whether they are meeting desired quality levels from both the provider’s and customer’s points of view. Sample All services in the IT Service Portfolio are reviewed quarterly to Application determine whether they meet value and service objectives. Those not meeting objectives will undergo analysis to identify service improvement actions. • Assures the quality of services offered/received. Rationale • Identifies services with poor value and failure to meet service targets before these become overly problematic. • We have tools that identify service problems as the customer sees Implications them. • Funding decisions for improvement actions will be driven by those services that need them the most combined with their value. • We understand what services IT is offering. • We understand the quality levels of IT delivery and the service delivery chain. © 2007 Randy A. Steinberg & Robin Yearsley Page 12

Guideline Example #4 – Improvement Process Guideline Costs for measuring and reporting service, operational and process metrics should be balanced against their value and use. Sample Trace data for sales order transactions has not been turned on because Application it was deemed that the costs and effort involved with storing, processing and reporting on that data are too high. Instead, IT relies on local log data as the next best indicator for transaction performance. The business has agreed to this approach. • Costs to produce measurement data may outweigh any value of the Rationale information gained from it. • In many cases, low-cost assumptions are perfectly acceptable to the business. • Producing measurements is an overhead activity that does not produce revenue for the company. • Tooling, implementation and maintenance costs for measurement Implications tools, storage and reporting infrastructures needs to be understood. • IT needs to understand that assumptions can be acceptable to the business and that not every IT event has to be 100% accurate. • IT needs to take a holistic view of the costs for capturing data such as labor costs, maintenance, storage and other associated items in addition to the technologies being employed. © 2007 Randy A. Steinberg & Robin Yearsley Page 13

Guideline Example #5 – Improvement Process Guideline We shall apply suitable methods for monitoring and, where applicable, measurement of the service management processes. These methods will demonstrate the ability of the processes to achieve planned results. Sample IT conducts reviews at planned intervals to determine whether the Application service management processes: - conform with the service management plan and to the requirements of set standards - are effectively implemented and maintained. • IT Service Management processes cannot be considered Rationale implemented unless they are being measured. • Supports continual improvement of IT Service Management process solutions. • Cannot identify solution improvements without first measuring them. • Validates success or failure of the IT Service Management program. • IT Service Management process metrics have been defined and Implication agreed to. • IT recognizes that IT Service Management is an ongoing program, not a one-time project. • An IT Service Management oversight committee will be needed to review measurement results and prioritize improvement activities. © 2007 Randy A. Steinberg & Robin Yearsley Page 14

Guideline Example #6 – Improvement Process Guideline The objective of service management review assessments and audits will be recorded together with the findings of such audits and reviews and any remedial actions identified. Any significant areas for improvement opportunities will be communicated to relevant parties. Sample IT conducts reviews at planned intervals to determine the health and Application status of IT Service Management processes, technologies and organization. Results from these reviews are communicated to IT staff and management. IT staff and management provide feedback for remedies to any significant improvement opportunities arising from the reviews. • Improves the effectiveness and efficiency of IT Service Management Rationale practices. • Ensures value is received from conducting IT Service Management audits and reviews. • Allows those delivering IT services to participate in continual service improvement efforts. • IT Service Management reviews need to be done on a regular Implications scheduled periodic basis. • IT needs to recognize that it is okay if significant gaps are found in the reviews and that the goals are to improve processes and management techniques – not punish individuals. • A practice of developing action plans needs to arise from the results and recommendations found in any review. © 2007 Randy A. Steinberg & Robin Yearsley Page 15

Guideline Example #7 – Improvement Process Guideline There will be a published policy for continual service improvement activities. Any non-compliance to the policy will be quickly remedied. Roles and responsibilities for continual service improvement activities shall be clearly defined. Sample IT maintains a formal Continual Service Improvement policy that Application outlines the objectives and goals for the continual improvement effort. This policy also describes a high level improvement process and identifies key roles and responsibilities for carrying that process out. • Ensures that continual service improvement is a daily part of IT Rationale activities. • Prevents finger pointing and disagreements over who is responsible for continual service improvement activities. • Demonstrates IT commitment to provision of high quality services to the business. • A continual service improvement process needs to be documented Implications and agreed to. • Roles and responsibilities for carrying out continual service improvement activities need to defined and agreed to. • Audits and controls need to be put into place to identify any non- compliance with the continual service improvement policy. © 2007 Randy A. Steinberg & Robin Yearsley Page 16

Guideline Example #8 – Improvement Process Guideline All recommended service improvement activities resulting from service measurements and findings will be recorded, prioritized and authorized. There will be a process put into place to identify, manage and report on improvement activities on an ongoing basis. Sample After conducting an initial service improvement review, improvement Application actions are identified. These are then recorded as part of the IT inventory of services and projects. A project office oversees all the improvement activities and projects. These are reported on monthly to IT management to identify progress against improvement plan goals and strategies. • Ensures that consistent and formal approaches are used to capture Rationale improvement plans and make sure they are acted upon. • Provides a means for prioritizing improvements based on business priorities and needs. • Provides a communication vehicle to demonstrate how IT is improving its service quality to the business. • A Project Office may be needed to provide oversight for continual Implications service improvement activities and projects. • A means for prioritizing improvement projects needs to be defined and agreed to with IT and the business. • Both IT and the business recognize that service improvement is an ongoing activity – not a one time project. © 2007 Randy A. Steinberg & Robin Yearsley Page 17

Guideline Example #9 – Service Reporting Guideline We will regularly measure and report on the services we provide. Sample By measuring and reporting the performance of the Service Desk Application service, in the customer’s terms, we give ourselves the ability to: • Manage it. • Improve it. • Demonstrate its value to the business • Demonstrate quantifiably that agreed service levels are met. • If we can’t measure it, we can’t manage it. Rationale • Demonstrate the value provided by the services we offer so the customer will understand the investment needed to improve the service. • Enables timely, quality service provision. • A process is in place to capture the pertinent data and report it a Implication regular basis. • Measures are agreed to with the customer. • We understand that measuring is not enough and we have the disciplines and processes in place to act on issues raised. • We understand that measurement simply provides data and we have established methods to turn the data into knowledge (e.g. trend and threshold analysis). • The proactive cycle of measure, analyze, report and action is part of our management culture. © 2007 Randy A. Steinberg & Robin Yearsley Page 18

Guideline Example #10 – Service Reporting Guideline We will regularly measure and report on the services we provide. Sample By measuring and reporting the performance of the Service Desk Application service, in the customer’s terms, we give ourselves the ability to: • Manage it. • Improve it. • Demonstrate its value to the business • Demonstrate quantifiably that agreed service levels are met. • If we can’t measure it, we can’t manage it. Rationale • Demonstrate the value provided by the services we offer so the customer will understand the investment needed to improve the service. • Enables timely, quality service provision. • A process is in place to capture the pertinent data and report it a Implication regular basis. • Measures are agreed to with the customer. • We understand that measuring is not enough and we have the disciplines and processes in place to act on issues raised. • We understand that measurement simply provides data and we have established methods to turn the data into knowledge (e.g. trend and threshold analysis). • The proactive cycle of measure, analyse, report and action is part of our management culture. © 2007 Randy A. Steinberg & Robin Yearsley Page 19

Guideline Example #11 – Service Measurement Guideline We will measure and deliver services based on Key Performance Indicators (KPIs) agreed to with the business. Sample The IT services offered to the Retail Distribution business unit should Application use business terms to report benefits or impacts based on business measures such as, volume of store deliveries or number of successful picks. • Enables the business to understand the value of IT services. Rationale • IT services can better communicate the business impact and benefits from services offered. • IT services understands the business use of the services. Implication • Service Level Agreements are in place to ensure both parties have equal expectations of the service to be delivered. • A mechanism for measurement and regular reporting on these services is in place. • KPI definitions that utilize business terms are in place. • Communication of KPI’s and business value is done. • A process to track KPI’s and adjust the service accordingly is in place. © 2007 Randy A. Steinberg & Robin Yearsley Page 20

Guideline Example #12 – Return On Investment Guideline Approval to proceed with any IT service improvement initiative will require an understanding of the value and return from that initiative. Sample Each IT service improvement initiative listed in the IT portfolio Application includes both the cost of that initiative as well as its value and return to the business. • IT investments need to target those initiatives that will provide the Rationale greatest return on their investment. • The business needs to see and understand the costs, value and return for any improvement initiative since they will be setting the priorities. • Labor spent on initiatives with low rates of return is a wasted investment in valuable IT resources. • Costs and value need to be understood for each service improvement Implication initiative. • Value and rate of return may not always be easily measured or quantified for some improvement initiatives. • Any assumptions used to communicate costs or value need to be documented and agreed to by the business. © 2007 Randy A. Steinberg & Robin Yearsley Page 21

Guideline Example #13 – Return On Investment Guideline Both one-time and ongoing costs need to be understood for every service improvement initiative. Sample Costs for the new database upgrade indicate: Application - $150,000 in one-time costs for implementation and server upgrades - $40,000 in annual ongoing costs for license and maintenance fees plus a half-time additional database administrator • The true cost picture of a service initiative needs to be understood. Rationale • Some initiatives may be attractive in terms of their one-time costs but terrible once ongoing costs are considered. • One time and ongoing costs need to be fully understood for each Implication initiative. • IT needs to take a holistic view of all costs (not just technology costs) when assessing the costs of an initiative. • Some costs may be ancillary – such as non-productivity, sales lost or market shares not gained when assessing costs of an initiative. © 2007 Randy A. Steinberg & Robin Yearsley Page 22

Guideline Example #14 – Return On Investment Guideline Every service improvement initiative effort will include a periodic review to assess whether planned value and return have been realized. Sample Every 6 months, a joint meeting is held between IT and the business to Application review each service initiative implemented and completed within the last 12 months. The value and return being realized with these is compared to their business case to validate whether planned objectives have been met. If not, the initiatives may be reopened to see if further work might be needed to make those objectives. • Determines whether IT efforts are succeeding or failing. Rationale • Some initiatives may be treated as completed when in reality they have not achieved their objectives yet. • Provides a means for lessons learned to improve the Service Continual Improvement processes. • ROI validation needs to be part of any post implementation review Implications efforts for service improvement initiatives. • Current value and ROI will need to be measured and understood for any initiative. • Each initiative needs to have a documented business case associated with it. © 2007 Randy A. Steinberg & Robin Yearsley Page 23

Guideline Example #15 – Return On Investment Guideline Every service improvement initiative needs to be associated with a formal documented business case. Sample An IT manager prepares a business case for a new service Application improvement initiative showing: - Description of the initiative - Planned value to the business - Planned rate of return to the business - One time costs for implementing the initiative - Ongoing annual costs associated with the initiative • Provides a baseline to compare the result of the initiative to its Rationale original plan. • Ensures clear understanding of the initiative and what it is supposed to achieve. • Provides input to those implementing the initiative to contain scope and focus on its intended objectives. • A consistent standard template for a Business Case will be needed. Implications • The business must agree to the business case presented. • Business cases will need to be archived and maintained. • Business cases must be well communicated – especially to those implementing the initiatives. © 2007 Randy A. Steinberg & Robin Yearsley Page 24

Guideline Example #16 – Business Questions Guideline Each improvement initiative will need to be recognized in terms of its value to the business and involve the business in the value decision. Sample Each quarter, IT prepares an inventory of all service improvement Application initiatives with their expected costs and benefits. Key business representatives review this inventory and make the final approval on priorities for implementing those initiatives. • Only the business fully understands the true impacts and value of a Rationale service improvement initiative. • Ensures IT activities are aligned with business goals and objectives. • Potential IT service improvements need to be proactively recognized Implication and documented. • Costs and benefits for each improvement initiative need to be understood and agreed. • IT recognizes that some business priorities may be different than IT priorities. © 2007 Randy A. Steinberg & Robin Yearsley Page 25

Guideline Example #17 – Business Questions Guideline Business reviews of IT service initiatives will follow a consistent structured analysis approach. Sample For each IT service improvement initiative, the following questions are Application officially raised: - What is the baseline quality for this service? - What benefits will occur because of implementing the initiative? - What are the one-time costs for the improvement initiative? - What are the ongoing costs for the improvement initiative? - What value will be received from the improvement initiative? • Not asking the right questions can lead to misplaced IT Rationale investments. • The business may challenge IT priorities and judgment. • IT priorities may be different than those of the business. • A consistent structured analysis approach needs to be defined and Implications agreed to with the business. • Some initiatives viewed as important by IT may not pass the analysis effort. • IT understands that business priorities sometimes outweigh IT priorities. • Changes in service targets and capabilities need to be understood as part of the value analysis. © 2007 Randy A. Steinberg & Robin Yearsley Page 26

Guideline Example #18 – Service Level Management Guideline No service targets will be established that cannot be effectively delivered, measured and reported on by our IT service organization and its suppliers. Sample The Desktop Support service will not guarantee repair of a desktop Application at a user location any sooner than 8 hours because the 3rd party support service cannot provide, guarantee or report on repairs taking less than one day. • Setting service targets that can’t be met will only create distrust and Rationale low satisfaction in the services IT delivers • The business may make costly mistakes by relying on IT services that really can’t be delivered as promised • Wasted labor is incurred in dealing with user calls, complaints and issues when their expectations are not met • A Service Catalogue is in place that clearly describes the services Implications and service targets that customers can expect to receive • Capabilities are in place to measure and monitor the service targets that have been set • A formal agreement process is in place for agreeing the service targets from the start • All 3rd party suppliers have agreed and documented the services and service targets they intend to deliver © 2007 Randy A. Steinberg & Robin Yearsley Page 27

Guideline Example #19 – Service Level Management Guideline No service target will become a service level unless it can be measured per methods agreed to by both the provider and the receiver of the service. Sample The availability service target for the HR Support service will be Application considered below target if more than 5 incident calls have been logged at the Service Desk in any given month. The Service Desk has the capability to measure how many calls for that service are received. The target of less than 5 calls per month has been agreed to by both IT as well as the HR business unit. • What cannot be measured cannot be managed. Rationale • Satisfaction with IT services will be low if only IT is setting the targets they think the business needs. • IT will typically operate and manage with service levels that they feel comfortable with delivering even though they may be inadequate for the business. • Increases business confidence in IT capabilities and services. • Service targets are defined in business terms. Implications • IT has the capabilities in place to monitor and measure the targets being established at reasonable cost. • A negotiation and agreement procedure is in place to agree on service targets and levels. • Reporting and communications are in place to communicate how well service targets have been met. © 2007 Randy A. Steinberg & Robin Yearsley Page 28

Guideline Example #20 – Service Level Management Guideline Services will be managed proactively to address business needs versus just reacting to business events and service issues. Sample IT action is initiated when established service targets appear Application threatened versus delaying action until they fall below target. • Increases business unit satisfaction with IT services. Rationale • Increases business unit confidence in IT capabilities. • Lowers risk of costly service outages. • Prevents service outages from occurring before they become visible incidents and problems. • Clearly established and agreed service targets are in place. Implications • Capabilities exist to monitor threats to established service targets before they become too severe. © 2007 Randy A. Steinberg & Robin Yearsley Page 29

Guideline Example #21 – Service Level Management Guideline No service targets will be agreed and communicated until all underpinning provider and supplier services related to those targets are formally agreed to. Sample Publishing of the availability service target for the Customer Application Relationship Support service is being delayed pending the underpinning contract with the 3rd party application support vendor and signature on Operational Level Agreements with 2 IT technical support units. • May set and communicate service targets that cannot be delivered. Rationale • Providers and suppliers will have no stake in ensuring targets are delivered as needed by the business. • Ensures that services are managed end-to-end versus as individual technology support silos. • Underpinning contracts and Operational Level Agreements need to Implications be established and maintained. • Some 3rd party vendor contracts may need to be modified if their service delivery targets are ill defined. © 2007 Randy A. Steinberg & Robin Yearsley Page 30

Guideline Example #22 – Service Level Management Guideline Each business unit will have a single point of contact into the IT organization for all its services to address service quality, escalate service issues and communicate service changes. Sample A Business Unit IT Liaison representative meets with the Marketing Application department once each month to review service quality, report on progress of key service issues and communicate new services needed by that department to IT. • Greatly increases business unit satisfaction with IT services. Rationale • Provides business needs and a business perspective to the IT organization. • Addresses service issues before they become too severe. • Identifies new changes to services needed to keep up with business demands for IT on a timely basis – prevents unplanned surprises. • Ensures IT activities are appropriately aligned to business needs. • Investment in IT to business liaisons will be needed. Implications • Roles and responsibilities for liaison staff need to be clearly defined. • Liaisons need to be aware of IT plans and activities. • Liaisons have proper management support to get things accomplished on behalf of the business units they represent. © 2007 Randy A. Steinberg & Robin Yearsley Page 31

ITIL Continual Service Improvement Design Guidelines For Version 3

0 comments

Notes on slide 1

2 Favorites