3.3 Solution Option Evaluation: Feasibility Studies & Make/Buy/COTS Tradeoffs

3.3 Solution Option Evaluation: Feasibility Studies & Make/Buy/COTS Tradeoffs

[!NOTE] PMI-PBA Exam Context: In Needs Assessment, evaluating solution options and conducting feasibility studies represents the culmination of Domain 1 (Task 2 & Task 4). Exam questions frequently test your mastery of the OTESL feasibility dimensions, the strategic criteria governing Make vs. Buy vs. COTS/SaaS decisions, the "iceberg principle" of Total Cost of Ownership (TCO), and the business analyst's role in conducting objective, requirements-driven vendor evaluations.

Once capability gaps are identified, the organization must decide how to bridge them. It is rare that only a single solution pathway exists. A mature business analysis practice generates and evaluates multiple viable solution options before committing capital.

The business analyst must never function as a rubber stamp for pre-selected solutions. Whether an executive is enamored with a vendor sales presentation or engineering is determined to build an in-house platform from scratch, the BA is responsible for executing a structured, objective, and data-driven Feasibility Analysis.

---

The OTESL Feasibility Framework

On the PMI-PBA exam, the primary standard for evaluating solution options is the OTESL Framework, which analyzes proposed solutions across five interdependent feasibility dimensions:

                    ┌─────────────────────────────────────────┐
                    │        The OTESL Feasibility Lens        │
                    └────────────────────┬────────────────────┘
                                         │
        ┌────────────────┬───────────────┼───────────────┬────────────────┐
        ▼                ▼               ▼               ▼                ▼
   Operational       Technical        Economic        Schedule    Legal/Regulatory
   • Culture         • Architecture   • NPV / ROI     • Deadlines • Data Privacy
   • Change impact   • Legacy APIs    • CapEx / OpEx  • Milestones• Licensing
   • Usability       • Scalability    • 5-Year TCO    • Resources • Compliance

1. Operational Feasibility

Evaluates how well the proposed solution fits the organization's existing culture, operational workflows, and human capabilities:

• Will frontline employees embrace the new system, or will cultural resistance cause system abandonment?
• Does the organization possess the operational maturity to execute new business processes?
• What degree of organizational change management (OCM) and training is required?

2. Technical Feasibility

Assesses whether the solution can be engineered, integrated, and scaled within the enterprise's architectural and technological constraints:

• Is the proposed technology mature and proven, or is it bleeding-edge and unverified?
• Does internal IT have the requisite expertise to develop, maintain, and support the architecture?
• Can the platform integrate seamlessly with existing legacy mainframes, enterprise data warehouses, and identity providers?
• Can the system meet non-functional performance benchmarks (e.g., 10,000 transactions per second with sub-50ms latency)?

3. Economic Feasibility

Appraises the financial viability and business return of the solution:

• Does the initiative generate a positive Net Present Value (NPV) and Return on Investment (ROI) across its projected lifecycle?
• What is the discounted Payback Period?
• Does the organization have sufficient capital expenditure (CapEx) or operational expenditure (OpEx) budget to fund the complete lifecycle?

4. Schedule Feasibility

Evaluates whether the solution can be successfully delivered within hard organizational or market deadlines:

• Can the solution be fully deployed before critical statutory or compliance deadlines take effect (e.g., new federal reporting mandates)?
• Are critical-path dependencies (e.g., third-party vendor integrations, data migration runs) achievable given current staffing levels?

5. Legal, Ethical, and Regulatory Feasibility

Ensures the proposed solution complies with all jurisdictional laws, industry mandates, and contractual obligations:

• Does the solution comply with strict data residency and privacy statutes (e.g., GDPR, CCPA/CPRA, HIPAA)?
• Are there intellectual property, patent infringement, or open-source licensing risks?
• Does the architecture satisfy strict industry security standards (e.g., PCI-DSS, SOC 2 Type II, ISO 27001)?

---

The Make vs. Buy vs. COTS vs. SaaS Decision Dilemma

One of the most consequential strategic choices in solution option evaluation is selecting the delivery modality. The business analyst analyzes the trade-offs among four primary archetypes:

+-------------------------------------------------------------------------------------+
|                     Strategic Delivery Archetype Comparison                         |
+-------------------------------------------------------------------------------------+
| MODALITY        | BEST SUITED FOR                      | PRIMARY ADVANTAGE / RISK    |
|-----------------+--------------------------------------+-----------------------------|
| Custom Build    | Core competitive advantage, highly   | Max flexibility & IP control|
| (Make)          | proprietary algorithms/workflows.    | / High CapEx & tech debt.   |
|-----------------+--------------------------------------+-----------------------------|
| Commercial COTS | Standard industry processes hosted   | Proven features & support   |
| (Buy On-Prem)   | on-premise for deep data control.    | / Customization lock-in trap|
|-----------------+--------------------------------------+-----------------------------|
| Cloud SaaS      | Commodity enterprise functions       | Rapid deployment & low CapEx|
| (Cloud Service) | (CRM, HRIS, General Ledger).         | / Loss of control & recurring|
|-----------------+--------------------------------------+-----------------------------|
| Business Process| Low-budget operational bottlenecks;  | Zero software acquisition   |
| Optimization    | non-technical root causes.           | / Limited scalability.      |
+-------------------------------------------------------------------------------------+

1. Custom In-House Development ("Make")

• Strategic Rationale: Pursued when the capability represents the company's core competitive differentiator—the proprietary "secret sauce" that distinguishes it in the marketplace (e.g., Amazon's recommendation engine, a hedge fund's high-frequency trading algorithm). Custom development provides total control over the architecture, user experience, and roadmap.
• Associated Risks: High upfront Capital Expenditure (CapEx), lengthy delivery timelines, risk of software defects, and permanent organizational responsibility for maintenance, patching, security vulnerabilities, and legacy technical debt.

