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.

AuthorBowman, Darrell D.
PositionManagement Wise

There is a thin line between value-added processes and inefficiency in 21st century business. Re-solving technical problems can be an expensive business. The practical approach to solving problems is a model that focuses on each step of the process having value. The emphasis should be on gathering data and analyzing it to gain an understanding of the problem before solutions are developed.

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.

...

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT