Skip to main content

Posts

Showing posts with the label ITIL Service Design

Co-Create and Accelerate! – ITIL 4

What is changing in your organization? The easier question might be what is not changing. We live in an accelerated world. To say that business and customer requirements are evolving is an understatement. It is a volatile time and the Co-Creation of services between service providers and customers as defined in ITIL 4 is the type of guidance could help. Studies have shown that there is a direct relationship between customer engagement in value co-creation and customer satisfaction.  There is no room for an “Us and Them” environment. Engagement means that we vet the requirements with the customer to ensure needs but also that the customer will engage and play a role in the design, development and the delivery of the product or service. They won't necessarily get down in the weeds with the developers and techies, but they absolutely should have a strategic and a bit of a tactical role to play throughout.  Beyond the consumer/customer and the service provider, the

ITIL – Back to Basics for Agile and DevOps

ITIL advocates that IT services are aligned to the needs of the business and support its core processes. It provides guidance to organizations and individuals on how to use IT Service Management (ITSM) ­­­as a tool to facilitate business change, transformation and growth. Some are believing that ITIL has run its course.  In truth I believe the opposite is true.   In the past, and still today, many organizations believe that Best Practice and ITSM processes are focused on the Service Operation Lifecycle.   Implementation, process design, and ITSM tools have had a very heavy focus on processes like Incident, Problem, Change and Configuration Management. Few have yet to recognize or have not seen the value in the guidance for Service Strategy and Service Design processes and roles.   How did these get overlooked? In the last three or so years I have seen a bit more buzz about “Business Relationship Management”.   Less so for “Demand” and “Strategy Management” for IT Services. Few are

IT Service Management - Tools

In today’s world where demand for up to date services has grown and the lead times for delivery has continued to be shortened I am often asked, what is the best tool? The answer is, of course, “it depends!” Every organization has different needs, budgets and resources, however the requirements for automated building, testing and delivering new functionality has never been greater. Every organization must be able to look at the list of requirements for tools from both the operational and development sides of the IT organization as the functions become more and more integrated. The starting point is a list of generic requirements. An integrated suite is preferable and should include options such as: Service Portfolio Service Catalog Service Design Tools Discovery/Deployment/Licensing Technology Workflow or process engines CMDB’S Configuration Management Systems (CMS) Self Help for Users Remote Control Diagnostic Utilities Reporting Tools/Dashboards Service K

Service Acceptance Criteria

I have often been asked what value does the Service Acceptance Criteria (SAC) provide?  Along with other criteria and elements, the Service Acceptance Criteria forms what is described in ITIL and the Service Design Package.  With so much importance on Design, Development and Deployment, the significance of the SAC increases as we look to optimize service value.  Do you want to increase value to your business and customers? First let’s understand what the SAC is.  Service Acceptance Criteria:   A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT Service when it has been deployed. This set of criteria is in the form of a formal agreement that an IT Service, Process, Plan or other deliverable is complete, accurate, reliable and meets the specified requirements.  In the past, this has sometimes been thought of and enacted on at the end of the value stream. High performi

Incident vs. Problem

You may have seen a similar blog from the Professor a few years back that talked about the distinction between the idea of an incident vs problem.  Everything from that article is still relevant.  As process and methods for development and deployment have matured so has the usage of Incident and Problem Management. This is one of the most often confused points in for Agile, LEAN and ITIL adaptations. The ITIL definition is the same. Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality Problem: The cause of one or more incidents, events, alerts or situation­­­­­­­ Where and how we apply Incident and Problem Management is evolving. A decade ago, and still in some organizations, Incident and Problem Management are processes exclusive to Service Operation.   ITIL is so very relevant and today we find, with the onset of DevOps and cultural shifts, many organizations are adopting little or zero tolerance

The Purpose and Value of a Business Impact Analysis (BIA)

I am often asked the purpose and value of a Business Impact Analysis (BIA).  The purpose of a BIA is to quantify the impact to the business (in dollars and cents) that the loss of a service would have.  It is a valuable source of input when trying to ascertain the business needs, impacts and risks that the organization may face in the delivery of services.  The BIA is an essential element of the overall business continuity process.  It identifies the most important services to the organization and therefore will help to define the overall strategy for risk reduction and disaster recovery.  At a more granular level this analysis enables the mapping of critical service applications and technology components to critical business processes.  It is an invaluable input for Continuity, Strategy, Availability, Design, and Capacity Management and can have a significant impact on the cost of designing, delivering and maintaining these services based on their criticality as defined by the busin

