Mostly Harmless

SGRT meets The Reluctant Surgeon

As promised, I attempt to shine the beneficent light of an analytical troubleshooting method into the dark recesses of the pesky Reluctant Surgeon problem.

The method in question is Sun Global Resolution Troubleshooting which is Sun Microsystems' implementation of Kepner-Tregoe's Resolve product. I will not give an exhaustive account but just show ways in which conscientious application of the method might uncover the concealed sticking point in the problem.

I was prompted to do this by the following question:

SGRT reminds you to list your assumptions but how can I list an assumption of which I am not conscious?

I can think of three ways in which SGRT might offer the key of this problem to a trouble shooter. Approaches 1 and 2 use the following problem statement.

Problem Statement

SGRT encourages us to frame a problem statement in terms of a divergence from what "should" pertain. The "should" here is that the surgeon should operate. The surgeon is not operating and we need to find out why.

First Key - Trivial

SGRT generates a set of questions which are used to establish precise details of what the problem IS and what it could be but IS NOT. (More about this later.) The answers to these questions are then used to ask more speculative questions to determine differences between the IS and IS NOT cases.

Having established initially that this particular surgeon won't operate but another one might, SGRT would lead us to ask a question like What is different or unusual about this reluctant surgeon?" to the person posing the problem. An honest answer in the UK would have to supply the information that the surgeon is a woman because, in the UK, only 6% of consultant surgeons are - so it is unusual. If the "IS NOT" surgeon was a male (likely) then the sex of the reluctant surgeon would count as a difference. Of course, in a real problem situation the person reporting the problem may ignore differences that they consider irrelevant, but this is why SGRT encourages us to "Question to the void" saying (repeatedly) What else is different or unusual about this surgeon? until even the most banal answers have been given.

However, this method is inadmissible for our problem because we are not allowed to ask questions. We can only suggest solutions. This situation is not uncommon in the real world. A customer might not be able to interrupt his production to provide more data, or we may be foolishly working on a problem while key people are unavailable (i.e. burning the candle at both ends).

So we have to suggest our own answers, and this too offers a key.

Second Key - Requires devotion

The first of the "IS" questions establishes in what object the problem resides. Answer "The surgeon" because "The surgeon IS reluctant". We then move to the "IS NOT" side of the same question:

What other surgeon could be reluctant but IS NOT?

Here is where we need to be conscientious. It is easy to fill in the blank here and simply answer "Some other surgeon". If this were an IT problem with an SFW series 1000+8i then this would be like answering "some other computer" or "my laptop". The idea is to find something as similar as possible to the problem object which nevertheless does not exhibit the problem. e.g: "Another SFW series 1000+8i in the same room" or "An SFW series 1000+4i".

In our case this makes us analyse the idea of kinship. We may think the surgeon is a deluded man. Perhaps he knows the boy slightly and is lying because he doesn't want to operate. Perhaps his use of the word "Son" is aspirational. We must put all that aside and simply list the surgeons who legitimately could and could not operate. If we are conscientious our table will have a "cannot operate" column including the word "mother".

Third Key - Shift of focus

It's irritating. We are not allowed to ask questions but the room is full of grinning idiots who know the answer and tell us it's easy. So that suggests a new problem statement.

I cannot understand the Reluctant Surgeon Problem

If we repeat the analysis with this problem statement then we will certainly start analysing our assumptions because the problem is now seen to be inside our own head. Because we have redefined the problem statement we can now start asking and answering questions about our mental model of the problem. We might be lucky and trip over our fatal assumption while listing all the assumptions we know we have made.

For instance, we might look at what elements are missing from our model (since it is we who are missing something); the other driver in the crash, the other medical staff, the other relatives (presumably telephoned) of the boy...

This list will also throw up the key insight that this is not a problem with a surgeon but a problem with inconsistency. It is a "someone must be lying" problem when we know they are not. The IT equivalent might be a silent data corruption problem where the entire datapath is protected by ECC logic. The hidden assumption is that data is being corrupted somewhere (because that's what it looked like when the problem statement was drawn up); the actual cause is that the application at one end of the path was built with later header files than the application at the other end. Addressing the inconsistency is key.

In the surgeon problem, focusing on the inconsistency causes us to give equal weight to the man driving the car as to the surgeon. After all - the fact that he is the boy's father is equally as problematic as the fact that the surgeon claims to be. "Someone must be lying".

If we ask the question "Who else might have driven the boy to the match but did not?" we are even more likely to think of the mother than if we ask it of the surgeon.

All in all the conclusion seems to be that an analytical troubleshooting method is only as good as the degree to which you follow it conscientiously. It is not just about filling in a template but about evaluating what you know and seeing what parts of it are wanting, and looking critically at whether what you know really justifies the current problem statement.

Posted at 12:36AM Dec 09, 2006 by John Alderson in Problem Solving  |  Comments[0]