Overview
Needs Assessment covers the work done before any requirement is elicited: defining or reviewing the business problem or opportunity, gathering and analyzing evidence about it, helping set project goals and objectives, identifying stakeholders, and learning what those stakeholders value. Its outputs are a situation statement, a solution scope statement or input to the business case, a view of the value proposition, and a stakeholder register that tells you whose input counts.
Candidates must understand that the analyst investigates the need before accepting a requested solution, uses root cause analysis and current-state evidence to separate symptoms from causes, and ties every goal to an organizational objective. The stakeholder values captured here become the baseline for prioritizing requirements in Domain 3, the business case is the context reviewed in Domain 2 planning, and the value proposition is what Domain 5 measures the deployed solution against.
How it's tested
Needs Assessment questions are short scenarios about the start of an initiative: a sponsor proposes a fix, data conflicts, or a stakeholder group was missed. You are asked what the analyst should do FIRST or which technique BEST fits. The right answer usually investigates the real need or widens stakeholder coverage before anyone commits to a solution, scope or requirement.
-
Problem before solution
A sponsor asks for a specific system or feature. The correct response clarifies the underlying problem or opportunity, often with root cause analysis, before scoping the requested solution.
-
Pick the analysis technique
The stem describes a situation (recurring defects, unclear market gap, competing proposals) and asks which technique fits, such as five whys, a fishbone diagram, SWOT, benchmarking or cost-benefit analysis.
-
Stakeholder coverage
A requirement or objective affects a group nobody has consulted, such as regulators or support staff. The answer identifies and analyzes that group before work continues.
A sponsor wants a new customer portal because call volumes rose 30%. Options include drafting portal requirements, building a prototype, analyzing call reasons, and estimating portal cost. The rise is a symptom, so the analyst first analyzes call logs to find why customers are calling. If most calls concern late invoices, the real problem may be billing, and a portal would not solve it.
Tasks 5
Official tasks from the PMI outline, in outline order.
1.1 Define or review a business problem or opportunityFrame the real need with problem and opportunity analysis.
- What it means
- The analyst uses problem and opportunity analysis techniques, such as root cause analysis, five whys, fishbone diagrams and SWOT, to describe the need precisely. The result feeds a situation statement, a solution scope statement, or the business case.
- What to understand
- A good situation statement names the problem, its effect, and its impact, without naming a solution. Root cause work stops at a cause the organization can act on, and the solution scope states what the solution must address, not how it will be built.
- How it shows up
- A stem gives a symptom (falling sales, rising complaints) plus a proposed fix and asks for the next step; the answer analyzes the cause first.
- Common confusion
- Treating the sponsor's requested solution as the problem statement, which locks scope before the need is understood.
1.2 Collect and analyze information from a variety of sourcesBuild the evidence that sizes the value proposition.
- What it means
- The analyst gathers data from documents, process metrics, interviews, market research, benchmarking and financial records, then applies valuation tools and techniques to estimate what solving the need is worth.
- What to understand
- Know the valuation measures: cost-benefit analysis, return on investment (net benefit divided by cost), net present value (discounted cash flows minus investment), internal rate of return and payback period. Multiple sources are needed because any single source carries its owner's bias.
- How it shows up
- A question asks which data or valuation result best supports the value proposition, or how to resolve two sources that disagree.
- Common confusion
- Relying only on the sponsor's figures, or picking the option with the largest total benefit instead of the best value after cost and time.
1.3 Collaborate in the development of project goals and objectivesClarify business needs so goals align with the organization.
- What it means
- The analyst does not own project goals but helps the sponsor and project manager shape them by clarifying business needs and solution scope, so the product aligns with organizational goals and objectives.
- What to understand
- Goals are broad outcomes; objectives are specific and measurable, usually written SMART (specific, measurable, achievable, relevant, time-bound). The analyst's job is to make sure each objective traces to an organizational strategy and a stated need.
- How it shows up
- A scenario presents a vague objective such as improve customer satisfaction and asks for the analyst's best contribution; the answer makes it measurable and tied to the need.
- Common confusion
- Assuming the analyst sets project goals alone, or confusing a project objective with a requirement.
1.4 Identify stakeholdersFind everyone who affects or is affected by the outcome.
- What it means
- The analyst reviews goals, objectives and requirements to find people and groups who will use, fund, approve, regulate, support or be affected by the solution, so the right parties are represented, informed and involved.
- What to understand
- Stakeholder identification is iterative and is recorded in a stakeholder register, then analyzed with tools such as a power and interest grid, RACI matrix or personas. New requirements can surface new stakeholders, so the list is revisited throughout the project.
- How it shows up
- A requirement affects a group missing from the register, and you choose the next action: identify and analyze that group before proceeding.
- Common confusion
- Treating the stakeholder register as complete once the project is chartered, or including only end users and the sponsor.
1.5 Determine stakeholder values regarding the productLearn what each group values to set the prioritization baseline.
- What it means
- Using elicitation techniques such as interviews, workshops, surveys and observation, the analyst learns what stakeholders expect and value from the product. Those values become the baseline against which requirements are later prioritized.
- What to understand
- Values differ by group, for example speed for operations, auditability for compliance and cost for finance. Capturing them early and explicitly lets the team rank requirements objectively in Analysis instead of by whoever argues loudest.
- How it shows up
- A later prioritization conflict is traced back to missing stakeholder values, or a stem asks why values are elicited before requirements.
- Common confusion
- Mixing stakeholder values (what matters and why) with stakeholder requirements (specific needs the solution must meet).
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Situation statement
A short description of the problem or opportunity, its effect, and its impact on the organization, written before any solution is chosen.
- Remember
- The pattern is problem of X has the effect of Y with the impact of Z, and it never names the solution.
- Tested as
- Questions ask which statement correctly frames a need, and the right one describes the condition and its consequence without prescribing technology.
- Trap
- Choosing a statement such as we need a new CRM, which is a solution disguised as a problem.
-
Root cause analysis
Techniques such as five whys and the fishbone (Ishikawa) diagram trace a visible symptom back to the underlying cause the organization can fix.
- Remember
- Five whys drills down a single causal chain, while a fishbone organizes many possible causes into categories such as people, process and technology.
- Tested as
- When a stem shows a recurring symptom with several possible causes, the expected answer analyzes causes before scoping any solution.
- Trap
- Treating the first plausible cause as the root cause and stopping the analysis there.
-
Business case
The document that justifies an initiative by describing the need, the options considered, the recommended option, and its expected costs, benefits and risks.
- Remember
- The analyst contributes evidence and the solution scope to the business case, and the sponsor uses it to decide whether to invest.
- Tested as
- Later questions about prioritization, change and evaluation all refer back to what the business case promised.
- Trap
- Treating the business case as a one-time approval document instead of the yardstick used again when the solution is evaluated.
-
Value proposition
The net value the initiative is expected to deliver, meaning the benefits weighed against the cost, effort and risk of getting them.
- Remember
- Requirements are accepted, deferred or cut according to how much they contribute to the value proposition.
- Tested as
- Answers that protect the value proposition beat answers that simply add features or satisfy the most senior stakeholder.
- Trap
- Equating value with total benefit and ignoring cost, risk and time to realize it.
-
Valuation techniques
Cost-benefit analysis, return on investment (ROI), net present value (NPV), internal rate of return (IRR) and payback period are used to put a number on the value of options.
- Remember
- NPV discounts future cash flows to today, so a higher NPV is better and a negative NPV destroys value; payback ignores everything after the investment is recovered.
- Tested as
- Stems give two or three options with figures and ask which one best supports the value proposition.
- Trap
- Choosing the shortest payback when another option has a clearly higher NPV over the solution's life.
-
SWOT analysis
A structured look at internal strengths and weaknesses and external opportunities and threats, used to frame an opportunity or assess organizational readiness.
- Remember
- Strengths and weaknesses are internal to the organization; opportunities and threats come from outside it.
- Tested as
- Appears when the stem describes a market change or competitor move and asks which technique frames the opportunity.
- Trap
- Classifying a new competitor as a weakness instead of an external threat.
-
SMART objectives
Objectives written to be specific, measurable, achievable, relevant and time-bound, so success can be judged later.
- Remember
- If you cannot measure an objective, you cannot evaluate the solution against it in Domain 5.
- Tested as
- A vague goal appears in a stem, and the best analyst action rewrites it into a measurable objective tied to the business need.
- Trap
- Accepting objectives such as improve efficiency that have no baseline, target or date.
-
Stakeholder register and analysis
The register lists stakeholders with role, interest and influence; analysis tools such as the power and interest grid and RACI chart decide how to involve each one.
- Remember
- High-power, high-interest stakeholders are managed closely, but low-power groups such as end users still supply critical requirements.
- Tested as
- Questions ask which stakeholder was missed, or how to treat a group based on its power and interest.
- Trap
- Ignoring indirect stakeholders such as regulators, auditors or support teams because they never use the product.
-
Current state vs. future state
Needs assessment documents how things work today and the desired future capability, and the difference between them is the gap the solution must close.
- Remember
- Gap analysis compares current and future state; it is not the same as the solution evaluation gaps in Domain 5.
- Tested as
- A stem describes the target capability and asks what the analyst needs next, which is often an accurate picture of the current state.
- Trap
- Skipping current-state analysis because the future state seems obvious, which hides transition requirements.
-
Solution scope statement
A statement of the capabilities the solution must provide to address the need, written before detailed requirements exist.
- Remember
- Solution scope describes what the product must do at a high level; project scope describes the work needed to deliver it.
- Tested as
- Questions ask what output of needs assessment bounds later elicitation, and solution scope is the answer.
- Trap
- Confusing solution (product) scope with project scope, which belongs to the project manager.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Problem vs. symptom vs. requested solution
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Symptom | The visible effect, such as rising call volume or late shipments | Observed directly but does not explain why it happens | Writing requirements to suppress the symptom |
| Problem (root cause) | The underlying condition producing the symptom | Found through analysis and is what the solution must address | Stopping at the first cause without testing it |
| Requested solution | A stakeholder's proposed fix, such as buying a new tool | One possible option, not a statement of need | Using it as the problem statement and scoping it immediately |
NPV vs. ROI vs. payback period
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Net present value (NPV) | Present value of future cash flows minus the initial investment | Accounts for the time value of money across the full horizon | Treating a positive but smaller NPV as worse than a faster payback without context |
| Return on investment (ROI) | Net benefit divided by cost, as a percentage | Shows efficiency of the investment but usually ignores timing | Comparing ROI across options with very different durations |
| Payback period | Time until cumulative benefits recover the investment | Measures speed of recovery and ignores benefits after that point | Selecting the fastest payback as the most valuable option |
Goal vs. objective vs. requirement
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Goal | A broad outcome the organization wants, such as better customer retention | Directional and not directly measurable | Trying to accept or test a goal |
| Objective | A measurable target supporting a goal, such as cut churn 10% within 12 months | SMART and used to evaluate success | Writing it as a feature instead of an outcome |
| Requirement | A condition or capability the solution must meet to satisfy a need | Specifies the solution and traces back to an objective | Adding requirements that trace to no objective |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Scoping the requested solution
- What candidates pick
- Begin eliciting detailed requirements for the system the sponsor asked for.
- Why it looks right
- The sponsor has authority and seems to know what is needed, so starting work looks responsive.
- Why it's wrong
- Needs assessment comes first: without a defined problem, the team may build the wrong thing and the business case cannot be justified.
Clue to watch for The stem mentions a symptom (complaints, delays, costs) and a proposed tool, but no analysis of why the symptom occurs.
-
Shortest payback wins
- What candidates pick
- The option that recovers its cost fastest.
- Why it looks right
- Fast recovery sounds low-risk and is easy to compare.
- Why it's wrong
- Payback ignores benefits after break-even; when NPV or total value over the solution life is given, the higher-value option better supports the value proposition.
Clue to watch for The options list both payback periods and NPV figures, and the NPVs differ significantly.
-
Only direct users count
- What candidates pick
- Proceed with the stakeholders who will use the product day to day.
- Why it looks right
- Users seem to be the source of most requirements.
- Why it's wrong
- Regulators, auditors, support teams and downstream departments can impose requirements or block approval, and missing them causes late change.
Clue to watch for The scenario mentions regulation, data sharing, or a process handoff to another team.
-
Analyst owns the goals
- What candidates pick
- The analyst writes and approves the project goals and objectives.
- Why it looks right
- The analyst understands the need best and may draft the wording.
- Why it's wrong
- The ECO says the analyst collaborates by clarifying business needs; the sponsor and project leadership own and approve goals.
Clue to watch for The question asks for the analyst's role or best contribution rather than who decides.
-
Values are the same as requirements
- What candidates pick
- Skip value elicitation because requirements will be gathered later.
- Why it looks right
- It looks efficient to collect everything once in Analysis.
- Why it's wrong
- Stakeholder values are the baseline for prioritizing requirements; without them, prioritization becomes a contest of opinion.
Clue to watch for A later conflict over priorities, or a stem asking why values are elicited during needs assessment.
-
One authoritative source
- What candidates pick
- Use the sponsor's data alone to build the value case.
- Why it looks right
- The sponsor is accountable and the data is readily available.
- Why it's wrong
- The task requires information from a variety of sources so the value proposition is not skewed by one viewpoint.
Clue to watch for Sources disagree, or the only figures come from the person promoting the initiative.
Answer framework
When a Needs Assessment stem describes the start of an initiative, run these checks in order.
- Separate the visible symptom, the underlying problem or opportunity, and any solution a stakeholder has already proposed, and refuse to scope the proposal yet.
- Analyze causes with five whys or a fishbone diagram, and gather evidence from several independent sources before committing to a solution scope.
- Estimate value with an appropriate valuation technique such as NPV or cost-benefit analysis, and favor options that maximize net value rather than speed or feature count.
- Check that goals and objectives are measurable and trace to organizational strategy, and help the sponsor clarify them where they are vague.
- Confirm every affected stakeholder group, including regulators and downstream teams, is identified and its values captured, because those values will drive prioritization later.
Practice question
Want more like this? The PMI-PBA practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study Needs Assessment first, because it supplies the vocabulary and reference points the other four domains reuse. Start with problem framing: practice turning symptoms and requested solutions into situation statements, and work through a few five whys and fishbone exercises until you can see where a causal chain becomes actionable.
Next, put real effort into valuation. Make sure you can calculate and interpret ROI, NPV and payback, and that you can explain why NPV usually decides between options with different lifetimes. Candidates tend to underestimate this area because it looks financial rather than analytical, yet it is how the exam tests the value proposition.
Then cover stakeholders: identification, the register, power and interest analysis, and the difference between stakeholder values and requirements. Practice spotting the missing stakeholder in a scenario, especially regulators and downstream teams.
Afterward, do mixed question sets that ask what to do FIRST at the start of an initiative. Review each miss by asking whether you accepted a solution too early or skipped a group. Then move to Domain 2, where the business case and goals you studied become the context for planning.
FAQ
How much of the PMI-PBA exam is Needs Assessment?
PMI weights Needs Assessment at 18% of the exam. Applied to 200 items that is roughly 36 questions, but that number is a planning estimate; PMI does not publish per-domain counts.
Does the business analyst write the business case?
The analyst contributes to it by defining the problem or opportunity, analyzing information and estimating value, and may draft parts of it. The sponsor owns the decision to invest.
What is the difference between a problem and a requested solution?
A problem describes a condition and its impact, such as late deliveries costing customers. A requested solution is one proposed fix, such as new routing software, and should be evaluated only after the problem is understood.
Which valuation technique matters most for the exam?
Know cost-benefit analysis, ROI, NPV, IRR and payback period well enough to compare options. When figures conflict, NPV is usually the stronger measure because it covers the full life of the benefits and the time value of money.
Why are stakeholder values elicited before requirements?
Values tell you what each group cares about and why. The ECO states they provide the baseline for prioritizing requirements, so having them early keeps prioritization in Analysis grounded.
Is stakeholder identification done only once?
No. Stakeholders are identified by reviewing goals, objectives and requirements, so new requirements can reveal new stakeholders throughout the project.
How does Needs Assessment connect to Evaluation?
Evaluation measures the deployed solution against the business case and value proposition established here. Vague objectives in Needs Assessment make the solution impossible to evaluate later.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have worked through problem framing, root cause analysis, valuation and stakeholder values. Test whether you can choose the right first step when a sponsor arrives with a solution already in mind.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PMI-PBA AI tutor Get any concept explained your way