Project Management Case Study

One missing slip of paper
nearly cost me an entire afternoon.

That day is the reason CTGP — College Gate Pass — exists: a role-based digital system that replaces paper gate passes with a secure, traceable workflow for students, teachers, guards, and administrators.

View Live Prototype → Read how it started ↓

MAIN GATE · OLD PROCESS

Request typePhysical gate pass slip

Slip bookOut of stock

Teacher response"Without a gate pass, we do nothing."

UrgencyGenuinely urgent

Fallback optionNone

what actually happened · no fallback, no exceptions

CHECKPOINT 01 · The Day It Happened

Gate Pass Register

Slip Book

Signatures · Manual entries · One physical copy

UNAVAILABLE

It was an ordinary day until it wasn't. I had a genuinely urgent reason to step outside campus — the kind of thing that couldn't wait for tomorrow. So I did what every student is trained to do: I went to get a gate pass.

Except the slip book was empty. No blank slips left, no printed copies, nothing to fill in and sign. When I explained the situation to a teacher, the answer was final: "Without a gate pass, we do nothing. You cannot go outside."

The rule itself wasn't unreasonable. What failed was the process behind it — a workflow with exactly one physical path, and zero fallback when that path broke.

I couldn't leave. Not because I wasn't allowed to in principle, but because a piece of paper wasn't in stock. That gap — between a legitimate need and a process too brittle to accommodate it — is where CTGP started.

For my Project Management coursework, I decided to treat this as a real product problem rather than a one-off complaint: define the stakeholders, map the workflow, design for the failure modes paper can't handle, and build a working prototype that proves the idea holds up.

CHECKPOINT 02 · The Problem

Paper gate passes don't fail quietly — they fail for everyone at once.

The slip-book incident wasn't an isolated glitch. The same process creates friction for every role that touches it.

Students

Wait on approvals with no visibility
Don't know if a pass is even approved
Can lose a physical slip entirely
Have no record of their own movement

Teachers

Verify requests manually, one by one
No centralized approval queue
Repeated verification is tedious
Easy to lose track of who asked what

Guards

Can't easily verify a paper slip is genuine
Searching registers at the gate is slow
No instant access to student details
No clean way to flag something suspicious

Administrators

No real-time view of campus movement
Historical data is hard to analyze
Auditing depends on manual records
Can't tell who's currently outside

CHECKPOINT 04 · Who Uses CTGP

One platform, four very different jobs-to-be-done

Rather than building four disconnected tools, CTGP is one system that understands which role is looking at it, and shows only what that role needs.

Student

Wants a simple, mobile-first pass

"I need to get permission to leave campus and prove that permission at the gate."

Teacher

Wants a fast approval queue

"I need to quickly verify whether this student should be allowed to leave."

Guard

Wants speed and certainty

"I need to know within seconds whether this student is authorized to exit or return."

Administrator

Wants system-wide visibility

"I need to know who is leaving, who is outside, and whether anything needs my attention."

CHECKPOINT 05 · Inside the Product

One door, four roles

Every role signs into the same login screen. What happens after that is designed entirely around what that person needs to do next.

Same platform, different responsibilities

Students sign in with a username, custom email, or roll number — whichever they remember in the moment. The system identifies the role automatically and routes them straight to the tools that role actually uses.

Don't make users understand the system. Make the system understand the user.

Student

The Digital Pass

QR pass + manual fallback code

Full movement history

Real-time notifications

QR is fast. The manual code is what actually matters.

Real gate environments aren't perfect — cameras fail, lighting is bad, devices glitch. So every pass ships with a 4-character manual code alongside the QR, printed right on the same screen.

QR Scan→fails→Manual Code→Same Verification

The student also gets a transparent event feed — approval, gate scan, exit, return — so they're never left guessing whether an action actually went through.

Teacher

Scan & Approve

Assigned classes overview

Camera scanner, with fallback notice

Error states get designed too, not just the happy path

When camera access is blocked or unavailable, the teacher isn't left at a dead end — the interface surfaces a clear notice and switches to 4-character manual entry.

Teacher scans or types the student's code
Full student + pass context is retrieved instantly
Approve or reject — rejection requires a clear reason, logged for the gate record

