Tuesday, March 25, 2014


Just Do It?

Every so often, someone from outside of academic affairs will ask me, earnestly, why we don’t “just do” something.  It often takes a couple of years to move from embracing a concept -- whether it’s seven-week courses, modular courses, or whatever -- to actually running it.  Why does it take so long?  Why don’t we just do it?

The popular stereotype has it that academics are mossbacked antiquarians who think change is a four-letter word.  But that’s not it, most of the time.  (Every college has a few…)  That’s why I’m so enamored of this presentation by Nikki Edgecombe and Susan Bickerstaff of the CCRC about the real costs of implementing a new developmental sequence.  

Edgecombe has done something that far too few ‘reformers’ do: she has actually spent serious time on the ground, on campuses, seeing how the sausage is made.  When you actually confront the administrivia in its natural habitat, you realize quickly that “just do it” just isn’t that simple.  The ripple effects of what seems like a simple change are vast and serious.

To take a recent effort that’s close to my heart, let’s say that you want to run some classes in a half-semester format so students whose lives don’t follow the semester calendar cleanly can make some headway.  That’s particularly important for adults who have been laid off and who need retraining; their benefits clock starts ticking at the moment of the layoff.  It doesn’t wait for the semester to start.  If someone gets laid off in February, and you only start your one-year certificates in September, that doesn’t work.  And given the complicated lives that many students lead, you have good reason to believe that shorter courses could lead to higher success rates.  Let’s say that you have faculty who are on board, conceptually, and who are willing to give it a shot.  Why don’t you just do it?

- Faculty workloads.  If a full-semester class gets cancelled for low enrollment, you could conceivably pick up a second-half class.  But if the second-half class is part of a workload, and it falls short of the needed enrollment, what do you do?

- Financial aid.  A student who only signs up for a late-start course won’t have the credit load to qualify for most financial aid.  And unless she signed up before the entire semester started, the chances of money still being available are zero.  In other words, for all practical purposes, the late-start courses can only get financial aid coverage if the student signed up at the normal time.  That largely defeats the on-ramp function of a late-start course.

- Room scheduling.  If the classes aren’t online, a class that only meets for half the semester takes a room for the entire semester.  Obviously you can mitigate that by pairing them off, but that doesn’t work so well for lab or studio classes.  

- Publications/notices.  If all of your systems have been predicated on a single semester, suddenly introducing part-of-term courses involves manual overrides for everything.  That’s labor-intensive, error-prone, and expensive at any meaningful scale.

- ERP systems.  We use Banner; other popular options include Datatel and Jenzabar.  Retrofitting Banner to recognize part-of-term grades, I’m told, is no small task.  It likes to run one term at a time.  

- Attendance reporting.  I hate that this matters, but it does.  We have a “freeze” date on which we report enrollment numbers to the Feds.  That works tolerably well when all of the classes are running on the same semester schedule.  But introducing a set of part-of-term courses involves making some difficult choices.  If a student enrolls for semester courses and hasn’t shown up for the month of September, we report that student as a no-show.  If the student has only signed up for a second-half class, then at the end of September, she wouldn’t have shown up yet.  We wouldn’t know whether she’s really “there” or not until late October at best.  That wreaks havoc with the numbers.

These are not mostly academic or conceptual issues.  They’re nuts-and-bolts issues that have major implications for our ability to carry out reforms that make conceptual sense.  

When you’re in the weeds like this, it’s easy to lose sight of the overall goal.  Some people will deploy inconvenience as an argument against positive change.  But that doesn’t mean that their concerns can be just brushed aside as so many details.  Letting your ERP system prevent constructive curricular change is pretty much a textbook case of putting the cart before the horse, but ignoring these issues has tremendous implications on the ground.  In my perfect world, the folks pursuing reforms would spend some time learning the constraints, and work with forward-looking people on campus to stretch the bounds of the possible.  If that sometimes means redirecting political pressure away from local administrations and towards software vendors or state or federal regulators, then that’s what it means.  

So, kudos to Edgecombe and Bickerstaff.  Instead of just prescribing policy changes from on high, they’ve actually looked at messy realities.  There’s a difference between doing and “just doing,” and that difference is easy to miss from a distance.  To find out why we can’t “just do it,” you have to look closer.  

