August 2026

You’ve probably heard this one. A young woman is making her first holiday dinner. She cuts the pot roast in half before putting it in the pan, exactly the way her mother always had. When she asks why, her mother admits she has no idea. She’d only ever done it because that’s how *her* mother did it.

So she calls her grandmother, expecting a closely guarded culinary secret. The answer is simpler. Grandmother had a small pan.

It’s a familiar story, and it survives because the punchline keeps being true somewhere. Three generations cut a perfectly good roast in half, not because it improved the flavor, but because one kitchen shortage quietly became a family tradition. Nobody decided to keep doing it. They just never stopped.

Higher ed institutions have their own version of that pan. Somewhere in nearly every department sits a process born from a real constraint years or decades ago, and the constraint is long gone. The system can hold the whole roast now. The habit is harder to retire than the limitation that justified it.

The workarounds are often younger than the systems they work around. Banner traces back to Systems and Computer Technology Corporation, which started selling it in 1988 as one of the first ERPs built specifically for higher education. Colleague goes back further, developed by Datatel starting in 1979. By 2000, Banner had a decade of campus use behind it and Colleague had two.

What changed around 2000 wasn’t the platforms. It was everything around them. Dial-up was standard. Windows 98 sat on most desktops. Integration between systems was minimal, and IT departments didn’t have the staff or budget to build the automated connections between offices we take for granted now.

So the people in financial aid, the registrar’s office, and business services did what capable people always do when the tools don’t match the job. They built workarounds. A spreadsheet tracked what the system couldn’t. A printed form routed for signatures because electronic approval wasn’t practical yet. A custom report pulled data through a script because native reporting wasn’t built for the question being asked.

None of that was bad judgment. Those were smart, resourceful answers to real gaps, and usually the best option on the table.

The platforms haven’t stood still since. After the 2012 merger that formed Ellucian, both Banner and Colleague moved to the cloud, added native workflow and approval routing, and gained modern API-based integration through Ellucian’s Ethos platform. Data moves between systems automatically now, instead of through a hand-maintained spreadsheet or a homegrown script. Much of what those early workarounds compensated for is baseline product today.

The systems grew up. A lot of the workarounds didn’t.

A process built around a 2001 limitation doesn’t check whether that limitation still exists in 2026. It just keeps running. The people executing it every day rarely have a reason to stop and ask. Left unexamined for twenty years, a clever accommodation turns into duplicate data entry, slower processing, and errors a native workflow would have caught on its own. Creating the workaround was never the problem. Never revisiting it is.

A temporary solution rarely announces itself as temporary. It solves the immediate problem, lands in a training manual, gets taught to the next new hire, and within a couple of years it’s simply how things are done. Nobody remembers deciding to make it permanent, because nobody did. Repetition decided.

That’s where the cost starts stacking up. A workaround that lives in one employee’s head becomes a liability the day that employee leaves. A stopgap becomes the reason an upgrade takes three extra months, because the customization built around the old limitation was never designed to survive an upgrade. Training someone on a baseline function takes an afternoon. Training them on a decade of tribal knowledge and undocumented exceptions takes much longer, and something still gets missed.

The useful question isn’t whether a process feels important. Every process feels important to the person doing it daily. The useful question is what happens if it disappears tomorrow.

A real need traces back to something concrete: a law, a formally adopted policy, or a mission-specific requirement the standard system truly can’t handle.

A habit traces back to something softer. “We’ve always done it this way.” “The system couldn’t handle this.” That second one is a historical fact, not a business requirement, and historical facts expire quietly while the processes built on them keep running.

The shadow spreadsheet. A department tracks information Banner or Colleague has handled natively for years, usually because the spreadsheet predates the native field and nobody checked. You end up with two versions of the truth, a reconciliation task nobody enjoys, and a data integrity risk that grows every semester it survives.

The manual hand-off. Approvals still travel by email or campus mail long after the ERP gained a native workflow that could route, timestamp, and log the same approval automatically. The manual version gets defended as a safeguard, a second set of eyes. In practice it adds risk. Paper and email trails are easier to lose and much harder to audit than a workflow with a built-in record.

The custom report. Somewhere on campus, a report that once required a clever COBOL or SQL script is still produced that way, even though a standard dashboard now delivers the same output. The script still runs. It probably still works. It also depends on someone who understands a language and a data structure that gets rarer every year, and every future upgrade has to account for custom logic a baseline configuration would have made unnecessary.

This audit doesn’t need a project plan to start. It needs someone willing to ask why, then ask again.

The five whys technique, borrowed from process improvement, works well outside higher ed and is disarmingly effective here. Why do we still print this form? It needs a signature. Why a physical signature? That’s how approvals have always worked in this office. Why? By the third or fourth why, the answer usually stops sounding like policy and starts sounding like grandmother’s pan.

Once you’ve identified a habit, going back to baseline pays off in ways that are easy to underestimate ahead of time. Standard configurations survive upgrades far more gracefully than custom ones. Vendor support is faster when the system looks like the one the vendor built. Data stays cleaner when it lives in one place instead of split between a native field and a spreadsheet nobody fully trusts.

This isn’t an argument that every customization is wrong. Some reflect a real institutional need the baseline can’t meet, and those should stay exactly as they are. The point isn’t to eliminate everything old. It’s to make sure what remains earned its place on purpose instead of surviving by accident.

Retiring a long-standing process unsettles the people who’ve relied on it, even when everyone agrees it’s unnecessary. Treat it like any other change management effort.

Bring affected staff in early, before the decision is made without them, so they can flag complications the audit missed. Roll the change out in phases so problems surface in a controlled setting instead of during a critical processing period. Expect some resistance and plan for it. Comfort with the familiar is human, not a sign anyone’s doing something wrong. And frame the change around what it makes possible, not what it takes away. That lands better than a cleanup exercise.

Every institution has at least one process that made perfect sense under constraints that no longer exist. Finding it doesn’t take a consultant looking over your shoulder. It takes someone willing to ask an uncomfortable question about a process everyone stopped questioning.

Pick one this month. Trace it back to where it started. If the honest answer is a law, a policy, or a real institutional need, leave it alone with confidence.

If the honest answer is a small pan nobody has needed for twenty years, it’s time to use the whole roast.

Written by: Angie Cummings, Senior Consultant