PMI-PBA Master Guide

What PMI-PBA recognizes

The PMI Professional in Business Analysis (PMI-PBA) is a professional certification for people who use business analysis on projects and programs. PMI describes the role as working with stakeholders to define business requirements, shape project outputs, and help deliver expected benefits. The certification focuses on the practitioner’s ability to apply analysis tools and techniques to real project needs. It does not grant a regulated license or guarantee a particular job outcome.

Business analysis is the work of understanding a business problem or opportunity, discovering stakeholder needs, considering possible solutions, and determining whether the delivered solution meets its purpose. The analyst connects business goals to actionable requirements and evidence. This role may collaborate closely with project management, product ownership, design, engineering, operations, and compliance. The exact division of responsibilities varies by organization, so the exam scenario’s roles and authority matter.

A requirements list is not the same as a business analysis outcome. If a department asks for a new dashboard, the analyst should understand which decision the dashboard supports, who needs it, what information is missing now, and how success will be measured. Only then can stakeholders compare options such as improving an existing report, changing a process, or building new software. Starting with the requested feature may conceal the actual need.

PMI-PBA exam at a glance

The 2022 handbook describes 175 scored questions, 25 unscored pretest questions, four hours, multiple choice, and no scheduled break. PMI’s current certification page confirms 200 questions and 240 minutes, but it does not show the scored/pretest split or break details. Treat those latter format details as handbook-era information until PMI republishes them in a newer authoritative document. The overall question count and time are shown on PMI’s current page.

Four hours for 200 questions averages 72 seconds per question. That is a pacing reference, not a rule that each question should take the same time. A case with several requirements and stakeholders may need more reading than a straightforward term question. Practice summarizing the business need, identifying the task requested, and choosing an answer before overanalyzing distractors.

The five current content domains

The percentages show the proportion of test items assigned to each domain. They do not guarantee a particular number of questions in one sitting, nor do they determine the relative importance of the work in a real project. Analysis has the largest share, but a failure to understand the business need can undermine every downstream requirement. Use the weights to plan review time, then adapt based on your own knowledge gaps.

How the work moves from need to outcome

The five domains form a connected analysis lifecycle. Needs Assessment establishes why change may be needed and what value it should create. Planning decides how to perform and govern the analysis work. Analysis discovers and expresses the requirements in a form stakeholders and delivery teams can use. Traceability and Monitoring preserve the relationships and status of those requirements as work changes. Evaluation checks whether the solution and deployed outcome meet the need.

The lifecycle is not always a one-way sequence. New analysis may reveal that an assumed business problem is actually a symptom. A prototype can change stakeholders’ understanding. Testing can show that a requirement is ambiguous. Outcome measures after deployment may reveal that the solution works technically but does not produce the expected benefit. The analyst uses evidence to revisit earlier decisions and communicate the effect.

A sound business case states the need, expected benefit, options, constraints, and assumptions. A requirement says what capability or condition is needed. Acceptance criteria provide observable conditions for deciding whether a specific requirement is satisfied. A test result supplies evidence about a solution. An outcome metric helps determine whether the deployed change produced the desired result. These artifacts answer different questions and should not be used interchangeably.

Needs Assessment: frame the right problem

Needs Assessment represents 18% of the outline. It covers defining or reviewing a problem or opportunity, collecting and analyzing information for a value proposition, clarifying goals and solution scope, identifying stakeholders, and understanding stakeholder values. The analyst gathers evidence from sources such as process data, customer feedback, interviews, observation, policies, and operational records.

Separate the problem from a proposed solution. ‘We need a mobile app’ may be a stakeholder suggestion, while the underlying problem is that field staff cannot check inventory while away from a workstation. The app is one option. A mobile web tool, offline workflow, or process change may meet the need differently. Define the gap between the current and desired state before evaluating options.

Stakeholder analysis is more than compiling a contact list. Identify who is affected, who has authority, who supplies information, who operates the solution, and whose needs may be underrepresented. An executive, front-line employee, customer, technology team, and compliance officer may value different outcomes. Elicit those perspectives early enough to inform scope and prioritization.

Planning: make the analysis work fit the project

Planning accounts for 22%. It includes reviewing the business case and project goals, deciding the traceability approach, developing the requirements management plan, selecting change control and document control methods, and defining business metrics and acceptance criteria. The analyst considers project approach, stakeholder availability, complexity, organizational standards, and the level of assurance the solution needs.

