Chapter 1

Chapter 1: Building Your Toolkit - From Framework Knowledge to Analytical Judgement

Learning Objectives

By the end of this chapter, you should be able to:

explain the difference between knowing a framework and using it well;
define the question an analytical tool must answer;
identify the major characteristics of a case;
select tools based on the decision rather than habit;
distinguish diagnostic, generative, evaluative, and implementation tools;
determine when a framework adds value and when it doesn't;
combine frameworks without duplicating analysis;
adapt tools to the available evidence and time;
build a personal toolkit organised around questions rather than framework names;
explain how analytical judgement strengthens a case recommendation.

Why This Matters

Every experienced case competitor develops a personal toolkit. Some tools help teams understand:

customers;
markets;
external trends;
competitors;
industries;
organisational capabilities;
operations;
financial performance;
stakeholder interests.

Other tools help teams:

identify root causes;
generate strategic alternatives;
evaluate options;
test assumptions;
estimate financial outcomes;
manage risk;
plan implementation;
support change;
communicate persuasively.

The range of tools available can create the impression that better case solving means learning more frameworks. It doesn't. Winning teams are rarely the ones that use the most frameworks; they identify the few questions that matter most and select the tools that help answer them. A team can complete six frameworks and still misunderstand the problem. Another team may use only two analytical tools but reach a stronger recommendation because those tools:

address the central decision;
use the available evidence;
reveal an important insight;
connect logically;
influence the solution.

A framework's value doesn't come from completing it. It comes from the decision it helps you make.

Discover Your MAD Skills Principle

Choose the question before you choose the framework.

Don't begin with: "Which frameworks should we use?" Begin with:

What decision must be made?
What do we not yet understand?
What evidence do we need?
What assumption must we test?
What could change our recommendation?

Then select the tool. A useful analytical progression is Decision → Question → Evidence → Tool → Insight → Strategic Implication. The tool sits in the middle of the process. It is neither the beginning nor the conclusion.

Knowledge Versus Judgement

Knowledge means knowing:

the names of frameworks;
their categories;
their definitions;
their steps;
the situations in which they are commonly used.

Judgement means knowing:

which question matters;
which tool fits that question;
how deeply to use it;
which parts of the tool are relevant;
what evidence supports the analysis;
how the insight connects to the decision;
when to stop analysing.

The Mix of Knowledge and Judgement

· A knowledgeable student may be able to define Porter's Five Forces.

· A case solver with judgement knows whether industry structure is relevant to the problem, and which two forces deserve the most attention.

· A knowledgeable student may be able to complete a SWOT analysis.

· A case solver with judgement knows that SWOT should synthesise prior analysis and lead to strategic implications.

· A knowledgeable student may understand the Business Model Canvas.

A case solver with judgement knows which blocks will change under the recommendation and whether the model remains desirable, feasible, and financially viable. Knowledge gives you options. Judgement tells you which option to use.

Frameworks Don't Think for You

Frameworks organise thinking; they don't replace it. A framework can help you:

divide a complex situation into manageable parts;
remember important questions;
organise evidence;
identify relationships;
compare alternatives;
expose gaps;
communicate an insight.

A framework cannot determine automatically:

which evidence is most important;
whether an assumption is reasonable;
what the root cause is;
which stakeholder should be prioritised;
whether a strategy fits the organisation;
which recommendation should be selected.

Those decisions require interpretation and judgement. A framework is a structure for asking better questions, not a machine for producing answers.

Begin with the Decision

Before selecting any analytical tool, define the decision the organisation faces. A case may contain dozens of facts, symptoms, concerns, and opportunities. Not all of them deserve equal attention. Ask what the organisation must decide. Examples might include:

Should the company enter a new market?
How should it respond to declining profitability?
Which customer segment should it prioritise?
Should it launch the proposed product?
How should it redesign an underperforming operation?
Which growth strategy should it pursue?
How should it implement a digital transformation?
Should it build, buy, or partner for a capability?
How should it balance financial, social, and environmental objectives?

A clear decision focuses the analysis. Without it, teams often gather information without knowing why it matters.

Decision Versus Topic

A topic is not the same as a decision.

Topic	Decision
International expansion	Should the company enter Germany, and if so, through which entry model?
Digital transformation	Which customer process should the company digitise first?
Sustainability	How should the company reduce packaging emissions without damaging affordability?
Declining sales	Which customer segment and value proposition should the company prioritise to restore growth?
Employee turnover	What changes should the organisation make to improve retention in critical roles?

