business-analyst

Files (1)

• SKILL.md

SKILL.md (first lines)

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

From NickCrew/Claude-Cortex, MIT.

More from NickCrew/Claude-Cortex