Systems Planning: Feasibility, Scope, Alternatives & Project Management

TAKEAWAYS:

• Feasibility studies assess whether a project is technically, economically, and operationally viable using four key criteria: technical, economic, operational, and legal.
• Scope definition clarifies project boundaries, deliverables, and constraints through tools like context diagrams and use case diagrams to avoid scope creep.
• Alternative solutions (e.g., custom-built vs. off-the-shelf software) are evaluated using cost-benefit analysis and SWOT matrices to select the best fit.
• Project management methodologies (Waterfall, Agile, Spiral) determine how tasks, timelines, and resources are structured—each suits different project needs.
• Risk management identifies potential threats (e.g., budget overruns, vendor delays) and mitigation strategies early in planning.
• Stakeholder analysis ensures alignment between project goals and user/business needs via tools like RACI matrices or stakeholder maps.

1. Why Planning Matters: The Foundation of Success

Planning is the bridge between business needs and technical execution. Without it, projects fail due to:

• Unclear goals (e.g., a bank’s digital loan system without defined user roles).
• Budget overruns (e.g., NTC’s fiber-optic expansion costing 3x estimates).
• Misaligned stakeholders (e.g., Daraz’s app updates ignored by rural sellers).

2. Feasibility Studies: Can We Build This?

Feasibility studies answer: "Is this project worth pursuing?" They evaluate four dimensions:

Worked Example: Feasibility of a Hospital Management System (HMS) for a Private Clinic

• Technical: Clinic lacks IT staff → Outsource to a vendor (e.g., Sofware Nepal).
• Economic: Costs ₹500K vs. savings of ₹800K/year in manual errors → Feasible.
• Operational: Doctors resist digital records → Pilot with 1 department first.
• Legal: Must comply with Health Information Privacy Act → Encrypt patient data.

3. Defining Scope: What’s In, What’s Out?

Scope defines what the system will (and won’t) do. Poor scope leads to:

• Scope creep (e.g., NEPSE’s trading app adding crypto support mid-project).
• Delays (e.g., Kathmandu Metro’s budget ballooning due to undefined routes).

Tools to Define Scope

1. Context Diagram (DFD Level 0) Shows the system as a single process interacting with external entities.

   flowchart TD
     A["Patient"] -->|"Registers"| B["Hospital Management System"]
     B -->|"Generates Bill"| C["Accounting System"]
     B -->|"Sends Alerts"| D["Doctor App"]
     B -->|"Stores Data"| E["Database"]

   Caption: Context diagram for a hospital’s HMS.

2. Use Case Diagram Maps user interactions (e.g., Pathao rider vs. customer workflows).

3. Scope Statement Template Project Name: NTC’s Smart Meter Rollout Deliverables: 50,000 meters installed by 2025, mobile app for readings. Exclusions: Customer billing software (handled by a third party). Constraints: Budget = ₹2B, must integrate with existing grid.

4. Evaluating Alternatives: Build vs. Buy vs. Hybrid

Not all solutions require custom development. Compare options using:

Worked Example: Choosing a Payment Gateway for a Nepalese Startup

• Option 1: Custom-built (₹500K, 12 months).
• Option 2: Khalti API (₹50K/year, 1 month setup).
• Decision: Hybrid—use Khalti for payments + custom dashboard.

5. Project Management Methodologies

The methodology dictates how work is structured. Choose based on:

• Project size (small vs. large).
• Uncertainty (high vs. low).
• Stakeholder needs (flexibility vs. control).

Visual Comparison: Waterfall vs. Agile

flowchart LR
    subgraph Waterfall
        A["Requirements"] --> B["Design"] --> C["Implementation"] --> D["Testing"] --> E["Maintenance"]
    end
    subgraph Agile
        F["Sprint 1"] --> G["Review"] --> H["Sprint 2"] --> I["Review"] --> J["Sprint 3"]
    end

6. Risk Management: Anticipating the Unexpected

Risks in IT projects include:

• Technical: System crashes (e.g., Nepal’s power outages during e-voting).
• Financial: Budget overruns (e.g., Kathmandu Metro’s cost escalation).
• Operational: User resistance (e.g., elderly avoiding digital banking).

Risk Management Steps:

1. Identify: List risks (e.g., "Vendor delay in delivering servers").
2. Analyze: Assess impact/probability (use a risk matrix).
3. Mitigate: Plan responses (e.g., "Have backup vendors").
4. Monitor: Track risks (e.g., weekly status reports).

7. Stakeholder Analysis: Keeping Everyone Happy

Stakeholders include:

• Users (e.g., Daraz customers).
• Developers (e.g., Sofware Nepal’s team).
• Investors (e.g., Nepal Investment Bank).

Tools:

• RACI Matrix: Assigns Responsible, Accountable, Consulted, Informed roles.

  | Stakeholder | Requirements | Design | Testing | | Developer Team | Consulted | Accountable | Responsible | | Business Owner | Accountable | Consulted | Informed | | End Users | Informed | Informed | Consulted |

• Stakeholder Map: A quadrant chart categorizing stakeholders by power vs. interest (e.g., Ncell’s board = high power/high interest). (Image: Peter Gladdish, CC BY 4.0, via Wikimedia Commons)

In the Real World

1. Khalti’s Payment Gateway

   • Feasibility: Economic (low transaction fees) and technical (integrated with banks).
   • Scope: Initially for online payments, later expanded to retail QR codes.
   • Risk: Fraud → Mitigated by two-factor authentication (OTP + fingerprint).

2. Pathao’s Driver App

   • Alternative: Built custom (not off-the-shelf) to handle Nepal’s traffic and terrain.
   • Agile Methodology: Weekly updates based on driver feedback (e.g., adding toll booth alerts).

3. NTC’s Smart Meter Project

   • Feasibility Study: Technical challenge (rural connectivity) → Pilot in Kathmandu first.
   • Stakeholders: NTC engineers, customers, government regulators.
   • Risk: Data privacy → Encrypted meters and GDPR-compliant storage.

Exam Tip

• Feasibility: Always evaluate all four types (technical, economic, operational, legal). Partial answers lose marks.
• Scope: Draw a context diagram or use case diagram in exams—it’s worth 5–10 marks.
• Alternatives: Compare at least two options (e.g., custom vs. off-the-shelf) with pros/cons.
• Methodologies: Know when to use Waterfall (stable projects) vs. Agile (dynamic needs). Mention iterative development for Agile.
• Risk Management: Use a risk matrix or mitigation table—examiners love structured answers.
• Stakeholders: A RACI matrix or stakeholder map can earn easy marks if labeled correctly.

Common Pitfalls:

• Ignoring legal feasibility (e.g., forgetting data privacy laws).
• Vague scope (e.g., "build a website" → specify features like user login, payment gateway).
• Choosing a methodology without justification (e.g., "We’ll use Agile" → explain why).

Final Checklist Before Submission: ✅ Did I cover all four feasibility types? ✅ Did I compare at least two alternatives? ✅ Did I draw a diagram (context diagram, use case, or risk matrix)? ✅ Did I link to a real-world example (e.g., Khalti, Pathao, NTC)?