Latest revision as of 20:05, 28 February 2021

Problem solving in companies is difficult: Not only do you first have to identify a problem, but the company may also be so deeply entrenched in the way that they are doing things that they cannot possibly consider doing it differently. Developed by highly respected consultancy firms, The Answer First methodology is a proven way of structuring a problem and its' solution in a way that in a way that is communicable, coherent, and thorough. By formulating a solution hypothesis - the Initial hypothesis - and breaking it down into smaller, test-able assertions a solution can be pressure-tested in a thorough manner, covering all elements. Backed by data, testing of the lowest level of the hierarchy - tertiary assertions - and whether these based on data can be validated or not is carried out. This validation aims to assess if they have an effect on the sub-assertion and through that the initial hypothesis. This breakdown enables a methodical, solution oriented and coherent problem-solving with clearly defined goals throughout. Framing the project around a initial hypothesis also creates a narrative and reasoning that presentable and easy to follow for stakeholders. This article will briefly explain the birth of this methodology. Subsequently it will explain how it fits into contemporary management theory. What follows will be a hand-book in working with problem solving using this methodology. This article will also highlight the pitfalls one can encounter when using this methodology as well as provide a general example throughout the presentation of the Big Idea.

[edit] Introduction

Sooner or later, each and every one of us will have to be presented with the task of communicating a complex problem and its' solution to important people. Unfortunately, solving and communicating complex problems is not easy. As a company machine grows, the cogs and gears comprising the business are increasingly interconnected - as such the complexity of problems are bound to increase. This further complicates concise and logical communication of the problem.

In order to tackle the problem of solving problems of increased complexity and communicating them in a concise and informative way some of the worlds biggest management companies McKinsey and Bain & Co. developed a structured problem solving methodology ^[1], ^[2]. The methodology, despite having distinct names, follow the same principles - understand and frame the problem and context, define an initial hypothesis/answer, break down the answer into analysable elements and lastly verification of the initial hypothesis/answer by validating the test-able tertiary assertions.

[edit] Big Idea

What better way to further communicate and exemplify that the Logic tree and the Answer First Methodology is a brilliant way to structure and communicate complex problems, than use the methodology as a framework to explain itself! If this methodology is successful in communicating itself, it will no doubt be a useful tool to managers or prospective engineers too.

1:

What comes first is the Initial hypothesis. This hypothesis not only lays a foundation for further exploration within the problem owners’ area of solution, but also provides a solution to the problem from the get-go. That's right - you answer the problem before you have even done any analysis or research!^[3] The arguments for this this statement are presented in Logic-Tree fashion below.

2:

A paramount facet of dealing with business problems, and one of which the success of the project according to PMI standards ^[4] is contingent on, is communicating them to stakeholders and the project team. The elevator test ^[1] states that a problem solver post-analysis should strive to be able to communicate a complex problem and its’ solutions over the course of an elevator ride. For you ‘stair people’ out there that is approximately 30 seconds. ‘Why?’ You may ask. The reason is two-fold: 1. For you to be able to boil a complex problem and its’ solutions down to 30 seconds requires a thorough comprehension of the essentialities within each of them. 2. Important stakeholders as well as the problem owner, be it manager or executive, whom are either responsible for change or can give you the mandate to implement a change simply does not have time to engage in the problem like you have. It is your job to present to him/her the essentialities of your findings ^[2]. This methodology enables exactly that.

2.1:

Using a model as an illustration will greatly aid your communicative efforts to get your point across by illustrating complex interrelated information in a simple way ^[5]. The Logic Tree is no different. Providing a hierarchy and structure to your communication that can at all times be referred to enables the target audience to clearly follow the reasoning points of your presentation and the thought process behind different assertions and how they relate ^[3].

2.1.1:

In a study, 182 senior managers were interviewed in a range of industries, 71% said meetings are often unproductive ^[6]. Using this tool, only stuff that is has an impact on the initial hypothesis is communicated. This avoids the communicator and the conversation straying into non-relevant gibberish, staying on topic. The overview the Logic Tree provides serves as a brilliant reference point as to how the project is progressing (eg. We are currently examining this tertiary hypothesis) to and what the goal of a given meeting is, keeping attention on the problem at hand ^[2].

2.1.2:

Throughout the communication the reasoning is traced from the Initial hypothesis down the Logic Tree all the way to the Tertiary assertions. What follows is a data-driven and fact-based verification in order to analyse to what extent these assertions hold true ^[3]. If they do, logical conclusions can now be made from the tertiary assertions all the way to the initial hypothesis. In this case – if data or facts support that 2.1.1 and 2.1.2 is true, a logical conclusion follows that 2.1 is true.

