PMI Visual Wall — Batch 1: Foundation & PMBOK 7

PMI VISUAL WALL · BATCH 2

Section 3 — Business Analysis · Posters 7–10 🖨 Print / Save as PDF — A3 landscape Tip: in the print dialog set paper = A3, layout = Landscape, margins = None, "Background graphics" ON.

Batch 2 — Business Analysis (Posters 7–10)

This batch covers the PMI Guide to Business Analysis : the BA domains end-to-end, requirements life cycle & types, elicitation & analysis techniques, and traceability/solution evaluation. Same anatomy as the rest of the wall — Purpose → Visual Map → Key Concepts → Relationships → Exam Concepts → Executive View → Industry Example → Memory Hooks → 60-second Daily Review. The gold spine marks Business Analysis. Print with the button above (A3, landscape, margins None, background graphics ON).

Where BA sits: business analysis is the discipline that finds the right problem and defines the right solution — it feeds and runs alongside project delivery, partnering the PM rather than replacing them.

POSTER 07

Section 3 · Business Analysis — The Discipline

Business Analysis & Its Six Domains

Business analysis is the set of activities that determine needs , recommend solutions and enable value delivery. In one line: BA finds the right problem and defines the right solution ; the PM then delivers that solution right. The two are partners, not rivals.

Visual Map — The Six Business-Analysis Domains

1 · Needs Assessment find & justify the right problem ▸ 2 · Stakeholder Engagement plan BA & engage the right people ▸ 3 · Elicitation draw out needs & requirements ▸ 4 · Analysis model, specify & validate ▸ 5 · Traceability & Monitoring link, baseline & manage change ▸ 6 · Solution Evaluation prove value vs the need

Stakeholder Engagement and Traceability & Monitoring run continuously across the others; Elicitation ↔ Analysis iterate as a tight loop. The chain is shown left→right but the work is iterative , not strictly sequential.

BA vs PM — Two Roles, One Goal

Lens	Business Analyst	Project Manager
Core question	Are we building the right thing?	Are we building the thing right?
Owns	Needs, requirements, solution scope, value	Time, cost, resources, delivery, risk
Key outputs	Business case, requirements, traceability, evaluation	Charter, plans, baselines, status reports
Shared ground	Scope · stakeholders · change control · quality · communication

Key Concepts

• Need ≠ requirement: a need is the problem; a requirement is a stated condition the solution must meet.
• BA can be a role or a set of activities anyone may perform.
• BA is product-focused ; PM is project-focused.
• BA spans strategy → delivery → value , including after go-live.

Exam Concepts

• Know the 6 domains and their order.
• Requirements are the heart of business analysis.
• BA precedes & outlives the project (needs → evaluation).
• Stakeholder engagement & traceability are continuous.

Executive View

• Good BA slashes costly rework by getting requirements right early.
• Ties every requirement to a business value.
• Bridges strategy and delivery — fewer orphaned features.

Industry Example

Defence

• Upgrading a vessel's combat-management system: BA elicits needs from operators & maintainers, defines requirements, traces each to a capability gap , and later evaluates the fielded system against mission outcomes.

Relationships

• Feeds the project charter (via the business case) and the PMBOK 7 value delivery system (Poster 4).
• Supports portfolio selection — needs assessment justifies the investment.
• Solution evaluation links to benefits realisation in programs (Poster 16).

Memory Hooks

• "Right problem · right solution · real value."
• Domain order — N·S·E·A·T·S : "Never Stop Eliciting And Tracing Solutions."
• BA = the "what & why"; PM = the "how & when."

60-sec Review Name the 6 domains in order BA vs PM core question Need vs requirement Which 2 domains are continuous? Where BA outlives the project

PMI Visual Wall · Poster 07 · Business Analysis — Discipline & Domains · original instructional design · A3 landscape

POSTER 08

Section 3 · Business Analysis — Domain 1