The more clearly the decision is defined, the easier it becomes to select relevant tools.

Define the Analytical Question

Once the decision is clear, identify what the team must understand before it can make that decision. For a market-entry decision, the team may need to understand:

Is the market attractive?
Which customers should be targeted?
What do those customers value?
How intense is competition?
What barriers exist?
Does the organisation have the necessary capabilities?
What entry model is most feasible?
What investment is required?
What risks must be managed?

Each question may require a different tool.

Analytical question	Possible tool
What external trends are changing the market?	PESTLE
How attractive is the industry?	Porter's Five Forces
What do customers value?	Customer Analysis, Personas, Jobs to Be Done
Where does the organisation create value?	Value Chain Analysis
Which capabilities may create advantage?	VRIO
How does the business model fit together?	Business Model Canvas
Is the organisation aligned to execute?	McKinsey 7S
Who can influence implementation?	Stakeholder Analysis
What do the strategy's costs and returns look like?	Financial Analysis
Which option is strongest?	Decision Matrix or weighted criteria
How should uncertainty be managed?	Scenario, Sensitivity, and Risk Analysis

The table is a guide, not an automatic formula. The case's characteristics, the evidence, the decision, and the available time should determine the final choice.

Deciphering Case Characteristics

Before choosing a framework, identify the case's characteristics. Ask:

Is this primarily a growth challenge?
Is profitability declining?
Is the organisation considering market entry?
Is customer behaviour changing?
Is innovation required?
Is the problem primarily operational?
Is implementation the greatest challenge?
Is the external environment changing rapidly?
Is competitive pressure increasing?
Is organisational capability a major issue?
Is stakeholder management critical?
Is sustainability central to the decision?
Is the organisation changing?
Is the problem strategic, operational, financial, organisational, or some combination?
How much uncertainty exists?
How much time does the team have?
What evidence is available?

These questions help identify the type of analysis required.

Growth Cases

Growth cases may require teams to examine:

customer segments;
market size;
market attractiveness;
competition;
capabilities;
channels;
business-model implications;
investment;
implementation.

Useful tools may include:

TAM–SAM–SOM;
Customer Analysis;
PESTLE;
Five Forces;
Ansoff Matrix;
VRIO;
Business Model Canvas;
Financial Analysis.

A growth case doesn't require every growth framework. The real question may be whether the organisation can serve a specific customer segment profitably, not how large the entire market is.

Profitability Cases

Profitability cases may require teams to understand:

revenue changes;
cost changes;
customer and product profitability;
price;
volume;
mix;
operational performance;
competitive pressure.

Useful tools may include:

profitability trees;
contribution-margin analysis;
break-even analysis;
customer or product segmentation;
Value Chain Analysis;
benchmarking;
Five Forces.

A declining profit margin doesn't automatically mean the organisation should reduce costs. The cause may be pricing, customer mix, product mix, supplier power, or weak differentiation.

Operational Cases

Operational cases may require teams to examine:

process flow;
capacity;
bottlenecks;
quality;
inventory;
technology;
labour;
handoffs;
performance measures.

Useful tools may include:

Value Chain Analysis;
process mapping;
bottleneck analysis;
root-cause analysis;
capacity analysis;
cost analysis.

Organisational Cases

Organisational cases may focus on:

leadership;
culture;
structure;
systems;
skills;
staffing;
incentives;
change readiness.

Useful tools may include:

McKinsey 7S;
stakeholder analysis;
force-field analysis;
change-management models;
organisational-design analysis;
capability-gap analysis.

Innovation Cases

Innovation cases may require teams to understand:

unmet customer needs;
problem–solution fit;
business-model uncertainty;
technology;
competitive response;
experimentation.

Useful tools may include:

Jobs to Be Done;
Design Thinking;
Lean Canvas;
Business Model Canvas;
Blue Ocean Strategy;
assumption mapping;
prototyping;
pilot design.

Stakeholder-Intensive Cases

Public-sector, healthcare, education, sustainability, and community-impact cases may require teams to examine:

competing interests;
rights and responsibilities;
power;
legitimacy;
ethical trade-offs;
public value;
implementation support.

Useful tools may include:

