Problem Solving: Techniques. Part One

PROBLEM : A question to be considered, solved, or answered.
– Marriam-Webster Dictionary –

This is why I have decided to gather the main techniques of root cause analysis and search for optimal ways of action and to give a review as a series of articles. Part one contains two of them and shares some of my practical experience:

1. Root Cause Analysis
2. CATWOE
3. Setting Root Cause in JIRA

1. Root cause Analysis

Root Cause Analysis (RCA) is a method of problem solving through identifying the root cause of the problem, analyzing it and drawing up a plan for resolving it. If the problem persists, the true root cause has not been found.

In reality, it may be difficult to distinguish between symptoms and the cause. For example, if you sprain your shoulder, you are bound to feel pain. Painkillers will only relieve the symptoms, while full recovery will require dedicated treatment.

Root cause analysis is aimed at identification of the root cause of the problem and uses a certain set of steps and tools:

1. To identify what has happened

2. To identify why it has happened

3. To find out what must be done to prevent it from happening again

We must keep in mind that systems and events are interconnected. If Joe has forgotten to check authorization before the release, Joe is very likely to go red in the face. When tracking the events in the chain, you will find out where exactly the problem occurred and how it transformed into the symptom that you keep fighting with a lot of effort but not much success.

Most often you will face the following three main factors:

1. Physical factor – material, tangible failures (for example, the term of a domain rent has expired)

2. Human factor – a person has made a mistake or failed to prevent it (for example, nobody has paid for the domain rent)

3. Organizational factor – the system or process used for making decisions and implementing tasks are faulty (for example, no one has been appointed responsible for paying the domain rent)

Root cause analysis teaches to turn to all three types of factors to analyze all aspects of negative influence, find underlying drawbacks of the system and work out steps for the best solution. This is why you will often get more than one root cause.

Process

RCA includes 5 consecutive steps:

Step 1: Identify the problem

• What has happened?
• How the problem manifests itself?

Step 2: Gather information

• Does the problem really exist?
• How long has the problem existed?
• What does the problem affect?

Before passing on to the next steps, it is necessary to study the situation thoroughly. The effort spent by the team on solving the problem might turn out more costly for the project than the problem itself. Efficiency of RCA may be increased by involving only those team members who are most familiar with the problem. There is no point in gathering everybody, especially if the problem does not affect the majority of the team members. At this stage, a technique called «CATWOE» may prove useful (see below).

Step 3: Identify possible factors:

• What action sequence leads to the problem?
• What circumstances does it emerge in?
• Are there any other accompanying problems?

The more factors we identify, the better. Quite often we identify one or two and then settle with it. But do we want to get stuck at the most obvious factors? Let’s dig in further!

Step 4: Identify the Root cause(s)

• Why did the problem occur?
• What is the true problem?

Step 5: Suggest and implement a solution

• How can repetition of the problem be prevented?
• How will the solution be implemented?
• Who will be responsible for it?
• What are the risks?

It is most important to be able to foresee what effect the solution will take. This way, we might prevent a fault or minimize the negative effect. A few techniques to analyze risks and identify the possible pitfalls of a solution will be described in the next article. And remember: the better you analyze the risks, the less you will need RCA.

2. CATWOE

This is a useful technique of gathering information about a problem. It can be used in the process of RCA. Its main principle is to break down the problem into different areas of influence. The abbreviation itself identifies these areas, namely, people, processes and environment.

Areas of application: moderately complex and complex problems

Customers – Who are they and how will the problem affect them?

Actors – Who is involved in the problem, who will be involved in implementing the solution and what will influence their success?

Transformation Process – What processes or systems does the problem affect?

World View – What is the big picture? Are there more global impacts of the problem?

Owner – Who owns the process or situation? What role will they play in the solution?

Environmental Constraints – Are there any constraints that will impact the success of the solution?

This checklist of six elements uncovers new perspectives, helps study the problem from the inside, and provides a more comprehensive output. And the main thing, it helps establish the complexity of the problem at the stage, which precedes active involvement of other team members.

3. Setting of Root Cause in JIRA

Our project had a task of tracking the root cause of bugs. We created a corresponding custom field in JIRA, filled it with variants and set the required display screen. The field was made mandatory to prevent developers from forgetting to enter causes. However, there was an issue: if default value was ‘None’, we could not even create a bug. The system required to fill the Root Cause, although this field was still absent physically at this stage. Selecting another default value would bring us back to the initial problem: the field is filled at the stage of creating a bug, which means there is high risk that it will remain untouched during the whole ticket lifecycle.

The problem was solved with the help of a totally free add-on Workflow Enhancer for JIRA. We used it to make Root cause field mandatory to fill at the step that we required. In contrast to the standard field settings, it operates the workflow settings. First of all, you will need the rights of Jira administrator.

1. Go to section -> Workflow. Click Edit opposite the Bug flow used on the project. It will open the diagram/lifecycle list of the bug-report. Define the step at which you want to make the Root cause field mandatory. In our case it was transition from ‘In progress’ to ‘Ready for deploy.’

Make sure that the workflow you are editing does not affect other Issue Types. If it does, your validator will relate to them too. You can check the used issue types in Workflow schemes section.

2. Choose Validators in the popup that opens, and click Add validator on the next screen. Add a validator with a boolean expression. In our case – set checking for the empty field. That is, if at the stage of bug-report transition from ‘In progress’ to ‘Ready for deploy,’ the Root cause field has no value, the transition will not happen and the user will see the message you have set.

Proceed to Problem Solving: Techniques. Part Two.

• #Software Product Development