Skip to main content

Posts

Showing posts from April, 2013

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