Johannesburg, 13 Jan 2015
Introduction to Kepner Tregoe
The Kepner-Tregoe methodology was developed to address certain types of functions we often have to fulfil on a daily basis. These functions may be problem-solving, decision-making or forward-planning.
For these, KT developed distinct processes, namely: problem analysis, decision analysis and potential problem analysis. The purpose behind each of the processes is to give its user access to the same logical thought flow whenever they carry out the said functions.
Before actually starting with any of these processes, however, there is fourth process, used to guide the user to the other three. Situation appraisal is used to gather, sort and clarify information, turn that information into actions and, finally, assign priority and responsibility.
Situation appraisal is often overlooked as the minor of the four processes, but can actually be very powerful in its ability to provide structure and order as we will see in the case study below.
The challenge
An ICT outsourcing company had recently taken on a new client. Six months into the contract, the account team was inundated with daily escalations. Users were unhappy with the level of service, SLAs were not being met, call-back logs were rapidly growing, and the client was threatening to cancel the contract. At the time, nobody could point out any one issue as the source of user dissatisfaction.
Using situation appraisal
The company was in the process of rolling out the Kepner-Tregoe Problem and Incident Management programme, and asked one of the programme leads to facilitate a session with the account team and the client.
The session was chaired by the programme lead. In attendance were the account management team, the service desk operations managers, the technical team managers as well as the IT relationship manager from the client side.
As the meeting kicked off, each person was given a chance to voice their individual concerns. Each concern and every concern was documented until everyone had no more to say. The list was long, and included technical issues such as application failures, network speed issues and access problems, as well as non-technical issues such as process failure, lack of coherence between teams and calls breaching SLAs.
In the next step, each concern was looked at to see if it related to other concerns, and was broken down to ensure that if there was more than one component, each would be addressed.
For example, two concerns:
1. SLAs are not being met
2. Calls are being assigned to the wrong technical teams
When asked to clarify these two statements, it was found both issues related to incidents and service requests.
When asked why the technical teams were failing incident and service request SLAs, the first reason given was that engineers had very little time left on the call by the time it was assigned to them, and in some cases the call had already breached the SLA. This was an indication that tickets were being assigned to the wrong teams. Further questioning highlighted the fact that an integration issue may have existed between the client and service provider service desks applications.
What was uncovered here was that the first concern had more than one component, and that the second concern was actually one of them.
After addressing each concern in this manner, priority was assigned. Finally, for each concern, an investigative or corrective action was determined and an individual was assigned to the task. Time frames were agreed upon for completion and feedback loops for each task.
Conclusion
Seen above is a typical example of what can happen when a problem-solving approach lacks structure. Problem solving becomes firefighting and there is very little tracking of any progress. Situation appraisal is designed to be very simple, yet very structured in its approach to organising any chaotic situation into structured tasks.
Share