Stakeholder Analysis;
ethical decision frameworks;
materiality assessment;
sustainability analysis;
change management;
risk analysis.

Most cases have more than one characteristic. The purpose of identifying the characteristics is not to place the case in a single rigid category. It is to recognise which questions require the greatest attention.

The Four Jobs of a Tool

Tools in your toolkit generally perform one or more of four jobs.

1. Diagnostic Tools: Understand the Situation

Diagnostic tools help answer:

What is happening?
Why is it happening?
What matters most?
Where is the problem?
What is changing?

Examples include:

PESTLE;
Porter's Five Forces;
SWOT;
Value Chain Analysis;
financial analysis;
root-cause analysis;
customer analysis;
McKinsey 7S;
Stakeholder Analysis.

2. Generative Tools: Develop Possible Solutions

Generative tools help answer:

What could the organisation do?
What different strategic directions exist?
How might we redesign the model?
What has not yet been considered?

Examples include:

TOWS;
Ansoff Matrix;
Design Thinking;
Blue Ocean Strategy;
Business Model Canvas;
brainstorming;
scenario development.

3. Evaluative Tools: Compare and Select

Evaluative tools help answer:

Which option is strongest?
What criteria matter?
What are the trade-offs?
Which option provides the best balance of value, feasibility, risk, and return?

Examples include:

decision matrices;
weighted criteria;
financial evaluation;
feasibility analysis;
risk analysis;
capability-fit assessment;
stakeholder-impact assessment.

4. Implementation Tools: Make the Strategy Happen

Implementation tools help answer:

What must change?
Who is responsible?
What resources are required?
What happens first?
How will risk and resistance be managed?
How will success be measured?

Examples include:

McKinsey 7S;
stakeholder engagement plans;
change-management frameworks;
implementation road maps;
responsibility matrices;
risk registers;
pilot design;
performance dashboards.

Some tools perform more than one job. For example, the Business Model Canvas can diagnose the current model, generate a model, and test whether the recommendation fits together. The important question is what job you need the tool to perform.

Build an Analytical Chain

Individual frameworks become more powerful when their findings connect. For example: PESTLE identifies new environmental regulation → Five Forces shows that compliance costs may increase barriers to entry → Value Chain Analysis identifies the activities that must change → VRIO determines whether the organisation has a relevant capability → Business Model Canvas shows how the solution changes partners, activities, costs, and value → McKinsey 7S identifies organisational requirements → Stakeholder Analysis identifies the support needed for implementation. This is not an instruction to use seven frameworks. It demonstrates that each tool answers a different question. A shorter chain might be enough: Customer Analysis identifies an underserved need → VRIO confirms the organisation has a relevant capability → Financial Analysis tests whether serving the segment is attractive. The number of tools matters less than the strength of the connections.

Framework Stacking Versus Framework Collecting

· Framework collecting means completing several tools without connecting their findings.

· Framework stacking means selecting tools that answer related questions and build toward the decision.

A weak case analysis might contain:

a PESTLE slide;
a SWOT slide;
a Five Forces slide;
a Value Chain slide; and
a recommendation

with no clear relationship among them. A stronger analysis might show: Demand is shifting toward convenient digital service → customers are dissatisfied with current response times → the organisation possesses valuable customer data but lacks integrated systems → a focused digital-service pilot is therefore more credible than full automation. Each analytical step contributes to the recommendation.

Avoid Duplicate Analysis

Several frameworks may reveal similar information. For example:

PESTLE may identify an external regulatory trend.
SWOT may classify it as a threat.
The Five Forces may show how it raises barriers to entry.
Stakeholder Analysis may identify the regulator's influence.
Risk Analysis may address the possibility of non-compliance.

Don't repeat the same fact as if it were five separate insights. Instead, decide what each tool contributes. A connected statement might be: New regulation creates a compliance threat, but it may also increase entry barriers. Early engagement with the regulator and investment in compliance capability could therefore reduce risk while strengthening the company's competitive position. One fact has been interpreted through several useful lenses without being repeated across several disconnected slides.

Depth Versus Breadth

Teams often believe that analysing more categories produces a more complete solution. Under time pressure, the opposite may happen. Using too many tools can create:

shallow analysis;
duplicated findings;
conflicting conclusions;
excessive slide content;
weak prioritisation;
less time for financials, implementation, and practice.