2.2:

The Answer First Methodology utilizes deductive reasoning to arrive at a pressure-tested and actionable solution ^[1]. Deductive reasoning sets itself apart by being thoughts that yield a conclusion from assertions being valid or not ^[7]. This way of reasoning is very familiar because we do it every single day when considering day-to-day choices: “I don’t want to arrive late to work tomorrow, so I better set an alarm and mentally prepare my morning routine”. Here it is implied that the general conclusion one is not late to work is true if the premises that one sets ones’ alarm and one mentally prepare ones’ morning routine are valid. This methodology hereby presents general conclusions – assertions – that when broken down are proven and as such affirm the assertions higher levels or dis-proven and in this case require a re-formulation or a complete dismissal of the assertion.

2.2.1:

Data is only presented to relevant and verifiable tertiary assertions To drive a concise communication it can be assessed which tertiary assertion that has the highest impact on the initial hypothesis ^[2] – and then the data for this assertion can be put forward to prove why a certain assertion is valid. The Logic Tree also clearly presents what assertion the shown data verifies – avoiding the pitfall of showing data that confuses the audience more than it backs up your points.

2.2.2:

A major strength of this methodology is that solutions are always present, just under different degrees of verifiability ^[2]. This means that, in principle, at any point stakeholder can inquire into the findings of your analysis and get a solution presented. In contrast, problems solving that is done by way of inductive reasoning need to have a high degree of quantitative analysis done in order to draw any valid conclusion ^[3]. This mean that if the problem and its environment are subject to change a lot over time and further complicating the problem, this tool is mitigative to this risk, being able to arrive at a solution more rapidly ^[2].

3:

Solving multi-faceted, complex problems is not easy. By using this methodology, clear objectives – goals - with their relations are clearly presented. The closer to the main hypothesis, the more vague and general the assertions are – as such these cannot be evidently dis-proven or proven ^[2] but have to be broken down into smaller, testable tertiary assertions. They do, however, tie the logic between the initial hypothesis and the factually verified tertiary assertions to create a coherent and easy-to-follow reasoning.

3.1:

A recognized method to solve complex problems (also seen in System-oriented problem solving and the Black-box tool ^[8]) is breaking it down into smaller, more manageable sizes. To do so we must deduct, discuss, and investigate with colleagues – what is they key element of each hypothesis? For this, a good question to for each step to ask is ‘Why?’^[1]. Assertion: Why does the Logic Tree and the Answer First Methodology ensure problem solving is done in a structured and coherent manner? …. Answer: The problems are broken into manageable sizes. And why does this fact ensure the former… ->

3.1.1:

The search for solutions is only manageable if it is known what to look for.” ^[8] When the problem has been properly de-constructed, focused data-gathering is commenced. Making sure to only do data-collection for the ‘lowest’ level of problems ensures a clear objective when gathering and analysing data that can validate or invalidate an assertion. Not only that, but a sensitivity assessment can also be assigned to each tertiary assertion determining how much they affect the parent assertions and in turn the initial hypothesis.

3.1.2:

As a framework for a detailed workplan in line with the WBS, the Logic tree can be utilized to manage a teams toward a solution. By using the Logic Tree as roadmap of activities, a project manager can utilize Tertiary assertions as as scopes for a further work breakdown ^[1]. It is important to note, however, that this methodology is not a project management tool per se. To properly manage a project it is therefore recommended to use other managerial tools such as the GANNT chart or SCRUM to manage the completion of tasks and day-to-day activities in conjunction with this methodology.

3.2:

A term leading consultancy companies using this tool swear by is MECE. At McKinsey, It is hammered into every graduate’s brain ^[2]. In context of this methodology, the use is straightforward - in the development of the logic tree, each assertion must address the previous one in a unique way. Not only that, but the sum of all sub-assertions under every assertion must also be Collectively Exhaustive of all relevant impacts ^[2].

3.2.1:

By having every assertion be unique, the problem-solving group mitigates the risk of double work, or even worse, that two non-unique tertiary assertions validates contradicting assertions.

3.2.2:

By having a Collectively Exhaustive list of assertion, no stone is left unturned. This means that all possible solutions are pressure-tested for impact on assertions.

[edit] Context and Application

A strength of this tool is its' scalability, allowing it to be utilized in both problem solving at strategic, project, program and portfolio level. Being able to adjust the generalization level of the initial hypothesis to the level of the problem can scope this tool to fit it ^[2].

