You have learned about how the problem evolves through its life stages and how it can be represented using its type and nature. We also studied how Decision Science and problem solving require a curious mindset with an interdisciplinary approach for the solution. We also explored how problems are actually interconnected in nature and internally composed of smaller problems that can again be of a different type, nature, and life stage. Lets now go ahead and study the problem solving framework.
The problem solving framework basically represents a blueprint for the entire solution designed for the problem. Lets say that we are building a software or house; we would basically have an entire list of items that we need to acquire as resources and steps to be executed as per the plan for the end product to look as we have envisioned. Problem solving is also a similar story. Here, the first step is to break down the problem into smaller problems (in case the problem is a big one) and then gather an exhaustive list of hypotheses. To solve a problem, we basically collect a plethora of hypotheses and then test them to get results. Finally, we combine all the results together in such a way that we create a story where we have an answer to the question that we are trying to answer in the problems context. The hypotheses can be data-driven or heuristics-driven.
Lets take an example to understand how the problem solving framework looks. Consider the case of a hydroelectric power plant, where we have a small setup of devices necessary for the hydroelectric power generation: a turbine, generator, transformer, dam, penstock with an intake control gate, and other essential ones. These devices have their regular roles, such as the dam takes care of storing water for the hydroelectric plant, and there would be a penstock that is basically a long intake pipe that carries the water from the reservoir through controlled gates into a powerhouse that hosts the turbine. The turbine is a device equipped with large blades that rotate when water falls on them, and finally the generator generates AC electric energy from the rotation of these blades in the turbine. (Lets ignore the physics behind this to an extent.) The transformer then converts the electric energy to a higher voltage energy. In the entire flow, the gates of the penstock can be controlled to change the rate of the flow of water into the powerhouse:
The hydro power plant diagram
So, what would be the problem?
You are the site engineer who has been asked the question: Why has the generation of hydroelectric energy been low for the past one month? Assume that you have no physical access to the location currently, but still you would first like to gather the maximum amount of information before you begin working on the site when you have access. This would be a scenario where you only have time at the site to fix the problem and not go there and then find out the root cause by testing and inspecting a couple of things. This is a use case that you can solve using data, data, and data. So, as a high-level approach, you would now use every dimension of data and find out the root cause that is possibly dipping the energy generation from the power plant.
Now that the context of the problem is clear, lets take a step back and try to understand more about the problem and then enter the problem solving framework. In this problem, we are trying to find out the root cause of an event-in a nutshell, we are trying to answer the question, Why did the event happen? This indicates that it is inquisitive in nature. Secondly, the problem is not radically new and neither has it been completely solved and tested to have an exhaustive solution guideline for all problems. Therefore, the problem is in the Fuzzy stage. Finally, the problem definitely has a high impact and is not a once-in-a-lifetime or once-in-a-couple-of-years event. We can probably conclude that the problem has moderate to high impact and moderate to high frequency. With the current landscape of the problem, we should probably build a product for this problem with a permanent automated solution. For now, lets explore the problem solving framework.
The framework is a very simple deal. If we are new to the business domain, we would first gather knowledge around the business domain before starting with the problem. In this scenario, we would explore the working of the hydroelectric workstation and how each component in the plant contributes to the overall process. Then we start collecting the list of hypotheses that can be a factor to the problems solution. So here, we lay down all the factors that could possibly be a reason for the root cause of the problem we are trying to solve:
Hydroelectric
In this scenario, we can think of a few factors that can be valid hypotheses for the root cause. For example, there would contamination in the oil of the transformer or there could be an oil spill. The rotors of the turbine could have overheated or the runners could have eroded. The amount of water flowing into the penstock and the water levels set in the gate control could be different, that is, water pressure in the penstock may be lower than usual, the RPM of the turbine blades is lower, or the critical parameters for the turbine have been operating at a lower value for a longer duration. Similarly, the critical parameters for the transformer or generator could have been performing beyond the normal operating range for a longer duration. Oil levels in the gears of the devices may be below the ideal point or the devices may be operating at a temperature beyond the normal range. For these devices, we would have multiple parameters in place that define the status of operation for the devices and deviance from normal operations. A closer look at these parameters will help us define the entire picture of the power plant. All of these factors that build our initial layer of root cause analyses forms the collection of heuristic-driven hypotheses.
Once we have the heuristics-driven hypotheses defined, we have action items in place to test what went wrong. We can individually test these hypotheses, evaluate the results from them, and gather insights. Secondly, our collection of hypotheses is still not exhaustive. We might have missed out on tons of important correlated factors that are probably latent in nature and might only be visible when we explore the data in more detail. Lets keep the data-driven hypotheses aside now. (This will be more realistic as we move to Chapter 3, The What And Why - Using Exploratory Decision Science for IoT). Consider a usual problem solving approach where we have collected a couple of heuristic-driven hypotheses, performed exploratory data analysis for the data, and tested the hypotheses collected. We would find that a few of the hypotheses that we designed earlier are not accurate as the results were not intuitive. We may discard a few hypotheses and prioritize a few others. We would also find a lot of new relationships between data dimensions that we had not accounted for initially. Now, if we revisit the previous list of hypotheses, we would probably have a version with better and more accurate hypotheses and also new hypotheses that we uncovered during our data exploration exercises. The new hypotheses may not be our final version. It may go through a series of iterations before it gets finalized. The refined final list of hypotheses can be called the problem solving framework. This is where the convergence of data-driven hypotheses and heuristic-driven hypotheses takes place. This can be represented as a matrix or prioritized list of hypotheses, which needs to be validated to solve the problem:
The problem solving framework
The initial list may have a few hypotheses that may not make sense to test as there may be data limitations or they may be counter intuitive with a few latent data relationships that we explored during our analysis. Once all the hypotheses have been tested, we will have results gathered from various tests from them under a single roof. The next step is to assimilate the results so that we can make sense of the story from the results. Synthesizing the results assimilated, we may find the root cause for the event as a result of a few other events. Lets say that while gathering results from our data, we might conclude that the malfunctioning of the controlled gates in the penstock was the root cause. This might be inferred from the critical parameters of the turbine and generator operating at lower thresholds continuously for a prolonged stint. A few data tests on the water pressure and its correlation with the value from the controlled gates differing over a period of time can be an indicative value for the same.
In a nutshell, we have glanced through a very high-level problem with a structured approach using the problem solving framework. The problem solving framework is a simplified approach to design and draft the exhaustive hypotheses generated as a result of the convergence of heuristics and data exploration. With the exhaustive list of hypotheses, we conduct various data tests and assimilate results from them to synthesize and solve the problem by gathering insights and creating a story. In the coming chapters, we will solve real business problems using the problem solving framework and also understand each incremental phase in more detail.
