Study Notes by Niladri & AI

ch09-structuring-the-analysis

15 min read

Chapter 9: Structuring the Analysis of the Problem

tpp pyramid-principle problem-solving diagnostic-frameworks logic-trees issue-analysis mece

Status: Notes complete

Overview

Chapter 9 explains how to structure the actual analysis of a problem so that data-gathering is efficient and findings translate naturally into a pyramid. The chapter argues against the historical consulting habit of gathering all available data first and organizing it later — a practice that generates 60% waste, according to Minto’s estimate from a major firm. Instead, the analyst should build diagnostic frameworks and logic trees before gathering data, using them to generate hypotheses and design focused, yes/no tests.

The chapter covers two categories of analytical tools: diagnostic frameworks (which help identify the causes of a problem by modeling the structure, cause-effect relationships, or classification of the relevant domain) and logic trees (which generate possible solutions and verify the logical structure of grouped ideas once a document is written). The chapter closes with a critique of “Issue Analysis” as a label, arguing that the term is often misapplied, and that what is really meant is either the process of developing diagnostic frameworks or the logic trees used to structure recommendations.

Core Concepts

Diagnostic Framework: A visual model — built using one or more of the three logical structuring techniques (divide, trace cause-effect, classify) — that shows the structure of the area in which a problem occurred. Used to generate hypotheses about the likely causes of the problem, so that data-gathering can be focused and yes/no questions can be answered.

Logic Tree: A tree diagram that lays out the logically possible actions that could be taken to solve a problem (or the possible ways to achieve an objective). Unlike diagnostic frameworks, logic trees do not diagnose causes; they generate solution options and check the completeness and mutual exclusivity of grouped ideas.

Issue: Strictly, a question phrased so as to demand a yes-or-no answer. The legal origin (“at issue”) implies two sides, one of which will prevail. “How should we reorganize?” is NOT an issue. “Should we reorganize functionally?” IS an issue. Minto recommends using “concerns” for topics that worry the client and reserving “issues” for genuine yes/no questions.

Abduction: The process of generating the likely possible reasons to explain why a problem exists — by looking critically at the structure of the area where the problem occurred. Referenced in Appendix A. Distinguished from deduction and induction.

Issue Analysis: A term coined at McKinsey by David Hertz and Carter Bales in the 1960s for NYC under Mayor John Lindsay. Originally a rigorous technique for decisions where urgency is high, multiple alternatives have merit, many variables must be considered, results are measured by conflicting criteria, and course of action significantly impacts other decision areas. Now often misused to mean any logic tree or grouped issues list.

The Case Against Starting with Data

Historical Consulting Practice

Early consulting (1950s–60s) proceeded by:

  1. Identify key success factors in the industry (market, price-cost, technology, structure, profitability)
  2. Assess client strengths/weaknesses (sales, technology, economics, financials)
  3. Compare client performance against key success factors
  4. Develop recommendations

Result: Overwhelming volume of facts from which it was hard to draw conclusions. A major consulting firm estimated 60% of fact-finding and analysis effort was wasted. Consultants produced “interesting” facts only marginally connected to the real problem.

The Better Approach: Structure Before Data

Better consulting firms now replicate the scientific method:

  1. Generate alternative hypotheses
  2. Devise crucial experiments (with alternative outcomes, each of which will exclude one or more hypotheses)
  3. Carry out the experiment to get a clean result
  4. Plan remedial action accordingly

This means forcing yourself to think up the likely possible reasons to explain why the problem exists (Abduction), then focusing data-gathering on proving or disproving those reasons.

The key insight: Those likely possible reasons come from looking critically at the structure of the area within which the problem occurred — specifically, the Opening Scene of the Problem Definition Framework.

Devising Diagnostic Frameworks

A diagnostic framework visualizes the structure of the domain where the problem occurred. This in turn reveals the elements or activities on which analysis should focus.

There are three ways to build a diagnostic framework (mirroring the three ways to structure any group of ideas from Chapter 6):

  1. Show the physical structure
  2. Trace cause and effect
  3. Classify possible causes

1. Showing Physical Structure

Draw a picture of the system as it is (or should be) functioning. This picture guides you to the questions that need yes/no answers.

