Earlier this week I had the pleasure (well, mostly) of visiting another University to spend the day talking about ITSM, Change, Organisation culture and generally trying to pretend I wasn’t being interviewed for a job – something I’m evidently still trying to do. It’s no secret I’m on the look out for the next exciting opportunity (even as I find myself more and more engaged with some of the cool stuff we’ve got going on at the moment at Surrey). But that’s not what this is about.
As interview days go, it was not your normal assessment process. All 5 candidates were briefed together first thing and given a timetable of interviews, presentations, tests and tours. 3 of us knew each other from UCISA conferences, which was a little weird, but the between-sessions banter was supportive.
Aside from the tour (it’s a lovely campus), the interview and presentation (I was the last of the day, which I fear worked against me – everyone looked a bit tired!) the stand out session of the day for me was the test. And not for a good reason.
One by one we were put in an office, presented with a copy of their (very well regarded) sports department’s 5 year strategy, and asked to create either a Service Level Agreement or a Service Level Definition to support it. For good measure, we had a copy of the local IT strategy for reference.
It’s fair to say that encountering this question caused me to have a pretty spectacular brain fart. There were a couple of things I couldn’t get over:
- I’ve only ever encountered SLDs as elements of SLAs
- Nowhere in the sports strategy is any IT service referenced
Lacking inspiration I cobbled together something about a shared objective, the aims of working together, key contacts on both sides, linked elements of the sports strategy (objectives and risks) with the IT strategy and called it an SLD. Not a performance I’m proud of.
Fundamentally I couldn’t get over the feeling that this was the wrong way to answer a very good question. When a unit within an organisation creates a non-IT specific strategy, how can the IT function provide and document it’s support?
There are many aspects of ITIL that people focus on inappropriately, because they are tangible and feel easily achievable (such as producing a service catalogue, documenting – if not actually following – processes etc.) and SLAs fall into this category. The idea that we can write an SLA and everything will be fine is a common exercise in self-deception. A well drafted SLA requires negotiation skills, a sound understanding of business requirements and a strong working relationship with your customer. I’d spoken on the day that technology is rarely the answer to a problem, the same is true of formal documents.
In an ideal world, IT (along with other appropriate supporting functions) would have been involved in formulating the strategy. IT is so fundamental to how most organisations work that it’s no longer best considered a stand-alone function. Economies of scale, politics and practicality mean there should always be an IT department – the trick is in having good relationship management and being sufficiently embedded in the business departments to be involved from day one.
With hindsight I should have challenged the question. An SL* wasn’t the right response to that situation. The sports strategy featured several objectives, each with their own lead who would develop an action plan. These stakeholders are the key contacts and establishing a relationship with them would be the best way forward, helping each with their plan, developing the IT requirements and finding other, perhaps less obvious, ways that IT can help.
An executive committee owned the overall strategy and this group could be reported to periodically, perhaps by a senior member of the IT team, on how IT were engaged in delivering their strategy.
If you really wanted to document that, then it would be a Memorandum of Understanding or similar that would outline IT’s commitment to help (if you feel that isn’t a given!) and describe the key relationships. If new services are developed then SLAs may be needed (if I could be persuaded). If existing services need revisiting then there’s the usual dance of cost vs capacity/availability/etc.
My experiences of the day (which were positive overall!) were useful and while I wait for a call / email has given me more to think on about the benefits and pitfalls of ITIL. Next up – the Service Catalogue: the wrong answer to a question no one is asking…
For the curious, here’s the slides from my presentation on organisational culture change. It’s very very abridged as despite having 20 minutes to fill my first draft went on and on and on and on… The question posed is on the 2nd slide.