Continual Chunky Correction

stormyWhat's with Continual Service Improvement? Hardly anyone gets to incrementally improve in this millennium. Gary and George did a good job of what they were asked to do with the fifth ITIL V3 book (CSI), but I think the whole ITIL framework misses the point. The ITIL mindset seems to be that Change is all about getting things as stable as possible, and then CSI is about tweaking and refining and maturing the result. CSI always brings to my mind an image of thoughtful engineers in white coats nudging knobs and watching the dials and making notes on clipboards, inching performance higher.

The IT I know and love is more about yelling people in boiler suits running by with fire extinguishers. Or at best it is those white-coats trying to get to their control knobs while builders rip up the floors and swap out the reactor core with the system still live. Change hits you in great chunks. Change is more about going sideways than upwards.

You know how it goes... The business announce they've chosen an application for the new line of business. It is written in the Eastern bloc by two graduates in a garage, Hulitz and Pakkardsk. The manuals are in the Cyrillic alphabet, in a language nobody can identify. Support in your country is provided by a refugee, their cousin, who used to install refrigerators and is studying English. It runs on an AS400.

You've no sooner got the new system bedded down, 18 months late and only half functional, when it turns out the integration feeds to the other systems were coded by some kids in suits (graduates) from a consultancy masquerading as expert programmers, who wouldn't know business analysis if it stood up in their cereal, and so your data is being quietly and progressively screwed. Service desk calls go through the roof. Emergency funds are allocated to do a data clean up and a code fix on the interfaces, but it is only half done when a recession hits and all the contractors are laid off, including the data transformation expert leading the cleanup and the project manager. Service desk calls go through the roof but this time you aren't allowed any more staff. Eventually the service desk manager - the only one in the building who knows what all the services do - walks off the job.

You've dragged the incident queues back to four figures (by deleting everything over three months old) when the company acquires a startup that didn't even have a service desk - the developers took the phone calls. You have nearly got the run book written for the new system when the Board announces they've signed a memorandum of understanding with SAP and you're to have the new system in for the next financial year.

Meanwhile a bunch of servers have gone end-of-life and the app won't run up on any operating system known to your staff. Just when you find a VM emulator and black-box it, a new CIO starts and decides budget can only be met by a sweeping program of Lean process. The five biggest projects are put on hold, including the data cleansing you had restarted and the long-overdue service catalog, and the funds are diverted to a Lean Team to tear up fifteen years of operational processes and redesign them to strip out everything, plunging productivity to new lows. Through long hours of team re-building and subversive process restoration, you get things almost back to normal, and then the company announces a merger.

Simultaneously the CIO announces that the primary channel of communications with users is to be Twitter, effective immediately...

Photo: CanStockPhoto

...You get the idea. Who has time for knob-twiddling? Who has anything around long enough to get it past a stable 1.0? Who has measurements that are comparable to anything more than 12 months old?

The real world I know is more about trying to respond to change that comes in big crunchy chunks, not genteel thoughtful increments. And it doesn't advance up a hill, step by step towards the top. Managing IT is more like a small boat in big seas than hiking up a hill. Change lurches and swoops and tumbles - the only view you get of hilltops is as they are swinging wildly by far above. It is not progression to improvement, just desperate correction to new destinations and changed circumstance.

ITIL V4 needs a new book on Continual Chunky Correction.

This post originally appeared on the Pink Elephant conference blog, for which The IT Skeptic writes a lot of the content, including interesting interviews with conference speakers and award winners.


So True

This is so true. Sometimes you are not even done with a stable v.1.0. I've seen my share of ITIL v.0.8 betas, which remained for what it seemed forever. By the way, thanks for the link to another useful blog.

Syndicate content