Bringing a horse to water: getting ITSM into an academic support team
Last week I took the ITIL Foundation Certificate in Service Management and so I face a new challenge of sharing this knowledge with my colleagues. This is something we’ve looked at a number of times over the last decade or so, but never actually been able to follow through on. Perhaps because we went into it like a bull in a china shop, didn’t really know what we were trying to achieve, or just because we didn’t know where to start.
I wanted to document this journey, partly to monitor how we’re doing, but also because I think this could be helpful to other people looking at service management and implementing best practice.
Our support team
I work in the Technical Support Group in Computer Science at UCL, a team of 11, which is small relative to the number of users, infrastructure and facilities we support. The Department has doubled in the last 10 years in almost every measurable way, but our team has not. We’ve actually lost a couple of people, and gained one or two more who are supporting other parts of the Faculty alongside us, or directly involved in particular research activities that fall into our area.
With a more complicated IT infrastructure this has meant that a lot of services we’ve put in place have not been well documented, and so we sometimes struggle with managing and tracking them. Or maybe one individual owns and manages a service, but we don’t communicate this well to each other or our customers. Without anyone dedicated to this, it’s got out of hand and we know we could do better.
Geeks are unmanageable?
I suspect this happens in technical support teams at many organisations, but as Jeff Ello points out, but it’s not necessarily something that’s ingrained in the personality of a stereotypical technical bod:
“…perfectly healthy groups with solid, well-adjusted IT pros can and will devolve, slowly and quietly, into the behaviors that give rise to the stereotypes, given the right set of conditions. It turns out that it is the conditions that are stereotypical, and the IT pros tend to react to those conditions in logical ways.”
Considering new ways to organise
Recalling my previous work at McDonald’s, where service and process were key components of the IT organisation, helped me to visualise the kinds of ways in which we could work, albeit acknowledging that the company culture and sheer ability to throw money at a process were a big factor.
I’ve already considered some of the ways we work during previous studies into group dynamics, collaboration and activity theory, so the connections between the ITIL processes, tools and functions made a lot of sense. It wasn’t hard to identify parallels in our team that could be tuned and aligned with ITIL processes.
My first action after the course was to write down an executive summary of ITIL for my manager, trying not to stray into a full explanation of ITIL, but describing the purpose and methodology of “services” and “processes” in ways that relate to our work. I already had a good idea of where we were already at, so was able to identify some areas we could refine and enhance, rather than try to force through changes that people might react against.
We’ve talked through the document, and once the rest of the team have had time to digest and respond, I’ll describe these ideas for finding direction in my next post.