A requirements management plan clarifies roles, communication, elicitation, analysis, documentation, approval, and change practices. It should be useful in the actual environment. A high-risk medical system may need formal approvals and detailed version control. A small internal workflow improvement may work with lightweight documentation and frequent reviews. Tailoring reduces unnecessary process while preserving the controls needed for quality and compliance.

Traceability planning determines which relationships to maintain. A team may need to link business objectives to stakeholder requirements, solution requirements, design elements, tests, and delivered capabilities. The necessary depth depends on risk, regulation, technical complexity, and the cost of change. A traceability matrix is not valuable merely because it is large; it should help answer questions about coverage, impact, status, or verification.

Analysis: discover and specify useful requirements

Analysis is 35% of the PMI-PBA blueprint. It includes elicitation, analysis and decomposition, evaluating options, prioritizing and baselining requirements, obtaining approval, writing specifications, validating requirements, and defining metrics and acceptance criteria. The analyst uses interviews, workshops, observation, document analysis, surveys, prototypes, process models, data models, use cases, user stories, and other methods according to the question and stakeholders.

Elicitation aims to discover needs and supporting details, including origin and rationale. Stakeholders may describe desired features without articulating the reason. Follow-up questions uncover workarounds, exceptions, constraints, and the conditions under which the solution must operate. Observation can reveal steps people forget to mention. A facilitated workshop can resolve conflicting assumptions, while a survey can gather comparable input from a large group.

Analysis clarifies dependencies, interfaces, data, process, rules, and options. Decomposition makes complex needs manageable while preserving their relationships. A requirement should be clear enough to evaluate and implement, but not so prescriptive that it unnecessarily dictates a design when alternatives remain open. The analyst checks that requirements support the business goals and that assumptions and constraints are visible.

Prioritization balances value, risk, dependencies, cost, schedule, resources, and stakeholder needs. A stakeholder’s seniority may affect decision authority, but it does not replace analysis of value. Obtain approval from the proper decision-makers before establishing a baseline. The baseline records the version accepted for planning and change management; it can change through an agreed process.

Traceability and Monitoring: preserve context as work changes

This domain accounts for 15%. It includes tracking requirement sources, status, and dependencies; monitoring the lifecycle; updating status; communicating issues and changes; and assessing change impacts against the baseline. Traceability helps the team see why a requirement exists and what else may be affected if it changes.

If a data privacy requirement changes, the analyst may need to identify related reports, interface behavior, test cases, training, and operational procedures. Without traceability, a team may update one visible feature while missing dependent components. Impact analysis considers the effect on value, scope, schedule, budget, risk, solution design, and other requirements. The result helps the accountable stakeholders make an informed decision.

Monitoring keeps information current. A status board or traceability tool that is not maintained can be worse than no tool because stakeholders may rely on stale evidence. Communicate changes and conflicts to the project manager and other relevant stakeholders using the plan. Escalate a decision when it exceeds the analyst’s authority, but first explain the options and effects clearly.

Evaluation: verify the solution and assess value

Evaluation represents 10%. It covers checking test evidence against acceptance criteria, identifying gaps between scope, requirements, and the solution, obtaining stakeholder sign-off where required, and evaluating the deployed solution against its business case and value proposition. Verification asks whether the solution meets specified requirements. Evaluation asks whether those requirements and the solution produce the intended outcome.

A feature can pass every acceptance test but still fail to create value. For example, a new appointment reminder may send correctly while missed appointments remain unchanged. The analyst should validate the test evidence, identify any gaps, and later compare outcome measures with the business case. The business may discover that timing, message content, or user consent is the more important issue. Sign-off on a deliverable does not prove the business benefit has been achieved.

When a solution has a gap, document the discrepancy and help stakeholders decide how to resolve it. A defect against an approved requirement may need correction. A requirement that no longer supports the business need may require analysis and an approved change. A solution limitation may require a workaround or scope decision. The analyst should not quietly rewrite acceptance criteria after a failed test to make the result appear successful.

Eligibility and application routes

PMI currently lists three education and experience routes. Set A requires a secondary degree, 60 months working as a business analysis practitioner in the past eight years, and 35 contact hours of business analysis training. Set B requires a bachelor’s degree or higher, 36 months of business analysis experience in the past eight years, and the same 35 contact hours. Set C requires a bachelor’s or postgraduate degree from a GAC-accredited program, 24 months of unique non-overlapping professional business analysis experience, and 35 contact hours of formal education.

