1. Is the outcome good or bad?
2. Who is responsible for the outcome?
3. If the outcome is bad, is the Responsible Party incapable and/or is the design bad?

If you keep those big questions in mind and anchor back to them, you should do well. What follows is a guide for getting the answers to these big-picture questions, mostly using a series of simple either/or questions to help you get to the synthesis you are looking for at each step. You should think of these as the answers you need before moving to the next step, leading all the way to the final diagnosis.

You can, but don't need to, follow these questions or this format exactly. Depending on your circumstances, you may be able to move through these questions quickly or you may need to ask some different, more granular questions.

Is the outcome good or bad? And who is responsible for the outcome? If you can't quickly get in sync that the outcome was bad and who specifically was responsible, you're probably already headed for the weeds (in other words, into a discussion of tiny, irrelevant details).

If the outcome is bad, is the RP incapable and/or is the design bad? The goal is to come to this synthesis, though to get there you may need to examine how the

How should the machine have worked? You may have a mental map of who should have done what, or you may need to fill it in using other people's mental maps. In any case, you need to learn who was responsible for doing what and what the principles say about how things should've gone. Keep it simple! At this stage, a common pitfall is to delve into a granular examination of procedural details rather than stay at the level of the machine (the level of who was responsible for doing what). You should be able to crystallize your mental map in just a few statements, each connected to a specific person. If you are delving into details here, you are probably off track. Once you've established the mental map the key question is:

Did the machine work as it should have? Yes or no.

If not, what didn't go as it should have? What broke? This is called the proximate cause and this step should be easy to get to if you laid out the mental map clearly. You can do this via yes/no questions as well because it should just require referring back to the key components of your mental map and pinpointing which the RP or RPs didn't do well.

Say your mental map of how the machine should have worked has two steps: that Harry should have either 1) done his assignment on time or 2) escalated that he couldn't. All you have to do is pinpoint the two steps. 1) Did he do it on time? Yes or no. And if not, 2) did he escalate? Yes or no.

It should be this simple. But this is when the conversation often gets dragged into gobbledygook, where someone goes into a detailed explanation of "what they did." Remember: It's your job to guide the conversation toward an accurate and clear synthesis.

You also have to synthesize whether the problem was meaningful-- that is, whether a capable person would have made the same mistake given the circumstances, or whether it's symptomatic of something worth digging into. Don't focus too much on rare events or the trivial problems--nothing and no one is perfect--but be sure you are not overlooking a clue to a systemic machine problem. It's your job to make that determination.

Why didn't things go as they should have? This is where you have synthesized the root cause in order to determine whether the RP is capable or not--or whether the issue is with the design. In order to anchor back to a synthesis rather than get lost in the details you might:

• Try to tie the failure to the 5-Step Process. Which step was not done well? Everything ultimately fits into those five steps. But you may need to get more specific, so:
• Try to crystallize the failure as a specific key attribute or set of attributes. Ask yes/no questions: Did the RP not manage well? Not perceive problems well? Not execute well?
• Importantly, ask yourself this question: If X attribute is done well next time, will the bad outcome still occur? This is a good way of making sure you are logically connecting the outcome back to the case. Think of it this way: If your mechanic replaced that part in your car, would that fix it?
• If the root cause is a faulty design, don't stop there. Ask who was responsible for the faulty design and whether they are capable of designing well.

Is the root cause a pattern? (Yes or no.) Any problem can be a one-off imperfection--or it could be a symptom of a root cause that will show up repeatedly. You need to determine which it is. In other words, if Harry failed to do the assignment due to reliability:

• Does Harry have a reliability problem in general?
• If so, is reliability required for the role?
• Is Harry's failure due to training or abilities?

How should the people/machines evolve as a result? Confirm that the short-term resolution of the issue has been addressed, as needed. Determine the steps to be taken for long-term solutions and who is responsible for those steps. Specifically:

• Are there responsibilities that need to be assigned or clarified?
• Are there machine designs that need to be reworked?
• Are there people whose fit for their roles needs to be reevaluated?

For example, if you've determined that 1) it's a pattern, 2) the RP is missing an attribute that's required for the role, and 3) the attribute is missing due to the RP's ability (not their training)--then you've likely been able to determine the answer to your most important question: the person is not capable and needs to be sorted from the role.