Problem-Focused Approach

A problem-focused approach to problem solving is self-defined and focuses on the problem. The person trying to solve the problem focuses on the problem by determining the root cause of the problem. Attempts are made to remove the problem by removing its root cause. It is not unusual to for corporate managers to struggle with issues in a complex IT environment when the solution to the problem is decided to lie within the organisation‘s ability to break the problem down into compartments, solving each sub-problem before solving the entire problem (Coppola, 1997). The use of problem-focused problem solving focuses on the problem while working to remove the problem. In a qualitative study (N = 18) in which researchers asked broad questions during telephone interviews, one conclusion drawn was that a requirement of effective problem solving is to realise that each situation is unique and that corrective actions should be aligned to the given situation (Armenakis et al., 2007).

A problem-focused approach to problem solving dominates the problem solving literature.

Volkema (2006) suggests that problem-focused problem solving provides adequate solutions whether people are intimately affected by the problem, have little stake it the outcome, or are simply interested in it. Finding a way to fix the problem begins with the diagnosis of the problem, defined as the identification of all components as either failing or not failing to explain the symptoms observed (de Kleer, Mackworth & Reiter, 1990).

Problem solving, as commonly taught, is analytical or procedural, employing almost exclusively the left hemisphere of the brain. A problem-focused approach requires specific, quantitative data about the entire problem and the environment in which it occurred. In a longitudinal study performed in the 1990‘s, Lumsdaine and Lumsdaine (1994) investigated the results from responses of engineering students to the Herrmann Brain Dominance Instrument (HBDI). This 120-question survey indicates the preference of problem-solvers to use analytical or creative thinking in their use of problem-focused problem solving skills.

Shown in Table 2-6, there are five steps in the diagnosis of a problem, using a problem-focused problem solving approach.

Table 2-6. Steps in Problem Diagnosis Steps in Problem Diagnosis (Coppola, 1997)

Step Problem Diagnosis

1. Define the problem.

2. Gather the information.

3. List the possible solutions.

4. Test solutions.

5. Select the best course of action.

The first step is to define the problem. Defining the problem includes identifying the state of being of a problem and the perception of the presence or absence of an error (Miettinen &

Flegel, 2003). One must determine what it is that has occurred that suggests a problem exists. In the case of incident managers, the occurrence of an unplanned outage is the problem that is perceived to exist. Normally, identifying what has stopped working, or what has begun to work differently than expected, characterises the state of being and defines the problem. The next step in diagnosing a problem is to gather information that is available, including the domain of the problem. The domain of a problem is the location where the problem occurred. In IT, the domain may be a network failure, a hardware failure, a software failure, or some other location where the problem or its symptoms are visible. Once the information about the problem has been gathered, solutions must be tested to determine which will resolve the problem; this is determined by identifying the root cause of the problem. Once done, the best course of action can be selected, implemented and the problem can be fixed. If, for example, the symptom of an unplanned IT outage indicates that the problem is the lack of response from a software application, the root cause of the problem may be that there is data contention on the network. The symptom of no network transactions being seen guides the problem solver to the problem, rather than to its symptom. The problem may be resolved by increasing the network bandwidth in order to remove the contention for network resources. The final step in a problem-focused approach to problem solving must occur. The problem must be removed through the selection of the best course of action to do so. Unplanned outages with significant negative impact to the end users or to the business often result in technical teams receiving executive encouragement—pressure from the corporate management team to fix the problem. Like its use in other industries, including law and criminal justice, executive encouragement is not necessary to accept when decisions are required; however, in some corporate cultures that exist in organisations, there is wisdom in accepting such encouragement (Meletta, 2008).

When executive encouragement is given to incident managers, it occurs during times when unplanned outages being managed are not restored in as timely a manner as the business requires and the executive managers are, often, hearing directly from customers and

end-users who cannot use the IT systems at the company. Executive encouragement is designed to deliver service restoration through the active oversight of technical support groups already working to restore service. As well, it is used to communicate the importance of problem resolution. The process of problem resolution occurs after the problem has been diagnosed. (See Table 2-7.)

Table 2-7. Steps in Problem Resolution

Steps in Problem Resolution (Kepner & Iikubo, 1996)

Step Problem Resolution

1. Understand the problem situation.

2. Understand the purpose to be served.

3. Involve the people who can help solve the problem.

4. Get a complete and accurate picture of the problem.

5. Find the cause and prove it.

6. Set the criteria for effective action.

