Skip to main content

Posts

The Best of Service Operation, Part 4

Event Management Activities Originally Published on November 9, 2010 In an earlier blog I was asked how to move from a reactive organization to a proactive one. My answer was through the use of Event Management, along with good design and proactive Problem Management. In this installment I would like to speak to the activities within Event Management and the impact they play in our ability to deliver a consistent level of services and a stable infrastructure to deliver them across. By definition an event is any detectable or discernible occurrence that has significance for the management of the IT infrastructure or the delivery of IT services. Event Management is the process that monitors all events that occur through the IT infrastructure to allow for normal operation and to detect and evaluate the impact any deviation might cause to the IT infrastructure or delivery of IT services. Event Management has several activities that we engage when implementing this process.  Event No

The Best of Service Operation, Part 3

The Value of Known Errors and Workarounds Originally Published on December 7, 2010 The goal of Problem Management is to prevent problems and related incidents, eliminate recurring incidents and minimize the impact of incidents that cannot be prevented. Working with Incident Management and Change Management, Problem Management helps to ensure that service availability and quality are increased. One of the responsibilities of Problem Management is to record and maintain information about problems and their related workarounds and resolutions. Over time, this information is continually used to expedite resolution times, identify permanent solutions and reduce the number of recurring incidents. The resulting benefits are greater availability and less disruption to critical business systems. Although Incident and Problem Management are separate processes, they typically use the same or similar tools.    This allows for similar categorization and impact coding systems.  Each of thes

The Best of Service Operation, Part 2

Tool Selection Criteria Originally Published on February 1, 2011 Service management technology plays a major role in our support of the business. There are enterprise wide tools that support service management systems and processes. There are also tools which support the specific lifecycle phases. You should define your process before selecting a tool. Countless organizations have purchased a tool prematurely, only to find that it does not match the workflow of their newly reengineered process. Defining one or more processes first will help to narrow down the requirements and selection criteria and make it easier for the supplier to demonstrate how their product can complement your new process. Match tools to the process, not the other way around. Wading through all the options, vendors, suppliers can often be a daunting task. Let’s discuss a technique for evaluating tools and finding the product which will support our goals and objectives. What Requirements? Meet with th

The Best of Service Operation, Part 1

We continue our "Best of " blog series by moving into Service Operation.   Cost per Incident Originally Published on August 17, 2010 A reader, upon downloading our ITIL ROI calculator , recently asked the following great question, “how do you determine cost per incident?” Cost per incident is a variation of cost per call or cost per contact, all of which are excellent ways to understand the impact of incidents, calls, or contacts on the business. The calculation is fairly straightforward. Cost per incident is the total cost of operating your support organization divided by the total number of incidents for a given period (typically a month). Cost per incident = total costs/total incidents To accurately calculate cost per incident you must: Log all incidents. You may also find it beneficial to distinguish between incidents (unplanned events) and service requests (planned events). Such a distinction will enable you to more accurately reflect business impact

Handling Incremental Delivery with ITIL Processes

As a follow-up to post regarding the blur between development and service management, a reader commented that DevOps seems to represent a long standing tradition of incremental delivery.   In that case, the reader asks “How is   incremental delivery tracked and managed in an ITIL framework? Would these initial requests for capability tracked as Requests and ultimately as a Request for Change?” As you can imagine, the answer is “it depends”.     An organization can choose to have multiple RFCs submitted or have a single RFC that decomposes into multiple releases but is managed as a single project.   Regardless, the incremental delivery addressed in DevOps is much faster than it was in the past – therefore requiring a tighter integration between development and operations teams – they must communicate well, use shared vocabulary and more importantly, shared metrics and dashboards. Teams that are tightly integrated will have higher rates of rapid change success – so much s

The Best of Service Transition, Part 4

Prioritizing Changes Originally Published in 2011 The Professor recently received the following question: Having put together a spreadsheet of information that I need to assess the impact of a change,  what I need to do next is figure out how to assess the impact of a change as being high, medium, or low? Any guidance you can give me on how to do this would be greatly appreciated.” The  Service Transition book provides great guidance on assessing the impact of changes (ST 4.2.6.4). This section provides 7 questions that must be answered to fully understand the impact. Many of these questions are answered using information in your spreadsheet. Others you may want to consider adding.  Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change?

The Best of Service Transition, Part 3

