The IT Skeptic - Comments for "Where does continual service improvement end? An important ITIL question"

Journeys

JamesFinister — Thu, 27 Nov 2008 10:45:06 +0000

Interesting, a piece of work I'm engaged on at the moment is to map how the different service stakeholder journeys map on to each other. I've also, after exposure to Don Pages's rules that he introduced at Marval during their ISO 20000 accreditation, moved towards a rule based approach, allowing people freedom to design their own work as long as they obey basic rules such as "document all changes"

James

CSI (does not) End when the business gets it needs met

taruu :: David Stucky — Thu, 27 Nov 2008 06:07:44 +0000

But, the question is: which business needs?

CSI is about alignment and realignment with needs as needs change and as other relevant parameters change, e.g. market conditions, technology, resource availability, strategy, etc.

CSI basically continues until the service or item under consideration is retired. As I mentioned in my earlier posting, all of the ITIL CSI models and processes have built-in mechanisms for forestalling and avoiding unnecessary improvement effort.

One of the really understated things about CSI is the special relationship is has with Strategy. Strategy is the long game. CSI provides for course corrections within the long game. In concrete terms, most IT services have a lifespan of between 3 and 7 years. Yet consider the other heavily influential timescales at play in most service environments. The average tenure of a CIO is about 18 months. The average tenure of an IT staffer is maybe that much. Technology platforms rev versions every 18-36 months. Markets fluctuate wildly (the current crash is the second significant economic upheaval in less than 8 years.) So, what exactly gives us any confidence that Service Strategy assumptions will endure for the life of the services they drive? Nothing, actually! CSI provides the antidote. It's much more than just an improvement mechanism. The real key is alignment.

So, the point of that longish paragraph is simply that change is the constant and CSI provides a means of aligning against changing parameters. Hence, it really does need to be a part of things until we retire them.

CSI Ends when the bsuiness gets its needs met

Visitor — Wed, 26 Nov 2008 20:34:45 +0000

It clearly states that the focus of CSI is the goals of the organization. You need to ask yourself, based on the stated objectives, what should we measure? Going through the imrpvement process, if there are no gaps, why continue? The authors have stated publicly that they chose continual instead of continous improvement for the express purpose of avoiding a never ending cycle.

just 2 cents from a canadian perspective.

CSI - optimization

ETV — Wed, 26 Nov 2008 08:39:39 +0000

Good question about where the Continual Service Improvement actually ends. Theoretically it ends when you are in maturity level 5 and try to stay there. In practice, it ends or at least should end when you can't justify the cost for the service improvement or the customer refuses to pay for it. This is just another case of optimizing your costs and (business) benefits.

CSI : it's only just begun

EppoL — Sun, 23 Nov 2008 15:25:28 +0000

Finally with the birth of ITIL V3 there is attention for a continual quality approach to IT Service Delivery. Methods and models like Six Sigma, CMMi, Business Intelligence, finally find there way to Service management and ITIL V3, however still in its infancy.

Eppo Luppes
Getronics Consulting Netherlands

A Modest Proposal: Yes! Improve forever, continually!

david.stucky — Wed, 19 Nov 2008 05:48:12 +0000

Clearly, our fearless Skeptic has himself become so absorbed in the improvement effort that he's not found time or opportunity to review what ITIL actually has to say on the topic. Let's see if we can fix that!

First, all of the models and processes for improvement discussed within ITIL (CSI Model, Deming, and 7-Step) actually have built-in checks which keep us from moronically cycling through a tail-chasing improvement nightmare. In the CSI Model, for example, we start by clarifying the vision, then we figure out where we are at present, then we decide where we want to be. In short, if we decide there's no vision (e.g. no business case for improvement) or that we don't want to change, then we stop the cycle. Simple. Similar checks exist in the other two approaches.

So, the question as to whether we should improve forever is...um...perhaps in need of some improvement. (Sorry, couldn't resist!)

Similarly, jousting at the windmill of 'Best Practice' is a little like complaining to the cook about last night's dinner as a means of improving the breakfast he just served you. It might feel good to get it off your shoulders, but it really has nothing to do with breakfast at all. ITIL nowadays deals in 'Good Practice', not best practice. So, in short, there's always at least the possibility of improvement. Simple.

Additionally, remember that improvement can happen in a variety of ways. If we're lucky, it's clearly guided by the gap between service level achievements and service level targets. Often however, we don't have that luxury, so ad hoc objectives or some other form of negotiated goal has to guide us. (I'll note here that in environments lacking SLAs, there seems never to be a shortage of ad hoc objectives!) And, even in cases where where it's not necessary or desirable to boost performance against targets, improvement can still be a fabulous thing if it takes the form of efficiency gains against the delivery of the service, e.g. a better cost structure for delivery.

A working CSI Manager also (hopefully) should have the common sense to define the frequency of improvement cycles appropriately, usually with an eye to what the service or thing in question actually requires. Maturity usually is the most significant factor used to make such decisions. New services are reviewed more aggressively than mature ones, etc. This of course places a practical check on the amount of energy we expend toward making things better.

Finally, there's never really any danger of cycling through improvements forever since most of the things we seek to improve have a finite life span of their own. In other words, we retire them and, in gracious return, they thank us by putting the more dogged improvers among us out of our misery.

But again, if we could just get those dogged improvers enough of a break to allow them to bone up a little on ITIL, they'd give it a rest all by themselves.

A static IT environment is a

Daran — Tue, 18 Nov 2008 11:54:45 +0000

A static IT environment is a stagnant IT environment. Of course, that may match the state of some businesses today. Nevertheless, if it works, it is good enough; the majority of the processes should be fairly static. Be wary of any changes that claim to reduce costs, especially if external consultants will be needed; most likely their fees will move the ROI to zero.

Service tracking is definitely required, as standards tend to slip and a refresher every three months or so may be needed. Some kind of program management (PRINCE2?) is needed to ensure that the most urgent/valuable changes/projects are undertaken first and finished on time. Self-serving managers or consultants may continue to gold-plate a service when energy can better be focused on a different area.
When working with both ITIL and PRINCE2 there is a danger of getting bogged down in paperwork and status meetings (esp. when there is a number of people resisting the changes).

Entropy

JamesFinister — Tue, 18 Nov 2008 09:48:19 +0000

Skep,

The trouble is most ITSM initatives are sold as programmes or projects and once the excitment of a successful "implementation" (sic.) has passed things can quickly return to their sub optimal norm, especially if the key evangelists move on to new roles or lucrative consultancy jobs.

I suppose you could ask Toyota if they feel there is a point where you don't need to do continual improvement ;-)

Where I think many people go wrong is to mistake continual improvement - a good thing- for continuous improvement - a bad thing

James

What is "Best Practice!"

buraddo — Tue, 18 Nov 2008 03:22:47 +0000

So if you are doing continuous improvement without consideration of "return" or "value" then you are misapplying the theory. Continuous improvement has never been about perfection. Its been about addressing the gap between optimal and current. Where optimal is the best possible delivery given all the environmental factors, which include cost, requirements etc..

Nothing about ITSM is "Best Practice" (no matter what marketing reads) because "Best Practice" assumes singlularity. Its in the adoption of the ITSM framework that we achieve best-practice for a given environment and given business etc.. etc.. etc..

So as you say, anything implemented for the sake of implementation is doomed to failure. As I have ranted many times before, it is possible to meet business needs for IT Service delivery without ever adoption one single concept of ITSM, but should you have a gap between desired optimal and current state, then give it a go...

$0.02

Brad Vaughan