This entry is part of a multi-post case study.

An effective way to become better problem-solvers is to use cases, so I'll post problems that we have solved in my class so we can review them. (These are all real problems.)

Here is the case of a multinational that has problems with sourcing cables, an essential part of its products.

The first step is to define the problem and record that definition in a problem identification card (PIC).

We've talked about the theory behind PICs in a previous post, so let's see if that works in this one.

[IMAGE MISSING: 3.40-Cables-negotiation-PIC2.png]
A problem identification card summarizes the vital information about your problem

A first sign that you have a good PIC is that you can understand it just by reading it once. If you read the content of the image on the left, does it make sense? Can you understand my problem and its context?

Write your PIC so that anyone can understand your problem

In this case, we wrote the PIC so that someone that doesn't know anything about the problem, or even about our company, can understand it (we'll do this for all problems on this site).

Of course, you need to adapt that to your situation: if you're going to present your problem within the company, you'll start the context at a different point than if you're using it with someone that doesn't know the first thing about what you do.

However, it's always a good idea to write one version of your PIC so that anyone can understand it. Here is why: out of the hundreds of problems that we've solved in my class, I've never found a single one that was too complicated or too technical that it couldn't be explained clearly and concisely to any audience (of reasonably educated professionals). In fact, the best problem solvers I've met all have an ability to explain their problems to the layman in a way that anyone can help their resolution.

Conversely, I have never met a single person with an attitude of "I can't explain my problem in a non-technical way" that was a good problem solver. Ever. I'm not sure why, but I think it has to do with your ability to step back, see the big picture, and adopt a point of view that doesn't feel natural.

Use a logical flow in the context

So, the situation takes the reader to a position where he understands the general context of the problem. The situation includes all the relevant information to do that and only the relevant information. Watch out! We have a tendency to include way too much information. At the end of the situation, the reader feels like saying "so what? why are you telling me that?"

Then comes the complication. There we introduce a problem. If we're doing a good job, the reader reacts with a "oh, I see, so what should we do about it?" That leads us straight to the key question: the logical next step after the complication. It's a natural follow up. It should look obvious. But make no mistake: even though a good key question seems trivial, it is surprisingly hard to get to. So be prepared to make it an iterative process. Remember that each word counts. Be ready to write up five or ten versions before comparing them and deciding which one is the best.

Again, this is a deceitful process: when you look at a good PIC, its clearness and conciseness makes you think that the process to get there is easy, but it isn't. Be ready to sweat over it. And you absolutely have to do it right too, because then you'll be solving the wrong problem.

Complement your problem description with the scope

You'll have noticed that, in the PIC, below the key question you also have some elements to fill-out: the scope, which includes the quality criteria for your problem-resolution process, the implementation parameters, and the elements that are out-of-scope. These elements also deserve your utmost care.

The quality criteria are like second-order derivatives of your problem-solving process: they are optional actions that you can take to make the process more  effective. In our negotiation case, we can choose to involve the suppliers to help up identify what impedes finding an agreement in time; involving them isn't obligatory (surely we can find the answer by ourselves) but it might help in uncovering the answer faster and it might build a stronger relationship, which might help us when we think about how we can make the negotiations more effective.

The implementation parameters are the logistical attributes of your project: when do you plan on finishing it? How much will you invest in the resolution? Whom will you enlist?

Finally, the out-of-scope elements are valid answers to your key question that you choose not to pursue and that, therefore, won't appear in your logic tree.

Find what works for you

Effective problem-solving is part science, part art. We've looked at the scientific elements, here are some of the artsy ones. Of course you'll have to find what works for you, here is what works for me:

• 
  Work on your problem bit by bit. It's better to spend four times 1/2 hour on it over the course of a day or two than to focus for two hours straight, because it will help you step back and see the big picture.

• 
  Work on your problem at the time of day when you are the most effective. I like mornings, that's when I'm the freshest. You?

• You know the rest: enlist others (groups are smarter than individuals), take several cracks at solving your problem, be ready to change your mind, ask "so what", etc.

(We'll develop the logic tree of this example in another post.)