Today we turn loose the reviewers to pound on the system, to scour the report for every error of fact or punctuation or spelling or what-have-you, and to make our tech support folks climb the walls as they try to keep up with bugz-reports.  It’s half-exciting and half-scary as we realize that we’re running toward deadline.

We already have plans in place to print the final document (20 copies, sheesh) and to assemble the notebooks for shipping.  Looks like we’re in for some long nights over the next week.

Has it been worth it?  Basically, yes.

We’ve seen that, for the most part, things really do work they way they’re supposed to work.  The occasional glitch would pop up, and we’d try to figure out why it was a glitch and how best to fix it.  Serious glitches?  Nope.

So, onward, my comrades in editing!

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.ÂÅ

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.

The SACS and QEP web sites have been re-tooled and now provide a single interface for users.  The navigation system is fairly intuitive, although you may want to take a look at Resources, Tools, and Data when you have the time so you get a feel for what goes where.  For example, the Tools section will house several applications of use to the members of the Project teams.  Resources entries will be different from Tools in that they won’t be applications; rather they’ll be papers, guidelines, and documents to assist users in their analysis of data.  The Data section will be more of the aggregated and public data used to draft reports and summaries; raw data files will be made available on an as-needed basis.

Your suggestions are always welcomed:  SACS-Team@utdallas.edu

Virginia Commonwealth University’s WEAVEonline is proving an interesting challenge.  It provides an excellent (even if somewhat light) interface for faculty and staff to detail their program assessment mission statements, outcome and objective statements, assessment strategies, and analysis.  Built on, I think, an Access frame, the program is relatively robust, provides a workable security strategy, and appears to be fairly simple to use, with an almost intuitive design.

In our version, we’ve included nearly 1,800 users, even though most are not “associated” with any program and, thus, can do little in the program.  For those users who are tied to a program (or to programs), the software works extremely well.  Users are guided to the areas for which they are responsible.  Program-specific screens lead users to develop and write a mission statement, as well as specific outcomes and objectives related to the mission.  Users are then guided to work through connecting their outcomes to strategic plan and institutional priorities–and even general education initiatives.

As users work through the year, they find a place to write the framework of their annual reports, extremely useful for budgeting cycles.  Users can also list staff accomplishments and publications in addition to events of significance.

All in all, WEAVEonline has already proved a good purchase (okay, it’s really a subscription).  As we move through the year, I am convinced every department will find WEAVEonline a reliable and helpful tool for simplifying the program assessment process.

Because we are looking to build a database-driven web site that will allow in-depth searches for our external reviewers, we have been discussing the specs for the database for months - and the naming convention for the data files that will be served from the database has been a hot topic for the last two months. Today was an almost-culmination of all that effort: we managed to work with a matrix of rules for “smart tags” to begin naming files that will become a part of the “critical mass” necessary to finalize the design of the database programming. (more…)