CSC315 System Analysis and Design

System Analysis and DesignUnit 415 min read

Feasibility Study & Economic Analysis: Methods, Models & Real-World Tradeoffs

Unit 4 of System Analysis and Design examines how to evaluate whether a proposed IT project is viable before development begins, covering technical, operational, economic, and schedule feasibility—with cost-benefit analysis, payback period calculations, and real-world case studies from Nepali tech companies.

TAKEAWAYS:

  • Feasibility studies assess four key dimensions (technical, operational, economic, schedule) to decide if a project should proceed, using structured checklists and expert judgment.
  • Economic feasibility compares development costs (one-time + recurring) against benefits (tangible like revenue savings, intangible like improved customer satisfaction) over the system’s lifetime.
  • The Net Present Value (NPV) method discounts future cash flows to today’s dollars, while Return on Investment (ROI) and Payback Period provide simpler but less precise comparisons.
  • Schedule feasibility evaluates whether the project can be completed within the required timeframe without compromising quality or resources.
  • Radical methods (e.g., prototyping, JAD sessions) gather requirements faster but may introduce ambiguity; traditional methods (interviews, document analysis) are slower but more structured.
  • Nepali companies like eSewa (economic feasibility via transaction cost savings) and NTC (technical feasibility of fiber-optic network upgrades) use these analyses to justify IT investments.

What is Feasibility Study?

A feasibility study is a detailed analysis performed before developing an information system to determine whether the project is practical, viable, and worth pursuing. It answers:

  • Can we build it? (Technical feasibility)
  • Should we build it? (Operational, economic, schedule feasibility)

Why is it important?

  • Avoids wasted resources: Prevents spending $90,000 on a system that may not work or be used.
  • Prioritizes projects: Helps organizations choose between competing IT initiatives.
  • Reduces risks: Identifies potential roadblocks early (e.g., lack of skilled staff, budget overruns).
  • Aligns with business goals: Ensures the system solves real problems (e.g., Khalti’s digital payment system reduced cash handling costs by 40%).

Four Categories of Feasibility

Feasibility is evaluated across four dimensions, each with specific questions and metrics.

1. Technical Feasibility

Definition: Can the system be built with existing technology, tools, and expertise? Key Questions:

  • Does the organization have the hardware/software (e.g., servers, databases)?
  • Are there skilled developers (e.g., Python, SQL, cloud architects)?
  • Can the system integrate with legacy systems (e.g., Nepal Rastra Bank’s core banking software)?

How to Measure:

  • Expert opinion: Consult IT teams or vendors.
  • Prototype testing: Build a small-scale version (e.g., Pathao’s early ride-hailing prototype).
  • Technology readiness assessment: Check if required tools (e.g., AWS, Docker) are available.

Example: NTC’s Fiber-Optic Network Upgrade

  • Challenge: Expanding broadband to rural areas required new fiber-optic cables and routers.
  • Feasibility Check:
    • Technical: Could NTC’s existing crew install the cables? → Yes, but needed training.
    • Cost: $5M for equipment vs. $2M saved annually in maintenance.
    • Time: 18 months to deploy (aligned with government deadlines).

2. Operational Feasibility

Definition: Will users accept and use the system? Does it align with business processes? Key Questions:

  • Will employees adopt the new system (e.g., eSewa’s online payment portal)?
  • Does it improve workflows (e.g., Daraz’s automated inventory system)?
  • Are there legal/compliance issues (e.g., NEPSE’s trading system must follow SEBON rules)?

How to Measure:

  • User surveys: Ask potential users (e.g., Ncell’s customer service reps).
  • Pilot testing: Roll out to a small group first (e.g., Khalti’s beta test in Kathmandu).
  • Change management plan: Assess training needs.

Example: Bank Loan Processing System (Himalayan Bank)

  • Problem: Manual loan approvals took 10 days.
  • New System: Automated workflow with AI risk assessment.
  • Operational Feasibility:
    • User Acceptance: Loan officers resisted initially (feared job loss).
    • Solution: Training + clear communication → 90% adoption rate.

3. Economic Feasibility

Definition: Is the system cost-effective? Do benefits outweigh costs? This is the most critical for board exams—focus on cost-benefit analysis (CBA).

Key Terms
Term Definition Formula/Example
Development Costs One-time expenses (e.g., software licenses, hardware). $90,000 (from past exam questions).
Recurring Costs Annual expenses (e.g., maintenance, salaries). $40,000/year.
Tangible Benefits Measurable savings/revenue (e.g., reduced labor costs, increased sales). $70,000 (Year 1), +$10,000/year.
Intangible Benefits Hard-to-measure advantages (e.g., better customer satisfaction). Faster eSewa transactions → happier users.
Net Present Value (NPV) Discounted future cash flows (accounts for inflation/time value of money). NPV = Σ [Benefits – Costs] / (1 + r)^n
Payback Period Years to recover initial investment. $90,000 / $30,000 (avg. annual benefit) = 3 years.
Return on Investment (ROI) Profitability ratio. ROI = (Net Benefits / Costs) × 100%.
Worked Example: eSewa’s Online Payment System

