Project: A Feasibility Study

Project: A Feasibility Study

You have spent nine lessons examining every dimension of feasibility — technical capability, economic justification, cost-benefit arithmetic, operational readiness, schedule realism, legal compliance, risk assessment, and the make-or-buy decision. Now it is time to put all of that into practice. This lesson walks you through a complete, end-to-end feasibility study for a realistic proposal: an online appointment booking system for a growing multi-branch clinic network.

Follow each section as if you are the lead analyst assigned to the engagement. By the end you will have a model you can adapt directly to real-world projects.

The Proposal: ClinicEase Booking System

Organization: Al-Shifa Medical Group — a private clinic network with four branches in a major city. Currently 600+ appointments per week are managed via phone calls and a shared spreadsheet. Missed appointments, double-bookings, and no-shows cost the group an estimated USD 85,000 per year in lost revenue and staff overtime.

Proposed system: ClinicEase — a web and mobile booking platform that lets patients self-schedule, receive automated reminders, and fill in intake forms online. Staff get a real-time availability dashboard and integrated patient history.

Trigger: A competitor clinic launched a similar system last quarter and is visibly winning referrals. The CEO has approved a feasibility study with a target go/no-go decision within six weeks.

Step 1 — Scope and Objectives

Before assessing any dimension, the analyst pins down exactly what is in scope. Scope creep during a feasibility study is just as dangerous as scope creep during development — it inflates cost estimates and delays the decision.

• In scope: patient self-booking (web + iOS/Android), automated SMS/email reminders, staff scheduling dashboard, basic patient profile and intake form, admin reporting on no-shows and utilization.
• Out of scope (Phase 1): electronic health records (EHR) integration, insurance billing, telemedicine video, AI-driven scheduling optimization.
• Success metric: reduce no-show rate from 22% to below 10%, reduce booking-related staff hours by 40%, recover at least USD 60,000/year net of system costs.

Step 2 — Technical Feasibility

The analyst interviews the IT manager and the two developers currently maintaining the clinic intranet. Key findings:

• The clinic has reliable broadband at all four branches and a cloud hosting account (AWS Lightsail).
• The in-house team has PHP/Laravel experience but no mobile development background. They can maintain but not build a React Native app from scratch.
• The existing patient database uses MySQL; a booking system schema is well within standard capabilities.
• SMS gateway integration (Twilio or local equivalents) is mature and well-documented — low technical risk.
• Gap identified: Mobile app development requires either a contractor or a SaaS product with a native app included.

Technical verdict: Conditionally feasible. Web-only in-house build is fully viable. Native mobile requires bridging the skills gap — either hire a contractor (~3 months) or choose a SaaS platform that bundles the mobile app.

Step 3 — Economic Feasibility

The analyst builds a 3-year cost-benefit model. All figures are estimated conservatively.

Costs (3-year total):

• Development / SaaS setup: USD 28,000 (one-time)
• Annual SaaS subscription (if SaaS route): USD 9,600/year → USD 28,800 over 3 years
• SMS / notification costs: USD 1,200/year → USD 3,600 over 3 years
• Staff training (one-time): USD 2,500
• Ongoing maintenance / support: USD 4,800/year → USD 14,400 over 3 years
• Total 3-year cost (SaaS route): ~USD 77,300

Benefits (annual, recurring):

• Recovered revenue from reduced no-shows (22% → 9%): USD 60,000/year
• Staff time saved (booking calls reduced 40%): USD 18,000/year (3 FTE × 25% time × USD 24,000 salary)
• Reduced overtime: USD 7,000/year
• Total annual benefit: USD 85,000/year

NPV calculation (discount rate 8%, 3-year horizon):

• Year 0 cash flow: −USD 30,500 (setup + training)
• Year 1 net: USD 85,000 − USD 15,600 (opex) = USD 69,400 → PV = USD 64,260
• Year 2 net: USD 69,400 → PV = USD 59,500
• Year 3 net: USD 69,400 → PV = USD 55,090
• NPV ≈ USD 148,350 — strongly positive.
• Payback period: approximately 6.5 months after go-live.
• 3-year ROI: ~192%

Economic verdict: Feasible. Even under a pessimistic scenario (benefits 30% lower than projected), NPV remains positive and payback stays within Year 1.

Step 4 — Legal & Compliance Feasibility

The clinic operates in a jurisdiction with a national health data protection regulation modeled on GDPR. The analyst reviews requirements with the clinic's legal advisor:

• Patient names, phone numbers, and appointment history are personal data under the regulation. A Data Processing Agreement with the SaaS vendor is required.
• Data must be stored on servers physically located within the country, or in a jurisdiction with an adequacy decision. The shortlisted SaaS vendors both offer local-region hosting — this must be a contract term.
• Patients must provide explicit consent for SMS reminders. The intake form must include a compliant consent checkbox.
• The clinic does not process payment card data in Phase 1 (consultations are billed separately at reception) — PCI-DSS compliance is not required at this stage.

Legal verdict: Feasible with conditions. Three mandatory actions: (1) sign Data Processing Agreement with vendor, (2) confirm local data residency in contract, (3) add GDPR-style consent to booking flow before go-live.

Step 5 — Operational & Organizational Feasibility

The analyst runs structured interviews with reception staff (3), doctors (4), and the clinic manager at each branch. Key findings:

• Reception staff strongly favor the system — booking calls consume 35% of their day and they frequently deal with angry patients over double-bookings.
• Doctors are neutral-to-positive; their primary concern is that the dashboard must not require them to manage their own schedules — the reception team must retain that control.
• One branch manager is skeptical: "Patients here are older and prefer calling." The analyst reviews the patient demographic data: 61% of patients are under 55 and already use mobile banking apps — smartphone adoption is not a barrier for the majority.
• Change management need identified: a simple patient communication campaign ("Book online, skip the queue") will be needed at launch.

