In Part II of this case study we saw that a global company (XYZ), developer of a billing and customer care application for GSM services (BACC), had decided on five main KPI’s thought to be critical to the success of XYZ’s Problem Management process.
The initial and most important KPI’s that were identified for XYZ’s Problem Management in Part II of this case study are summarized below:
1. Time taken for RCA
High priority problems (Severity Level 1) meant that the team had the target of completing the RCA within a timeframe of 12 hours.
2. Problem resolution time and effort
The goal was to adhere to the estimated time and effort and not exceed estimates by more than 5 %.
3. Problems prevented from occurring
The goal was to tolerate no more than 1% recurrence of known problems, or incidents centered on known problems.
4. Problems repeated (after resolution)
The goal was set at 0% repeat problems.
5. Problems ‘On Hold’ or ‘Unresolved’
The percentage of unresolved problems out of all the problems registered was considered to be unacceptable if it exceeded 3%.
In the next part of this case study, we will look at how more metrics were set up for the Problem Management activity.
A team meeting was held after a month of operation of the new team. It was agreed by the IT Manager and the Team Leader, Problem Management, that any further metrics to be set up should be meaningful and really relevant to Problem Management. The metrics should be easily measureable and the data easy to analyze over a period of time. The five KPIs identified earlier were found to be very relevant and reflective of the efficiency or effectiveness of Problem Management for customers of BACC at XYZ.
After much brainstorming, the following additional metrics were decided upon:
1. Time taken for RCA was extended as a metric for all severity (1 to 4) of issues, and goals were set in the range of 12 hours to 7 days, based on severity.
2. Effort saved by preventing problems from occurring.
This is related to the third KPI set in Part II of this case study. When known problems (that is, those that have already occurred in at least one customer’s environment) are prevented from occurring by proactively offering a work-around, resolution or software patch to the customer, the estimated effort saved in customer handling, problem resolution, and related activities were to be quantified as effort in man-days. It was felt that data analysis of this measurement would bring out the performance level of Problem Management and show that “prevention is better than cure”. The goodwill thus generated in customer relationships, however, was not quantified.
3. Number of problems related to bugs in software development or design deficiencies. This was thought to be important as XYZ’s team was the developer of the BACC application and needed to keep track of improvement opportunities related to the software development process.
It was decided to collect and record the data meticulously and analyze the findings on a monthly basis to decide on further action to be taken.
In Part IV of this case study, we will look at working according to customer SLA’s.