Business Analysis 101: Solution Evaluation Assessing Solution Limitations Gap Analysis Root Cause

What This Is

Assessing Solution Limitations is the analysis of the gap between the current (as‑is) state of a solution and the desired (to‑be) state, plus the underlying reasons why those gaps exist. In the BABOK® Guide this activity lives in the Analysis and Solution Evaluation knowledge areas. It helps the Business Analyst (BA) surface missing functionality, performance short‑falls, regulatory constraints, or hidden costs before a solution is approved or released.

Real‑world example: A financial services firm is rolling out a new Customer Relationship Management (CRM) system. After the prototype is demoed, the sales team discovers that the system cannot capture multi‑currency commissions—a critical need for their global accounts. The BA conducts a gap analysis, uncovers the root cause (the CRM’s data model was designed for a single‑currency environment), and documents the limitation so the vendor can propose a fix.

Key Terms & Techniques

• Gap Analysis – Comparing the current solution capabilities with the required capabilities; output: Gap Document (Requirements Analysis knowledge area).
• Root‑Cause Analysis (RCA) – Systematic investigation to discover why a problem exists; common techniques: 5 Whys, Fishbone (Ishikawa) Diagram; output: Root‑Cause Report (Solution Evaluation).
• As‑Is / To‑Be Models – Visual or textual representations of the existing solution and the future desired solution; deliverable: Process Model (Business Analysis Planning & Monitoring).
• Impact Assessment – Evaluating the effect of identified gaps on scope, schedule, cost, and risk; output: Impact Matrix (Solution Evaluation).
• Stakeholder Map – A diagram that shows who is affected by the limitation and who can influence its resolution; deliverable: Stakeholder Register (Business Analysis Planning & Monitoring).
• Prioritization Matrix (MoSCoW, Weighted Scoring) – Ranking gaps by business value, risk, and effort; output: Prioritized Gap List (Requirements Analysis).
• Feasibility Study – Determining whether a proposed fix is technically, financially, and operationally viable; deliverable: Feasibility Report (Solution Evaluation).
• Traceability Matrix – Linking each identified limitation back to a business need or requirement; output: Requirements Traceability Matrix (Requirements Management & Communication).
• Risk Register – Recording risks that arise from the limitation (e.g., regulatory non‑compliance) and mitigation actions; output: Risk Log (Solution Evaluation).
• Change Request – Formal request to modify the solution scope to address the gap; output: Change Request Document (Requirements Management).

Step‑by‑Step / Process Flow

1. Confirm the Baseline – Review the approved solution design, prototype, or release notes to establish what the solution currently delivers (inputs: Solution Scope, Requirements Specification).
2. Elicit & Document Limitations – Conduct workshops, interviews, or surveys with affected stakeholders to capture symptoms, work‑arounds, and complaints; record each as a Limitation in the Gap Document.
3. Perform Gap Analysis – Map each limitation against the to‑be requirements or business objectives; identify missing functionality, performance short‑falls, or compliance gaps.
4. Run Root‑Cause Analysis – For each gap, ask “Why?” repeatedly (5 Whys) or build a Fishbone diagram to trace the underlying cause (e.g., design decision, technology constraint, policy).
5. Assess Impact & Feasibility – Populate an Impact Matrix (scope, schedule, cost, risk) and a Feasibility Study to decide whether to fix, work‑around, or accept the limitation.
6. Recommend & Document – Produce a Solution Evaluation Report that includes prioritized gaps, root‑cause findings, impact assessment, and recommended actions (change request, redesign, or acceptance). Obtain stakeholder sign‑off.

Common Mistakes

• Mistake: Treating a limitation as a “requirement” and adding it to the requirements backlog without analysis.
  Correction: BABOK requires the BA to first analyze the limitation (gap & root‑cause) and then decide whether it becomes a new requirement, a change request, or an accepted risk.

