{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreid2da7xqgz6tpefnsi56t5atds3cegbt2rxzorsh4slbs6amwvo44",
    "uri": "at://did:plc:dwfz7or64ad5te6ds2oveka5/app.bsky.feed.post/3mnbydqcy2kp2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiatnftdjt5aowp7eb36dxdy7qgixs4fzgou7rjrxnw7jgvhwzaizu"
    },
    "mimeType": "image/png",
    "size": 2268173
  },
  "description": "The PMI Visual Wall Batch 2 turns PMBOK 7 into a precise, wall‑scale reference linking governance, performance, and value delivery. Each panel converts complex project domains into clear, actionable visuals — helping engineers and project leaders see how intent becomes measurable outcomes.",
  "path": "/pmi-visual-wall-batch-2/",
  "publishedAt": "2026-06-02T06:39:36.000Z",
  "site": "https://kevos.com",
  "textContent": "PMI Visual Wall — Batch 1: Foundation & PMBOK 7\n\n# PMI VISUAL WALL · BATCH 2\n\nSection 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.\n\n## Batch 2 — Business Analysis (Posters 7–10)\n\nThis 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).\n\n**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.\n\nPOSTER 07\n\nSection 3 · Business Analysis — The Discipline\n\n## Business Analysis & Its Six Domains\n\nBusiness 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.\n\n### Visual Map — The Six Business-Analysis Domains\n\n**1 · Needs Assessment**\nfind & justify the right problem ▸ **2 · Stakeholder Engagement**\nplan BA & engage the right people ▸ **3 · Elicitation**\ndraw out needs & requirements ▸ **4 · Analysis**\nmodel, specify & validate ▸ **5 · Traceability & Monitoring**\nlink, baseline & manage change ▸ **6 · Solution Evaluation**\nprove value vs the need\n\n**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.\n\n### BA vs PM — Two Roles, One Goal\n\nLens| Business Analyst| Project Manager\n---|---|---\n**Core question**|  Are we building the _right_ thing?| Are we building the thing _right_?\n**Owns**|  Needs, requirements, solution scope, value| Time, cost, resources, delivery, risk\n**Key outputs**|  Business case, requirements, traceability, evaluation| Charter, plans, baselines, status reports\n**Shared ground**|  Scope · stakeholders · change control · quality · communication\n\n### Key Concepts\n\n  * **Need ≠ requirement:** a need is the problem; a requirement is a stated condition the solution must meet.\n  * BA can be a **role** or a **set of activities** anyone may perform.\n  * BA is **product-focused** ; PM is **project-focused**.\n  * BA spans **strategy → delivery → value** , including after go-live.\n\n\n\n### Exam Concepts\n\n  * Know the **6 domains** and their order.\n  * Requirements are the **heart** of business analysis.\n  * BA **precedes & outlives** the project (needs → evaluation).\n  * Stakeholder engagement & traceability are **continuous**.\n\n\n\n### Executive View\n\n  * Good BA **slashes costly rework** by getting requirements right early.\n  * Ties every requirement to a **business value**.\n  * Bridges **strategy and delivery** — fewer orphaned features.\n\n\n\n### Industry Example\n\nDefence\n\n  * 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.\n\n\n\n### Relationships\n\n  * Feeds the **project charter** (via the business case) and the PMBOK 7 **value delivery system** (Poster 4).\n  * Supports **portfolio selection** — needs assessment justifies the investment.\n  * Solution evaluation links to **benefits realisation** in programs (Poster 16).\n\n\n\n### Memory Hooks\n\n  * **\"Right problem · right solution · real value.\"**\n  * Domain order — **N·S·E·A·T·S** : _\"Never Stop Eliciting And Tracing Solutions.\"_\n  * BA = the **\"what & why\"**; PM = the **\"how & when.\"**\n\n\n\n60-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\n\nPMI Visual Wall · Poster 07 · Business Analysis — Discipline & Domains · original instructional design · A3 landscape\n\nPOSTER 08\n\nSection 3 · Business Analysis — Domain 1\n\n## Needs Assessment\n\nBefore 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.\n\n### Visual Map — From Problem to Business Case\n\n**Identify**\nproblem / opportunity ▸ **Assess Current State**\ncapabilities, costs, pain ▸ **Define Future State**\ngoals & objectives ▸ **Determine Options**\nassess feasibility ▸ **Recommend & Justify**\nthe business case ▸ **→ Charter**\nhand-off to delivery\n\nThe **gap** between current and future state defines the **solution scope**. Options are screened on **feasibility** — operational, technical, financial, schedule — before one is recommended.\n\n### Define the Problem\n\n  * **Situation statement:** problem/opportunity + impact + consequence.\n  * **Root cause:** 5 Whys · Ishikawa (fishbone) — fix the cause, not the symptom.\n  * **SWOT** to frame internal/external factors.\n  * Quantify the **cost of the problem** & cost of delay.\n\n\n\n### Define the Future State\n\n  * **Goals** (broad) → **objectives** (**SMART** : specific, measurable, achievable, relevant, time-bound).\n  * Identify **capability gaps** to close.\n  * Set the **success measures / KPIs** up front.\n  * Bound the **solution scope**.\n\n\n\n### The Business Case\n\n  * Recommended option + rationale.\n  * **Costs vs benefits** — NPV, ROI, payback, IRR.\n  * Risks, assumptions, constraints, dependencies.\n  * Success measures & recommendation to proceed.\n\n\n\n### Exam Concepts\n\n  * Needs assessment may occur **pre-project** (portfolio) or in-project.\n  * **Assess** the current state — don't assume it.\n  * Goals vs objectives; **objectives are SMART**.\n  * Feasibility = operational · technical · financial · schedule.\n\n\n\n### Executive View\n\n  * **Kills weak ideas early** — protects the budget.\n  * Aligns each investment to **strategy**.\n  * Locks in **measurable success criteria** before spend.\n\n\n\n### Industry Example\n\nManufacturing\n\n  * **\"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**.\n\n\n\n### Relationships\n\n  * Output → **business case** → **charter** → BA plan & delivery.\n  * Feeds **portfolio** selection & prioritisation (Poster 18).\n  * Future-state measures become **solution-evaluation** criteria (Poster 10).\n\n\n\n### Memory Hooks\n\n  * Sequence — **P·C·F·O·C** : Problem → Current → Future → Options → Case.\n  * **\"Don't fall in love with a solution before you've defined the problem.\"**\n  * **Gap = future − current = the scope.**\n\n\n\n60-sec Review Recite the P-C-F-O-C flow Write a situation statement Goals vs SMART objectives 4 feasibility types Business-case components\n\nPMI Visual Wall · Poster 08 · Business Analysis — Needs Assessment · original instructional design · A3 landscape\n\nPOSTER 09\n\nSection 3 · Business Analysis — Domains 3 & 4\n\n## Elicitation, Analysis & Requirements\n\nThe 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.\n\n### Elicitation — Draw It Out\n\n**Plan** ▸ **Conduct** ▸ **Confirm results** ↺\n\n  * **Techniques:** interviews · facilitated workshops (JAD) · focus groups · observation / job-shadowing · surveys · document analysis · prototyping · brainstorming.\n  * **Always confirm** elicitation results with stakeholders — capture, then play back.\n\n\n\n### Analysis — Make It Buildable\n\n**Model** ▸ **Specify** ▸ **Validate & Verify**▸ **Prioritise**\n\n  * **Validation** = the _right_ requirements (meet the need).\n  * **Verification** = requirements built _right_ (quality, testable).\n  * **Prioritise** with **MoSCoW** — Must / Should / Could / Won't.\n\n\n\n### Requirement Types — The Classification Ladder\n\n**Business**\nwhy — goals & value ▸ **Stakeholder**\nwho needs what ▸ **Solution — Functional**\nwhat it must do + **Solution — Non-functional**\nhow well (perf, security…) ▸ **Transition**\nhow we get there (training, migration)\n\n**Good requirements are:** clear · concise · complete · consistent · feasible · unambiguous · **testable** · **traceable**. Transition requirements are **temporary** — they retire once the solution is live.\n\n### Modelling Toolkit — Show, Don't Just Tell\n\n  * **Scope:** context diagram · use-case · feature model.\n  * **Process:** flowchart · swimlane · BPMN.\n  * **Rules:** decision table · decision tree.\n\n\n  * **Data:** ERD · data dictionary · state diagram.\n  * **Interface:** wireframe · report table · prototype.\n  * **Agile:** user stories + acceptance criteria.\n\n\n\n### Exam Concepts\n\n  * Elicitation **surfaces latent needs** — it's active, not passive.\n  * Always **confirm** elicitation results.\n  * **Functional** = what it does; **non-functional** = how well.\n  * **Validate** vs **verify** — know the difference cold.\n\n\n\n### Executive View\n\n  * Prioritised, testable requirements = **predictable delivery**.\n  * Models give a **shared picture** across business & tech.\n  * MoSCoW makes **trade-offs explicit** when budgets tighten.\n\n\n\n### Industry Example\n\nIT\n\n  * New SaaS module: **workshops + prototypes** elicit needs; a **context diagram** bounds scope; **user stories** + acceptance criteria specify; **MoSCoW** sets the MVP.\n\n\n\n### Memory Hooks\n\n  * Levels — **B·S·S·T** : Business → Stakeholder → Solution → Transition.\n  * **\"Validate = right thing · Verify = thing right.\"**\n  * Elicit → Model → Specify → Confirm — then **loop**.\n\n\n\n60-sec Review Plan-Conduct-Confirm List 4 elicitation techniques B-S-S-T requirement levels Functional vs non-functional MoSCoW + validate/verify\n\nPMI Visual Wall · Poster 09 · Business Analysis — Elicitation, Analysis & Requirements · original instructional design · A3 landscape\n\nPOSTER 10\n\nSection 3 · Business Analysis — Domains 5 & 6\n\n## Traceability, Monitoring & Solution Evaluation\n\nThe 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.\n\n### Visual Map — The Requirements Traceability Matrix (RTM)\n\nBusiness need / objective| Stakeholder req.| Solution req.| Design / build| Test case| Status\n---|---|---|---|---|---\nCut line defects 50%| Operator alert on fault| FR-12 fault alarm <2s| PLC module M4| TC-12| **Verified**\nCut line defects 50%| Trace each reject| FR-15 log reject + cause| MES report R7| TC-15| Implemented\n\n**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.\n\n### Traceability & Monitoring\n\n  * **Trace** each requirement both ways; maintain **coverage**.\n  * **Baseline** approved requirements; control change via **impact analysis**.\n  * Track **requirement states:** proposed → approved → implemented → verified.\n  * **Approve** changes through the right authority before work proceeds.\n\n\n\n### Solution Evaluation\n\n  * Define **evaluation criteria & KPIs** (from the future-state measures).\n  * Collect actuals; compare **actual vs expected** value.\n  * Identify **limitations / solution & enterprise gaps**.\n  * Recommend: **release · iterate · replace · retire**.\n\n\n\n### Exam Concepts\n\n  * Traceability enables **impact analysis** & guards against scope creep.\n  * Evaluation can continue **after go-live**.\n  * Tie results back to the **business case & benefits**.\n  * A baseline is an **approved** version; changes are controlled.\n\n\n\n### Executive View\n\n  * **Proof the investment paid off** — value, not just delivery.\n  * Objective basis to **continue, scale or kill**.\n  * Traceability protects scope & supports **audit / assurance**.\n\n\n\n### Industry Example\n\nManufacturing\n\n  * 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.\n\n\n\n### Relationships\n\n  * RTM underpins **integrated change control** with the PM.\n  * Evaluation feeds **benefits realisation** (programs, Poster 16) & **value** (Poster 4).\n  * Findings inform **portfolio** continue/kill decisions (Poster 18).\n\n\n\n### Memory Hooks\n\n  * **\"Trace it · prove it · value it.\"**\n  * **RTM = the spine** linking need → test. **No trace, no proof.**\n  * Evaluation answer = **release · iterate · replace · retire.**\n\n\n\n60-sec Review Forward vs backward tracing Sketch an RTM row 4 requirement states Evaluation: actual vs expected 4 evaluation outcomes\n\nPMI Visual Wall · Poster 10 · Business Analysis — Traceability & Solution Evaluation · original instructional design · A3 landscape",
  "title": "PMI VISUAL WALL · BATCH 2",
  "updatedAt": "2026-06-02T06:45:51.549Z"
}