14.2 Solution Gap Analysis, Discrepancy Resolution & Workarounds

14.2 Solution Gap Analysis, Discrepancy Resolution & Workarounds

[!NOTE] PMI-PBA Examination Alignment: In Domain 5 (Evaluation), Task 2 requires candidates to: "Analyze solution gaps and discrepancies between the developed solution and original requirements to determine impacts and recommend resolution options." Exam scenarios frequently test the practitioner's ability to evaluate discrepancies during late-stage testing or pilot rollouts, decouple technical severity from business priority, choose among the four resolution pathways (fix, defer, descope, workaround), and design compliant, cost-effective manual workarounds without introducing operational chaos.

---

The Anatomy of a Solution Gap versus a Technical Defect

In business analysis practice, practitioners must distinguish between a simple technical defect (a bug) and a true solution gap:

1. Technical Defect (Software Bug)

• Definition: A direct divergence between the approved software specification and the actual behavior of the compiled code.
• Example: The specification states that the checkout total must calculate state sales tax, but the code throws an arithmetic null-pointer exception whenever an order contains digital gift cards.
• Resolution: The developer reviews the code, identifies the missing null check, applies a patch, and re-submits for verification.

2. Solution Gap (Operational & Strategic Delta)

• Definition: A condition where the software functions exactly as specified and coded, but the delivered capability fails to satisfy the underlying business need, or an unanticipated operational variance prevents the realization of business value.
• Example: The system successfully calculates state sales tax exactly as designed, but during live pilot deployment, the enterprise discovers that a newly enacted interstate commerce tax exemption requires capturing county-level agricultural tax exemption certificates—a workflow never elicited or specified in the original requirements baseline.
• Resolution: Requires root-cause analysis, business impact assessment, stakeholder re-alignment, and adjudication through formal governance pathways.

+===================================================================================================+
|                                 ROOT CAUSES OF SOLUTION GAPS                                      |
+===================================================================================================+
|                                                                                                   |
|   1. Elicitation & Scope Omissions                                                                |
|      • Unidentified edge cases, missing operational exception paths, or unconsulted SMEs.         |
|                                                                                                   |
|   2. Ambiguous or Untestable Acceptance Criteria                                                  |
|      • Engineering built what was written, but what was written was open to interpretation.       |
|                                                                                                   |
|   3. Environmental & Market Drift                                                                 |
|      • Business policies, statutory regulations, or competitor products shifted during build.     |
|                                                                                                   |
|   4. External Integration & Legacy System Variances                                               |
|      • Upstream or downstream partner systems deliver data schemas that diverge from documented   |
|        API interface agreements.                                                                  |
+===================================================================================================+

---

Techniques for Uncovering Latent Solution Gaps

Many solution gaps do not emerge in clean laboratory test environments; they remain dormant until the solution encounters real-world human behavior, dirty legacy data, and complex operational handoffs. The business analyst deploys four specialized techniques to uncover these hidden deltas before full-scale enterprise release:

1. Pilot Deployments and Canary Releases

• Mechanism: Rolling out the solution to a restricted, representative subset of the target population (e.g., deploying a new retail point-of-sale system to 3 stores out of 500, or routing 5% of web traffic to a new payment router).
• Value: Exposes unpredicted human workflows, local environmental friction, network bandwidth throttling, and physical ergonomics that cannot be simulated in a test lab.

2. Shadow Processing & Parallel Operations

• Mechanism: Running live production transactions simultaneously through both the existing legacy system and the new solution increment, comparing transaction outputs, ledger balances, and exception rates side-by-side.
• Value: Instantly exposes discrepancies in business rule calculations, rounding mechanics, and data reconciliation without risking live operations or customer experience.

3. Contextual Inquiry and Observational Shadowing

• Mechanism: The BA physically or virtually sits alongside operational end users as they interact with the pilot release during live operational shifts.
• Value: Identifies unspoken cognitive friction—such as users writing down transaction numbers on sticky notes, switching back and forth between secondary browser tabs, or hesitating at confusing UI terminology.

4. Synthetic Stress & Boundary Volumetrics

