PMI-PBA — PMI Professional in Business Analysis Exam Blueprint
Practical PMI-PBA exam blueprint for PMI Professional in Business Analysis readiness, covering business analysis planning, requirements, traceability, evaluation, and exam judgment.
How to Use This PMI-PBA Exam Blueprint
Use this checklist as a practical readiness map for the PMI Professional in Business Analysis (PMI-PBA) exam from PMI. It is organized around the business analysis work a candidate should be able to recognize, plan, perform, monitor, and evaluate in project, product, predictive, agile, and hybrid settings.
For each area, ask:
- Can I identify the business analysis objective?
- Can I choose the right technique, artifact, or stakeholder action?
- Can I explain what should happen next in a scenario?
- Can I distinguish between requirements, designs, solutions, benefits, risks, assumptions, and constraints?
- Can I apply the concept in both predictive and adaptive delivery contexts?
Do not use this as a memorization-only list. The PMI-PBA exam is judgment-heavy. You should be ready to interpret scenarios, select appropriate actions, and understand why a business analysis decision supports value delivery.
PMI-PBA Readiness Areas at a Glance
| Readiness area | What to review | You are ready when you can… |
|---|---|---|
| Needs assessment | Business problems, opportunities, objectives, current state, future state, feasibility, value | Connect a business need to measurable outcomes and recommend whether more analysis is justified |
| Stakeholder analysis | Stakeholder identification, influence, interest, communication needs, engagement strategies | Determine who must be consulted, informed, involved, or escalated to in a scenario |
| Business analysis planning | BA approach, requirements approach, governance, traceability, change control, acceptance planning | Select the right planning artifact or tailoring decision for predictive, agile, or hybrid work |
| Elicitation | Interviews, workshops, observation, surveys, document analysis, prototypes, brainstorming | Choose an elicitation method based on stakeholder availability, ambiguity, urgency, and risk |
| Requirements analysis | Requirement types, models, prioritization, validation, verification, quality criteria | Refine vague needs into clear, testable, valuable requirements |
| Traceability and monitoring | Traceability matrices, baselines, change impact, requirements status, approvals | Explain how to track requirements from business need through delivery and evaluation |
| Solution evaluation | Acceptance, validation, defects, performance, benefits realization, lessons learned | Determine whether the solution meets business needs and what to do when it does not |
| Project and product context | Scope, schedule, cost, quality, risk, value, delivery approach, governance | Balance BA decisions with project constraints and product value goals |
| Agile, predictive, and hybrid BA | Backlogs, user stories, increments, baselines, change requests, progressive elaboration | Adapt BA work without losing clarity, stakeholder alignment, or traceability |
Needs Assessment Checklist
The exam may test whether you understand why work is being considered before jumping into requirements or solution details.
Business Need and Problem Definition
Be able to check off the following:
- Identify the difference between a business problem, business opportunity, business need, and proposed solution.
- Recognize when stakeholders are describing symptoms rather than root causes.
- Clarify the desired business outcome before documenting detailed requirements.
- Determine whether the organization has enough information to proceed with analysis.
- Identify assumptions, constraints, dependencies, and risks that affect the business need.
- Link the business need to strategy, benefits, compliance, efficiency, customer experience, revenue, cost reduction, risk reduction, or operational improvement.
Current State and Future State
| Topic | Can you do this? |
|---|---|
| Current-state analysis | Identify existing processes, pain points, stakeholders, systems, data, and constraints |
| Future-state definition | Describe the desired capability or outcome without prematurely locking into a solution |
| Gap analysis | Compare current and future states and identify capability, process, technology, data, or people gaps |
| Feasibility | Recognize business, technical, operational, schedule, cost, legal, organizational, and risk considerations |
| Recommendation support | Distinguish fact-based analysis from stakeholder preference or solution bias |
Root Cause and Opportunity Analysis
Know when to use or recognize:
- Five Whys
- Fishbone / cause-and-effect analysis
- Pareto analysis
- Process analysis
- Data analysis
- SWOT-style thinking
- Benchmarking
- Business case inputs
- Capability gap review
Scenario Cues
| If the scenario says… | Think about… |
|---|---|
| “The sponsor already selected a solution” | Confirm the business need and evaluate whether the solution actually addresses it |
| “Users disagree about the problem” | Facilitate stakeholder alignment and validate current-state facts |
| “The team is documenting requirements immediately” | Determine whether needs assessment and scope boundaries are clear enough |
| “The project is high risk or high cost” | Consider additional feasibility, alternatives analysis, or governance review |
| “Benefits are vague” | Define measurable outcomes and success criteria before proceeding too far |
Business Analysis Planning Checklist
Business analysis planning is about deciding how the work will be performed, governed, communicated, changed, traced, and accepted.
Planning Decisions to Review
| Planning decision | What to consider |
|---|---|
| BA approach | Predictive, agile, hybrid, regulatory, organizational maturity, stakeholder availability |
| Elicitation approach | Techniques, schedule, participants, preparation, facilitation needs |
| Requirements management approach | How requirements are documented, prioritized, approved, changed, and traced |
| Governance | Decision rights, approval levels, escalation paths, change authority |
| Communication | Who needs what information, when, how, and at what level of detail |
| Traceability | What relationships must be tracked and why |
| Prioritization | Value, urgency, risk, dependency, cost, effort, compliance, stakeholder importance |
| Acceptance | How solution acceptance will be evaluated and by whom |
| Collaboration | How BA work integrates with project managers, product owners, sponsors, SMEs, testers, architects, and delivery teams |
BA Plan Readiness
You should be able to answer:
- What business analysis activities are needed?
- Which stakeholders participate in each activity?
- What artifacts will be produced?
- How much detail is appropriate for the delivery approach?
- How will requirements be reviewed, validated, approved, and changed?
- How will conflicting stakeholder priorities be handled?
- What traceability is necessary to manage scope, value, and impact?
- How will solution acceptance be planned?
- What risks affect BA work?
- What tailoring is appropriate?
Predictive, Agile, and Hybrid Planning
| Context | BA planning emphasis | Common exam trap |
|---|---|---|
| Predictive | Upfront requirements planning, baselines, formal approvals, change control | Assuming every change can be handled informally |
| Agile | Progressive elaboration, backlog refinement, collaboration, acceptance criteria | Assuming no planning, documentation, or traceability is needed |
| Hybrid | Mix of upfront planning and iterative detail | Applying one delivery style rigidly to all work |
| Regulated or high-risk | Documentation, approvals, auditability, traceability | Under-documenting decisions and requirement changes |
| Innovative or uncertain | Discovery, prototyping, experimentation, feedback loops | Freezing requirements too early |
Stakeholder Analysis and Engagement Checklist
PMI-PBA scenarios often test whether you know who to involve, how to resolve disagreement, and when to escalate.
Stakeholder Identification
Review stakeholder categories such as:
- Sponsor
- Business owner
- Product owner or product manager
- End users
- Customers
- Subject matter experts
- Project manager
- Development or delivery team
- Testers and quality specialists
- Operations and support teams
- Compliance, legal, audit, or risk stakeholders
- Vendors or external partners
- Change management or training teams
- Executives or governance boards
Engagement Readiness Table
| Skill | Ready means you can… |
|---|---|
| Identify stakeholders | Find missing voices that affect requirements, acceptance, operations, or benefits |
| Analyze influence and interest | Tailor communication and involvement based on stakeholder power and impact |
| Manage conflict | Facilitate resolution using data, value, scope, risk, and decision rules |
| Maintain engagement | Keep stakeholders involved throughout elicitation, validation, prioritization, and evaluation |
| Escalate appropriately | Escalate when authority, priority, risk, or unresolved conflict exceeds the BA role |
| Communicate appropriately | Match detail, format, timing, and channel to the stakeholder’s needs |
Stakeholder Decision Prompts
Ask yourself:
- Who owns the business outcome?
- Who can approve or reject requirements?
- Who will use the solution?
- Who will operate or support the solution?
- Who may be negatively affected?
- Who provides regulatory, security, financial, or policy constraints?
- Who has decision authority when stakeholders disagree?
- Who should validate requirements before delivery begins?
- Who should evaluate whether benefits were achieved?
Elicitation Checklist
Elicitation is not just “gathering requirements.” It is active discovery, clarification, confirmation, and alignment.
Elicitation Techniques
| Technique | Best fit | Watch for |
|---|---|---|
| Interviews | Deep input from individuals or experts | Bias, limited perspective, inconsistent terminology |
| Workshops | Group alignment, prioritization, process review | Dominant voices, unresolved conflict, poor facilitation |
| Observation | Understanding actual work practices | Hawthorne effect, incomplete scenarios |
| Document analysis | Existing policies, procedures, contracts, systems | Outdated or conflicting documents |
| Surveys | Broad input from many stakeholders | Low response quality, shallow detail |
| Prototyping | Clarifying uncertain needs or user experience | Stakeholders mistaking prototype for final solution |
| Brainstorming | Generating options or identifying risks | Lack of prioritization or feasibility review |
| Interface analysis | System boundaries and integrations | Missing data, security, timing, ownership issues |
| Process modeling | Workflow, handoffs, bottlenecks | Modeling too much detail too early |
| Data analysis | Business rules, reporting, decisions | Poor data quality or unclear definitions |
Elicitation Preparation
- Define the objective of the session.
- Identify participants and their roles.
- Choose the technique based on the information needed.
- Prepare questions, models, scenarios, or source documents.
- Confirm logistics and access to needed information.
- Establish ground rules for workshops.
- Plan how outputs will be documented and validated.
- Identify known assumptions, constraints, and open questions.
During and After Elicitation
- Distinguish facts from opinions.
- Capture requirements, assumptions, risks, issues, decisions, and action items separately.
- Ask follow-up questions to clarify ambiguity.
- Confirm terminology and definitions.
- Watch for conflicting requirements.
- Validate notes with participants.
- Update relevant artifacts.
- Identify next elicitation steps or missing stakeholders.
Scenario Cues
| If the scenario says… | Best BA thinking |
|---|---|
| “Users are unavailable” | Use alternate sources, plan targeted sessions, escalate availability risk if needed |
| “Stakeholders provide conflicting answers” | Facilitate clarification, analyze impacts, and use decision authority or prioritization rules |
| “Requirements are vague” | Ask clarifying questions and model examples before baselining or building |
| “A workshop went off track” | Reconfirm objectives, manage facilitation, and document unresolved items |
| “The team lacks domain knowledge” | Involve SMEs and validate assumptions early |
Requirements Types Checklist
A strong PMI-PBA candidate can classify and work with different requirement types without mixing them.
| Requirement type | What it describes | Example cue |
|---|---|---|
| Business requirement | High-level business objective or need | “Reduce claim processing time” |
| Stakeholder requirement | Need of a stakeholder group | “Agents need to see claim status” |
| Solution requirement | Capability or quality the solution must have | “The system shall display claim status” |
| Functional requirement | Behavior or function | “User can submit an application” |
| Nonfunctional requirement | Quality attribute or constraint | “Response time must support user needs” |
| Transition requirement | Temporary capability needed to move from current to future state | Training, migration, conversion, cutover support |
| Data requirement | Information, definitions, relationships, quality needs | Customer record fields, retention, reporting |
| Interface requirement | Interaction between systems, users, or organizations | API, file transfer, screen, handoff |
| Business rule | Policy, calculation, condition, or decision logic | Eligibility, pricing, approval threshold |
Requirement Quality Checklist
A requirement should be:
- Clear
- Concise
- Complete enough for its purpose
- Consistent with related requirements
- Testable or verifiable
- Feasible
- Necessary
- Traceable
- Unambiguous
- Prioritized
- Aligned to business value
Common Requirement Defects
| Defect | Example cue | What to do |
|---|---|---|
| Ambiguous | “Fast,” “easy,” “user-friendly” | Define measurable criteria or examples |
| Design disguised as requirement | “Use this exact tool” without rationale | Validate whether it is a true constraint or just a preference |
| Conflicting | Two stakeholders need incompatible behavior | Facilitate trade-off and decision |
| Missing acceptance criteria | Team cannot confirm done | Add testable conditions |
| Untraceable | No link to business need | Confirm value or remove/defer |
| Gold plating | Extra feature not tied to value | Challenge priority and business justification |
| Too broad | Multiple needs in one statement | Split and clarify |
| Too detailed too early | Premature design decisions | Match detail to delivery stage and approach |
Requirements Analysis and Modeling Checklist
Requirements analysis turns elicited information into structured, validated, prioritized, and usable requirements.
Analysis Activities
- Organize elicitation results.
- Identify gaps, overlaps, and conflicts.
- Model processes, data, decisions, states, interfaces, or user interactions.
- Refine requirements to the right level of detail.
- Define acceptance criteria.
- Confirm assumptions and constraints.
- Assess feasibility and dependencies.
- Prioritize based on value, risk, urgency, cost, and dependency.
- Validate requirements with stakeholders.
- Verify requirements for quality.
- Prepare requirements for approval, backlog refinement, or delivery planning.
Modeling Artifacts to Recognize
| Artifact or model | What it helps clarify |
|---|---|
| Process flow | Work steps, handoffs, bottlenecks, roles |
| Context diagram | System or solution boundaries and external actors |
| Use case | User goal, interactions, main and alternate flows |
| User story | User role, need, and value in agile contexts |
| Story map | User journey, release slicing, value flow |
| Data model | Entities, relationships, definitions |
| Data dictionary | Standard definitions and attributes |
| Decision table | Complex business rules and conditions |
| State diagram | Lifecycle states and transitions |
| Interface specification | Interactions between systems or organizations |
| Prototype or wireframe | User interaction, layout, navigation, feedback |
| Requirements traceability matrix | Links among needs, requirements, design, testing, and outcomes |
| Acceptance criteria | Conditions for accepting a requirement or increment |
Can You Do This?
- Convert a vague stakeholder request into clear requirements.
- Identify when a model is needed to reduce ambiguity.
- Choose between process, data, decision, interface, or state modeling.
- Spot missing alternate flows or exception cases.
- Separate business rules from process steps.
- Separate requirements from designs.
- Determine whether a requirement is ready for approval or delivery.
- Explain how requirements support scope and value.
- Identify when more elicitation is needed.
Prioritization Checklist
Prioritization is a frequent exam judgment area because it requires balancing value, risk, constraints, and stakeholder expectations.
Prioritization Factors
| Factor | What to ask |
|---|---|
| Business value | Which requirement best supports the objective or benefit? |
| Risk reduction | Which item reduces uncertainty or major exposure? |
| Urgency | Is there a deadline, compliance need, market event, or operational issue? |
| Dependency | Does another requirement or deliverable depend on this one? |
| Cost or effort | Is the value justified by the effort? |
| Stakeholder impact | Who is affected, and how significantly? |
| Technical feasibility | Can the team realistically deliver it? |
| Quality impact | Does it affect performance, security, usability, reliability, or maintainability? |
| Regulatory or policy need | Is it mandatory or optional? |
| Learning value | Will delivery or prototyping provide important feedback? |
Techniques and Concepts to Recognize
- MoSCoW-style classification
- Ranking
- Weighted scoring
- Cost-benefit thinking
- Risk-based prioritization
- Value versus effort comparison
- Minimal viable or minimal marketable scope thinking
- Backlog ordering
- Timeboxing and scope negotiation
- Dependency mapping
Scenario Traps
| Trap | Better response |
|---|---|
| Prioritizing by loudest stakeholder | Use agreed criteria and decision authority |
| Treating all requirements as equal | Apply value, risk, urgency, and dependency |
| Ignoring constraints | Reassess scope, schedule, budget, quality, and risk trade-offs |
| Building low-value features first | Focus on value delivery and learning |
| Assuming compliance items are optional | Validate mandatory constraints and acceptance obligations |
Traceability and Monitoring Checklist
Traceability helps confirm that requirements remain aligned to business value and that changes are understood.
Traceability Links to Understand
| Link | Why it matters |
|---|---|
| Business need to requirement | Confirms requirement has a purpose |
| Requirement to design | Confirms the solution addresses the requirement |
| Requirement to test case | Confirms the requirement can be verified |
| Requirement to acceptance criteria | Confirms stakeholders can evaluate completion |
| Requirement to risk | Shows where uncertainty or exposure exists |
| Requirement to change request | Shows impact of approved changes |
| Requirement to release or increment | Shows when value is expected |
| Requirement to benefit | Supports evaluation after delivery |
Monitoring Activities
- Track requirement status.
- Monitor changes to scope, priority, and acceptance criteria.
- Maintain traceability as requirements evolve.
- Confirm requirements are still valid.
- Identify orphan requirements with no business value.
- Identify missing requirements for approved business needs.
- Assess change impacts before approval.
- Communicate requirement changes to affected stakeholders.
- Monitor unresolved issues and decisions.
- Support audits, reviews, or governance needs when applicable.
Change Impact Analysis
When a requirement changes, assess impact on:
- Business objectives
- Scope
- Schedule
- Cost
- Quality
- Risk
- Benefits
- Other requirements
- Designs
- Test cases
- Data
- Interfaces
- Operations
- Training
- Contracts or vendors
- Compliance or policy
- Stakeholder expectations
Scenario Cues
| If the scenario says… | Think about… |
|---|---|
| “A stakeholder requests a change after approval” | Follow the agreed change process and perform impact analysis |
| “A delivered feature does not map to a business need” | Challenge value and check for scope creep |
| “Testing reveals missing functionality” | Trace back to requirements and acceptance criteria |
| “Requirements keep changing” | Review governance, elicitation quality, prioritization, and stakeholder alignment |
| “The team cannot tell which tests cover which requirements” | Improve traceability between requirements and verification artifacts |
Solution Evaluation Checklist
Solution evaluation asks whether the delivered solution actually solves the business problem and achieves value.
Evaluation Concepts
| Concept | What to know |
|---|---|
| Verification | Did we build according to specified requirements? |
| Validation | Does the solution meet the business need? |
| Acceptance | Do authorized stakeholders agree the solution is acceptable? |
| Performance measurement | Does the solution achieve target outcomes or indicators? |
| Benefits realization | Are expected business benefits being achieved? |
| Defect analysis | What gaps, failures, or quality issues exist? |
| Operational readiness | Can the organization use, support, and sustain the solution? |
| Transition assessment | Are training, migration, communication, and adoption needs addressed? |
| Lessons learned | What should be improved for future BA work? |
Evaluation Readiness
Be able to:
- Define evaluation criteria before or during delivery planning.
- Connect acceptance criteria to requirements and business outcomes.
- Identify whether a gap is a requirement issue, design issue, implementation defect, training issue, adoption issue, or business process issue.
- Recommend corrective action when outcomes are not achieved.
- Distinguish user dissatisfaction from unmet requirement, poor adoption, or changed business need.
- Determine whether additional elicitation, change control, training, or process improvement is needed.
- Review whether benefits are measurable and attributable.
- Capture lessons learned and recommend improvements.
Acceptance and Evaluation Scenario Cues
| Situation | Likely exam focus |
|---|---|
| Users reject a delivered feature | Check acceptance criteria, validation process, stakeholder involvement, and requirements clarity |
| Solution works technically but benefits are not achieved | Evaluate adoption, process fit, training, measurement, and original assumptions |
| A defect is found late | Trace to requirement, test, design, or implementation gap; assess impact |
| Sponsor asks whether project was successful | Compare outcomes to business objectives and benefits, not just delivery completion |
| Operational team is unprepared | Review transition requirements and stakeholder engagement |
Project, Product, and Governance Context
The PMI-PBA exam sits at the intersection of business analysis and project delivery. You do not need to become a project manager for every question, but you should understand how BA work affects delivery decisions.
Delivery Constraints and Trade-Offs
| Constraint or concern | BA relevance |
|---|---|
| Scope | Requirements define, refine, and control what is included |
| Schedule | Elicitation, analysis, approvals, and changes affect timing |
| Cost | Requirement complexity and change impact budget |
| Quality | Clear, testable requirements support quality outcomes |
| Risk | Unclear, unstable, or high-impact requirements increase risk |
| Stakeholder satisfaction | Engagement and validation reduce surprises |
| Value | Requirements should support business outcomes |
| Compliance | Requirements may need evidence, approvals, or auditability |
| Benefits | BA work connects delivered outputs to measurable outcomes |
Governance Checks
- Who approves requirements?
- Who approves changes?
- Who resolves requirement conflicts?
- What is the escalation path?
- What documentation is required?
- What traceability is required?
- What criteria define acceptance?
- What happens when scope, value, schedule, or risk changes?
- How are decisions recorded?
- How are stakeholders informed?
What Should the Business Analyst Do Next?
| Scenario | Strong next step |
|---|---|
| Requirement conflict between departments | Facilitate analysis using business objectives, impacts, and decision authority |
| Sponsor bypasses change process | Explain impact and follow governance; escalate only if needed |
| Team starts building without validated requirements | Confirm readiness, clarify gaps, and involve appropriate stakeholders |
| Stakeholders cannot agree on priority | Apply agreed prioritization criteria and decision process |
| Requirement threatens schedule | Analyze options and trade-offs; communicate impact |
| New regulation affects scope | Assess mandatory requirements, impacts, and governance actions |
| Delivered solution misses business outcome | Evaluate root cause and recommend corrective action |
Agile, Predictive, and Hybrid BA Checklist
PMI-PBA candidates should be comfortable adapting BA work to different delivery approaches.
Predictive BA Readiness
- Understand baselined requirements.
- Recognize formal review and approval points.
- Use change control for post-baseline changes.
- Maintain traceability across requirements, design, testing, and acceptance.
- Support scope definition and validation.
- Identify risks from incomplete requirements before delivery begins.
Agile BA Readiness
- Understand backlog refinement.
- Work with user stories and acceptance criteria.
- Support prioritization based on value and feedback.
- Elaborate requirements progressively.
- Collaborate closely with product owners, teams, users, and stakeholders.
- Use prototypes, examples, and conversations to clarify needs.
- Maintain enough documentation and traceability for the context.
- Evaluate increments against acceptance criteria and business goals.
Hybrid BA Readiness
- Identify which work needs upfront analysis and which can be elaborated later.
- Maintain governance without slowing learning unnecessarily.
- Preserve traceability across predictive and agile artifacts.
- Align release planning with business value.
- Manage change through the appropriate mechanism for the workstream.
- Communicate clearly when artifacts differ across teams.
Artifact Translation Table
| Predictive-style artifact | Agile-style counterpart or related artifact | BA concern |
|---|---|---|
| Requirements specification | Backlog items, epics, features, user stories | Maintain clarity and value alignment |
| Requirements baseline | Prioritized backlog or release scope | Control expectations and change |
| Change request | Backlog reprioritization or formal change, depending on governance | Assess impact and authority |
| Requirements traceability matrix | Trace links among epics, stories, acceptance criteria, tests, releases, outcomes | Keep visibility from need to value |
| Formal acceptance sign-off | Product acceptance, demo feedback, acceptance criteria completion | Confirm authorized acceptance |
| Detailed upfront plan | Rolling-wave elaboration and refinement plan | Tailor detail to uncertainty |
Business Analysis Artifacts Checklist
You should recognize what each artifact is for and when it should be updated.
| Artifact | Purpose | Update when… |
|---|---|---|
| Business case inputs | Support investment or solution recommendation | Need, benefits, risks, costs, or options change |
| Stakeholder register or analysis | Identify and understand stakeholders | New stakeholders emerge or influence changes |
| BA plan | Defines BA approach and activities | Delivery approach, scope, risk, or governance changes |
| Elicitation plan | Organizes discovery activities | Information needs or stakeholder availability changes |
| Requirements documentation | Captures requirements at appropriate detail | Requirements are clarified, approved, or changed |
| Models and diagrams | Clarify complexity | Understanding changes or ambiguity remains |
| Backlog | Orders work by value, risk, dependency, and readiness | Priorities or needs change |
| Traceability matrix | Tracks requirement relationships | Requirements, tests, designs, risks, or releases change |
| Change log | Records requested and approved changes | A change is proposed, analyzed, approved, rejected, or deferred |
| Issue log | Tracks open problems | New issues or decisions occur |
| Decision log | Records decisions and rationale | A significant decision is made |
| Acceptance criteria | Defines completion and acceptance conditions | Requirements are refined or validation gaps appear |
| Evaluation report or findings | Summarizes solution performance | Acceptance, benefits, or outcome data is reviewed |
| Lessons learned | Captures improvements | Significant learning occurs during or after work |
Techniques and Tools Readiness Checklist
Analysis Techniques
- Gap analysis
- Root cause analysis
- Process analysis
- Interface analysis
- Data analysis
- Decision analysis
- Risk analysis
- Cost-benefit thinking
- Feasibility analysis
- Prioritization
- Modeling
- Prototyping
- Workshops
- Document analysis
- Benchmarking
- Acceptance criteria definition
Requirements Quality Techniques
- Peer review
- Walkthrough
- Inspection
- Stakeholder validation
- Testability check
- Traceability review
- Conflict analysis
- Ambiguity review
- Completeness review
- Dependency review
Facilitation and Communication Techniques
- Active listening
- Questioning
- Conflict resolution
- Negotiation
- Consensus building
- Decision facilitation
- Meeting management
- Visual modeling
- Tailored communication
- Escalation when appropriate
Common PMI-PBA Weak Areas and Traps
| Weak area | Why candidates miss it | Readiness correction |
|---|---|---|
| Jumping to solutions | Scenario mentions a tool or feature early | Reconfirm business need and outcomes first |
| Confusing validation and verification | Both sound like “checking” | Verification checks conformance; validation checks fitness for need |
| Ignoring stakeholders | Technical work appears central | BA work requires stakeholder alignment and acceptance |
| Treating agile as no documentation | Agile scenarios emphasize collaboration | Use appropriate documentation and traceability |
| Treating predictive as no change | Baselines appear fixed | Changes can occur through governance and impact analysis |
| Missing transition requirements | Focus stays on product features | Include migration, training, deployment, adoption, and support |
| Poor prioritization | Candidate chooses stakeholder preference | Use value, risk, urgency, dependency, and constraints |
| Weak traceability | Requirements seem documented | Track links to business need, tests, changes, and outcomes |
| Confusing requirements with design | Scenario describes how to build | Ask whether it is a true constraint or implementation choice |
| Over-escalating | Conflict appears in scenario | Facilitate first when within BA authority; escalate when decision authority is exceeded |
| Under-escalating | Authority or governance issue exists | Escalate unresolved decisions, major risks, or approval conflicts appropriately |
| Forgetting benefits | Project delivery appears complete | Evaluate whether business outcomes were achieved |
Scenario Judgment Practice Prompts
Use these prompts to test exam-style reasoning.
Prompt Set 1: Needs and Scope
- A sponsor requests a new system but cannot define measurable benefits. What should the BA do next?
- Users request automation of a process that may not be necessary. What analysis should come first?
- A proposed solution conflicts with organizational strategy. What should be reviewed?
- Stakeholders disagree on whether the problem is process-related or technology-related. What technique helps?
- A project is approved before detailed requirements are known. How should BA planning adapt?
Prompt Set 2: Elicitation and Requirements
- Stakeholders are geographically dispersed. Which elicitation techniques may work best?
- Workshop participants provide contradictory requirements. What should be documented and resolved?
- A requirement says the application must be “easy to use.” What is missing?
- Developers ask for more detail before estimating. What BA artifact or activity helps?
- A user story lacks acceptance criteria. What risk does that create?
Prompt Set 3: Change and Traceability
- A high-priority stakeholder requests a change after requirements approval. What happens before acceptance?
- A test case fails but the requirement is ambiguous. What should be reviewed?
- A feature has no trace to business value. What should the BA question?
- A requirement change affects training and operations. What impact areas must be considered?
- A backlog item is moved earlier due to regulatory urgency. What should be updated?
Prompt Set 4: Evaluation
- The solution was delivered on time but adoption is low. What should be evaluated?
- Users accepted a feature, but business metrics did not improve. What does that suggest?
- Defects appear after release due to misunderstood business rules. What earlier BA activities may have failed?
- A transition requirement was missed. What stakeholders should have been involved?
- Benefits cannot be measured. What should have been defined earlier?
Final-Week PMI-PBA Review Checklist
Content Review
- Review needs assessment concepts and root cause analysis.
- Review BA planning decisions and tailoring.
- Review stakeholder analysis and engagement strategies.
- Review elicitation techniques and when to use each.
- Review requirement types and quality criteria.
- Review modeling artifacts and what each clarifies.
- Review prioritization factors and trade-offs.
- Review traceability and change impact analysis.
- Review solution evaluation, acceptance, and benefits.
- Review predictive, agile, and hybrid BA differences.
Scenario Practice
- Practice identifying the actual problem in each scenario.
- Practice deciding what the BA should do next.
- Practice selecting the best artifact to update.
- Practice choosing when to facilitate, analyze, document, validate, or escalate.
- Practice eliminating answers that skip stakeholder involvement.
- Practice eliminating answers that ignore governance.
- Practice distinguishing immediate action from long-term improvement.
- Practice recognizing when more information is needed before deciding.
Artifact Review
- BA plan
- Stakeholder analysis
- Elicitation plan
- Requirements documentation
- User stories and acceptance criteria
- Process models
- Data models or data dictionaries
- Decision tables
- Interface documentation
- Traceability matrix
- Change log
- Issue log
- Acceptance documentation
- Evaluation findings
- Lessons learned
Exam-Day Thinking Habits
- Read the full scenario before choosing an answer.
- Identify the delivery context: predictive, agile, hybrid, regulated, urgent, uncertain, or high risk.
- Identify the BA objective in the question.
- Look for missing stakeholders, unclear requirements, unmanaged change, or unvalidated assumptions.
- Prefer actions that clarify, validate, analyze impact, and align with governance.
- Avoid answers that jump straight to building, approving, rejecting, or escalating without analysis.
- Choose the response that best protects business value and stakeholder alignment.
- Remember that documentation level should be tailored, not ignored.
Quick Readiness Scorecard
Use this table to identify final review priorities.
| Area | Green: ready | Yellow: review | Red: urgent |
|---|---|---|---|
| Needs assessment | Can define problem, value, gaps, and feasibility | Know terms but miss scenario cues | Jump to requirements or solutions |
| Stakeholders | Can identify, analyze, engage, and escalate appropriately | Know roles but miss hidden stakeholders | Ignore conflict, authority, or communication |
| BA planning | Can tailor approach and governance | Know artifacts but not when to update them | Treat all projects the same |
| Elicitation | Can choose techniques by situation | Know techniques but not trade-offs | Think elicitation is just note-taking |
| Requirements | Can classify, refine, validate, and verify | Miss nonfunctional or transition needs | Accept vague or untestable requirements |
| Prioritization | Can balance value, risk, urgency, dependency | Overweight one factor | Follow loudest stakeholder |
| Traceability | Can link need to requirement, test, change, and outcome | Understand matrix but not purpose | Cannot assess change impact |
| Evaluation | Can assess acceptance, defects, adoption, and benefits | Focus mostly on testing | Equate delivery with success |
| Delivery context | Can adapt across agile, predictive, and hybrid | Know labels but not implications | Apply one approach rigidly |
Practical Next Step
After reviewing this checklist, choose your weakest two readiness areas and practice scenario questions that force a decision: what to do next, which artifact to update, who to involve, whether to escalate, and how to protect business value. For PMI-PBA preparation, the strongest improvement usually comes from explaining why the best answer is better than the second-best answer.