Edgecombe has done something that far too few ‘reformers’ do

Teach a full load of classes?
But, seriously, you raise good points. And while I think some of the considerations here are kind of silly and need to be removed to streamline the system, many of these are responses to the very same outside forces that lament lack of innovation. "Be more accountable! Experiment more!" Um, well, accountability means record-keeping. Record-keeping means rules and standards and paper-pushers to do it all. And now, after getting things neat enough to produce a report that isn't entirely fictional, you want us to shake it all up?

"Why are your programs so expensive? Why are you spending so much money on paper-pushers! We demand proof that you are spending this money well and producing results! Quick, somebody generate a report!"

This is as close as I get to having sympathy for the people in the admin building.
Oh, god, enterprise management systems. One of the worst experiences of my life was being on a committee that had to deal with the implementation of PeopleSoft. The program from hell.
I remember when I was teaching at Research Intensive Technological Institute that there were a couple of occasions when we were told that we couldn’t implement a couple of curricular reforms and innovations because the registrar’s office couldn’t support them. Either the database couldn’t handle the changes, or the computer program wouldn’t support them. It was frustrating to be told that we couldn’t do certain things because some computer program wouldn’t allow them. We asked ourselves: who was running this school? The faculty or some computer program?

The natural response of the faculty was to have the administration immediately order the registrar’s office or the software company to make it happen. But the faculty is often unaware of the true cost of making such changes. The faculty often regards administrators as overpaid, soul-less bean counters who only think about money, but administrators are more keenly aware that just about everything the school does costs money, and that this money has to come from somewhere. In order to introduce thse changes, the school would have to hire extra staff, bring in expert consultants, or otherwise spend tons of extra cash.

Just about everything these days is controlled or monitored by computer software. In order to introduce these changes, the software would have to be rewritten or modified. As I learned while working with Large Telecommunications Company, software is never simple, and even the most innocuous change is bound to break *something*. Should we introduce these changes too hastily, we might break some existing functionality and throw the registrar’s office into utter chaos. Student transcripts might get randomly changed, might get entirely erased, or get hosed in some manner.

Then the whole matter would balloon out of control. Students would get angry, parents would get mad, the faculty would get demoralized, and the entire curriculum would be thrown into disarray. The whole school would end up with egg on its face. The media would get wind of the problem and TV news critters would swoop down on the school. Students would start staying away in droves and administrators would start hinting about layoffs. A whole bunch of junkyard-dog lawyers would jump in and sue the school. All of this because of one simple change!

Nice read! Very informative. Something interesting: This Rapidly Expanding Grocery Chain Is Shockingly Cheaper Than Walmart.
Read it here: http://goo.gl/SisRZg

Doc and ArtMathProf are right about the software/computer issues. I worked at a particular college for EIGHT YEARS during the implementation of PeopleSoft. Every year, my department was slated to be next in the "peoplesoft rollout" and every year it never happened.

In my observation, there were two reasons for this:
1) transferring the data took a huge amount of time and admissions and financial aid rightly had priority
2) the system was billed as "customizable" and "flexible," but the college only paid for the "off-the-shelf" version. Which meant that IT was responsible for doing all the coding and building everything we wanted to do. This bogged down the process considerably.

I have trouble imagining that over 8 years, the school spent LESS (in terms of IT support, various interim programs/resources purchased to bridge the gap, lost time on other projects, PLUS HIRING the PeopleSoft representative to be a permanent member of the staff halfway through) than it would have cost to have the final product designed by the company.

As it was, there were in my opinion far too many instances where we were told "the system can't do that, so you'll have to change how you consider, count, gather, analyze and report that data."

Why, exactly, did we buy this program? To make our professional work run more smoothly and have a better, less expensive product at the end of the day.

I realize that an appeal to tradition and "we've always done it this way" is not a particularly compelling argument against innovation, but when you have to change almost everything (and not get a faster/better/cheaper result) for no other reason than "the program can't do it because we bought the basic model," you get a lot of disgruntlement and a lack of personnel buy-in to the New Tech Order.
Post a Comment

<< Home

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