Skip to main content

Posts

Showing posts from 2010

Process Maturity Assessments

I recently gave a workshop outlining the basic ideas and steps needed to design and implement ITSM processes. During the workshop we discussed the importance of knowing the maturity level of your processes. You determine the maturity of your processes by conducting a maturity assessment. Using a maturity assessment model will allow you to know where your processes currently reside in terms of usability, effectiveness, efficiency and economy. You can also determine what level of maturity you want your processes to achieve as a future state. Finally a maturity assessment will show you what steps you need to take to close the gap between your “as is” process and your “to be” future state. There are three maturity assessment models you might think about using. Capability Maturity Model Integration (CMMI), ISO/IEC 15504 and the ITIL Process Maturity Framework (PMF). All three use a multi-level approach to identify the maturity of your processes. Each also uses a set of assessment criteria

Knowledge Management and Social Networking

I was recently asked a very thought provoking question about the importance of social networking to knowledge management? Social networking is having a wide and varied impact on ITSM as a whole. As with all new and emerging technologies,  organizations must develop strategies on how social networking will be incorporated into their environment. Policies must be established that define what will and will not be allowed in the corporate arena. Within the knowledge management process,  many organizations are embracing the use of social networking technologies but doing so with caution. Once knowledge is posted on the web, it can take on a life of it’s own. There must be internal security policies that insure that proprietry knowledge does not become available to the public. These policies should address the appropriate use of the technology as well as appropriate staff behavior.  Policies and procedures should also be defined for filtering, validating and controlling any knowledge tha

Event Management Reactive to Proactive

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

Conducting a Needs Assessment

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

The Components of a Process

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

CPDE and Six Sigma

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

ITSM Learnings from Fusion 2010

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

Why Use a RACI Matrix?

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

The Need for Speed

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

Strategic Thinking

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

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

Application Cost Models

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

Problem Management Techniques

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

Examples of Major Incident Criteria

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

Dealing with Major Incidents

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

Demystifying Cobit and ITIL

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

Roles vs. Jobs

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

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

ITIL Technology Lifecycle Management

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

Application Management Lifecycle

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

Application Management

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

Service Acceptance Criteria

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 en

Applying the CSI Model to Teenagers

I had a recent chat with a coworker of mine that used the CSI Model at home in a funny yet very practical way. I have her permission to use this and I hope you find this as interesting as I have. In her own words…. “In addition, to my career responsibilities I have the honor and for the most part the pleasure of being a Mom to two teenage girls. As we all have experienced in life, our work demands sometimes spill over into our home life. On occasion, I have been accused by my girls that I am NOT their boss, and to leave my work demeanor at the front door. Being so entrenched in striving for continual improvement, I figured, this model works at the office, why not see if I can improve things at home? I know – this has trouble written all over it! The CSI Approach – Using the CSI Model Step 1 - What is the vision? (Define your vision, your goals, your objectives) My vision is that my 17 year old high school junior has straight A’s on her report card for the third marking period –

Effective Brainstorming Session

There are several problem analysis techniques which are discussed in the V3 Service Operation book, including brainstorming. I have used brainstorming sessions often in my career. Brainstorming is used throughout the problem solving process whenever the team needs to generate ideas quickly and effectively. Some sessions have been very valuable, others not so much. What was the difference? Basically, we need some structure around the sessions and some rules of engagement. Let’s begin by defining brainstorming. This is a technique used to quickly generate a list of ideas by a team to solve problems or issues. The relevant people must be gathered together either physically and/or electronically to increase creativity and idea generation in a very short amount of time. Here are 3 different types of brainstorming methods:  Free Wheeling Brainstorming Participants call out their ideas when they occur to them and in no particular order. A recorder posts all ideas for everyone to see as

The ITIL Application Management Lifecycle and SDLC

