Skip to main content

ITIL 4 Guiding Principles – Focus on VALUE!


Adopting the ITIL seven “Guiding Principles” for service providers could be the best way to establish a healthy organizational culture. All “Guiding Principles” are powerful but today are some thoughts on just one and that is “FOCUS ON VALUE”.  

ITIL 4 best practice guidance says to focus on value.  Getting level set on what VALUE is for your business partners, customers and consumers is critical to every strategic, tactical and operational action! To understand this better let’s start with the official definition of a service. “A service is a means of enabling value co-creation by facilitating OUTCOMES that customers want to achieve without the customer having to manage specific costs and risks". If this is so, then there is a direct correlation between VALUE and OUTCOMES. When it comes to defining “VALUE” we must get OUT of “IT”. 

An “OUTCOME” is what we deliver. It is not the activities within the value delivery stream but rather the RESULTS of all people, process, activities, and technology that is used. Every initiative/action has a value-add element to it but in and of itself does not deliver VALUE. In order to deliver value, it is not only necessary to identify the requirements for a new or changed service but also to identify and agree on what the expected OUTCOMES should be. These identified and quantified outcomes will become the cornerstone for your metrics and measurements. All too often we look at internal metrics to measure value and truly this does not work. 

Example: 

A techy at a large insurance company asks; “How many servers should we be able to spin up per hour in order to have a good DevOps continuous delivery pipeline?” 

Or 

Developer says, "We doubled our cycle time from Q1 to Q2!" 

This is a very large insurance company so one of their business partners is “Claims Processing”. Now, put yourself in that seat. Do either of these internal siloed measurements resonate with the person who is processing claims? The answer? “No”! 

In order to get to real OUTCOMES, that deliver VALUE we must get out of “IT”. The measurements in the first example may or may not RESULT in VALUE! How do we know what VALUE is? Quantify the OUTCOMES from the customer perspective! Therefore; a better example to identify and quantify outcomes here might be: 

How many claims does Claims Processing Department need to process per hour? 

When two hurricanes hit the United States few insurance organizations were able to manage the volume of requests for processing claims in a timely way for their consumers. This example is a quantified customer OUTCOME that is sure to deliver VALUE for the service provider, the business customer and the external consumer! Once OUTCOMES are identified the service provider can then determine what the low-level metrics and measurements in the value stream should be to meet that “QUANTIFIED OUTCOME”. 

Promoting a “Focus On Value” culture is an effective way of breaking down organizational siloes. Every person in your organization should have a clear understanding their contribution towards creating value for the organization, its customers and other stakeholders. 

Educate & Inspire…



Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…