I have been asked by many students, how do you move from that role as the fire fighter resolving incidents to the role of being able to prevent them from occurring in the first place? Much of this has to do with good design and a strong proactive problem management process, but a solid event management process is an excellent offensive weapon in the prevention of impacting incidents in your environment. Event Management is the process that gives IT the ability to detect events, make sense of them and determine the appropriate control action. It is the basis for our operational monitoring and control. This gives us a way to compare actual performance against what was designed and written in SLAs. What is perfect about event management is that we can apply it to any aspect of our environment from delivery of a service, monitoring an individual CI, environmental conditions to software license usage. In conjunction with the other Service Management processes, along with both passive an

In order for IT organizations to be successful, we must align ourselves with our business partners. Business and customer requirements must drive service and process continual improvement activities. As a service provider, we must ask ourselves if we really understand our customer’s needs and expectations. When was the last time we checked with our business to determime if we are delivering value? When was the last time you asked the business, “How are we doing”? One of the gathering techniques we learn in the Certified Process Design Engineering (CPDE) course is how to conduct a needs assessment. Here are the steps for conducting a successful assessment: 2 to 4 weeks prior to the assessment: Establish a high-level interview schedule Identify interview participants Develop a detailed interview schedule Contact each participant to determine availability Develop a list of interview questions/solicit feedback Refine your list of interview questions  1 to 2 weeks prior to the ass

I often get asked what goes into a Process Definition Document (PDD).  Certified Process Design Engineers (CPDE) learn that PDDs should  include: Policies A process overview Roles and Responsibilities Process Maps Activities Vocabulary Policies Policies specific to a process should be included in the Process Definition Document.  A policy is a formal document that describes the overall intentions and direction of a service provider, as expressed by senior management. Company policies are used to guide actions toward a specific outcome. They must be specific, measurable and underpinned by the process.  Overview The overview section contains the process description, objectives, goals, owner boundaries, triggers, supplier data, inputs, high level activities, outputs, customers and metrics. Roles and Responsibilities Roles and responsibilities define and describe the active participants in the process, including the process owner, process manager, suppliers, customers and sta

I was asked recently how Certified Process Design Engineer® (CPDE) and Six Sigma might work together. I was also asked to clarify the value of holding a Certified Process Design Engineer® certification. To deal with these questions we must first clarify the difference between CPDE® and Six Sigma. First CPDE® is a role and a set of methods and approaches for that role to use in defining, designing and implementing strong IT Service Management processes. Six Sigma is a quality framework based on the work of men like W. Edwards Deming, Joseph Juran and Philip Crosby (the Big Three of the quality movement) and developed out of Motorola’s efforts to improve quality. The two are not at odds, rather they complement each other. A CPDE has the skills to look at an organization, understand its culture, its approach to process and quality and its need for improvement. Once this assessment is done (using tools like the ITIL Process Maturity Framework, or CMMI) the CPDE would identify which el

I recently attended a great opportunity to connect, learn and grow at the itSMF USA Fusion 10 Conference in Louisville, Kentucky. It was a wonderful chance to see old friends and acquaintances, to meet and make new friends and learn from some of the most articulate and impressive speakers on ITSM and ITIL available in the industry. I came away with some key points that I thought I would share with you so you can also gain the benefit and value of the data, information, knowledge and wisdom presented at the Conference. Here are my key take0aways: Service Management is alive and well. A new wave of users and supporters has emerged and were present at the show. I saw and met so many new people. I was impressed that ITSM and ITIL has not simply remained in the hands of a core group of users but has found continued life among new industries and implementers. ITSM and ITIL seem to be growing especially among colleges and university IT departments and in the medical and scientif

Not too long ago, I was involved in a post implementation meeting for a change that was not very successful. During the meeting there was a very heated discussion, some of the comments I heard were:  ‘I thought you were going to do that’ ‘That is not my responsibility” ‘Why wasn’t I informed that this was occurring’ 'I have the responsibility, but not the authority to get the job done' ‘I knew how to fix the issue, but no one ever asked me’   It occurred to me that having a RACI chart would address these comments. The RACI model is a straight forward tool used for identifying activities and relating them to roles and responsibilities, thus avoiding confusion over who does what and how people are involved. The acronym RACI stands for:  Responsible : This role is responsible for the correct execution of process and activities. This person or persons do the work to achieve the task. Accountable : This role has ownership of the quality and the end result o