I often get questions on the differences and similarities between the Software Development Lifecycle (SDLC) and the ITIL Application Management Lifecycle. Is the ITIL framework just another rebranding of SDLC? SDLC defines the organization’s standards for the creation and maintenance of applications. The SDLC can be divided into ten phases during which defined IT work products are created or modified. The phases range from initiation, design, development, implementation, operations & maintenance to disposition. The tenth phase, disposition, occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The ITIL Application Management Lifecycle presents a more holistic, service oriented view. It allows for greater alignment between the development view of the applications and the live management of those applications. This ITIL lifecycle focuses on the overall management of applications as part of IT services. Understanding the c

Change Categorization

Rusty asked: I was looking for terms used for categorizing the impact of a change, I remember in Version 2 of ITIL that changes where categorized as Major, Significant, Minor and Standard is that no longer done? Or is the Imapct also defines as the priority High, Medium, and Low Rusty, I’m going to give you my answer in three parts. This information can also be found in Section 4.2 of your Service Transition Book.   In ITIL V3 changes are now categorized into three distinct types:   • Standard Change: Change to a service or infrastructure for which the approach has been pre-authorized by Change management that has an accepted and established procedure to provide a specific change requirement. It has a defined trigger, documented tasks and budgetary approval. The risk is low and well understood. • Normal Change: Change to a service or infrastructure for which the risk must be assessed and must go through the Change Advisory Board (CAB). These are Changes that happen either on

Organizational Change Management

One of the most important yet often less fully considered aspects of using Service Management is Organizational Change Management. When it comes down to it, Service Management is about people—as customers, users, providers, maintainers, supporters and a myriad of other roles. So while we get caught up in getting effective, efficient and economical services, processes and technologies in place to provide value, we must not push aside the importance of attitude, behavior and culture. We have all encountered new situations, changes in process or work flow, new technologies and other unfamiliar situations. Most people recognized from experience that different people deal with change in different manners. But we do not have to rely simply on hearsay or belief or personal experience. We can turn to experts in the field of Organizational Change Management for a way to work through the adoption of new ideas, approaches and technologies. In 1962 in his work Diffusion of Innovations, Everett

Service Requests and Standard Changes

Paul recently asked; Hello, When browsing on the topic of Service Requests, I visited your site where a question was answered on the differences and similarities of Service Requests and Standard Changes. I was triggered by the following passage: "It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk changes that are not "requestable" by the user. Any Service Request or Standard Change that presents a higher risk may require reassessment and reclassification by Change Management." I am trying to think of a term that would differentiate the one from the other. Considering that there are Service Requests that may invoke a Standard Change, I can see two possibilities: it may be a Standard Change that can be requested by any end-user or it ma

Use CSI to Meet Changing Customer Needs

You can’t always go home again, but you can use Continual Service Improvement (CSI) to meet the changing needs of your customers. I recently posted a blog about returning to a service desk I had managed and spoke about how the changing business environment had impacted management’s ability to sustain the current list of Critical success factors (CSFs) and Key Performance indicators (KPIs). The 1st question that was asked was “What should we measure?” Within the new business reality we reviewed how the corporate vision, mission, goals and objectives had changed? We spoke with service owners, business process owners, business analysts and customers and asked what was critical to them. What services that we were providing was creating the most value to them and enabling them to meet these new goals and objectives? Management then identified the gaps of “what we should measure”, to “what we can measure”. From this a more customer focused list was developed. The overriding objective

Simplifying Service Management

One of the things that troubles me at times is how often people try to make the world more complex than it needs to be. The world is really a rather simple place if you take the time to step back and avoid complexity. I recently read a statement that made think upon this problem again. The opposite of “simple” is “elaborate”, not “complex”— Dan Roam, The Back of the Napkin What people call complex, may in reality be elaborate. They confuse the two ideas. This can lead to issues in the delivery of Business and IT Services to customers. If someone believes a service is too complex they can often be less willing to make the effort to provide the service, or support it or improve it. Most likely the service is just elaborate (having lots of underpinning elements and components), not really complex (being of a nature that is difficult to understand). So how do we move away from complexity and towards seeing Service Management in terms of simplicity and elaboration? Here are several tech