Friday February 03, 2006

Further process loops Kepner-Tregoe have a model of human behaviour called the "Performance System" model, and we use this concept extensively in the management of the installation of the SGR Troubleshooting process (Sun branding for the Kepner-Tregoe Resolve process, KT-Resolve) in Sun. The project office is not empowered to provide consequences, and we make it our job to get management to understand that; we do provide, and get involved in the infrastructure that drives the feedback loops.

If we maintain that feedback is provided to an individual to improve their performance for the next time they see the same situation, the feedback -  to be effective - needs to be timely, accurate and targetted. We have a rule in the project office that feedback provided more than 7 elapsed days after the event is not worth either the coach completing or the engineer receiving. This drives tight loops. Most of the feedback loops are of less than 48 elapsed hours, and it's that long because we have a global organisation and any report that runs once in a 24 hour period arrives in someone's timezone while they are not at work.

The primary feedback loops we run are as described in a blog entry below. We have built a number of secondary feedback loops to begin to measure and reinforce good behaviour.

Daily Coaching Loop

Every day the coaches that are assigned a group of mentees (who are often the colleagues that they have trained) receive an invitation (and key) to assess the intent and quality of the work that is passing from their group to the next group. This could be thought of as a daily survey of the quality of work that is passing between engineers. We are assessing the quality of the documentation.

Over time we can see whether engineers are improving in the quality of their documentation or not, and can take action to provide additional coaching or support for engineers who are not reaching the required standard of internal documentation quality.

Reputation Feedback

Given that we now have "End-To-End" installation of SGRT almost everywhere in the Customer Facing organisations and in the backline support organisations, we can begin to get engineers to measure engineers by reputation. A loop recently installed (and being used as a pilot for the Betty Support Model) is asking for process usage by reputation.

Part of the main coaching loop has process coaches assessing the intent behind an escalation. The trigger for the reputation feedback loop is the closure of a case that had "Cause Unknown" set as it's intent by the process coach. This tells us that the subject of the escalation was a "Problem" (using the classic definition provided by Problem Analysis thinking) to the Escalation Generator. Given that it was a "Problem", it should have been specified using PA thinking and the process of Problem Analysis continued by the Handling engineer. On escalation closure, both the Escalation Generator and the Escalation Handler are offered a survey of how the other engineer did.

The form for the Generator and Handler, and the key for completion for the Generator and Handler.

This has been an extremely useful loop in an unexpected way - apart from providing an opportunity to build up a picture of coachable opportunities, the comments field is exposing further opportunities to work even more effectively in Sun.

Process Escape Loops

From time to time things go wrong, and to handle those situations where effective call handling goes astray we have set up a process escape loop. This loop can operate in the forward direction and the backward direction, and always involves a process expert to assess the situation and provide coaching where necessary.

Why are we doing this?

Simply put, because it's more effective to do so. Sun is striving toward providing a better quality customer experience by standardising on the troubleshooting method we use throughout the support organisation. It's less expensive to have engineers all use the same troubleshooting process than it is to have them inventing new processes every time. It's results in more consistent (think reduction in variation in terms of manufacturing or Sigma measurement) support by reducing the standard deviation on elapsed time metrics, and reduces average elapsed time metrics.

The opportunities that this offers Sun and it's customer are many, and include the possibility of reaching out to our customers who use, or are interested in using KT-Resolve. Imagine a time when customers, empowered with the same troubleshooting method as Sun, perform a clear Situation Appraisal, identify the Object with the problem and the Defect that it is seeing and have spent a few minutes gathering accurate data surrounding a problem. When they pass that info to Sun, it can be immediately routed to the most likely person to solve the problem, and if that person can't solve the problem they can continue the same troubleshooting process. This has to be cheaper for our customers, and provide a better level of service to their business.
( Feb 03 2006, 10:50:37 AM GMT ) Permalink