Operational verdict: Feasible. Staff buy-in is high. Patient adoption risk is low for the majority demographic. The skeptical branch needs a targeted communication plan and a phone fallback (which the system does not remove).

Step 6 — Schedule Feasibility

The CEO wants the system live before the next public holiday booking rush, which is 14 weeks away. The analyst builds a high-level timeline:

• Vendor selection and contract: 2 weeks
• Configuration, branding, data migration (existing patient records): 4 weeks
• Staff training across 4 branches: 1 week
• User acceptance testing (UAT) with reception and doctors: 2 weeks
• Soft launch (one branch pilot): 2 weeks
• Full rollout: 1 week
• Total: 12 weeks — 2 weeks of buffer before deadline.

A custom-build route would require 20–24 weeks minimum (design, development, testing). That path is not schedule-feasible for the immediate deadline.

Schedule verdict: SaaS route is feasible within the deadline. Custom build is not. This finding effectively closes the make-vs-buy decision in favor of SaaS for Phase 1.

Step 7 — Risk Register

The analyst documents the top five risks, with likelihood (1–5) and impact (1–5) scores:

• Vendor lock-in — Likelihood 3, Impact 4 (score 12). Mitigation: negotiate data-export clause and 90-day exit window in contract.
• Low patient adoption at launch — Likelihood 3, Impact 3 (score 9). Mitigation: launch communication campaign; keep phone booking open indefinitely.
• Data breach / GDPR violation — Likelihood 2, Impact 5 (score 10). Mitigation: Data Processing Agreement, penetration test pre-launch, encryption at rest and in transit.
• Integration failure with existing patient database — Likelihood 2, Impact 4 (score 8). Mitigation: pilot on one branch first; validate data migration before rollout.
• Key staff resistance (branch manager) — Likelihood 2, Impact 2 (score 4). Mitigation: involve that manager in UAT design; address concerns early.

No risk scores above the 15-point threshold that would require escalation to the board. The risk profile is manageable.

Step 8 — Make, Buy, or Subscribe Decision

The schedule finding (Step 6) makes the choice clear, but the analyst documents it formally:

• Custom build: Full control, but 20–24 weeks, higher cost, mobile skills gap, and highest technical risk. Ruled out for Phase 1.
• Buy (off-the-shelf software, self-hosted): Lower cost than custom, but requires server management, patching, and update management by the in-house team. Given the small IT team, this adds operational burden. Not recommended.
• SaaS subscription: Fastest time-to-value (12 weeks), lowest upfront investment, vendor handles infrastructure and compliance updates, includes native mobile apps. Highest ongoing cost but best total-cost profile within a 3-year window given the team's constraints. Recommended.

Step 9 — The Feasibility Report & Recommendation

The analyst compiles the findings into a structured report. The key sections of a well-formed feasibility report are:

1. Executive Summary — one-page overview of proposal, recommendation, and key rationale. Written for the CEO who may read nothing else.
2. Scope & Objectives — what is in/out of scope, success metrics.
3. Technical Assessment — skills, infrastructure, technology readiness.
4. Economic Assessment — costs, benefits, NPV, ROI, payback, sensitivity analysis.
5. Legal & Compliance Assessment — regulatory requirements, required actions.
6. Operational Assessment — stakeholder interviews, change management needs.
7. Schedule Assessment — realistic timeline, critical path highlights.
8. Risk Register — top risks with scores and mitigation plans.
9. Make/Buy/Subscribe Analysis — options compared on cost, time, risk, control.
10. Recommendation — explicit go/no-go verdict with conditions and next steps.

Step 10 — The Final Recommendation for ClinicEase

The analyst's recommendation to the CEO reads:

"The ClinicEase booking system is feasible and financially compelling. We recommend proceeding with a SaaS implementation on the following conditions: (1) confirm data residency and sign a Data Processing Agreement with the selected vendor before contract signature; (2) add GDPR-style patient consent to the booking flow prior to go-live; (3) engage a patient communication campaign at each branch. The SaaS route delivers go-live in 12 weeks at a total 3-year cost of approximately USD 77,000 against projected 3-year benefits of USD 255,000 (NPV ≈ USD 148,000, payback ~6.5 months, ROI ~192%). Risk exposure is manageable. We recommend immediately issuing an RFP to three shortlisted vendors and targeting contract signature within 2 weeks."

What Makes This a Strong Study?

Before you close this lesson, identify the practices that made this feasibility study credible and actionable:

• Scope was locked before analysis began. No scope creep inflated estimates.
• Each dimension produced a verdict. Not "this needs more research" — actual pass/fail with conditions.
• Numbers were grounded. Salary assumptions, SaaS pricing, and no-show revenue loss were all sourced from the organization's own data or published benchmarks — not pulled from thin air.
• Risks were scored, not listed. A risk list without likelihood and impact scores is decoration, not analysis.
• The recommendation was specific. Not "we suggest exploring SaaS options" but "issue an RFP to three vendors within 2 weeks."
• Alternatives were compared. The make/buy/subscribe analysis showed why SaaS was chosen over build — the CEO understands what was rejected and why.

Applying This to Your Own Projects

Every project you analyze will have different numbers, constraints, and stakeholders — but the structure stays the same. Start with scope, work through each TELOS + Risk dimension systematically, document your sources and assumptions, quantify where possible, and close with a recommendation that a busy executive can read in three minutes and act on.

The clinic scenario demonstrated that a feasibility study is not an academic exercise. It stopped a custom-build path that would have missed the business deadline by two months, surfaced three legal compliance actions that might otherwise have been discovered post-launch, and gave the CEO a financial model with a clear payback timeline. That is the value of doing this work well.