2.3 Plan Business Analysis Governance

2.3 Plan Business Analysis Governance

Overview & Purpose of BABOK Task 3.3

The primary purpose of Plan Business Analysis Governance is to define how decisions are made regarding business analysis work—including requirement prioritization, change control, reviews, approvals, and governance body escalations. Governance provides the structural framework within which business analysts and stakeholders make authoritative choices regarding requirements and designs.

Without an established governance approach, initiatives suffer from uncontrolled scope creep, unresolved decision deadlocks, unauthorized requirement changes, and ambiguous approval states. Effective governance balances control and flexibility, establishing clear accountability while enabling timely decision execution.

---

Core Elements of Business Analysis Governance

BABOK v3 identifies four critical elements when planning governance:

1. Decision-Making Process

The governance plan must specify how decisions are made when consensus cannot be reached. It answers:

• Who are the designated decision-makers? (Individual sponsor vs. Change Control Board vs. Steering Committee).
• What decision rule applies? (Unanimous consensus, majority vote, delegated authority, or executive mandate).
• What is the escalation path? Clear steps for escalating conflicts when working-level stakeholders disagree.

2. Requirement Prioritization Approach

Prioritization determines the relative importance and order of requirement execution. The BA establishes:

• Prioritization Criteria: Value alignment, cost, risk, regulatory compliance, dependency constraints, or time-to-market impact.
• Prioritization Formalities & Frameworks:
  • MoSCoW: Categorizes into Must Have (non-negotiable), Should Have (important but workaround exists), Could Have (desirable delighter), and Won't Have (out of scope for current release).
  • Kano Model: Classifies features as Basic (Must-be), Performance (Linear satisfaction), or Delighters (Excitement).
  • Timeboxing / Budgeting: Fixed resource constraints dictate how many high-priority items fit.

3. Change Control Process

Change control defines how changes to baselined requirements and designs are requested, evaluated, and approved. A robust change control workflow includes:

• Change Request Submission: Standardized intake capturing change description, rationale, and requester.
• Impact Analysis: Assessing the ripple effect across 5 dimensions: Scope, Cost/Effort, Schedule, Quality/Architecture, and Risk.
• Decision & Communication: Authorization by the Change Control Board (CCB) and formal update to baseline repositories.

4. Approval Process

The approval process establishes how sign-offs are secured for business analysis deliverables:

• Approval Type: Formal written sign-off, digital cryptographic approval, or verbal sprint review approval.
• Authority Levels: Setting financial or risk thresholds where local project leads can approve vs. requiring executive sponsor sign-off.

---

Prioritization Framework Comparison

---

Impact Analysis Dimensions in Change Control

When evaluating a proposed change, the BA must analyze five critical dimensions before presenting recommendations to the CCB:

1. Scope Impact: Does the change add new features, alter existing logic, or invalidate completed work?
2. Schedule Impact: Will the change delay milestone deadlines or critical path deliverables?
3. Cost/Resource Impact: Does it require additional development hours, license fees, or specialist skills?
4. Quality & Architecture Impact: Does it compromise system security, performance SLAs, or maintainability?
5. Risk Impact: What new operational, compliance, or technical risks are introduced?

---

BACCM Alignment in Governance

• Change: Ensure that all modifications to baseline requirements are systematically evaluated.
• Need: Verify that proposed changes align with underlying enterprise needs.
• Solution: Protect solution integrity by preventing unauthorized scope additions.
• Stakeholder: Clarify decision-making authority and escalation channels.
• Value: Prioritize high-value requirements over low-value requests.
• Context: Fit governance rules within organizational policies and compliance standards.

---

Inputs, Guidelines, and Outputs

• Inputs:

  • Business Analysis Approach: Dictates overall methodology (predictive vs. adaptive).
  • Stakeholder Engagement Approach: Identifies key decision-makers and approval roles.

• Outputs:

  • Governance Approach: Formally documents decision rules, change control workflows, prioritization frameworks, and approval authorities.

---

Enterprise Scenario: Emergency Change Request

Scenario: Two weeks prior to deploying a new insurance claims engine, a senior compliance officer submits an urgent change request to add automated tax reporting logic.

Governance Execution: The BA follows the baseline Governance Approach. Instead of immediately modifying code, the BA conducts a 5-dimension impact analysis: adding the logic requires 80 hours, delays deployment by 4 days, but prevents severe non-compliance fines. The BA presents this to the Change Control Board (CCB). The CCB approves the change, adjusts the project baseline, and formalizes the budget revision.

---

CBAP Exam Tips & Triggers

• Exam Trigger: If a stakeholder verbally asks a BA to add a "quick minor feature" to a baselined BRD, the correct BA response is to instruct the stakeholder to submit a formal Change Request for impact analysis.
• Exam Trigger: If stakeholders cannot agree on feature priorities, the BA should apply the established Prioritization Framework and escalate unresolved conflicts through the Governance Escalation Path.
• Key Distinction: Governance defines how changes are managed; it does NOT mean refusing all changes.