When a student system project fails, the post-mortem usually blames the technology. In my experience the technology was rarely the problem. The system did what the specification said. The staff simply went back to their spreadsheet.
I understand why, because I used to be one of those staff.
How I came to this work
I started at the front counter of a college in 2007. Over the following years I worked in sales, IT operations, admissions and the registrar’s office, became a senior registrar, and then a financial aid administrator. Only after that did I move to the technical side: integrations, reports, workflows and eventually architecture.
So I learned these systems as a user first. I know them from the chair where the work gets done, with a student waiting and a deadline close. That turned out to be the most useful thing I know.
The workaround is the requirement
Every office has workarounds. A spreadsheet beside the system. A sticky note listing the three fields you must never trust. A report that everyone exports and fixes by hand before it goes anywhere.
Project teams tend to see these as bad habits to be trained away. They are the opposite. A workaround is a staff member telling you, as clearly as they can, what the system does not do for them. The spreadsheet is a requirements document. Nobody wrote it down because nobody asked.
When I start a project, the workarounds are the first thing I look for. They are a more honest specification than anything produced in a meeting.
The exception is the process
On a whiteboard, a process is a straight line: application, acceptance, enrollment, award. At the counter it is nothing like that. It is the student who changed programs in week two, the document that arrived under a different name, the term that started before the paperwork finished.
A design that handles the straight line and leaves the exceptions “for later” has automated the easy part and left the hard part where it was, with less time to do it. Staff notice right away. That is when the spreadsheet comes back.
I build for the exceptions first. If a workflow cannot say what happens to the awkward cases, it is not ready.
Words matter more than engineers think
The office calls it one thing. The database calls it another. A report that uses the database’s word is technically correct and practically useless, because nobody is sure it means what they think it means.
I name things the way the office names them. I put the records that need attention at the top, not buried in row nine hundred. I make sure the total at the bottom is one that somebody can check against a screen they already trust. None of that is difficult engineering. All of it decides whether a report gets opened twice.
What this changes about how I work
- I sit with the people who do the job, or read what they really do in the system, before I design anything.
- I write the process down in their words and have them correct it.
- I show real output early, on real cases, and expect to be told what I missed.
- I treat “people are not using it” as a defect in what I built, not in the people.
Software for a college is only finished when the person at the counter would rather use it than not. I know what that person is weighing, because I have stood there. That is the side of the screen most systems are never designed from.
If that is the kind of help your project needs, here is how to reach me.