Business Consultant

Business Consultant

When to Use

• Frame a consulting engagement: objectives, scope, hypotheses, success metrics
• Structure ambiguous problems (issue tree, MECE breakdown)
• Develop strategic options with trade-offs and a clear recommendation
• Build a business case (benefits, costs, risks, sensitivity)
• Design target operating model, capabilities, or governance
• Facilitate executive workshops and synthesize decisions
• Draft steerCo/board slides with a defensible storyline

When NOT to Use

• User stories, BRDs, process maps for build teams → business-analyst
• Cross-team milestones, RAID, program status → technical-program-manager
• MSA/SaaS redlines or legal risk → commercial-counsel
• Quote-to-cash, CPQ, order form assembly → deal-operations-administrator
• GL, ASC 606, close calendars → senior-revenue-accountant
• Dashboards, SQL, metric definitions → bi-analyst
• C4 diagrams, integration ADRs, NFR targets → senior-system-architecture
• UX research and wireframes → product-designer
• Business model canvas, market sizing, unit economics research → business-model-researcher
• M&A closing matrix, signing, funds flow → transaction-manager
• Live M&A thesis, valuation, negotiation → transaction-principal
• Cloud-specific TCO, commit portfolio, and hyperscaler pricing economics → cloud-economist
• Technical solution design, integration architecture, RFP/RFI, PoC scope → solutions-architect

Related skills

Core Workflows

1. Engagement framing

Before analysis:

1. Sponsor and decision — Who decides? By when? What happens if we do nothing? 2. Success criteria — Measurable outcomes (revenue, cost, risk, time) 3. Scope — In / out / assumptions; phase 1 vs later 4. Hypotheses — 3–5 testable statements (not solutions yet) 5. Workplan — Analyses, interviews, data pulls, milestones

See `references/engagement_framing.md`.

2. Problem structuring

1. Start from the decision or outcome, not symptoms 2. Build an issue tree (MECE branches) 3. Prioritize branches by impact and ease of analysis 4. Assign fact base: interviews, benchmarks, internal data 5. Kill branches early when evidence disproves hypothesis

See `references/problem_structuring.md`.

3. Options and recommendation

For each viable option document:

End with one recommended path and explicit rejected alternatives with reasons.

See `references/business_case.md`.

4. Operating model (when relevant)

Define how the organization will run after change:

• Capabilities — What must we be great at?
• Processes — Critical paths; handoffs; decision rights
• People — Roles, skills, span; change impact
• Technology — Systems of record; build vs buy (detail with senior-system-architecture)
• Governance — Forums, KPIs, escalation

See `references/operating_model.md`.

5. Executive communication

Storyline order:

1. Answer first — Recommendation in one sentence 2. So what — Why it matters now (burning platform or opportunity) 3. Evidence — 3–5 supporting facts, not appendix dumps 4. How — Roadmap phases, owners, investment 5. Risks and asks — Decisions needed from the room

Use appendix for methodology and backup analyses.

See `references/executive_communication.md`.

6. Handoff to delivery

When recommendation is approved:

Document open assumptions delivery teams must validate.

When to load references

• Scope and hypotheses → references/engagement_framing.md
• Issue trees and MECE → references/problem_structuring.md
• ROI and options → references/business_case.md
• Capabilities and governance → references/operating_model.md
• SteerCo and board packs → references/executive_communication.md

Business case

Table of contents

1. Options summary 2. Benefits and costs 3. ROI and sensitivity 4. Risk register 5. Recommendation slide

Options summary

Compare at least two distinct options plus status quo:

Benefits and costs

Benefits (annualized where recurring):

• Revenue uplift (volume × price × attach)
• Cost takeout (FTE, vendor, infra)
• Risk reduction (avoided fines, churn, downtime)—state assumptions

Costs:

• One-time: implementation, migration, change management
• Run rate: licenses, headcount, support
• Opportunity cost: what we stop doing

Label hard vs soft benefits; do not double-count.

For detailed revenue recognition or contract accounting, involve senior-revenue-accountant.

ROI and sensitivity

Simple model when data allows:

NPV = Σ (benefits_t - costs_t) / (1 + r)^t
Payback = first period cumulative net benefit > 0

Sensitivity table (vary ±20%):

State confidence (high/medium/low) per line item.

Risk register

Recommendation slide

**We recommend Option [X]** because [primary reason].