• Mistake: Jumping straight to a solution (e.g., “We need a new module”) before understanding the true cause.
  Correction: Conduct a proper Root‑Cause Analysis; the BA must uncover the why before proposing what.

• Mistake: Ignoring non‑functional aspects (performance, security) when documenting gaps.
  Correction: Include both functional and non‑functional gaps; BABOK’s Solution Evaluation knowledge area explicitly calls for quality attribute assessment.

• Mistake: Updating the Traceability Matrix only after the solution is built, losing the link between the gap and its originating business need.
  Correction: Maintain the Traceability Matrix during gap analysis so each limitation can be traced back to a specific business objective or stakeholder need.

• Mistake: Failing to involve the right stakeholders (e.g., only IT staff) in the RCA workshop.
  Correction: Use the Stakeholder Map to ensure all impacted parties (business users, compliance, finance) are present; BABOK stresses Stakeholder Engagement throughout analysis.

Certification Exam Tips

1. Know the Knowledge‑Area Boundaries – Gap Analysis lives in Analysis; Root‑Cause Analysis is part of Solution Evaluation. Exam questions often test whether you can place the activity in the correct area.
2. Watch for “What’s the next step?” – After a limitation is identified, the BA should perform a Gap Analysis before creating a Change Request. Selecting “Create a requirements baseline” is a trap.
3. Prioritization Technique Choice – If a question asks how to rank gaps by business value, the answer is a Prioritization Matrix (MoSCoW, Weighted Scoring). “Use a RACI matrix” is incorrect.
4. Root‑Cause vs. Symptom – The exam may present a symptom (e.g., “users cannot upload large files”). The correct response is to apply Root‑Cause Analysis (5 Whys, Fishbone) to discover the underlying design limitation.

Quick Check Questions

1. Scenario: After a pilot of a new claims processing system, the underwriting team reports that the system rejects claims over $50,000, even though the business rule allows up to $250,000. Which technique should the BA use first?
   Answer: Root‑Cause Analysis (e.g., 5 Whys).
   Why: The symptom is a rejection error; the BA must uncover why the system enforces the lower limit before documenting a gap.

2. Scenario: A stakeholder list shows that the finance department, compliance officer, and sales manager all have concerns about a data‑privacy limitation. What artifact helps the BA ensure all voices are captured?
   Answer: Stakeholder Map (or Stakeholder Register).
   Why: It visualizes who is impacted and who can influence the resolution, ensuring comprehensive elicitation.

3. Scenario: The BA has identified three gaps: missing multi‑currency support, slow report generation, and lack of audit logging. The project sponsor asks which gap should be addressed first. Which prioritization method is most appropriate?
   Answer: MoSCoW Prioritization (or Weighted Scoring).
   Why: It ranks gaps by Must, Should, Could, Won’t, aligning with business value and risk.

Last‑Minute Cram Sheet (10 one‑liners)

1. ⚠️ Elicitation = activity; Requirements = output (BABOK §5).
2. Gap Analysis belongs to the Analysis knowledge area; its primary output is a Gap Document.
3. Root‑Cause Analysis is a Solution Evaluation technique; deliverable = Root‑Cause Report.
4. As‑Is / To‑Be models are created in Business Analysis Planning & Monitoring to set the baseline for gap work.
5. Impact Matrix links each gap to Scope, Schedule, Cost, Risk – essential for the Solution Evaluation decision.
6. Fishbone Diagram and 5 Whys are the two most common RCA tools; both produce a Root‑Cause statement.
7. Prioritization Matrix (MoSCoW, Weighted Scoring) is the go‑to technique for ranking gaps; it is not a risk‑assessment tool.
8. Traceability Matrix must be updated during gap analysis to keep the link to original business needs.
9. Change Request is the formal output when a gap is approved for remediation; it lives in Requirements Management & Communication.
10. Stakeholder Map → Stakeholder Register → ensures the BA engages the right people before any RCA or Gap session.