business-analyst

What this skill does

# 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
| Task | Technique | Output |
|------|-----------|--------|
| Elicit requirements | Interviews, workshops, observation | Requirements list |
| Document requirements | BRD template | Business Requirements Document |
| Map current state | Swimlane diagram, flowchart | AS-IS process map |
| Design future state | TO-BE process map | Process redesign |
| Find gaps | Gap analysis matrix | Gap analysis report |
| Manage stakeholders | RACI / Power-Interest grid | Stakeholder register |
| Document user interactions | Use case format | Use Case document |
| Prioritize requirements | MoSCoW method | Prioritized requirements |
| Validate requirements | Walkthrough, prototype review | Sign-off document |

## Instructions

### Step 1: Stakeholder Identification and Management

**Stakeholder register:**
| Stakeholder | Role | Interest Level | Influence Level | Stance | Engagement Strategy |
|-------------|------|---------------|-----------------|--------|---------------------|
| VP Operations | Executive sponsor | High | High | Champion | Weekly status briefing |
| IT Director | Technical owner | High | High | Neutral | Bi-weekly architecture review |
| Customer Service Mgr | Process owner | High | Medium | Skeptic | Involve in requirements workshop |
| End users | Operators | Medium | Low | Unaware | Survey + demo sessions |

**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:**
| Activity | Business Sponsor | BA | IT Lead | Process Owner |
|----------|-----------------|-----|---------|---------------|
| Define requirements | A | R | C | C |
| Approve BRD | A | R | I | I |
| Design solution | I | C | R | C |
| Test & validate | I | C | R | A |
| Sign off to launch | A | C | C | R |
(R=Responsible, A=Accountable, C=Consulted, I=Informed)

### 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**
| Objective | Success Metric | Target | Timeline |
|-----------|---------------|--------|----------|
| Reduce order processing time | Avg processing time | From 4 hours to 30 min | By Q3 |
| Eliminate manual data entry errors | Error rate | From 3.2% to <0.5% | By Q3 |

**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**
| ID | Requirement | Priority | Source | Notes |
|----|-------------|----------|--------|-------|
| BR-001 | System must validate order completeness before submission | Must Have | Operations Mgr | Reduce downstream errors |
| BR-002 | Automated email notification to customer upon order status change | Should Have | Customer Service | Reduce inbound call volume |
| BR-003 | Ability to generate weekly summary reports without IT involvement | Should Have | VP Operations | Currently takes 4 hours/week |

**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**
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Data migration errors | High | High | Parallel run period of 4 weeks |
| User adoption resistance | Medium | Medium | Change management program |

**10. Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Business Sponsor | | | |
| IT Director | | | |

---

### 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

```
Custo