• Mechanism: Injecting extreme, multi-variable transactional batches simulating catastrophic business conditions (e.g., simulating end-of-quarter financial closing combined with a cyber-attack DDoS surge and third-party payment gateway outages).
• Value: Demonstrates how the system handles graceful degradation and operational recovery.

---

Discrepancy Adjudication: Decoupling Severity from Priority

One of the most heavily tested principles on the PMI-PBA examination is the governance discipline of Discrepancy Adjudication. In high-pressure delivery environments, engineering teams and business stakeholders frequently argue over defects because they conflate Technical Severity with Business Priority.

A certified PMI-PBA practitioner enforces a strict multi-dimensional decoupling between these two concepts:

                        DISCREPANCY ADJUDICATION MATRIX
                        
            ┌─────────────────────────────┬─────────────────────────────┐
            │ HIGH SEVERITY / LOW PRIORITY │ HIGH SEVERITY / HIGH PRIORITY│
            │                             │                             │
            │ • Severe system crash or    │ • Core transactional flow   │
            │   fatal exception, BUT in an│   completely blocked with   │
   HIGH     │   obscure feature that runs │   zero workaround.          │
            │   once annually.            │                             │
            │ • ACTION: Defer fix to      │ • ACTION: Emergency hotfix; │
TECHNICAL   │   subsequent release.       │   block production cutover. │
SEVERITY    ├─────────────────────────────┼─────────────────────────────┤
            │ LOW SEVERITY / LOW PRIORITY │ LOW SEVERITY / HIGH PRIORITY │
            │                             │                             │
            │ • Cosmetic typo on an       │ • Typo on a public-facing   │
            │   internal admin report     │   legal disclosure that     │
   LOW      │   viewed by 2 people.       │   violates statutory law.   │
            │ • ACTION: Backlog backlog   │ • ACTION: Must fix before   │
            │   cleanup when time permits.│   launch; high legal risk.  │
            └─────────────────────────────┴─────────────────────────────┘
                         LOW                           HIGH
                         
                                  BUSINESS PRIORITY

1. Technical Severity (System-Level Consequence)

• Evaluation Basis: The degree of technical impact the defect exerts on the software infrastructure, data integrity, or system stability.
• Severity Tiers:
  • Severity 1 (Blocker / Catastrophic): System crashes, complete data corruption, primary server unresponsiveness, security breach.
  • Severity 2 (Critical): Major feature failure with no technical bypass; primary workflow broken.
  • Severity 3 (Major): Non-critical feature failure, or major failure with an existing automated software bypass.
  • Severity 4 (Minor): Minor system anomaly, interface alignment error, or benign error handling message.
  • Severity 5 (Cosmetic): Font discrepancies, spelling typos, or minor visual styling defects.

2. Business Priority (Enterprise-Level Consequence)

• Evaluation Basis: The urgency with which the business requires resolution, measured by financial loss, operational impairment, customer churn, legal liability, or strategic schedule deadlines.
• Priority Tiers:
  • Priority 1 (Urgent / Must-Fix for Launch): Solution cannot go live without resolution; intolerable commercial, legal, or operational risk.
  • Priority 2 (High / Fast-Follow Patch): Solution can launch with an interim procedure, but a permanent software patch must deploy within 14–30 days.
  • Priority 3 (Medium / Standard Release Backlog): Resolution scheduled into a standard post-launch sprint or quarterly maintenance release.
  • Priority 4 (Low / Desirable Enhancement): Low-value fix addressed only if spare development capacity permits.

The Defect Triage Committee

The BA chairs or actively facilitates the multi-disciplinary Defect Triage Committee (comprising the Lead BA, QA Lead, Technical Architect, Product Owner, and Business Sponsor). The BA ensures that discussions do not devolve into emotional arguments, using empirical evidence from the RTM and business case to adjudicate every discrepancy objectively.

The Four Definitive Resolution Pathways

When a solution gap or discrepancy is analyzed and adjudicated, the business analyst facilitates executive alignment on one of four structured resolution pathways:

Pathway 1: Immediate Technical Fix / Re-Engineering

