Building a better model for technical problem solving: when an organization develops a practical approach to problem solving, it teaches employees how to overcome barriers and instills in them a desire to accept ownership of problems.
According to James Rooney and Deborah Hopen, authors of "Problem Solving Should Be like Treasure Hunting" in the Journal for Quality & Participation, "The fundamental approach that separates structured problem solving from other methods is root cause determination. The process assumes that if the implemented solutions do not address the true underlying cause, the problem will recur, wasting the resources that were invested in the original effort."
A study by this author of an information technology department's problem solving approaches in central Indiana determined that a structured problem-solving model using strong subject knowledge, experience, logic, and reasoning was favored.
Structured and Non-Structured Problems
The author of "Experimental Learning to See Through Strategic Behavior in Large Scale Projects," P.W.G. Bots, wrote that technical and business problems may be categorized into two types, structured and non-structured. Structured problems are those for which a solution has been developed, and the solution is documented. Computer programs, such as order processing systems and customer relationship management systems, solve structured problems on a daily basis. Another example is structured problems found in a knowledge base system, whose documented solutions are used by a help desk or a customer call center.
Once a problem's solution is documented, the documentation can be used to solve the problem if it occurs again. Procedure manuals and processes are the result of problems that have been solved and documented.
Non-structured problems are those for which a solution has not been documented. For example, a bug in a computer program can be a non-structured problem. Usually a program bug is a new problem that developed because of a unique circumstance, such as a modification of data format. The year 2000 (Y2K) problem that arose at the end of the 20th century is an example of a non-structured problem. The Y2K problem resulted because programmers did not anticipate that year date fields in programs would need more than two characters of data.
A non-structured problem may have occurred previously and may have been solved. However, if the solution was not documented, the problem continues to be non-structured and the problem has to be re-solved. Organizations are plagued with undocumented (non-structured) problems, resulting in avoidable expense. One objective for converting non-structured problems into structured problems is the accumulation of information for the creation of knowledge.
Barriers to Problem Solving
People must be motivated to solve problems. They must have a strong desire to do so, because problem solving often requires persistence and involves risks. Good problem solvers commit to the task.
Some common stumbling blocks in problem solving are fear of failure and unwillingness to take ownership. Fear of failure may be accompanied by fear of being associated with the problem. According to Rooney & Hopen, some people may not want to commit to solve a problem because there may be guilt by association--that is, once the technician owns the problem, the problem is identified with the technician.
However, not knowing how to solve problems is perhaps the most common reason for hampered motivation, and a structured problem-solving model can remove this barrier. Knowing how to solve problems begins by understanding that the problem solver needs three resources.
Required Resources: Time, Money, and Knowledge
Without sufficient quantities of time, money, and knowledge, a problem cannot be solved. Inversely, all technical problems can be solved with sufficient time, money, and knowledge.
Time, money, and. knowledge are related. With enough time, knowledge can be acquired internally by training current staff so they have the skills and knowledge needed to solve the problem. If time is short, but money is plentiful, knowledge can be hired from the outside through consultants or contractors.
Knowledge is the primary problem-solving tool. When employers hire employees, they are really hiring knowledge. An employer who needs to solve the problem in a short time period is likely to hire someone with enough knowledge and experience to be productive immediately. This option trades money for time, because knowledgeable, experienced employees require higher compensation.
However, if the need is not as immediate, the employer may choose to hire a person with less knowledge and experience. The employer will then plan to invest time, allowing the new person opportunities to gain experience and acquire the knowledge needed to be productive. If an employer is willing to hire an inexperienced person, then the employer is willing to trade time for knowledge.
Time is always diminishing, and as it does so, it becomes more valuable. As time diminishes, it must be used more efficiently. Brooks' law of project management says that adding more people to a project, late in the project, will make the project later.
Pitfalls of Traditional Problem Solving
The traditional problem-solving model begins by defining the problem. However, if sufficient data is not known about the problem, an accurate definition cannot be determined. Beginning the process by defining the problem is similar to a police officer declaring a murder victim committed suicide without gathering evidence.
Starting the process with defining the problem can cause the solver to jump to conclusions, which can lead to the shotgun approach to solving problems. When a person fires a shotgun at a target, a pellet may hit the target, but it's impossible to identify which pellet hit. In problem solving, imagine that the pellets are possible solutions. One of the solutions worked and the problem is solved, but which solution was it? The shotgun approach is difficult to document, and without documentation, the solution remains non-structured. Starting the process by gathering data helps to reduce assumptions and prejudices about the cause of the problem and avoids the shotgun approach.
The Practical Problem-Solving Model
1. Data Gathering
In this first step of practical problem solving, data is collected, even if the problem solver is not sure the data is related. Environmental data, historical data, interviews with individuals (experiential data), and, if possible, quantitative data are gathered. Careful notes should be taken during the data-gathering step.
The purpose of analysis is to understand what the data is saying. The problem solver processes data and tries to create information useful to understanding the problem. According to Svetoslav Stoyanov and Paul Kirschner in "Effect of Problem Solving Support and Cognitive Styles on Idea Generation: Implications for Technology-Enhanced Learning," during analysis, the problem solver prioritizes and categorizes the data, sorts it, and draws pictures, charts, or other illustrations that help make sense of the data. Mind mapping and brainstorming can be helpful. Traditional statistical analysis and the repertory grid method of data analysis can also be helpful for solving complex problems. Near the end of the analysis step, a clearer understanding of the problem will develop.
3. Hypothesis Development and Testing
A hypothesis is an explanation or definition of the problem. It is the result of reasonable analysis. A hypothesis is not a theory, because, according to the 2003 Merriam-Webster's Collegiate Dictionary, a theory involves speculation and may not be the result of reasonable analysis. Hypothesis defines the problem, based on the information created in the analysis step. The hypothesis step is a milestone in the problem-solving model. When the problem solver defines the problem, it means the cause of the problem is believed to be understood, or the problem solver has a reasonable idea of such a cause.
But, the hypothesis or problem definition stills needs to be tested. In "Constructive Controversy for Management Education: Developing Committed, Open-Minded Researchers," author Dean Tjosvold said trying to recreate the problem can be an effective way to prove the hypothesis. Statistical testing can also be performed to prove the hypothesis. As the hypothesis is tested, the problem solver may learn more about the problem.
4. Solutions Development
A solution is an answer or resolution to the problem. Once the hypothesis has been tested, the problem solver can begin developing solutions. This is an iterative process, which may require different methods. A more complex problem may require a prototype software or system be developed.
The Y2K problem demonstrated different approaches to solving a problem. One solution was to modify existing programs to accommodate expanded date fields. This approach usually requires identifying all date fields in all of the programs in all software applications. If any date field is overlooked, it can have serious results. The second solution was to replace existing applications with new applications. The solution chosen in most Y2K cases was usually a balance of the time and cost required for its implementation.
Developing solutions can be an iterative process that is a part of hypothesis testing, and it is not unusual for more than one solution to be developed. Technical people often develop solutions, but management decides which solution to implement. Documenting solutions is important during this step because such documentation can help explain the problem and possible solutions to decision makers.
Often, the solution chosen by management is based on the three resources--time, money, and knowledge--needed to implement the solution. Solution A may require knowledge that is beyond the capabilities of the organization. If time is not critical, the decision may be made to train current staff to solve the problem. If time is critical, the decision may be to contract for resources with the knowledge needed to solve the problem.
5. Implementation and Documentation
The final step is to implement the solution and document the problem along with its successful resolution. A knowledgebase system is a good way to track changes and document problem solutions. Knowledgebase systems allow non-structured problems to become structured problems. They offer functions and features that allow easy retrieval of solutions to previous problems. They also have built-in statistical analysis tools. Even without computerized documentation means, the problem and its resolution still need to be documented.
Effectiveness of the Practical Approach
The practical approach to problem solving was the standard model used to solve level-two help desk problems at Irwin Mortgage Corporation from 1998 through 2000. Many help desks have a multi-tier hierarchy of categorizing problems. If the problem is resolved in the initial call, it is considered a level-one problem. Problems not solved in the initial call are escalated and assigned to level two. Level-two personnel are more technical and often resolve an issue with code changes to an application or a change in business process.
According to this author's research, prior to implementing the structured model, the daily resolution rate for level-two help desk calls was approximately 50 percent. After implementing the structured approached, resolution improved to nearly 75 percent. The level-two technical team was required to document the problem using the practical approach and complete the documentation by updating a knowledgebase system.
Learning Organizations Use the Practical Approach
The practical approach to problem solving features a goal of documenting solutions to convert non-structured problems to structured problems. This method builds processes, procedures, and knowledgebases, which reduce redundant effort. It is an effective methodology to solving problems.
An organization with a practical approach to problem solving is a learning organization that teaches employees how to overcome barriers to solving problems and instills a desire to accept ownership of a problem.
Bots, P. W. G., "Experimental Learning to See Through Strategic Behavior in Large Scale Projects." Production Planning & Control, September 2006.
Bowman, Darrell. "A Study of Ivy Tech State College Computer Information System Faculty and Advisory Committee Problem-Solving Constructs." UMI number 3121063, 2004.
Rooney, James & Deborah Hopen. "Problem Solving Should be Like Treasure Hunting;' Journal for Quality & Participation, Fall 2004.
Stoyanov, Svetoslav & Paul Kirschner. "Effect of Problem Solving Support and Cognitive Styles on Idea Generation: Implications for Technology-Enhanced Learning:' Journal of Research on Technology in Education, Fall 2007.
Tjosvold, Dean. "Constructive Controversy for Management Education: Developing Committed, Open-Minded Researchers." Academy of Management Learning & Education, 7, No. 1, March 2008.
Darrell D. Bowman, Ph.D., is assistant professor of computer information systems at the University of Indianapolis School of Business. He may be contacted at email@example.com.