A focused analysis should go deeply enough to influence the decision. For example, instead of listing ten PESTLE factors, identify the two external forces that materially affect the strategy. Instead of rating all five industry forces with equal attention, explain the two pressures that shape profitability. Instead of listing every stakeholder, focus on the stakeholder relationships that could change or stop implementation. The goal is not analytical completeness. The goal is decision relevance.

The Evidence Test

A framework is only as strong as the evidence placed inside it. For every important conclusion, ask:

What evidence supports this?
Is the evidence contained in the Case?
Is it based on external research?
Is it a calculation?
Is it a reasonable inference?
Is it an assumption?
How confident are we?
What would change our conclusion?

Teams should distinguish among:

· Facts: Directly supported by the case, data, research, or calculation.

· Inferences: Reasonable conclusions drawn from available evidence.

· Assumptions: Claims accepted temporarily because evidence is unavailable.

· Hypotheses: Possible explanations or ideas that require testing.

This distinction matters. A team may hypothesise that younger customers will adopt a new service. It should not present that belief as a proven fact. When evidence is limited, the recommendation may need:

a pilot;
customer testing;
sensitivity analysis;
scenario planning;
additional research;
a decision trigger.

Frameworks should expose uncertainty, not hide it.

The "So What?" Test

Every analytical finding should answer: So, what does this mean for the decision? For example:

· Observation: Interest rates are high.

· So What? The organisation's debt-financed expansion would be more expensive and may fail to meet its return threshold.

· Strategic implication: Phase the expansion, reduce the initial capital requirement, or consider partnership financing.

The analytical chain becomes: Evidence → Interpretation → Strategic implication. If a finding has no strategic implication, ask whether it deserves time or presentation space.

The "What Would Change?" Test

A useful tool should change something. Ask what would change in our recommendation if this analysis produced a different result? If the answer is "nothing," the analysis may not be decision-relevant. For example:

If market demand were half the estimate, would the recommendation change?
If the organisation lacked the required capability, would the entry strategy change?
If customer willingness to pay were lower, would the revenue model change?
If the regulator opposed the model, would implementation change?
If the largest supplier withdrew, would the strategy remain feasible?

This test helps distinguish essential analysis from decorative analysis.

Tool Selection Under Time Pressure

The available time should influence how the team uses its toolkit. A six-hour case and a 24-hour case should not contain the same depth of analysis.

In a Short Case

Prioritise:

the decision;
the root cause;
the most important customer or market evidence;
essential financial analysis;
two or three viable alternatives;
a clear recommendation;
key implementation requirements; and
major risks.

Use frameworks selectively.

In a Longer Case

The team may have time to:

conduct deeper research;
compare segments;
test scenarios;
build more detailed financial models;
examine stakeholder implications;
assess organisational capability;
develop implementation depth.

More time doesn't justify using every framework. The additional analysis should improve confidence, specificity, and strategic depth.

A Practical Time Test

Before using a tool, ask:

What question will it answer?
How important is that question?
What evidence do we have?
How long will the analysis take?
What decision could it change?
Is there a faster or clearer way to answer the question?

If the tool consumes significant time without influencing the decision, stop.

Frameworks Are Flexible

A framework is not a form that must always be completed in full. You may use:

only the two PESTLE factors that matter;
three priority stakeholders rather than fifteen;
the most important parts of the Value Chain;
selected Business Model Canvas blocks;
the two 7S gaps preventing implementation; or
one VRIO capability that shapes the strategy.

Adapting a framework is not the same as using it incorrectly. It demonstrates judgement, given the team doesn't omit something essential simply because it is inconvenient.

When Not to Use a Framework

Sometimes the best analytical choice is not to use a named framework. A clear calculation, causal chain, comparison table, customer insight, or process map may answer the question more directly. For example:

a margin bridge may explain declining profitability better than a SWOT;
a customer funnel may explain weak conversion better than PESTLE;
a process map may reveal an operational bottleneck better than Five Forces;
a simple comparison of alternatives may be clearer than a complex matrix;
A cause-and-effect chain may convey the insight more clearly than a full framework diagram.

Frameworks should improve clarity. They should not make a simple question appear more complicated.

Building Your Personal Toolkit

A useful personal toolkit should be organised around the questions you need to answer, not only the names of the tools.

Understanding the Situation