Exhibit 37 (page 144) — Physical structure of a sales/marketing operation: Shows the chain Manufacturer → Wholesaler → Retailer → Consumer, with marketing activities (Awareness → Initial Purchase → Repurchase) above and sales activities (Shelving → Pricing → Special Merchandise Support) below. This tells an analyst whether share of market is down because customers aren’t aware, or aren’t convinced to buy, or aren’t repurchasing.

Exhibit 38 (page 144) — Industry structure: A hexagonal diagram showing the full chain from raw material source through manufacturer → warehouse distribution → consumer purchaser → consumer user → post-purchase services, with Economic Points of Leverage labeled at the top and Market Points of Leverage at the bottom. Used to identify where value is added, where profits are made, and where vulnerabilities lie.

Typical Opening Scene structures: Organization charts, computer configurations, plant/office locations, geographical markets.

Typical Opening Scene processes: Sales/marketing activities, information systems, administrative processes, distribution systems, manufacturing processes.

2. Tracing Cause and Effect

Show the elements, activities, or tasks that combine to produce a particular end result. Three variants:

a. Financial Structure (Exhibit 39, page 145): Decomposes Return on Investment into Trading Profit and Assets, then breaks each down to its drivers (Sales → Products/Prices/Service/Market Conditions; Costs → Variable Labor/Materials, Fixed). Numbers on the chart immediately reveal whether the problem is in Sales or Costs or both. The structure is MECE — every element is mutually exclusive and collectively exhaustive.

b. Task Structure (Exhibit 40, page 146): Begins with EPS and divides the tree in terms of the company’s financial structure, stating each element as a discrete managerial task (“Increase Net Sales,” “Reduce Leaf,” etc.). Imposes Profit and Loss Account categories and Balance Sheet categories on the tree structure. Advantage: identifies what kind of action is required if the problem is found at any point in the tree.

c. Activity Structure (Exhibit 41, page 147): Traces the activities that produce an undesirable end objective — for example, installations taking longer than expected. The undesirable effect goes at the left; you hypothesize MECE reasons at the next level (fewer men per rack / more hours per man per rack / fewer hours on duty per week), then break each down further. Results in a complete list of areas where facts could be gathered.

3. Classifying Possible Causes

Group likely causes by similarity, on the assumption that pre-grouping helps synthesize facts. Two approaches:

a. Similarity classification (Exhibit 42, page 148): Classify at the upper branch (e.g., Sales break into Semi-Fixed Factors and Variable Factors), then determine what information you would need to gather to prove or eliminate each. At the Profits level: Sales → Semi-fixed (falling market, store number/location, size, accessibility) and Variable (wrong goods, layout, price, in-store display, selling staff, advertising); Gross Margin → Price too low / buying cost too high / wrong mix; Costs on Sales → Overelaborate cost base / poor cost control / cost-related merchandise decisions.

b. Choice structure / Dual-choice diagram (Exhibit 43, page 149): Display dual yes/no choices at each stage. The tree starts with the undesirable effect and bifurcates at each step. Example: Ineffective sales support → Ineffective at retail OR Ineffective at headquarters. If at retail → Right Stores or Wrong Stores. If right stores → Right Frequency or Wrong Frequency. Continues until reaching actionable causes (priorities not clear, salesman overloaded, wrong compensation, inadequate supervision).

Exhibit 44 (page 151) — Sequential marketing analysis: The most sophisticated diagnostic structure. Three top-level questions: (1) Does the brand have a problem? (2) Where does the problem lie? (3) Why does the problem exist? Beneath these, the full marketing chain — Positioning → Distribution → Awareness → Trial → Repurchase — with data elements hanging off each stage. Feedback loop: if no problem source found, go back and reconsider whether target market and consumer benefit have been accurately defined.

The Power of Yes/No Questions in Diagnostics

Diagnostic frameworks rely on yes/no questions. These serve as “crucial experiments” — their answers unambiguously identify or exclude contributing causes. They also tell you in advance when you will be finished with your research.

Diagnostic frameworks vs. decision trees and PERT diagrams (Exhibit 45, page 152): Decision trees and PERT diagrams reveal the need for action (what to do and in what sequence) rather than diagnosing causes. They are not diagnostic frameworks.

What a Diagnostic Framework Tells You

