Business Analysis Frameworks practice questions

Identify Stakeholders, then Analyze Stakeholders, then Plan Stakeholder Engagement, then Manage Stakeholder Engagement, then Monitor Stakeholder Engagement

Why wrong: This sequence includes 'Analyze Stakeholders' after Identify, which is not a separate PMBOK process. The correct order should have Plan Stakeholder Engagement right after Identify.

Identify Stakeholders, then Manage Stakeholder Engagement, then Plan Stakeholder Engagement, then Monitor Stakeholder Engagement, then Analyze Stakeholders

Why wrong: Incorrect order. Manage and Plan are swapped, and Analyze is placed last.

Plan Stakeholder Engagement, then Identify Stakeholders, then Analyze Stakeholders, then Manage Stakeholder Engagement, then Monitor Stakeholder Engagement

Why wrong: Incorrect order. Plan should not come first; Identify comes first.

Lack of traceability

Why wrong: Traceability helps manage changes but does not cause the gap.

Incorrect prioritization

Why wrong: Prioritization affects sequence, not correctness.

Poor elicitation technique

Why wrong: Elicitation may be fine; the issue is validation, not collection.

Requirements traceability matrix

Why wrong: Requirements traceability matrix links requirements, not financials.

Stakeholder register

Why wrong: Stakeholder register identifies stakeholders, not financials.

Work breakdown structure

Why wrong: WBS decomposes work.

Inadequate requirements prioritization

Why wrong: Inadequate requirements prioritization is not the root cause of scope creep; scope creep stems from uncontrolled changes, not from prioritization issues.

Lack of stakeholder identification

Why wrong: Lack of stakeholder identification can lead to missing requirements but is not the primary root cause of scope creep; poor change control is the main cause.

Insufficient testing

Why wrong: Insufficient testing occurs after development and does not cause scope creep; scope creep is about adding unauthorized features.

Scrum

Why wrong: Scrum is an agile framework focused on iterative delivery and is not suitable for a predictive approach.

Six Sigma

Why wrong: Six Sigma focuses on reducing process variation through DMAIC, but the scenario requires a framework for reconciling conflicting stakeholder requirements across departments, not for optimising an existing process. The predictive approach demanded by the sponsor aligns with a structured requirements-elicitation and prioritisation method, which Six Sigma’s statistical control tools do not provide. It is tempting because Six Sigma is often used in large-scale process improvement projects, and it would be correct if the goal were to standardise a single, defective process rather than to negotiate divergent requirements.

Rational Unified Process (RUP)

Why wrong: Rational Unified Process (RUP) is an iterative framework that does not align with a pure predictive approach and is outside the PMI-CAPM syllabus.

To design the technical architecture of the proposed solution

Why wrong: Design is a separate activity after requirements are defined.

To validate that the solution meets business requirements

Why wrong: This is solution evaluation, done after implementation.

To prioritize projects based on return on investment

Why wrong: Prioritization may use needs assessment output, but it's not the primary purpose.

Create a RACI matrix to clarify stakeholders' roles and responsibilities.

Why wrong: RACI clarifies who does what but doesn't address conflict resolution or prioritization.

Perform a detailed cost-benefit analysis to determine the best technical solution.

Why wrong: Cost-benefit analysis is useful but insufficient to handle ongoing stakeholder conflicts.

Propose a Waterfall approach to finalize all requirements upfront and avoid changes.

Why wrong: Waterfall is inflexible and unlikely to satisfy all parties with evolving needs.

Immediately implement a change control process to manage scope changes.

Why wrong: This treats symptoms, not the root cause of misalignment.

Train the business analyst on the project's requirements gathering techniques.

Why wrong: The issue is framework alignment, not lack of training.

Update the requirements documentation to include a traceability matrix.

Why wrong: This improves documentation but does not solve the process misalignment.

User stories

Why wrong: User stories are detailed requirements, not high-level scope.

Business case

