Understanding service requirements: How true are the truisms?

How easy it is to say that ‘IT service delivery should start with the business’? It’s one of those statements like ‘the customer is king’ or ‘always clean up as you go along’, that may indeed save time in the long run but which can be a lot harder in practice than some theorists would like.

Like many a true word, just because it’s glib doesn’t make it any less relevant. But when faced with the hustle and bustle of keeping systems up and running, it can be easy to forget that IT is just a means to an end.

Business users don’t necessarily make things easier either. They are tough to please, and even if you can get past the “We want everything, and now” mentality, they can also find it hard to say what they want. I paraphrase but I can recall being told on more than occasion, “Service requirements? Isn’t that your job to work them out?”

To be fair, medium-sized organisations do have less of a challenge in trying to understand business needs than larger companies/enterprises simply because the former are less complex than the latter. This doesn’t always mean such organisations are in for an easy ride, however.

I remember one of my formative early jobs as an IT consultant. I was brought in to help write a Service Level Agreement (SLA) for a public body. What I didn’t know before I arrived was that the designated IT department representatives weren’t actually talking to their business counterparts anymore – an IT-business equivalent of a marital breakdown. I wish I could say I saved the day, but sadly all I did manage to coax out of the situation were a few response time targets.

Even in the best of cases, SLAs are only one element of service delivery. We all know whether or not we are getting what we would perceive as ‘good service’, be it in a restaurant or a shop or indeed from IT. The challenge (as I’m sure anyone who has worked in hospitality or retail would profess) is knowing what to put in place to support the delivery of services, whatever their shape or form.

In IT terms this boils down to the infrastructure itself, and how it is managed and operated. In a previous article we considered the architectural aspects of IT and how to deploy infrastructure that supports/enables the service requirements of the business.

While all organisations are different, a simple way to think about different service requirements is to remember that business activities tend to fall into one of two categories. The first is activities that are, or can benefit from being executed in a structured manner; and the second is those that cannot.

Considering more structured activities first; these have been given various names at various points over the past few decades – workflows, business processes and so on. Methodologies abound to identify and restructure them, with the goal of improving their efficiency and repeatability. Such treatments may also serve as the basis for understanding what can be automated – tasks which may or may not benefit from use of technology – and what their service expectations.

Forgive me if this is egg-sucking stuff, but in reality things don’t always work out that way. How many times have we seen software applications that are used only in part, if at all, because they don’t fit with the way the business actually works? Of course, the business can (and sometimes should) change to fit with new capabilities provided by technology. Still, business activities should be in the driving seat until it is ascertained that it is unique or adds considerable value, or is generic and does not.

For IT to support structured activities, it needs to operate efficiently – that is, as cheaply as possible. Interactions are largely transactional – responding to specific service requests or updating specific information items. In the structured world, flexibility is a second priority to service levels. If the service is unavailable or inaccessible for whatever reason, the cost to the business can be very high.

The second activity type – “everything that cannot be structured” – is no less important when it comes to deciding IT service requirements. We talk about collaboration tools, portals and information sharing facilities in this context, as well as mobile devices and other communication and information access capabilities.

For less structured activities, accessibility, flexibility and responsiveness are key drivers. There is no point at all, for example, in having a world class customer management system if it isn’t able to cough up a phone number to the service engineer who is working off-site.

From a service delivery perspective, the type of management required depends largely on the type of service being delivered. Transaction workers in structured environments need a similar structure when it comes to fault reporting and resolution, whereas more collaborative environments by their very nature will probably build in several different ways of getting to an answer (“Can’t access the file? OK, I’ll email it to you”).

At the heart of it all, however, lies a service mindset, which can be difficult to teach. I can think back to a number of colleagues who just knew that the quickest way to working out the answer was first to ask the right question. “Hang on,” said one, “Exactly what problem are we trying to solve here?”

A good starting point to find out is of course the business. Even if we think we know what the business priorities are, it doesn’t take much to check in with someone who is well placed enough to say. Assuming, of course, that the two sides are still talking. If not, it’s going to take more than an SLA to resolve that one.