What is the decision?
What is happening?
What has changed?
What is the root cause?
Who is affected?
What does the customer value?

Understanding the External Environment

What broad trends matter?
How is the industry changing?
Where does competitive pressure come from?
What opportunities or threats are emerging?

Understanding the Organisation

Where is value created or lost?
What resources and capabilities exist?
Which capabilities may create advantage?
How does the business model work?
Is the organisation aligned to execute?
Which stakeholders matter?

Developing Solutions

What strategic alternatives exist?
How could the business model change?
What capabilities are required?
What could be built, bought, borrowed, or partnered for?
What assumptions must be tested?

Evaluating Alternatives

Which criteria matter?
What are the financial outcomes?
Is the option desirable, feasible, and viable?
What are the risks and trade-offs?
Does the option fit the organisation?
How will stakeholders respond?

Implementing the Strategy

What must happen first?
Who owns each action?
What resources are required?
What organisational changes are needed?
How will people be supported?
What risks must be managed?
How will success be measured?

Communicating the Solution

What must the audience understand?
What evidence supports the argument?
What belongs in the presentation?
What belongs in the appendix?
What questions are likely?
How can the message be delivered clearly?

Over time, add tools to each question category. This creates a practical system for retrieval under pressure.

Build a Tool Card

For each framework in your personal toolkit, create a short tool card. Include:

Tool-card element	Question
Purpose	What does this tool help me understand?
Best used when	What Casee characteristics make it relevant?
Inputs	What evidence does it require?
Process	How do I use it?
Output	What insight should it produce?
Connection	Which other tools might it inform?
Common mistake	How is it usually misused?
Presentation use	What part, if any, belongs in the deck?

For example: Porter's Five Forces

· Purpose: Understand the structural pressures affecting industry profitability.

· Best used when: The case concerns market entry, competitive strategy, pricing pressure, or industry attractiveness.

· Inputs: Competitor information, customer concentration, supplier structure, entry barriers, substitutes, growth, switching costs, and cost structure.

· Output: The forces most affecting profitability and the strategic response available to the organisation.

· Common mistake: Rating the forces without explaining what creates the pressure.

· Presentation use: Show only the forces and implications that materially influence the recommendation.

A tool card makes the framework easier to use under competition pressure.

Build the Toolkit Through Reflection

Your toolkit should evolve through experience. After each case, ask:

Which tools did we use?
Which tool produced the strongest insight?
Which analysis did not affect the recommendation?
What did we overlook?
Did we confuse a symptom with a cause?
Did we use a framework out of habit?
Which assumption needed more testing?
What would we do differently next time?
Which tool should be added to our toolkit?
Which tool do we need to practise using more deeply?

Reflection converts case experience into judgement. Without reflection, teams may repeat the same analytical habits even after completing many cases.

Coach's Lens

I have seen teams spend valuable time completing a framework because they believed judges expected to see it. That is backwards. Judges don't award marks because a team included a SWOT, PESTLE, or Five Forces diagram. They respond to:

relevant insight;
sound reasoning;
evidence;
strategic choices;
financial credibility;
implementation depth;
clarity.

The question is not which framework will impress the judges; it is which question must we answer to make a credible recommendation. Then choose the simplest useful tool. A framework should disappear behind the insight it creates.

Common Mistakes

· Starting with the Framework: Teams choose a familiar tool before defining the problem. Define the decision and the analytical question first.

· Using Frameworks as Checklists: The team fills every category whether it matters or not. Focus on the elements that influence the decision.

· Using Too Many Tools: Breadth replaces depth. Select the smallest set of tools that answers the critical questions.

· Repeating the Same Insight: The same fact appears in several frameworks without new interpretation. Clarify what each tool contributes to the analytical chain.

· Treating Framework Output as the Answer: Completing a matrix doesn't produce a recommendation. Translate every important finding into a strategic implication.

· Forcing the Case into the Tool: The framework shapes the analysis more than the evidence does. Adapt the framework to the situation.

· Ignoring Evidence Quality: Teams place assumptions into frameworks as if they were proven facts. Clearly label facts, inferences, assumptions, and hypotheses.

· Analysing Everything Equally: Not every category, stakeholder, competitor, or capability matters. Prioritise equally based on decision relevance and potential impact.

