PMI Professional in Business Analysis

Projects fail when they solve the wrong problem. You define the problem or opportunity, find its causes, describe the current and desired states, and decide what the business actually needs.

• Defining the problem or opportunity
• Root cause analysis
• Current state analysis
• Future state and desired outcomes
• Gap analysis
• Stating the business need

You build A needs assessment with root cause, current state and gap analysis.

A need becomes a project through a case. You compare solution options, estimate benefits and costs, set the boundaries of the solution, and agree measures of success.

• Identifying and comparing solution options
• Cost-benefit analysis and financial measures
• Feasibility: technical, operational and organizational
• Defining solution scope and boundaries
• Success criteria and measures
• Writing the business case

You build A business case with options, a recommendation and success measures.

Analysis needs its own plan. You identify stakeholders, choose techniques and an approach, plan how requirements will be managed, and agree who decides what.

• Stakeholder identification and analysis
• Choosing an analysis approach
• The business analysis plan
• The requirements management plan
• Planning communication and decision rights
• Estimating the analysis effort

You build A business analysis plan and a requirements management plan.

Requirements do not simply arrive. You use interviews, workshops, observation, surveys, prototypes and document review to draw out what people need, including what they cannot yet say.

• Preparing for elicitation
• Interviews and questionnaires
• Facilitated workshops
• Observation and shadowing users at work
• Prototypes, mock-ups and storyboards
• Document and data analysis
• Confirming and recording results

You build An elicitation plan and notes from two techniques applied to one stakeholder group.

Raw needs become requirements others can build from. You sort them by type, write them clearly with acceptance criteria, decompose them, and resolve conflicts between stakeholders.

• Business, stakeholder, solution and transition requirements
• Functional and non-functional requirements
• Writing clear, testable requirements
• User stories, use cases and acceptance criteria
• Decomposing and organizing requirements
• Resolving conflicts and gaps

You build A requirements specification with acceptance criteria for one solution.

A picture shows what a paragraph hides. You build process, data, context and interface models, and use decision tables and state models to make rules and behavior precise.

• Context diagrams and scope models
• Process models and BPMN
• Data models and entity relationships
• Use case and UML models
• Wireframes and interface models
• Decision tables and rule models
• State and sequence models

You build A set of models that describes one business process and its data.

Requirements must be right and agreed. You check them for quality, confirm them with stakeholders, order them by value and risk, and set the baseline the team will work to.

• Verification and validation techniques
• Reviews, inspections and walkthroughs
• Prioritization methods
• Value, risk and dependency in ordering
• Approval and baselining
• Managing requirement conflicts at sign-off

You build A prioritized, approved requirements baseline.

Every requirement should connect to a need and to proof that it was met. You build traceability, control changes, assess their impact, and keep the baseline honest.

• Traceability matrices and attributes
• Tracing from need to test
• Change control for requirements
• Impact analysis of a change
• Version control and baselines
• Handling emerging and volatile requirements

You build A traceability matrix and a change log for one requirements set.

Requirements move as the work progresses. You track their status, check that the solution is being built to them, keep stakeholders informed, and spot drift early.

• Tracking requirement status
• Monitoring development and testing against requirements
• Managing dependencies with the delivery team
• Communicating status to stakeholders
• Detecting scope drift
• Measures of requirements health

You build A requirements status report with drift indicators.

The work ends when value is shown, not when the product ships. You plan acceptance, assess whether the solution met the need, measure benefits, and recommend what to do next.

• Acceptance criteria and acceptance testing
• Evaluating results against success measures
• Identifying defects and gaps
• Benefits measurement after release
• Recommendations for improvement
• Transition to operations and support

You build A solution evaluation report that compares results with the original need.

Analysis does not stop when delivery turns iterative. You apply it to backlogs, stories and short cycles, and adjust techniques to keep the need and its measures in view.

• The analyst’s part in an agile team
• Backlog creation and refinement
• Stories, acceptance criteria and examples
• Just-in-time analysis and models
• Stakeholder collaboration in iterations
• Blending predictive and agile analysis

You build A backlog and story set derived from a business need.

One initiative carries the course. You assess the need, plan the analysis, elicit and specify requirements, trace and baseline them, and show how you would evaluate the result.

• Assessing the need and building the case
• Planning and eliciting
• Specifying, modeling and validating
• Tracing and managing change
• Evaluating the solution

You build A complete requirements package with needs, models, traceability and an evaluation plan.