I spent an hour yesterday responding to a request from a colleague to write a clearer statement defining what level of support academic departments could expect from staff in our Academic Information Services group in maintaining their departmental web pages. She noted, quite correctly, that our service-level agreement (SLA) was a tad mushy when it came to that subject and that the ambiguity continued to generate friction among department chairs.
At one level, the text should have been fairly easy to write. The policy (sort of) says that we don’t support department, program, center or institute web sites.
We used to. Over the last few years the college has invested tens of thousands of dollars and hundreds of hours in developing a template application that allows non-technical users to create and maintain web sites. Anyone who can fill in a web form can have a website with a host of features that used to require late night hours by a departmental liaison with a PHP manual and a coffee pot. There’s no need to depend on an academic technology specialist to fill in web forms, and we have plenty of projects that do demand the skills that only those folks have. The SLA states that change pretty clearly.
The problem is that the service level agreement doesn’t align perfectly with reality. Over the years, our service model has been shaped more by our membership in the community than it has been the more transactional approach that’s implied by the SLA.
If I’m walking by a faculty office and I’m asked for help getting an image to display on a template site, I’m always going to do what I can to help. If a colleague who I’ve worked with on multiple committees, eaten meals with and see in the gym every Tuesday asks me for help re-sizing a batch of pictures for the department web site, I’d do it, because the relationship is more important to me than the policy. If someone calls and says that they’ve been struggling to understand the documentation on the template site and they still can’t figure out how to set up the calendar, I’m very likely to run over to their office to help, since supporting self-directed learners is a core value for me.
However, if someone who I don’t know sends me an email message and says “please have someone make these changes to our web site by tomorrow at 8 AM”, I’m likely to point to the SLA. Not our job. If a department creates a new center or institute that needs a complex web site built next week, I’ll probably invoke the SLA and suggest that someone attend the template workshop.
I don’t know how to capture that reality in a public document. (Maybe that’s what this entry is doing.) Our AIS group was founded to insure that there were people within the college community who had a deep commitment to learning and a passion for understanding technology. Living with commitment and passion requires living in a grey area where decisions are often made based on the implicit logic of community membership rather than on the clarity of an SLA. That logic allows us to say no to some tasks and to focus on others, even if we can’t always articulate it as clearly as we might like.