In this example, the scope of programs, portfolios and projects in this makeup car manufacturer BS Auto is derived from the overall Initial Hypothesis that gaining EV (Electronic Vehicles) market share within the car industry will solve the problem of BS Auto's Year-over-year decline in revenue the past years. As such the portfolio scope should be 'Model insert-fancy-model-name-here'. Similarly, program and project scopes can be derived from the logic tree that is developed from the answer-first assertions in the logic tree.

[edit] In relation to other tools with a hierarchical structures

Other relevant and popular tools like the root cause analysis and work breakdown structure also use a hierarchical structure to visualise dependencies and hierarchy. While they definitely carry resemblance in the way they are used to breakdown something complex into easier to managable elements, they have different abstraction levels and are also different in what they are trying to communicate. As such they should be used differently. In order to distinguish between them a summary and a collection of use cases are presented below:

Root-cause analysis: The Root-cause analysis tree is mostly used in the context where the goal is to find the root cause for a particular error or undesired state of something, often leading to a very deep dive into a very specific and detailed level ^[9]

• A production where the end-product experiences too many errors during production (Ishakawa)
• A mechanical problem on a complex machine
• Why you are still single

Work-structure breakdown: The work-structure breakdown is a breakdown of a complex task or project into actionable elements that are then assigned members of a project team for completion. The goal for work-structure breakdown is to end up with tasks that are clearly actionable. ^[4]

• Design of a complex engineering system
• Method of developing Standard Operating Procedures
• Identifying tasks under a project scope

Logic tree and the Answer First Methodology: The Logic tree and the Answer First Methodology is used as a way of solving business problems in a way that is communicable. The Logic Tree and the Answer First Methodology aims to, based on a thorough understanding of the problem, develop concrete solutions rapidly and with a clear reasoning. ^[3]

• To determine scopes for future Portfolios, Programs and Projects from a business problem as seen in the figure to the right.
• Communicating reasoning and solutions to executives and other important stakeholders
• Solving complex problems with multiple causes

A main difference can be found in the abstraction level between the two other tools and the Logic tree and the Answer First Methodology. Whereas the former seek to find arrive at very detailed tasks and causes, the latter is more general. As such, the tool described in this article is better suited to solve business problems that facilitate strategic decision making, defining scopes for Portfolios, Programs and Projects in the process. These scopes can be further be broken down into actionable work-tasks using Work-structure breakdown if need be.

[edit] In conjunction with system-oriented problem solving

As it happens, this methodology fits neatly into the system-oriented problem solving method. In fact, literature suggests that Answer First principles and structure Logic Tree brings to the table is a good idea to implement while approaching goal definition and concept synthesis in the system-oriented project solving process:

"The result of the goal definition is a structured catalogue of objectives. This catalogue of objectives is further used in the concept analysis and selection" Page 91 in ^[8].

As such, it is recommended to use the Logic Tree as a way to clearly structure objectives, worded in Answer First principle, in the goal definition stage. Note that the objectives in this case should be the primary and secondary assertions, and not the tertiary as these are concrete, testable solutions.

"In the first step of a synthesis-analysis-cycle, a wide and comprehensive range of solutions is developed with only a shallow description of the details. This first step aims at completely covering the field of possible solutions" Page 95 in ^[8].

Utilizing MECE, the Tertiary assertions here represents the wide and comprehensive range of concrete and validate-able solutions. This falls perfectly in line with purpose of the concept synthesis that is to find diverse and concrete solutions which are related to our objectives (Primary and secondary assertions).

" The concept analysis aims at identifying unsuited solutions or individual deficiencies selecting and improving ideas and solutions and narrowing down the spectrum of alternatives in the process of the analysis" Page 95 in ^[8].

" In principle, the concept analysis is about examining ‘validity’ of the individual solutions. For this purpose, the solutions have to be analysed under different aspects." Page 103 in ^[8].

The general concept analysis aims to validate these solutions by way of critically examining and whether they fulfil and affirm the parent assertion. Concrete Data and facts should support the decision whether the tertiary assertion is either valid or invalid.

As seen in in ^[8]

To sum up, it is recommended to use Logic Tree for its structural and complexity reducing capabilities as an alternative to the Black Box method in conjunction with the Answer First Methodology for its communicative benefits. More specifically, in the system-oriented problem solving context, it is desirable to use the methodology in the recursive procedure initialized in the steps of Goal Definition, concept analysis and the general concept analysis in ^[8].

[edit] How-to-use handbook

