Wednesday, January 29, 2014

 

Capturing the Wouldas



Has anyone out there figured out how to quantify the number of students who would have signed up for a given class if seats were available?

We don’t have a system for waiting lists, which would be the most obvious way.  I’m told, by people who have worked in places that had waiting lists, that they’re nightmares to manage.  Apparently, when the waitlists are automated, students will game the system by signing up for far more classes than they actually intend to take, and then cobbling together the most amenable schedule they can at the last minute.  As a result, the waitlists are full of people who don’t really mean it.  And if you put them in automatically and force them to back out again when they’re clogging the system, you create a manual processing nightmare in financial aid.

If you keep manual waiting lists, the issues are even worse.  Say a section is capped, and full, at 32.  You keep a list of five students who want ‘in.’  A student drops, thereby opening a seat.  But before you -- the holder of the list -- notice, another student has gone online and captured the seat.  That student has effectively leapfrogged your list.  Once word gets out that that’s possible, you might as well not have waiting lists at all.

Because we don’t have an elegant way to handle those dilemmas, we don’t have wait lists.  Instead, we have classes that fill, classes that run below top capacity, and classes that get canceled for low enrollment.  (We don’t run tiny classes on a pro-rata basis; that was an institutional decision made years ago.)  When we have to cancel small sections, we try to do it late enough to be sure they wouldn’t have filled, but also early enough to be able to find reasonable alternatives for both the professor and the students.  It’s a necessarily frustrating and imperfect process, since it involves guessing about potential demand from late registrants.

After some students get shut out of cancelled sections, we start to hear about students who would have taken x if seats had been available.  Some students are relatively vocal, others just mutter things to someone in passing, and others take to social media.  But it’s hard to tell how many students fall into the “woulda” category for a specific class.  Volume of complaint is a terrible indicator, given that some students are louder than others, and some of the loudest complainers have the most constraints on their schedules.

The issue was less urgent when we were bursting at the seams with students.  At that point, the major challenge was just adding capacity within severely slashed budgets.  Now, though, as the 2009-10 surge recedes and we’re looking at a decade or more of declining numbers of high school grads in the area, it’s becoming more important not to leave enrollments on the table.

Online classes make the question somewhat easier, since it’s far less challenging to add server space than to add classroom space, and there’s no issue of timeslots.  But we still need faculty, and still need to be able to afford to pay them.  Online courses help, but don’t solve the entire problem.

I’m guessing that the most sophisticated online merchants track more than just purchases; they also track attempted purchases that fell short, people who just looked (what IRL we call “window shopping,” but I don’t know what the online equivalent is --- browser shopping?), and what people defaulted to when a given item wasn’t available.  But I don’t know of any ERP systems that do that.

Wise and worldly readers -- especially those in enrollment management -- has anyone out there found a realistic and helpful way to track the “woulda” enrollments?

Comments:
We found the following worked for our waiting lists:

1. A student could waitlist at most one section of a given course. That is, if a student was waitlisted for one section of English 101, the student was not allowed to waitlist another section of English 101. Similarly, a student who was enrolled in English 101 could not waitlist a section of English 101 that the student perceived to be "better" in some way.

2. A student could waitlist at most two courses at any given time.

This is not to say that the registrar's crack team of software engineers did not create hilarious situations from time to time with the waitlists.
 
We don't have waitlists, but we do have instances where the Dean will push one student into a section over the capacity so it doesn't open up when someone drops. (Our ERP stinks, but it does allow manual enrollment.) That works if there are actually enough chairs in the room, just not enough seats. I think we only use it to deal with serious job conflicts.

What we do is try to revise our schedules from time to time based on past data. The cost is running a trial section at a new time to see what happens. The management problem is separating cult of personality from time constraints, but I am told that you can see that happen in real time when registration opens.
 
We have similar restrictions on being waitlisted for only one section of a course, but as far as I know students can be waitlisted for as many units as they want up to the limits for a full-time load.

After the first day of instruction, students can't add themselves into classes anymore. Dropped students automatically get replaced with students from the waitlist. If students want to add and are not on the waitlist, they have to get a permit number from the instructor (permit numbers are essentially override codes).

In especially impacted classes, the permit numbers are pretty precious information. I once heard of a student who was able to "steal" a permit number by looking through a grad student's papers while under the pretense of visiting office hours!
 
Our registrar default setting is that once a class hits cap, any additional adds require instructor permission. I.e., if a class is capped at 30, but drops to 28 during drop/add, it will still read as closed unless the instructor requests otherwise, so that students have to request permission to add. The instructor can then issue permission only to those who've been attending class to add, or only seniors, or whatever their preference is. Seems to work reasonably well.
 
Congratulations, you've just discovered why the reservation systems are worth more to the airlines than the airplanes, and why there are fees for changing reservations!

Seriously, though, over-booking has been a problem for any service that offers a fixed capacity on a fixed schedule, whether it's a flying tenement, an eleven bedroom sleeper, or Physics for Poets in a 500 seat lecture hall.

I've resorted, recently, to requesting a "Hold Further Enrollment" once my class fills, and maintaining my own waiting list. Of late, Northern Illinois has been slammed by the smaller flow of late adolescents leaving high school, and this dodge is purely theoretical. It worked well enough the few times I tried it.
 
Waitlists won't give you the whole picture as they shift so dramatically in the first few weeks of class. The software answer to your question is to put a function in the registration system where students can indicate they would have added if they could but they couldn't and therefore didn't. But I know that would be really difficult.
 
When I was an undergraduate, the system worked like this:

When you were signing up for courses, you would submit via the online form the list of sections that you wanted to enroll in and a list of alternates that you would accept if your first choices were not available.

On some magically chosen day, the computer in the registrar's office would process all of these requests. Some courses had enrollment preferences based on "seniors first" or "declared majors first" or "freshmen first." Other courses had no such restrictions.

During the time between "submit your slate of courses day" and "enrollment matching day," the Powers That Be could determine to fuss with the course offerings so that they better matched student demand.

After the magic enrollment matching day, everything converted to first-come, first-served.

I am pretty sure that this was homebrew software, as the registrar had previously been faculty in the Operations Research / Industrial Engineering department.
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?