Skip to content
SM Tutorials & Certification

Setting up a Team for Problem Management: A Case Study: Part II

In Part I of this case study we saw that a global company (XYZ), developer of a billing and customer care application for GSM services (BACC), had set up a Problem Management team to provide support services to their customers in Europe and Asia. The top management and the IT Manager had carefully selected a nine-member team to handle Problem Management as part of ITSM. In Part II of this case study we will look at the KPI’s set up for Problem Management. The KPIs were finalized in a meeting involving the entire team. The criteria used to decide on the KPIs were the following: the KPIs had to be critical to the success of XYZ’s Problem Management process and be easily measurable. After much discussion and brainstorming, five KPIs thought to be relevant to the situation at that time were set up : 1. Time taken for RCA This was the time taken for the Problem Management team to identify the root or actual cause of the problem. Since this was a very critical activity affecting the actual fix or resolution of the problem, targets or goals were set according to the category (based on severity and priority). For instance, for high priority problems the target for completing the RCA was within a timeframe of 12 hours. 2. Problem resolution time and effort This referred to the tome taken to resolve the problem or provide a fix which prevented the problem from recurring. Usually, after the RCA, the team would provide an estimate of time and effort for resolving the problem. In some cases, this could involve a Change Request and therefore the Software Development team. Customer SLA’s were taken into account when planning this resolution estimate. The goal was to adhere to these estimates and not exceed them by 5 %. 3. Problems prevented from occurring This point refers to the number of problems prevented from occurring after the RCA has been carried out for a particular problem. If you remember, all the customers of XYZ were using similar versions of BACC. Therefore it made perfect sense to inform all customers of problems arising due to coding errors or other known errors which had been identified earlier for one or more customers. The goal was to tolerate no more than 1% recurrence of known problems, or incidents centered on known problems. 4. Problems repeated (after resolution) Problems could occur again in the same environment for various reasons. For example, the RCA may not have been accurate; hence the fix based on the RCA did not resolve the problem in its entirety. There could even have been an error in the fix, or software patch or even implementation of the fix which has caused the same or a new but related problem to surface. The goal was set at 0% repeat problems, as recurrence of such problems pointed to serious lapses in Problem Management and possibly other groups such as QA or Software Development. 5. Problems ‘On Hold’ or ‘Unresolved’ Problems not resolved and not in any state of resolution at any given point of time were counted. The percentage of unresolved problems out of all the problems registered was considered to be unacceptable if it exceeded 3%. All unresolved cases at the end of the month came up for review with the aim to resolve them or close them after discussing with the customer, if necessary. In the next part of this case study, we will look at how more metrics were set up for the Problem Management activity.