Service Test Models

Quality: The ability of a service or product to meet customer requirements and create value for that customer.  Perceived quality affects customer support more than any other element.  Products and services must attain a certain minimum level of quality.  No other components can make up for a significant shortfall on this one and the perceived loss of value this can create. In business today, “Time to Value” has increasingly become one of the most significant measures an organization reviews and reports on.  Today’s ever more progressively shorter time scales for this cannot be met without being able to incorporate such practices as continuous delivery (CD), continuous integration (CI) and continuous deployment (CD), which all are dependent on our ability to do continuous testing. As many of you have certainly experienced, this need for speed continues to be a clear and present danger in our ability to create a high trust culture where testing and learning from failure is allowed

The Technical Catalog

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization.  In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog.  In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support.  The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure.  It is this second view that we will review here. Our service catalog provides us with a central source of information on all of the IT servi

Failing Forward

In the introduction of her book The ITSM Process Design Guide, Donna Knapp writes “In today’s competitive business climate it’s not enough to do things right; Information Technology (IT) organizations have to do the right things right.”  Well what happens when we don’t? Remember New Coke?  Not every decision we make, every new design or redesign we engage in goes according to plan.  What happens when we fail?  One of the most important and most deeply entrenched reasons why established companies struggle to grow is fear of failure. In fact in a 2015 Boston Consulting Group survey, 31% of the respondents identified a risk adverse culture as a key obstacle to innovation. (1)  ITSM processes for strategy, design, transition, operation and CSI are all based on efficiency and effectiveness.  It’s about being in control of our IT environments and that we must do everything we can to prevent failures.  Now this may go against many of our strongly held beliefs but Pixar’s president, Ed Ca

The Customer Experience

We are all customers of someone right?  What was your last customer experience like?  Was it so good that it completely changed how you thought about the product or the organization you were receiving services from? On the other hand was the service you received so poor that you vowed never to use their products or services ever again.  We have all been in those situations. You may not have realized it, but how that interaction was designed can have a huge impact on the perception you, the customer, walk away with.  I recently read a series of articles in the September issue of Harvard Business Review magazine.  The entire series was titled “The Evolution of Design Thinking” - It’s no longer just for products. It speaks to how executives are using this approach to devise strategy and manage change.  I can’t tell you what an absolute must read this is for all.  It will make you take a second look at how you design, deliver and support the services to your customers. For me personally t

Designing a Service Design Package

I was recently asked what the compliance requirements, architectural constraints and interface requirements are in designing the service design package for a new app. The short answer is that the Service Design Package (SDP) would have ALL of the documents and information related to how the app was designed and developed including any policies or known compliance or other constraints.  The purpose of the SDP is to provide a living set of knowledge assets that can be passed around the lifecycle for use in each stage (e.g. deployment, operations, support, updating, etc.). For more information the the SDP please use this link:  http://www.itsmacademy.com/itil-sd/

Managing Across the Lifecycle

As the current IT organization has grown from a provider of technology to the Service Provider of choice we have had to incorporate the principles of service management to ensure that we deliver the outcomes required by our customers.  Given that, we have to ask ourselves a couple of strategic questions: What outcomes are we trying to provide? How do we as a service provider facilitate that? Delivering an outcome based definition of services will allow the IT organization to move beyond just business / IT alignment to towards business / IT integration, which really should have been the goal from the beginning.  Supporting customer / business outcomes should be the ultimate focus of the IT organization thus creating value through the delivery of services. A focus on business outcomes is both a critical and in most cases a cultural shift for IT service providers.  As customer’s preferences and perceptions change over time so does the value statement that a service provider

CSI and Design Coordination

I have often been asked about how to implement a good design coordination process.   My response is have you ever thought of implementation of a new process from a CSI approach?   First let’s understand what the purpose and objective of a design and coordination process should be.   Ensuring that the goals and objectives are met by providing and maintaining a single point of coordination and control for all activities and processes within the design stage of the lifecycle.   If we approach this from a Continual Service Improvement perspective the first question to ask is: What’s the vision?    Come to an accord among key stakeholders about what it is you want to create and what the underpinning critical success factors should be in support of the defined goals and objectives of the organization.   Will they ultimately support the long term mission and vision of the business leadership? Where are we now? Set that baseline starting point about the current condition of where yo

