PMI-PBA cheat sheet

A business need is the documented gap between current state and future state; if no measurable gap can be stated, the initiative has no valid business need.

Standard sequence: identify problem or opportunity → assess current state → define future state → perform gap analysis → evaluate options → recommend a solution.

Root cause techniques: 5 Whys (single causal chain), fishbone/Ishikawa (categorized causes), process analysis; solutions that address symptoms alone typically fail validation.

Options are compared on cost, benefit, risk, feasibility, time to value, and strategic fit; the recommendation must state its rationale and the rejected alternatives.

Future-state goals should be SMART (specific, measurable, achievable, relevant, time-bound); these same goals become the metrics used later in solution evaluation.

Situational assessment covers internal factors (culture, process, technology, capability) and external factors (market, regulation, competition, suppliers).

Common triggers for needs assessment: new regulation, competitive threat, performance shortfall, technology change, or a strategic directive from leadership.

Decision rule: if the stated problem is organizational or political rather than solution-driven, escalate to the sponsor to reframe before committing requirements effort.

The business analysis plan covers BA scope, deliverables, techniques, schedule, stakeholders, communication approach, prioritization approach, traceability approach, and change control.

The requirements management plan defines who approves requirements, how they are baselined, how changes are controlled, and how traceability is maintained.

Stakeholder analysis outputs: power/interest classification, influence, attitude toward the change, current engagement level, and preferred communication channel.

Engagement rule: high power + high interest → manage closely; high power + low interest → keep satisfied; low power + high interest → keep informed; low + low → monitor.

Three-point (PERT) estimate = (Optimistic + 4×Most Likely + Pessimistic) ÷ 6; standard deviation = (Pessimistic − Optimistic) ÷ 6.

A communication plan specifies audience, information need, frequency, format, sender/owner, and escalation path for each stakeholder group.

Planning rigor scales with uncertainty and impact: regulated, cross-functional, or high-risk efforts require more formal elicitation, review, and approval steps.

Business analysis scope is not project scope: BA scope covers the requirements and analysis work, project scope covers all work needed to deliver the solution.

Requirement hierarchy: business requirements → stakeholder requirements → solution requirements (functional and nonfunctional) → transition requirements.

Quality characteristics of a requirement: necessary, unambiguous, complete, consistent, feasible, verifiable, and traceable.

Verification asks 'did we document the requirement correctly?'; validation asks 'does this describe what the stakeholder actually needs?'

Prioritization methods include MoSCoW, weighted scoring, 100-point allocation, Kano analysis, and time-boxing; priority is recorded together with its rationale.

Model selection rule: process → BPMN or swimlane diagram; data → ERD or class model; behavior → use case or state diagram; rules → decision table or decision tree.

An assumption is believed true but unverified; a constraint is an imposed limitation. Both are documented, monitored, and traced to affected requirements.

Acceptance criteria are written during analysis, not after build, and must be testable - commonly in Given/When/Then form.

Elicitation techniques: interviews, facilitated workshops, observation, document analysis, surveys, focus groups, prototyping, and interface analysis.

Traceability directions: backward (requirement → source need), forward (requirement → design, build, test artifacts), and full bidirectional coverage for complete verification.

Traceability matrix minimum fields: identifier, requirement text, source, rationale, priority, owner, status, and linked design/test artifacts.

Change control flow: request → log → impact analysis → CCB decision → implement → update requirements and traceability → communicate outcome.

Impact analysis dimensions: affected requirements, scope, schedule, cost, quality, risk, and test coverage.

Requirement status values: proposed, approved, implemented, verified, deferred, rejected, cancelled.

A baseline is the approved requirement set at a point in time; any change after baseline requires formal approval through the change control process.

Monitoring metrics: requirement volatility (changes per requirement per period), change-request cycle time, open defects, and traceability coverage percentage.

Unresolved requirement conflicts escalate to the sponsor or governance body; the BA documents the conflict, the options, and the resulting decision.

Solution evaluation compares actual measured results against the business objectives, acceptance criteria, and expected benefits defined during needs assessment.

Formative evaluation happens during development or pilot to enable correction; summative evaluation happens after full deployment to judge overall value.

ROI = (benefits − costs) ÷ costs; payback period = initial investment ÷ annual net cash flow; NPV discounts future cash flows to present value.

Acceptance requires both verification (built to specification) and validation (meets the business need) before stakeholder signoff.

Evaluation data sources: KPIs and operational metrics, surveys, observation, focus groups, system logs, and the post-implementation review.

If results fall short of expected value, the options are: correct or retrain users, enhance the solution, adjust the business process, or retire the solution.

Transition requirements - data conversion, training, cutover, and support readiness - must be satisfied before planned benefits can be realized.