Trends such as virtualization, cloud computing, and agile development have all prompted the need for leaner, more efficient, and more highly automated ITSM processes. Probably one of the things that is most misunderstood about ITIL is that it is a highly scalable framework. Organizations need to understand that if their processes are bureaucratic, it’s most likely because they have made them that way. So in the spirit of continual improvement, what’s an organization to do… throw out ITIL and start over? That’s what the DevOps folks would have you think. If you haven’t heard of DevOps, according to Wikipedia the term refers to the emerging understanding of the interdependence of development and operations in meeting a business' goal to produce timely software products and services. DevOps has been referred to as (1) a movement, (2) an approach, and one blogger went so far so refer to it as (3) a “framework of ideas and principles designed to foster cooperation, learning and coo

What is strategic thinking? This question often crosses my mind and those of my students, especially when I am teaching the ITIL Lifecycle classes. Just as often as the question arises, a variety of answers are put forth as well. One definition of strategic thinking holds that “the role of strategic thinking is ‘to seek innovation and imagine new and very different futures that may lead the company to redefine its core strategies and even its industry’ ". This implies that the definition and use of strategic thinking are related but different from strategic planning—putting into action or executing the ideas developed using strategic thinking. Strategic thinking is just that—postulating or thinking about what the future holds and what the future looks like. Strategic planning is action based. A good organization recognizes they need both. As a Professor who attempts to provide learners with theory-driven practical data, information, knowledge and wisdom, I particularly like th

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

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

The Professor has been asked, “Does ITIL address Technology Lifecycle management?” In version 2 of ITIL, the ICT Infrastructure Management book focused on technology management.  This is still a good resource, although availability of the publication may now be very limited.   In Version 3, the same information is spread across the lifecycle - most heavily in Service Design, Service Transition and Service Operation.  There are a couple of updates in ITIL Version 3 for technology management.   Configuration Management is now "Service Asset and Configuration Management" so that Asset Management and Configuration Management are integrated.   Service Design now defines a Technical Service Catalog to acknowledge underpinning technical services that are critical elements of business services.  ITIL also includes a Technical Management function as the custodian of technical expertise. While the Technical Management function performs most of it's work in Service Operation, it

In a previous Blog I spoke to Application Management from the point of view that they do not actually develop the application but manage it throughout its entire lifecycle. This is done through the Application Management Lifecycle along with Operational Models. Operational Models are the specifications of the operational environment in which the application will run after it has been deployed. This model is used to simulate and evaluate the live environment during the Design and Transition stages. It also ensures that proper environmental requirements and sizing can be documented and understood by all groups or teams involved with application development and management. Many of you are familiar with “Software Lifecycle (SLC) and “Software Development Lifecycle” (SDLC). These are use by application development and project teams to manage the designing, building, testing, deployment and support of applications. From an ITIL perspective the Application Management Lifecycle looks at the

When I teach ITIL V3 Foundation classes I often have to make the distinction between Application Management which is one of the “Service Operation Functions” and Application Development. I often begin my discussion by explaining that Application Development is responsible for the actual development and building of applications by the developers. Application Management is responsible for managing applications throughout their lifecycle and is performed by any department, group or team that is involved in managing and supporting operational applications. Additionally the function also plays a role in the design, testing and improvement of applications that form part of IT services. Application Management plays a key role in all applications whether purchased from a third party manufacturer or developed by in-house staff. During the design stage of the ITIL Lifecycle one of the key decisions made by Application Development is whether to buy or build. After that decision is made Applic

I have often been asked what value does the Service Acceptance Criteria (SAC) provide? First let’s understand what the SAC is by definition. 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. We 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, we must ensure that the contents of the Service Acceptance Criteria are incorporated and the required achievements are planned into the initial design. The Service Acceptance Criteria is the document that will ensu