Needs Assessment

Before any solution: understand the problem or opportunity , compare current vs future state , weigh viable options , and recommend & justify a solution in a business case. This is where bad ideas should die cheaply — and good ones earn their funding.

Visual Map — From Problem to Business Case

Identify problem / opportunity ▸ Assess Current State capabilities, costs, pain ▸ Define Future State goals & objectives ▸ Determine Options assess feasibility ▸ Recommend & Justify the business case ▸ → Charter hand-off to delivery

The gap between current and future state defines the solution scope. Options are screened on feasibility — operational, technical, financial, schedule — before one is recommended.

Define the Problem

• Situation statement: problem/opportunity + impact + consequence.
• Root cause: 5 Whys · Ishikawa (fishbone) — fix the cause, not the symptom.
• SWOT to frame internal/external factors.
• Quantify the cost of the problem & cost of delay.

Define the Future State

• Goals (broad) → objectives (SMART : specific, measurable, achievable, relevant, time-bound).
• Identify capability gaps to close.
• Set the success measures / KPIs up front.
• Bound the solution scope.

The Business Case

• Recommended option + rationale.
• Costs vs benefits — NPV, ROI, payback, IRR.
• Risks, assumptions, constraints, dependencies.
• Success measures & recommendation to proceed.

Exam Concepts

• Needs assessment may occur pre-project (portfolio) or in-project.
• Assess the current state — don't assume it.
• Goals vs objectives; objectives are SMART.
• Feasibility = operational · technical · financial · schedule.

Executive View

• Kills weak ideas early — protects the budget.
• Aligns each investment to strategy.
• Locks in measurable success criteria before spend.

Industry Example

Manufacturing

• "Should we automate the welding line?" Current state: labour cost & defect rate. Future state: +30% throughput, −50% rework. Options: cobots vs full automation vs outsource. Business case picks cobots on payback < 18 months.

Relationships

• Output → business case → charter → BA plan & delivery.
• Feeds portfolio selection & prioritisation (Poster 18).
• Future-state measures become solution-evaluation criteria (Poster 10).

Memory Hooks

• Sequence — P·C·F·O·C : Problem → Current → Future → Options → Case.
• "Don't fall in love with a solution before you've defined the problem."
• Gap = future − current = the scope.

60-sec Review Recite the P-C-F-O-C flow Write a situation statement Goals vs SMART objectives 4 feasibility types Business-case components

PMI Visual Wall · Poster 08 · Business Analysis — Needs Assessment · original instructional design · A3 landscape

POSTER 09

Section 3 · Business Analysis — Domains 3 & 4

Elicitation, Analysis & Requirements

The engine room of BA: draw out needs (elicitation), then classify, model, specify, validate & prioritise them (analysis). Elicitation is not passive note-taking — it actively surfaces latent needs. The two iterate as a tight loop until requirements are clear and agreed.

Elicitation — Draw It Out

Plan ▸ Conduct ▸ Confirm results ↺

• Techniques: interviews · facilitated workshops (JAD) · focus groups · observation / job-shadowing · surveys · document analysis · prototyping · brainstorming.
• Always confirm elicitation results with stakeholders — capture, then play back.

Analysis — Make It Buildable

Model ▸ Specify ▸ Validate & Verify▸ Prioritise

• Validation = the right requirements (meet the need).
• Verification = requirements built right (quality, testable).
• Prioritise with MoSCoW — Must / Should / Could / Won't.

Requirement Types — The Classification Ladder

Business why — goals & value ▸ Stakeholder who needs what ▸ Solution — Functional what it must do + Solution — Non-functional how well (perf, security…) ▸ Transition how we get there (training, migration)

Good requirements are: clear · concise · complete · consistent · feasible · unambiguous · testable · traceable. Transition requirements are temporary — they retire once the solution is live.

Modelling Toolkit — Show, Don't Just Tell

• Scope: context diagram · use-case · feature model.