Guard

Gate Terminal

Campus Exit mode

Campus Return mode

The guard shouldn't just see "VALID"

A green checkmark isn't enough context to make a real security decision. Scanning a pass surfaces identity, class, assigned teacher, reason for exit, approval status, and validity window — everything needed to decide with confidence.

And when something feels off, the guard doesn't have to force a binary approve/reject: a dedicated Flag Suspicious Student action escalates it for administrative review instead.

Every camera failure has the same answer

Manual 4-character code entry appears identically for teachers and guards. One fallback pattern, reused everywhere, so nobody has to learn a second way of doing the same job.

Admin

Central Console

"Currently outside" is a live operational metric, not a report

Because CTGP tracks movement as a state machine rather than a one-time stamp, the admin console can show exactly how many students are approved today, currently outside, rejected, or awaiting registration — updated as gate events happen, not at the end of the day.

CHECKPOINT 06 · Designed For Failure

Paper had one failure mode. Software needs to handle a dozen.

This is the section the slip-book incident actually taught me. A process only proves itself in the moments it's expected to break.

Camera fails

No camera access at the gate

The exact failure that started this whole project — except now it has an answer.

→ Switch to 4-character manual code

Expired pass

Student shows an expired QR

Passes are time-bound; the system won't honor one past its validity window.

PASS EXPIRED — do not permit exit

Duplicate scan

Student already exited

A second exit scan shouldn't silently log a second exit event.

CURRENT STATE: OUTSIDE CAMPUS

Inconsistent state

Return scan without a prior exit

The state machine catches movement that doesn't make logical sense.

Flagged as inconsistent movement

Not approved

Teacher scans an unauthorized pass

Status is stated plainly rather than left for the teacher to infer.

PASS NOT APPROVED

Human judgment

Something feels wrong

Not every exception has an automatic answer — sometimes it needs a person.

→ Flag Suspicious Student, escalate to admin

CHECKPOINT 07 · PRD Snapshot

From incident to requirements

The full Product Requirements Document breaks down into 29 functional requirements across four roles, plus a set of non-functional constraints that matter specifically because this runs at a physical gate.

Functional Reqs

User Roles

Edge Cases Covered

Lifecycle States

Authentication & Student FR-01 – FR-09

FR-01Users authenticate with assigned credentials

FR-02System identifies the user's role

FR-03Access is restricted to that role's functionality

FR-04Student can view their digital gate pass

FR-05Student can access QR verification

FR-06Student can access a manual verification code

FR-07Student can view movement history

FR-08Student can view system notifications

FR-09Student can see current pass status

Teacher FR-10 – FR-14

FR-10View assigned classes

FR-11Scan a student's QR pass

FR-12Manually enter a student's verification code

FR-13View student and pass information

FR-14Approve or reject eligible requests

Guard FR-15 – FR-22

FR-15Select campus exit or return mode

FR-16Scan student QR codes

FR-17Manually verify a student

FR-18View student identity information

FR-19View pass validity

FR-20Record exit events

FR-21Record return events

FR-22Flag suspicious activity

Admin FR-23 – FR-29

FR-23View campus statistics

FR-24View recent movement

FR-25View student records

FR-26View movement logs

FR-27Manage departments

FR-28Manage staff accounts

FR-29Review registrations

Security

Role-based access control, authenticated sessions, time-bound passes, full audit logging.

Performance

QR verification should return a result within seconds — the gate is not a place to wait.

Availability

Gate verification stays usable through connectivity issues via the manual-code fallback.

Usability

Guard interface prioritizes large controls, high contrast, minimal steps, clear status.

CHECKPOINT 09 · Future Roadmap

What this prototype earns the right to become

These are deliberately framed as future enhancements — not assumptions baked into the current build.

V2Parent / Guardian Notifications

Automatically notify a guardian when a pass is approved, when the student exits, and when they return.

V3Visitor Management

Temporary passes for parents, guests, vendors, and contractors — extending the same state machine beyond students.

V4Analytics

Peak exit times, most frequent reasons, average time outside, and department-level movement patterns for admins.

V5Smart Security

Face verification, anomaly detection, and duplicate-pass detection as later-stage, higher-trust capabilities.