What is presented here is a complete step-by-step guide on how to implement this tool in the field:

1: Workshop setting with Project team and problem owners - Frame the problem the Initial hypothesis solves and explain present an initial plan of the problem solving procedure. :

Firstly, we need to understand the context of the problem the initial hypothesis addresses (Pyramid). For this, scoping tools like the Task analysis and/or System Demarcation can be used in a workshop setting to illustrate and facilitate and understand of context.

Consider if there are elements in the environment that can cause complications

• Make efforts to understand industry specific particularities
• Map important stakeholders including the problem owner
• Develop a fact-base to support a concrete problem statement (eg. Financial statement supports that Revenue has declined by X in the recent year)

2: Develop initial hypothesis (IH) within the project team´:

Develop an initial hypothesis that solves the problem

• Consider whether your IH is your general enough - rather be too general and scope down later, than too narrow and missing important aspects.
• Be as concise as possible - the IH should not be the length of a novel, but rather a sentence.
• Consider whether
• Avoid outside influence: The problem owners may already have an idea for a solution or the root of a problem. Put this aside, as it will bias your search for solution

3: Workshop: Break down initial hypothesis´ with your project team: Break down your IH into its central components - what facts must be valid for the IH to be true?

• Remember the MECE principles: Develop Mutually Exclusive and Collective Exhaustive assertions
• Consider at what time an assertion is difficult to reasonably break down anymore. Is it verifiable? If yes, it is a tertiary assertion (McKinsey)
• Enable a idea-rich environment: Use brainstorming techniques for assertion generation! And remember - no idea is inherently bad. You can always discard the idea later if it is not relevant.
• Consider your team and their skills and knowledge. Are you well covered within this problem and industry scope? If not, consider acquiring expertise to help the breakdown of the problem

4: Stakeholder meeting: Communicate your Logic tree to stakeholders:

Stakeholders management is an important aspect of any P/P/P (Project). Communicate your answer-first Logic tree to stakeholders to inform them of your initial draft of a solution.

• Bring them into the discussion: If they can find inconsistencies in the reasoning between assertion or additional assertions consider adding them to the model.
• Gauge their satisfaction and compromise if necessary: Not all solutions, even though they might technically be the best solutions, is the best for the problem owner and other important stakeholders for various reasons (Stakeholder engagement).

5: Create a detailed workplan that aims to validate or invalidate tertiary assertions

• Consider incorporating other task management tools like GANNT charting, weekly meetings, SCRUM
• Set clear deliverables for each tertiary assertion and assess how much data is sufficient to properly analyse it

6: Workshop: Consolidate validity of tertiary assertions and re-evaluate Logic Tree

Next is bringing the data to work. The goal of this workshop for your project team is to consider what impact the data-gathering and analysis have on the coherence and reasoning in the Logic Tree. Remember - working with complex problems should be an iterative process.

• Does the invalidation of some assertion require a dismissal or reformulation of some assertions?
• Reconsider the IH based on the Logical conclusions that comes from the bottom-up from the primary, secondary and tertiary assertions. Does it still hold truth or should it be changed?
• Does the potential changes to assertions/IH imply new assertions that need validation?

7: Workshop: General Concept Synthesis

Develop a Concept Synthesis comprising of a solution package that is presented to stakeholders and the problem owner.

• Consider doing a sensitivity analysis on your tertiary hypothesis prior - which of them has the highest impact? These should be covered by your solution package
• Consider whether multiple assertions can be covered by one implementation. The more the ways a concept "attacks" your problem the better - refer to the Logic tree!
• Design a solution package with feasibility in mind: the problem owner must have resources to implement the package

8: Stakeholder meeting: Communicate your finalized Logic tree to stakeholders:

The big meeting: Communicate your findings to stakeholders including the problem owner.

• Define scopes of subsequent implementation projects
• Communicate concisely and with a base in the logic tree so the reasoning is clearly understandable

After this, the project work can continue within the framework of system-oriented problems solving - that means a detailed concept synthesis followed by the concept analysis and the evaluation/decision process ^[8]. The structure and overview of the general assumptions and assertions made using the Logic tree and the Answer First Methodology should, however, be used throughout for referencing.

[edit] Limitations

As with any tool, the Logic tree and the Answer First methodology is not without its' limitations and pitfalls that should be avoided. Because breakdown of the problem starts from the Initial hypothesis actions must be taken to ensure that resources are not spent in fact checking tertiary hypothesis that stem from a IH that is flawed. The Initial hypothesis should be general, based on industry knowledge, a fact-base and have roots in the problem context ^[1]. Similarly, a problem solver should not fall into the pitfall target fixation. The steps in this tool should be considered iterative in the sense that if at any time a finding implicates a change in the initial hypothesis or a parent assertion, the problem solver should not be afraid to change that them as long as they update the assertions leading out from it. Further - let us explore what this methodology is not:

