Process Assessment Using a DIY Approach – Potential Resources

Conducting an ITSM process assessment can be both important and beneficial. The assessment exercise is important because it can provide the baseline information needed in order to improve the processes that were assessed. The improvement in the efficiency and effectiveness gained usually leads to better IT services, which is always a benefit for our customers. Conducting a process assessment is also not a trivial exercise. It takes a good deal of planning and preparation upfront before the first survey goes out to the stakeholders.

A number of organizations utilize the help of external consultants to perform the assessment. A number of organizations also would like to roll their own assessment exercises. This post will go into some suggested resources if you are thinking about performing a self-assessment on your ITSM processes today. Consider the following…

One or more of the core ITIL documents: Since we are talking about assessing ITSM processes, the ITIL documentation seems to be the most logical baseline material to have. Get the entire set of five manuals, preferably the 2011 update edition, from Best Practice Management or another source. There have been a number of books written on ITIL, and they do provide good information. Have the official ITIL manuals handy nevertheless.

A Process Maturity Model: For each process you assess, you will need to be able to assign a numeric rating that denotes the maturity level of the process. I would suggest adopting either the approach of Capability Maturity Model Integration (CMMI) for Service or ISO/IEC 15504. Both CMMI and ISO/IEC 15504 have a numeric ranking system of 0-5 to measure the process maturity level. The ways both standards label the maturity levels are also very similar. However, there is a cost consideration involved. CMMI can be downloaded free from Software Engineering Institute while ISO/IEC 15504 documents need to be purchased from ISO. If you have access to ISO/IEC 15504 at your organization, go for it. If not, download and use CMMI from SEI. At the end of the day, I believe either maturity model definition will do just fine for DIY assessments.

In addition to the maturity levels, you will need a list of best practices or control objectives for each process. The best practices or control objectives contain the finer details that show what a mature process will look like. Take the Problem Management (PM) process for example; a mature PM process should have something like…

  1. A procedure to identify, record, classify, and track problems
  2. A procedure to perform root cause analysis and closure for a problem
  3. A mandate where problems require changes in configuration items for resolution must be handled via the Change Management process
  4. A setup for Known Errors repository when root cause has been identified but the problem cannot be fully resolved for some legitimate reasons
  5. A procedure to monitor and measure the effectiveness of the PM process
  6. A well-defined set of interfacing procedures or protocols between PM and other related processes such as Incident, Service Request, and Change Management

To come up with a list of best practices or control objectives, I can suggest researching, distilling and integrating information from the following sources…

  1. The ITIL Core Documentation.
  2. COBIT 4.1: For our PM example, Process DS10 (Manage problems) has the control objectives which can be used for accessing the PM process. COBIT also contains a number of control objectives that can be mapped to other ITIL processes as well. COBIT can be downloaded from ISACA (registration required).
  3. CMMI Version 1.3 for Service: The section “Incident Resolution and Prevention” on page 171 contains some worth-a-while ideas and what a maturity level 3 will look like for Problem Management. CMMI for Service can be downloaded from SEI.
  4. ISO/IEC 20000-1 and 20000-2: ISO 20K and ITIL v3 share a number of similarities. For example, section 8.2 of ISO 20000 deals specifically with Problem Management and spelled out details on what constitutes compliance with the ISO standard. I would suggest purchasing the two ISO 20000 documents, with the latest updates from 2011 and 2012 if possible. ISO/IEC standards can be purchased from ISO or ANSI.

Combining the four documents between ITIL, COBIT, CMMI, and ISO 20000, you should be able to come up with a list of assessment criteria for a particular process. Coming up with a list of assessment criteria is probably one of the most time-consuming exercise of the process assessment. There is where the external consulting can help or come into the picture. The external consultants will likely already have those assessment criteria on hand and ready to go. Since we are talking about the DIY approach, coming up with a robust list of assessment criteria will be well worth the time to do it the very first time. After the one-time start-up effort, the assessment criteria can be fine-tuned and used over and over again for the subsequent assessments.

Other Supplementary Materials: I suggest obtaining the following documents because they contain valuable information that can help you immensely as you sort through various documents to formulate your assessment model.

  1. Aligning COBIT® 4.1, ITIL® V3 and ISO/IEC 27002 for Business Benefit: This document provides a detailed mapping of COBIT 4.1 processes to ITIL V3 and vice-versa.
  2. COBIT Mapping: Mapping of ISO/IEC 20000 With COBIT 4.1: Another helpful mapping document but available to ISACA member only. Non-ISACA members can also purchase the e-book from ISACA.

