{"id":607,"date":"2021-01-29T15:02:18","date_gmt":"2021-01-29T20:02:18","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=607"},"modified":"2021-07-20T22:45:06","modified_gmt":"2021-07-21T02:45:06","slug":"problem-solving-process","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/problem-solving-process-180215\/","title":{"rendered":"Problem Solving Processes for Success in Multiple Domains"},"content":{"rendered":"

Problems are everywhere and having a formalized framework with which to approach them is essential to success both in programming, software engineering, and life-at-large. Here we’ll discuss some problem-solving processes that can be applied to a wide range of problem domains.<\/p>\n

4-Step Problem Solving Process<\/h2>\n

Starting simply, a problem-solving process of four steps as described in the 1945 Book How to Solve It<\/em> by G.Polya provides a solid foundation on which to start (1). These process stages are by no means deemed universal. They do serve well as the basis from which more specific and evolved problem-solving processes can be built. Understanding these core tenants of the problem-solving process is essential.<\/p>\n

1. Understand the Problem<\/h3>\n

It should go without saying that to effectively solve a problem one must first understand that problem, at least in part. To help ensure an effective understanding of the problem considers the following:<\/p>\n

    \n
  1. Who are the stakeholders for this problem set?<\/li>\n
  2. What unknown variables exist for this problem?<\/li>\n
  3. Can the problem be broken down into smaller problems and, if so, would this offer an advantage in solving the larger problem?<\/li>\n
  4. Can this problem be represented graphically such that analysis can be performed for deeper insight?<\/li>\n<\/ol>\n

    Problems can be more fully understood and thus more completely addressed by working to answer these basic questions and address these basic concerns.<\/p>\n

    2. Plan the Solution<\/h3>\n

    Just as with Software Engineering<\/a>, without a plan of action few problems are solved. At the very least, the absence of a plan is likely to result in an inefficient<\/em> result. Planning techniques vary wildly depending on the problem domain, solution domain, and available resources. Below are some general guidelines to help structure the planning stages:<\/p>\n

      \n
    1. Are there existing solutions to similar problems that could be used for reference or application?<\/li>\n
    2. Can the larger problem be broken into smaller problems in such a way that these sub-problems can be addressed individually? If so, can any sub-problems be compared to existing problems where full or partial solutions exist?<\/li>\n
    3. Can a design model be created for a potential solution, such that it can be analyzed, improved, and ultimately lead to an effective solution?<\/li>\n<\/ol>\n

      Learning from existing solutions and past problems is an invaluable tool for addressing new problems. Particularly in software development, even partial solutions may already exist such that considerable resources can be conserved in addressing new projects.<\/p>\n

      3. Carry Out the Plan<\/h3>\n

      Design planning can help model potential problem solutions but eventually, they must be applied to realize their merit. Carrying out the plans and applying models developed during the planning stage often leads to the discovery of many previously-unknown variables. This process is often iterative and requires astute observation, consideration, and adjustment to reach goals. The following points are useful to consider:<\/p>\n

        \n
      1. Does the solution align with the plan\/model? If not, where and why were deviations made and how did they affect the outcome of solving the problem?<\/li>\n
      2. Is each aspect of the solution\u00a0provably<\/em> correct in that rigorous proofs and\/or tests can be applied?<\/li>\n<\/ol>\n

        Execution separates ideas from products and requires that one take action. When approaching a problem this means applying one’s plan and measuring outcomes. Was the solution successful? If not, was it partially<\/em> successful? These questions can help identify what about your current process is providing positive results and where improvements can be made.<\/p>\n

        4. Examine the Results<\/h3>\n

        Solutions, especially in software, aren’t always wholly successful. This hallmark characteristic of software products doesn’t necessitate scrapping a project, however. Even large-scale projects can be deemed successful while still possessing the potential for error. Things like bugs, unforeseen user behaviors, or overlooked requirements can all be addressed iteratively. Having a robust system to detect such bugs and errors is essential to having a flexible and dynamic problem-solving framework. Consider these two points when examining the results when problem-solving:<\/p>\n

          \n
        1. Can each aspect of the solution be tested and verified? If so, can the accuracy and effectiveness of these solutions be consistently measured?<\/li>\n
        2. Does the solution produce results that conform to the requirements of the results that are required? If so, can these results be validated by stakeholders?<\/li>\n<\/ol>\n

          Examination of results is a hallmark of scientific and engineering processes by which efforts can be quantified. Problem-solving processes are, by their very nature, scientific in nature. This characteristic can be illustrated by the systematic approaches outlined by common problem-solving frameworks. The measurement and validation\/verification of solution results is arguably the most essential stage of any problem-solving process.<\/p>\n

          Other Steps<\/h2>\n

          There are several extensions of the simple 4-step problem-solving process that are popular among software developers, business leaders, and manufacturing processes. In essence, the more granular processes sub-divide certain aspects of the 4-step for deeper clarification.<\/p>\n

          For example, in a common 8-step problem-solving process, step 1 is divided into identifying the problem<\/em> and\u00a0understanding the problem<\/em>. While distinct in practice, both these steps are essentially about problem awareness.<\/em><\/p>\n

          Another common addition to the basic 4-step process is a final stage describing an iterative approach. This may be referred to as\u00a0iteration<\/em>,\u00a0cycling<\/em>, or just simple\u00a0repetition.<\/em> The idea here is to maintain a mindset, and course of action, of continuous improvement.<\/p>\n

          Another common separation of steps within problem-solving process frameworks is the selection of solutions. In the 4-step process, this would fit within the plan the solution<\/em> stage. Selecting a solution would be done at the end of step two after initial solutions had been proposed. An extension of this step, while useful, is still essentially a modeling and design<\/em> focused step.<\/p>\n

          Final Thoughts<\/h2>\n

          Problem-solving is universal. Whether concerning a chicken trying to cross the road or NASA planning a manned mission to Mars. Having a framework with which to approach problems will produce more efficient and successful outcomes. The basic 4-step problem-solving process can be adapted for domain-specific use and even expanded upon for a more granular focus.<\/p>\n

          References<\/h2>\n
            \n
          1. Polya, G. How to Solve It: A New Aspect of Mathematical Method (Princeton Science Library)<\/i>. Princeton University Press, 1945.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

            Problems are everywhere and having a formalized framework with which to approach them is essential to success both in programming, software engineering, and life-at-large. Here we’ll discuss some problem-solving processes that can be applied to a wide range of problem domains. 4-Step Problem Solving Process Starting simply, a problem-solving process of four steps as described […]<\/p>\n","protected":false},"author":2,"featured_media":609,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[246],"tags":[202,258],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/607"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=607"}],"version-history":[{"count":4,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/607\/revisions"}],"predecessor-version":[{"id":613,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/607\/revisions\/613"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/609"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}