· Ignoring the Available Time: Teams begin an analysis they cannot complete or use. Match the depth of analysis to the decision, evidence, and competition format.

· Showing Every Framework: The presentation becomes a record of the team's process rather than an argument. Present the insight, not every tool used to develop it.

· Using a Named Framework When a Simpler Tool Is Clearer: Complexity is mistaken for sophistication. Use a calculation, causal chain, process map, or comparison when it communicates the answer more directly.

· Failing to Reflect: Teams complete cases without improving their analytical habits. Conduct a brief toolkit review after every practice and competition.

MAD Skills Drill

Consider the following case question: A regional service company is experiencing declining profitability and is considering entering a new customer segment.

Step 1: Define the Decision

Rewrite the case question as a specific decision. For example: Should the company enter the institutional customer segment to restore profitable growth?

Step 2: Identify the Unknowns

List the five things you most need to understand before making the decision. These might include:

the cause of declining profitability;
the needs of institutional customers;
the attractiveness of the segment;
the organisation's relevant capabilities;
the financial implications of entry.

Step 3: Select the Tools

Choose no more than three primary tools. For each tool, explain:

what question it answers;
what evidence it requires;
what output it should produce; and
how the result could change the recommendation.

Step 4: Build the Analytical Chain

Show how the tools connect. For example: Profitability Analysis identifies the source of decline → Customer and Market Analysis tests the institutional opportunity → VRIO evaluates whether the company has the capabilities to enter successfully

Step 5: Remove One Tool

Remove the least important tool. Ask:

What insight would be lost?
Could that question be answered more simply?
Would the recommendation become less credible?

This step forces prioritisation.

Step 6: Decide What the Judges Need to See

Determine:

which insight belongs in the main presentation;
which analysis belongs in the appendix; and
which work doesn't need to appear at all.

Step 7: Deliver the Rationale

Prepare a 60-second explanation answering:

What is the decision?
What are the most important unknowns?
Which tools will you use?
Why do those tools fit?
How will their findings connect to the recommendation?

Don't define the frameworks. Explain why they are necessary.

Chapter Summary

A strong case-solving toolkit is not a large collection of memorised frameworks. It is a system for selecting and applying the right tool to the right question. Strong analytical judgement follows this progression: Decision → Question → Evidence → Tool → Insight → Strategic implication. Begin by defining the decision. Identify the case characteristics and the questions that must be answered. Select the smallest, useful combination of diagnostic, generative, evaluative, and implementation tools. Use frameworks deeply enough to create insight, but selectively enough to preserve time for:

alternative development;
financial analysis;
implementation;
risk;
presentation design;
practice.

A weak case solver asks: "Which frameworks do I know?" A strong case solver asks: "What must I understand, and which tool will help me understand it?"

Key Takeaways

✓ A personal toolkit should be organised around questions and decisions, not only framework names.

✓ Framework knowledge gives you options; analytical judgement tells you which option to use.

✓ Define the decision before choosing a tool.

✓ Identify the characteristics of the case to determine which questions deserve attention.

✓ Diagnostic tools explain the situation, generative tools develop possibilities, evaluative tools compare options, and implementation tools turn the strategy into action.

✓ Frameworks organise thinking but don't replace evidence, interpretation, or judgement.

✓ Use the smallest combination of tools capable of answering the critical questions.

✓ Connect tools into an analytical chain rather than presenting disconnected frameworks.

✓ Avoid duplicating the same finding across several tools.

✓ Apply the "so what?" test to every important insight.

✓ Apply the "what would change?" test to determine whether an analysis is decision-relevant.

✓ Distinguish facts, inferences, assumptions, and hypotheses.

✓ Adapt analytical depth to the available time and evidence.

✓ Use only the parts of a framework that add value to the decision.

✓ A simple calculation, causal chain, comparison, or process map may be more useful than a named framework.

✓ Present the insight created by the tool, not a record of every framework the team completed.

✓ Reflect after each case so experience becomes judgement.

Looking Ahead

With the foundation of your toolkit established, Part II turns to the thinking skills that allow you to use those tools effectively. The next chapters examine how case solvers:

question assumptions;
interpret evidence;
identify patterns;
distinguish symptoms from causes;
think critically and creatively;
make decisions under uncertainty; and
develop stronger strategic insight.

The frameworks in this manual will give you structure. The thinking skills in Part II will help you use that structure with judgement.