Once developed, a diagnostic framework lets you show the client:

  • What the structure/system looks like today as it delivers R1 (what’s going on now)
  • What the structure/system logically would have to have been to deliver R1 they now get (what you must have been doing)
  • What the structure/system ideally should look like to deliver the desired R2 (what you need to do to achieve your objective)

Applying the Frameworks

The appropriate diagnostic frameworks are generally implied by the Opening Scene of the Problem Definition Framework. You do not choose a framework in the abstract; domain knowledge guides the choice.

Case Study: Barrows/ISD (Exhibit 46, page 153)

Problem: Information Systems Division (ISD) of Barrows cannot respond to growth opportunities.

  • Opening Scene: Barrows with ISD division running new production planning and control systems (Master Production Scheduling, Material Planning, Shop Paperwork, Order Status Reporting)
  • Disturbing Event: Lack of required parts, not filling orders on time
  • R1: Afraid system not being used as well as possible; user groups may not understand; can’t judge where inefficiencies lie
  • R2: Production capability able to cope with expected growth; improved efficiency and productivity in support groups

Diagnostic approach: Since the problem is low efficiency on the factory floor, the first diagnostic framework needed is a picture of the activities and processes on that floor.

Exhibit 47 (page 155) — Flow diagram of the organization: Shows Engineering and Purchasing feeding into six functional areas (Order Processing, Manufacturing Engineering, Material Control, Schedules, Dispatching, Operations Evaluation), with six data categories below (Information on order and lead times; Bills of material and routings; Inventory and ordering factors; Master operations and load formulas; Shop dispatching and priority rules; Control standards; Evaluation data for management decision).

With this diagram, the consultant formulates focused yes/no questions:

  1. Order and lead times — do they promise uncompetitive lead times, and do they deliver as promised?
  2. Purchased items — are there delays or excessive costs in obtaining raw materials?
  3. Availability of stock items — are shortages and stock-outs hurting sales or increasing costs?
  4. Availability of capacity — is capacity adequate to meet forecast demand?
  5. System costs — are management controls in one area throwing the system out of balance?
  6. Management reports — do status and labor efficiency reports provide necessary control?

Administrative benefit: Before beginning, the consultant can identify source of each data item, assign responsibility for collecting it, establish schedule, and estimate costs. The entire effort becomes efficiently manageable.

Developing Logic Trees

Logic trees serve a different purpose than diagnostic frameworks: they generate possible solutions (steps 4 and 5 of Sequential Analysis) rather than diagnosing causes (steps 2 and 3).

The Sequential Analysis connection:

  • Steps 2 & 3 (Where does it lie? Why does it exist?) → Use diagnostic frameworks to model what exists
  • Steps 4 & 5 (What could/should we do?) → Use logic trees to generate possible solutions

Logic trees also serve a third purpose: revealing flaws in grouped ideas once a document is written.

Generating Possible Solutions

A logic tree spells out the logically possible actions to solve a problem in a MECE breakdown.

Exhibit 48 (page 157) — Reduce direct labor costs: Starting from “Reduce direct labor costs,” break into Primary Process Costs, Making Department cost per cigarette, Packing Department costs, Other costs. For Making Department: Cost per hour (reduce overtime / use cheaper labor / minimize wage awards) × Hours per million cigarettes (reduce people per machine / increase machine speeds / increase machine efficiency). Once the logical possibilities are laid out, the consultant can calculate benefit and estimate risk of each action.

Exhibit 49 (page 158) — Strategic opportunities for a European bank: “Capitalize on opportunities arising through normal growth of the economy” branches into: Fill the gaps in the current business / Exploit increasing financial sophistication of the corporate sector / Finance expansion in building and construction / Capitalize on increased EC trade and investment / Participate in growing overseas projects.

Revealing Flaws in Grouped Ideas

You can use logic trees to question the logic of what you have written.

Case: Texas piping company (pages 159–162): A consulting proposal listed 10 “Key Issues” but they were actually wordy questions, not MECE issues. Analysis showed:

  • The real problem: Centralized inventory management ($27M) ties up too much working capital (R1 = Excessive capital tied up in inventory; R2 = Right amount of capital devoted to inventory)
  • The proper issues are yes/no: “Is the centralized management system placing orders properly?” and “Is it keeping too much obsolete and slow-moving inventory?”
  • The proper pyramid: “We will determine whether/how you can cut the cost of inventory” → three branches: (1) Determine the right level of inventory to meet customer service objectives with the present centralized structure; (2) Determine how much the present level can be lowered by changing procedures; (3) Determine whether the inventory level can be lowered further by decentralizing the structure