Measuring Service Management Maturity

I was recently asked about how to measure service management maturity when the maturity of individual processes is not equal. Frankly, it’s a bit of chicken and egg. It can be difficult to define where your organization is as a whole compared to each individual process when the processes are at different levels. When we look at a specific process we have to judge it against a specific set of criteria. Each organization will develop this criteria based on the organizational goals and objectives. Each process may have a different set of criteria, different levels of benefit or impact so therefore a different level of need-based maturity. For example, for organizations that are highly dependent on suppliers and outsourcing, the need for a mature Supplier Management process is critical. Other organizations may not focus on Supplier Management but invest their focus and resources on other processes such as Configuration Management. The maturity of individual Service Management process

Component Failure Impact Analysis

Availability Management balances business availability requirements against the associated costs. So, should we consider availability requirements before the service has been designed and implemented or after?  The Availability Management process should begin in the Service Strategy stage of the lifecycle and continue in each stage of the service lifecycle. Availability Management ensures that the design approach takes two distinctive but related perspectives. Designing for availability focuses on all aspects of the technical design of the IT service. Designing for recovery ensures that in the event of a service failure, the business can resume normal operations at normal as quickly as possible. One of the techniques that can be invaluable to both perspectives is the Component Failure Impact Analysis (CFIA). The CFIA can be used to predict and evaluate the impact a component failure can have on its related IT service. This activity identifies areas of weakness or fragility within

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

People are Important to Service Design

One of my favorite sets of analogies to use in class is food, the making of  food or restaurant operations. We make what we eat by pulling together ingredients into recipes. In the same way, we design services. We use the elements of services combined into the five aspects of design (solutions, tools, architectures, process and measurement) to produce the Service Design Package (SDP). When we think about designing services, we must remember it takes a number of elements. ITIL v3 says there are four elements of service design: People Process Products Partners I like to think of these elements as the “ingredients” of a service. The most important “ingredient” in any service is the “people”. We can have effective processes, efficient products, and loyal partners, but without people the service will get nowhere.   People are the elements that make the value for the customer truly possible. Processes do not execute themselves, products do not spontaneously build and partners are not

Usability or "User-Ability" Requirements

Too often, IT professionals jump from strategy right into implementation without doing the proper due diligence in collecting, analyzing and recording detailed customer requirements. The ITIL Service Design book defines three levels of requirements: Functional, Management / Operational and Usability. It gives us in-depth descriptions of Functional requirements and Management/Operational requirements but leaves me a bit empty when it comes to Usability requirements. The definition is as follows, “The primary purpose of usability requirements is to ensure that the service meets the expectations of its users with regard to its ease of use. To achieve this: Establish performance standards for usability evaluations Define test scenarios for usability test plans and usability testing. I like to define this as “User-ability”. Service Design (Section 5.1.1) describes this as the ‘look and feel’ needs of the user that facilitates its ease of use. Usability requirements ar

Making the Case for Self-Help

HDI (formerly Help Desk Institute) recently released its 2009 Practices and Salary survey and reports that an incident resolved via the telephone costs $22, while an incident resolved via self-help costs $12. Furthermore, 11 percent of the organizations surveyed report that self-help tools are prompting a decrease in the number of incidents reported to the Service Desk. Having said that, these organizations also report that only three percent of incidents are resolved via self-help. With the Baby Boomers retiring and technically savvy Gen Y joining the workforce – and, oh yeah, the economy – the time has come to get serious about self-help as a support channel. Many think the solution lies in finding and installing the right technology; however, new technology projects often fail from a lack of preparation and management. Here’s where the four Ps come in to play. Introduced in the ITIL Service Design publication, the four Ps – in the context of self-help – include: People – How can yo

Collecting and Analyzing Requirements

Every ITSM framework and standard references the need to meet "customer requirements". Unfortunately, there is less attention paid to the process of collecting and managing those requirements. I am happy to report that the ITIL Service Design book contains some good high level guidance on "Requirements Engineering" (Section 5.1). Requirements Engineering is defined as "the approach by which sufficient rigor is introduced into the process of understanding and documenting business and user requirements and ensuring traceability of changes to each requirement." The section goes on to to describe a Requirements Catalog for documenting and managing changes to requirements. It also describes techniques and tools for gathering, analyzing and validating requirements with customers. ITIL defines three levels of requirements: Functional, Management and Operational and Usability. The Service Design book is particularly good for those who do not have a background in