client-deliverables ยท diff
git:20260320.065d38e to v2.1.0
137 added, 660 removed. Audit A to A.
---
name: client-deliverables
- description: Create consulting-grade client deliverables (written reports and executive presentations). Use when producing strategic assessments, board decks, due diligence reports, steering committee updates, recommendation documents, PE IC memos, or any formal analysis requiring structured narrative (SCQA/SCR), evidence-based argumentation, data visualization, audience adaptation, and professional formatting. Covers both written and slide-based formats.
+ description: Produces consulting-grade client deliverables (written reports and executive presentations) built on structured narrative (SCQA/SCR), the pyramid principle, action-titled sections, and evidence-backed recommendations. Use when creating strategic assessments, board decks, due diligence reports, PE investment committee (IC) memos, steering committee updates, recommendation documents, or any formal analysis that must drive an executive decision. Covers storylining, audience adaptation, exhibit design, and the choice between a document and a deck.
+ license: MIT
+ metadata:
+ category: communication
+ version: "2.1.0"
+ author: Anot
---
# Client Deliverables
- Produce formal consulting deliverables that communicate complex analysis with clarity and impact. This covers deliverable creation during and after consulting engagements, including both written reports and executive presentations. For pitch decks and proposals aimed at winning work, see proposal-development. Structure everything for decision-makers: bottom-line up front, evidence-backed findings, actionable recommendations, professional formatting.
+ Formal consulting deliverables that carry a complex analysis to a decision. This covers work produced during and after an engagement, in two formats: written reports and executive presentations. For pitch decks and proposals aimed at winning work, use proposal-development instead.
+ The discipline is constant across both formats. Lead with the answer. Back every finding with traceable evidence. Structure the argument top-down so a busy reader reaches the recommendation already understanding why it holds.
+
## Before You Begin
- Deliverables carry the firm's credibility. Every number and finding must be traceable. Before drafting:
- - What is the deliverable's purpose and who is the audience?
- - What decision does this deliverable enable?
- - What format is required (written report, presentation deck, leave-behind, or some combination)?
- - What analysis has been completed and what data is available to support findings?
- - Don't fabricate data points, source citations, benchmark figures, or case study results. When illustrative numbers are needed to demonstrate a format, label them clearly as examples. If specific numbers aren't available, use placeholders and flag them: "This needs [specific data]. Showing a placeholder based on [typical range]."
+ Deliverables carry the firm's credibility. Every number must trace to a source. Settle four things before drafting:
- ---
+ - Purpose and audience: who reads this, and what do they already believe?
+ - The decision: what choice does this deliverable enable?
+ - Format: written report, deck, leave-behind, or a combination (see "Document or Deck" below).
+ - Evidence base: what analysis is done, and what data actually supports the findings?
- ## Part 1: Common Methodology
+ Do not fabricate data points, citations, benchmark figures, or case results. When you need an illustrative number to show a format, label it: "Example, validate before use." When a real number is missing, use a placeholder and flag it: "Needs [specific data]. Placeholder based on [typical range]." Present any benchmark with its source and context. An unsourced benchmark invites challenge and erodes the whole document.
- These principles apply to both written reports and presentations.
+ ## Document or Deck
- ### Structured Narrative: SCQA / SCR
+ This is the first real decision, and people get it wrong constantly. The wrong format wastes days.
- The same narrative logic underpins both formats. Reports use SCQA (Situation-Complication-Question-Answer). Presentations use the compressed SCR variant (Situation-Complication-Resolution). The difference is that presentations drop the explicit "Question" because it's implied by the complication, and the spoken format needs momentum.
+ Choose a **written report** when the argument has dependencies that need prose to hold together, when the reader will engage alone and asynchronously, when the analysis must survive scrutiny months later, or when regulators or an IC expect a document of record. Reports carry nuance, caveats, and a full evidence trail.
+ Choose a **deck** when the deliverable exists to drive a decision in a room, when you will be present to narrate, or when the audience wants the argument in visual chunks they can react to live. Decks compress. They trade completeness for momentum.
+
+ The failure mode is the hybrid nobody asked for: a "deck" that is really a report crammed into slides (walls of text at 12pt, forwarded and unreadable) or a "report" that is a thin string of bullet fragments. If a single artifact must do both jobs, build one primary format well and bolt on the other deliberately: a deck with a genuine 1-page standalone executive summary, or a report with a 10-slide spoken summary (template in the presentations reference).
+
+ Rough sizing:
+
+ | Signal | Lean Report | Lean Deck |
+ |---|---|---|
+ | Reader is present when it lands | No | Yes |
+ | Argument has many interlocking parts | Yes | No |
+ | Must be defensible in 6 months | Yes | Sometimes |
+ | Decision needed in a live meeting | No | Yes |
+ | Audience reads alone, on their own time | Yes | No |
+
+ When genuinely unsure, draft the executive summary first (one page). If it stands on its own, you may not need the rest at deck length.
+
+ ## Storylining: SCQA and SCR
+
+ Both formats run on the same narrative spine. Start with what the reader already accepts, introduce the tension, resolve it. The reader arrives at the recommendation understanding why it matters, so the recommendation reads as inevitable rather than asserted.
+
+ Reports use the full **SCQA**. Presentations use the compressed **SCR**, which drops the explicit Question (the Complication implies it) because a spoken format needs to move.
+
```
- SITUATION -> "This is where we are..."
- | (Establish context the reader/audience already agrees with)
+ SITUATION -> "Here is where we are."
+ | Context the reader already agrees with.
v
- COMPLICATION -> "This is the problem..."
- | (What's changed, what's at risk, what's broken)
+ COMPLICATION -> "Here is what changed or broke."
+ | What is now at risk, and what it costs.
v
- QUESTION -> "This is what we must answer..." [Reports]
- | (The central question the report addresses)
+ QUESTION -> "So what must we decide?" [Reports only]
+ | The single question the deliverable answers.
v
- ANSWER / -> "This is what we recommend..."
- RESOLUTION (The recommendation, stated clearly)
+ ANSWER / -> "Here is what we recommend."
+ RESOLUTION The recommendation, stated flat.
```
- SCQA/SCR works because it mirrors how people process information: start with what they know, introduce the tension, then answer it. The reader/audience arrives at the recommendation already understanding why it matters.
+ Build the Situation from facts the audience will nod at. If they argue with your Situation, you have lost the room before the Complication. Make the Complication cost something concrete: a number, a deadline, a competitor moving. That tension is what earns attention for the Answer.
### The Pyramid Principle
- Every deliverable follows top-down logic, whether it's a 5-page brief or a 50-slide strategy deck.
+ Every deliverable runs top-down, whether it is a 5-page brief or a 50-slide strategy deck.
```
+---------------+
- | Answer | <- State this first
+ | Answer | <- State this first.
+-------+-------+
+------------+------------+
- +-----+-----+ +---+---+ +------+------+
- | Argument 1| | Arg 2 | | Argument 3 | <- 2-3 supporting reasons
- +-----+-----+ +---+---+ +------+------+
- +---+---+ +--+--+ +----+----+
- |E1 |E2 | |E3|E4| |E5 |E6 | <- Evidence for each
- +---+---+ +--+--+ +----+----+
+ +-----+-----+ +----+---+ +------+------+
+ | Argument 1| | Arg 2 | | Argument 3 | <- 2-3 supporting reasons (MECE).
+ +-----+-----+ +----+---+ +------+------+
+ +---+---+ +--+--+ +----+----+
+ |E1 |E2 | |E3|E4| |E5 |E6 | <- Evidence under each.
+ +---+---+ +--+--+ +----+----+
```
- **The Answer** (top of the pyramid): One sentence that is the main point. If the audience remembers nothing else, they remember this.
-
- **Supporting Arguments** (2-3 maximum): The reasons why your answer is true. Each must be mutually exclusive and collectively exhaustive (MECE).
-
- **Evidence** (per argument): Data, examples, case studies that support each argument. Every fact must connect back to the argument above it.
+ - **The Answer** is one sentence. If the audience remembers nothing else, this is it.
+ - **Supporting arguments** are 2-3, no more. They must be mutually exclusive and collectively exhaustive (MECE): no overlap, no gaps.
+ - **Evidence** sits under each argument. Every fact connects to the argument directly above it. A fact that supports nothing gets cut.
- This structure applies at every level: the deliverable as a whole, each section/slide, each paragraph/bullet.
+ Apply the pyramid at every level: the deliverable as a whole, each section or slide, each paragraph or bullet.
- ### Action Headlines and Titles
+ ### Action Headlines
- The single most impactful discipline in consulting deliverables. Every section heading (reports) and slide title (presentations) must be a complete sentence stating the takeaway, not a topic label.
+ The single highest-leverage habit in consulting deliverables. Every section heading (reports) and every slide title (presentations) is a complete sentence stating the takeaway, never a topic label.
- Bad: "Market Analysis"
- Good: "The addressable market has contracted 15% since 2023, driven by regulatory changes in three key segments"
+ - Bad: "Market Analysis"
+ - Good: "The addressable market has contracted 15% since 2023, driven by regulatory change in three segments."
+ - Bad: "Revenue Overview"
+ - Good: "Revenue fell 12% on mid-market churn, and the trend accelerated in Q3."
- Bad: "Revenue Overview"
- Good: "Revenue declined 12% driven by customer churn in the mid-market segment"
+ Read the headlines alone, top to bottom. They should tell the whole story with the exhibits removed. If you cannot write the action headline for a section, that section has no point yet. Fix the thinking, then write.
- If you can't write the action headline, the section or slide doesn't have a point yet.
+ ## Audience Adaptation
- ### Audience Adaptation
+ Who reads it changes what leads, what gets cut, and how much methodology survives.
| Audience | What They Want | How to Deliver |
- |----------|---------------|----------------|
- | CEO / Board | Decision, strategic implications, risk | Lead with recommendation, quantify impact, address key risks, connect to shareholder value |
- | CFO | Financial proof, ROI, assumptions | Detailed financials, sensitivity analysis, conservative estimates |
- | COO | Implementation feasibility, resources | Operational plan, resource requirements, timeline |
- | CTO | Technical viability, architecture | Technical assessment, scalability, integration requirements |
- | Steering Committee | Progress, decisions needed, blockers | Status against plan, decision items, escalations |
- | Mixed / Large Group | Alignment, clarity, next steps | Simple message, clear visuals, explicit ask |
+ |---|---|---|
+ | CEO / Board | The decision, strategic and risk implications | Lead with the recommendation, quantify impact, address the top risk, tie to shareholder value |
+ | CFO | Financial proof, ROI, assumptions | Detailed financials, sensitivity, conservative estimates |
+ | COO | Feasibility, resources | Operating plan, resource load, timeline |
+ | CTO | Technical viability | Architecture assessment, scalability, integration risk |
+ | Steering Committee | Progress, decisions, blockers | Status vs. plan, decision items, escalations |
+ | Mixed / Large Group | Alignment and a clear ask | One simple message, clean visuals, explicit next step |
- **Executive audiences**: Lead with the answer and impact. Minimize methodology (move to appendix or backup). Focus on decisions and trade-offs. Use visual summaries over dense text.
+ Three moves cover most cases:
- **Technical audiences**: Include methodology in detail. Show analytical work and assumptions. Use precise terminology (but still define specialized terms). Include sensitivity analysis.
+ - **Executive audiences**: answer and impact first. Push methodology to backup. Spend the airtime on decisions and trade-offs, not on how you did the work.
+ - **Technical audiences**: show the method, the assumptions, and the sensitivity. Use precise terms, but still define the specialized ones.
+ - **Mixed audiences**: progressive disclosure. Headline, then support, then full data at the back, so each reader stops where their interest ends.
- **Mixed audiences**: Structure with progressive disclosure. Headline finding, then supporting detail, then full data. Put methodology and technical detail at the back.
+ ## Exhibits and Data Storytelling
- ### Data Storytelling
+ An exhibit makes one point. If it makes two, split it. The reader should get the point from the title and the annotation without decoding the axes.
- - **Lead with the most compelling data point**: Don't bury the headline
- - **Annotate charts and exhibits**: Call out the insight, don't make readers find it
- - **Show change, not state**: Trends and deltas are more compelling than snapshots
- - **Use comparison**: "3x the industry average" lands harder than "15%"
- - **Connect to consequences**: Every number should answer "and that means..."
- - **Quantify the cost of inaction**: Makes the complication concrete
+ - Lead with the most compelling data point. Do not bury the headline inside a table.
+ - Show change, not state. A delta or trend lands harder than a snapshot.
+ - Use comparison to give scale. "3x the industry average" beats "15%."
+ - Connect every number to a consequence. Each figure should answer "and that means what?"
+ - Quantify the cost of inaction. It makes the Complication concrete.
- ### Chart Selection
+ Pick the chart from the relationship, not from habit:
- | Data Relationship | Recommended Chart |
+ | Data Relationship | Chart |
|---|---|
- | Comparison across categories | Bar chart (horizontal for many categories) |
- | Trends over time | Line chart |
- | Part-to-whole | Stacked bar, waterfall, or pie (sparingly) |
- | Correlation | Scatter plot |
+ | Comparison across categories | Bar (horizontal when many categories) |
+ | Trend over time | Line |
+ | Part-to-whole | Stacked bar or waterfall (pie sparingly, max 4-5 slices) |
+ | Correlation | Scatter |
| Distribution | Histogram or box plot |
- | Geographic | Map or choropleth |
- | Process or flow | Sankey diagram or flowchart |
- | Hierarchical | Treemap or org chart |
- | Sensitivity / driver ranking | Tornado chart |
- | Scenario comparison | Side-by-side bar or table with conditional formatting |
- | Financial bridges (revenue to EBITDA, cost drivers) | Waterfall chart |
-
- **Chart standards** (both formats):
- - Title states the finding, not just the topic
- - Include source notes
- - Highlight the key data point visually (bold, color, annotation)
- - Consistent color schemes throughout the deliverable
- - Remove chartjunk: unnecessary gridlines, 3D effects, decorative elements
- - Every chart should make exactly one point. If it makes two, split it
+ | Financial bridge (revenue to EBITDA, cost drivers) | Waterfall |
+ | Which variable matters most | Tornado |
+ | Scenario comparison | Side-by-side bar or conditional-format table |
- **Presentation-specific chart rules**:
- - One chart per slide, making one point
- - Annotate the insight directly on the chart
- - Avoid pie charts with more than 4-5 slices
- - Max 5 rows in any table shown during a live presentation. Move detail to backup slides.
+ Chart standards, both formats: the title states the finding; the source is noted; the key point is highlighted (bold, color, or a callout); colors stay consistent across the deliverable; chartjunk (3D, heavy gridlines, decoration) is removed. In a live deck, one chart per slide and no table over five rows. Detailed exhibit and chart-construction recipes live in the presentations reference.
- ### Sensitivity Analysis
+ ### Sensitivity, Handled Honestly
- When presenting financial projections with uncertainty, use these formats:
+ When projections carry uncertainty, show it rather than assert a single number. Two workhorses:
- **Tornado chart** (for identifying which variables matter most): List variables vertically, show NPV impact range horizontally. Order by magnitude of swing. The top 2-3 bars are where management attention belongs.
+ A **tornado chart** ranks variables by how much they swing the outcome. The top 2-3 bars are where management attention belongs.
```
- Variable | NPV Impact Range
- Adoption rate |=====[----BASE----]==========| +/- $12M
- Benefit timeline |=======[--BASE--]========| +/- $8M
- Implementation cost |========[-BASE-]======| +/- $5M
- Discount rate |=========[BASE]=====| +/- $3M
+ Variable | NPV Impact Range
+ Adoption rate |=====[----BASE----]==========| +/- $12M
+ Benefit timeline |=======[--BASE--]========| +/- $8M
+ Implementation cost |========[-BASE-]======| +/- $5M
+ Discount rate |=========[BASE]=====| +/- $3M
```
- **Scenario table** (for communicating overall risk profile):
-
- | Scenario | Key Assumptions | NPV | IRR | Payback | Probability |
- |----------|----------------|-----|-----|---------|-------------|
- | Upside | [2 key drivers] | $XX | XX% | X yrs | XX% |
- | Base | [2 key drivers] | $XX | XX% | X yrs | XX% |
- | Downside | [2 key drivers] | $XX | XX% | X yrs | XX% |
-
- Always state the break-even threshold: "The business case remains positive even if benefits are [X]% below plan."
-
- **Structure each scenario with:**
-
- | Element | Base Case | Upside | Downside |
- |---|---|---|---|
- | Key assumption | [Most likely] | [Optimistic] | [Conservative] |
- | Revenue/benefit impact | $X | $Y | $Z |
- | Probability weighting | 50-60% | 20-25% | 20-25% |
- | Trigger indicators | [What you'd see] | [What you'd see] | [What you'd see] |
-
- Include:
- - **Decision triggers**: "If [metric] falls below [threshold] by [date], shift to [alternative plan]"
- - **Sensitivity analysis**: Which 2-3 assumptions most affect the outcome? What happens if each moves +/- 20%?
- - **Break-even analysis**: At what point does the recommendation no longer hold?
+ A **scenario table** communicates the overall risk profile across base, upside, and downside, each with its two key drivers, its returns, and a probability weighting. Always state the break-even: "The case stays positive even if benefits land [X]% below plan." Any probability or weighting you assign without hard data is a directional estimate. Label it as one. Full scenario-table structure and decision-trigger templates are in the written-reports reference.
- ### Writing Standards
+ ## Writing Standards
- These apply to both prose in reports and text on slides (adapted for density).
+ These apply to prose in reports and to text on slides (denser on slides). This is where an AI tell hides, so hold the line.
| Element | Standard |
|---|---|
- | Sentence length | Max 25 words |
- | Paragraph length | Max 4 sentences (reports); bullets preferred (slides) |
- | Headlines/titles | Action-oriented complete sentences, not topic labels |
- | Numbers | Always quantify where possible |
- | Dates | Always specify, avoid "soon", "later", "in the near term" |
- | Names | Use full names for people and organizations |
- | Jargon | Avoid or define all technical terms |
-
- **Evidence standards:**
-
- | Type | Requirement |
- |---|---|
- | Data | Source, date, and methodology noted |
- | Quotes | Named sources, verified |
- | Benchmarks | Comparable sources cited |
- | Expert opinions | Named experts where possible |
- | Case studies | Specific examples with results |
+ | Sentence length | Vary it. Most under 25 words. Short ones to land a point. |
+ | Paragraph length | Max 4 sentences in reports; bullets on slides |
+ | Headlines | Complete-sentence takeaways, never topic labels |
+ | Numbers | Quantify wherever the data allows |
+ | Dates | Specify them; never "soon," "later," "in the near term" |
+ | Names | Full names for people and organizations |
+ | Jargon | Cut it or define it |
- **Voice:**
- - Active voice: "We recommend" not "It is recommended"
- - Be direct: avoid hedge words like "perhaps", "might", "may"
- - "We believe X because Y" is stronger than "X could potentially be considered"
+ Voice: active and committed. "We recommend" beats "It is recommended." Drop hedge words (perhaps, might, may) unless the uncertainty is real, in which case name it plainly. "We believe X because Y" is stronger than "X could potentially be considered."
- **Before/After: Bad vs. Good Consulting Prose**
+ **Before and after.** The pattern is always the same: replace throat-clearing with the conclusion, hedges with data, abstractions with specifics.
Vague and passive:
- > "It is believed that there may be potential opportunities for significant improvement in certain areas of the organization's operational processes, which could potentially lead to enhanced performance outcomes going forward."
+ > "It is believed that there may be potential opportunities for significant improvement in certain areas of operational processes, which could lead to enhanced performance outcomes going forward."
Direct and quantified:
- > "Three process changes will cut order fulfillment time from 14 days to 5 days, saving $2.3M annually in working capital costs."
-
- Hedge-laden:
- > "The market appears to be showing some signs of potential softening, which might suggest that a more cautious approach could perhaps be warranted in the near term."
-
- Clear and committed:
- > "The addressable market contracted 12% in Q3. We recommend delaying the product launch to Q2 2027 and reallocating $4M from marketing to R&D."
+ > "Three process changes cut order fulfillment from 14 days to 5, saving $2.3M a year in working capital."
Buried lead:
- > "After conducting an extensive analysis of the competitive landscape, examining market trends across multiple segments, and reviewing internal capability assessments, our team has concluded that the acquisition of TargetCo represents a compelling strategic opportunity."
-
- Bottom-line up front:
- > "Acquire TargetCo for EUR 85M. It fills our capability gap in APAC distribution and is accretive to EBITDA by Year 2. Three factors support this recommendation."
-
- The pattern: replace throat-clearing with the conclusion. Replace hedges with data. Replace abstractions with specifics.
-
- ### Quality Assurance
-
- Before finalizing any deliverable:
-
- - Executive summary / first slide stands alone (readable in 5 minutes, gives the complete picture)
- - Every finding has supporting evidence
- - Every recommendation has rationale
- - All numbers are sourced
- - All terms are defined
- - Formatting is consistent throughout
- - The conclusion matches the evidence
- - The deliverable answers the original question
- - Scenario analysis included for recommendations with significant uncertainty
- - Specific owners and dates for all recommended actions
- - When citing benchmarks or peer comparisons, flag the source explicitly. "Industry benchmarks suggest..." is weaker than "Per [Source/analysis], the benchmark is X." If no published source exists, say "based on our analysis" or "directional estimate based on [basis]." Unsourced benchmarks invite challenge and erode credibility.
-
- ---
-
- ## Part 2: Written Reports
-
- ### Report Types
-
- | Type | Purpose |
- |---|---|
- | Strategic assessment | Evaluate options and recommend direction |
- | Due diligence report | Investigate and validate claims or assumptions |
- | Implementation plan | Define how to execute a strategy |
- | Performance review | Assess results against targets |
- | Recommendations document | Present findings and proposed actions |
- | Status report | Communicate progress and issues |
- | PE investment committee memo | Present investment thesis for fund decision |
-
- ### Depth and Length Calibration
-
- Match report depth to audience and purpose. Not every analysis needs 30 pages.
-
- | Output Level | Word Count | When to Use |
- |---|---|---|
- | Executive brief | 500-800 words | Board-level summary, decision memo, time-pressed stakeholders |
- | Working report | 2,000-4,000 words | Standard client deliverable, recommendations with supporting analysis |
- | Deep-dive report | 4,000-8,000 words | Comprehensive strategic assessment, due diligence, regulatory submissions |
- | Full study | 8,000+ words | Multi-workstream transformation reports, market entry studies with appendices |
-
- When in doubt, write shorter. A 3,000-word report that gets read beats a 10,000-word report that doesn't.
-
- ### Tone Calibration
-
- - **Voice**: Expert, collaborative, or direct (match the client relationship)
- - **Technical level**: Executive summary, detailed, or technical
- - **Format**: Formal report, executive briefing, or working document
-
- ### Narrative Structures
-
- **SCQA (full version for written reports):**
- 1. Situation: establish context
- 2. Complication: what's changed or at risk
- 3. Question: the central question the report addresses
- 4. Answer: the recommendation, stated clearly
-
- **Answer-First Structure** (for audiences who want to cut to the chase):
- 1. **Executive Summary** ... full message here (someone who reads only this page gets the complete picture)
- 2. **The Question** ... what we were asked to address
- 3. **The Answer** ... our recommendation in brief
- 4. **Supporting Evidence** ... analysis section by section
- 5. **Required Actions** ... what needs to happen, by whom, by when
- 6. **Appendices** ... supporting detail
-
- ### Section Templates
-
- #### Executive Summary
-
- The executive summary is the most important section. It must stand alone.
-
- Structure:
- - **Bottom Line**: One paragraph stating the answer, the impact, and the recommendation
- - **Key Findings**: 3-5 findings, quantified where possible
- - **Recommendations**: Prioritized list
- - **Expected Outcomes**: Impact and timeline for each
- - **Next Steps**: Immediate actions required
-
- Write the executive summary last, after all analysis is complete.
-
- #### Analysis Sections
-
- Each analysis section follows the same pattern:
- - **Headline**: One sentence capturing the key finding (not a topic label)
- - **Supporting Evidence**: Data points with sources and implications
- - **Analysis**: Explanation of what the evidence means
- - **Implications**: What this means for the business
-
- #### Recommendation Sections
-
- Each recommendation needs:
- - **The Recommendation**: Clear statement of what should be done
- - **Rationale**: Why this is the right course of action
- - **Supporting Evidence**: Data that backs this up
- - **Impact**: Projected outcomes with current vs. projected metrics
- - **Risks and Mitigations**: What could go wrong and how to address it
-
- ### PE Investment Committee Memo
-
- Investment committee (IC) memos follow a rigid structure because the committee reviews multiple deals per meeting. Deviation from the expected format slows the decision.
-
- ```
- INVESTMENT COMMITTEE MEMORANDUM
-
- Company: [Target Name]
- Sector: [Industry / Sub-sector]
- Deal Type: [Buyout / Growth Equity / Add-on / Recapitalization]
- Enterprise Value: [Amount]
- Equity Check: [Amount]
- Target Close: [Date]
- Sponsor Coverage: [Deal Team Lead]
-
- 1. EXECUTIVE SUMMARY
- - Investment thesis in 3-4 sentences
- - Key return drivers
- - Headline returns: [X.X]x MOIC / [XX]% IRR over [X] year hold
-
- 2. COMPANY OVERVIEW
- - Business description, products/services, end markets
- - Revenue: $[X]M | EBITDA: $[X]M | EBITDA Margin: [X]%
- - Revenue mix (by product, geography, customer)
- - Customer concentration (top 10 customers as % of revenue)
- - Management team assessment
-
- 3. INVESTMENT THESIS
- - Thesis pillar 1: [Growth lever with quantified impact]
- - Thesis pillar 2: [Margin lever with quantified impact]
- - Thesis pillar 3: [Strategic lever with quantified impact]
-
- 4. MARKET & COMPETITIVE DYNAMICS
- - TAM/SAM sizing
- - Growth drivers and secular trends
- - Competitive positioning and moat assessment
-
- 5. FINANCIAL OVERVIEW & PROJECTIONS
- - Historical financials (3 years) with key metrics
- - Management case vs. sponsor case
- - Revenue bridge and EBITDA bridge
- - Working capital and capex requirements
-
- 6. DEAL STRUCTURE & RETURNS
- - Sources & uses
- - Capital structure and leverage ratios
- - Returns analysis: base / upside / downside
- - Key assumptions driving each scenario
-
- 7. KEY RISKS & MITIGANTS
- | Risk | Severity | Mitigant |
- |------|----------|----------|
- | [Risk 1] | [H/M/L] | [Specific mitigation] |
-
- 8. VALUE CREATION PLAN
- - 100-day plan priorities
- - Operational initiatives with timeline
- - M&A / add-on pipeline (if applicable)
-
- 9. EXIT CONSIDERATIONS
- - Likely exit paths (strategic sale, sponsor-to-sponsor, IPO)
- - Comparable exit multiples
- - Target exit timeline
-
- 10. RECOMMENDATION
- - Approve / Approve with conditions / Decline
- - Conditions or open items (if any)
- - Requested next steps
- ```
-
- **IC memo writing standards**: Be factual, not promotional. The committee's job is to find reasons NOT to invest. Anticipate their objections and address them directly. Management cases are always more optimistic than reality; show the sponsor case with conservative assumptions. Every number needs a source.
-
- ### Document Structure
-
- ```
- [Firm/Company Logo]
- [Report Title]
- [Date]
- [Classification: Confidential / Internal / Public]
-
- Table of Contents
-
- Executive Summary
-
- 1. Introduction / Context
- 2. Methodology (if applicable)
- 3. Findings / Analysis
- 4. Recommendations
- 5. Implementation Plan
- 6. Appendices
- ```
-
- Version, author, and reviewer should be noted on the cover page or in document properties.
-
- ### Multi-Author Coordination
-
- For reports with multiple contributors (common on large engagements), establish these upfront:
-
- **Before Writing:**
- - **Single outline owner**: One person owns the overall narrative arc and section structure. Committee-written outlines produce committee-quality reports
- - **Section assignments**: Each section has exactly one author. Shared ownership means nobody owns it
- - **Style guide agreement**: Agree on voice (first person plural "we" vs. third person), tense, heading conventions, and evidence citation format
- - **Placeholder convention**: Use `[TBD: description of needed content]` for sections awaiting input. Never leave blank sections
-
- **During Writing:**
- - **Integration checkpoints**: Schedule two review points: (1) after first drafts of all sections, (2) after revisions. Don't wait for final assembly to discover inconsistencies
- - **Cross-reference log**: Track which sections reference data or findings from other sections. When one section changes, flag dependent sections
- - **Terminology register**: Maintain a short list of key terms and how they're used. "Revenue" vs. "net revenue" vs. "ARR" discrepancies across sections destroy credibility
-
- **Version Control and Review Workflow:**
-
- Naming convention: `[Client]_[Report]_v[Major].[Minor]_[Date]_[Author].docx`
- - Major version: structural changes, new sections, post-review rewrites (v1.0, v2.0)
- - Minor version: edits within existing structure (v1.1, v1.2)
- - Example: `Acme_MarketEntry_v2.1_2026-03-15_JSmith.docx`
-
- | Stage | Version | Who Reviews | What They Check |
- |-------|---------|-------------|-----------------|
- | First draft | v0.1 | Author self-review | Structure, completeness, argument logic |
- | Peer review | v0.5 | One colleague | Logic, evidence gaps, readability |
- | Manager review | v1.0 | Engagement manager | Narrative arc, client-readiness, accuracy |
- | Partner review | v1.5 | Partner/director | Strategic positioning, risk, tone |
- | Client draft | v2.0 | Client review | Factual accuracy, alignment with expectations |
- | Final | v3.0 | Final QA | Formatting, cross-references, typos |
-
- **Track changes discipline**: One reviewer at a time. Resolve all comments before passing to the next reviewer. Parallel reviews at the same level produce conflicting edits.
-
- **Working in shared drives**: Lock the file when editing. Use a simple status tracker: "v1.2 with JSmith for manager review, due back Mar 18."
-
- **Final Assembly:**
- - One person does final assembly and voice harmonization. This takes longer than people expect (budget 1-2 days for a full report)
- - Check that the executive summary reflects the actual content, not an earlier draft's conclusions
- - Verify all cross-references and page numbers
-
- ### Report-Specific Quality Checklist
-
- In addition to the common checklist:
- - Page numbers present
- - Table of contents is accurate
- - Grammar and spelling are correct
- - Scenario analysis included for recommendations with significant uncertainty
-
- ---
-
- ## Part 3: Executive Presentations
-
- ### Defining the Core Message
-
- Before opening any slide tool, write these three things:
-
- 1. **The answer in one sentence**: "We should enter the German market through acquisition of [Target] for EUR 120M"
- 2. **The three supporting arguments**: Why now, why this target, why acquisition vs. organic
- 3. **The evidence for each**: Market data, target financials, comparable transactions
-
- If you cannot write these clearly, you are not ready to build slides.
-
- ### Deck Structure
-
- | Slide Type | Purpose | Key Elements |
- |------------|---------|--------------|
- | Title | Set expectation | Punchy title (max 6 words), subtitle with key message, presenter, date |
- | Executive Summary | Full message for time-pressed readers | 3-5 bullets covering the complete recommendation; bottom line up front |
- | Context/Situation | Establish common ground | Facts the audience agrees with, current state data |
- | Problem/Complication | Create urgency | Impact metric, trend visualization, quantified cost of inaction |
- | Analysis | Show the thinking | Framework visual (2x2, waterfall, etc.), key insight in one sentence |
- | Recommendation | Present the answer | Recommendation in one line; why now, why us, why this; quantified impact |
- | Financial Impact | Prove the value | Benefits, costs, net value; waterfall or bridge chart; key assumptions and sensitivity |
- | Roadmap/Next Steps | Call to action | Phased timeline with actions, owners, dates; immediate first action |
-
- ### Slide Anatomy
-
- ```
- +-------------------------------------------+
- | ACTION TITLE (complete sentence) | <- The slide's takeaway
- +-------------------------------------------+
- | |
- | [Exhibit: chart, table, framework] | <- Visual evidence
- | |
- | |
- | |
- | Source: [data source, date] | <- Attribution
- +-------------------------------------------+
- ```
-
- The action title is what distinguishes consulting slides from everything else. Write it as a complete sentence stating the takeaway.
-
- The body is exhibit-driven. Charts, tables, and frameworks dominate... not paragraphs or bullets. One focused exhibit is ideal. Two related exhibits side by side works when they jointly support the action title.
-
- **The "So What?" test** for each slide:
- - So what? (Why does the audience care about this?)
- - Says who? (Is this credible? What's the source?)
- - What if? (What are the implications?)
-
- If you can't answer "so what?" in one sentence, cut or restructure the slide.
-
- ### Presentation vs. Leave-Behind
-
- Different formats require different density. Decide which you're building before you start.
-
- | Dimension | Presentation Deck | Leave-Behind / Read-Ahead |
- |-----------|-------------------|---------------------------|
- | **Primary audience** | People in the room | People reading alone, later |
- | **Font size** | 30pt minimum | 18pt minimum |
- | **Content density** | One point per slide | Can layer 2-3 points per page |
- | **Exhibits** | One per slide, annotated | Can include supporting detail |
- | **Action titles** | Short, punchy | Can be longer, more descriptive |
- | **Appendix** | Separate backup slides | Can be inline or appended |
- | **Typical length** | 8-12 slides + backup | 15-30 pages |
- | **Goal** | Drive a decision in the room | Survive forwarding to people who weren't there |
-
- A presentation deck that gets forwarded as a read-ahead usually fails at both jobs. If the deck will serve both purposes, add a 1-page executive summary that works standalone, and put supporting detail in clearly labeled appendix sections.
-
- ### 10-Slide Report Summary Template
-
- For reports that also need a board or executive presentation, produce a 10-slide summary. This is not "put the report on slides." It's a restructured argument for a spoken format.
-
- | Slide | Content | Notes |
- |---|---|---|
- | 1. Title | Report title, date, classification | Match the report cover |
- | 2. Executive summary | 3-5 bullet recommendation with impact numbers | Someone who sees only this slide gets the full message |
- | 3. Situation | Context the audience agrees with | 2-3 data points, not a wall of text |
- | 4. Complication | What's changed or at risk | Quantify the cost of inaction |
- | 5. Key finding #1 | Strongest analytical finding | One chart or framework, action headline |
- | 6. Key finding #2 | Second finding | One chart or framework, action headline |
- | 7. Key finding #3 | Third finding (if needed) | Merge with #6 if two findings suffice |
- | 8. Recommendation | What to do, quantified impact | Options table if multiple paths |
- | 9. Scenario / sensitivity | Base, upside, downside with key triggers | Tornado chart or scenario table |
- | 10. Next steps | Actions, owners, dates | First action should be achievable this week |
-
- ### Board Deck Specifics
-
- Board presentations have distinct dynamics. Directors have fiduciary obligations, limited time, and see dozens of proposals.
-
- **Framing**: Connect every recommendation to shareholder value, risk management, or strategic positioning. Boards think in terms of fiduciary duty, not operational efficiency.
-
- **Governance committee expectations**: If the proposal touches audit, compensation, or risk committees, address their specific mandates. An audit committee wants control frameworks. A risk committee wants quantified exposure. A compensation committee wants alignment between incentives and outcomes.
-
- **What boards want to see**:
- - Investment size relative to total capital budget (context, not just the number)
- - Downside scenario and management's plan for it
- - Competitive implications of acting vs. not acting
- - Management's confidence level and basis for it
- - Clear decision requested: approve, approve with conditions, or defer
-
- **What boards don't want**:
- - Operational detail they can't evaluate (save it for backup)
- - Options without a recommendation (they hired management to decide)
- - Surprises (pre-wire key stakeholders before the meeting)
-
- ### Pre-Wiring Key Stakeholders
-
- Pre-wiring means socializing the recommendation with influential stakeholders before the formal meeting. It eliminates surprises, surfaces objections you can address in the deck, and converts potential opponents into allies (or at least non-blockers).
-
- **Who to pre-wire**: The decision-maker, anyone with veto power, known skeptics, and anyone whose public reaction will influence the room.
-
- **How to pre-wire**:
- 1. Request 15-20 minutes 1:1, framed as "I want to make sure this lands well... can I walk you through the key points?"
- 2. Share the recommendation and 2-3 supporting data points (not the full deck)
- 3. Ask for their reaction and concerns. Listen more than you pitch
- 4. Incorporate legitimate objections into the deck (add a slide, adjust language, prepare a backup)
- 5. If they disagree fundamentally, you know before the meeting and can adjust scope, framing, or the ask
-
- **Timing**: 2-5 days before the meeting. Too early and context shifts. Too late and you can't adjust.
-
- **What pre-wiring is NOT**: Lobbying for a predetermined outcome. If pre-wiring reveals your recommendation is wrong, change the recommendation.
-
- ### Backup Slides
-
- Every deck should have backup slides ready for Q&A. Build them before you need them.
-
- **Standard backup categories**:
- - Detailed methodology and assumptions
- - Full financial model with sensitivity tables
- - Competitive benchmarking data
- - Risk register with mitigations
- - Alternative scenarios that were considered and rejected
- - Implementation timeline at workstream level
-
- **Formatting backup slides**: Use the same action-title format as the main deck. Label each clearly (e.g., "BACKUP: Detailed NPV Assumptions"). Number them separately from the main deck (B1, B2, B3) so you can reference them quickly.
-
- ### Storytelling Techniques
-
- | Element | Technique | Example |
- |---------|-----------|---------|
- | Start strong | Provocative question or data point | "What if everything you thought about growth was wrong?" |
- | Create tension | Highlight cost of inaction | "Every quarter we wait costs us $X million" |
- | Show the journey | Share a concrete finding | "We met with 50 customers and heard the same thing three times" |
- | Build to climax | Layer insights | "First we found X, then Y, which led us to Z" |
- | End with action | Clear call to decision | "We recommend you approve Phase 1 by Friday" |
-
- ### Flex Structure: Reordering and Skipping Slides
-
- No presentation survives first contact with the audience. Build your deck so you can adapt in real time.
-
- **Before the meeting**: Know which slides are load-bearing (must show) and which are supporting (can skip). Mark them in your speaker notes. A typical 12-slide deck has 5-6 must-show slides.
-
- **Reading the room**:
- - If the audience is nodding through context slides, skip ahead: "I see you're aligned on the context... let me jump to the analysis."
- - If they're stuck on a point, pause the planned flow. Going forward when the room is still processing slide 3 means slides 4-12 are wasted.
- - If a question jumps ahead to a later slide, go there. Don't say "I'll get to that." You'll lose them.
- - If energy drops during detailed analysis, jump to the recommendation and work backwards: "Let me show you where we landed, then we can dig into the supporting analysis."
-
- **Structural enablers**:
- - Number your backup slides (B1, B2...) so you can navigate quickly
- - Use section dividers so you can skip entire sections cleanly
- - Keep a mental map of three paths through the deck: full, abbreviated (skip supporting detail), and "cut to the chase" (exec summary + recommendation + next steps)
-
- ### Handling Live Slide Edits
-
- Clients will ask you to change slides during the meeting. This is normal in consulting.
-
- **When to edit live**:
- - Wording changes to recommendations that reflect genuine alignment shifts
- - Adding a caveat or condition the room agrees on
- - Updating a number with better data someone provides in the moment
-
- **When NOT to edit live**:
- - Structural changes that require rethinking the argument
- - Requests that are really one person's preference, not the room's consensus
- - Changes that would take more than 60 seconds
-
- **How to handle it**:
- - Acknowledge: "Good point. Let me capture that." Make the edit if quick, or write the change on paper/in notes and confirm: "I'll update the deck and circulate by [time]."
- - If using projected slides, have a second person make edits on a laptop while you keep presenting
- - Always read back the revised language to confirm: "So the recommendation now reads [X]... does that capture it?"
- - Send the updated deck within 24 hours with changes highlighted
-
- ### Handling Q&A
-
- **Preparation**: For every presentation, build an anticipation table:
-
- | Anticipated Question | Why It's Hard | Best Response | Fallback |
- |---------------------|---------------|---------------|----------|
- | "Why not option B?" | They may prefer it | Data comparison showing A outperforms | "Happy to model both scenarios" |
- | "What's the downside?" | Acknowledging risk | Quantified risk with mitigation plan | "We've stress-tested three scenarios" |
-
- **Response framework**:
- 1. **Listen completely**: Don't interrupt, let them finish, acknowledge the question
- 2. **Confirm understanding**: "So what you're asking is..." or "Let me make sure I understand..."
- 3. **Answer directly**: Lead with the answer, support with evidence, be concise
- 4. **Confirm resolution**: "Does that address your question?"
-
- If you don't know the answer: say so. "I don't have that data with me. I'll follow up by [date]." Credibility is built by honesty, not by bluffing.
-
- ### One-Page Recommendation Memo
-
- When a full deck is overkill:
-
- ```
- # Memo: [Recommendation Title]
-
- ## Recommendation
- [Clear statement of what you recommend]
-
- ## Problem
- [What challenge or opportunity this addresses]
-
- ## Analysis
- 1. [Key finding 1 with evidence]
- 2. [Key finding 2 with evidence]
- 3. [Key finding 3 with evidence]
-
- ## Value
- - [Benefit 1 -- quantified]
- - [Benefit 2 -- quantified]
-
- ## Implementation
- - Timeline: [Duration]
- - Key milestones: [Milestones]
- - Investment required: [Amount]
-
- ## Risks and Mitigations
- | Risk | Mitigation |
- |------|-----------|
- | [Risk 1] | [Mitigation] |
- | [Risk 2] | [Mitigation] |
-
- ## Decision Needed
- [What you need from the decision-maker, by when]
-
- ## Next Steps
- 1. [Immediate action -- owner -- date]
- 2. [Follow-up action -- owner -- date]
- ```
+ > "After extensive analysis of the competitive landscape, examining trends across segments and reviewing internal capabilities, our team concluded that acquiring TargetCo represents a compelling strategic opportunity."
- ### Design Principles
+ Bottom line up front:
+ > "Acquire TargetCo for EUR 85M. It closes our APAC distribution gap and turns EBITDA-accretive by Year 2. Three factors support this."
- - Use brand colors consistently (client's or firm's, depending on context)
- - Limit to 3-4 colors per slide
- - Use color to highlight, not decorate
- - Ensure high contrast for readability
- - White space is a feature, not wasted space
- - Use consistent fonts and sizes throughout
- - Consider accessibility (color-blind friendly palettes)
+ ## Quality Assurance
- ### Behavioral Principles
+ Before finalizing anything, confirm:
- - **Lead with the answer, always.** Executives lose patience with build-up. State the recommendation in the first 30 seconds and earn the right to explain afterward.
- - **Every slide must pass the "so what?" test.** If you cannot articulate why the audience should care in one sentence, cut or restructure it.
- - **Quantify or don't claim it.** Unsupported claims erode credibility. Attach a number, a source, or a date to every assertion.
- - **Design for the skeptic in the room.** Assume at least one audience member will challenge your logic. Build the pyramid so each level withstands scrutiny independently.
- - **Less content, more conviction.** A 7-slide deck delivered with authority beats a 30-slide deck that hedges. Cut ruthlessly and own what remains.
- - **Consider the hybrid audience.** When presenting to both in-room and remote participants, design for the screen first.
+ - The executive summary or first slide stands alone and gives the full picture in five minutes.
+ - Every finding has evidence; every recommendation has rationale.
+ - Every number is sourced; every term is defined.
+ - The conclusion matches the evidence, and the whole deliverable answers the original question.
+ - Recommendations with real uncertainty carry a scenario or sensitivity view.
+ - Every recommended action has a named owner and a date.
+ - Benchmarks are attributed. "Per [Source], the benchmark is X" beats "industry benchmarks suggest." With no published source, write "based on our analysis" or "directional estimate based on [basis]."
- ---
+ ## References
- ## PPTX Generation
+ Load the reference that matches the format you are building:
- When generating actual .pptx files (not markdown outlines), read
- [references/pptx-generation.md](references/pptx-generation.md) for consulting-specific slide
- masters, anatomy rules, and layout patterns using pptxgenjs. Default to
- `LAYOUT_WIDE` (13.33" x 7.5") for consulting decks.
+ - Building a written report (report types, section templates, IC memo, document structure, multi-author coordination): read [references/written-reports.md](references/written-reports.md).
+ - Building an executive presentation (deck structure, slide anatomy and exhibit recipes, board decks, pre-wiring, backup, Q&A, live edits, the one-page memo): read [references/executive-presentations.md](references/executive-presentations.md).
+ - Generating an actual .pptx file rather than a markdown outline: read [references/pptx-generation.md](references/pptx-generation.md) for slide masters, anatomy rules, and pptxgenjs layout patterns. Default to `LAYOUT_WIDE` (13.33" x 7.5") for consulting decks.