Project: Analyze a Small Business Problem

Project: Analyze a Small Business Problem

This lesson is your capstone for the Introduction to System Analysis tutorial. Everything covered so far — systems thinking, stakeholder analysis, the business case, documentation skills, ethics — comes together here in a single, end-to-end worked example. You will walk through the full analytical cycle on a realistic small-business scenario, producing the core artifacts an analyst delivers before design begins.

The Scenario — City Smiles Dental Clinic

City Smiles is a five-dentist private clinic operating in a mid-size city. It currently manages appointments by phone and paper logbook. The practice manager, Leila, contacted you after a frustrating week: two patients showed up for the same slot, three dentists sat idle because of unreturned reminder calls, and the receptionist spent four hours chasing insurance authorizations manually.

Leila wants "something digital." Your job is not yet to build it — your job is to understand the situation so that the right solution can be specified.

Step 1 — Apply Systems Thinking: Map the Current System

Before interviewing anyone, sketch the system boundary and its components. A system has inputs, processes, outputs, and feedback. The clinic appointment system today looks like this:

• Inputs: Phone call from patient, dentist availability (paper calendar), insurance details (paper form).
• Processes: Receptionist checks logbook, pencils in slot, calls patient back to confirm, manually writes reminder card, faxes pre-authorization request to insurer.
• Outputs: Confirmed appointment, reminder letter, insurance authorization (or denial).
• Feedback: No-show rate (counted weekly by hand), patient complaints (verbal, rarely logged).

Already two system weaknesses emerge from this map alone: the process is entirely synchronous (the receptionist must be present and on the phone for any step to happen) and feedback is informal and delayed (no-show data takes a week to surface and drives no automatic corrective action).

Step 2 — Identify Stakeholders and Their Needs

A stakeholder is anyone who is affected by the system or can affect it. For City Smiles we identify the following groups and their primary needs:

• Patients — book appointments at any time (including evenings), receive automatic reminders, know their out-of-pocket cost before arriving. Pain point: can only book by phone during office hours.
• Receptionist (Sara) — reduce time spent on phone callbacks; avoid double-bookings; have a single screen showing all dentist schedules. Pain point: manages five paper calendars simultaneously.
• Dentists (5 practitioners) — see today's patient list and clinical notes before entering the treatment room; not be interrupted by admin queries mid-procedure. Pain point: paper notes are filed separately from the schedule.
• Practice Manager (Leila) — report on no-show rate, revenue per dentist, and insurance turnaround time; control access so staff see only their relevant data. Pain point: no data except manual weekly tallies.
• Insurance Companies — receive structured pre-authorization requests in a standard format; send decisions electronically. Pain point: current fax process causes delays and errors.

Step 3 — Define the Problem Statement

A crisp problem statement prevents scope creep and anchors requirements gathering. Use the structured format:

This one-page artifact can be signed off by Leila before any requirements are written. It prevents the project from silently expanding to include a full electronic health record system, a billing module, or a patient portal with lab results — all legitimate future desires, but not the stated problem.

Step 4 — Perform a Gap Analysis

Gap analysis compares the current state with the desired future state and lists what must change:

• Gap 1 — Booking channel: Currently phone-only during office hours → need web/mobile booking 24/7.
• Gap 2 — Double-booking prevention: Currently relies on receptionist vigilance → need real-time slot locking in the database.
• Gap 3 — Reminders: Currently manual reminder card → need automated SMS/email 48 h and 2 h before appointment.
• Gap 4 — Schedule visibility: Currently five separate paper calendars → need unified digital schedule per dentist with role-based access.
• Gap 5 — Insurance workflow: Currently paper fax with 2–5 day turnaround → need structured electronic pre-auth submission.
• Gap 6 — Management reporting: Currently weekly manual counts → need live dashboard with no-show rate, revenue, and utilization.

Step 5 — Derive High-Level Requirements

Each gap translates into one or more requirements. At this stage they are business requirements — what the system must do, not how:

1. The system shall allow patients to book, reschedule, and cancel appointments via a web browser or mobile device at any time without staff involvement.
2. The system shall prevent two patients from booking the same dentist slot concurrently.
3. The system shall send automated appointment reminders by SMS and email at 48 hours and 2 hours before each appointment.
4. The system shall provide each dentist with a private daily schedule view showing patient name, appointment type, and duration.
5. The system shall generate insurance pre-authorization requests in the HL7 FHIR standard and receive electronic responses.
6. The system shall provide the practice manager with a real-time dashboard showing no-show rate, revenue per dentist, and slot utilization.

Step 6 — Assess Risks and Constraints

Every project faces constraints that shape what is feasible. City Smiles has:

• Budget constraint: Leila has provisionally approved £12,000 for the first phase. This rules out off-the-shelf enterprise systems but is sufficient for a well-scoped cloud-based booking solution.
• Regulatory constraint: Patient data is subject to GDPR (or equivalent local health data regulation). Any system must implement data minimisation, patient consent records, and a right-to-erasure workflow.
• Integration constraint: The existing dental practice management software (Dentrix) must remain in use; the new system must integrate with its patient database rather than replace it.
• Adoption risk: Sara the receptionist has expressed anxiety about a new system. Change management and training are non-optional costs.
• Dependency risk: The HL7 FHIR insurance integration depends on the insurer's own API readiness, which the clinic cannot control. This gap may need to be delivered in a later phase.

The Deliverable Package

After completing these six steps, the analyst hands the following artifacts to Leila for sign-off before any design begins:

1. Current-state system map (diagram, one page).
2. Stakeholder register with name, role, needs, power/interest rating (table, one page).
3. Problem statement (half a page, signed by sponsor).
4. Gap analysis table (six rows, current vs. desired).
5. Business requirements list (numbered, each traceable to a gap).
6. Risks and constraints log (table with likelihood, impact, and proposed mitigation).

Together these six documents form the Analysis Package — the handoff that makes design possible without guesswork. Each requirement is traceable back to a gap, which is traceable back to a stakeholder need, which is grounded in the current-state map. If a developer later asks "why do we need this feature?", you can answer in three sentences.

Summary

• Apply systems thinking first: draw the current-state boundary, inputs, processes, outputs, and feedback before conducting any interviews.
• Identify every stakeholder — not just the sponsor. Hidden stakeholders (insurers, integration partners) surface constraints early.
• Write a signed problem statement to lock scope before requirements gathering begins.
• Gap analysis makes requirements concrete and prioritizable — each gap is a traceable item.
• Requirements describe what, not how. Keep technology out of requirements.
• Always surface constraints and risks — budget, regulation, integration, adoption — before design, not during it.
• The six-artifact Analysis Package is the analyst's deliverable; it enables informed design decisions and controlled scope.