7. Find the best actions to resolve the problem.

8. Create a workable first draft of a plan.

9. Fine-tune the plan into a program of action.

10. Communicate to gain understanding and acceptance.

This traditional problem-solving method is linear and the steps are taken sequentially; it is not always an optimal problem-solving approach for multi-dimensional problems (Coppola, 1997). These steps, however, can be taken and applied to all problems, though these steps may prove time consuming.

Most available research investigates the use of a problem-solving approach to solving problems and finds that approach to be methodical, simple, and effective. It does not, however, indicate that it can be performed expeditiously. The application of the Kepner-Tregoe problem-solving analysis to determine why Apollo XIII failed took weeks to complete;

yet, the work to return the astronauts to earth could not wait weeks. All the while promoting a problem-focused approach to solving its problems, the U.S. National Aeronautics and Space Administration (NASA) used a solution-focused approach to get the astronauts back to earth in days. Though referred to as an ―abbreviated use of the problem analysis‖ (Kepner &

Tregoe, 1997), what the team of engineers on the ground did to return the astronauts to earth was to focus on the solutions available to achieve their goal. Their goal was the safe return of the astronauts to earth; that an oxygen tank exploded mid-flight was identified as the root cause of the disaster, through problem-focused techniques, was used after the solution-focused approach achieved its goal. This aligns precisely with the work of de Kleer,

Mackworth and Reiter (1990) who state that to fix a problem begins with the diagnosis of the problem, defined as the identification of all components as either failing or not failing to explain the symptoms observed. NASA had no such time to apply these techniques.

ITIL identifies the steps of root cause analysis performed when desiring the permanent removal of a problem by means of the Kepner-Tregoe method (Taylor, 2007). Actually named the Kepner-Tregoe Problem Solving and Decision Making (PSDM) process, ―Kepner-Tregoe‖ and ―K-T‖ have become common nomenclature for solving problems. Its four steps are cited in Table 2-8:

Table 2-8. K-T Steps in Problem Solving

K-T Steps in Problem Solving (Continuous Improvement Facilitators, 2006)

Step Problem Resolution

1. Describe the problem.

2. Identify possible causes.

3. Explore possible causes.

4. Verify the true cause.

Use of the Kepner-Tregoe problem-solving method affords incident managers an alternative to a common use of hunches, instinct, and intuition to restore service (Marquis, 2006). A problem-focused approach to restoring service makes use of the combined knowledge, experience, insight, and judgment of a team, resulting in faster and better decisions. Though the K-T method describes ITIL‘s problem management function, it is often applied as an incident management tool when the restoration of service is less important than determining the root cause of the problem that caused the unplanned outage. A primer to its application is offered in Table 2-9, in which the correct K-T questions are asked, for which answers are sought.

Table 2-9. Problem Analysis Worksheet When Failure time Other times where

failure did not

Table 2-9 describes the four aspects of every problem—what it is, where it happens, when it happened, and how severe its pain was to the impacted party. The IS column provides space to describe specifics about the problem. The COULD BE but IS NOT column provides space to list items related to the problem, excluding detail. These two columns can assist in removing both intuitive and incorrect assumptions about the problem. With columns one and two completed, the third column provides space to detail the differences between what IS and COULD BE but IS NOT. The last column provides space to list any changes made that could account for the differences (Taylor, 2007).

Kepner-Tregoe problem-solving is one of a variety of problem-focused approaches used by problem solvers working to determine why an event has become a problem. Unlike solution-focused managers, problem-focused managers not only ask, ―What happened?‖ but work to discover the answer to the question. Other problem-focused problem solving tools and techniques are quality improvement programs including Ishikawa diagrams, Total Quality Management (TQM), and Six Sigma. All are designed to solve problems.

The Ishikawa diagram, also known as a cause-and-effect or fishbone diagram, is one of seven basic tools used in quality management to solve problems. The other six are histograms, Pareto charts, check sheets, control charts, flowcharts, and scatter diagrams (Calabrese, Foo & Ramsay, 2007; Maze-Emery, 2008). The other six are not discussed here

in detail, yet their applicability to problem solving is, in fact, variations on the themes identified through the use of the Ishikawa diagram. Developed in the 20th century, the Ishikawa diagram is credited to a Japanese quality manager, Karou Ishikawa, who first introduced this problem-solving tool in 1943 (Rooney, Kubiak, Westcott, Reid, Wagoner, Pylipowe, et al., 2009). Ishikawa diagrams are used to aid problem solvers in determining the root cause of an issue and to understand why the issue is experienced. It forces the participants in its creation to determine why the process to be delivered is not being delivered as expected (or at all), and to identify from where data should be obtained to fix the issue.