• Process: flowchart · swimlane · BPMN.

• Rules: decision table · decision tree.

• Data: ERD · data dictionary · state diagram.

• Interface: wireframe · report table · prototype.

• Agile: user stories + acceptance criteria.

Exam Concepts

• Elicitation surfaces latent needs — it's active, not passive.
• Always confirm elicitation results.
• Functional = what it does; non-functional = how well.
• Validate vs verify — know the difference cold.

Executive View

• Prioritised, testable requirements = predictable delivery.
• Models give a shared picture across business & tech.
• MoSCoW makes trade-offs explicit when budgets tighten.

Industry Example

IT

• New SaaS module: workshops + prototypes elicit needs; a context diagram bounds scope; user stories + acceptance criteria specify; MoSCoW sets the MVP.

Memory Hooks

• Levels — B·S·S·T : Business → Stakeholder → Solution → Transition.
• "Validate = right thing · Verify = thing right."
• Elicit → Model → Specify → Confirm — then loop.

60-sec Review Plan-Conduct-Confirm List 4 elicitation techniques B-S-S-T requirement levels Functional vs non-functional MoSCoW + validate/verify

PMI Visual Wall · Poster 09 · Business Analysis — Elicitation, Analysis & Requirements · original instructional design · A3 landscape

POSTER 10

Section 3 · Business Analysis — Domains 5 & 6

Traceability, Monitoring & Solution Evaluation

The back end that closes the value loop : keep every requirement linked from origin to test and under change control (traceability & monitoring), then confirm the deployed solution actually delivers the intended value (solution evaluation). No trace, no proof; no evaluation, no learning.

Visual Map — The Requirements Traceability Matrix (RTM)

Business need / objective	Stakeholder req.	Solution req.	Design / build	Test case	Status
Cut line defects 50%	Operator alert on fault	FR-12 fault alarm <2s	PLC module M4	TC-12	Verified
Cut line defects 50%	Trace each reject	FR-15 log reject + cause	MES report R7	TC-15	Implemented

Forward tracing = need → requirement → build → test (coverage). Backward tracing = test/feature → originating need (no orphans, no gold-plating). The RTM is the backbone for impact analysis & scope control.

Traceability & Monitoring

• Trace each requirement both ways; maintain coverage.
• Baseline approved requirements; control change via impact analysis.
• Track requirement states: proposed → approved → implemented → verified.
• Approve changes through the right authority before work proceeds.

Solution Evaluation

• Define evaluation criteria & KPIs (from the future-state measures).
• Collect actuals; compare actual vs expected value.
• Identify limitations / solution & enterprise gaps.
• Recommend: release · iterate · replace · retire.

Exam Concepts

• Traceability enables impact analysis & guards against scope creep.
• Evaluation can continue after go-live.
• Tie results back to the business case & benefits.
• A baseline is an approved version; changes are controlled.

Executive View

• Proof the investment paid off — value, not just delivery.
• Objective basis to continue, scale or kill.
• Traceability protects scope & supports audit / assurance.

Industry Example

Manufacturing

• Post go-live on the automated cell: measure OEE, scrap %, throughput vs the business case. Defects fell 42% (target 50%) → recommend tuning , then evaluate scaling to a second line.

Relationships

• RTM underpins integrated change control with the PM.
• Evaluation feeds benefits realisation (programs, Poster 16) & value (Poster 4).
• Findings inform portfolio continue/kill decisions (Poster 18).

Memory Hooks

• "Trace it · prove it · value it."
• RTM = the spine linking need → test. No trace, no proof.
• Evaluation answer = release · iterate · replace · retire.

60-sec Review Forward vs backward tracing Sketch an RTM row 4 requirement states Evaluation: actual vs expected 4 evaluation outcomes

PMI Visual Wall · Poster 10 · Business Analysis — Traceability & Solution Evaluation · original instructional design · A3 landscape