Assumptions:

  • Development Costs: $150,000 (one-time).
  • Recurring Costs: $50,000/year (servers, security).
  • Benefits:
    • Year 1: $200,000 (reduced cash handling + transaction fees).
    • Years 2–5: $300,000/year (scalable with more users).

Calculations:

  1. NPV (r = 10%):
    Year 0: -$150,000 (initial cost)
    Year 1: ($200,000 – $50,000) / 1.10 = $136,364
    Year 2: ($300,000 – $50,000) / 1.10² = $225,356
    ...
    NPV ≈ $780,000 (positive → **feasible**).
    
  2. Payback Period:
    • Cumulative benefits exceed costs by Year 2 → 2 years.
  3. ROI:
    • Total benefits (5 years) = $1,300,000.
    • ROI = ($1,300,000 – $150,000 – $250,000) / $150,000 = 566%.

Decision: Proceed—high ROI and short payback period.


4. Schedule Feasibility

Definition: Can the system be delivered on time without compromising quality? Key Questions:

  • Are deadlines realistic (e.g., Nepal’s census system needed in 6 months)?
  • Are there resource constraints (e.g., limited developers)?
  • Can milestones be realistically achieved?

How to Measure:

  • Gantt charts: Visualize timelines (see below).
  • Critical Path Method (CPM): Identify longest tasks.
  • Risk assessment: Plan for delays (e.g., NTC’s fiber rollout faced monsoon rains).

Example: NEPSE’s Trading System Upgrade

  • Goal: Launch by Chaitra 1 (new fiscal year).
  • Challenges:
    • Legacy system integration: 3 months.
    • Regulatory approvals: 2 months.
    • User training: 1 month.
  • Solution: Parallel testing → met deadline.

Methods for Gathering Feasibility Data

Method Description Pros Cons Best For
Document Analysis Review existing reports, manuals, and system logs. Low cost, objective data. Outdated info, misses gaps. Ncell’s billing system audit.
Interviews Talk to stakeholders (users, managers, IT staff). Deep insights, customizable. Time-consuming, biased. Himalayan Bank’s loan system.
Observation Watch users perform tasks (e.g., Daraz’s warehouse workers). Unbiased, sees real workflows. Intrusive, slow. Process bottlenecks.
Questionnaires Surveys to gather opinions (e.g., eSewa user satisfaction). Scalable, quantitative. Low response rates. Large user bases.
Prototyping Build a mock-up (e.g., Pathao’s ride UI). Early feedback, reduces risk. Expensive, scope creep. High-risk projects.
JAD (Joint Application Development) Group sessions with users/developers. Fast, collaborative. Requires skilled facilitator. Critical projects.

Comparison: Traditional vs. Radical Methods

Feature Traditional Methods (Structured) Radical Methods (Agile/Prototyping)
Speed Slow (weeks/months) Fast (days/weeks)
Cost High (detailed upfront) Lower (iterative)
Flexibility Rigid (fixed requirements) Adaptive (changes welcome)
User Involvement Low (late in process) High (continuous feedback)
Risk of Failure High (if requirements wrong) Low (early validation)
Best For Stable requirements (e.g., NTC’s billing) Uncertain requirements (e.g., Khalti’s new features)

In the Real World

  1. eSewa’s Economic Feasibility

    • Idea Used: Cost-Benefit Analysis (CBA).
    • How: Compared $1.2M development cost vs. $5M annual savings (reduced cash transactions + government subsidies). NPV over 5 years: +$18M → approved.
  2. NTC’s Fiber-Optic Expansion

    • Idea Used: Technical + Schedule Feasibility.
    • How: Assessed whether 10,000 km of fiber could be laid in 24 months with existing crews (yes, but needed 15% more labor). Used Gantt charts to track progress.
  3. Daraz’s Inventory Management System

    • Idea Used: Operational Feasibility.
    • How: Tested with 5 warehouses before full rollout. Found 30% faster picking but training needed → adjusted plan.
  4. NEPSE’s Trading Platform

    • Idea Used: All Four Feasibilities.
    • Technical: Could the system handle 10,000 transactions/sec? → Yes (scaled with cloud).
    • Operational: Brokers resisted new UI → redesigned.
    • Economic: Saved $2M/year in manual processing.
    • Schedule: Launched on time despite delays.

Feasibility Study Process (Step-by-Step)

flowchart TD
    A["Start: Define Project Scope"] --> B["Identify Stakeholders"]
    B --> C["Gather Data<br/>(Documents, Interviews, etc.)"]
    C --> D["Analyze Feasibility<br/>(Technical, Operational, Economic, Schedule)"]
    D --> E["Assess Risks<br/>(Delays, Budget Overruns)"]
    E --> F["Prepare Report<br/>(Recommend: Proceed/Modify/Abort)"]
    F --> G["Present to Management<br/>(Get Approval)"]
    G -->|"If Approved"| H["Proceed to SDLC"]
    G -->|"If Rejected"| I["End Project"]

