Wednesday, November 02, 2005

 

Carts, Horses, and IT

I recently endured one of those conferences where the formal part of the program was disappointing, but the intramural conversations between presentations were actually instructive. Among other things, I learned that what I’ve been told was simply a fact of life, isn’t.

At my current school, we have a terrible time enforcing course prerequisites because our IT system isn’t very good about blocking students who don’t have them. We’ve actually rejected calls to tighten up our prereqs because the computer (broadly speaking) couldn’t handle it. The cart came before the horse.

(Why a student who isn’t academically prepared for a course would sign up for it, against the sage counsel of academic advisors, I still don’t know. When I ask them, they mutter something about ‘getting it out of the way,’ graduating quickly, or ‘who cares?’ Mystifying. Do they think we pick prereqs out of a hat?)

When I’ve complained about this, which is pretty much monthly, I’ve always heard the same answer: it can’t be helped. C’est la vie. Suck it up.

At this conference, almost as an aside, someone from another school mentioned that their IT system doesn’t have this issue. It enforces prereqs seamlessly, so the faculty is arguing over what the particular prereqs ought to be.

Hmm...

It’s almost as if the IT people are more concerned with other things...

Does your school have any weird academic decisions based on operational failures?

Comments:
On the students ignoring prereqs:

I don't know what it's like there, but in my experience teaching pre-professional students (especially, but not only, at Ivy League and "Public Ivy" joints): they consistently ignored prereqs because everybody knows all classes start off with an intensive review section, at least for the first 1/3 of the semester.

But of course the reason the instructors felt obliged to review every year was that there were in each class many students left clueless about the prereq material, either by (a) never having taken the class, or (b) never having learned the material in the class.

One arguably valid reason a student might not have learned much in a prereq class is... wait for it... because the lion's share of the time in that prereq class was spent on its own prereqs, and not the new material. And so on.
 
Mine has a quirk that drives me batty. It does not and allegedly cannot prevent students from dropping before the posted drop date -- even students who have plagiarized or otherwise engaged in behavior that is in breach of the student code of conduct. Now, this is the ONLY school at which I've seen this. Isn't it just the dumbest thing you've ever heard?
 
