8/8/2019 Steps and Tips on Implementing ITIL Problem Management

http://slidepdf.com/reader/full/steps-and-tips-on-implementing-itil-problem-management 1/2

ITIL defines an "Incident" as any unplanned interruption to an IT service or reductionin the quality of an IT service and ITIL defines a "Problem" as the cause of one ormore of those incidents. The primary objectives of taking on Problem Managementare to prevent problems and resulting incidents from happening, to eliminaterecurring incidents and to minimize the impact of incidents that cannot be prevented.Problem Management is dependent on a mature Incident Management process.

Although it is possible to start early with Problem Management, this process is highlyintegrated with Incident Management. So, it is best to implement ProblemManagement after you have implemented Incident Management. You will requireincident data, impact, and frequency and incident trends to help identify relevant andworthwhile Problems to work on eventually.

It is often possible to start with Problem Management activities, without having aformally defined Problem Management process. Rather than getting bogged downwith the activities related to process design, implementation of supporting tools anddocumentation at the start of the project, consider going for quick wins. You couldstart with actions like the following:

* Identify the top 5 to 10 incidents

* If needed, provide guidance to incident management/service desk on how torecord - incidents

* Find some problems and solve them!

A key activity in Problem Management is to look for the root cause of one or moreincidents and recommend a permanent fix. Choosing the right people for the job iscrucial. Analytical people with the right technology background are best given suchroles. This need not be a permanent role. If fact, most organisation do not assign

someone to be "THE Problem Manager". Problem managers are best identified andassigned based on the problem(s) at hand. Sometimes, a task force could beappointed, instead of a single person. Besides technical skills, the assigned ProblemManager(s) would preferably have problem-solving skills and experience withtechniques like Kepner Tregoe, Pain-Value Analysis and using of Ishikawa diagramsto perform fault isolation and problem solving.

At some stage, the process would need to be designed, documented and formallyrollout throughout the organization. IT Infrastructure Library (ITIL) would provide anexcellent framework and guidance for defining the process activities and steps. Rolesand Responsibility for Problem Management needs to be formally defined and aprocess owner needs to be assigned for this process. The responsibility of theprocess owner would be to ensure that the process is documented, role and

responsibilities are clear and well communicated, people are using the process andthere is focus on continual improvement to the process. Reports and metrics have tobe defined. Examples include:

* Number of Problems and Known Errors in a period by status, service or category.

* Percentage of Problems which have been solved per category and period.

8/8/2019 Steps and Tips on Implementing ITIL Problem Management

http://slidepdf.com/reader/full/steps-and-tips-on-implementing-itil-problem-management 2/2

* Average time taken to find root cause per category.

* Average resolution time of Problems and Known Errors per category.

* Effort invested in Problems pending resolution and expected effort required forclosure per period (as measured by resolution time).

* Number of Problems that re-occur. Unlike Incident Management metrics like"percentage solved within target time",

Problem Management metrics are typically not included explicitly in Service LevelAgreements (SLAs).

Setting up a Known Error Database (KEDB) is another key activity. A Known Error isa Problem that has a documented root cause and workaround or solution. The KEDBmaintains information about problems (i.e., isolation and resolution procedures) andthe appropriate workarounds, scripts, references to patches, FAQs and resolutions.The KEDB or knowledge database must facilitate flexible retrieval of information,

preferably by keyword search.

However, the KEDB may not add much value if the Incident Management process istoo immature to efficiently use them. Many organizations have set up a KEDB system,without real success, due to the fact that the Incident Management or Service Deskstaff was too immature to help capture information and use the system to aid infirst-line diagnostics. So, setting up a KEDB system in itself is not enough. Aknowledge management mindset and culture is needed as well. Incentives andmetrics would have to be introduced to motivate the right behavior in Incident andProblem management staff.

Implement a tool to support the creation and tracking of Problem and Known Error

records should be considered. Given the close dependency between the Incident andProblem Management, integration of incident and problem management workflowand data records in the tool is important. Most commercially available tools likeBMC's Remedy or HP's Service Manager comes with separately purchasable butintegrated modules for Incident Management, Problem Management, ChangeManagement and a Configuration Management Database (CMDB) to store the systemmanagement records and also Configuration Item (CI) information.

Lastly, like any other ITIL processes, the Problem Management process should thengo through the Plan-Do-Check-Act cycles and improved and refined over time.

Jeffrey Lee is a IT Service Management (ITSM) consultant and ITIL trainer.