With COBIT 5’s planned release in April 2012, we will see some changes in how COBIT presents the process assessment and control objective information. If you need to start planning the process assessment effort for your organization, there is no need to wait for COBIT 5 in my opinion. Between ITIL V3, COBIT 4.1, CMMI Version 1.3, and ISO 20000, you have more than enough pieces to put together your own maturity assessment model picture. In the future posts, we will go into more assessment how-to’s such as surveying the stakeholders, analyzing the results, and presenting the findings.

Event Management Process Design – Part One

This post is the first part of a series where we discuss the Event Management process and how to put one together. Accordingly to ITIL (quoted directly), Event Management is the process that monitor all events that occur through the IT infrastructure to allow for normal operation and also to detect and escalate exceptional conditions. Another word, Event Management picks up the alerts and events generated from the devices and applications, figure out what to do with those alerts and events, and follow up afterward to make sure the alerts and events get the due attention and addressed properly. To begin putting together an Event Management process for your organization, here are some elements to think about.

  1. What events and alerts do you plan to trap and process? It may be a noble goal to design a process that can trap 100% of the alerts from the environment and process them all. It is not always possible. Some events can be trapped and processed automatically by the tools you have on hand, and some alerts will require manual intervention. Where will the alerts/events be captured from and where they will be recorded? ITIL suggested centralizing the event management process as much as possible, and it makes sense. If the alerts need to come from different technology stacks or devices, which they often do, can you at least centralize the location where the recording and processing activities can take place? Determine the scope, what you can do or cannot do, and have a clear idea of what you hope to get out of the process.
  2. Once you determine the set of events or alerts that can be picked up and fed through the process, you will need a set of rules on what to do with those events. The rules need to be explicit so there is little room for guessing or personal interpretation by those carrying out the process. The rules will determine what conditions, after being met or exceeded with some thresholds, will trigger an event. For example, you may have a rule that says when server ABC’s CPU utilization reaches 90% and stay there consistently for over 10 minutes during business hours (6am to 6pm), an alert will be triggered. The rule will further stipulate what actions will be taken when the event is triggered. For example, you may have a rule that says the CPU alert will be escalated or handed over to the systems admin team for further evaluation via email or phone call. The rule will also call out what acknowledgement or interaction will constitute a successful escalation or hand-off.
  3. You should have a classification scheme for the incoming alerts/events. Not all alerts require the same handling actions. Using ITIL’s suggestion of having alerts that can be either Informational, Warning, and Exception is a good starting point and more than sufficient for most organizations anyway. For example, informational alerts usually get recorded for historical purposes and not escalated anywhere else, only the warning and exception get escalated further. Between the warning and exception alerts, they may get escalated differently to different teams with different timing considerations. Furthermore, once the alert is escalated, the job of Event Management is not 100% done. We also need to have a standard rule or approach on how to follow up while the alert condition is being addressed and to close out the alerts once certain conditions are met (incident resolved or alerts cease to repeat within a 24 or 48 time frame).
  4. As you can see, determining what to do with an alert, making sure the alerts are handled correctly and efficiently, and following up to close the alerts properly take some up-front thoughts and planning. The number of alerts monitored in a moderately complex IT environment can grow very quickly. Therefore, having heavily customized, individual alerts is not recommended, and really not necessary. My suggestion is to have a default event handling procedure that will work for over 90-95% of the events you anticipate to process. For the remaining 5-10%, use the default handling procedure as the foundation but with some customized procedure on top so the events can be handled correctly.
  5. Who will be on point as the process owner for and responsible for carrying out the Event Management process? If you are lucky enough where you can have a team in your organization whose primary responsibility is to monitor the environment and process the events, that team can be both accountable as the process owner and responsible for doing it. If a dedicated team is not an option and multiple people/teams will be carrying out the process, at least designate one, single process owner and have a consistent process in place for everyone else to follow.
  6. How will the process be measured for efficiency and effectiveness? What measurements does your organization care about? What actions will result from analyzing the measurement data? Measurements will mean very little if they are not acted upon to further improve the performance of the process.

Those are a lot to think about for now. In part two, I will provide a sample list of Event Management process design requirements and a sample process flow for further discussion.

Links to other posts of the series