The route should match the candidate’s records. A person with a bachelor’s degree and three years of recent analysis work may use Set B if the experience is qualifying and documented. A candidate with a high school diploma needs five years under Set A. A qualifying GAC graduate can use Set C’s two-year experience requirement, but overlapping months cannot be counted twice for the unique experience total. Keep course titles, providers, hours, completion records, project descriptions, dates, and verifier details available.

The 35 hours are business analysis training, not a total study-hour recommendation. Training should cover business analysis practices and be complete before application submission. If only part of a university course concerns business analysis, count only that portion. Experience should describe your own role and responsibilities on projects rather than simply narrating the project’s overall scope.

PMI may select an application for an eligibility audit. The application path includes payment after acceptance and scheduling through Pearson VUE, either at a test center or online-proctored. PMI’s current page describes identity verification and allows up to three attempts within the one-year eligibility period. A scheduled appointment is separate from application approval, so save the eligibility information and booking confirmation.

Study with the current outline

Use the five domains as a study map. Analysis carries 35%, so it deserves the largest share of focused practice. Planning is 22%, Needs Assessment 18%, Traceability and Monitoring 15%, and Evaluation 10%. A candidate should still study all five because each supports the full analysis lifecycle. A low-weight domain can contain a gap that undermines decisions elsewhere.

Start with a baseline set, then tag misses by domain and task. Ask whether you misunderstood the business need, used an elicitation method that missed key stakeholders, produced an ambiguous requirement, failed to trace an impact, or confused acceptance testing with outcome evaluation. Study the actual cause. A person strong at writing requirements may need more practice in business value and post-deployment evaluation.

Practice scenarios rather than only memorizing tool names. If a stakeholder asks for a system change, identify the underlying need and evidence before selecting a solution. If a requirement changes, consider its source, dependencies, baseline, and impact. If a solution passes testing but outcomes are poor, distinguish conformance to requirements from value realization. Explain why the next action fits the stage and the decision authority.

A worked end-to-end example

A regional clinic reports long check-in lines and proposes purchasing kiosks. The analyst begins by defining the problem and collecting arrival, staffing, and wait-time data. Interviews and observation reveal that many patients must repeat insurance information because records do not sync. The analyst identifies patients, front-desk staff, billing, IT, privacy, and operations as stakeholders and compares options, including better data integration and process changes. This is Needs Assessment: diagnose the gap before committing to kiosks.

The analysis approach then sets communication, elicitation, approval, document control, change handling, traceability, and acceptance methods. This is Planning. Workshops and process models clarify requirements for record lookup, exception handling, data security, and staff override. Requirements are decomposed, dependencies are traced, options are prioritized, acceptance criteria are written, and stakeholders approve the baseline. This is Analysis.

During development, a privacy policy changes. The analyst traces affected data fields, interface behavior, test cases, and staff instructions, assesses the impact, and communicates it through the agreed change process. That is Traceability and Monitoring. Testing shows that the integration meets the requirements, but after launch the median check-in wait remains high because a separate eligibility review causes the queue. Evaluation compares results with the business case, identifies the remaining gap, and gives stakeholders evidence for the next improvement. The team has met a technical requirement but has not yet achieved the full intended benefit.

Results and certification maintenance

PMI sets passing standards through psychometric analysis and evaluates candidates against the criteria for a qualified business analysis practitioner. It does not publish a fixed public raw percentage cutoff in the cited current material. PMI’s handbook describes a pass/fail result with diagnostic domain information. Use practice results to identify gaps, not to claim a guaranteed official outcome.

PMI-PBA holders need 60 professional development units every three-year cycle. This maintenance requirement begins after earning the credential and is separate from the 35 contact hours required to apply. Plan continuing development and retain records so renewal is manageable.

A practical preparation sequence

1. Confirm which eligibility route fits your education, unique experience, and training records.
2. Read the current five-domain outline and make a task checklist.
3. Take a diagnostic set and record misses by task and decision error.
4. Study Needs Assessment and Planning before deeper Analysis work so the context and governance are clear.
5. Practice requirements elicitation, modeling, prioritization, traceability, and acceptance with original cases.
6. Use mixed timed practice to connect the domains and improve pacing.
7. Review Evaluation scenarios that distinguish a passing test from realized business value.
8. Confirm exam appointment details and prepare identification and testing setup.

The PMI-PBA is broad because business analysis spans the path from a business need through deployed outcomes. Candidates prepare well when they can explain why a requirement exists, how it will be managed, what evidence will verify the solution, and whether the change created its expected value. Use the current outline, practice the decisions, and treat local workplace habits as context rather than universal rules.