How do you manage ambiguity using a framework?

Issue Tree helps structure various thoughts, bucket issues appropriately and visualise them logically as components. If time allows this is an excellent tool for Problem definition. Problem statement is a quicker turnaround item that defines the key issue and it’s sub problems. Almost always an imperative than choice. Hypothesis is not a necessary component of a problem statement, but if included it adds to the flavour and provides a sense of probe direction. Hypotheses are mostly generated in sets and need an expertise to state the most relevant, the most representative sets. Type of hypotheses often dictates the choice of the framework too. Issue Tree- Great Tool Problem Statement - Must Do Hypothesis - Optional and Expertise Driven

A problem is an expression of the reality. Defining it as detailedly as possible contributes to the finding of a solution. Thus, how we build this definition plays an important role towards the solution. Situations are rarely static, and storytelling provides a rich way to integrate into the description of the problem all stakeholders, relations, constituent elements, dynamics, timeline, etc. The human brain is wired to understand stories. This brain feature is a valuable asset when facing solving-problem situations.

While defining a problem, perspective is important as well. Whether a situation is a problem or not may be determined by the perspective or lens through which we are looking at it. Maybe a change in perspective, changes the problem into an opportunity. What we need to be wary of is the bias or subjectivity we put while defining problems. We should be as objective as possible and look at a situation through every conceivable perspective.

When trying to define the problem, you may find that there are actually several related issues that are masquerading as "the problem". So step 1 is to generate a list of all the related issues. Step 2 is then to discuss which issue is the most important to solve. The stakeholders might not agree on which issue is the most important, so the conversation should be framed around solving issues that will have the greatest impact & address any urgent issues. Furthermore, you should discuss whether it's most efficient to solve some issues before others. If you're lucky, a few of the smaller issues will go away if you solve the more important issues first. Look for the leading domino, so to speak.

If something seems ‘ambiguous’ it can often suggest a lack of understanding and people may be coming at things from very different perspectives. Before falling in to the trap of detailed analysis and debate, often better to take a step back and ensure you ‘start with the end in mind’. Gain consensus on what it is you are trying to achieve and ground this in common-sense language that everyone understands (particularly your customers…!). Once clear, incremental steps rather than a giant leap of faith will help build confidence and aligned clarity of purpose…from where the real hard yards in terms of analysis etc can flow.

Selecting the appropriate framework takes time and experience. Frameworks are heuristics that help solve problems - but it's important to remember there's no 'one size fits all.' As a start, I would recommend acquainting yourself with various frameworks (e.x. MECE, SCQA, SWOT, etc). If there are any people in your organization or network who have experience applying these in real-life work situations, it would be good to talk with them as well.

One methodology, for Process Optimization or Performance Improvement Initiatives, my teams and I use extensively is to Plan, Analyze, Prioritize, Execute, Deliver and Measure. There are different frameworks that are apt for different scenarios, but I keep falling back to this one.

I believe this subtitle should be renamed to "Choosing the right framework for your problem", as @Tim Yau also said, it is more about selecting and adapting the existing theoretical frameworks in practices, which also takes a lot of effort and knowledge. Designing your own framework would need years of experience, a monumental number of trials and errors, prototypes and different situations to test it it, before using it the right way most of the time. Picture frameworks like a box of Lego bricks, as it is always up to us how to use them to eventually build whatever we want. They are just the tool(boxe)s, as we should remain the masters, not their slaves. Some frameworks like Design Thinking and Sprint are very fun and engaging as well.

Frameworks to me are a way to eliminate a lot of guesswork when doing an analyses. As others pointed out, choosing the right ones is fundamental to the outcome of this process. However, any consultant should have a few frameworks/models that can be used to make sure that nothing is missing from the analysis. The added benefit is that they usually are simple enough to force you to analyze the process down to the first principles. However, frameworks are just boundaries and scaffolding to limit and support us. They are helpful, but they are not an excuse to be lazy with our effort to understand the real nature of the problems we're facing.

Given the continuous and progressive nature of applying any framework, reminiscent of Sisyphus's eternal boulder push rather than a singular magical fix, we must ask ourselves: Is the core challenge clearly identified for this long-haul effort? With the understanding that there's no quick fix, how deep is our grasp of the problem's context? Does the chosen framework match the relentless and evolving nature of the challenge? How will we measure progressive successes in this journey? Are there biases influencing my perception, given the constant push required? Is the team ready for an ongoing commitment rather than a one-off solution? How will we communicate and adapt results as the framework application progresses?

Getting the planning right will determine how the findings from the analysis phase are socialized and delivered on. The planning phase will also determine the type of analysis needed such as interviews, data and analytics methods - correlation, regression, etc, benchmarking, market research, amongst others.

This is a very delicate step because reducing ambiguity with a framework could potentially have the downside effect of hindering innovation. Even when new data don't show significant variances, the environment or other factors might be changing and therefore it would be good to leverage different techniques such as "pre-mortem" to ensure the higher chance of success.

It is interesting to use frameworks for problem solving and discover that there is no acceptable solution. And then what? Sometimes you need a new mindset and to accept that the problem is not the problem. Does this make sense to you?

I can only second what @Rory Kilburn said here, and add a bit to it. Expecting different results from the same methods is one of the definitions of insanity. This is why refining of the framework is another constant effort based on iterations or repetitions. This just adds to the "magical wand" analogy, as people who see frameworks as one-stop solutions are gravely falling back behind the ones who see & use frameworks as repetitive cycles of learning and adaptation. Like there is nothing linear in a life of a human, except maybe the information on the grave afterwards, there is nothing linear in the process of using and refining frameworks until the final report. Remember, it is never the framework that is working, it is always us humans!

Socialization is key. I found out that we can never communicate enough. Change is inevitable but often met with stiff resistance. Understanding the stakeholders', organizations' and participants' motivation are critical to refining and adoption of the framework.

Any framework will help provide the structure to solve problems, but it takes an experienced consultant to truly drive growth and deliver on outcomes by applying best practice methodologies, experiential learnings and strategic insight. The best framework might serve as a blueprint, but you're going to want an experienced contractor guiding the construction for sure!

Individuals are the key to the success of every program. The project and execution team might have really novel and innovative ideas but adoption will be extremely difficult without buy-in.

A caution in using frameworks, is that 'no-one is perfect in this world', sometimes the framework also may have ambiguity. wrt to Business Continuity Management, standard ISO 22301 (2019), a debate has been on for decades 'whether Business Impact Analysis first or Risk Assessment first'. To resolve such ambiguities, again with the example of BCM and ISO 22301, read it, and read it again, and read it thoroughly. In this case, the clause for BIA appears first - so BIA first (so simple). Also, by definition, BIA needs to be conducted for all processes, while RA needs to be conducted for only the prioritised processes (which is the output from BIA) - hence QED!