• It is not a complete framework to be used exclusively throughout a project. This methodology is not a complete management tool in the sense that it captures all challenges and tasks of a P/P/P manager ^[4]. As such it could for example be initialized in the Goal Definition stage in the systems-oriented problem solving, serving as a structured breakdown of problem the same way the Black Box Method is used ^[8].
• It is not a methodology for a project manager to define work tasks and a detailed project activities. This methodology should be used as a framework for understanding and clearly communicating the different elements of a problem and what assertions, if proven true, reinforces a certain solution for it.
• It is not a tool to use for very detailed and specific technical problems. As the methodology relies on 'general' solutions to be tested, it is more fit for breaking down general business problems. Instead use root-cause analysis ^[9].

The Logic tree and the Answer First Methodology needs, like any other tool, to be played to its' strengths in order to harness the most from it. As such it should be used in conjunction with System-oriented problem solving and alongside other relevant P/P/P tools.

[edit] Further reading

The Minto Pyramid Principle Barbara Minto, 2010, Prentice Hall, ISBN: 0273710516

In this book Barbara Minto, a seasoned and respected consultant, presents why thinking and communicating in a structured way is desirable. Drawing from her own lengthy experiences in high-ranking consultancy companies, Minto conveys the Logic tree (here called the Pyramid principle) and its application through simulated work-like situations. Albeit a bit lengthy, The Minto Pyramid Principle provides industry insight into the consultancy world, as well as a nice overview of the methodology and its' real life applications.

Cracked it! How to solve big problems and sell solutions like top strategy consultants Bernard Garrettte, Corey Phelps, Olivier Sibony, 2018, Springer, ISBN: 9783319893754

Bernard Garrette et al. provide a pragmatic insight into this methodology and its' how it can be integrated boiled down into a fool-proof process. This book describes how a problem solver can define the problem by categorization and thoroughly understanding its' nature. The strength of this book is its applicability and that it relates this methodology to other problem solving tools like 4S and Eight Degrees of analysis. They also have a youtube channel discussing their approach to problem solving: https://www.youtube.com/watch?v=4zHx_JE9Jsg.

The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business Ethan M. Rasiel, McGraw-Hill, 1999, ISBN: 9780071368834

In this work by Ethan M. Rasie, the McKinsey way of consulting is 'whistle-blowed'. As he states himself, McKinsey guard their company secrets well. But perhaps not too well as Rasiel in detail explains the inner workings and work methodologies of this consultancy giant. In an informal language Rasiel especially deep dives into how McKinsey tackles problem-solving consultancy tasks. Speaking directly to the reader, this work is not exactly the academic pinnacle of good writing and source practices, but does provide an interesting insider knowledge.

[edit] References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4 1.5} Bain & Co problem solving approach, Morten Bay Company Presentation TEMO 2020 'Note: while this presentation is not publicly available, it must be regarded as an empirical approach. The experience the presenter has had with this tool in Bain & Company is very real
2. ↑ ^{2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9} The McKinsey way Ethan M. Rasiel, 1999, McGraw-Hill, ISBN: 9780071368834,0071368833
3. ↑ ^{3.0 3.1 3.2 3.3 3.4} The Minto Pyramid Principle Barbara Minto, 2010, Prentice Hall, ISBN: 0273710516
4. ↑ ^{4.0 4.1 4.2} Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th edition, PMI standards
5. ↑ In the Company of Others: An Introduction to Communication J. Dan Rothwell, 5th Edition, Oxford University Press, ISBN 0190457422, 9780190457426
6. ↑ Stop the meeting madness Harvard Business Review, https://hbr.org/2017/07/stop-the-meeting-madness
7. ↑ Deductive Reasoning P.N. Johnson-Laird, 1999, Annual Review of Psychology, Vol. 50 page 109-135, https://doi-org.proxy.findit.dtu.dk/10.1146/annurev.psych.50.1.109
8. ↑ ^{8.0 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9} No more Muddling Through P. Troxler and Rainer Zust, 2006, Springer, ISBN: 9781402050183
9. ↑ ^{9.0 9.1} Kvalitetsstyring og Måleteknik Torben Jul Jensen, 2012, Erhvervskolernes Forlag, ISBN: 9788770822961