Early Life Support Originally Published on May 3, 2010 I have found, after doing a number of releases throughout my career, that a solid Early Life Support program (ELS) can really enhance the acceptance and support of any new or changed service. The ITIL Service Transition definition of ELS is the “Support provided for a new or changed IT service for a period of time after it is released." During ELS the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional resources for Incident and Problem Management.   Although stakeholders have agreed to the entry and exit criteria in the Service Design stage, it may become necessary to finalize the performance targets and exit criteria after the build and testing of the service has been completed. This will help to clarify the deployment process and set the proper expectation of the operational resources that will perform the support after ELS has been completed. ELS ensures that ap

The Best of Service Transition, Part 2

Transition Planning and Support Originally Published on February 28, 2012 I am often asked on how to manage transition.   Most organizations find that there are a lot of moving parts.   What happens here effects all stake holders and if expectations aren’t set correctly the reputation of the IT organization can often be at risk and that it can be difficult to meet the changing needs of the business in a cost effective and timely manner.   In order for us to be able to effectively meet these challenges we should start with the big picture process of Transition Planning and Support: The purpose and objective of the transition planning and support process is to provide overall planning for service transitions and to coordinate the resources that are required.   It does that with the following activities: Plan and coordinate resources to deliver the requirements of service strategy that have been translated in service design and insure they are effectively delivered in service oper

The Best of Service Transition, Part 1

We continue our "Best of" blog services by moving into Service Transition Who is the Change Initiator? Originally Published on July 21, 2010 The “change initiator” is the individual or group that is requesting the change. Change initiators could be users, suppliers or IT staff – depending on the nature of the proposed change. It is the change initiator’s responsibility to justify the reasons for making the change.  However, since the change initiator may not understand all of the risks associated with a seemingly innocuous change, some type of impact assessment should occur.  The assessment could be very simple and quick - or extensive- based on the scope of the change and business processes that are potentially affected. The change authority (CAB, Steering Committee, local CABs, etc.) assesses the impact of the propose change and determines if the change is necessary or beneficial.  Impact could be negative or positive and should consider cost/benefit, resources r

The Blur between Service Management and Development

Someone recently asked me to clarify how service management handles the blur between management and development.    Great topic area. While many perceive service management frameworks as affecting only the production environment, ITIL and others actually wrap best practices around an entire service lifecycle that starts with strategy and works its way through design, transition and operation.   Service management does acknowledge that there are already proven, trusted software development lifecycle (SDLC) approaches in use and that development may occur inside or outside the customer organization.  Given that, there is more focus on service design than service development  in ITIL and a recommendation to use the SDLC methodology of choice when developing. Enter DevOps - a philosophical movement that recognizes that today's rapid development environment requires a stronger connection between development teams and operational teams.   Agile is quickly replacing the classic waterf

The Best of Service Design, Part 4

ITIL 2011:  Design Coordination Originally Published on September 20, 2011 The Service Design stage of the ITIL Service Lifecycle can be a powerful and beneficial set of activities and undertakings if managed, guided and coordinated in a holistic and comprehensive manner. One of the more powerful processes to emerge with the publication of the ITIL 2011 addition is the Design Coordination process. Previous editions of ITIL had the reader and practitioner assume or extrapolate the guidance provided in the Design Coordination process. ITIL 2011 formalizes the guidance and shows the need to have a method of ensuring the smooth operation of all the moving parts of Service Design.   Design Coordination has several important objectives including (SD 2011 4.1.1): Ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements

The Best of Service Design, Part 3

The Importance of Availability Management Originally Published on July 5, 2011 The Availability Management process ensures that the availability of systems and services matches the evolving agreed needs of the business. The role of IT is now integral to the success of the business. The availability and reliability of IT services can directly influence customer satisfaction and the reputation of the business. The proactive activities of Availability Management involve the proactive planning, design and improvement of availability. These activities are principally involved within design and planning roles. The proactive activities consist of producing recommendations, plans and documents on design guidelines and criteria for new and changed services, and the continual improvement of service and the reduction of risk in existing services wherever it can be cost-justified. There are several guiding principles that should underpin the Availability Management process and its focus:

The Best of Service Design, Part 2

ITSM Requirement Gathering Techniques Originally Published February 20, 2010 In a previous discussion, we talked about the three levels of requirements in Service Design: Functional, Usability and Management and Operational. There is a range of techniques that can be used to actually obtain these services requirements. It is often difficult to get your customers to verbalize what they need. It has been my experience that the customers and the business are not completely sure of what their requirements actually are. They will need assistance and prompting from the designer or requirements gatherer. This must be done in a professional and sensitive manner to ensure that it is not seen as IT dictating the business requirement. We are all familiar with the most popular techniques, interviewing and workshops. The following is a list of additional techniques which might aid you in the Service Design requirements gathering stage: Observation: Watch your customers perform a spec