Ishikawa diagrams illustrate the main causes and sub-causes that lead to an effect. It provides problem-solvers information, not data, in a graphic format. Ishikawa diagrams, as well as the other six basic quality management tools, provide graphical information for consideration when working to determine the cause of a problem. An example of an Ishikawa diagram can be seen in Figure 2-9.

Figure 2-9. Example of an Ishikawa, aka Fishbone, Diagram (HCI, 2009)

Total Quality Management (TQM), a problem solving tool that contributed to the fundamental problem-solving activities performed in manufacturing organisations in Japan, has multiple theories as to its origin; however, in the 1980‘s its use was applied internationally and its origin is credited, primarily, to four quality management experts, including W. Edwards Deming, Joseph Juran, Philip Crosby, and Kaoru Ishikawa (cited previously for the problem solving tool commonly referred to as the Ishikawa ―fishbone‖

diagram). The aim of TQM is to reduce variation from every process used to create a product in order to increase consistency in the delivered product (Royse, Thyer, Padgett, &

wrong address

Logan, 2006). Unquestionably, it requires measuring performance, making improvements, re-measuring performance, and ensuring that all parties using the process apply all improvements made in a consistent manner. Additionally, one key component of TQM is its consideration by all parties performing the processes. Workers are not asked just to perform, but to be responsible and accountable for their performance to ensure improvements are incorporated consistently.

TQM comprises four steps, each with a Japanese name, given that the Japanese first successfully deployed TQM on a broad scale. The steps are cited in Table 2-10.

Table 2-10. The Steps of Total Quality Management The Steps of Total Quality Management (de Villiers, 2006)

STEPS ACTIVITIES

Kaizen Focuses on continuous process improvements, using a team to obtain input from all impacted parties and makes processes visible, consistent, and measurable

Atarimae Hinshitsu Focuses on the intangible effects of processes and focuses on quality that is expected by the user

Kansei Examines the manner in which the user of the product actually uses the product in order to improve the product

Miryokuteki Hinshitsu

Requires that the product has an aesthetic quality and it is pleasing to use so that a user will use it

Unlike other problem solving tools, Six Sigma is a management process designed not to improve products or services, but to remove defects, defined as anything that causes customer dissatisfaction. Introduced by the Motorola Corporation in the United States in 1982, Six Sigma is considered more a business strategy than a quality program, although its successful deployment undoubtedly improves product quality (Maguad, 2006). Although a subtle alternative to solving problems, Six Sigma processes focus on the identification of defects and their removal, measuring defects in order to obtain a degree of performance and acceptable quality at the mathematical value of Six Sigma. The Six Sigma process measures the number of defects per opportunity to have a defect, with the goal of achieving Six Sigma performance. Sigma, expressed mathematically using the Greek letter σ, represents the standard deviation of quality from perfection. Table 2-11 identifies the level of quality and accurate products made when achieving each of the first six levels of sigma performance. Achieving Six Sigma states that only 3.4 defects occur from the 1,000,000 opportunities in which a defect could occur.

Table 2-11. Sigma Quality – Percentage of Defect-Free Products Sigma Quality – The Percentage of Defect-Free Products

Sigma Percent of Quality and Defect-Free Products Produced

1 31.00000%

2 69.20000%

3 93.32000%

4 99.37900%

5 99.97700%

6 99.99966%

A problem-focused approach to problem solving, when done effectively, finds the cause of the problem and eliminates it. A problem-focused approach to solving problems is not used to determine if information exists to solve the problem, but to stimulate new learning to solve the problem (Hallinger & Kantamara, 2001). It is a time-weathered approach to bringing forward solutions and allows for creative thinking in identifying alternative solutions that may resolve a given problem. Solutions must meet the needs of the parties experiencing the problem; problem-solving techniques are used to identify the cause of the problem in order to determine a solution. Known as effective vehicles to improve quality, problem-focused problem solving is presented within the frameworks of Ishikawa diagrams, Six Sigma, TQM, K-T problem solving and other alternatives that have strict measuring guidelines to determine performance. It is among the K-T framework that ITIL promotes work within the problem management slice of service management to perform problem-focused problem solving. ITIL recommends no approach for managing incidents.