• Application: The discrepancy represents a Priority 1 business issue (e.g., patient health data exposure, unauthorized fund withdrawals, regulatory violation) for which no manual or operational workaround is legally or practically viable.
• Governance Action: The BA documents the blast radius across downstream components. The project manager halts the release gate. Engineering develops a hotfix. The QA and BA teams execute targeted re-testing and full regression testing. The release gate is re-evaluated.

Pathway 2: Deferred Release / Backlog Scheduling

• Application: The discrepancy causes operational inconvenience or affects a secondary feature, but does not jeopardize core business operations or regulatory compliance. A software fix is desirable, but delaying the entire enterprise launch would incur unacceptable financial costs of delay.
• Governance Action: The BA logs the defect in the product backlog, links it to the governing requirement in the RTM, assigns it an approved post-launch sprint (e.g., Release 1.1 or Sprint 14), and secures written sign-off from the product owner and business sponsor.

Pathway 3: Permanent Scope Reduction / Descoping

• Application: The gap analysis reveals that the developed system lacks a specific feature, but comprehensive business analysis demonstrates that the feature is obsolete, delivers negative return on investment (ROI), or that user needs have evolved to render the requirement unnecessary.
• Governance Action: Rather than wasting capital engineering an unneeded feature, the BA prepares a formal change request to permanently remove the requirement from the project scope baseline. The change request routes to the Change Control Board (CCB). Upon CCB approval, the RTM is updated to mark the requirement as "De-scoped/Retired," and contract or budget adjustments are finalized.

Pathway 4: Operational Manual Workaround

• Application: The enterprise must launch by an unmovable deadline (e.g., statutory regulatory effective date, market trade show, contractual partner obligation), but a software defect cannot be resolved in time. However, an operational manual procedure can bridge the gap temporarily without risking data integrity or legal compliance.
• Governance Action: The BA designs, documents, risk-assesses, and validates the manual workaround, establishing a strict sunsetting expiration date.

---

Engineering and Governing Operational Workarounds

An operational workaround is a temporary, documented procedural bridge designed to achieve a business outcome when the automated software solution fails, exhibits a defect, or lacks a specific capability. Workarounds are not informal "hacks" or unvetted tribal knowledge; in enterprise environments, workarounds must be engineered with the same rigor as software code.

The Anatomy of an Enterprise-Grade Workaround

A complete workaround package authored by a business analyst must incorporate seven mandatory components:

1. Trigger Condition: The precise operational event or error code that mandates activating the workaround (e.g., "When a foreign passport holder attempts digital onboarding and receives Error Code ERR-KYC-902").
2. Step-by-Step Standard Operating Procedure (SOP): Granular, sequential instructions guiding operational personnel through the manual steps (e.g., "1. Download the unverified identity PDF; 2. Log into the LexisNexis manual verification portal; 3. Enter passport metadata; 4. Capture verification hash").
3. Roles and Responsibilities (RACI Matrix): Clear designation of who executes the manual procedure, who reviews and approves the outcome, who is consulted, and who is informed.
4. Dual-Control and Authorization Safeguards: For financial, clinical, or security procedures, workarounds must mandate dual-authorization (maker-checker controls) to prevent fraud or human error during manual data manipulation.
5. Audit Logging and Data Reconciliation: A mandatory tracking log (e.g., an encrypted, access-controlled spreadsheet or auxiliary ticketing queue) recording every instance the workaround is invoked, the customer ID, the employee ID, the timestamp, and the reconciliation status.
6. Financial Cost-Benefit Assessment: An analysis quantifying the true labor cost of the workaround. If an automated process cost $0.10 per transaction, and the manual workaround requires 15 minutes of an analyst's time ($12.50 per transaction) across 1,000 daily transactions, the workaround costs the enterprise $12,500 per day in operational overhead.
7. Hard Expiration / Sunset Date: Every workaround must possess an immutable expiration date tied to a scheduled software release (e.g., "This workaround expires on November 15 upon deployment of Hotfix Build v2.4.1"). Without an expiration date, temporary workarounds become permanent, dangerous operational debt.

---

Solution Gap Discrepancy Adjudication Framework Table

The following framework illustrates a real-world discrepancy adjudication log for an enterprise Logistics and Global Supply Chain Fulfillment Platform: