Turning a spreadsheet-run national placement operation into a self-feeding system of record, and learning that shipping isn't adoption
IHNA's national clinical-placement operation ran on spreadsheets stitched across disconnected vendor systems. I designed, built and shipped POMS solo in 11 weeks, diagnosed near-zero adoption after launch, and pivoted it into an integration-fed system of record, now syncing 6,417 students, 9,424 allocations and 615 facilities nightly.
The Institute of Health and Nursing Australia (IHNA) places nursing and health students into clinical facilities across five campuses: Melbourne, Sydney, Perth, Brisbane, and an online/offshore cohort. Every placement is a compliance-heavy transaction: seats procured from a facility, students matched to seats, documents verified before start dates, cancellations managed inside contractual windows.
A national team of 12–15 placement coordinators ran all of this on spreadsheets, cross-referencing two vendor systems that don't talk to each other: the placement-management system (Clinsoft) and the student-management system. A coordinator answering a simple question ("how many confirmed seats do we have in Perth for this intake, and which students still have documents outstanding?") had to open three tools and reconcile them by hand.
The failure modes were predictable and constant: seat counts that disagreed between sheets, cancellations that slipped past no-fee windows and incurred avoidable facility charges, document chasing done from memory, and zero shared visibility between the placement, academic, and student-support teams.
Every hour a coordinator spends re-keying and cross-checking data is an hour not spent placing students.
Pain Points Identified
Double and triple data entry
The same allocation was keyed into Clinsoft, a tracking spreadsheet, and email threads, with no system authoritative
No live seat visibility
Procurement targets, booked seats, and allocated students lived in different places; over- and under-booking surfaced late
Untracked cancellation cost
Cancellations outside contractual windows carried facility charges nobody was systematically tracking
Manual document chasing
Placement-critical document deadlines were tracked by memory and ad-hoc reminders across thousands of pending items
5–15 hrs
Estimated hours per coordinator per week lost to manual re-keying and cross-checking (5 = conservative modelling scenario; 15 = the team's own estimate)
The first version of POMS was, by every engineering measure, a success. I mapped the placement process with the team, wrote a full specification, and built the system in an 11-week solo sprint: roughly 2,000 automated tests, role-based access control with campus scoping, and a 15-stage delivery plan that finished its baseline scope six and a half weeks early. It launched to production with real data: 640 students, 51 facilities, 10 intakes.
Then I measured usage. Almost nobody logged in.
Instead of pushing harder on training, I ran a structured critique of my own product, the kind of review I'd give someone else's. The diagnosis was uncomfortable and precise: POMS asked an overloaded team to manually re-key data that already lived in the systems they used every day. It was a tracker, not an engine. The team would always default back to the source systems, POMS would go stale, and a stale system is worse than no system.
Discovery Process
Process mapping with the placement team
Structured interviews and workflow mapping across campuses, scored against five gap types (access, effort, timing, workflow, variance). This produced the original specification. And, honestly, an incomplete picture of where the effort really went
Launch telemetry
Post-launch usage snapshots pulled from production told the unambiguous truth: near-zero active users one month in. I treated that as data, not as a training problem
Root-cause critique
A formal business-analysis review of my own product identified the "double-entry trap": every workflow in POMS began with a human copying data out of another system. The automation designed to repay that effort (reminder engine, document-chase escalation) wasn't delivering value either
Vendor API feasibility probes
Before redesigning anything, I probed the placement vendor's live API directly (authentication model, entity coverage, data quality, latency at production scale), so the pivot was grounded in verified access, not assumed access
Key Insight
An overloaded team will never re-key data into a second system, no matter how well-built it is. For POMS to become the source of truth, it had to feed itself from the systems the team already used, and earn the right to write back later.
The goal shifted from "a better tracker" to "a system of record that maintains itself": every student, intake, allocation, facility, and pending document flows in automatically, and the team's screens open already populated. The engineering foundation (schema, access control, test suite) was sound and was kept; the product strategy around it was rebuilt.
Three principles guided the pivot and every release after it.
Design Principles
The app feeds itself
Never ask a human for data that already exists in another system. A nightly integration pipeline pulls the full placement dataset from the vendor system, so POMS is current every morning without anyone typing anything.
Read before write
Integration risk was phased deliberately: a read-only sync shipped first and had to earn trust before any write-back was considered. Field-level ownership rules protect staff edits: machine-owned fields refresh nightly, staff-owned fields (notes, references, seat counts) are never overwritten by a sync.
Ship small, measure honestly
Every change went to live production in small, revertable slices through a spec → failing-tests-first → implement → review pipeline, with earned-value tracking against the baseline plan and periodic usage snapshots. The same honesty that exposed the adoption failure was kept as a permanent instrument.
I owned the product end to end: discovery, specification, architecture, implementation, automated testing, documentation, and executive reporting, using AI-assisted development (Claude Code) inside a disciplined spec-and-test pipeline to sustain solo delivery at production quality. IHNA's software team owned security testing, production hardening, and cloud deployment.
Each capability traces directly to a pain point from discovery.
Capabilities
Nightly sync and reconciliation engine
Pulls students, intakes, allocations, facilities, and pending documents from the placement vendor's API every night: 6,417 students and 9,424 allocations at production scale. A reconciliation layer recognises staff-made bookings and updates them in place instead of duplicating; ambiguous records are quarantined for human review rather than guessed at. This kills the double-entry trap at its root
Intake-first operational workspace
Procurement targets, facility bookings, and student allocations live on one semester sheet per intake, with live seat-availability counts, cross-intake student moves, ward-level tagging for facility teams, and campus/state filtering. The "three tools and a spreadsheet" reconciliation became one screen
Always-current reminders
Cancellation-window countdowns, document-chase escalations, and facility-agreement expiry alerts are computed live from the data at the moment a user looks, a deliberate redesign after the first version's scheduled reminder engine proved fragile. There is no batch job to silently fail; if the data says a deadline is near, the alert exists
Governance and adoption kit
Role-based access control scoped by campus, four role-specific user guides produced through an automated screenshot pipeline (so documentation regenerates as the product evolves), and an executive reporting pack (earned-value delivery tracking, benefits modelling, and adoption snapshots), so leadership sees the same honest numbers I do
POMS runs in production on IHNA infrastructure at its own internal domain, refreshed nightly from the vendor system, with the national placement team provisioned across all five campuses. The second launch inverted the first one's core failure: coordinators now open screens that are already populated and current, instead of being asked to populate them.
Delivery performance was measured against the original baseline plan using earned-value analysis, and the benefits case was built on a deliberately conservative scenario (5 hours saved per coordinator per week, one third of the team's own estimate), with time-tracking validation scheduled to firm up the numbers.
Impact Metrics
6,417 students / 615 facilities / 9,424 allocations
The full national placement dataset now lives in one system of record, refreshed automatically every night, up from 640 manually loaded students at first launch
~3-month payback, 10x three-year return (modelled, conservative)
Benefits modelled on the conservative time-saving scenario; the team's own estimate implies roughly 30x. Building in-house also avoided a recurring commercial licence
1.7–5.1 FTE-equivalent capacity
Coordinator time released back to placing students rather than reconciling spreadsheets, across the conservative-to-team-estimate range
42% more scope than planned, baseline 6.5 weeks early
Earned-value tracking across the delivery showed the baseline scope complete well ahead of schedule, with the pivot, redesign, and integration all absorbed within the original effort envelope
The most valuable artifact in this project was an unflattering usage snapshot. Launch metrics measure the builder; usage metrics measure the product. Instrumenting adoption from day one, and believing the numbers when they hurt, is what turned a stalled project into a successful one.
When users won't adopt a tool, the reflex is more training and more encouragement. The real fix was structural: remove the data-entry cost entirely. No amount of change management convinces an overloaded team to do double entry; deleting the double entry convinced them for free.
AI-assisted development gave me the velocity of a small team, but velocity without structure just produces mistakes faster. What made it safe at production scale was the unglamorous machinery around it: written specs, failing-tests-first, phased rollouts, revertable releases, and earned-value tracking. The discipline is what let one person credibly own a system that a whole team depends on.