The Best of Service Design, Part 1

We continue our "Best of" blog series by  moving into Service Design. The Service Design Package Originally Published in 2010 I have gotten many questions about what value does the Service Design Package provide? We first must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, clear, concise and unambiguous specifications of the requirements must be documented and agreed. The SDP is where we document and agree to Requirements – What the business wants and how they plan to use this new service. Define who all of the stakeholders are  Service Design – Functionality of this new or changed service (SOR). Service levels to be delivered (SLRs, SLAs). Operational management requirements (OLAs, Contracts). Overall design and topology. Defined outcomes and deliverables.  Organizational Readiness Assessment

The Best of Service Strategy, Part 5

ITIL 2011:  Business Relationship Management Originally Published on August 16, 2011 With the recent publication of the ITIL 2011 edition, several items within the best practice set have undergone a transformation. One of the goals of the 2011 edition is to bring even more consistency and standardization to the best practices by formally recognizing and organizing several ideas and activities that the 2007 edition had not previously structured as full, formal processes.  While always referenced in the 2007 edition (and ISO/IEC 20000), Business Relationship Management is now an official ITIL process The newly structured Business Relationship Management process now formalizes the activities and links between the customer or user and the service provider through a central contact point embodied in the Business Relationship Manager role. The ITIL 2011 edition states that the purposes of Business Relationship Management are twofold: To establish and maintain a business relatio

The Best of Service Strategy, Part 4

Cycles Originally Published December 4, 2012 As we move into the waning of the year in the northern hemisphere and the waxing of the year in the southern hemisphere, it becomes time to reflect on the meaning and understanding of the idea of cycles. The yearly cycle of seasons was long ago recognized by early mankind as playing a significant role in culture and society. Planting, growth, maturity and harvesting each set the day to day activities of peoples around the globe throughout a given year. This is no less true when it comes to the lifecycle of services and the lifecycle of Service Management. Both play a significant part in the culture and functioning of an organization. A cycle is defined as “any complete round or series of occurrences that repeats or is repeated.” This definition holds true for service management and IT services. When it comes to providing value through IT services and governing, controlling and managing those services, we do not exist in a “once and

The Best of Service Strategy, Part 3

The Fundamentals of Portfolio Management Originally Published June 14, 2011 IT must begin to align with drivers of business value other than just managing infrastructure and applications. In order for IT to organize its activities around business objectives, the organization must link to business processes and services, not just observe them. IT leadership must engage in a meaningful dialogue with line-of-business owners and communicate in terms of desired outcomes. We have to become a Business & Service oriented organization. The transition from managing infrastructure to managing services is a fundamental cultural shift for many organizations. Managing infrastructure requires a focus on component operational availability, while managing services centers on customers and business needs. In order for us to link service assets to business services we must first begin to develop a portfolio of services using the following work methods. Define: Begin by collecting informatio

The Best of Service Strategy, Part 2

Service Strategy's Four P's Originally Published on July 10, 2012 Whenever I am introducing ITIL and ITSM to a new group of students I always make sure that the concept of Strategy as a process is always discussed.   The reaction that I usually get from most is: “Strategy isn’t something the business does?”   I begin our discussion with a simple definition.   Service Strategy comprises the processes of: strategy management for IT services, service portfolio management, financial management for IT services, demand management and business relationship management.   In the world of ITSM, Service Strategy is the stage of the lifecycle were we align our IT strategy the with business strategy and define our perspective, position, plans and patterns that we as a service provider will have to execute in order to meet an organizations business outcomes.     These four elements must be present and help guide us in defining and documenting our overall IT strategy.     

The Best of Service Strategy, Part 1

I've been hearing a lot lately about "going back to the basics" of ITIL and IT Service Management.  So for the first half of 2013, I'm going to package and republish the best of my blogs for each lifecycle stage.  As always, I welcome your comments and questions!   ~~ ITSM Professor Utility and Warranty Equals Value Originally published October, 2012 When a service provider is developing a service for a customer or group of customers the underlying goal is to ensure that the service has value for the customers by meeting a set of defined requirements.    The value is often defined by what the customer is willing to pay for this service rather than what it actually cost the service provider to produce the service or any other essential feature of the service itself. Services themselves do not actually have intrinsic value.   That value is created by the outcome enabled by employing the service and therefore the value of the service is not determined by the provid

Change Evaluation

I often get asked where change evaluation takes place.   Isn’t it part of change management?   It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.   It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended affects, unintended affects and actual performance once the service change has been implemented.    The purpose of change evaluation is to provide a uniform and structured means of determining the performance of a c