Why wrong: A business case justifies the project’s viability through cost-benefit analysis and strategic alignment, not by documenting the solution’s high-level boundaries and capabilities. The stem asks for an artifact that defines the solution scope, which is the role of the solution scope statement. The business case is tempting because it is created early in the planning phase and often outlines the problem or opportunity, leading one to assume it also captures solution boundaries; it would be correct if the question asked for the artifact that authorises project initiation or secures funding approval.

Work breakdown structure (WBS)

Why wrong: The WBS decomposes deliverables, not solution scope.

Prioritize Requirement X because it is regulatory, and defer Requirement Y.

Why wrong: This bypasses stakeholder input and may not be optimal.

Escalate to the steering committee for a decision.

Why wrong: Escalation without analysis is premature.

Include both requirements and extend the project deadline.

Why wrong: Extending deadline may not be feasible and bypasses conflict resolution.

Brainstorming with the project team

Why wrong: May not capture all stakeholders, especially those outside the team.

Conducting one-on-one interviews with known stakeholders

Why wrong: Interviews are effective but may not identify unknown stakeholders.

Distributing a questionnaire to the organization

Why wrong: Questionnaires may have low response and miss indirect stakeholders.

Escalate directly to the project sponsor.

Why wrong: Escalation without analysis is not professional.

Modify the requirement to avoid the constraint without informing stakeholders.

Why wrong: Changing requirements without approval is unethical and risky.

Accept the project manager's decision and proceed.

Why wrong: This ignores the business analyst's responsibility to validate feasibility.

Schedule variance

Why wrong: Schedule variance measures time performance, not requirements quality.

Number of requirements traced to test cases

Why wrong: Traceability indicates coverage, not correctness of requirements.

Stakeholder satisfaction survey results

Why wrong: Satisfaction is important but subjective and not a direct metric of requirements process.

Alignment with industry standards

Why wrong: Industry standards may not be cost-effective for small projects.

Comprehensiveness to cover all possible scenarios

Why wrong: Comprehensive frameworks may be too heavy for small projects.

Integration with existing project management tools

Why wrong: Tool integration is helpful but not the most important for framework selection.

Stakeholder engagement

Why wrong: Stakeholder engagement is a task, not a separate knowledge area.

Procurement management

Why wrong: Procurement is not a core BA component.

Risk management

Why wrong: Risk management is a project management knowledge area.

SWOT analysis

Why wrong: SWOT analysis is used for strategic planning, not requirements elicitation.

Critical path method

Why wrong: Critical path method is for scheduling, not elicitation.

Immediately escalate to the project sponsor to decide whether to include the requirement.

Why wrong: Escalation without impact analysis is premature and not following the framework.

Add the requirement to the requirements document and adjust the project plan accordingly.

Why wrong: Adding without prioritization and approval can lead to scope creep and unrealistic expectations.

Reject the requirement because it was not identified during elicitation and will delay the project.

Why wrong: Rejecting without analysis may miss a critical need and damage stakeholder relationships.

Continue with the same questions but provide a glossary of technical terms.

Why wrong: A glossary may help but does not address the root cause of overly technical questions.

Replace interviews with a review of existing documentation.

Why wrong: Documentation may not capture current or future needs and misses stakeholder interaction.

Reduce the number of stakeholders to only those with technical backgrounds.

Why wrong: This may exclude key business stakeholders and lead to incomplete requirements.

Reject the feature because it exceeds the budget.

Why wrong: The BA should not unilaterally reject a feature without stakeholder consensus.

Add the feature to the backlog but flag it as out of scope.

Why wrong: This does not resolve the conflict and may lead to scope creep.

Request a budget increase from the project sponsor.

Why wrong: The BA should first explore options and gain agreement before escalating.

To document the final version of requirements after project closure.

Why wrong: The RTM is maintained throughout the project, not only at closure.

To assign requirements to specific team members.

Why wrong: Assignment of tasks is typically done in the work breakdown structure.

To estimate the cost of each requirement.

Why wrong: Cost estimation uses other tools and techniques.