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