The Professor was recently asked about Application Cost models.  While ITIL does not speak specifically about “Application Cost Models,” there is information about how to create a service cost model using ITIL’s Financial Management process.  From ITIL’s perspective, an application is one part of an end-to-end service. Developing a cost model involves: Identifying all costs attributed to the service (hardware, software, salaries, accommodations, external services, transfer costs (e.g., from other internal units) Determining which costs can be directly tied to the service Deciding how to fairly apportion indirect costs (e.g., infrastructure, technical staff time) Adjusting the total to allow for unabsorbed overhead costs (e.g., administrative or managerial salaries, building/accommodation costs such as a data center or IT office space) A spread sheet can be used to break each cost down into a unit cost.  Overall cost for the application (or service) can then be calculated based

Perhaps one of the most underused yet powerful processes from ITIL is Problem Management. Many people recognize the importance of Problem Management, especially in relationship to Incident Management. Yet when I ask students if they have implemented a Problem Management process the response is often “We plan to...” or “We started but did not get too far…” or “Not yet.” So what is keeping companies and individuals from using Problem Management to its full effectiveness? I propose that some of the reason is fear, uncertainty and doubt about how to go about “doing” Problem Management. By understanding that the Problem Management process has a number of techniques and tools available to help a service provider indentify root cause and recommend permanent resolution we may be able to remove some of the fear, uncertainty and doubt. What are some of the techniques and how could we apply them? Let’s take a brief look and see what we can uncover. Chronological Analysis: This time based appr

The Professor was recently asked for real life examples or best practices for the criteria that organizations have used to define major incidents. ITIL defines a major incident as an incident that results in significant disruption to the business and so real world examples are going to vary from one business to the next. For a financial services company, for example, a major incident could be an incident affecting live money transactions. For a retail company, a major incident could be an incident affecting its point of sale service. For a manufacturing company, a major incident could be an incident that affects the production line. Simply put… real dollars are being lost. A major incident could also be a service outage that affects are large number of users. Those users could be your company’s external customers, or it could be your internal employees. So for many organizations, outages affecting the company’s web site, or its email or customer relationship management (CRM) service

A close friend of mine has a saying that I always remember “All roads lead through incident management”. We know that the primary goal of the incident management process is to restore normal service operations as quickly as possible and to minimize any adverse impact on business operations. This will insure the highest levels of service quality and availability are delivered to the user community, guaranteeing that the business is receiving value and facilitating the outcomes it wants to achieve. The value this process produces for the business is in the ability to: detect and resolve incidents quickly, resulting in higher availability of IT services. align IT activities to real time business priorities and dynamically allocate resources as necessary. identify potential improvements to services, through the analysis of incident trends. So it sounds like we have everything covered as long as we handle all incidents in the same consistent and proceduralized manner. Well not so fast

Our senior IT executives are being held accountable to better manage the quality and reliability of IT in business and respond to a growing number of regulatory and contractual requirements. Every enterprise needs to tailor the use of standards and practices to suit its individual requirements. Control Objectives for Information and Related Technology (COBIT) and the IT Infrastructure Library (ITIL) can both play a useful role in IT governance. Very simply COBIT helps our senior management teams to define what should be done and ITIL provides the framework for how to manage our services. When we think about COBIT and IT governance at the most fundamental level, there are four questions that every leader asks him or herself when it comes to IT initiatives: Is my IT organization doing the right things? Are we doing them the right way? Are we getting them done well? Are we getting value from our IT department? COBIT helps answer these questions by defining IT activities in a gen

During one of my recent classes a discussion came up about the difference between roles and jobs. ITIL v3 speaks to the importance of roles in performing the steps or activities of a process or procedure. A role is a set of responsibilities, Activities and authorities granted to a person or team. A Role is defined in a Process. One person or team may have multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by a single person.               -- Service Strategy Glossary This appears to be a fairly clear definition of “role”. So why do some people have difficulty identifying the proper roles to play during the execution of a process? As the recent discussion showed, it may be because of our long focus on jobs as opposed to roles. Most learners recognize a difference between the two. When asked how many “job titles” they have, the answer is inevitably that they have one job title. When asked how many roles they perform, they inevitably r

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