Economic Analysis Techniques

1. Cost-Benefit Analysis (CBA)

Steps:

  1. List all costs (development, maintenance, training).
  2. List all benefits (tangible + intangible).
  3. Calculate NPV, ROI, Payback Period.

Example:

Year Costs ($) Benefits ($) Net Cash Flow ($) NPV (10%)
0 90,000 0 -90,000 -90,000
1 40,000 70,000 30,000 27,273
2 40,000 80,000 40,000 33,058
... ... ... ... ...
Total NPV +$120,000

Decision Rule:

  • NPV > 0 → Feasible.
  • NPV < 0 → Not feasible.

2. Break-Even Analysis

Definition: The point where total costs = total benefits. Formula: Example:

  • Initial Cost: $90,000.
  • Annual Benefit: $30,000 (after costs).
  • Break-Even: years.

Common Pitfalls in Feasibility Studies

  1. Ignoring Intangible Benefits
    • Example: A hospital management system reduces errors (intangible) but saves lives (priceless).
  2. Overestimating Benefits
    • Example: Claiming $1M/year savings without data (common in Nepali government projects).
  3. Underestimating Costs
    • Example: Forgetting training costs for Ncell’s new CRM system.
  4. Bias in Data Collection
    • Example: Only interviewing IT staff (not end-users) for eSewa’s new feature.
  5. Political Pressure
    • Example: Approving a project because a minister’s son is involved (seen in Nepal’s e-Governance projects).

Feasibility Study Report Template

A formal report includes:

  1. Executive Summary: Key findings (1 page).
  2. Project Overview: Goals, scope.
  3. Feasibility Analysis:
    • Technical (tools, expertise).
    • Operational (user acceptance).
    • Economic (NPV, ROI).
    • Schedule (Gantt chart).
  4. Risks and Mitigation: Table of risks + solutions.
  5. Recommendations: Proceed, modify, or abort.
  6. Appendices: Raw data, surveys, prototypes.

Example Snippet (Economic Section):

Net Present Value (NPV): The system yields an NPV of $120,000 at a 10% discount rate over 5 years, indicating strong economic viability. The payback period is 2.5 years, well below the 3-year threshold set by management.

Sensitivity Analysis: If benefits drop by 15%, NPV remains positive ($85,000), confirming robustness.


Exam Tip

How to Score Full Marks in TU/PU Exams:

  1. Define Clearly:

    • Start every answer with a one-sentence definition (e.g., "Feasibility study is a pre-development analysis to assess whether a project is viable across technical, operational, economic, and schedule dimensions.").
  2. Use Formulas:

    • For economic feasibility, always show calculations (NPV, ROI, payback period). Use the past exam question as a template:
      NPV = Σ [Benefits – Costs] / (1 + r)^n
      Year 1: ($70,000 – $40,000) / 1.10 = $27,273
      Year 2: ($80,000 – $40,000) / 1.10² = $33,058
      ...
      
  3. Compare Methods:

    • If asked about document analysis vs. observation, use a table (as above) and give one real-world example for each (e.g., "NTC used document analysis to review old billing records, but observation revealed inefficiencies in call-center workflows.").
  4. Link to Real-World:

    • Every answer must tie to Nepali companies (e.g., "Like eSewa’s economic feasibility study, this project must justify costs via NPV to stakeholders.").
  5. Visuals = Extra Marks:

    • Draw a Gantt chart for schedule feasibility or a cost-benefit table for economic analysis. Use Mermaid diagrams for processes (e.g., feasibility study steps).
  6. Avoid Common Mistakes:

    • ❌ "Feasibility is just about money." → Wrong (it’s four dimensions).
    • ❌ "NPV is always the best method." → Partial (mention payback period for simplicity).
  7. Exam Question Patterns:

    • Define + Explain: "Define feasibility. Explain economic feasibility." → Give definition + NPV/ROI formulas + example.
    • Compare: "Observation vs. document analysis." → Table + pros/cons + real-world use.
    • Worked Example: "Calculate NPV for given costs/benefits." → Show year-by-year table.

sequenceDiagram
    participant User
    participant Analyst
    participant Stakeholder
    User->>Analyst: Request feasibility study for new system
    Analyst->>Stakeholder: Gather requirements (interviews, docs)
    Analyst->>Analyst: Analyze technical/operational/economic/schedule feasibility
    Analyst->>Stakeholder: Present NPV, ROI, risks
    Stakeholder-->>Analyst: Approve/Reject project

Based on the TU BSc CSIT syllabus for System Analysis and Design (CSC315), unit 4.

Discussion

Loading…