One word: PeopleSoft. I can't tell you how many things we're told (whether it's true or not is a different issue) we can't do, or must do, because of how PeopleSoft works.

One example, which has had enrollment consequences: We used to have two separate summer sessions, one runing from mid-May to the end of June, the other from about July 1 to mid-August. Students registered separately for each. Now we have one summer session, with two parts (same as above), but students are expected to register for the whole summer (and pay) up front. Not surprisingly, enrollment is off in the second half of the summer. (It's a little more complicated than that, but not much.)

But PeopleSoft can handle pre-requisites.
 
Man, you have a lot of problems with your IT crew.

There's this prerequisites problem, the constant-update-of-software problem that's making your faculty batty, their steadfast refusal to switch to open-source software...

Sounds like one of two things. Either your IT department is way too small and it spends all of its time just holding the ship together, leaving no time to fix the larger problems, or it's staffed with goobers.

I have no idea how you'd figure out which is which. Maybe talk to IT about these issues, compare your CC's department with others to see if it's bigger or smaller and how they handle the same problems?

IT is tricky. Stuff that sounds simple can be insanely hard, and stuff that sounds insanely hard can be simple. There's no way to tell until you get into the nuts and bolts of the software, which requires...a background in IT.

As far as students and prereqs, I don't remember lack of concern for prereqs deriving from as rational a thought as "everybody knows the class starts off with a recap" and more "I need this class, so I'm gonna take it. Prereq? Meh. I can handle it." That was my impression, anyway.
 
When I requested last year to have a 2nd IP address given clearance for connecting to the LAN from my office, so that my TA could, you know, TEACH...

IT refused and told us that its job was to protect the network (from dirty Macs I guess) and that it had no interest in the needs of teaching.


In writing.
In an email.

Priceless.
 
I've taught at a few different post-secondary campuses, as well as a couple of K-12 campuses, and I'm convinced most K-14 IT departments are staffed by goobers.

Often, one can easily verify this by looking at the salaries the goobers earn and comparing them with the salaries paid in private industry.

Someone I know was making $80K/year as a network engineer for a major defense contractor out on the west coast. Dooes your campus, even after you adjust for local variation, pay any of their IT people a salary in this range? I'm talking indians here, not chiefs.

When I look at the IT department at my campus, I find myself wondering if their approach to hiring goes something like this: "Why should we hire one competent person at $X thousand per year, when we can hire five goobers for $X/5 thousand per year?"
 
Well, we can't increase the size of our lectures (which would allow us to decrease the size of our 30-student "seminars") because we don't have large enough classrooms. Does that count?

And we can't improve our web site b/c there's only one web person for the entire college, and he's doing other things.
 
Verily, there are goobers among us, but I prefer to stay away from ad hominem explanations. If the problem were simply a few goobers, we could do a purge and that would be the end of that. Given how widespread these issues seem to be, I'm guessing the heart of the problem is something more structural.

On ignoring prereqs, I think my brother is closer to accurate than Mr. Tozier. At my cc, we don't spend anything even approaching a third of a course on review, but students skip prereqs anyway. "False bravado" probably comes closer than any sort of rational calculation.

PeopleSoft, Oracle, Datatel -- they've all got really fundamental, very annoying quirks. I haven't tried Banner yet, so I can't speak to that one. If some grant-funded techie would start up an open-source version of one of these...

Classroom size is a mixed blessing. I'm fairly confident that larger classrooms, over time, would lead to larger sections w/o the corresponding smaller sections; the baseline would move, and that would be it. Budget crunches have a way of making that happen. (My previous school was a champ at that.) At least when the fire marshall sets a limit, it's a real limit.
 
We have exactly the same problem with pre-reqs at my university, though a new system is being phased in over the next two years, which is SUPPOSED to solve the problem. Interestingly, even though the new system is supposed to be able to handle this pre-req thing, the administration asked us to eliminate as many prerequisites as possible before the new system goes into effect to make it easier on this new system.

In short, yes, I think the problem is structural. I think part of it is that while instructors are unhappy about these sorts of things, they do not want to fight the good fight in meetings where decisions get made. IT people (at least at my university) ultimately are focused on the tech side and don't realize that ultimately teaching should be the force driving the technology and not the other way around. Of course, they aren't entirely to blame because, again, people doing the teaching don't want to deal with IT unless it's absolutely necessary.

And if you've got an administration that's all about the bottom line (as mine is) then generally they tend to side with whatever is more cost-efficient.

I'm not sure what to conclude from all of this, but no, you're not alone.
 
I have encountered no problem in being blocked if I don't 'appear' to have the pre-reqs. My CC has a pretty good system, pre-reqs can only be cleared manually. If you want to bypass a prereq, you'd have to convince a counselor to let you do it. I think they use 'WebReg' (but I don't know which company develops it.)

It seems like your problem is an 'attitude problem'-- whether your CC/IT is willing to work things out.
 
You are right in that this is a systemic problem, not just at your school, but in so many other schools.

IT departments get away with serving the wrong master because the administration is afraid or mute when dealing with them. It is so important that schools have at least one learning technologist or equivalent who is focused on the educational needs of the college and who has the knowledge to deal with IT.

I have seen IT departments completely fabricate requirements because they didn't want to deal with a request or thought it would be too much work. Its not at all uncommon.

Could you ask other schools that use the same system you do, through a listserv or something, if they are able to enforce prereq's?
 
There's a 'users group' for our system, and we've asked our rep to the group to hammer that one home. Whether anything will come of it, I don't know, but I can't imagine that we're the only school with prereqs.
 
When I went to a CC, and to UC, we registered by silling in computer forms. The computers checked prereqs and blocked people from registering for courses they shouldn't take.

At the CC where I last taught -- 20 years later -- the computers can't do this ...

hmmmmm
 
Hi,

I happen to work in "IT" for a large 4-year, so I thought I'd chime in..

"We can't, not possible, sorry bub" is a very generic response. I've used it, yes, but only when it's true and I know that the real answer would only end up confusing the issue more. The fact that you're getting it means there's something else going on under the surface.

I'd wager that even if your SIS system does allow pre-req's (perhaps you have an older version that doesn't) it may be that there are issues that are not easy to overcome and not easy to discuss for one reason or another (either they make the unit look bad, or there's a bunch technical jargon that's confusing, or maybe it's politics..) Some common examples would be:

- The Pre-Req information is not owned by the SIS people and there's no way to get it, or get it ina format that's useful. (Ownership and flow of data is a big issue everywhere)

- We have the data, but it won't fit into the system without major work which we don't have time for and don't want to do because we're upgrading this next year anyway. (OASIS, for instance, can cause these kind of issues)

- We have the data, and we can put it into the system, but once it's there we need to make some large, sweeping changes to the business processes of the University to support it, and we're not willing to undertake such a project right now. (PeopleSoft and Banner are known for this, as they are extermely complicated and hard to fine tune, and often it's easier and cheaper to change the University than change the Software.)

- We really don't know how to make that happen, and don't have the budget to hire consultants to do it for us. (This is a corallary to the above and an indicatior your IT unit is underfunded both in yearly budget and staffing.)

There's lots more similar reasons, but all of them are probably valid for one reason or another, unless of course, they really are just goobers. Sadly, you're not hearing those reasons and it's probably time for you to find them out. Minimally for the short term, knowing this might help the it sting less :)

I think that a lot of IT units in higher-ed really do make policy by limiation (I won't go so far as to say "operational failures") becasue often solving the problem correctly is too resource intensive. So things are built around the known limiations. After a few decades, this can create some very odd processes and continue the lifetime of the limiation well past it's actual lifetime and make everything more difficult to untagle. This can be made worse because there's typically old and crufty code written by someone who retired 10 years ago in a dead language that needs updating along with the irradication of the limitaion. Business Process Kudzu, if you will, which can lead to the above kind of issues.
 
Anonymous -- Thanks! That makes much more sense than anything I've been able to come up with. If what I'm hearing from them is shorthand for "the explanation is far too complicated/embarrassing/lost to history to go into," that would explain why they always seem so pinched and crabby when they say it.

Thanks for giving at IT point of view. The goober hypothesis may not be the final answer.
 
My university is in the process of upgrading our registration system, and one of the absolutely best benefits is that "the computer" can now handle multiple pre-requisites. My department has also gone through a fairly extensive process of reorganizing our curriculum to require our majors to take more senior seminars which are limited by serious pre-requisites.

(This is an English department, so there are fewer lock-step pre-reqs than there probably would be in a science department; nonetheless, lit theory is a huge one for us.)

Even though we're still in the process, these changes are making a world of difference. Now, when students want to take a course they don't have the formal pre-req for, they actually have to get the instructor's permission. As an instructor, I can look at what a student's taken, and see that s/he has enough experience to be likely to be a good contributor, or I can rely on previous experience with the student. So there are ways around the pre-reqs, but students can't just ignore them.

The biggest benefit has been that our senior level classes have better-prepared students so that the discussion starts at a higher level from the get go. I may review a theoretical concept, but I'm usually able to do it quickly, and can count on most students to chime in. As a result of the higher level of discussion, etc. our seniors seem to be making stronger connections between classes, getting a stronger sense of themselves as part of a community of people who study English seriously, and mostly enjoy the more challenging classes.

We're still at the beginning stages of seeing our new curriculum kick in; that is, we have students who are still fulfilling the old curriculum major requirements, who are still being allowed to by-pass some pre-requisites. But so far, I think the faculty is thrilled and the students seem to be indicating (in exit interviews and such) that they're getting the educational experience we were aiming for.

I hope your IT folks can find a way to get pre-reqs into the system effectively, and that your faculty can take advantage of the benefits.

ps. Great blog, by the way. I went to a CC for a couple years, and it's fascinating to get a sense of the other side of that experience (which was a wonderful opportunity for me).
 
The only way to handle this is to put the IT department under the chief academic officer. Otherwise you are roadkill. You may be roadkill anyhow. The major step missing at CCs and non research places is that when the IT software is specified academics have no input. NIGO. Nothing in, garbage out.
 
Post a Comment

<< Home

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