Exhibit 50 (page 162) — Energy cost cutting: A 10-issue list is diagrammed against a logic tree. Issues 7, 8, and 9 simply don’t relate to energy costs. Issues 1, 2, and 6 relate to fixing existing equipment; Issues 3 and 4 to creating new equipment; Issue 5 to using lower cost fuels; Issue 3 also covers adding new equipment with less costly fuel; Issue 10 refers to cutting energy costs altogether.

The principle: All groupings of ideas must have originated in an analytical activity. Matching your ideas to the diagnostic structures you created verifies their logical validity.

Performing an Issue Analysis

What Issue Analysis Really Is

The term “Issue Analysis” was coined by David Hertz and Carter Bales at McKinsey in the 1960s during a study for New York City under Mayor John Lindsay. Its original purpose was to help urban managers make complex decisions when:

  • The need for decision was urgent
  • More than one alternative had merit
  • Many variables needed to be manipulated
  • Results could be measured by varied, conflicting criteria
  • The ultimate course of action could significantly impact other decision areas

The “Issue” Confusion

The word “issue” is frequently misused. Minto’s definition:

  • Correct: An issue is a yes/no question (from legal phrase “at issue” — two sides, one prevailing). “Should we reorganize functionally?” is an issue.
  • Incorrect: “How should we reorganize?” is NOT an issue — nothing is “at issue,” since it presupposes a decision has already been made.

Practical recommendation: Use “concerns” when listing topics that worry the client. Reserve “issues” for true yes/no questions that can be answered yes or no and that enable clear-cut problem-solving decisions.

Why Issues Are Valuable

Yes/no issues are vital because:

  1. They enable clear-cut answers
  2. It is the ability to formulate yes-or-no questions that dictates how efficient a problem-solving effort will be
  3. They serve as the “crucial experiments” of the analytical process — unambiguously identifying or excluding contributing causes
  4. They tell you in advance when you will be finished with your research

Issue Analysis vs. Diagnostic Frameworks

Minto argues there is no real need for a section called “Issues” in a consulting proposal. The issues, the process, and the end products of the study all turn out to be the same thing. The issues derive from the analytical process — which is the diagnostic framework. Sections of Key Issues in consulting documents are almost always confused re-statements of either the diagnostic frameworks or the logic trees.

Key Takeaways

  1. Gathering data first and organizing later is historically inefficient — structure the analysis before gathering data.
  2. The Opening Scene of the Problem Definition Framework implies which diagnostic frameworks you need to develop.
  3. There are three ways to build diagnostic frameworks: show physical structure, trace cause-and-effect, and classify possible causes.
  4. Diagnostic frameworks work through yes/no questions — these are the “crucial experiments” that unambiguously include or exclude hypotheses.
  5. Logic trees differ from diagnostic frameworks: diagnostic frameworks identify causes; logic trees generate possible solutions.
  6. Logic trees must be MECE — mutually exclusive and collectively exhaustive — to be useful for either generating solutions or revealing flaws.
  7. Logic trees can also reveal logical flaws in lists of “key issues” already written — diagramming issues against the problem structure exposes non-sequiturs.
  8. A true “issue” demands a yes/no answer; most consulting “issue lists” are actually concerns or process steps, not genuine issues.
  9. Issue Analysis was a specific McKinsey technique from the 1960s; its meaning has been diluted by overuse to the point of confusion.
  10. Deep domain knowledge is always required — there is no substitute for expertise in the subject area where the problem occurred.
  11. Administrative benefits of pre-structuring the analysis: you can assign data sources, responsibilities, schedules, and cost estimates before work begins.
  12. All groupings of ideas in a final document must trace back to one of the analytical structures built during diagnosis; this is how you verify logical validity.
  • ch08-defining-the-problem — The Opening Scene from the Problem Definition Framework implies which diagnostic frameworks to build
  • ch06-imposing-logical-order — The three ways to structure ideas (divide, cause-effect, classify) are the same three techniques used to build diagnostic frameworks
  • ch07-summarizing-grouped-ideas — Logic trees reveal whether grouped ideas in a document have a valid analytical origin

Graph View

Backlinks