Archive for August, 2006

Progress Report - Huckaba - 31 Aug 2006

Thursday, August 31st, 2006

We’ve agreed to start adding our weekly progress reports to the web site. Part of the reasoning is simple: It’s a way to keep anyone interested informed about the progress we are making (duh). Another reason: It’s a simple way to how the Team’s efforts in doing what we are asking others to do: Close the Loop.

Admittedly, our progress reports may not always indicate an objective, some measure of assessment, and the complete analysis of the results before we “close the loop.” Sometimes, the whole loop routine isn’t about data or assessment; sometimes it’s just about making a decision and moving on. For example: Deciding to do this. It’s obvious that we discussed another component of a communication strategy, and Voila! Another loop closed. (Okay, maybe we’re just moving the two end points closer; maybe it’s not really a closed loop yet.)

As for the week’s work, my focus has been on two elements: Data and Netid’s. Re: Data–I have worked through about 1,000 course titles and am still “cleaning up” some of the spellings, abbreviations, and plain old mistakes in course titles that currently reside in SIS. Our goal here is to provide as clean and complete a set of course titles as possible when we display them along with syllabi or assessment documents or anything else relevant. As far as netid’s go, I met yesterday with reps from HR, Info Security, CaTS, Student Systems, and SACS Team to discuss the problems we are encountering because some faculty are not already given netid’s (or worse, they have them but they have more than one each and are, therefore, bounced out of the “golden file” and don’t show up in our available data files.

The whole netid issue is important to the SACS project because we opted to use the netid as the primary identifier for all persons in our database. The netid is presumably a single, unique ID that is not somehow protected by FERPA or some other regulation. After all, we display the netid in some email addresses. When you visit our document repository or when you visit our syllabus web site, the netid is part of the identification of a document related to a person. With that netid, we can match faculty to the name, a course section, a course title, an assessment document, a syllabus, a transcript, a curriculum vita (CV), or a publication. Simply, it’s extremely useful.

Re: the actual progress, the group agreed that we can overhaul a part of our process. Now, when we make an offer to a potential faculty member, we will include forms that, when returned, can be used to create the new person’s netid and, thereby, open up the email account and access to a number of valuable resources on campus. It may seem a bit clunky at first, but we can iron out the wrinkles over the next term as we seek to hire more faculty for temporary and permanent positions.

20060831/rch

Cleaning Data

Wednesday, August 30th, 2006

One of the advantages of a project such as this is the opportunity to take a fresh look at business practices or, simply, how we do things.  One of the hurdles we face is making sure the data are clean across multiple systems and platforms.

For example, we’re finding folks with multiple netid’s versus no netid.  New employees, for example, may be “in the pipeline” but aren’t far enough along to have a netid generated.  That holds up our posting, among other things, a new faculty member’s syllabus for a class.  We continue to find others who still have more than one netid, a holdover from a previous process whereby a student who became an employee (or vice versa) could wind up with an extra netid. 

Similarly, we find that with the use of multiple data entry points for, among other things, class schedules and/or faculty course assignments, occasionally something slips through the cracks.  We might have cross-listed courses that are not so marked (they meet in the same room at the same time with the same instructor, but the classes aren’t marked), and we occasionally (still) find a 6xxx class cross-listed with a 3xxx class, and each of those instances must be reviewed to determine whether or not that is really a cross-listing or a mistake or a legitimate use of coding. 

We’re making some basic assumptions about how data can be used, as well.  For example, if a class is a “lecture-based” class, we assume there’s a syllabus to be found.  If a class is an independent study, we assume there is likely not a syllabus.  Usually that works; sometimes it doesn’t.  That’s not so much a matter of clean or dirty data; rather it’s simply about how people interpret their own workloads.

At least with a new set of eyes viewing all the data sources, we’re finding folks are generally welcoming the fresh input.  All we really want is good data with which to work; it makes all our work lives simpler.ÂÅ

Fall term’s start spurs changes

Wednesday, August 23rd, 2006

Students have returned to campus in droves, and faculty members have begun sharing their knowledge with a new crop of eager learners.  With this seasonal change comes a set of new schedules for all involved in the SACS Team project. 

Meetings times are changing for some committees, including the Executive Committee, now meeting at 9 a.m. on Wednesdays.  The “status” meeting remains at 9:30 a.m. on Fridays.  Thus far, the Steering Committee meeting time has not changed - but that may happen once all the team members’ teaching schedules are firmly in place.  (Some things do change during the first week of classes, you know.)  The other various committees, such as the Institutional Effectiveness Committee and the Graduate Education committee, have always kept fairly flexible schedules to accommodate the ever-changing schedules of the faculty and staff who tackle such tasks.

Another change in the works is a new strategy for uploading common core course assessments and, potentially, faculty credentialing documents.  Moving away from the generic Word and Excel templates, the Tech Team is preparing web forms to allow easier updates and uploads.  This follows on the heels of some “very cool” programming to allow faculty to upload their syllabi directly into the queue for review and placement on the web.

One other big change is the upcoming “roll out” for the entire project.  Scheduled for the afternoon of 14 September, the SACS Roll-out will give all campus constituents a chance to get a first-hand look at the progress made so far and at the challenges that lie ahead.

If the fall term has now begun, can cooler weather be far behind?

Syllabi, Syllabi Everywhere….

Thursday, August 17th, 2006

Okay, I admit it. I hate having to work with syllabi. Faculty members generally provide sufficient guidance to their students with whatever kind of syllabus is proffered. Even so, between SACS and the Academic Senate, we now face a set of relatively strict guidelines for what a syllabus should include. The tricky part is telling when a syllabus passes muster and when it doesn’t.

For now, we’re trying to ensure that every syllabus has AT LEAST student learning outcomes (or course objectives), some kind of calendar or sequence of topics, and a “grading policy,” something that tells students how the course will be graded, what kind of grade scale is in force, how much homework (vs. tests vs. papers) counts, etc. When folks are reviewing over a hundred a day (as they are now with the start of a term), some things will be misclassified. Based on that information, I proceeded to send an email to a number of faculty members about something being “not quite right” with the syllabi they had submitted.

Unfortunately, the information was not 100% accurate. As a result, I probably ticked off a few folks and confused others - but I did try to recall the emails - and those that had not been read already were apparently recalled.

My bottom line: We will (and that is the imperative form for 1st person plural) get our act together. We will take a breath before we send out emails. We will double-check our work.

I promise.

Richard

The Joys of Technology

Sunday, August 13th, 2006

Simon has managed to put together a database that is able to serve a variety of documents in a flash. The catch: We’re still relying on a set of data stores that come in a variety of states of accuracy. We’re finding that using the netid as a primary identifier for people, while it made perfect sense since the netid should be truly unique, doesn’t guarantee a truly unique data set. Some people who are in the system, such as faculty, don’t always have a netid that’s valid. Some faculty don’t have a netid at all. That has led to many discussions about how to ensure that at least faculty and staff who work for the university wind up in the university’s databases.

Okay, it’s not as odd as it sounds. Some classes can be taught by “faculty” who aren’t even university employees. This happens often with consortial arrangements, classes that are taught by other universities (such as ROTC classes at UNT or UT Arlington), and some distance ed classes (such as telecampus courses). They’re perfectly legit faculty; they’re just not in our human resources system. We will generally find the faculty in the student information system in the faculty tables; they just don’t have netid’s.

Add to that “procedural glitch” the joys of searching for files. We received an email message this week-end from someone who indicated that we had not included a certain course prefix in the database of syllabi. (Syllabi? Yes. http://www.utdallas.edu/syllabus) The course prefix CLDP is legit; the prefix first appeared in Fall 2005, or so it appears in the student information system. I, however, can find no record of a CLDP course having a syllabus on file electronically. The courses have been taught–often as cross-listed courses with ACN or PSY prefixes. As a result, I have to speculate that the course syllabi have been listed under the other prefixes. Ah, yes, technology, meet the human element. Human element, meet technology.

Aside from that minor problem, much of the tech solution is working remarkably well. Simon, Serenity, Metta, and Ben have managed to stash over 4,000 documents in the database so far - and there’s plenty more to come. We already have at least another thousand or so ready to add, once we get the files formatted and tagged. Simply, the project database is growing rapidly. We’ve been awaiting that moment of “critical mass” when the project would seem to be truly underway; it seems we’re reaching that milestone rapidly.