Last year I listed Zza's College Rankings based on public data from IPEDS, to show the average net cost of attendance versus instructional value. In the context of bureaucratic load, it's interesting to see how many staffers it takes to support an instructor. Note that these reported statistics come from very different schools, and need to be taken with pinch of salt. I chose my alma mater SIU-C, my former employer Coker College, and for comparison threw in MIT and Williams College.
The second row gives how many directors and executives (management positions) it takes to run the institution divided into the number of instructors. The third row include all administrative staff, including managers. The last divides that figure into the number of students.
Of course, not all administrators are devoting their time to bureaucracy. There are plenty of services provided too, sports teams to coach, tutoring labs, IT shops, and so on. So it's not surprising to see that Williams has a lot of staff per instructor. It is interesting, however, that SIU rivals that number. Given the size difference, one might think there would be economies of scale involved. It's also interesting that there are half as many management positions per instructor at SIU. This is probably evidence of a fatter administration pyramid, where a manager pushes policy down to a lot of staffers to administer to the 20K students. I didn't put the ratio of managers to staff in the table, but it's 13 for SIU compared to around 5 for Coker and Williams, and MIT in the middle at 8.5.
In the big picture, it seems excessive that in all cases, there's at least one admin of some sort for every instructor at all of these schools, and two have twice that. Certainly a large portion of what these people are needed for is maintaining the bureaucracy.
Cutting Kudzu My current institution is no different, although I didn't run the numbers. We have a lot of forms and processes. In my IT capacity (one of my hats), I have a long wish list to automate some of these processes. This week I finally had time to work on it directly. Until then I'd been exploring off-the-shelf solutions called workflows. There are plenty of them out there, some open source ones even. I installed a couple of these, tried out commercial ones, and even looked at using our SharePoint service to build a solution. But in the end these were not exactly what I was looking for.
There is a real virtue to simplicity: doing one thing well. This is part of Google's corporate philosophy. Their first three statements are:
- Focus on the user and all else will follow.
- It's best to do one thing really, really well
- Fast is better than slow.
Some have argued that understanding exponential growth is the most important knowledge a person can learn. At the heart of any process is some number of ways in which elements can be combined. In crude terms we can think of it as combinations of elements, represented by a rapidly-growing list of ways things can go wrong in practice. In mixing ten colors together, we have 1024 basic ways to do it (2 to the 10th). If order matters in a process, it's even worse than exponential: the number of ways to list ten unique names is 10! = 3,628,600. It's essential to limit possibilities to only the essential ones if you want to avoid errors from unexpected conditions.
My eform solution is very simple. It uses standard html forms because there are already many resources for creating them. I standardize the forms with a few rules to reduce complexity. I use the OpenIGOR installation we already have to save them, and just added a new document type. So half of the problem is solved without hardly lifting a finger. Here are some of the remaining design elements:
- A form itself is a template, like a Platonic ideal. It belongs to a group responsible for its maintenance, like Human Resources
- Form elements (inputs) will have standardized names to enable global searches. So a person's first name will always be an input called "First".
- Form data is created when someone fills out a form, either anonymously or as a logged-in user
- Form data is stored in simple text files. Updates are appended with a time stamp, so the whole history of the form data will always exist.
- The owner of the form data is the only one who can update data or take actions like deleting it.
- There is view-only access that can be sent as a hyperlink, and exists automatically for anonymous submissions to a group.
- Anonymous form data comes to the sponsor group to be claimed.
- All of the form data files viewable to a user are displayed on a simple interface that already existed to list paper forms. A sample is shown below.
A sample of the form is shown below. This is one that had data filled in from the stored file. It shows the transaction history. This is all test data.
One of the nice things about this project is that it has led me to ask "why?" with respect to current processes. Rather than blindly reproducing some paper chase with an electronic version, it's good to step back and see if there's not a better way. For example, at the end of a term, adjuncts have to chase around to about eight departments to get signatures to show they've turned in grades, evaluations, etc., before they can pick up a check. This is a pain for everybody. Why not turn that process 90 degrees and simply create a global approval table that can be updated by each of those eight administrators? This would cut out more than half the work, and allow the process to pick out only those adjuncts who have some problem or another in compliance.
Of course, this is my first week with machete in hand, looking at the field of wild vines. We'll see how sore I am after the week is over, and the users have tried out the prototype. Stay tuned.