CSI: Let's get out of the lab, interview the suspect, then do a warrantless search

But Continual Service Improvement – now THAT'S a real job

Is CSI a real thing? No, I don't mean the American TV series about investigating crime scenes: that's clearly a very broad-strokes* take on a real job. I'm talking about Continual Service Improvement – that thing that you see on business cards and on LinkedIn profiles from time to time, and think to yourself: “Is that actually a proper job?”

In an ITIL sense (and it's within the ITIL framework that one generally finds the CSI concept), Continual Service Improvement does pretty much what it says on the tin: it sits at the end of the process chain and continuously analyses how systems and processes are working with a view to improving performance.

The main question is, though: is it a thing in its own right, or is it just part of what the rest of us would regard as normal day-to-day operations?

I've spent a lot of time in IT operations, and it's covered a vast range of activities. After all, you take the system as delivered by the upstream teams and it's your job to keep it running. As you go along you find problems and fix them. You come across stuff that runs slowly and you investigate why it's so sluggish and maybe modify bits to work better. Because your higher-ups demand to be up to date with what's going on, you measure system and process performance and produce both technical and management reports. And if something isn't working you pass it up the support chain – which perhaps results in the original developer being passed the problem if those in the previous tiers of support aren't able to rectify the issue. All of the above results in improvements, so why the need for CSI?

Well, all the examples I gave of the operational side of things were generally reactive. Something doesn't work, so you get it fixed. Something's performing slowly so you look into why that is and improve it. You pull out shedloads of data into reports because the grown-ups are asking for it. You're not going out to find problems – you're just reacting when they happen. And unless you're a particularly large and/or overstaffed business, the chances are that keeping the lights on is taking 100 per cent of the operations team's time – which means there's no space in the calendar to do anything proactive.

And this is where the specific CSI role fits. If you have a CSI role in your IT structure the chances are that you've decided you need some person time set aside specifically to go out proactively to find ways to make things work better.

For systems and services the aim is to look actively at how things are working and find ways make them better. While the operations team is working on the gap between “normal” and “broken,” the CSI role is going one step up and trying to find ways of going from “normal” to “better” - and of course to redefine normality based on that new level of performance.

While the operations team is keeping the systems running, the CSI role actively reviews the services and the service providers (which may of course be internal teams) to ensure they're working efficiently and to ask the question: “Could we change this to make it better?”. They're examining the processes that are used around the team, but more importantly they're approaching the people who actually do the activities – and my fiver says that in at least half the cases those people will have a fistful of comments about where there are inefficiencies and ways to make things better.

And this is the point. If you don't specifically call out the concept of CSI, it's highly likely that any improvement that's made to your systems and processes will be anything but accidental. Yes, some of your ops team may have an inherent habit of wanting to improve stuff, but that's not deliberate or orchestrated on your part.

All of which brings us on to a question that I'm hearing more and more these days. On one hand it sounds trite, on another a bit pseudo-philosophical: “What goes 'good' look like?”

The ops team are there to keep systems running. But in so many cases systems find their way into production without consideration of how they should perform, and the users get used to them behaving the way they've always behaved. How often do we hear the users bemoaning the performance, or the usability, or the responsiveness, or the look and feel?

Actually, not very often. Because we're not there listening to the users saying that. Ops teams don't as a habit go out and meet the users, ask them what they like and what they hate, invite them to help improve the performance or the process. They don't go and ask whether the system people are using is any better than whatever manual process existed before. Users tend not to report areas for improvement unless performance is appalling – or unless someone tells them to put all preconceptions from their mind and describe what they'd wish things to be like in an ideal world.

“Hang about, we do that,” some of you are crying. And if you do… well, it sounds like you have a CSI function but you don't call it that.

If your ops team are doing this kind of stuff inadvertently that's great, but if you're going to get the best value from the concept you'll need to consider CSI in its wider sense. That’s because the improvements the CSI function can identify and action are only partly within the ops department: sometimes you'll need to feed them back into the delivery function for inclusion in future releases of a product or service. And, from time to time, there'll be a need for the ideas to work their way right back to the beginning of the ITIL timeline and be discussed as part of the strategy.

So, then: CSI is a real thing. Not only that but it's a useful thing. It makes you question stuff proactively, and without it you run the risk of preserving a potentially underperforming status quo. ®

* As far as CSI the TV programme goes, I think we can all agree that the job they do bears little similarity to actual crime scene investigators' jobs.

Want to learn more about DevOps, Continuous Delivery, and Agile? Head to our Continuous Lifecycle Conference from May 3-5. Full details here.