Business Analyst

Overview

This skill covers the structured practice of business analysis—translating business problems into clear requirements, mapping current and future-state processes, identifying gaps, managing stakeholder alignment, and producing the documentation (BRDs, use cases, process maps) that enables successful project delivery. It bridges the gap between business needs and technical or operational solutions.

When to Use

• You need to document what a system or process must do (requirements gathering)
• You're mapping a current business process to find inefficiencies
• You need to perform a gap analysis between current and desired state
• You're building a Business Requirements Document (BRD)
• You need to identify and manage project stakeholders
• Writing use cases or functional specifications

When NOT to Use

• Writing user stories and sprint backlog items (use product-manager skill)
• Conducting qualitative UX research (use ux-researcher skill)
• Technical architecture or system design
• Financial modeling or ROI calculations (use a finance skill)
• Project scheduling and resource planning (use a PM tool)

Quick Reference

Instructions

Step 1: Stakeholder Identification and Management

Stakeholder register:

Power-Interest grid:

• High Power + High Interest → Manage closely (key decision makers)
• High Power + Low Interest → Keep satisfied (executive sponsors)
• Low Power + High Interest → Keep informed (operational users)
• Low Power + Low Interest → Monitor (peripheral stakeholders)

RACI matrix for project roles:

Step 2: Requirements Gathering Techniques

Technique 1 — Structured Interviews: Run 45–60 minute sessions with key stakeholders. Use open-ended questions:

• "Walk me through how you currently handle X from start to finish."
• "What are the biggest pain points with the current process?"
• "What would have to be true for this to be considered a success?"
• "If you could change one thing, what would it be?"
• "What constraints do we need to work within (regulatory, technical, budget)?"

Technique 2 — Requirements Workshop (JAD session):

• Invite 6–10 stakeholders representing all affected groups
• 2–4 hour structured session with a facilitator
• Use whiteboards or collaborative tools (Miro, Mural)
• Activities: process walkthroughs, affinity mapping, scenario walkthroughs

Technique 3 — Observation (Process Shadowing):

• Spend 1–2 hours observing end users performing the actual process
• Note what they do, workarounds they use, and pain points
• Often reveals requirements that no one thinks to mention in interviews

Technique 4 — Document Analysis:

• Review existing SOPs, training materials, system documentation
• Analyze reports, dashboards, and data that support the current process
• Review help desk tickets for common user problems

Step 3: Business Requirements Document (BRD) Template

Document Title: [Project Name] Business Requirements Document Version: 1.0 | Date: [Date] | Status: Draft / In Review / Approved Author: [BA Name] | Sponsor: [Name]

1. Executive Summary One paragraph: business problem, proposed solution, expected business value, and scope.

2. Business Objectives

3. Project Scope In Scope:

• [List what the project will address]

Out of Scope:

• [List what is explicitly excluded to prevent scope creep]

4. Current State (AS-IS) Overview Brief description of how the process/system works today.

• Current pain points (supported by data where possible)
• Volume and frequency: "200 orders processed daily by 5 team members"

5. Future State (TO-BE) Overview Description of the desired end state and how it differs from today.

6. Business Requirements

7. Assumptions and Dependencies

• Assumption: ERP system will provide API access for integration
• Dependency: IT infrastructure upgrade must complete before this project starts

8. Constraints

• Budget: $150,000 total project cost
• Timeline: Must launch before Q4 peak season
• Regulatory: Must comply with SOC 2 Type II requirements

9. Risks

10. Approval

Step 4: Process Mapping (AS-IS and TO-BE)

AS-IS Process Map — document the current state exactly as it is:

• Use swimlane diagrams (one lane per role/system)
• Map every step, decision point, and handoff
• Note pain points with 🔴 and workarounds with ⚠️
• Capture time and volume data at key steps

Swimlane notation (text format):

Customer → [Submit order form] → [Order lands in shared inbox] 
                                          ↓
Sales Rep → [Manually copy to ERP] → [Check inventory] 
                                          ↓ (if in stock)
Warehouse → [Pick and pack] → [Update ERP] → [Email customer]
                                          ↓ (if out of stock)
Sales Rep → [Call customer] → [Offer alternative] → [Cancel or modify]

Pain points: ⚠️ Manual ERP entry takes 15 min/order; 🔴 3.2% error rate on data entry

TO-BE Process Map — design the improved future state:

• Eliminate the waste/pain points identified in AS-IS
• Show automation, integration, and self-service where appropriate
• Include new systems or tools introduced

Custom