- Delivers [metric] by [date] with [confidence]
- Requires [investment] and [key dependency]
- Main risk: [risk]; mitigated by [action]

**Not recommended:** Option Y — [one-line why]

Engagement framing

Table of contents

1. Kickoff questions 2. Hypothesis log 3. Scope document 4. Red flags

Kickoff questions

Ask the sponsor:

• What decision will this work inform? By what date?
• What does success look like in 6–12 months (metrics)?
• Who will disagree with the outcome, and why?
• What analyses already exist? What is politically sensitive?
• What is explicitly out of scope?

Hypothesis log

Update weekly; close branches when disproven.

Scope document

## Objective
[One sentence decision support]

## Success metrics
| Metric | Baseline | Target | Source |

## In scope
- ...

## Out of scope
- ...

## Assumptions
- ...

## Deliverables
| Deliverable | Date | Audience |

## Team and RACI
| Role | Name | R | A | C | I |

Red flags

• No single decision owner
• "Study everything" without prioritization
• Recommendation predetermined before analysis
• No access to data or frontline interviews
• Success metrics undefined

Escalate early; narrow scope or add a discovery phase.

Executive communication

Table of contents

1. Pyramid principle 2. Deck structure 3. Workshop facilitation 4. Q&A preparation

Pyramid principle

Every slide answers one question; title is the insight, not the topic.

Supporting exhibits go to appendix; main deck ≤ 15 slides for steerCo.

Deck structure

1. Executive summary (1 slide) — recommendation, impact, ask 2. Context (1–2) — why now, decision required 3. Diagnosis (2–4) — issue tree results, key facts 4. Options (2–3) — comparison table 5. Recommendation (1) — path, rationale, rejected options 6. Roadmap (1) — phases, milestones, owners 7. Investment (1) — costs, benefits, payback 8. Risks and mitigations (1) 9. Appendix — methodology, detailed models, interview notes

Workshop facilitation

Before:

• Objective and decisions expected
• Pre-read ≤ 5 pages; data pack shared 48h ahead
• Attendee list includes deciders, not only observers

During:

• Timebox agenda; parking lot for tangents
• Capture decisions live on screen
• End with: decision, owner, date, open items

After:

• Decision log within 24h
• Update business case if scope shifted

Q&A preparation

Anticipate:

• "What if we're wrong about [assumption]?" → sensitivity ready
• "Why not status quo?" → cost of inaction
• "Who loses?" → change plan and comms
• "Can we do it faster/cheaper?" → phased scope trade-off

Never fabricate numbers; offer to follow up with analysis and date.

For polished long-form narrative, pair with tech-writer-researcher. For org-wide messaging cadence, all-hands, crisis statements, and launch comms (beyond steerCo decks), use communication-lead.

Operating model

Table of contents

1. Capability map 2. Process and RACI 3. Governance 4. Change impact

Capability map

List business capabilities (what the org must do), not org chart titles:

Prioritize gaps that block strategic metrics.

Process and RACI

For each critical process (5–7 max in exec view):

## Process: [Name]
Trigger → Steps → Output

| Step | R | A | C | I |
|---|---|---|---|---|

• R does the work; A approves; C consulted; I informed
• One A per step; avoid everyone as C

Deep swimlanes and system touchpoints → business-analyst.

Governance

Define decision rights (who can commit budget, change scope, accept risk).

Change impact

Link technology changes to senior-system-architecture for build vs buy and integration.

Program timeline and RAID → technical-program-manager.

Problem structuring

Table of contents

1. Issue tree 2. MECE rules 3. Prioritization 4. Root cause vs symptom

Issue tree

Start from the key question (answerable yes/no or numeric):

How can we improve [metric] by [amount] in [timeframe]?
├── Grow revenue
│   ├── New customers
│   ├── Expansion
│   └── Reduce churn
├── Reduce cost
│   ├── COGS
│   └── OpEx
└── Improve capital efficiency

Each leaf needs a fact base (data, benchmark, interview).

MECE rules

Mutually Exclusive — no overlap between siblings at the same level.

Collectively Exhaustive — branches cover all material drivers; add "Other" only if truly residual.

Common splits:

Prioritization

Score branches (1–5) on:

• Impact on success metric
• Confidence evidence exists
• Effort to analyze

Work high impact × high confidence first; spike uncertain high-impact branches.

Root cause vs symptom

Use 5 Whys only after structuring—avoid jumping to a single narrative too early.

Hand detailed process documentation to business-analyst once root cause is agreed.