What's your data-driven process for problem-solving?

The technique that i use for problem-solving is based on the DMAIC methodology, which stands for Define, Measure, Analyze, Improve, and Control. I define the problem clearly and precisely, using data and facts to describe the gap between the current state and the desired state. Furthermore before analysing the problem, We must identify the customer requirements from their point of view , putting us in their shoes as well as the project goals and scope.

In my data-driven problem-solving process, I approach challenges like puzzles, breaking them into smaller pieces to enhance my clarity of thought. A key step involves breaking down the business goal into a basic math equation, examining data for each contributing factor to identify strengths and areas of opportunity. This approach enables me to focus on the right metrics to reach the business goals. With these insights, I initiate a comprehensive journey of primary and secondary research. It's like being a detective, discovering what our customers truly need and understanding why it's crucial to solve their problems right now. It's not just about fixing problems; it's about meeting our customer's needs and making a positive impact.

This is where 90% of problem-solving attempts fail. And using many complex tools represented by weird acronyms does nothing to lower that number. The one thing that does, is a thorough answer to the only question that matters: what does success look like ? Guaranteed, not a single stakeholder has the full answer from the get-go. Get specific: understand exactly what behavior or outcomes the solution should drive. Take examples, edge cases, unlikely scenarios: you have to group-QA-test your understanding of success to weed out misalignment, misunderstandings from the get-go. Once you do that, your problem isn’t a nebulous affair anymore; it’s a clear cut trade off being rewards and costs.

I begin outside the box. Never asking the why they do what they did. I use What, How, If, When, Could type questions. The why is is often received with a response of needing to justify their actions. Gets them feeling like you are judging them and then they go into protect mode. More open questions and deep listening is the key, to drill down to the real issues. I begin with a 'What led you to that solution, and how did that work out for you'? What would you do differently if there were no restrictions. This opens up the mind, to them feeling they have something worthy to contribute. I never offer a solution, I lead them towards the solution that will work for them. Giving them the power that they are in control.

Problems should be define precisely in terms of Who, What,where,when & how much.The problem itself, stated clearly and with enough contextual detail to establish why it is important.Problem statement must be written clearly and accurately in order to deliver successful.Problem statement should not be too narrow & not too broad.The statement should not include solutions or posible causes.A problem statement should include absolute or relative measures of the problem that quantify that gap.The problem itself, stated clearly and with enough contextual detail to establish why it is important

Often once the problem is defined clearly and precisely, data may be used to identify the gap(s) that need to be addressed. If data is not available, then that could be the problem in and of itself. You may need to go gather the data, either manually or using a digital tool. If data is readily available it is ofen not in the format necessary for decisions to be garnered or may need to be stripped of private or personal information (PII, PCI). Data may be 'massaged' by a technological resource to be able to slice and dice information as a basis to make reasonable decisions. Either way data is invaluable information used in problem solving.

Data collection has to have a structure to solve a problem sustainably no matter which area; it can be in production, in indirect areas or in software management. Data should be collected in a classified way by asking questions; what, where, when, who, how much. The aim is to derive contrasts based on the facts already existing.

I search for the right tool to collect my data. At this stage, I want data from several different sources (people, process, procedures, management, etc.) I might use Ishikawa diagram (fish bone) or if a time based problem, a chronology based timeline. Always use facts that are proven. To prove my facts, I might use Fault Tree to examine all branches. To generate data, I collect papers, interviews, inspections, etc to get a cross section.

This shouldn’t be the second step. First, you want to assess where you will want to use data, to reduce uncertainty. Where is uncertainty costing you most in making this decision ? Where is uncertainty the cheapest to reduce/remove ? Identify areas where you will invest analytical ressources (BA, DA, DS, Statistician), and then get to gathering the data. Ensure you understand the source of your data: is it primary (yours), secondary (your org) or tiertiary (outside the org) ? Ideally, gather insights on how this data was generated, so you capture the potential biases it holds. Repeat the process until you have high confidence you have the best data set possible, within the limit of your ??uncertainty reducing?? budget.

In reality, data collection is often an iterative process in which new data sources need to be added as we progress with the root cause analysis. However, the process of data collection can be significantly shortened if an organization systematically makes data available upfront, e.g. in the form of a data lake or a data warehouse.

In my experience looking at the data is not as difficult as it sounds. While there are many methods, often looking at summaries, filters, or just scrolling through can give someone a LOT of insight on the problem. I can't count how many times I've solved problems that were simple such as data input issues. For example: IF there is a field that allows someone to type in a response, versus selecting from a list of responses, the problem is often a typing issue (spelling, hyphenation, capitalization). Another example might be an option has not been used - the problem may be the option itself is not a good selection, or it may not be working. These are two simple problems that can be identified very simply by just looking at data.

Efficient data analysis converges toward the root cause of the problem, by leveraging contrasts in the data that can effectively rule out potential causes and thus progressively narrow down your search until you can pinpoint the technical root cause.

One thing I've realized over time is that you should try to come up with a simple solution. Often there are multiple ways to solve a problem and there is usually a time component and a cost component present. IF the problem is impacting a business you need to get the problem resolved ASAP. Look at the risks of each solution and keep in mind the time and cost for each. Often there can be a small situational outlier that is not part of the most logical and simple solution. IF that outlier has a low probability of happening then you need to assess the risk of the time and cost to solve for that low probability! Make sure your solutions don't get mired down in low probabilities and what if's and focus is on problem resolution.

This step is paramount. Corrective solutions are usually simple to notice and implement, but in my opinion they are often administrative in nature (and sometimes less expensive). I prefer solutions that prevent the problem and this requires plenty of analysis and testing. I like using run charts and other statistical. The result must fit in the analysis to prevent the problem; the ultimate solution must still be proven in real-world.

It is paramount that any solution is actually based on the correctly identified root cause from the previous step. Due to time pressure, many organizations rush to implement actions and "solutions", that do not actually address the root of the problem.

Communicating the result should include systematically applying the lessons learned from your problem solving case in all other applicable cases in your organization.

In my opinion, an important aspect of communicating results or recommendations is the buy-ins. I may not always be the one to execute the solution or recommendations and hence the stakeholders who are directly involved in the executions are important.

In my experience it's important to communicate the monetary benefits of this activity to inspire others to make necessary plans and investments to develop more people to resolve further issues. Lessons gained out of the activity is vital to prevent reoccurrence and to deploy the same gains in different areas. Last but not least, the team worked in that should be recognized in a way most suitable for the organization.

Use "5 why's" to get started. Yes, it can oversimplify, but if your boss is asking you about a problem in the first few minutes, you might be able to get to the third why and make an impact. Just my two cents.