2. Commercial Off-The-Shelf ("Buy / COTS")

• Strategic Rationale: Pursued when the business need centers on well-established enterprise workflows (e.g., ERP, warehouse management, billing). COTS solutions offer proven functionality, vendor product roadmaps, and peer-group testing.
• The Dangerous "Customization Trap": When organizations attempt to heavily customize COTS packages to match their legacy, idiosyncratic business processes, implementation costs skyrocket, future vendor upgrade pathways are broken, and the platform becomes an unmaintainable "Frankenstein" system. PMI-PBA best practice dictates that organizations adopt process re-engineering to match the COTS tool rather than customizing the COTS tool to match broken legacy processes.

3. Software-as-a-Service ("SaaS / Cloud")

• Strategic Rationale: Modern enterprise standard for commodity business capabilities (e.g., Salesforce for CRM, Workday for HRIS). Rapid time-to-market, automated vendor-managed patching, zero local server maintenance, and shifts expenditures from upfront CapEx to predictable subscription OpEx.
• Associated Risks: Long-term recurring subscription cost escalation, data residency and privacy concerns (data residing in multi-tenant cloud environments), reliance on vendor availability SLAs, and limited capability to customize specialized workflows.

4. Business Process Optimization (BPO / Lean Alternative)

• Strategic Rationale: The business analyst must always evaluate whether a technology acquisition is truly necessary. Many performance gaps stem from bloated approval hierarchies, redundant manual handoffs, or ambiguous policies. Eliminating non-value-add steps through Lean or Six Sigma process re-engineering often resolves the need with zero software development.

---

Total Cost of Ownership (TCO): The Iceberg Principle

Executive decision-makers frequently fall victim to the visible price fallacy—comparing solutions solely on their initial acquisition or licensing quote. The business analyst counters this distortion by developing a comprehensive Total Cost of Ownership (TCO) model spanning a 3- to 5-year operational lifecycle.

              ▲
             / \       VISIBLE ACQUISITION COSTS (15 - 25%)
            /   \      • Initial software licenses
           /     \     • Base subscription fees / Hardware purchase
          /───────\  ◄───────────────────────────────────────────── [ Waterline ]
         /         \
        /           \  SUBMERGED OPERATIONAL & LIFECYCLE COSTS (75 - 85%)
       /             \ • Custom integration & API middleware engineering
      /               \• Data cleansing, ETL scripting, & legacy migration
     /                 \• User training, re-skilling, & change management (OCM)
    /                   \• Annual vendor maintenance fees (18-25% of license/yr)
   /                     \• Cloud infrastructure consumption & data egress
  /                       \• Technical debt remediation & future upgrades
 /─────────────────────────\• Eventual decommissioning & data archiving

Submerged Cost Categories to Model in TCO:

1. Integration and Customization: Developing and maintaining API connectors between the new platform and legacy enterprise systems.
2. Data Migration and Cleansing: Extracting, scrubbing, transforming, and validating millions of legacy records.
3. Annual Maintenance and Support: COTS software typically charges 18% to 25% of the initial perpetual license fee annually for maintenance, security patches, and support.
4. Infrastructure and Cloud Hosting: Compute instances, database storage, backup redundancy, network bandwidth, and disaster recovery hosting.
5. Organizational Change Management (OCM): Developing training curriculums, conducting user workshops, productivity loss during the initial learning curve, and support desk staffing.
6. Decommissioning and Archiving: Costs associated with safely sunsetting legacy platforms, auditing data completeness, and paying long-term read-only archival storage.

---

Multi-Criteria Feasibility Comparison Matrix

To synthesize solution evaluations for executive steering committees, the business analyst builds a weighted Feasibility Comparison Matrix. The following matrix demonstrates how four alternative solution pathways were evaluated for an enterprise claims processing modernization:

---

Requirements-Driven Vendor Evaluation and Proof of Concept (PoC)

When solution options involve commercial software or third-party cloud vendors, the business analyst plays a pivotal role in ensuring that vendor selection is driven by validated requirements, not vendor sales showmanship.

Requirements Baseline (Functional & Non-Functional)
                       │
                       ▼
Request for Information (RFI) ──> Broad market research (5 to 10 vendors)
                       │
                       ▼
Request for Proposal (RFP)    ──> Detailed scoring against weighted requirements (Shortlist 3)
                       │
                       ▼
Scripted Vendor Demonstrations──> Standardized business scenarios with identical test data
                       │
                       ▼
Proof of Concept (PoC Spike)  ──> Time-boxed technical test of high-risk integrations
                       │
                       ▼
Final Vendor Contract & Business Case Approval

Best Practices for Vendor Evaluations:

1. Standardized Scripted Demonstrations: Never allow software vendors to present generic marketing demonstrations. The BA develops detailed, scripted operational scenarios containing representative enterprise data, requiring each competing vendor to execute identical business processes during their presentation.
2. RFI vs. RFP vs. RFQ: Understand the distinct procurement instruments: RFI (Request for Information) gathers broad market capabilities; RFP (Request for Proposal) evaluates detailed technical and functional compliance against weighted requirements; RFQ (Request for Quote) focuses strictly on commercial pricing and SLA terms.
3. Proof of Concept (PoC) and Technical Spikes: For critical architectural questions—such as whether a SaaS platform can ingest 50,000 records/minute across the enterprise firewall—the BA collaborates with architects to execute a time-boxed (e.g., 2-week) PoC to test and eliminate high-risk technical assumptions prior to contract execution.